-
Notifications
You must be signed in to change notification settings - Fork 708
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#![no_std] #21
Comments
Can you say a bit more about what requirements you have that require |
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. |
As of now, I am going to keep the std dependency. |
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 |
I'm not familiar w/ the micro controller case. If there is no |
I'll play around some with mio to understand its internals. I'll come back with an answer once I've done that. |
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 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. |
@dreamcat4 Mio currently has a shim for unsupported targets, so that takes us a step closer. However one major blocker is |
We probably could define our own error type as a wrapper around That said, @dreamcat4 how would you impl non-blocking IO on ARM cortex controllers regardless of 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 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 |
@dreamcat4 if you or someone else is willing to write code to support Mio in some form on |
To be truly close to the metal, stdlib must be dropped. Drop stdlib. :)
The text was updated successfully, but these errors were encountered: