Question: Is this usable in no_std environment at the moment?

[iamadahn]

Hello, sorry for creating issue, I'm trying to test mousefood on stm32h7 mcu and I'm struggling a bit. I was looking into your mousefood-esp32-demo repo and it looks like in last 3 months some api changes happened and for example there is no mousefood::prelude::Terminal already. It is if I'm using git version, if using crates.io version it doesn't want to compile with no_std at all. So the question is in the title, I want to know if it is possible to make it work at the moment.

[j-g00da]

The latest version on crates.io - v2.1 uses std, but the version on main branch is already no_std.

You can use the version from git and you will also need a compatible ratatui alpha version:

mousefood = { git = "https://github.com/j-g00da/mousefood", rev = "1028ac24f83920fd95a5585a85ef943901ee63ac" }
ratatui = { version = "0.30.0-alpha.5", default-features = false }

Then you can import Terminal directly from ratatui, and embedded backend from mousefood.

Let me know if you manage to run it on stm32h7!

[iamadahn]

Ok, it compiles and even tries to display something, but the allocation is huge, I have stm32h723vg with 320kb of ram and 480x320 display and ratatui tries to allocate buffer with full frame size which is to big. Is there a way to make it use partial buffer like for example in LVGL?

[j-g00da]

I want to make buffer optional in the next release. For now, best you can do is try to render on just part of the display.

[iamadahn]

It's working

[j-g00da]

Nice! I can create a temporary branch with buffer turned off completely if you want.

[iamadahn]

That would be great, because in my case 480x320 is too big for full frame allocation. It's not that big of a deal when you're working with esp32, but stm32 chips have a lot less ram

[iamadahn]

Hey again, I decided that it would be good to test mousefood with esp32 no_std too, e.g. using esp-hal with embassy, but I'm struggling to compile the project once again, this time it returns an error in kasurai, do you have any idea how to fix that?

error[E0432]: unresolved import `alloc::sync`
   --> kasuari-0.4.7/src/constraint.rs:1:12
    |
1   | use alloc::sync::Arc;
    |            ^^^^ could not find `sync` in `alloc`
    |
note: found an item that was configured out
   --> stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/lib.rs:231:9
    |
231 | pub mod sync;
    |         ^^^^
note: the item is gated here
   --> stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/lib.rs:230:1
    |
230 | #[cfg(all(not(no_rc), not(no_sync), target_has_atomic = "ptr"))]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0599]: no method named `fetch_add` found for struct `AtomicUsize` in the current scope
  --> kasuari-0.4.7/src/variable.rs:17:26
   |
17 |         Self(VARIABLE_ID.fetch_add(1, Ordering::Relaxed))
   |                          ^^^^^^^^^ method not found in `AtomicUsize`

I thought that it might be related to esp-alloc crate and changed it to embedded-alloc, which I used on stm32, but nothing changed. Also I'm using esp32c3 mcu which is risc-v, not xtensa, may be it's related somehow.

[Hectorban]

Got it working with the esp32 https://github.com/Hectorban/esp_hal_mousefood

[Hectorban]

Had some problems with getting it working async + flush callback but i think that's an specific quirk of the ssd1306 crate which needs display.flush().await.unwrap();

[j-g00da]

Yeah, ratatui requires allocation, so you need to build alloc. @iamadahn

[unstable]
build-std = ["alloc", "core"]

Btw. there's an option (on the main branch) now to disable the framebuffer, this way you should be able to draw to the whole screen on your stm32:

mousefood = { git = "https://github.com/j-g00da/mousefood", rev = "2c78249e169312a91482d0aac23337c687cf0dfa", default-features = false, features = ["fonts"] }
ratatui = { version = "0.30.0-alpha.5", default-features = false }

[iamadahn]

Thank you for clarification, will test soon

[Hectorban]

