Raspberry Pi Bare Metal Programming with Rust (opens in new tab)

After having played around with Rust a bit and seeing it used in some non-trivial applications I've grown to like it a lot, despite being an initial skeptic. However it's aggravating that in every post about Rust which raises valid criticisms about the language (in this case having to do with the ease with which C allows you to do low level programming), those associated with the Rust project leap to its defense and suggest that Rust's decisions are right for every situation.

Just because Rust can't easily do things that C can doesn't make it a bad language, but it does mean that, shockingly, there are somethings that Rust isn't as well positioned for as other languages are.

Similarly, there are things that C is bad at. Both at the high level and the low level. At the low level it hides too much of the CPU's features so for some very low level programming you need to drop to assembly. At the high level it has obvious deficiencies, many of which Rust addresses, but for interfacing with the actual hardware it is tough to beat C in terms of convenience.

Whilst having to debug this is still undesirable, I recommend trying `rr` (http://rr-project.org/) to track this if you're ever in such a situation. It's as simple as setting a watchpoint and reverse-continue-ing!

I don't do much C/++ these days, but when I do (and it's a large codebase which is hard to debug), `rr` is invaluable. It works with Rust too.

Exactly. I saw the gp comment and feared there was lots of boilerplate, arcane incantations -- and the only slightly smelly thing in the (IMNHO) beautiful and short example is the use of an empty asm block to "fight" the compiler on optimizing out the busy loop.

I can't imagine the full C example for this is any prettier or easier to follow?

[ed: As for "no name mangling" - having such an easy way to turn it off when needed, and yet avoid collisions when you do need it seems pretty good to me. Perhaps just having something that's "extern" be umangled by default would be better -- but it's not like one needs to bend over backwards to get a "mostly safe" bare metal program here.]

> Has hello world ever been exciting

The HN upvote says otherwise. :-)

But I guess had there been an HN-equivalent in assembly age people would get excited about C, too.

> The question is what does Rust have to offer as your embedded program grows.

Exactly.

We are aware of the good, bad and ugly bits of C. The industry has built extensive tooling around it. Rust has a long way to go. I certainly wish to see more pioneering projects from Rust.

zinc.rc is certainly interesting. Thanks for sharing!

> Even in Linux if you access the Pi's GPIO registers directly you can toggle pins in a tight loop at around 1-2mhz.

Careful, this is strongly dependent upon the hardware, not Linux.

I seem to recall that people doing SWD programming can barely get the GPIO's to move faster than a couple of KHz.

I can tell you that, at least on the BeagleBone Black, you have to do some Linux driver voodoo to get better than a couple of KHz.

Edit: I stand corrected. Apparently the Broadcom chip in the RPi does much better than the TI one in the BeagleBone Black when driving baseline GPIO's.

Excellent, thanks!

So GPIO performance won't be a problem, but they note that OS multitasking can cause issues:

"What is not evident from the snapshots, however, is that due to multitasking nature of Linux, the GPIO manipulation is constantly interrupted for short periods when the CPU is doing something else, such as receiving or sending data over network, writing log files, etc"

Running on bare metal should take care of that, so the only remaining problem is how to synchronize the signal generation on the RPi with the recording of data on the host computer. (Sigh, if only RPi had a USB3 port...)

That's true, the reason I mentioned the RPi was because I happen to have one lying around. (Actually, I seem to remember there are a couple of AVR development boards lying around in the lab, so these might be worth a look.)

My project involves generating two analogue signals to drive a mirror (a sin wave on the x-axis and a staircase pattern on the y-axis), and a synchronized digital trigger signal for the camera. There are a number of configuration options that make this slightly more interesting than it looks at first (frequency, number of sin periods per staircase step, duty cycle and number of triggers per sin).

An implementation of this on a NI DAQ took the better part of a day and an implementation on a FPGA took roughly two weeks (mostly spent on familiarizing with the tools and communicating settings from the host.) I actually think an implementation on the RPi would be simpler than either, including wiring up simple DAQ.

I wouldn't recommend an AVR. That is outdated technology. Even Atmel mostly makes ARM microcontrollers now (and they are much nicer than their AVR ones).

Or a Parallax Propeller

>maybe go in the future

Go is not going to replace Java in the future. For a language which cannot even lock dependencies to a version, people sure like to pretend it is the holy grail because Google made it.

The first release of D was in 2001. That's 15, not 5, years ago.

Could you list which packages you tried to use which were blocked on a nightly? In many cases a package can be moved off nightly with trivial changes, I can try to do it.

I see the point you're trying to make, yet:

- Nobody in their right mind would choose Rust or Javascript for a project where the other is more appropriate.

Though (AFAIK) Scala and Clojure both interop quite well with Java, and Scala/Clojure interop isn't terrible either, plus there's definitely a culture of reusing in Clojure/Scala all the stuff that the Java ecosystem already had. So this cluster isn't causing much fragmentation at all.

You have something of an argument that Go and the JVM languages clash for mindshare, but at that point the argument around really annoying fragmentation has kind of lost steam.

I can't stand JS and Go syntax, I tried a few times... This is the worst thing that happened to humanity after in XXI century. I feel more comfortable with Prolog than with JS.

Don't forget to add Nim to that list! One of Nim's defining features (compilation to C) makes it work rather well for this sort of thing.

I think he was asking which languages could actually be used to do this today, without writing a new cross-compiler first.

And C++, surely? (Although, I would probably choose C (or even assembler) over C++ for something this simple (loop, blink a light). And between all those, I think Rust is really interesting.

It could probably be argued that Rust doesn't add much on top of D (as a "better" C++) -- but between the mind-share and the focus on "safe" (and boxing in unsafe) memory access, I think Rust is really interesting. Not sure how run-time free D is coming along - believe there were some issues with the standard lib?

Ada was troubled by a confusing split between FSF LGPL Gnat trailing Ada Core GPL/commercial compiler with a release -- leaving people a little confused if there was a good Free Ada compiler that could be used for commercial (or just non-GPL) development. (Yes, it was a real issue, just as one needs an LGPL libc for c development etc).

But as I understand it the GNAT compiler has matured to the point that one can now use modern Ada without having to worry about that. Unfortunately Ada probably lost a lot of potential developers due to the confusion/issue.