From Zero to Main(): Bare Metal Rust

A fun alternative way to play with Rust on bare-metal, is <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-console&#x2F;gba" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-console&#x2F;gba</a>, which is a Rust crate for writing (unavoidably bare-metal) homebrew for the Gameboy Advance.<p>See the second half of <a href="https:&#x2F;&#x2F;rust-console.github.io&#x2F;gba&#x2F;bitmap-video.html" rel="nofollow">https:&#x2F;&#x2F;rust-console.github.io&#x2F;gba&#x2F;bitmap-video.html</a> for an example of what code using the gba crate looks like.<p>Tangent: IMHO, the GBA is a nearly-perfect platform to get started with bare-metal programming on. It&#x27;s not painfully-constrained like the 8-bit micros of old, but it doesn&#x27;t have any extra layers of abstraction like virtual memory, either. Plus, multimedia IO (drawing to the screen, playing sounds, reading buttons) are all just banging bits, similar to using POKEs in BASIC on an Apple II, which makes for immediate gratification, important for younger learners. <i>And</i> you can run GBA software through emulation on pretty much any device you own; with there being some <i>excellent</i> visual debuggers available as well for Windows&#x2F;Linux.

Great blog post. It&#x27;s been wonderful to see rust take off in the space and the approaches the folks in the embedded wg and ecosystem have come up with. The cortex-m starter projects, embedded-hal tying the ecosystem together, and various intro books like &quot;discovery&quot;. I never would have thought I would explore anything this &quot;low level&quot; but rust has opened those doors for me.

This is great and I love Rust, but<p>&gt; However, when working directly with the hardware, which has no knowledge of Rust’s guarantees, it is necessary to work in Rust’s unsafe mode, which allows some additional behaviors, but requires the developer to uphold certain correctness guarantees manually.<p>If the whole code will be wrapped in unsafe blocks, then what is the point of using Rust?

<p><pre><code> xxd target&#x2F;thumbv7em-none-eabihf&#x2F;release&#x2F;from-scratch.bin | head -n 5 00000000: 0000 0120 dd00 0000 0000 0000 0000 0000 ... ............ 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ </code></pre> &gt; Reading this, our initial stack pointer is 0x20100000, and our start address pointer is 0x000000dd.<p>I see the pointers in the top line, but is this a standard feature of objcopy&#x27;s binary format? Are the pointers the stack and entrypoint always at the beginning?

I implemented firmware for very specialized AC motor speed and torque control that also does whole bunch of other things on a very low end microcontroller. Was implemented in C. Out of curiosity I just dug into source code and tried to imagine how it could benefit from Rust. Frankly the benefits would be none. As for safety: this firmware something like 6 years in production with just a single update. And the update was not made because of the bug. Somewhere along the way bunch of parts was ordered for new devices and wrong letter code was used. So instead of receiving 2% tolerance on part it was now 10%. As the order was expensive and not returnable I modified firmware to account for this.

Semi-related: are there any good recommendations for Rust-based RTOSs. Bare metal is great, but for a lot of projects you&#x27;ll want some sort of scheduler.

&gt; Rust does have one additional requirement for a bare metal program: You must define the panic handler.<p>What would panic? Who is doing (and where) the <i>panic</i> checking? Since no additional libraries are being used, is the <i>panic</i> checking in the core library?<p>What is the overhead of <i>panic</i> checking?

There are some issues I have with using Rust for bare metal work:<p>- “zero cost” abstractions end up compiling to lots of code&#x2F;code that does weird things that can cause cashe thrashing and&#x2F;or pipeline misprediction. In C the cost of everything is very explicit, in Rust it’s very easy to end up with an inefficient binary. The low correspondence between Rust&#x2F;C++ and machine code is unattractive when doing bare metal work.<p>- unsafe blocks seem to defeat the purpose of Rust. It’s like building a proof on top of lemmas that are just random guesses.<p>- Clean builds of my test project are very slow.