shared memory and loading savings

Wouldn't you also have to be extremely careful to keep stack usage to approximately zero, which is a big step beyond merely not using a heap? I expect almost none of the no-alloc crates are designed with that constraint.

When you're trying to strictly limit stack usage, I'm not sure Rust is a good fit - something simple like assigning to a static struct will conceputally construct a temporary value on the stack then memcpy it into the static, and you're relying on the optimiser to turn that into direct writes to the static's memory, and sometimes the optimiser won't cooperate and you'll overflow your tiny stack.

If I remember correctly, I tried this a while ago and it stopped optimising away the stack allocation when the struct size exceeded maybe 8KB. If you neatly contain all your application state in one big struct that's more than half your RAM, and try to dynamically initialise it, that's a problem. You have to write ugly, unidiomatic code and then hope the optimiser cooperates. It's easier to avoid implicit stack allocations in C, and in such a small program with no dynamic allocation and no threading you don't need the memory safety benefits of Rust, so it doesn't seem a good tradeoff.

(By the time you get up to, say, 256KB of RAM, you're not going to be accounting so carefully for every byte and you'll probably have a real heap and an RTOS, and then I think the tradeoff flips the other way and Rust is much more appropriate.)