#![no_std] about mio HOT 11 CLOSED

Can you say a bit more about what requirements you have that require #![no_std]?

from mio.

If one were to make an stdlib replacement, with IO handled at a deep level by mio, it would be odd to depend on libstd instead of libcore.

from mio.

As of now, I am going to keep the std dependency.

from mio.

Can we revisit this? If we can get mio to work without std (obviously reducing the available feature set) then we can "easily" start implementing threading for microcontrollers through one of the coroutine libraries

from mio.

I'm not familiar w/ the micro controller case. If there is no std, what will drive Poll? Could you help me figure out how something like that would work?

from mio.

I'll play around some with mio to understand its internals. I'll come back with an answer once I've done that.

from mio.

This is an old issue, but I would just like to register my interest in seeing this happen. Because there are many lower power ARM cortex micro controllers (for example STM32 platform and others). Which simply do not have enough program memory for STD. So in the embedded world being compatible with no_std is an important thing. Especially for lower power applications. For example smart watch, IOT devices, remote sensors.

It's a great question to look into. Because most web frameworks require tokio. Which in turn requires Mio. Tokio has a tracking issue for this.

from mio.

@dreamcat4 Mio currently has a shim for unsupported targets, so that takes us a step closer. However one major blocker is io::Error I believe, is there am alternative for that?

from mio.

We probably could define our own error type as a wrapper around io::Error. That isn't a big problem IMO.

That said, @dreamcat4 how would you impl non-blocking IO on ARM cortex controllers regardless of mio?

from mio.

A great question...

Uhm forgive my naiivety here, if my general idea / approach is wrong in any way. But I was hoping to go with RTIC, which has been developed for STM32 family of embedded MCUs.

Did a quick search in RTIC docs just now... and here are the places where RTIC already exposes interrupts:

https://rtic.rs/0.5/book/en/internals/interrupt-configuration.html
https://rtic.rs/0.5/api/rtic/index.html?search=interrupt

I myself have not gotten around to play with anything Rust at all just yet. Just researching this general topic whilst trying to get debugging working for STM32 embedded. So... here I am trying to see what the current limitations are. Which places might have some underlying roadblocks. Hopefully that explanation makes some kind of sense to you guys.

As I don't have much time to learn new languages and ecosystems. So if embedded rust is a worthwhile option then it makes the choice of rust overall more compelling (a higher value). More bang-for-my-buck in terms of learning time invested. And reducing the number of new platforms to learn by n=1. Since rust is also great for other types of of development outside of embedded.

In fact embedded applications are like clincher for rust. Because nearly all of the other modern options for (something other than 'C', for getting better memory management)... Others all have much more expensive runtimes. Which then in turn isn't going to shrink down / fit onto the lower end embedded MCUs. And of course because runtime garbage collection usually ends up messing with RTOS guarantees. Which rust doesn't seem to have so many problems with. At least in principle, and also if using no_std to avoid the std runtime.

from mio.

@dreamcat4 if you or someone else is willing to write code to support Mio in some form on no_std platforms I would be ok with it. But currently it doesn't seem useful to turn this is into a no_std crate without actually supporting an implementation. If someone is starting to work on this feel free to open a new issue or a w.i.p. pr with any questions.

from mio.