|Scope:||Open source firmware for smart (wrist-)watches|
|Status:||free time project|
About two years ago I got access to the MetaWatch, an approach for a smart-watch started at Fossil which became a separate company in 2012. The idea of the MetaWatch is to create a kind of terminal like device as extension to smart phones, i.e. the intelligence of the watch software is reduced to displaying data and accepting input from the user. Communication from phone to watch is done by Bluetooth™, the display is a monochrome 96x96 pixel Sharp polymer display, similar to LCD but without polarizers. The whole thing is driven by a low power MSP430F5438a microcontroller with the increadible memory capcity of 256kbytes of flash (for program and data) and enormous 16kbytes of RAM :) But it can run @16MHz! So any software running on this thing has to be very memory conservative. The original firmware of the MetaWatch is also open source and available on GitHub. But for me it had some disadvantages... first of all it does not compile with open source tools like GCC, it is tailored for either IAR or TI Code Composer Studio which are both proprietory and pretty expensive tools. Second problem is that the Bluetooth stack used is also proprietory and provided as a binary blob. And for quite some time a third issues existed which were proprietory init data blobs which needed to be loaded into the Bluetooth chip (TI CC2560, later CC2564) which were also not openly licensed.
But all turned to the better!
MSP GCC now has support for larger binaries and so can be used for an open source firmware and the init scripts have been put under an open license by TI - thanks! And this was the point where I started more thoroughly to work Oswald.
There are several challenges that need to be covered:
Oswald consists basically of two parts, the upper layer Oswald application level and the lower level hadware part. Currently the only hardware that is supported is a GTK+ simulation that helps enormously developing new screens or app and a lower level hardware layer that implements the specifics for e.g. MetaWatch. The goal is that Oswald can also run on other devices like e.g. the Pebble, if they would provide information on how to write such an adaptation layer (which they currently don't and most likely never will :(
For Bluetooth I tried to port or adapt different existing open source stacks like Smalltooth, LWBT or BTStack. But all had bigger or small issues, like licensing (being too restrictive), using too much RAM or making certain assumptions about the HCI. So I went the "roll your own" way. Currently it looks pretty good and Oswald-MetaWatch can support HCI-H4 (UART), the CC2560 and CC2564, eHCILL (low power HCI) for the TI chips, very basic HCI link and connection handling (l2ping e.g. working) and a basic L2CAP connection handling and data exchange (sending and receiving data). Enough to start Bluetooth connected apps!
I tried to abstract the application layer as much as possible from the hardware. It is also made around the idea of events, i.e. every action of the application layer is triggered by some event - timers, buttons, communication etc.
To get an idea about the current state I made a screenshots page with some more of the already implemented screens.
For the UI I needed bitmaps for e.g. icons and needed to a) edit them and b) get them into a format that can be compiled into the software. Here I decided to use the XBM format which can be directly saved into a C header file so that it can be included and compiled with the source. Pretty convenient! For editing the bitmaps I am using good old "xpaint", available for most Linux dustributions.
The fonts were a little bit more difficult. The fonts needed to be in bitmap format and must look good even on very low resolution. Compared to a modern screen 96x96 pixels is nothing but we want to display messages like SMS there and still get a reasonable amount of information conveyed. So the fonts need to be small, in terms of number of pixels and also in terms of memory usage. There are quite some ready mode bitmap fonts used in some projects that are also available as C header files. I first used some of them but some glyphs were looking bad, the sizes I wanted were not available etc. So I needed a way to create my own.
After some searching I found "gbdfed" by Mark Leisher (et.al.). This tool is already pretty amazing since it allows importing TrueType fonts and making bitmap/pixel fonts from them! And it already had a HEX export function. I tweaked it a little more so that it can now directly export C style header files, similar to XBM, that can be directly included and compiled. The sources of my modified version of gbdfed can be found in GIT here: http://git.kernelconcepts.de/?p=gbdfed.git;a=summary
The Bluetooth "stack" implementation in the MetaWatch part of Oswald follows several main objectives:
So far the Bluetooth code seems pretty functional though still is very basic. But it was already very good for my learning! Since the whole stuff is licensed under LGPL feel free to use it somewhere else but please give credit and if you enhance the code give back the enhancements.
For the code I wrote I chose the "Library GNU Public License", in short LGPL, as license. This has reasons. First of all I want that users of the code can link their own code to Oswald code without being forced to license their code under an opensource license too. I would of course appreciate it if they did but I do not want to enforce it. But on the other hand I want to enforce that Oswald itself stays open for all times, that consumers of the code have to acknowledge this and that changes to Oswald itself must be made public again.
I herewith explicitely grant permission to link statically against Oswald code - on small systems like microcontrollers you almost can not avoid it.
With Android and the much more liberal Apache 2.0 license we more and more see the issue that people (manufacturers) use the code but do not give anything back to the project or public. This is against the idea of open source and especially free software. And more importantly it can kill these projects. If changes and enhancement are not made public again then the original project will not evolve and thus die over time.
Sourcecode can be found in the project's GIT repository:
Have a look at the Downloads page.
The stuff above was made by me, Nicole Faerber. If you have question, comments or want to talk to me about it, contact me at firstname.lastname@example.org.