New voltage regulator for ZX Spectrum+

I decided to make small reorganization in my Spectrum+. Removing the heatsink for the linear voltage regulator seemed to be a good idea, and this generally means that the linear vreg will also have to be removed (as usually it has to dissipate about 2.2W). So I had to put a replacement vreg that doesn't need a (big) heatsink. The usual rule of thumb is that small components/modules without heatsink can dissipate up to 600mW without serious concerns for their longevity. 2.2W will fry any regular electronic component, even TO-220 package, when not cooled down.

Some months ago I purchased a handfull of these switching regulators. The expected current consumption of the Speccy is about 0.5A, so it was a good match for this regulator.

Here's the old linear vreg before the change (heatsink is already removed):

And here's how it looks after the replacement with DC-DC converter:

The switching regulator has good enough efficiency (datasheet states it's up to 95%?), during normal operation of the Speccy it gets barely warm. As a result of the improved efficiency, the Speccy current consumption was reduced from 550mA to about 400mA (with 9V power supply), which is very nice.

debconf: warning: possible database corruption

I recently saw this error message on my ARMHF Debian board. Here's how it's solved:

cd /var/cache/debconf
rm *-old
for i in *.dat; do cat /dev/null > $i; done

Mainline Linux for RIoTBoard

Yep, these days you can enjoy a good Linux mainline support for RIoTBoard, thanks to the hard work of lots of people. Here are my notes how to build latest Linux kernel for this cool board.

mkdir ~/riotboard
wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.17.tar.xz
tar xf linux-3.17.tar.xz && cd linux-3.17
make distclean && make imx_v6_v7_defconfig && make LOADADDR=0x10008000 uImage -j4
cp arch/arm/boot/uImage ~/riotboard/
cp arch/arm/boot/dts/imx6dl-riotboard.dtb ~/riotboard/
make modules_install INSTALL_MOD_PATH=~/riotboard

Well, now ~/riotboard contains the fresh kernel, device tree and drivers, so you can copy them to your embedded target.

Mainline U-Boot for RIoTBoard

Well, the days when there was no mainline U-Boot support for RIoTBoard are behind us. The official board support was added with v2014.07. Here are my notes for how to get the latest bootloader for your RIoTBoard, just make sure you have a working ARM cross-compiler.

wget ftp://ftp.denx.de/pub/u-boot/u-boot-2014.10.tar.bz2
tar xf u-boot-2014.10.tar.bz2 && cd u-boot-2014.10
make distclean && make riotboard_defconfig && make u-boot.imx -j4

You can load u-boot.imx on the board either via USB OTG port (by using Freescale's MFGTool or Boundary Devices's imx_usb_boot), just configure the on-board micro-switches for USB OTG boot, as described here.

Otherwise you can flash the new bootloader to your non-volatile boot memory (spi nor, sdcard, raw/managed nand, etc). I prefer to test new bootloaders via USB.

Introduction to RIoTboard

I have this board for some months, finally decided to put some technical notes about the RIoTboard's peripherals and interfaces.

Main components:
- CPU: i.MX6 Solo @ 800 MHz, 512K L2 cache, 32K+32K I&D cache
- RAM: 1 GiB DDR3 @ 400 MHz (800 MT/s), 32-bit, single rank

Storage:
- USDHC2: SD card (J6)
- USDHC3: MicroSD card (J7)
- USDHC4: 3.6 GiB eMMC NAND

Interfaces:
- UART1: Connected to OpenSDA debugger
- UART2: 3.3V serial console (J18)
- UART3: Expansion port (J13)
- UART4: Expansion port (J13)
- UART5: Expansion port (J13)
- I2C1: PMIC, audio codec
- I2C2: HDMI DDC
- I2C3: LVDS DDC, Expansion port (J13)
- I2C4: CSI, Parallel camera, Expansion port (J13)
- SPI1: Connected to OpenSDA debugger
- SPI2: Expansion port (J13)
- SPI3: Expansion port (J13)
- USB 2.0 OTG: OTG port (J11), the board can boot from this interface
- USB 2.0 Host: uses internal USB-hub to provide 4x host ports with over-current protection
- Ethernet: 10/100/1000 Gigabit ethernet (PHY address 0x04)
- Audio: I2S integrated audio codec with MIC preamp and HP amp, supports sample-rates 8-96 KHz, supports master-slave clocking, full-duplex mode. Beware that the SGTL5000 doesn't respond at all to I2C communication if the master clock is not running.
- HDMI: HDMI connector (J3) - the only port that has ESD-protection
- LVDS0: LVDS connector (J2)
- CSI: MIPI serial camera (J8)
- Parallel camera: Not sure whether this is MIPI-compliant (J9)
- JTAG: Debug interface with non-standard connector (J10), you can easily wire standard 20-pin ARM JTAG connector here

Boot sources:
They are selected by 8-way micro-switch SW1. Here's a list of some common boot configurations:

[00 xxxxxx] - Boot from fuses (Note: fuses are not programmed by default!)
[01 xxxxxx] - Boot from OTG (can be used with MFGtool for Windows or imx_boot for Linux)
[10 xxxxxx] - Internal boot (boots according to BOOT_CFG pins)
[11 xxxxxx] - Reserved

Here are all usable combinations (imho) for the Internal Boot:
[10 10X010] - MicroSD card (J7), normal boot, 1 delay cells, 1-bit, port = USDHC3
[10 10X110] - MicroSD card (J7), normal boot, 1 delay cells, 4-bit, port = USDHC3
[10 10X001] - SD card (J6), normal boot, 1 delay cells, 1-bit, port = USDHC2
[10 10X101] - SD card (J6), normal boot, 1 delay cells, 4-bit, port = USDHC2
[10 110011] - eMMC NAND, normal boot, 1-bit SDR, port = USDHC4
[10 110111] - eMMC NAND, normal boot, 4-bit SDR, port = USDHC4

Legend:
Orient the PCB so that the imx6 is at the top side, and SW1 is bottom side. 0 means low switch position, 1 means high switch position.

Pros:
The board has a pretty modern and fast Cortex-A9 CPU (if you have used Cortex-A8 boards in the past, you'll feel the difference instantly), and also the CPU is probably the single best documented modern ARM Cortex-A9 in the commercial world. The board has also good amount of system memory, flexible on-board audio, lots of connectivity and display options, low power consumption. All this can be yours for a price which is definitely in range of home experimenters (it currently retails for 70.49E at Farnell, which is about 89$ USD). Btw, the board was designed and manufactured by Embest Technologies, and I think they've done a great job with this design. As of today, Embest is acquired by Farnell.

Cons:
All interfaces (except HDMI) are missing ESD protection (TVS diodes are not soldered, even if they're shown on the schematic). Taking into account that this board is intended to be attached to zillions of user devices, peripherals and what-not, for me this is a serious failure. Congratulations, you-re just about to fry 70 euro.

TDA1543 from China

Recently got a bunch of TDA1543's from China-based seller. I was wondering about how good these chips are, taking into account that they are not manufactured anymore, and there's a huge change to receive either completely borked chips, or chips discarded by factory testing.

So, as I usually do for all my new ICs, I set up a testbench and checked what's up with these. I was kinda pleasantly surprised to find out that they actually work. Still puzzled, I decided to check all possible sample rates that my USB sound card allows (I'm using for the test Asus Xonar U7). It turned out that chips handled without issues samplerates in the range 44.1-96 KHz, but on 176.4 KHz instead of music I heard horrifying noise. I explicitly check one old original TDA1543 made by Phillips, and handled 176.4 KHz without any issues, exactly following the specification. Of course, the original Philips TDA1543 also couldn't play at 192 KHz.

Intrigued by this finding, I tested all new chips from the batch (10x total) and found that:
- 6 of them work up to 96 KHz
- 3 of them work up to 176.4 KHz
- 1 of them is sleeping with the fishes

Well, that's not too bad. The intended usage for these DACs is for retro computing projects using samplerates below 96 KHz, and the can easily tolerate non-audiophile performance, so no big deal.

So, this was my opinion on "TDA1543 from China". Hope this helps someone.
Regards.

Building Yocto 1.6 "Daisy" for i.MX6

Quick guide how to download and build Yocto 1.6 "Daisy" for i.MX6 platform:

mkdir ~/bin
curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo

PATH=$PATH:~/bin
mkdir fsl-community-bsp && cd fsl-community-bsp
repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b daisy
repo sync
source ./setup-environment build
bitbake core-image-minimal

The default target machine is "imx6qsabresd", but you can change it from conf/local.conf file.

Getting my UPS to work with Linux

Recently I acquired an UPS to power my home file server. The model is "Eaton 5E 1100i USB", made by Eaton (obviously). Now, to tell you something straight - if you relate Eaton with the high-end PowerWare UPSs from the near past (we used them to power our server room back in the good old days), well... that's OK, but the 5E serier is something I'll never refer as "high-end". Let me explain.

The UPS box came with the following things:
- 1x UPS
- 2x IEC power cords for attaching equipment
...and nothing else. No power cord to power the UPS itself from the grid, no USB cable, no CD/DVD with software. Cool, huh?

First thing I did when got the UPS was to connect it to the power grid so it can immediately start charging the batteries (sitting on the store shelves doesn't improve the battery health, you know). Then I connected the UPS via USB to my laptop and started looking for software, so I can test it on Windows (somehow assuming this will be the easiest way to test USB commnication). Eaton provides a software package called "Eaton UPS Companion", so I went to their site to download it. Unfortunately, if you want to download their software, you'll have to provide them your email, and there's no way around it (it's pretty funny, on the web form asking for your email they say "Hey, please enter your email, we maybe already have your details!" - how the hell is this possible I don't know). So you give them away your email address, and then you receive a download link in your email, where you click and get the software. The SW package was small (2-3MB) and downloads/installs quickly.

Again unfortunately, after installing their software on Windows 7, it just refused to work properly. The SW was unable to connect to the UPS over USB, and in general it was totally non-responsive. What's even cooler is that the SW showed in the system tray and there was no way to stop/exit it. It didn't reacted on menu actions like (start / stop / show). I can admit that giving my email away on "someone out there" and installing arbitrary crap on my box was already enough to piss me off quite a bit, so I decided that half an hour wasted for Windows was enough and rebooted the machine under Debian.

Initially I expected that the Linux UPS setup will be much harder than Windows. So, it turned out to be exactly the opposite. First, connect the UPS to an USB port, and check whether the USB device is "visible" to the OS:

lsusb
...
Bus 008 Device 002: ID 0463:ffff MGE UPS Systems UPS
...

Next you need to install a software package called "nut" (comes from Network UPS Tools):

sudo apt-get install nut

Now you need to configure your UPS, so nut can use it. You have to edit /etc/nut/nut.conf:

sudo mcedit /etc/nut/nut.conf
...
MODE=standalone

Now edit /etc/nut/ups.conf and add section for the UPS device itself:

...
[myups]
    driver = usbhid-ups
    port = auto
    vendorid = 0463
    pollfreq = 30

You may need to adjust the vendorid to suit your case. The pollfreq setting show how period in seconds between consecutive USB commands to the UPS - you can reduce it, but some UPSs hang if it's too fast (mine works OK with pollfreq = 10). Again YMMV.

Now we can start the driver:

sudo upsdrvctl start

If the tool moans about some issues with starting the driver, you can reboot the machine (not scientific, but it works).

And finally, you can check that your UPS is connected and alive - there are console and GUI tools to do this. The console tool is called "upsc", and you can use it as regular user:

upsc myups

And here's the output for my UPS:

battery.charge: 75
battery.runtime: 1737
battery.type: PbAc
device.mfr: EATON
device.model: 5E 1100i
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.vendorid: 0463
driver.version: 2.6.4
driver.version.data: MGE HID 1.31
driver.version.internal: 0.37
input.voltage: 229.0
outlet.1.status: on
outlet.desc: Main Outlet
outlet.id: 1
outlet.switchable: no
output.frequency: 49.9
output.frequency.nominal: 50
output.voltage: 233.0
output.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.firmware: 01.04.0018
ups.load: 12
ups.mfr: EATON
ups.model: 5E 1100i
ups.power.nominal: 1100
ups.productid: ffff
ups.start.battery: yes
ups.status: OL CHRG
ups.timer.shutdown: -1
ups.vendorid: 0463

If battery.charge/battery.runtime fields are "0", you'll have to wait for several minutes until they're populated with actual values.

There's a GUI tool called "NUT-Monitor" and is located in the "nut-monitor" Debian package:

sudo apt-get install nut-monitor
NUT-Monitor

(TODO: Add configuration for handling power events)

On the positive side, things are looking well with the USB communication. The UPS provides lots of details about it's state of charge, voltages/currents, attached loads, etc. It's just better than the good olf days when most of the UPSs (except the most expensive ones) had dumb serial interface with ON/OFF signals, and now even a low-cost UPS has similar features. Also, I'm still to test how this UPS handles power outages (but I think our power company will do this for me in the next evenings).

So, that's it - just 5min to make it work with free/libre software in your favorite OS. It's also possibly to export the UPS status across the local network, so other machines can also use it (for power management or even for logging). Now you can enjoy your freshly power-backed system and don't forget to thank to the NUT Team.

Thanks for reading.

PS: When the UPS is charging, the cooling fan is quite noisy, which freaked me out the first time. This is definitely "no go" if you want to use the UPS in silent environment. The good part is that during normal operation (aka waiting for power outage), the UPS is dead silent.

Simple optimizations for SSD on Windows 7

Recently I dusted-off one SSD and decided to install it into my ThinkPad X201. It's a small 64GiB 2.5" Transcend drive, and wanted to see how much better is using the SSD compared to the conventional spinning disk drive. So here's my check-list:

1. Install Windows 7 as usual.
2. Disable scheduled disk defragmentation - right click on the drive, select "Tools" tab, click "Defragment now...", click "Configure schedule...", uncheck "Run on a schedule".
3. Disable file indexing - right click on the drive, select "General" tab, uncheck "Allow files on this drive to have contents indexed in addition to file properties".
4. Check the MSAHCI driver is using SATA mode - edit registry key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msahci\Start" to value "0".
5. Reboot and check in your BIOS that the disk is in SATA (sometimes described as AHCI) mode, not Compatibility mode.
6. Check for disk TRIM support, run this command in the console (run "cmd" as administrator): "fsutil behavior set disabledeletenotify 0".
Note: SSD TRIM can actually slow-down your machine, by explicitly marking blocks for deletion. It's entirely possible to have TRIM disabled and to just over-provision your disk by leaving some non-partitioned spaceon the disk (between 7% and 25%). Feel free to experiment and choose what suits you best.
7. Disable your system page file - Control Panel -> System, select "Advanced" tab, click on "Settings..." button in "Performance" area, select "Advanced" tab, click "Change...", uncheck "Automatically manage paging file size for all drives", select "No paging file" radio-button, click "Set", reboot (hey, GUIs are nicer than command-line, aren't they?).

It's not very scientific, but it works.

PS: This information was found on the "Internet", and was copied here solely for my own convenience. I didn't invented this tip, credit should go to others.
PS2: Need to dig out my notes for similar checklist on Linux SSD setup.

Synchronizing Linux and Windows 7 system clocks on dual-boot machine

Offtopic: As I tend to forget I have to write things down, especially important ones. So I decided to start putting short post-it notes online, just not to forget countless little things that I have to remember.

It became a habit of mine to always have at least 2 OSes installed on all of my machines - a favorite one (GNU/Linux) and a "expensive-and-buggy" one (Windows 7). It took me a while to notice that the system clock is always wrong in one of the OSes, and when you fix it in one of them, it breaks the other one. It turned out that Windows 7 prefers to use user's local time as system clock, while Linux uses UTC and calculates the offset to the local time. I decided to force Windows 7 to the "the right thing". You need to edit the following registry key value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal

...and change its value from "0" to "1". If this registry key value doesn't exist, just create a new one with value type "DWORD" and set it to "1". Now you can reboot and enjoy a synchronized clocks on both OSes.

PS: This information was found on the "Internet", and was copied here solely for my own convenience. I didn't invented this tip, credit should go to others.