Chibios based runtime for Rust

[davidji]

There's an existing project which targets a board I have:

https://github.com/neykov/armboot

But it's approach is deprecated now - rust has built in support for null runtime environments. And anyway, I'd rather not start from scratch.

Is anyone thinking about doing this?

Cheers
David

[TexZK]

I don't know this language. What's the purpose of using it on a MCU instead of C++?

[genosensor]

http://www.rust-lang.org/

I'm no fan of C++
And, I really like what the Rust developers are attempting in their clean slate design.
However, their stated focus is on "programming in the large"
How many applications running on the microcontrollers targeted by ChiBiOS and its ilk qualify as "programming in the large"?
Further, for most parts, there's not enough RAM available to support the dynamic object creation and garbage collection intrinsic to Rust.
And, even when there is, making it all happen in constant time will remain a challenge.

[davidji]

I'm not interested in debating the benefits of Rust over C++: these forums are likely to have a large confirmation bias in a particular direction, but I it's worth pointing out:

- the memory management in Rust is optional, and the project I linked to doesn't provide it.
- there are no intrinsic down sides for supporting programming in the large. Re-using code without having to edit it is of benefit in almost any context.
- the way memory is managed in Rust, on a per thread basis, makes it a lot easier to do garbage collection: the thread root can be treated in isolation, so you never have to stop the world - only stop individual threads.

So the interesting thing about Rust is that for the parts of your code where a GC pause is too slow, you can choose not to use it, but still safely interface with the parts of your code where it's convenient to have it, and that where you do want GC the design makes predictable GC pauses a lot easier. Check out Metronome TS. It gives predictable pauses, and it's targeting a much harder problem.

Rust also has an integral concurrency model, which means code which requires concurrency is portable between systems, which I think is of great benefit in an embedded environment.

[TexZK]

You're talking about GC. Does it generate a swamp of pointers? I think GC requires too much memory overhead at runtime, while the best MCUs nowadays have 256 KiB of SRAM (often split into banks with different capabilities). Performance-wise there should be no problems as you describe it, but memory-wise it may generate a lot of overhead in the heap, because of heavy use of pointers and counters. Anyway, good luck

[davidji]

In memory, Rust promises it's record types are bit compatible with C on that platform - that means any C data structure has a Rust equivalent. How many pointers there are is up to you. Rust has a neat safe version of C's & to create references to things which aren't managed objects: the compiler checks you don't mutate the referenced object while the reference exists, so you can use in-lining of other peoples types if you want. An object becomes managed through boxing (yes Rust overloads the term), which is orthogonal to the type.

There's no need to do reference counting: a many paged copying scheme would work perfectly well for Rust. This is how Metronome achieves it's results. I am interested in developing a GC along these lines, but I think that would be the last thing to tackle. Better to try and do something in Rust without it, first.

[TexZK]

Thanks for the summary It looks interesting, maybe for the platforms available in the near future, or at least with SDRAM.

I still consider GC a technology which puts allocations/deallocations under the carpet, perhaps not much more than the classic heap, considering the allocation features you referenced. BTW, I hope C++11 will become the default C++ version in the near future, it's too much sexy.

[davidji]

I'm not sure what SDRAM has to do with it: GC has reached the point where you can guarantee you give up no more than half your memory, and half your CPU to achieve a maximum pauses of 250us. This is in the realm of real time, and its probably possible to do much better with Rust. Certainly people use Chibios to do things that are no more real time than this. I could buy an STM32F303 for £3.09 or an STM32F407 for £5.73. The difference in price buys you 2.5x the mips, and 6x the memory, so the upgrade gets you GC, and then some.

People do useful things with STM32F303s, otherwise ST couldn't sell them. So by extension, you can definitely do the same useful things using STM32F407 in a language that uses GC.

Development with GC gets you a correct program faster, because it eliminates a lot of possible errors, and lets you re-use code without modification (assuming it exists in the first place, which obviously is a chicken and egg problem). Either the saving justifies the hardware cost, or it doesn't. That mostly depends on volume. Since nearly everything I do is a prototype, buying the next biggest microcontroller, and choosing a higher level language with GC would always be a no-brainer for me, assuming that's available.

The amount of SRAM will go right on increasing with the transistor count, doubling every two years, so ever more applications will be developed more cost effectively with GC.