wasp-os: MicroPython for PineTime!

[33YN2]

Daniel, since you sounded like you had issues with your pinetime, would you like me to send you a new sealed pinetime unit with the new bootloader to help with your development efforts? I got a three pack, but i wont be needing all three.

[arkharim]

I suspect that int(z[1]+si*p-w//2) has evaluated to a negative number (resulting in one of the four expressions on the last line being out of range). When running on the simulator it should be easy to print them: perhaps modify the set_window() method to print out all its arguments.

It will be a slow but it should be fairly clear.

That was it! In fact, not negative but too large. I somehow wanted to draw hands larger than the display, which went well until now. I'll commit and re-do the pull request later today. Thanks so much!

Hi,

I'm developing a watchface based on your analog and chrono24 watchfaces . My goal is develop a configurable clock that allows the user customize the watchface using a settings page (not implemented). Currently supports de digital clock (same than the Dainelt but refactored) and an analog clock. I'm struggling with the performance... In the simulator, your analog or chrono24 apps or my configurable clock it seems not to be enough faster.

If you are interested, lock at: https://github.com/arkharim/wasp-os/blob...e_clock.py I tried to clean a liitle but it is in development.

One interesting feature is that it supports background images . I modified the Draw565 library adding the redraw_blit method.

Finally, today in the pinetime chat one guy share a table with the sin and cosine calculated. In want to try to check the performance but my feeling is that the problem is related with spi velocity.

Important, I only tried this watchface in the simulator as I don't have a pinetime already (waiting for a one unit sealed pinetime)

[danielt]

I'm developing a watchface based on your analog and chrono24 watchfaces . My goal is develop a configurable clock that allows the user customize the watchface using a settings page (not implemented).

I'd also like to be able to offer customizable watch faces but I don't personally think a configurable clock is the right way to handle supporting multiple watch faces. A large monolithic clock app risks making it difficult for users to provide a new watch face. Large apps only be loaded into FLASH whilst small apps can be loaded into RAM allowing the app to be loaded without having to recompile the whole firmware.

The system is currently designed such that the first app on wasp.system.quick_ring is special and will automatically be switched to when the display turns off due to inactivity (unless the current app asks for this not to happen). The result is that watch face will be displayed by default the next time the watch is activated. This is the only difference between a watch face and any other app. To change the default watch face then the users's main.py (or a settings app) can simply do something like: wasp.manager.quick_ring[0] = NewWatchApp() .

On other words rather than having a configurable clock app I think it is better to have several single watch face applications and to modify the system manager to offer better ways to enumerate the applications that are available.

Please don't be discouraged by anything here. I'm keen to see new watch faces and have started to merge faces from other developers into the wasp-os repo! I just think it is better for each watch face to be a separate app.

PS I spent some time this weekend simplifying and commenting the existing digital clock app (which has been requested by others who want to code their own watch faces). I've not pushed it yet because it needs a little more testing but there are some fairly significant simplifications (the code to handle lazy redraw is not a lot clearer).

[arkharim]

I'm developing a watchface based on your analog and chrono24 watchfaces . My goal is develop a configurable clock that allows the user customize the watchface using a settings page (not implemented).

I'd also like to be able to offer customizable watch faces but I don't personally think a configurable clock is the right way to handle supporting multiple watch faces. A large monolithic clock app risks making it difficult for users to provide a new watch face. Large apps only be loaded into FLASH whilst small apps can be loaded into RAM allowing the app to be loaded without having to recompile the whole firmware.

The system is currently designed such that the first app on wasp.system.quick_ring is special and will automatically be switched to when the display turns off due to inactivity (unless the current app asks for this not to happen). The result is that watch face will be displayed by default the next time the watch is activated. This is the only difference between a watch face and any other app. To change the default watch face then the users's main.py (or a settings app) can simply do something like: wasp.manager.quick_ring[0] = NewWatchApp() .

On other words rather than having a configurable clock app I think it is better to have several single watch face applications and to modify the system manager to offer better ways to enumerate the applications that are available.

Please don't be discouraged by anything here. I'm keen to see new watch faces and have started to merge faces from other developers into the wasp-os repo! I just think it is better for each watch face to be a separate app.

PS I spent some time this weekend simplifying and commenting the existing digital clock app (which has been requested by others who want to code their own watch faces). I've not pushed it yet because it needs a little more testing but there are some fairly significant simplifications (the code to handle lazy redraw is not a lot clearer).

Hi Danielt,
Thanks for the whole explanation. I'm only free time developer without experience in this kind of systems before. I'll follow your suggestion to develop a small app.

[danielt]

The wasp project is proud to announce the release of wasp-os v0.3. This release is long overdue given the step counter and heart rate monitor (which was the original target for this release) have been running since mid-July. Anyhow, the long gap between releases has allowed lots more new stuff to be added. This includes the infrastructure for notifications (just the infrastructure... a GadgetBridge port it available as a companion app for Android but currently it is available only as a source-only pre-release) together with extensive support for over-the-air updates, including support for the OTA updates to and from the new factory firmware for Pine64 PineTime devices.

https://github.com/daniel-thompson/wasp-...s/tag/v0.3

As ever all the new features have corresponding updates to the documentation meaning you can read all about the new apps and features right now at: at: https://wasp-os.readthedocs.io . You can also watch many of the new features in action by looking at some of the most recent wasp-os video blogs:

* Step counting and heart rate monitoring on Pine64 PineTime
* Installing on a Pine64 PineTime running the latest factory firmware

[laureote]

Hello Daniel,
Thanks you for your job
I tried your os and it's works !!
I want to know if it's possible with micropython to send via urequest Heart Rate datat on a flask server from pinetime.
Thanks you !!






Update 22 Nov 2020:
The wasp project is proud to announce the release of wasp-os v0.3. This release is long overdue given the step counter and heart rate monitor (which was the original target for this release) have been running since mid-July. Anyhow, the long gap between releases has allowed lots more new stuff to be added. This includes the infrastructure for notifications (just the infrastructure... a GadgetBridge port it available as a companion app for Android but currently it is available only as a source-only pre-release) together with extensive support for over-the-air updates, including support for the OTA updates to and from the new factory firmware for Pine64 PineTime devices.

https://github.com/daniel-thompson/wasp-...s/tag/v0.3

As ever all the new features have corresponding updates to the documentation meaning you can read all about the new apps and features right now at: at: https://wasp-os.readthedocs.io . You can also watch many of the new features in action by looking at some of the most recent wasp-os video blogs:

* Step counting and heart rate monitoring on Pine64 PineTime
* Installing on a Pine64 PineTime running the latest factory firmware

---

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).