Tried with the esp32c6 and got what i think is memory alignment/size issues.
The compilation generates 1 extra mem segment(4,5) when the ratatui crate is present which makes the bootloader fail (rom_index < 2):

ESP-ROM:esp32c6-20220919
Build:Sep 19 2022
rst:0x15 (USB_UART_HPSYS),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x4080082e
0x4080082e - __EXTERNAL_INTERRUPTS
   at ??:??
SPIWP:0xee
mode:DIO, clock div:2
load:0x40875720,len:0x16b8
load:0x4086c110,len:0xe90
load:0x4086e610,len:0x3054
entry 0x4086c11a
I (23) boot: ESP-IDF v5.4.1-426-g3ad36321ea 2nd stage bootloader
I (23) boot: compile time Apr 29 2025 15:14:17
I (24) boot: chip revision: v0.1
I (24) boot: efuse block revision: v0.3
I (28) boot.esp32c6: SPI Speed      : 80MHz
I (32) boot.esp32c6: SPI Mode       : DIO
I (35) boot.esp32c6: SPI Flash Size : 4MB
I (39) boot: Enabling RNG early entropy source...
I (44) boot: Partition Table:
I (46) boot: ## Label            Usage          Type ST Offset   Length
I (53) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (59) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (66) boot:  2 factory          factory app      00 00 00010000 003f0000
I (72) boot: End of partition table
I (75) esp_image: segment 0: paddr=00010020 vaddr=42000020 size=00100h (   256) map
I (83) esp_image: segment 1: paddr=00010128 vaddr=40800000 size=00050h (    80) load
I (90) esp_image: segment 2: paddr=00010180 vaddr=42000180 size=20334h (131892) map
I (122) esp_image: segment 3: paddr=000304bc vaddr=40800050 size=00014h (    20) load
I (122) esp_image: segment 4: paddr=000304d8 vaddr=420204d8 size=2773ch (161596) map
I (155) esp_image: segment 5: paddr=00057c1c vaddr=40800064 size=0134ch (  4940) load
I (158) boot: Loaded app from partition at offset 0x10000
I (158) boot: Disabling RNG early entropy source...
Assert failed in unpack_load_app, bootloader_utility.c:777 (rom_index < 2)

https://github.com/Hectorban/esp_hal_mousefood_esp32c6/tree/main

[j-g00da]

Hey again, I decided that it would be good to test mousefood with esp32 no_std too, e.g. using esp-hal with embassy, but I'm struggling to compile the project once again, this time it returns an error in kasurai, do you have any idea how to fix that?

Update:
It will be soon possible to use ratatui on targets without atomic instructions: ratatui/kasuari#30

Tried with the esp32c6 and got what i think is memory alignment/size issues. The compilation generates 1 extra mem segment(4,5) when the ratatui crate is present which makes the bootloader fail (rom_index < 2)

Sadly no idea about this one right now.

[suri-codes]

Tried with the esp32c6 and got what i think is memory alignment/size issues. The compilation generates 1 extra mem segment(4,5) when the ratatui crate is present which makes the bootloader fail (rom_index < 2):

Just ran into this one today as well, I can try working on it but looks pretty strange.

Definitely don't think it's a size issue, esp_flash tells you how much flash it'll use.

[iamadahn]

@j-g00da I have finally tested new commit without framebuffer that you provided and so far everything works flawlessly, I was able to use full 480x320 resolution with just 128kb of heap for everything, while before it was like 256kb of heap for 480x60.
But there is a problem, at first I tried to use the latest commit and I wasn't able to build the project, there is an error for some reason after you've bumped the version of thiserror crate:

error: failed to select a version for `thiserror`.
    ... required by package `ratatui-core v0.1.0-alpha.6`
    ... which satisfies dependency `ratatui-core = "^0.1.0-alpha.6"` (locked to 0.1.0-alpha.6) of package `mousefood v0.2.1 (https://github.com/j-g00da/mousefood?rev=1def4cb2f62a1ba55991996d4a45e1835c698c9e#1def4cb2)`
    ... which satisfies git dependency `mousefood` of package `iamui v0.1.0`
