Pragmatic Bare Metal Rust | Hacker News Reader

Pragmatic Bare Metal Rust

hashmismatch.net

138 pointsjakobdabo33 comments

We really need a less ambiguous phrase than bare metal for this, because searching for "Bare Metal Rust" really isn't going to get you the results you want here.

I searched for "Bare Metal Rust" and got relevant results. "Metal Rust" is an issue though. :)

I think Google partitions people into categories, so if you have searched a bunch of programming related stuff previously, it changes the weighting for the rust programming language.

I'm a metallurgist (materials engineer) who does a decent amount of programing I don't have a hope...

OT: does your programming relate to your materials work? what a metallurgist needs programming for? serious question, genuinely interested!

Yes: I work in an industrial plant, mostly doing numerical simulation work. I work at the smelting end rather than the "real" metallurgy part.

My day to day work largely involves maintaining and improving various process models (largely written in C or Fortran) which feed into our operating guidance systems.

There already is a term: freestanding. A program that can be executed without a runtime or an operating system present. Bare metal refers to software that runs natively on the "bare metal", as opposed to with an interpreter.

Author here, pun totally intended. Sorry. :)

Bare Metal Rust +microcontroller

I tried a Google search in an incog tab as an experiment, most of the first page results were relevant. Seems like reasonable terminology given that test.

Even 'Rust' is a bit difficult to google for. Easier than Go, but not that much easier! We need an equivalent convention to golang

Well, the website is rust-lang.org, and `rustlang` will get you what you want nearly all the time.

Very cool, thanks for sharing the info on using rust bare metal!

I'm really curious to try running rust code on the popular ESP8266 module (http://makezine.com/2015/04/01/esp8266-5-microcontroller-wi-... and http://www.esp8266.com/), but I think the board's xtensa architecture and LLVM's lack of support for it means its a non-starter. If anyone is a LLVM guru, is there any hope of compiling code for xtensa architecture and ABI? Or is there any crazy way to get LLVM to compile rust into plain old C code that can then be compiled with the modified GCC toolchain that supports the ESP8266's xtensa architecture?

I was just looking for a solution to get Rust on the esp8266 this weekend. Neat little devices.

Rust can emit to LLVM-IR via `--emit llvm-ir` when compiling your Rust program, but I think the IR that gets produced isn't platform agnostic.

Yes, LLVM IR is inherently not portable.

This is awesome, surprised the author isn't using libopencm3[1] rather than ST Micro's pretty horrendous library. But the awesome thing is that between this and Zinc I expect there will be a lot of interest in Rust on "high end" embedded platforms.

[1] Disclosure I contribute to that repo when allowed to :-)

I wonder if there's a reasonable to bind the c++ mbed to rust - it would be quite a useful tool.

Binding C++ in Rust is significantly more complicated that binding C.

Binding C++ in anything is significantly more complicated than C :)

Observe:

http://source.winehq.org/git/wine.git/blob/master:/dlls/msvc...

This is great! I've been thinking about doing something like this with Rust for a while. Anybody have experience using Zinc.rs[0] in a similar capacity?

[0] https://zinc.rs/

If you are looking into Zinc, there is a newer version of it here at https://github.com/mcoffin/zinc/tree/new-build

If I'm not wrong, it will be merged with the official version soon.

That is the hope, since master is currently out of date.

I have been working with Matt Coffin some on getting this working. Feel free to increase its chances of merging by helping us test any of the supported boards (Freescale K20, NXP LPC17xx, SAM3x (on a branch), STM32F4, STM32l1, TI Tiva C).

I plan on putting together an RFC for how we can modify zinc (or provide documentation) to make it easier for individuals to create both libraries and projects that work well with zinc, but do not require modifying zinc itself.

Zinc looks very promising. Will it fit on the Arduino Due, which is an ARM system with limited memory?

Yes, I believe so. The binaries I have built so far have been very small (<2KB for a blink example). mcoffin has a branch with SAM3x support, which appears to be the processor on the Due: https://github.com/mcoffin/zinc/tree/sam3x

The Due has 512KB of room for code which is quite a lot (for microcontrollers).

2KB to blink LEDS? seriously? this needs to be on the order of a few ten of bytes to be competitive...

It probably can be lowered by manually linking and similar stuff.

See: http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-...

That depends on what's in there. My understanding is that that 2Kb is not so much overhead as required dependencies. Dependencies that most real applications would probably end up pulling in anyway, like a dynamic memory allocator.

The end of the market with tiny micros and extremely simple applications (like just blinking LEDs) is likely to never be well suited to Rust, but doesn't gain much from it anyway.

A few points:

* I don't think a few tens of bytes is realistic for a real application that needs to set up the stack, timers, and then blink some LEDs (https://github.com/mcoffin/zinc/blob/new-build/examples/app_... / https://github.com/mcoffin/zinc/blob/new-build/examples/app_...)

* Assuming the code size overhead does not continue to bloat after some initial overhead, I think rust can still be very competitive. Although modern embedded systems are still very constrained, the days of 8-bit micros are basically over. You can buy a 32-bit ARM micro for nearly the same cost with sufficient RAM/Flash to run rust well.

* Looking back, I think the size of blink should actually be closer to 600 bytes. Will need to investigate: http://zinc.rs/stats/

This could be big in safety-critical firmware business.

Some utility to assist bulk conversion from C to Rust would be nice. That way Rust-based firmware could be reality in 2025. :-)

> Some utility to assist bulk conversion from C to Rust would be nice

One of the problems with this is that Rust's guarnatees usually really affect your design. I'd imagine that a bulk C -> Rust translator would have to use `unsafe` all over the place.

Doesn't mean that it wouldn't be useful, but I wonder if slowly replacing APIs bit by bit isn't a better approach overall.

Yeah, the ease and mostly-cost-free nature of C-Rust interop is a really big selling point, as you can pretty much just drop Rust in piecemeal to replace your legacy libraries.

I think the better approach here is to phase out existing applications in chunks. You can link call rust code from C (when externed and rustc is told not to mangle) and C code from rust (via ffi).

My experience with code automatically converted has not been good.

Reply on news.ycombinator.com