For a while I have been eyeing with the TI eZ430 Chronos watch, a slightly bulky “sports watch” that not only comes with a built-in thermometer, barometer and accelerometer, but also a freely programmable micro controller (from the TI MSP430 family – hence the name). In addition it has a small radio chip included and can communicate wirelessly with the computer, or possibly other devices. All in all, a very geeky toy.
A week ago I managed to buy one quite cheaply via eBay (30€ including shipping). It took me a while to get an overview of the various resources about the device. Here is what I have learned.
Hardware: I have the new edition (the included debug board and wireless access point are white). This means that I cannot update the software of the watch via the wireless connection, and it means that most software written for it does not support the new altimeter sensor (yet).
Development: Debian is a very suitable development platform; the packages mspdebug and gcc-msp430 provide all I need to compile (make config && make) and upload (mspdebug rf2500 "prog ../foo.txt") new software.
Code: Besides the original software that comes with the device (which supports the new hardware), there are two main lines of community-driven developments: OpenChronos and openchronos-ng. The former is (as the name suggests) older and maintained mostly by forks in variousplaces. The latter is newer, its UI deviates further from the original software and seems to be slightly more active.
Communication: Both of these have their own mailinglists (openchronos, where I did not get a reply yet, and ti-chronos-development, where my messages are still waiting for moderation). I found only one IRC channel, #openchronos on freenode, with similarly little activity.
After I found that out, I tried to hack a bit on the various software. The first issue I had (and still have) is that I cannot use the buttons of the device while it is attached to the debug board. They do work if forget to take out the battery, but supposedly that is bad for the battery. So my compile-upload-test-cycle becomes a compile-upload-detach-insert-battery-test-remove-battery-attach-cycle. I could not find out how to emulate button presses using mspdebug. Any suggestions are welcome.
The other problem was the new altimeter hardware: Neither OpenChronos nor openchronos-ng support that yet. I originally planned to port the driver from the official software to a random OpenChronos fork when I read that Richard Rondu did that to openchronos-ng yet. I found the code in a month-old merge-request.
I tried it, it worked, and I started to clean up the code a bit and add a variometer mode to it, e.g. displaying the current rate of climb – my ultimate goal is to use this as a surprisingly cheap variometer for paragliding. After a day of hacking and quickly lifting the watch from the room floor to the room ceiling and back I believe that it works okish, although quite a few parameter can benefit from more tweaking: sample rate (currently 20Hz), length of history (currently 2s) and the linear regression method (currently simply the difference between the average of the samples of the current second with the samples of the last second). As always, patches welcome, the code is in my fork on sf.net.
Next to do would be to enable some buzzing noise depending on the rate of change; during flight I don’t want to decipher a low-contract LCD screen. But it is questionable whether the buzzer is loud enough – we’ll see. I was also happy to hear that there are other zE430-hackers in Karlsruhe, one of them for example tries to make the alarm clock sleep-cycle-aware.
Please note that the msp430 toolchain is badly lacking updates, as the whole projects is being rewritten and upstreamed by TI and RedHat (but still to unstable IMHO).
As the mantainer, I've never tried the current toolchain on the Chronos but I'm glad it works without too many issues...
Gcc, binutils and gdb have already been upstreamed. mspdebug is a separate project. The fate of msp430mcu (chips layout) and libc-msp430 (small optimized libc) is uncertain. The port has been tested with newlib, which is mostly a no-no for smaller chips, and I'm unsure how they'll handle layout definitions (hardcoded?).
That's why the old (PBigot mspgcc series) toolchain is still in unstable.