peteg's blog - hacking

/hacking/mac | Link

Since my MacBook Pro got a new mainboard, and being told that the new Intel CPUs are not much faster (though more power efficient), I decided to upgrade it with 16Gb of 1600MHz DDR3 1.35v memory, for $181.56 from MSY. This old 2011 Sandy Bridge can handle those specs but Apple does not admit it; so far so good though, as my readings of the internet suggested it would be.

Addendum: Mac OS X leaks like a sieve. The purge command reclaims the "inactive" memory that the OS refuses to via automatic means. Looks like I was wrong to blame FireFox for being the fat pig that it is; there's a fatter one hiding behind it. After a purge the system typically has about 10Gb free.

/hacking/mac | Link

My MacBook Pro was playing up; maybe an external disk got frisky, maybe some projector somewhere, I don't know. It's working again after four (4!) visits to the Apple Store. First up: Bondi was totally useless. They reinstalled Snow Leopard and sent me on my way. The CBD store decided the DVD drive was busted, but when it came back it was sicker than before, with scanlines on the LCD and a complete refusal to start. They took a week to replace the guts and it has been OK since. All of this was free under AppleCare; that has about six months to run. I'm not very impressed with the working knowledge of the geniuses. I did enjoy being without it for a week though.

For future reference: my retail copy of Snow Leopard is too stale to boot this machine. The grey disks that came with the machine crashed when restoring the Time Machine backup (!). Fortunately an up-to-date Snow Leopard got things back.

Goodbye VMware Fusion, hello VirtualBox

/hacking/mac | Link

I got sick of VMware Fusion 3.1.3 failing to bring the bridged ethernet interface back up after sleeping, and figured that it wasn't worth $US40 to find out what the newer v4 does on the now near-obsolete Snow Leopard. Time to try out the free/libre VirtualBox that so many people have mentioned.

Well, installing Debian is easier than ever. Configuring the network was quite tricky though, as I have a relatively complex setup. The first adaptor is a NAT interface for talking to the internet. The second is the ethernet bridge that serves TFTP and NFS to the ts7250 ARM board when I'm hacking it, and the third a host-only adaptor so I can SSH into the virtual machine. That all seems to work OK. The bridged ethernet is even more reliable than before: it always comes back after sleep, and the TFTP boot does not time out like it used to under VMware.

... and then there is the USB connectivity: I plug the FTDI-based AVR programmer into the virtual machine so I can make install there. This doesn't work too well with VirtualBox due to this bug, though cranking the number of CPUs down to one does get it to go: I can program the AVR using it. The USB performance seems a bit dire though, and this is one area where they lag VMware by a long way.

I don't know if the graphics emulation is much chop as I use X11 over SSH to (only) run Emacs.

Long term stable Linux kernels and compat-wireless

/hacking/nixie_clock | Link

Skipping right over justifications, I've been trying to get the ts7250-based nixie clock project in the can, at least hardware-wise. To recap, I was hoping to use Linux RT to drive the multiplexed nixies from user space, and that worked. The problem was that if you want to decode mp3s on the board at the same time then the CPU load is insane; one or the other is fine, with mp3 decoding taking maybe 70% CPU tops, and the display down in the noise. David G at NICTA suggested I write a kernel driver as it was probably the cache flushage (or other context switch overhead) that was killing it. Instead I took the less hairy chested and hopefully more reusable path of driving the display with an ATmega328P, interfaced to the ts7250 by TWI/I²C. That was the easiest hack ever: everything worked first-go (to the limit of the code on the AVR).

As I'm stuck with a 3G dongle for internet presently, I was hoping to use the ts7250 as an access point. To that end I bought a TP-Link TL-WN722N from MSY and set about getting it to work. The box claims it goes to 150Mbs, but the bloke at MSY told me I'm only going to get 54Mbs out of it from the MacBook Pro. I have zero idea about post-802.11g wifi; all I know is I can get several megabytes a second at UNSW on the UWN.

I've had luck with compat-wireless before, but really struggled with the 2.6.34 kernel, the most recent one that Matthieu's patches apply to cleanly. (Something really funky happened in 2.6.35 and onwards to do with SPARSEMEM — suffice it to say that if I can get one of these more recent kernels to boot then I only get 32Mb of memory, not 64Mb. Everything else seems fine though.) After much fruitless hackery I asked on IRC, and got the first useful advice I've ever received from that medium.

