peteg's blog - hacking

Bye bye Net Origin, hello Linode.

/hacking | Link

I've hosted my vanity website with Net Origin since they started due to what was a sweetheart deal: a lifetime 50% discount or somesuch. Their recent invoice was far too high (AUD 180 a year for a dinky VPS; I used to pay AUD 6 a month) whereas Linode only wants USD 5 per month and offers several free months up front. No choice really. Hopefully they won't also delete my VPS by accident.

Too much hardware.

/hacking | Link

I've been contemplating how one connects to 3G or 4G internet. Previously I've used an Optus dongle which was sufficiently catholic amongst the various resellers of that network. Well, the days of dongles are pretty much dead: the old 3G-ish Huawei E1762 was apparently locked to the Optus network, though I didn't have a SIM to verify that. I shelled out $32 for a Telstra-locked one that refused to acknowledge a reseller's SIM; moreover unlocking it seemed painful and probably expensive.

The solution, of course, is a super-cheap Android phone. Michael Ginsburg pointed me to a ZTE Zip 4G that I acquired from Officeworks in Carlton (south of St George) for an entirely reasonable $39. Moreover his preferred unlocker did the business in about six-and-a-half hours (for $5) and the almost-free Belong SIM I bought a while back worked first try.

Allowing that this was my first encounter with Android, things didn't go too badly. The only really annoying thing was that the USB tether settings do no stick (i.e., there is no equivalent to iOS's "Trust this computer"), and it seems I need to root the device to fix that. Also, once I finally got hostapd somewhat set up on the Beaglebone Black, it seems to like to aggressively drop TCP connections (even live ones!). This might be the network though.

The whole thing has been a massive timesoak, as (cheap) hardware always is.

New MacBook Pro.

/hacking/mac | Link

It's been about four-and-a-half years since I bought the last one. I'd been hanging on for Apple to release a machine with the latest quad-core Intel processors, but those got released just before these new models, back in June, and so I am stuck with some earlier year's. (I think Apple might have known that the yields were poor.) What forced my hand was that Isabelle started reliably crashing the old machine, perhaps due to the heat, dust and possibly borderline support for the memory I put in it. Or maybe it did have the infamous GPU hardware bug, despite getting a new mainboard in September 2013.

Anyway, what I give up with the new machine is a DVD drive, which I only ever used to reinstall the OS, and an ethernet port, which I will miss if I ever get back to hacking hardware. Also they have gotten rid of the Kensington lock slot. I now have to use Yosemite, which is not hugely different to Mavericks, so shrug. What I gain is USB3, a superfast SSD, a very sharp screen, and less weight to lug around. I doubt the battery life is going to matter, or the extra ThunderBolt port. So faster, yes, but otherwise pretty much a wash. I do like having a machine where the only moving parts are the keys and the fans though.

Buying the thing was an ordeal. It was quite expensive: $2.5k and another $230 in Illinois state sales tax (I mind paying money to the state less than to the Fed), but amortised over four years it's not so bad ($2 a day). I live quite close to the Lincoln Park Apple Store and figured that if I put enough cash on my Visa debit card, things would go OK. But when I got there I figured what the hell, let's try putting some of it on the credit card. This failed, and the card got totally blocked. They like doing that to me — why they can't just reject the transaction and notify me I don't know. I'm never going to rely on it when I'm overseas. Then the debit card got blocked too, as it has a $2k daily limit. The lady at my credit union told me about that, and said I could go pull another $1k in cash from an ATM. Another two calls to them got it unblocked, two trips to the ATM ($600 limit per withdrawal there) got me the difference, and an intervening switch of sales assistant finally allowed me to pay for it. The machine was brought up from the stockroom three times, by the same girl, to my excruciating embarrassment. They insisted I take my 84 cents in change. This is why I shop online.

After that I spent the whole afternoon sitting in the Apple store reinstalling Yosemite (all for a case-sensitive root partition) and Xcode. Everything comes off the internet now, so it's slow. At home the Migration Assistant took five or more hours to scrape my data off the Time Machine backup. After that, reviving the usual arcana (MacPorts, the venerable perl blogging script, some settings) went far more smoothly than previous times.

Update 2015-08-02: The right shift key ceased to pop back up after mild use. A trip to the Genius Bar at Apple Lincoln Park on Monday 2015-08-03 got it replaced, and we'll see if it's fixed.

Haskell Apostasy #1: now where did they hide the higher-ranked polymorphism?

/hacking/ocaml | Link

About fifteen years after it was cool (to type systems people), I figured it was time for me to try ocaml, or more broadly, to make my peace with this call-by-value thing. One motivation was because I work with a Frenchman, and another was that I want more space- and time-efficiency than Haskell allows. No, I'm not listening to you talk asymptotics or microbenchmarks or parallelism. So, where else to start than by trying to port Bird and Paterson's de Bruijn encoding? (Edward Kmett's recent work places this scheme in the vast terrain of representations of higher-order languages and sets the bar for type insanity / wizardry.)

Here's what I ended up with:

You'll see that I ran out of patience / interest in working out a full showE function for the efficient representation. I think you're supposed to normalise it first and use showT. As I observe in the file, Yallop and White have thought about how to massage the syntactic overhead of higher-ranked polymorphism (think Haskell's functors, monads, traversables, this crazy nested datatype stuff, etc.).

I came to think that ocaml's module and object systems (really row polymorphism) give Haskell's baroque combination of features some solid competition. I like being able to define lightweight namespaces that actually do encapsulate things. The uniformity of ocaml's type declarations (just say type) is awesome, and would be even more awesome if they'd wired row polymorphism in there too, rather than adding a whole pile of constructs for an object-oriented style that is foreign to just about everyone. I don't care about the fine details of syntax but would observe that its treatment of user-defined operators frankly sucks. *shrug*

Note that Bird and Paterson's scheme is a non-starter in Standard ML due to the latter not supporting polymorphic recursion.

I also tried to test this representation using an ad hoc QuickCheck-alike, using Pierre Lescanne's ideas about generating λ-terms. As Oleg shows, it takes some doing to generate interesting ones. More on this later perhaps.

Mavericks did not eat my homework.

/hacking/mac | Link

I've been using Snow Leopard for five years now, which is getting on to Windows XP longevity. Having left academia, I just now figured that whatever was keeping me on that tired platform has probably gone to the grave, and moreover Mavericks looks a lot more enticing than Lion ever did. Ergo upgrade.

So far no real problems, apart from new (empty) windows in Chrome interacting in a nasty way with Spaces. I lost my RSS feeds, as I knew I would; there's a widget in Chrome that is somewhat usable but a long way from either Google Reader or the old Conversely the new seems a bit faster and less buggy... though it keeps hitting up IMAP servers from a lifetime back. I had to reinstall MacPorts, as always. clang seems a lot faster than GCC. My venerable perl blog script broke, as always. Fast times.


/hacking | Link

Quite a while ago I cranked out an over-ambitious assignment for JAS: no, not that one, but FLAN and its graphical relative FLANGE. I decided it was time to air the examples I wrote for it.

/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
#include <util/setbaud.h>

  /* Set the baud rate */

  /* 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);
  UCSR0A &= ~(1 << U2X0);

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
img file read error: Could not open /Users/peteg/Sites/static//P7160005.JPG: No such file or directory

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.