We've been actively working on stabilizing #![no_std], as well as making cross-compilation easier. In the future, ideally, you'll just need

    $ cargo build --target thumbv7em-none-eabi

instead of

    $ rustc -C opt-level=2 -Z no-landing-pads --target thumbv7em-none-eabi -g --emit obj -L libcore-thumbv7m -o runtime.o runtime.rs

or other shenanigans. You can run that Cargo command right now, but you still need to do a little bit of work first.

Nice! Any pointer to a documentation / wiki explaining how to use it ?

"it" being --target? https://github.com/rust-lang/rfcs/blob/master/text/0131-targ... is the original RFC. Off the top of my head, I think that's it for now. Since cross compilation is getting easier in the future, I haven't invested a lot of time into writing docs now.

Very nice. When this gets cleaned up, and Rust stabilizes a bit more, it should be promoted for the Arduino Due. The Due is a minimal ARM machine, a step up from the Atmel CPUs but well below the level required to run Linux.

Safety at the Rust level is very valuable in embedded work. Debugging small embedded machines is not fun.

In my opinion Arduino Due are overrated. They are pricey, their processor isn't really top-tier and you don't get a builtin JTAG probe for debugging (I think).

You should try ST's discovery/nucleo boards. Much cheaper and ChibiOS (www.chibios.org) has some nice API and examples to get started.

Handy to know; thanks for the heads up!

I agree. I wonder though - why all the rust projects go bare metal, instead of integrating a c based RTOS using rustbingen ? Seems like the fastest way to get cross-platform, which is key for many developers - and speed rust's adoption - making bare metal much easier.

I think rust people wants to proove repeatedly the addded value of their language : "no cost abstraction over bare metal" because it is the thing that will win the heart of their audience. Still, in practice, it will likely play as you say, but not now.

A C based rtos inherits all the difficulties present in C. Ideally Rust is interesting, to me, as an ideal language to write the RTOS itself in. Once you get through the low level details, writing a (simple) schedule system is not hard and would be more flexible due to the better types safety in Rust. Also C is difficult for DSLs, Rust should be better. That's the dream at least.

>> A C based rtos inherits all the difficulties present in C.

Can you please expand on that, especially assuming(a big assumption) that the c code you're interfacing is high quality , with rare bugs ?

Even assuming the existing code is high quality, there is still a lot of problems with pointer ownership and type checking which Rust removes.

Personally I think the best way is to wrap existing C code into higher level, safer Rust APIs.

Exactly, even the most disciplined code base will have errors. Rust type system "automates" the process that many well designed C code bases will do by convention (e.g. borrowing and keeping ownership localised).

While wrapping C libraries in safer Rust APIs is useful for many application, having something as fundamental as time-sharing, task interruption, etc would be much better if written in Rust and care is taken to define simple semantics for the system (e.g. like the recent HN post regarding state-machine based asynchronous IO in Rust).

author here. My RTOS of choice (ChibiOS) uses a lot of function like macros which are not supported by rustbindgen. Other RTOSes such as FreeRTOS or UC/OS-II would be easier but they don't provide drivers, making them less interesting.

If anybody has experience with writing C macros to rust bindings I would be interested in hearing about it.

I know that chibi OS is funded by ST(for developing a version for their automotive line of automotive mcu's). Hence why it's only limited to ST platforms(still that's a lot of variety at great price).

Maybe they'll be interested in funding rust development? it might give them some competitive advantage, some amount of control of a possible future platform, i.e. rust.

I did not know that ChibiOS was funded by ST. I thought they only worked on FreeRTOS (CHibiOS is not limited to ST's MCUs).

Hooking into an RTOS doesn't really give you much cross-platform ability: most RTOS only give you a scheduler and synchronisation primitives, not any drivers. The closest thing to a a cross-platform RTOS I know of is chibiOS, and it supports a fairly low number of platforms.

Rust does look promising for embedded applications. Ideally, I'd like to be able to use it to program Pebble applications. I managed to get a simple executable written in rust to write to the screen a few months ago, but haven't been able to get even slightly more complex things to work. Hopefully the hard work of rust devs will make this easier in the future.

How would they make it easier?

Erm, see steveklabnik's comment on this story. It is sort of a complex process right now in that you have to build libcore yourself and then try to link everything together (for me, that mostly involves trying something and then crossing my fingers, because my knowledge of that level of tooling is limited). I've heard several times that rust devs are hoping to make cross compilation easier.

This is going to be interesting. Rust on top of rumprun bare-metal unikernel https://twitter.com/gandro23/status/645734117699624960