[HN Gopher] Tactility: OS for the ESP32 Microcontroller Family
___________________________________________________________________
Tactility: OS for the ESP32 Microcontroller Family
Author : freetonik
Score : 140 points
Date : 2025-01-10 08:37 UTC (14 hours ago)
(HTM) web link (tactility.one)
(TXT) w3m dump (tactility.one)
| trilbyglens wrote:
| This is sweet! Looking forward to playing with this
| bayindirh wrote:
| Moreover, it's licensed with GNU/GPLv3, which I love.
| bArray wrote:
| 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
| pjmlp wrote:
| This kind of approach feels like the modern version of BASIC +
| Assembly from 8 and 16 bit days.
| bArray wrote:
| Exactly, but with more processing power than the BASIC +
| Assembly days, and more connectivity.
| pjmlp wrote:
| 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. :)
| rvense wrote:
| I always thought Micropython deserved a C64-like computer
| (with some pins exposed on top).
| seba_dos1 wrote:
| 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/
| bArray wrote:
| 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
| mitjam wrote:
| 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?
| bArray wrote:
| This is exactly what we are investigating, to record audio
| locally (minimal processing) and process it off-device. I
| think it's definitely possible.
| mitjam wrote:
| Ok, I'll give it a try. Maybe I can get my daughter
| interested in programming with MicroPython on such a watch,
| as well.
| teamonkey wrote:
| 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...
| mitjam wrote:
| Thank you, that's even an integration, already.
| pantalaimon wrote:
| Something like this?
|
| https://tristam.ie/2024/1126/
| mitjam wrote:
| Wow, even with local wake word. Looks like a nice retrofit
| for my Logitech Smart Radio.
| nine_k wrote:
| If your apps run continuously, how's the battery life?
|
| If you freeze them to save the battery, how do you handle
| unfreezing?
| bArray wrote:
| 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...
| anigbrowl wrote:
| 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?
| numpad0 wrote:
| This appear to be a window system and desktop environment than
| OS, but isn't it that ESP32 user code always runs atop FreeRTOS
| for radio management purposes?
| MrBuddyCasino wrote:
| If you use ESP-IDF, then yes. I'm not sure other OS support
| wifi.
| seba_dos1 wrote:
| Not yet, but: https://github.com/esp32-open-mac/esp32-open-
| mac
| dfox wrote:
| Espressif ships the wifi driver also as an .o file that takes
| huge struct of function pointers to OS-provided functions
| that works with other RTOSes. But you need some kind of RTOS.
| MrBuddyCasino wrote:
| Thats progress! Is it already integrated in another RTOS?
| pantalaimon wrote:
| RIOT-OS implements shims of the FreeRTOS functions required
| by the Wifi driver when running on ESP32
| teamonkey wrote:
| Tactility appears to be built on top of FreeRTOS.
|
| FreeRTOS itself is very barebones, a library that provides
| basic memory management, task scheduling, io and a TCP stack,
| but not, for example, an abstraction layer for screen, keyboard
| or other peripherals, or the concept of running user
| applications.
| dazhbog wrote:
| Any idea where is the simulator project located?
| beardyw wrote:
| An "ESP Microcontroller" definitely doesn't have a keyboard or a
| screen. That title is misleading and should say something like
| "ESP based device". I can buy an ESP32 for PS3, these are a
| different thing altogether.
| bayindirh wrote:
| Yet you can use the same OS for headless application
| development. No?
|
| Not all x86 systems have keyboards and screen, but Linux and
| Minix work on them with no problem.
| TechSquidTV wrote:
| If you buy a desktop computer it 100% does not come with a
| screen and only sometimes comes with a basic keyboard. This
| doesnt seem relevant.
| leptons wrote:
| > it 100% does not come with a screen
|
| There are plenty of "all-in-one" desktop PCs that are a PC
| with a built-in screen. Apple, Dell, HP, Lenovo, and others
| make them.
| junon wrote:
| This seems like needless pedantry.
| corv wrote:
| I'm glad to see M5Stack is supported!
| bigfishrunning wrote:
| I have a few M5 cardputers, i wonder how hard a port would be
| jeffhuys wrote:
| Meshtastic is another project that has recently made serious
| strides[0] in their UX on the Lilygo T-deck (and similar ESP32
| devices), but specifically regarding LoRA-enabled devices.
|
| It's still on a branch, but I compiled and ran it, and now I have
| two T-decks that can communicate with eachother off-the-grid
| without a smartphone attached to send messages; it's actually
| usable in emergencies now, which is why I bought the devices in
| the first place.
|
| Currently in the process to deploy a mesh from me to my parents
| and family.
|
| [0]: https://github.com/meshtastic/firmware/pull/3259
| jeroenhd wrote:
| What's the data transfer speeds you can attain with LoRA
| devices like these? My understanding is that they're geared
| more towards bytes per hour than bytes per second, and other
| than some kind of "I'm alive" message, I don't get the
| impression these devices are very usable for communication.
| vaxman wrote:
| It is probable the latest editions of ESP32, Rockchip and other
| controllers manufactured in China do contain CCP exploits. Even
| the Intel-based mainboards from certain Chinese manufacturers
| also contain EFI with CCP exploits. (It's not about the chip or
| brand, it's about the CCP forcing this on China-based
| manufacturers.) Disclaimer: I've been downvoted over raising this
| in years past, but now it's a widely covered mainstream issue. I
| too like the idea of $2 multicore SoCs with integrated RF, but
| not devices that can potentially blow an on-dye fuse with a
| specific RF-delivered opcode sequence to enable "new
| functionality"..and for you technician types, there is a lot more
| to RF than BLE/WiFi/NFC and various HA protocols that some ESP
| officially support.)
|
| I saw soon to retire Jensen announce a new SoC
| (https://www.reuters.com/technology/nvidia-ceo-says-mediatek-...)
| at CES 2025 in partnership with Taiwan's Mediatek for their new
| DIGITS PC (just before NVIDIA stock tanked on the speech) and
| thought his fire is playing with fire, but this may be a solution
| to untrustable RockChip performance, Qualcomm profiteering and
| Apple proprietary solutions.
| be_erik wrote:
| Do you have proof of these claims that you can link here on HN?
| While I'm not surprised, maybe you can provide proof of which
| brands are working with the CCP and the kinds of backdoors
| being installed?
| anigbrowl wrote:
| What's the advantage over The device as ap and just flashing it
| from your development environment? I'm quite interested as I'm
| into ESP32, but the lack of detail is disappointing and makes me
| not want to invest time.
___________________________________________________________________
(page generated 2025-01-10 23:01 UTC)