wasp-os: MicroPython for PineTime!

[danielt]

Update 20 Feb 2021:
The wasp-os project is proud to announce the release of wasp-os v0.4. Wasp-os is a firmware for smart watches that are based on the nRF52 family of microcontrollers, and especially for hacker friendly watches such as the Pine64 PineTime. Wasp-os features full heart rate monitoring and step counting support together with multiple clock faces, a stopwatch, an alarm clock, a countdown timer, a caclulator and lots of other games and utilities. All of this, and still with access to the MicroPython REPL for interactive tweaking, development and testing.


During the v0.4 development cycle our focus was on improving the watch/phone integration whilst also taking steps to improve the general fit and finish. This release introduces a new clean-and-simple analog watch face, new button, checkbox and spinner widdgets to make UI more consist, new customization options such as a theming engine and a configuration tool that provides access to most of the new goodies without having to write a line of Python code (although Python is still fully available to those that want to make very deep customizations).

In this development cycle we have worked with the Gadgetbridge project to add wasp-os support to the latest versions of Gadgetbridge. For more information on how to obtain Gadgetbridge (hint: don't use the Play store) take a look at the appropriate wiki page.

As usual documentation is an important part of making wasp-os awesome so you can read up on how to install wasp-os and take look at all the new apps and features right now at: at: https://wasp-os.readthedocs.io

You can also see many of the new features in action by looking at some of the most recent wasp-os video blogs:


A tour of the new applications for wasp-os


Step counting and heart rate monitoring on Pine64 PineTime

---

Since I received my PineTime a couple of weeks ago I have been working whenever I have a spare moment to make my PineTime wearable. At this point I have, more or less, reached this goal! Admitedly It's not any smarter than the dumbest of my dumb watches but I've been wearing my PineTime for the last two days and I haven't been late to any meetings. That means I think its time to talk a bit more about what I have been doing.

Firstly, if you just want the code please visit: https://github.com/daniel-thompson/wasp-os (there is also a short intro video if you'd prefer)

If you're still interested in a bit more of the story... there are a great many different possible approaches to developing a firmware for a wearable like the PineTime and I wanted to experiment a bit with MicroPython to see whether I could "go fast" during development by using tools that allow for easy interactive hacking on the device itself and that also naturally shares a stack trace when I mess something up.

I've not got far enough to draw conclusions on whether MicroPython helps me get more done in my limited free time but I can certainly attest that having a REPL to send interactive commands to the ST7789 display was really good for helping me get to grips with how it actually worked (something I hope can be repeated for some of the other drivers).

As mentioned in the intro, wasp-os currently provides nothing more than a simple digital clock application for PineTime together with access to the MicroPython REPL for interactive testing and tweaking. However it keeps time well and has enough power saving functions implemented that it can survive for well over 72 hours between charges so even at this early stage it is functional as a wearable timepiece.

It also includes a bootloader based on the Adafruit nRF52 Bootloader which has been extended to make it robust for development on form-factor devices without a reset button, power switch, SWD debugger or UART. This is working well and allows me to update the main application over-the-air but there remain a few extra features that I want to get right before glueing the back on my own device (currently I am relying on double sided tape).

[jwhooper]

Since I received my PineTime a couple of weeks ago I have been working whenever I have a spare moment to make my PineTime wearable. At this point I have, more or less, reached this goal! Admitedly It's not any smarter than the dumbest of my dumb watches but I've been wearing my PineTime for the last two days and I haven't been late to any meetings. That means I think its time to talk a bit more about what I have been doing.

Firstly, if you just want the code please visit: https://github.com/daniel-thompson/wasp-os

If you're still interested in a bit more of the story... there are a great many different possible approaches to developing a firmware for a wearable like the PineTime and I wanted to experiment a bit with MicroPython to see whether I could "go fast" during development by using tools that allow for easy interactive hacking on the device itself and that also naturally shares a stack trace when I mess something up.

I've not got far enough to draw conclusions on whether MicroPython helps me get more done in my limited free time but I can certainly attest that having a REPL to send interactive commands to the ST7789 display was really good for helping me get to grips with how it actually worked (something I hope can be repeated for some of the other drivers).

As mentioned in the intro, wasp-os currently provides nothing more than a simple digital clock application for PineTime together with access to the MicroPython REPL for interactive testing and tweaking. However it keeps time well and has enough power saving functions implemented that it can survive for well over 24 hours between charges so even at this early stage it is functional as a wearable timepiece.

It also includes a bootloader based on the Adafruit nRF52 Bootloader which has been extended to make it robust for development on form-factor devices without a reset button, power switch, SWD debugger or UART. This is working well and allows me to update the main application over-the-air but there remain a few extra features that I want to get right before glueing the back on my own device (currently I am relying on double sided tape).


wasp-os digital clock app running on PineTime

I have the bootloader.hex working on my PineTime, but no matter what I do nordic Connect give a DFU error 6, and I have set packets down to 1.  Maybe my phone is too slow, it's a Moto G6.  Soooo close.  Really nice work, the only thing I had to adjust was replace all with lto=0 on the make file at the end, otherwise it just wouldn't compile, don't know why.

---

Didn't work on my tablet either, same error. Is this something that is signed?

[jwhooper]

OK, now I have it.  It helps to upload the correct file!  Ah, but it's the large pine cone, not the time and battery, so I compiled the old version.  I'll get it right tomorrow.  Outstanding work!  Can't beat OTA updates!

[danielt]

OK, now I have it.  It helps to upload the correct file!  Ah, but it's the large pine cone, not the time and battery, so I compiled the old version.  I'll get it right tomorrow.  Outstanding work!  Can't beat OTA updates!

Glad to hear you got this working.

Regarding the LTO=0 this is probably toolset related, in particular there are known problems with older toolchains. All my builds are built using gcc-9 from the gnu-rm toolchain (2019-q4) although I did add a patch to ensure LTO=0 builds do actually work.

BTW I also forgot to add a disclaimer to the original announcement about the code quality! What is currently in the repo is the result of a sprint to meet dumb watch feature parity and I have taken several short cuts along the way (the watch app is synchronous and blocks the REPL, all code is in frozen modules, a couple of dubious burned in assumptions and a manager whose role is rather fuzzy). At this stage wasp-os might be useful experimenting with the PineTime platform but there's not enough framework to support plug-in applications.

However, as you will see from the TODO list the next milestone is all about the developer experience and on getting the a binary release make sense so I hope things will gradually change in that regard!

[jwhooper]

OK, I'll come back to it when it is ready for plug-in applications. Maybe I can find another OS to play with in the meantime, thanks for the information.

[jwhooper]

Will the bootloader.hex need to be updated again, or can all the updates from this point install over BLE? I have a borrowed ST-Link. I was planning on buying my own programmer, but all of this is looking a lot more difficult than I thought. I have done some ESP8266 or ESP32 programming using Arduino IDE, but I've spent days just trying to get the tool chain to work, so I think the microcontroller OS level is not for me.

[danielt]

Will the bootloader.hex need to be updated again, or can all the updates from this point install over BLE?

That is the plan, yes.

The goal is to have an updater image that can be downloaded instead of micropython.zip that will run a few consistency checks (checksums and battery levels) and then update the bootloader and softdevice. I haven't written the updater yet but I'm confident this approach will be possible.

However... that is only useful for replacing the wasp bootloader with a newer version of itself. If you want to run PineTime programs that either do not use a bootloader or rely on a different bootloader then you might have to use an SWD programmer to switch between them.

I have a borrowed ST-Link.  I was planning on buying my own programmer, but all of this is looking a lot more difficult than I thought.  I have done some ESP8266 or ESP32 programming using Arduino IDE, but I've spent days just trying to get the tool chain to work, so I think the microcontroller OS level is not for me.

Don't be too discouraged. It is painful working on a dev kit intended for a "developer with extensive embedded OS experience and an interest in Smart Watch development" but there are also great learning opportunities! To be honest I found loading bootloader.hex to the PineTime to be the most difficult and frustrating part of the project so far (although getting the MicroPython REPL configured right came a close second).

PineTime is pretty new and currently the documentation and blog posts on compiler choice and SWD programming is either not beginner friendly (needs skill and experience to understand) or is heavily simplified (meaning it needs skill and experience to expand from the specific example provided to general principles). Information is starting to accumulate (at https://wiki.pine64.org/index.php/Reprog...e_PineTime ) but it still needs careful organising both to describe tasks not technology (unlock chip, program elf file, program hex file, debug with gdb) and to de-duplicate (openocd instructions are usually common regardless of the debug adapter used so distinguishing between RPi/ST-Link/CMSIS-DAP so it would better to have a single openocd chapter with sub-sections for the different adapters).

So I hope you keep going. If you do be aware that you cannot use ST-Link to remove the flash protection (I used black magic probe for this since I had one around but I think many others used the RPi). Once you have removed flash protection I'm pretty sure the instructions here worked for me: https://dev.to/aaronc81/flashing-your-pi...enocd-54dd . As I said I didn't keep good notes but that last program command should be able to cope equally well with raw binaries, elf files and hex files.

Update: Sorry... I got a bit muddled between forum and github threads. Reading back you've already got the STLink working I think? Does that mean you're currently in the "now what?" stage when you are presented with the pinecone (or time if you have updated to a later version) and aren't sure what you should do next?

[danielt]

I've been slowing chugging through the TODO list and recently landed some changes that really start to change the way we can set about writing code for wasp-os.

The major new pieces are a hosted simulator that allows us to test a lot of the python code on your workstation simply by running "make sim". The other thing that has  landed recently is patches to bring up a real filesystem (using the 4MB external SPI NOR FLASH). This is, IMHO, a big step in making the device more developer friendly. Combined with the new wasptool helper program it is possible to copy python sources to the device without having to launch a full OTA update. Instead we can have a faster development cycle that looks something like this

Code:

./tools/wasptool --upload mycode.py
./tools/wasptool --console
>>> import mycode
>>> mycode.do_something_interesting()
>>> ^X
<write a new main script to exploit mycode>
./tools/wasptool --exec main.py
<repeat until happy>
./tools/wasptool --upload main.py
<long press into bootloader, short press back into uPy and watch the new main launch whatever you have written>

The code that runs the default watch application still needs a lot of work to reach the point where we can have plugable application (no launcher, no async framework, etc) but today anyone who knows a little python can take the whole system by the scruff of the neck and code whatever takes your fancy!

So... not finished but suddenly I think it is a much more interesting playground for people because it feels more like coding in Python than the traditional embedded edit/compile/download/debug cycle!

[mulm]

Will the bootloader.hex need to be updated again, or can all the updates from this point install over BLE?

The goal is to have an updater image that can be downloaded instead of micropython.zip that will run a few consistency checks (checksums and battery levels) and then update the bootloader and softdevice. I haven't written the updater yet but I'm confident this approach will be possible.

FYI, A week ago or so, I was able to OTA update my rebuild of bootloader.zip by simply using nRF Connect (Android).  I can't recall exactly, but I think I also tried re-sending softdevice in this way as well.  Personally, I think this is a fine solution to above problems and wouldn't spend any more time on it.  The Nordic tools seem already mature enough to support most of the upgrade use-cases.

[mulm]

I may be mistaken about bootloader OTA.  When I tried again just now, I was unable to update bootloader with either bootloader.zip or the contents directly.  This was, again, with nRF Connect for Android.  I also tried reverting to the earlier commit that I used to build the version currently in the device, but no luck.

The behavior I see is this:

• open nRF Connect
  
• connect to PineDFU
  
• click on DFU button and "Select file type" (and tried both as "Distribution packet (ZIP)" and "Bootloader")
  
• nRF Connect goes to "Starting DFU..."
  
• Pinetime resets, dropping connection
  
• nRF Connect goes back to ready-to-connect screen
  

I would think this is just a missing element or misconfiguration of underlying bootloader... the Nordic tools seem very mature from what I've seen so far.