Hacker News Reader

Comment by Animats | Hacker News Reader

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.

View on HN

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.

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.

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).

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).

Reply on news.ycombinator.com