The Rust Programming Language: Saving Us From Digital Oblivion?

I’ve programmed embedded systems for most of the last 40 years. And of those 40, 30 were using C. (Oh My God…) C is like an old friend to me… but I’m growing restless and uneasy. I’m sorry C, but we’re growing apart. “What have you done for me lately?”

Restless? Because that’s a long time to do anything in one language professionally. Sure, I learned C++ when it first came out, and have used it off and on for various projects. I learned Java when it came out, and again have used it off and on… and then JavaScript.. Python… PHP (shudder)… a tiny bit of Objective C (egads, what a mess)… and just enough C# to muddle by on a contract.

But none of these languages can replace C in the kinds of embedded environments I make a living in: close to the metal, with no OS or a simple one. Sure, you can avoid the bad parts of C++ and use it, but to work well and reliably in an embedded system, you need to throw a lot of it out, and so what you’re left with are classes (which can be done using C structures and function pointers), and default parameter values (which can be helpful). OK, maybe a few other minor improvements. But it won’t be more reliable.

Uneasy? Because it’s REALLY HARD to write bug-free, secure, reliable C code. So many embedded systems are hackable or fail in the field due to coding errors. So many more take much longer to get to market than they should. And even more simply are flaky and unsatisfying to users and customers. How much of the backbone of this society depends on devices whose firmware is written in C? A frightening percentage are.

Sure, we can add more discipline to reduce the problem: better training, static code analysis, code reviews, coding standards, unit tests… but what if the language reduced this burden? What if it helped, rather than was part of the problem?

From what I’ve read, Rust could be an answer; there is a growing community adapting it to embedded systems. So, I’m currently reading Rust Essentials, and will play around with the Teensy port as a starting point.

I have hope that Rust could be a way out for the embedded world to improve productivity, reliability, and security, and usher in the use of modern language constructs in the embedded world. We shall see.

GCC Mayhem

I tend to use gcc and gcc-derived tools quite often in my work; examples include the Arduino environment, LPCXpresso, and WinAVR. While not the best compiler in the world performance-wise, it wins hands down when you factor in its portability, ubiquity, and stability — as well as cost.

Sometimes weird stuff happens though. Recently I upgraded my main desktop machine from Windows XP to Windows 7. Since then, I have been unable to run any of the above toolchains successfully. What gives?

Turns out the problem was caused by a recent installation of a gcc toolchain, Ride7, from Raisonance, for the EM Micro 6819 processor family. That’s right, one gcc toolchain killed 3 others!

The solution (at least to make the first 3 work again) was to remove the GCC_EXEC_PREFIX environment variable that Ride7 created. Turns out that is a variable used in older gcc implementations that now causes havoc with newer ones. And Ride7′s gcc is OLD! 2.80! Current gcc versions are in the 4.3 range or higher.

Despite my initial fear that the trouble was Windows 7 itself, it turned out to be a combination of things — I never tried those other tools again after installing Ride7.