Needed: A Better Language for Embedded Systems Programming

The C programming language is currently the accepted industry standard for embedded programming. Occasionally you’ll get C++ or Ada, but the vast majority of work in the field is C. For applications that don’t require interfacing directly with hardware, developers have, for the most part, abandoned C in favor of languages that are more expressive and less error prone. However, C remains a popular pick in the embedded world due to its extremely low overhead, control over memory management, performance, and easy access to physical hardware.

While C provides the control needed for embedded programming, It would be nice to be able to use a more modern language. I find that most of the bugs I encounter would either not even be possible or would be much easier to debug in a more modern language. A more expressive language would also just make a programmers life easier in general. Unfortunately, most modern languages are unsuitable for embedded development. Embedded systems have some pretty harsh requirements. For example, the current microprocessor I’m working with runs at 80Mhz and has only 112KBytes of RAM total. Imaging trying to get a language like Ruby or Haskell to run in 112K! It is not uncommon that we have to work with even less. Often we do not have an operating system and need to handle things like concurrency manually.

Fortunately, it turns out there are a few possible alternatives. So far, I’ve found bitC, Cyclone, Habit and Timber.

• bitC and Cyclone are relatively similar. They are both C-like languages (though bitC has a significantly different syntax) but with some higher level constructs and compile time protections against segmentation faults.
• Habit is a very interesting language that has a lot of potential. It attempts to have more the feel of Haskell but to be able to run in the real time constraints of an embedded system. The main objective is to make it easy to use automatic provers to verify properties of Habit programs. Unfortunately they do not have a public working implementation, yet.
• Timber is a functional language which centers round a reactive event based concurrency system with timing constraints (very handy if your application is highly concurrent).

All of these languages are a vast improvement over C. They all have strong static typing with type inference, compile time checks that reduce or remove segmentation faults and lots of expressive higher level constructs and they do it with performance that is within a percent or two of C. While these languages are still fairly immature they at least demonstrate that it’s possible to have a safe and expressive language without sacrificing control or performance.

There is, however, one major roadblock preventing me from using these languages at work. I am often forced to use the complier and tools (think debugger) provided by the chip vendor, which almost always only support C. If I were to use an alternate language it would have to compile to C, but not just C, readable C. I need to be able to use the (vendor supplied) C debugger. I  would need to be able to debug the C output and be able to follow along in the original source. This doesn’t seem like an insurmountable obstacle however. Hopefully one of these languages, or perhaps a new one, will provide such capabilities in the near future.