Hackable wrist watch makes Dick Tracy dreams come true

The inPulse watch is a great platform to hack on. It has an ARM7, 32 KB of flash and 8 KB of RAM, Bluetooth, a buzzer, an OLED screen and a button. Not much by today’s standards, but plenty to play around with. The programming environment is very much like a microcontroller; no multitasking, no dynamic memory, and very constrained memory/cpu. That is, of course, what makes it so much fun. From very basic timekeeping contraction devices to today’s smartwatches, clocks have certainly evolved so much. If you wanna know more about the history or watch news, visit James Hampton-Smith’s blog called SpotTheWatch.

My multi-app framework attempts to make it possible to write multiple apps that can share the limited RAM by a technique similar to FORTRAN COMMON blocks. The main app.c file has the mainloop that calls the loop() method of the current app. This main loop also does a static allocation that fills the entire BSS; each app that is linked in rewrites it with its own local state while it is running. When the user holds the button for two seconds, the main app selects the next linked in app and call its init() method to allow it to perform its setup.

Since some of the apps need trig functions and there is no floating point support, I’ve written a fixed-point sin() and cos() function that are within +/- 0.0075 of the real sin function. Close enough for most government work… The function and lookup table consume 157 bytes of flash and no precious RAM. I haven’t benchmarked the performance, although most of the apps already have time-delays to only redraw the screen at 30 fps.

There are still several things that need to be done to make the watch usable as a watch. The most important is power management. Even in “powersave mode”, the battery runs dry in about three hours. Clearly it is not saving much by turning off the display.

The other two major requirements are a local build environment and a more accurate simulator. The cloud-compile environment does make it easy to get up and running, but there are many things that a local build would make easier. For instance, the Bluetooth stack is always linked in even if it is not used, leaving less RAM and flash to the user. Or figuring out why calling snprintf() breaks everything. Hopefully they’ll release the local SDK soon.

Until then, the developers hang out on the inPulse forum and have been super helpful with debugging some of the getting-started difficulties.