Comment by bArray | Hacker News Reader

Comment by bArray | Hacker News Reader

I'm personally working on something like this for the ESP32, but written on top of micropython [1]. A few things are written in C such as the display driver, but otherwise most things are in micropython. We chose the T-Watch 2020 V3 microphone variant as the platform [2].

Our objective is to build a modern PDA device via a mostly stand-alone watch that can be synced across devices (initially the Linux desktop). We want to achieve tasks that you might typically do on your desktop, focussed towards productivity.

We did consider a custom OS, but decided against it for a few reasons:

1. Allowing somebody else to handle basic OS stuff allows us to concentrate on what really matters, the higher level stuff on top.

2. Having multiple threads in micropython is super simple and we are able to run many active apps at the same time, rather than having to kill them off [3]. Our background apps can continuously interact with the network in the background.

3. Code written for micropython can be easily run on other Python-capable devices.

[1] https://micropython.org/

[2] https://lilygo.cc/products/t-watch-2020-v3

[3] https://tactility.one/#/application-lifecycle

The thing with threading in micropython is that you'll have to either rely on task priorities and cooperative yielding, or GIL, and both of them can be easy to shoot yourself in a foot with.

The CCCamp23's flow3rbadge also used micropython to implement its app framework st3m: https://flow3r.garden/

We only have a few privileged tasks (scheduler, hardware, visible app). We ask that apps finish their processing within a certain time, otherwise we kill them [1]. Ideally we would have the ability to pause and restore them at will.

Our system is not all dis-similar from flow3r it seems [2].

[1] https://docs.micropython.org/en/latest/library/_thread.html

[2] https://docs.flow3r.garden/app/guide/basics.html

This kind of approach feels like the modern version of BASIC + Assembly from 8 and 16 bit days.

Exactly, but with more processing power than the BASIC + Assembly days, and more connectivity.

Definitely, I always compare the ESP32 to a modern version of the Amstrad PC 1215, and we could already do quite a lot with it.

Hence why unless we're doing some kind of PIC like development, it is about time to embrace more modern tooling. :)

I always thought Micropython deserved a C64-like computer (with some pins exposed on top).

I'd hate to be that poor little bastard, having to run 200 bullshit instructions for each useful one.

I'd probably just output a middle finger somewhere and halt forever.

This is really interesting.

Do you think the hardware would be a suitable platform for voice assistant type applications, with AI on server side, of course?

This is exactly what we are investigating, to record audio locally (minimal processing) and process it off-device. I think it's definitely possible.

Ok, I'll give it a try. Maybe I can get my daughter interested in programming with MicroPython on such a watch, as well.

You might be interested in the M5Stack Atom Echo. I believe you can flash them to work with Home Assistant (you could also just use the new HA Voice hardware).

[EDIT] Looks like the T-Watch 2020 also has HA support https://github.com/velijv/LILYGO-T-Watch-S3-ESPHome/tree/mai...

Thank you, that's even an integration, already.

Something like this?

https://tristam.ie/2024/1126/

Wow, even with local wake word. Looks like a nice retrofit for my Logitech Smart Radio.

Is the project available anywhere? I have that hardware, and am on the lookout for demo platforms for the ML/DSP library I am developing (https://github.com/emlearn/emlearn-micropython).

That's very interesting. I'd been thinking about getting a T-watch. Do you plan to have it work with the S3 series as well?

If your apps run continuously, how's the battery life?

If you freeze them to save the battery, how do you handle unfreezing?

We're still working out the exact process, but apps return a dictionary when they are put to 'sleep' to allow them to return to a previous state. The app state is stored in RAM currently, but could also be saved to disk. They can request that certain hardware is available for when they are woken, and they can request to be woken up at a certain frequency.

We can for example put the ESP32 into a light sleep for some time [1] and keep networking alive if apps require it. The idea is to just stretch the battery to the length of a day, shutting down the display gets a lot of the way already.

[1] https://randomnerdtutorials.com/micropython-esp32-deep-sleep...

Reply on news.ycombinator.com