8 ms·

Mousefood – Build embedded terminal UIs for microcontrollers

244 points by orhunp_ 8mo ago

dbacar 8mo ago
Hi Orhun, Could it be used with CYD (Cheap yellow display) ?
- nine_k 8mo ago
  At the bottom of the page there is a mention of "Phone-OS - A modern phone OS for ESP32 CYD", so apparently it must be supported.
- 01HNNWZ0MV43FF 8mo ago
  Today I Learned: https://github.com/witnessmenow/ESP32-Cheap-Yellow-Display https://github.com/witnessmenow/ESP32-Cheap-Yellow-Display
  - 0xbadcafebee 8mo ago
    fwiw, in my research into this, it looks like there are inconsistencies in the devices available, since there's no one manufacturer and they're clones of clones. one might have been reliable but then it goes out of stock
- orhunp_ 8mo ago
  Most likely. I just checked and it uses embedded-graphics already which means you can plug in Mousefood directly. The touchscreen might be a bit tricky though, it might need some hacking on the event handler side. But it will most likely work if you map the coordinates to the terminal cells abstraction somehow.
wjholden 8mo ago
Cool! I just recently began learning the Raspberry Pi Pico. Could anyone recommend a specific display that I could use with the Pico 2/2W and Mousefood?
IamDaedalus 8mo ago
aaaaand this how I learn rust I learned go because of bubbletea and mousefood (which combines my work as an embedded systems programmer and love for torminals) is here
- redanddead 8mo ago
  Oh bubbletea is really cool. Is this how most interactive CLIs are made?
  - GeertJohan 8mo ago
    I used bubbletea for a while but quit it because of inconsistencies in the design. Went to ratatui and never looked back. Go and Bubbletea are nice, but rust is much more suited for building tuis.
    - joshka 8mo ago
      Ratatui dev here. We love both Bubbletea and Textual (though I'm personally not a huge fan of either Go or Python). They're inspirations for us to make good looking stuff.
    - Kerrick 8mo ago
      I'd love to hear more about those inconsistencies. Would you be willing to share? I built RatatuiRuby recently, and I'm currently building Rooibos, its MVU framework to compete with BubbleTea. I'd love to avoid repeating Charm's mistakes.
nine_k 8mo ago
«Mousefood - a no-std embedded-graphics backend for Ratatui!» Hence 100% Rust. Works on ESP32, RPi2040, and even STM32. Several displays mentioned, including e-ink.
GeertJohan 8mo ago
This is awesome! I love ratatui, having it available on embedded is very cool! I wonder if it will work with async on embedded e.g. embassy..
- orhunp_ 8mo ago
  absolutely, it will work with any other embedded Rust application. The backend only provides a bridge between the embedded-graphics library and the Ratatui widget renderer.
onjectic 8mo ago
Reminds me a lot of the UI styles in the Minecraft mod ComputerCraft.
- orhunp_ 8mo ago
  we're bringing back those aesthetics!
- LoganDark 8mo ago
  ComputerCraft was part of how I learned to code. I first learned about password hashing when I tried to make the actually most secure door lock program. I first used raw SHA-256, but then someone on the forum introduced me to PBKDF2... Sometimes I miss those days.
zokier 8mo ago
> Embedded-graphics includes bitmap fonts that have a very limited set of characters to save space (ASCII, ISO 8859 or JIS X0201). This makes it impossible to draw most of Ratatui's widgets, which heavily use box-drawing glyphs, Braille, and other special characters You have a bitmap display, you can just draw lines and stuff without needing to rely on font-based hacks.
- weinzierl 8mo ago
  Sure, but that's beside the point. Text based graphics with fancy or custom fonts is just crazy efficient. That is exactly how we got the amazing graphics of The Last Ninja or Turrican on machines with less than 64KiB useable RAM. Same for more modern embedded devices. If you constrain yourself to text you increase both runtime performance and your developer productivity.
  - orbital-decay 8mo ago
    It was crazy efficient on character or tile-based hardware. It makes no difference on bitmap displays, or rather adds some overhead.
    - weinzierl 8mo ago
      At the end of the day it's always pixels - alway has been [1] - and the efficiency of storing and blitting a small number of fixed size rectangles is hard to beat if you can get away with it. [1] Except for the early oscilloscope style vector displays maybe.
      - gmueckl 8mo ago
        No, this is technically not fully correct. Early text based display output systems were relying on special character generator hardware to generate the display signals producing the text on screen. Those systems did not have any means of generating arbitrary pixel patterns.
orhunp_ 8mo ago
Hey all, thanks for the interest to the crate! I'm currently live on YouTube (doing some maintenance & testing). Feel free to join if you have any questions! https://www.youtube.com/watch?v=PoYEQJbYNMc https://www.youtube.com/watch?v=PoYEQJbYNMc
Liftyee 8mo ago
Really neat project but - Rust on embedded. Haven't tried it yet - has anyone got experience comparing it to C/C++?
- VorpalWay 8mo ago
  My experience is with Aruduino wiring vs Rust with embassy. And very much from a hobbyist POV. Rust on embedded uses a HAL layer, which is vendor independent (and resolved at compile time, like templates would be in C++). It doesnt cover everything yet, but basics like GPIO, SPI, I2C etc are covered. This avoids the issue of N drivers times M vendor SDKs: I2C drivers can just be written against the HAL, and you instantiate with a specific HAL in your application. Also reduces vendor lock-in. The setup process still requires some chip specific code to select which pins to use etc, but once you are past that you can be vendor neutral. Speaking of which, the API uses some clever patterns (called typestate) to ensure at compile time that your peripheral config is valid: if you "take" GPIO2 you can do that again, so you can't give the same pin to two different pieces of code by mistake. And if the driver expects a pin configured as output you can't give an input pin (you can convert a pin to "dynamic at runtime" if you really need to, so there is an escape hatch). Then there is the embassy framework. This is an alternative to RTOSes (there are some Rust RTOSes as well, haven't tried them). It makes use of async/await tasks in Rust that are statically allocated and scheduled. You can have several priority levels of schedulers (even though internally the schedulers are cooperative for the tasks inside, but they are preempting between schedulers by using interrupts). Async actually makes many things on embedded easier, such as waiting for a GPIO. No longer do you need to write your own interrupt handler, or figure out when to put the chip on a low power state, the scheduler and HAL futures do it for you. All that said: C++ still is a larger ecosystem with more tutorials, drivers and better chip support. But that is advancing rapidly in the Rust world. ESP32 series has official vendor support in Rust for example, as does at least one or two other vendors (or they are in the process of adding it). Popular chips like the RP2040 etc have support, and I have seen HALs for NRF and ST around (but never played with them). Drivers for common chips exist. So I would say it is worth experimenting with at least, but you should check up front what HALs and drivers exist for what you want to use and check how complete those are. Two years ago I wanted to do I2S things on the ESP32, but that was still missing. A year ago it had support, but some of the DMA things were clunky still. I should check again some time.
piskov 8mo ago
But all the modern TUI are react/solid (claude code, opencode), this should in typescript (thank god it isn’t; why do people drag web everywhere is beyond me)

244 points by orhunp_ 8mo ago

dbacar 8mo ago

Hi Orhun, Could it be used with CYD (Cheap yellow display) ?

nine_k 8mo ago
At the bottom of the page there is a mention of "Phone-OS - A modern phone OS for ESP32 CYD", so apparently it must be supported.
01HNNWZ0MV43FF 8mo ago
Today I Learned: https://github.com/witnessmenow/ESP32-Cheap-Yellow-Display https://github.com/witnessmenow/ESP32-Cheap-Yellow-Display
- 0xbadcafebee 8mo ago
  fwiw, in my research into this, it looks like there are inconsistencies in the devices available, since there's no one manufacturer and they're clones of clones. one might have been reliable but then it goes out of stock
orhunp_ 8mo ago
Most likely. I just checked and it uses embedded-graphics already which means you can plug in Mousefood directly. The touchscreen might be a bit tricky though, it might need some hacking on the event handler side. But it will most likely work if you map the coordinates to the terminal cells abstraction somehow.

wjholden 8mo ago

Cool! I just recently began learning the Raspberry Pi Pico. Could anyone recommend a specific display that I could use with the Pico 2/2W and Mousefood?

IamDaedalus 8mo ago

aaaaand this how I learn rust I learned go because of bubbletea and mousefood (which combines my work as an embedded systems programmer and love for torminals) is here

redanddead 8mo ago
Oh bubbletea is really cool. Is this how most interactive CLIs are made?
- GeertJohan 8mo ago
  I used bubbletea for a while but quit it because of inconsistencies in the design. Went to ratatui and never looked back. Go and Bubbletea are nice, but rust is much more suited for building tuis.
  - joshka 8mo ago
    Ratatui dev here. We love both Bubbletea and Textual (though I'm personally not a huge fan of either Go or Python). They're inspirations for us to make good looking stuff.
  - Kerrick 8mo ago
    I'd love to hear more about those inconsistencies. Would you be willing to share? I built RatatuiRuby recently, and I'm currently building Rooibos, its MVU framework to compete with BubbleTea. I'd love to avoid repeating Charm's mistakes.

nine_k 8mo ago

«Mousefood - a no-std embedded-graphics backend for Ratatui!» Hence 100% Rust. Works on ESP32, RPi2040, and even STM32. Several displays mentioned, including e-ink.

GeertJohan 8mo ago

This is awesome! I love ratatui, having it available on embedded is very cool! I wonder if it will work with async on embedded e.g. embassy..

orhunp_ 8mo ago
absolutely, it will work with any other embedded Rust application. The backend only provides a bridge between the embedded-graphics library and the Ratatui widget renderer.

onjectic 8mo ago

Reminds me a lot of the UI styles in the Minecraft mod ComputerCraft.

orhunp_ 8mo ago
we're bringing back those aesthetics!
LoganDark 8mo ago
ComputerCraft was part of how I learned to code. I first learned about password hashing when I tried to make the actually most secure door lock program. I first used raw SHA-256, but then someone on the forum introduced me to PBKDF2... Sometimes I miss those days.

zokier 8mo ago

> Embedded-graphics includes bitmap fonts that have a very limited set of characters to save space (ASCII, ISO 8859 or JIS X0201). This makes it impossible to draw most of Ratatui's widgets, which heavily use box-drawing glyphs, Braille, and other special characters You have a bitmap display, you can just draw lines and stuff without needing to rely on font-based hacks.

weinzierl 8mo ago
Sure, but that's beside the point. Text based graphics with fancy or custom fonts is just crazy efficient. That is exactly how we got the amazing graphics of The Last Ninja or Turrican on machines with less than 64KiB useable RAM. Same for more modern embedded devices. If you constrain yourself to text you increase both runtime performance and your developer productivity.
- orbital-decay 8mo ago
  It was crazy efficient on character or tile-based hardware. It makes no difference on bitmap displays, or rather adds some overhead.
  - weinzierl 8mo ago
    At the end of the day it's always pixels - alway has been [1] - and the efficiency of storing and blitting a small number of fixed size rectangles is hard to beat if you can get away with it. [1] Except for the early oscilloscope style vector displays maybe.
    - gmueckl 8mo ago
      No, this is technically not fully correct. Early text based display output systems were relying on special character generator hardware to generate the display signals producing the text on screen. Those systems did not have any means of generating arbitrary pixel patterns.

orhunp_ 8mo ago

Hey all, thanks for the interest to the crate! I'm currently live on YouTube (doing some maintenance & testing). Feel free to join if you have any questions! https://www.youtube.com/watch?v=PoYEQJbYNMc https://www.youtube.com/watch?v=PoYEQJbYNMc

Liftyee 8mo ago

Really neat project but - Rust on embedded. Haven't tried it yet - has anyone got experience comparing it to C/C++?

VorpalWay 8mo ago
My experience is with Aruduino wiring vs Rust with embassy. And very much from a hobbyist POV. Rust on embedded uses a HAL layer, which is vendor independent (and resolved at compile time, like templates would be in C++). It doesnt cover everything yet, but basics like GPIO, SPI, I2C etc are covered. This avoids the issue of N drivers times M vendor SDKs: I2C drivers can just be written against the HAL, and you instantiate with a specific HAL in your application. Also reduces vendor lock-in. The setup process still requires some chip specific code to select which pins to use etc, but once you are past that you can be vendor neutral. Speaking of which, the API uses some clever patterns (called typestate) to ensure at compile time that your peripheral config is valid: if you "take" GPIO2 you can do that again, so you can't give the same pin to two different pieces of code by mistake. And if the driver expects a pin configured as output you can't give an input pin (you can convert a pin to "dynamic at runtime" if you really need to, so there is an escape hatch). Then there is the embassy framework. This is an alternative to RTOSes (there are some Rust RTOSes as well, haven't tried them). It makes use of async/await tasks in Rust that are statically allocated and scheduled. You can have several priority levels of schedulers (even though internally the schedulers are cooperative for the tasks inside, but they are preempting between schedulers by using interrupts). Async actually makes many things on embedded easier, such as waiting for a GPIO. No longer do you need to write your own interrupt handler, or figure out when to put the chip on a low power state, the scheduler and HAL futures do it for you. All that said: C++ still is a larger ecosystem with more tutorials, drivers and better chip support. But that is advancing rapidly in the Rust world. ESP32 series has official vendor support in Rust for example, as does at least one or two other vendors (or they are in the process of adding it). Popular chips like the RP2040 etc have support, and I have seen HALs for NRF and ST around (but never played with them). Drivers for common chips exist. So I would say it is worth experimenting with at least, but you should check up front what HALs and drivers exist for what you want to use and check how complete those are. Two years ago I wanted to do I2S things on the ESP32, but that was still missing. A year ago it had support, but some of the DMA things were clunky still. I should check again some time.

piskov 8mo ago

But all the modern TUI are react/solid (claude code, opencode), this should in typescript (thank god it isn’t; why do people drag web everywhere is beyond me)