wasp-os: The M2 pre-release running on Pine64 PineTime

[danielt]

Hello Daniel,
Thanks you for your job
I tried your os and it's works !!
I want to know if it's possible with micropython to send via urequest Heart Rate datat on a flask server from pinetime.
Thanks you !!

Possible? Yes. Implemented? No. It really depends on what protocol is used to communicate between the watch and the rest of the world.

Currently wasp-os adopts a very simple approach of presenting the Python REPL via the Nordic UART Service. Thus the watch is very much a peripheral and tools such as wasptool (for GNU/Linux) or GadgetBridge (for Android) work by connecting to the UART Service on the watch and sending it python commands and JSON via the "UART".
 
For urequests to work you'd need a full network stack which means switching the protocol from the UART Service to IPv6 over BLE. That would be really cool party trick but its a big job. Running IPv6 over BLE would also require users to setup some kind of gateway device (or run a special application) to bridge BLE to their home network. Over time such gateways may become common... although that world hasn't arrived yet (and maybe never will).

For now I'd recommend using the app model to exflitrate data from the watch. In other words get tools running on a WiFi capable device (wasptool or gadgetbridge) to periodically grab data from the watch and post it to your flask server.

[purlupar]

What's going on if the simulator does not respond to keypresses/mouse swipes? I triple-checked the dependencies and importantly, there is no warning or error coming up whatsoever. Interestingly, swipe up only DOES work (resulting in echoing the motor action). I tried from a fresh clone from git.

BTW: I finally got some time again to work on Chrono24, to be pull-requested in a few days/weeks' time!

[danielt]

To be honest I've never seen the simulator unreactive to these things. There are a couple of ways a broken application could cause this but you've done a fresh clone and the built-in applications are unlikely to cause this.

Either way I'd recommend starting by adding a couple of prints:

1. Check the lowest level of the simulator is correctly handling events by printing event here: https://github.com/daniel-thompson/wasp-...ay.py#L221
2. Check wasp-os is handling interrupts from the (simulated) touch screen by printing dbuf here: https://github.com/daniel-thompson/wasp-...ay.py#L105

After that follow where the prints lead and add further prints further through the stack to zoom in. If you need to learn more about the structure of wasp-os you might be able to use traceback.print_tb or pdb.set_trace from critical bits of code (the former prints a stack trace, the later enters a text mode debugger allowing you to explore dynamically)... or you can just ask here once you have gathered more evidence!

[purlupar]

To be honest I've never seen the simulator unreactive to these things. There are a couple of ways a broken application could cause this but you've done a fresh clone and the built-in applications are unlikely to cause this.

Either way I'd recommend starting by adding a couple of prints:

1. Check the lowest level of the simulator is correctly handling events by printing event here: https://github.com/daniel-thompson/wasp-...ay.py#L221
2. Check wasp-os is handling interrupts from the (simulated) touch screen by printing dbuf here: https://github.com/daniel-thompson/wasp-...ay.py#L105

After that follow where the prints lead and add further prints further through the stack to zoom in. If you need to learn more about the structure of wasp-os you might be able to use traceback.print_tb or pdb.set_trace from critical bits of code (the former prints a stack trace, the later enters a text mode debugger allowing you to explore dynamically)... or you can just ask here once you have gathered more evidence!

1. Gives back <sdl2.events.SDL_Event object at 0x.....
2. Gives back bytearray(b'\x03\...

Now, I realized that the simulator seems to be working -- it tells me "volume down" (for the mock music app), for example -- but not updating the simulator display (the time does not change either, for example). I'm a bit overwhelmed by deciding where to look next. What I've been doing is removing the dependencies of the simulator (requirements.txt) via pip and installing them via my distro's package manager, which my distro's wiki says is the preferred way to install python packages. The point being, this looks like a sdl-related problem if I understand correctly, and well, I have very little experience with that. Oh and the simulator's stdout tells that it does in fact refresh (I put a print there), and a lot so. What would you do next? Thanks for the advice so far!