30 days of watches

May 15, 2011 6:01 AM

30 days of watches
I'm writing a new watch face every day for a month to try some more creative programming ideas on the inPulse wrist-watch. So far I've completed 21 days and am working on clock number twenty two this morning.

To add to the technical challenge, the watch has only 4 KB of usable program space (after the system libraries consume 28 KB) and about 4 KB of RAM (out of 8 KB total). For extra creative challenge, I'm trying to make every day a very different way of telling time.

Some of the ones so far have been Nixie tubes, time spirals, a rolling odometer, an animated flip clock and a slowly rotating world. The one that started the project was a Utah Teapot rendered with my own 3D library using fixed point math.

Role: Programmer, designer, etc.

posted by autopilot (7 comments total)

If I wanted to learn C*, would buying one of these watches be an interesting/fun way to learn?

* or some variant of C - I don't really understand the difference between C, C++, C#, etc.)
posted by alby at 6:34 AM on May 15, 2011

i really like this idea, and if you posted the code you used - along with any insights into the mistakes / discoveries you make - this might also become a very good teaching tool for all of those out there who are self taught coders :D

Congrats on what you have done so far :D
posted by Faintdreams at 6:47 AM on May 15, 2011

Learning C on an embedded platform is simultaneously the best and worst way to do it. On the positive side, there are very few APIs to learn and no complex object models to get in your way. You get to write code that runs on the bare metal with no OS interruptions. You typically need to learn how all of the pieces fit together because you have to write most of them, and you need to be able to do it in as little memory as possible so you learn how much everything costs in terms of the memory footprint. Since the embedded systems are typically slow (1-50 MHz and no FPU), you also need to revisit optimization tricks from years ago. On the down side, debugging is typically limited to "flash this LED if my code reaches this point" and when things go wrong there is really no way to fire up gdb on the core file.

The systems that are targeted towards beginning embedded developers typically have better support for getting started. The Arduino has a fancy IDE, a single step debugger and tons of online help. But, you can't wear it on your wrist and show off the nifty program you wrote over the weekend.

So if you yearn for the days of demo scenes on the 68k or 6502, go for it!
posted by autopilot at 6:54 AM on May 15, 2011

Faintdreams, all of the source is posted. Once I'm done with the month I plan to revisit the code to try to put together a clean set of libraries for the different techniques (3D rendering, antialiased lines, SPI flash access, etc) for others to use. The pace of writing a new one every day means that some proper software engineering techniques have fallen by the wayside and I'm just copying all of the previous days support files into a new directory.
posted by autopilot at 6:57 AM on May 15, 2011

I regret buying the Chronos before the inPulse was announced.

A programmable watch (with a reasonable battery life :-)) has always been on my wishlist. The newer low power mcu's area awesome.
posted by trialex at 10:17 PM on May 15, 2011

Also, are you on holidays or something? Where do you find the time (pun intended)!
posted by trialex at 10:19 PM on May 15, 2011

Unfortunately I'm not on holiday. Most of the watches only take a few hours to write, so it is just an evening project. Some of the more involved ones have been full day on the weekend.

The Chronos looked neat (and I have one), but the lack of OS X drivers for the proprietary RF module prevented me from doing anything with it. The upcoming Metawatch looks interesting, too, although I hope they've opened up the development platform a bit.
posted by autopilot at 4:25 PM on May 16, 2011