yes! i am missing things like that because all the stuff that exists and is usable now is either Android or some weird custom thing with vendor lock-in, and way too big of a computer in any case.

that's why i am making software for things like these devices for myself, and in the hope it will be useful for others

i have visions of running a clock app with all the alarm and stopwatch functionality you might want, a simple calendar app (probably with syncing), a simple email app, notes (drawing and text), calculator (maybe even graphing calculator eventually), and a terminal app to access the shell functionality on the RTOS i'm building this atop

and i'm working on loadable apps with an SDK. i plan to create a port of Quake as a demo of the capabilities of it, for heavier devices with the RAM for it (like the T-Deck). DOOM should also be possible on devices without lots of RAM

i am actually using Zephyr as the RTOS/kernel, basically as a pre-made microkernel that already makes a lot of the same decisions i would have anyway (plus, i use it at work too).

but it doesn't have all of the things i need. it doesn't have "apps" in the conventional sense, it is designed around an assumption that your firmware contains exactly one "app" that does everything. which works for 99% of commercial products that need to do precisely one thing

so i'm just writing all of my "OS middleware" to handle loading and managing user-facing apps, switching between them, and coordinating their use of resources like the display, etc

yes, and Zephyr supports a lot of other microcontrollers too. my firmware image builds without source changes for some RISC-V and ARM based microcontrollers as well as the Xtensa-based ESP32s

there's some missing functionality though, like dual-core SMP support (you can do AMP, with each core running a different firmware image), and there is currently no driver for high-speed MIPI-DBI displays using the LCD peripheral. but other than that most things work fine

@linear wait, so does AMP mean gur second core loads off a different parition / regeon of flash???
or does gur first core load code into ram and then start gur second core?

(i've never actually used an AMP system before and basically all of my SMP experience is on x86 or arm)

your first guess was correct, it is a separate partition in flash, though i am not sure how the second core is started, and that may actually still be kicked off by the first core.

paste.sr.ht/~ky0ko/8e27b0506bd…

this device tree file contains the partition layout i have define for my LilyGo T-Deck, which is set up for A/B partitions for each image type. you'll notice there are two flash partitions each for the main cpu, appcpu, and lpcore.

PROCPU (protocol CPU) is the name for core 0, and its name is omitted. APPCPU is the name for core 1. originally it was intended that core 0 handled wireless comms, core 1 handled GUI stuff, but nobody really does that. i currently don't use the appcpu or the low power core for anything.

@linear Ooh, that's more straight forward then i expected, i might have to try this out next time im doing an esp32 project

hmm, i wonder if i could have gur second core run a baremetal program to implement a virtual machine, and have gur first core run everything else

you would even have the conveniences of Zephyr on the second core if you do this, and assign hardware specifically to one core or the other (ymmv; it depends very heavily on what is attached to the board and how, they can't share peripherals)

it supports first class integration with OpenAMP, which handles providing a communication channel between the cores. i've used this professionally in a medical device, to communicate between cores running an RTOS and controlling FPGA fabric, and cores running Linux on the same Xilinx SoC, it's pretty nifty