In brief, some long term stable Linux kernels are more popular than others, and as many distros picked up 2.6.32 it is the one to go for. (2.6.34 seems to be the least popular release around that time — apparently 2.6.35 got used by some embedded systems.) Sure enough, an hour of compiling later and I had the latest wifi drivers built and working on the ts7250. The moral is not to believe claims of compatibility with unpopular kernels.

Getting hostapd going is another story. I have a basic configuration that lets the MacBook Pro connect, but nothing exciting happens as I haven't configured the TCP/IP machinery on the ts7250 yet. The fun bit is figuring out what it wants to know about WPA2.

I also bought an ATEN UC232A USB-RS232 adaptor. MSY was promising them for $18 but had no stock, so I had to pay $25 in Little Tokyo. It's top notch, it even works through a hub.

When too much hardware is barely enough

/hacking/mac | Link

Apple continue to ship their MacBook Pros with insufficient memory. I got jack of this thing hitting swap even though it had another gigabyte on my previous MacBook; subjectively it felt worse for the same workloads, maybe because Chrome is a memory pig. (I'm back on FireFox now.) So last Friday I went to MSY to buy a couple of 4Gb sticks. Their price for Kingstons: $42 each. Apple wants $480 for the pair. That is an insane price differential.

MSY (being MSY) only had one in stock, however, and I wasn't in the mood to wait howeverlong. (It is extremely irritating that they don't indicate their stock levels online, or allow online orders. It is also irritating to have to wait for some bloke to pointlessly, endlessly complain about their refusal to give him a replacement/refund when his son couldn't install a CPU properly.) I hoofed it back to the place where mrak got his last time, in the little slice of Tokyo on George St near the tram line. They wanted $60 a stick which was fine by me, and the bloke helped me install it. While prying the underside off it I tipped three of the tiny screws onto the floor, but somehow by the end of our conversation he had recovered all three. I have no idea how he did that.

Thus far I cannot get it to use the final 1.5Gb or so, even with Windows XP and Debian running in VMware concurrently. Thus I can hope it will last a year or so, though I fully expect Lion to eat it when the time comes.

Today I bought what may have been the last two Logitech USB hubs available in a shop in New South Wales, from Myer in Orange, for $36 each. mrak told me ages ago that these things were reliable and I've been happy with the one I got at the time, which is presently hooked up to the BeagleBoard at ANU. The price tag was $60 each but the bloke gave me a hefty discount on the merest suggestion they were overpriced. I am shocked that Logitech has not replaced this classic hub, and that there is nothing else readily available with its reputation for just working.

Further steps with the talking clock.

/hacking/avr | Link

I bought a couple of the MMA7660 accelerometers I mentioned some time ago from Farnell (before their gender op). The chips are incredibly tiny, 3mm to a side, and 0.5mm pitch legless contacts have to be seen to be believed. Soldering wires onto those was beyond me, and I was fortunate to have Aaron at NICTA kindly solder one to a board for me. Etienne more-or-less inhaled the other one. Some basic prodding seemed to indicate that the device was still functional after this surgery.

Much later I tried to solder some wires to the board, using NICTA's excellent facilities (Dremel, high-end electric iron and stereoscopic magnifier). Suffice it to say that the device showed no signs of life after that. Fortunately the market has responded to my demand in the intervening period: the Mad Scientist Hut sold me a couple of these devices pre-attached to macro breakout boards. Their prices are OK but their shipping is very expensive, at about $10 for the pair. I guess it would make sense if I'd bought fifty of them, but I didn't.

Suffice it to say that the bidirectional circuit mentioned in SparkFun's tutorial did the trick of interfacing the circa 3v TWI/I²C levels of the accelerometer to the circa 5v used by the AVR and the rest of the circuit. I fabbed it on some stripboard and get plausible readings from the sensor.

The penultimate bit of hardware hacking was to switch off the speech chip when quiescent, with the goal of getting the current draw under a milliamp in the most-of-the-time case. Doing this with is a FET is entirely straightforward, but the current draw remains a ridiculous 6.5mA. I think (hope) that is fixable in software. Adding the batteries — a button cell as a backup for the RTC, and four NiMH AAs — is largely a mechanical problem. Later I might also try to bring the volume under software control.

I have begun trying to flesh out the control software for this thing. I'm trying to avoid writing spaghetti C and have been a little successful, but am hoping for a more abstract way of writing the core state machine as it will involve commands coming as data on the U(S)ART and timeouts, as well as the presumably complicated interactions the accelerometer will allow. Maybe I can get by with less overkill than Esterel.

The code is at github. Possibly of interest to others is the growing MMA7660 driver for AVR.

When too much hardware is not quite enough

/hacking/mac | Link

Finally Apple released a new MacBook Pro that was worth buying; I'd been waiting about two years for this. Somewhat surprisingly, given Intel's problems with the SATA interfaces on their new Sandy Bridge chips, Apple managed to roll out the new laptops pretty much under the radar and at a time that suited me: NICTA wanted me to pay off my salary sacrifice by the end of March (the end of the fringe-benefits tax (FBT) year, I believe), so I hurried off to the Apple Store at Bondi, where the service was terrible but everything was shiny.

The calculus of which one to buy was pretty easy, as it turned out. The 13 inch ones, which I would be inclined to buy, only have two cores and crappy Intel integrated graphics, and the bottom-end 15 inch one has an ATI/AMD card that is apparently worse than the previous-generation's NVIDIA one. That left the top-end 15 inch, of which I got the 2.2GHz one as I'm not going to miss 100MHz of CPU performance. I was going to get a high-resolution screen and faster hard disk, but they don't do that in the shop, and teeing up a delivery was a bit tricky, being on holidays and all.

It ended up being a lot of cash with the AppleCare and the 8Gb iPod Touch, free with a mail-in rebate. Yep, I got suckered the same way last time, but this time it's free! What could go wrong with that...

Performance-wise this machine smokes the old Core2 Duo MacBook; building my stock Isabelle theory takes about a third of the time, albeit by toasting my thighs. Given that the unibody is (even) more durable than the plastic case, I expect to easily get four years out of this thing. Moreover I can play finally all those games of yesteryear, such as Portal. I think there are a few issues for Apple to iron out yet, though; it's a lot crashier than the old MacBook, perhaps due to immature graphics drivers.

Virgin Mobile Broadband: it just works on everything but Mac OS X.

/hacking | Link

Coles was (and maybe still is) flogging these crappy Virgin Mobile-branded Huawei E160E modems for $24.50 (half-price), with 4Gb of data included. I figured that the modem is obsolete and hence probably well-supported, and while it is presumably locked to the Optus network, I could probably swap to a better Optus reseller or unlock it without too much hassle.

It turned out to be easy enough to get going under Windows XP, using the drivers on the modem. Similarly under Debian the default option driver does the trick, with some hackery of the chat script/ppp options. Mac OS X put up a fight though: the included drivers work fine (they're pretty generic anyway), but the included chat script was garbage. Maybe that Java monstrosity took care of all of that, I don't know. Once I twigged, patching in the relevant things from Debian did the trick.

Unscientifically, in Orange under Debian I initially got:

  apt-get install ...
  ...
  Fetched 42.9 MB in 13min 56s (51.3 kB/s)

Not terrible, but a long way from the 3.6Mbps (HSDPA, not HSUPA) this modem is capable of. Apparently the Optus network is saturated with tennis traffic, and Virgin supposedly massively oversubscribe anyway. Later it completely fell apart; under Mac OS X I got 11kbps sorts of speeds, i.e. slower than dialup, and similarly under Debian. Maybe I'm on the GPRS/GSM/EDGE/slowarse network. It doesn't bode well for mobility.

Update 2010-02-01: Back in Sydney I get about 2Mbps according to Oz Broadband Speed Test, and it does feel snappy.

AVRUSB serial connections going for $AU3 a pop.

/hacking/avr | Link

As I said a while ago:

[T]his bloke has a super-cheap approach to USB interfacing, viz using those USB-RS232 cables that don't do level conversion. I'm off to buy a cache of them from eBay.

Well, I bought five of those cables from these guys in China for a grand total of about $AU11. They turned up less than a week later, and are about as cheap and nasty as their price suggests.

The first thing to do was to ensure the Mac recognised them. This was painless as they look like a Prolific PL2303, about as stock as they come. The second step was to extract the circuit board from the (very cheap and very nasty) serial plug. This took a while as the plastic is pretty tough; next time I'll heat it up a bit first, or perhaps try out the Portasol's hot knife. Also I smashed the ceramic resonator in the process, which was a mixed blessing as apparently they are not very stable wrt temperature, so replacing it with a 12MHz crystal is probably worthwhile anyway. Good thing I got something like a lifetime supply from Sure a while ago.

The remaining problem is that RS-232 inverts the signals: low is a logic 1. These cheap cables treat low as something like 0v, so there's nothing fancy required to get the signal the right way up; two instances of the circuit at the bottom of this page did the trick, one for each direction. I tried a 10kΩ / 100kΩ pair as he suggests but the power sucking 1kΩ / 10kΩ combination seemed necessary.

After wiring that up, the magic incantation screen /dev/tty.PL2303-0000xxx 9600 for some xxxx worked fine as a zero-functionality terminal. It seems that 9600 baud is the limit with the default 8MHz-divided-by-8 clock of the ATmega328P, which surprised me as I wasn't expecting anything more than about 1200 baud to work due to the probably huge error in the clock.

So all up there's the cable ($AU2.20), two transistors (Jaycar is expensive here, $AU0.26 per BC549, where Farnell only wants $AU0.10 or so), four resistors (marginal) and some time. Much better than $US20 for a "USB TTL cable".

The other thing to note is that while the AVR's UART is incredibly easy to get going, the code depends a lot on which particular chip you've got: I had to pepper the I/O register names in mine with 0s for no reason I could fathom, for the ATmega328P only has one U(S)ART. (Yes, yes, there are a few other serial interfaces but those are hardly universal; they are not even asynchronous AFAIK.) Here's the guts of it:

#include <stdint.h>

#include <avr/io.h>

#define BAUD 9600

static inline void
UART_read(uint8_t *c)
{
  while(! (UCSR0A & _BV(RXC0)))
      ;
  *c = UDR0;
}

static inline void
UART_write(uint8_t c)
{
  while(! (UCSR0A & _BV(UDRE0)))
      ;
  UDR0 = c;
}

static inline void
UART_init(void)
{
#include <util/setbaud.h>

  /* Set the baud rate */
  UBRR0H = UBRRH_VALUE;
  UBRR0L = UBRRL_VALUE;

  /* Turn on the transmission and reception circuitry: 8 N 1. */
  UCSR0B = _BV(RXEN0) | _BV(TXEN0);
  UCSR0C = _BV(UCSZ00) | _BV(UCSZ01);

#if USE_2X
  UCSR0A |= (1 << U2X0);
#else
  UCSR0A &= ~(1 << U2X0);
#endif
}

Next up is fabbing it on some veroboard.

A talking clock.

/hacking/avr | Link

Hacking AVRs is too easy these days: without any real snags I got an LED flashing on one of the pins of an ATmega328P. From there it was a short step to hooking up an SPO256-AL2 General Instrument speech synthesis chip from circa 1980 and getting it to talk. Making the AVR listen to the SPO256-AL2 required me to read the AVR manual: the AVR's GPIO pins have distinct registers for reading inputs (PINx) and setting outputs (PORTx), unlike the ARM in the ts7250.

I bought the SPO256-AL2 at a good price from a bloke in Melbourne. Email me if you want his details.

Slightly harder was getting the AVR to talk to the DS1307 real-time clock hanging off the TWI/I²C bus. As it didn't just work, I put off debugging this until I could borrow an oscilloscope from Andrew T. He lent me a venerable BWD 539D that was probably abused to within an inch of its life in the electrical engineering laboratories back when I was an undergrad. Suffice it to say that even with my inexpert knowledge it quickly showed the TWI/I²C bus was alive, and with some minor software fixups things came good.

On that front I started with something not too far from Peter Fleury's venerable TWI/I²C code, and ended up with something a bit cleaner and more abstract. There really isn't much going on with that protocol.

Today I wired up a DS18B20 one-wire temperature sensor in parasitic-power mode. It worked immediately using this driver after some minimal configuration and plumbing. Too easy.

My next step is to add an accelerometer, specifically this cheap one from Farnell. I think it is pretty crap as far as accelerometers go, being intended more for the user-interface sort of application I need it for: tap, double-tap, I'm-this-way-up, don't-shake-me-so-hard. Soldering it will be fun, and I need to figure out how to do the level conversion between the 5v required by the SPO256-AL2 and the DS1307 and the 2.8v this accelerometer wants on the TWI/I²C bus. SparkFun's tutorial makes it look not impossible.

After that I hope to put all this stuff on a PCB and polish the software. The power consumption is a bit crazy, with the SPO256-AL2 chewing about 75mA at 5v, as one would expect from vintage TTL technology. It could probably be simulated by a low-end AVR for a milliamp or less now.

Here's a sample of it saying the time and the temperature. The code is at github.

On another note, this bloke has a super-cheap approach to USB interfacing, viz using those USB-RS232 cables that don't do level conversion. I'm off to buy a cache of them from eBay. Possibly cheaper is the mostly software approach.

Some kind of progress.

/hacking/nixie_clock | Link

The controller for the nixie clock is ridiculously complex, given how many buttons the remote control has and the combinatory explosion of modes it can be in. Ergo the attraction of Esterel, the venerable imperative synchronous language that is supposed to nail exactly these problems.

The only publicly-available tools for Esterel are from the crusty old v5.92 distribution of circa 2000, which presumably occurred before Gérard Berry et al tried to commercialise it. [*] Fortunately for me, Tim has tried them out recently and demonstrated that they're not too crusty for my kind of purpose.

Up to now I've spent more time than I should doing the boilerplate, and am only just getting started on the controller proper. It is difficult to work out the architecture ahead of time, given how much of neophyte I am with the language. The system interfaces are pretty good, and it seems possible that one day I could run some of this code on an AVR.

I meant to say that Rob gave me a remote that works fine with the ts7250. I think he got it to control MythTV. It's quite nice, and the HID driver in Linux has been very cooperative.

[*] Well, there is also the Columbia Esterel Compiler, but it hasn't seen any development for many years now.

AVR programmer and demo board from Sure Electronics.

/hacking/avr | Link

For many reasons, mostly not so good, I want to get the gear needed to hack some kind of microcontroller. After working on Andrew T's microphone board, and assembling the Bulbdial kit, I'm pretty sure AVRs are the devices to use, though I expect others will swear by PICs. In both cases there are way too many to choose from.

I plumped for an implausibly cheap programmer and USB / LCD / atmega16 demo board from Sure Electronics, hoping they would be happy with each other. Sure has an eBay shopfront, but it is cheaper to order from them direct. They screwed up my order a bit, giving me an LED controller or something in place of a power supply. I decided to wear that, as the postage was cheap and delivery rapid — Hong Kong Post airmail in about a week [*].

Things look promising. The board has a lot of stuff on it — a USB port, a temperature sensor, the LCD panel, and most importantly, all the ports broken out. Unfortunately it uses a Silicon Laboratories CP2012 chip to talk USB, and their driver for Mac OS X is pretty terrible, inducing kernel panics at critical moments, like device disconnection. Apparently there is a Linux driver now. The Windows driver is fine.

The programmer and board aren't totally happy with each other though; my first attempts at scraping programming info from the board failed, with the sort of errors that made me think the programmer was fine but the board recalcitrant. Fortunately one of the wise heads at AVRfreaks told me to remove the LCD board, and sure enough magic happened.

The plan is to prototype things on this board and then construct final versions on veroboard; the hope is that the other AVR chips are close enough to this stock atmega16 to reduce porting to a formality.

[*] Upon closer inspection I found that they got my order spot-on. The power supply is half of some kind of LED driver board, the other half being some kind of PIC, and hence the board is a lot larger than I expected. It has a different part number to what I ordered.

A Bulbdial clock

/hacking | Link

3:24:50pm

I bought this kit a while ago, when the Australian dollar was near its peak. The postage to Australia is insanely expensive at $US40 or so, whereas they'll ship it for free to the locals. The kit itself is a bit pricey, partly excused by the high number of LEDs (about 70) in it. I got the Chronodot, so it would keep time even without power, and a black/transparent plastic case.

Putting it together is too simple: the instructions are exceedingly well written and the design quite well thought through. It took me about five or six hours in total to solder the components to the board and assemble the case. The few fiascos were minor.

Ultimately it is even more beautiful than I expected, and I'm very happy with it. That doesn't stop me carping though. :-)

  • Most irritating is that the power supply socket and programmer header are well inside the case (you can see it on the right in the picture). This means that you need to pull the front cover off to access them.
  • The viewing angle is quite narrow, as the clock dial is recessed a long way into the case.
  • The clock is essentially digital, i.e. 3:45pm is rendered with the hour hand pointing at '3', and the minutes hand at '45', whereas an analogue clock would point the hour hand closer to '4'. This is surprisingly confusing.
  • The flat watch battery that powers the Chronodot is soldered on, so replacing it will require finding something very similar. These days I would hope for a super cap.

I highly recommend this kit, with some misgivings about the cost; the Evil Mad Scientists deserve to become rich if they can keep cranking out open-sourced novelties like this one.

Adding a temperature sensor to the clock.

/hacking/nixie_clock | Link

My Hồ Chí Minh clock has a temperature reading on it, alongside the lunar calendar, so I figured the nixie clock should have one too.

In the past one-wire temperature sensors have been cheap and plentiful, and were traditionally hooked up to classic PC serial or parallel ports. Nowadays the sensors seem to start at $US5, though I was fortunate to get some DS18B20s from this bloke on eBay for $AU3 each plus postage. The ts7250's GPIO pins stand in for the less flexible interfaces of yore.

These DS18B20 devices are pretty fancy, being able to source power parasitically from the data bus and yielding 12 bits of temperature data. They're only accurate to 0.5° on average, though, or perhaps a bit better at room temperatures, so I don't understand why one would need more than the 9 bits of the other models.

Anyway, wiring it up took about 5 minutes, and finding a suitable cable another half-hour or so. Fortunately the first four GPIO pins of the DIO header on the ts7250 are supposed to have the requisite pull-up resistors, so the sensor can indeed be powered parasitically.

Getting Linux to talk to it was a bit challenging, as the one-wire drivers don't seem to be set up for actual use. Apparently you have to use the non-mainline w1-gpio-custom module to indicate the GPIO pin to the one-wire driver. I don't know how to do it any other way; perhaps it is supposed to be hardwired somewhere. Moreover to get timing right for the parasitic powering, one needs a few more patches, which this bloke has hacked together.

It works:

# cat /sys/bus/w1/devices/28-0000027d5e12/w1_slave
09 01 4b 46 7f ff 07 10 bf : crc=bf YES
09 01 4b 46 7f ff 07 10 bf t=16562

but often the w1-therm driver complains:

w1_slave_driver 28-0000027d5e12: 18S20 doesn't respond to CONVERT_TEMP.

and the CRC check fails with occasionally crap data. I'm suspicious about the device ID as the code apparently does know about the DS18B20. Unloading the w1 drivers doesn't work either. Still, this is all much better than I had any right to expect, I guess.

We have real time.

/hacking/nixie_clock | Link

Finally I have managed to get a real-time Linux kernel running on the ts7250, resulting in a flicker-free display. Score one to patience.

Briefly, the Linux RT blokes skipped 2.6.32.x as the kernel's concurrency foundations got a reworking. They released an RT patch against 2.6.33.2, and as ynezz has forward-ported the ts72xx patches it was a cinch to move to the bleeding edge. YAFFS (a flash filesystem) broke as it uses some old-school mutexery. Grossly updating it all to the struct mutex way of doing things is straightforward and seems to work.

Hacking the clock driver code is trickier now though, as the process runs at the maximum real-time priority. If it loops without making syscalls, the system dies.

Wrapping up Worker/Wrapper.

/hacking/isabelle | Link

At last I have completed the submission process for my worker/wrapper corrigendum-ish thing: the JFP emailed me the printing proofs and I have sent them back, all four and a half pages of it. I am told it will be online sometime soon, and in print at some later time.

MPD on the nixie clock.

/hacking/nixie_clock | Link

Slow and steady progress compiling software this week. It is tedious as hell, and I am mystified as to why mature projects still have such baroque configuration management systems. For example, GLib (a part of GTK) does not support cross-compilation out of the box. A few hacks later and it does compile relatively painlessly, so why haven't the hacks been folded back into the project itself? I think the lasting effect of Debian's packaging of the known universe is that these nasty problems get patched but not pushed (or accepted or whatever) upstream.

Anyway, I was shocked, surprised and relieved that my long-in-the-making cross-compiled MPD ran first-go on the ts7250. It took me an age to configure — ALSA calls the mixer "Speaker" instead of the conventional "Master", and ALSA is so overengineered that even something this simple requires forensic deobfuscation. Everyone's had problems with ALSA, so Google is full of unanswered questions from noobs with poor grammar, or pages from 2005 describing now-obsolete obscurities.

Well, yeah. Using the pleasant MPD client Theremin, I can now blast tunes from the Nixie clock and control it from the laptop. It sounds fine, and uses less than 60% of the CPU with the clock driver doing its thing. I feel like I have finally joined the class of 1998.

The last of the desiderata is a remote control, so I can park the clock on the mantelpiece and do less sophisticated things without the MacBook. The receiver half of this cheap-arse infra red thing I bought does not get along with the ts7250 too well, though it might be OK on stock hardware. Having pretty much given up on it, I will flog its carcase in all the fora known to Cirrus EP93xx sufferers as a public service. I would so dearly like to be cool and trendy and BlueToothy, but I have no cool and trendy mobile phone to pair a receiver with.

Scraping the nixie clock software together.

/hacking/nixie_clock | Link

I spent the evening polishing a root filesystem for the ts7250. The flash is quite fat (128Mb) so I gave up on some of the buggy busybox applets (udhcpc in particular) in favour of their real counterparts from the Debian distro. This approach put dropbear back onto its branch, and as the board can reliably connect to the WiFi router I can now SSH into it almost always after boot. It displays the time now, and synchronises with ntp, and the built-in real-time clock works too, albeit with some hefty drift.

Unfortunately the system still does not schedule my program very satisfactorily: any perturbation in CPU load results in flicker, and it struggles to play an mp3 without skipping. This is with a low-latency Linux kernel (2.6.32.3). I get the impression that later kernels in that series are easy to get going on the ts7250, so I might try one, but apparently there will not be a full RT patch for 2.6.32. Bleeding edge it may have to be.

Part of the reason is that my program naively uses the kernel scheduler for all delays, not just the larger ones. Thus when there is contention for the CPU the system overhead spikes, taking roughly as much time as user code. The sirq (presumably clock interrupt) load is circa 10%. I can feel some busy waiting coming on.

Putting it together.

/hacking/nixie_clock | Link

Replacing the anode driver transistor was entirely routine. Its friend survived. As I was having one of those rare days when the crappiness of earlier decisions on this and other topics was not only manifest but within reach of correction, I decided to assemble the hardware. Here's some photos, taken with the Olympus μTough 6010 on Daz's shonky tripod.

It's running on one of Andrew T's old power supplies, as my old-school LM7805 arrangement couldn't handle the heat. These devices have good failure modes for the most part, but overheating manifests as a loop: the ts7250 draws less current when the CPU is idle, so when the regulator comes back from a shutdown due to heat the processor gets to run for a few seconds before the regulator overheats once more. Nasty.

I discovered the ts7250 puts out enough current on the USB port to power the WiFi and audio adaptors.

It seems that Google's Android platform is attracting a lot of people to ARM platforms.

Software-wise things are still on the slow. Debian's armel port features a working dropbear SSH server, so I reckon there's something fishy with my cross-compiler setup, maybe the C libraries. Conversely nothing ALSA-ish wanted to run. Generally things are looking pretty likely.

Debian on the ts7250 and another kind of disaster

/hacking/nixie_clock | Link

The options for getting software onto the ts7250 are unappetising; either hand-compiling everything or running the risk of someone else miscompiling something. I'm sick of the former so I thought I'd try the latter, in the form of Debian's armel port. Martin Guy's recipe makes this straightfoward. Andrew T gave me a little script that copies binaries and just the libraries they depend on, but what I really want is an easy way to recompile programs and their dependencies. I've used apt-get source blah in the past and been happy.

Bogosity: dpkg does not like running on NFS exported through nfs-user-server. It seems that lockd has been on their TODO list for approximately the last twelve years. Sanity and serenity is provided by nfs-kernel-server.

I sorted out the remaining issues on the nixie board, viz making the anode resistors uniformly 11kΩ. The display is bright but some PWM will cure that. So it was time to fit the whole show together, and just as I gave up on one of Andrew T's power supplies I managed to release some magic smoke from the nixie board by forgetting how parlous the power arrangement was when reaching over the board. I'd switched everything else off but not my power supply, which the cockroaches will be getting when the time comes. The ts7250 survived unscathed, and a ginger replugging of it all revealed that I'd only managed to toast at most two of the anode switching transistors, and their failure mode is to go short-circuit. Phew. Relief. The Russian K155ИД1 is still going like a champ, and John Taylor's power supply didn't notice a thing.

More RoHS-non-compliant repair tomorrow.