versions that meet the requirements `^2` (locked to 2.0.12) are: 2.0.12

all possible versions conflict with previously selected packages.

  previously selected package `thiserror v2.0.16`
    ... which satisfies dependency `thiserror = "^2.0.16"` of package `mousefood v0.2.1 (https://github.com/j-g00da/mousefood?rev=1def4cb2f62a1ba55991996d4a45e1835c698c9e#1def4cb2)`
    ... which satisfies git dependency `mousefood` of package `iamui v0.1.0`

failed to select a version for `thiserror` which could resolve this conflict

[j-g00da]

Thanks for letting me know!

Btw. Can you share a photo of mousefood running on a bigger display? :)

[iamadahn]

Sure

[iamadahn]

@j-g00da I've encountered a strange issue, if I try to build the project in release mode I have a strange errors in ratatui-widgets and ratatui-core:

error[E0061]: this method takes 0 arguments but 1 argument was supplied
    --> .cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ratatui-widgets-0.3.0-alpha.5/src/block.rs:1084:14
     |
1084 |         self.style(style)
     |              ^^^^^ ----- unexpected argument of type `S`
     |
note: method defined here
    --> .cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ratatui-core-0.1.0-alpha.6/src/style/stylize.rs:17:8
     |
17   |     fn style(&self) -> Style;
     |        ^^^^^
help: remove the extra argument
     |
1084 -         self.style(style)
1084 +         self.style()
     |

error[E0308]: mismatched types
    --> .cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ratatui-widgets-0.3.0-alpha.5/src/block.rs:1084:9
     |
1083 |     fn set_style<S: Into<Style>>(self, style: S) -> Self::Item {
     |                                                     ---------- expected `block::Block<'_>` because of return type
1084 |         self.style(style)
     |         ^^^^^^^^^^^^^^^^^ expected `Block<'_>`, found `Style`

It happens even if remove everything from [profile.release] in Cargo.toml

[orhun]

Hmm there seems to be a version incompatibility somehow 🤔

Some things you can check:

• Run cargo tree -i ratatui-core and cargo tree -i ratatui-widgets to see which versions are pulled in.
• Ensure that your Cargo.lock does not pull wrong versions.

[iamadahn]

Yes, you are right, I deleted cargo registry to redownload all crates and now everything builds correctly, ty for help

[Hectorban]

Got a ST7796 320×480 working with a esp32. Needed to use the IBM437_9X14_REGULAR font and the disabled framebuffer for it to run with the limited heap:

[memark]

Just wanted to chime in here as well. After a (long Christmas) weekend of tweaking, I'm now up and running on a Raspberry Pi Pico! Thanks a lot for this crate!

(Atm using a hacked version of the deprecated st7789 display driver, getting the modern mipidsi driver working is the next step.) Done.

[j-g00da]

Great! I'll try to clean some things up and release a new version with ratatui 0.30 and no-std support by the end of January :)

[iamadahn]

I guess it's time to close the issue, the dream is now true. However, I wonder if there is way to use touch input with mousefood, is there a way to somehow detect which widget is being pressed?

[j-g00da]

Converted this into discussion instead of closing the issue.

You know the area in which you are rendering the widget, so it's a matter of mapping touch screen coordinates to widget coordinates, absolutely doable. Beyond the scope of mousefood, or even ratatui though, as we leave input handling entirely to the user and/or third party libraries.

[iamadahn]

Thank you for the response, somehow I discovered links to projects built on mousefood only after asking this question and turns out that https://github.com/Julien-cpsn/Phone-OS is a great example of mapping touch screen coordinates to widget areas

[j-g00da]

Short answer: Yes, this is usable in no-std environments starting from mousefood 0.3.0 and ratatui 0.30.0 (January 2026)