Coffee Space

First Device

With my first PineTime I was very enthusiastic about programming it. My original intention was even to build my own OS for it, but actually I realised I don’t really have enough experience with working on such controllers to do so.

I originally played with the idea of running a micro virtual machine on the device to allow for multiple apps to run relatively sandboxed on the device. I even looked to utilise a Java VM designed to run on microcontrollers (designed for a Lego robot I believe). Unfortunately it was never meant to be.

I got my first PineTime a while back and was working on a method to flash it using an Orange Pi, but in my foolish attempt to solder such a small pitch board ended up back-firing and I broke the watch. I made a few attempts, but there is no recovery of this device - something is fundamentally broken now.

Second Device

I still needed a decent smart watch to monitor my health, and after having purchased an off-the-shelf solution from China with a fake sensor, I decided enough is enough and I really want to pursue this project again. I ordered another device, but this time it came with the firmware written by JF002, which came with the awesome ability to support OTA (over the air) updates via BLE.

I got the device with version 0.7.0 (I believe) and was easily able to flash it to 0.9.0 using the latest relase from GitHub, using the OTA DFU process. I was very happy about how well this process worked and decided to (controversially) super glue the device together.

As long as I don’t flash crazy bad firmware, in theory this should continue to work… We shall see though!

Development

The next step was to build a development environment that I was happy with that can build various images. After a couple of hours of reading and hacking, I finally built a development environment based on Vagrant. There is a docker version, but honestly I would rather have a completely enclosed virtual machine rather than container given we’re running random binaries.

I’m currently working towards getting the heart rate sensor up and running, a basic feature I want in order to be able to use this as a daily driver. Without it, it’s just an overly complicated time interface (and honestly, not a great one).

Thoughts

After having spent a few hours in the code base, I have a few thoughts (which may be subject to change at a later date):

• Formatting – The code formatting is all over the place, there are some rules, but not nearly enough for my taste. I guess in some ways this gives me some freedom to implement the code in my style… But it’s not pleasant to read.
• Comments – There is not nearly enough comments explaining what is going on or why. The whole thing doesn’t quite read as a coherent story.
• Drivers / Components / Tasks – It’s not really clear how these really differ. Each of them for example has an update function and can return some data. It feels like a driver should really inherit some interface that allows it to be treated like a task, where it can be registered for some type of callback (periodically, interrupt, timeout, etc).
• Applications – These are currently baked into the firmware at compile time, it’s a shame these can’t be loaded on the fly. In the future it would be nice to be able to customize your setup with apps that interest you specifically. Also, allowing a developer to just work on an app (or module) without the need to look at the OS I think would massively encourage developers. As it stands, there is no escaping having to handle the entire OS.

Regarding the hardware, I have a few thoughts:

• Processing – I hate to say it, but it really does need some more processing power, perhaps more than one core. As it stands, it sometimes struggles to handle user input (either on the display or hardware button) simply because it is busy doing something else. It could really do with a small core just handling I/O to maintain responsiveness.
• SPI – I believe the display shares the same SPI bus as the storage, meaning to store anything essentially you give up on being able to write to the display, which is in itself slow.
• Communications – I’m not sure why, but I really wanted this device to run on an ESP32, with WiFi and Bluetooth, several cores, etc. They are really capable devices. With WiFi you could even seriously consider pulling RSS feeds for example and do network based communications without the need for a phone. Currently it is absolutely tied to a mobile phone, something that bugs the hell out of me (as somebody who doesn’t care for phones).

Anyway, this is enough ranting for now - hopefully I will be in a position to improve the situation!