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.

  • Mark says:

    Not to sound like a broken record, but I’m loving D in the embedded space. It has a lot of power, but still is incredibly efficient. People have even gotten it to work with a debugger or two out there, like the BDI2000. Check it out if you haven’t already:

    • Job Vranish Job Vranish says:

      Yeah I looked at D. I didn’t include it in the above list because AFAICT it can’t yet run without an OS and the runtime is too big. Though please correct me if I missed something.
      The D toolset seems to be quite a bit more mature than other options. If D could run on bare metal I’d seriously consider giving it a shot :)

  • Sam says:

    One word: Forth.

    The more things change, the more they stay the same…

  • Matt Wilbur says:

    Nice post.

    I tried Forth for quite a few months and gave up (I mean, I seriously tried). At first I loved it, and dang is it small. But it is just so different than anything else, I found it was hard to move back and forth between, say Ruby on my desktop and Forth for a project.

    I’m currently driving a project using Lua so I can get non-embedded SW people to do scripting on bare-metal for factory POST and BIST. Including the REPL and lexer, Lua is biggish, but I can get it <256k on a PPC (and even better on ARM with thumb). Additionally, there are unit testing frameworks for lua already (though I'm just digging them up this week).

    Matz gave a presentation on an embeddable Ruby.

    I'm gonna check out D.

  • Matt Wilbur says:

    Forgot to mention, a company from Quebec (Deep Object Knowledge) is working on a language called B# which has C#-like semantics but has a very small footprint.

  • Potato says:

    Hi, I’d like report an its/it’s typo on line 5.
    I feel the Internet has way too many of these.

  • Dear embedded developers,

    For those interested in small footprint embedded systems, our next public release (this fall) of the B# language will be in synch it with our upcoming book on it. The latter will express and clarify several major additional features that need to be documented.

    B# (pronounced “be sharp” — is a new object-oriented programming language designed explicitly for the development of small footprint embedded systems. It embraces modern programming techniques without compromising speed, memory, size, and simplicity. It directly supports interrupt handling, address device registers and multi-threading without dependency on third party compiler or RTOS vendors. Coupled with a compact virtual machine, B# code is easily ported and reused across multiple hardware platforms. The virtual machine written in ANSI C takes only 24KBytes Flash and requires a minimum RAM of 2KBytes! In short, the B# language has been built from the bottom up with the embedded system developer in mind. It helps to emulate, test, and debug virtual device drivers on host as much as possible.

    Best Regards,

    Michel de Champlain, Ph.D.
    Chief Scientist
    DeepObjectKnowledge Inc.


    “The B# language is a personal project to introduce modern programming techniques to the embedded system programmer who like me, has sought a better way to develop applications which are portable, reliable, and reusable and who does not wish to sacrifice size, speed,
    and simplicity to do so. Begun nearly 25 years ago, B# and its virtual machine have evolved over the years to meet these criteria with the ongoing support of seminar participants, colleagues, and industry.

    I understand and empathize with the programming frustrations of the embedded system programmer. I hope that my efforts go a long way to making the implementation of small footprint embedded systems a more pleasurable and productive pursuit.”


    — Michel

  • Alberto Ruiz says:

    You should have a look at Vala.

    It is a C#-like language with a static reference-counting memory management system. It basically targets the C/GObject API and therefore it produces C code that can be generated and debugged using the standard C toolchain (as long as GLib/GObject is compiled for it).

    It has been used in several middleware components in MeeGo such as Rygel and Tracker for exactly the same reasons that you describe.

    • Jakob Eriksson says:

      Good look porting Gobject to a 112 kilobyte RAM computer with no OS.

  • Philip White says:

    An alternative to a different programming language is a greater emphasis on design, and code autogeneration from design. This can be done using a modeler like QM, which has you develop UML statecharts, executing your own code in state transitions. Add to it the QP framework, which uses the actor model, and requires as little as 1-2KB of code and just several bytes of RAM. (According to its web site.) With the combination of QP/QM, you can develop complex software using your choice of C/C++, but with great design, way fewer bugs, and easy debugging/tracing.

  • Karl Lam says:

    We’re currently developing a new language we are tentatively calling V#. It’s based on C#, but we aim to provide both hard real time capability (in the sense of a guaranteed latency) and automatic garbage collection in the same language. This page describes what we are trying to do:

  • Comments are closed.