The project is called “Tactility” and its website is https://tactility.one/
You can run ELF binary apps directly from an SD card without restarting or flashing the ROM. There’s an SDK for building these apps, but I haven’t made an official release yet.
I wrote a blog post with some background information: https://bytewelder.com/posts/2025/01/06/tactility-one-year-later.html
Source code and project files: https://github.com/ByteWelder/Tactility
I just picked up one of those lily go systems and am excited
You can find some builds at the bottom of the page here: https://github.com/ByteWelder/Tactility/actions/runs/12659191949 These files expire in 30 days though.
Looks cool, but what should I look to do with it?
In its current state, it’s mainly a tool for developers to be able to build prototypes or experiments quickly. From a user perspective, there isn’t enough yet. We’ll need more apps before it’s useful for end-users. I want to improve the core functionality before I build more apps: I already have to maintain about 2 dozen apps and I’d rather spend my time on building a better platform for now.
I have a python app that would love to run on a small wifi device like an ESP, how far away is the possibility to do that? Could I freeze the python fikes to (8MB IIRC) executables (Linux) and run them?
Also, how do you use an sd card on the esp?
I toyed around a lot with the old ESP 8266 back in the day so I’m a bit out of the loop with thise newer ones.
I don’t expect regular Python apps to ever run on Tactility, as the memory requirements are likely too high. There is at most about 8MB of RAM for apps available. Perhaps a special build of micropython could work at some point.
You can open the Files app and there’s a folder named “sdcard”. So far, all SD card implementations are done via a serial interface (SPI). I cannot mount them on-the-fly yet - only at boot.
I cross posted this to !esp32@lemmy.ml
Thanks! Good to see there’s an ESP32 community too. I just subscribed ^^
Nice! I currently only use my tdeck for meshtastic but this would broaden it’s capabilities.
Meshtastic is cool I wish there were more public users around me.
very cool! lots of neat other projects too
Looks cool! However, there is with badge.team also a similar app platform which they used on https://flow3r.garden/, on the MCH22-badge and the now in preorder namatsu: https://shop.nicolaielectronics.nl/products/tanmatsu?variant=55608856183133 (which I just ordered two of)
While it definitely is a cool project, it’s a micropython one, so the target audience is similar but not the same.
My friend runs a similar project in Rust, focusing on running wasm-compiled programs
Admittedly, I don’t know a whole lot about what instruction set features the ESP32 actually has, but isn’t an embedded processor that small by nature lacking in things like, say, a memory management unit? Don’t take this the wrong way, but the notion of making a general-purpose OS that relies on cooperative multitasking seems a bit sketchy at a time when you could just spend an extra buck to move up to something like a Raspberry Pi Zero that can run a proper memory-safe and preemptive OS.
There is indeed no way to create new virtual memory mappings. When a binary is loaded, it’s manually mapped into IRAM (instruction RAM).
The target audience for things like Lilygo T-Deck is probably the more technical side of the Flipper Zero audience. I can see how it could also become an end-user device (like Flipper Zero is to many people), but we’ll need more apps for that.
And sure, you could use a Raspberry Pi, but part of the fun/challenge of this project is that it hasn’t been done for ESP32 before (as far as I’m aware). Some differences: a Raspberry Pi draws more power, costs more, and generally doesn’t boot in under 2 seconds. I’m also not aware of compact Pi-based handhelds like the Lilygo T-Deck is to my project. edit: There’s the uConsole, but it’s twice the price, likely has 6+ months delivery time, is much larger, and weighs much more.
Is there a reason you didn’t use the ESP-S3’s MMU? https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-reference/system/mm.html
I didn’t know this exists! I’m currently using a dependency to load ELF files: https://components.espressif.com/components/espressif/elf_loader I guess it would make more sense to have the memory mapping done inside
elf_loader, so that S3 devices can load to PSRAM and non-S3 devices can load into IRAM. Thanks for the tip!Looking at some of the bug reports it looks like your dependency may already be using the MMU.
