There has been a lot of emphasis lately on switching from eight-bit to 32-bit microcontrollers, but little attention has been given to an equally important change in the embedded software world. The availability of ever higher-level programming languages is just as significant as the change in hardware.
Like MCU hardware, software has become more versatile. The ability to compile microcontroller code in C, for instance, allowed for code that was more reusable, easier to understand, and less tied to a microcontroller than assembly code. Though this code is better for engineers to work with, it generally has poorer performance than assembly, due to compiler imperfections.
Now that 32-bit microcontrollers with faster clocks, more RAM, and more storage are becoming commonplace, is it time again to move to a more powerful language? How about C++?
Most of the big Cortex-M compilers, including Keil, IAR, and CrossWorks, can compile C++, but you don't often see it used in example code or public projects. Some of the most popular, easiest-to-use development systems, such as MBed and Arduino, are based on C++. So why hasn't it drawn a broader audience?
The biggest advantage of C++ is that it allows object-oriented programming but does not necessarily force it. In fact, a C++ compiler will compile just about any C code. This allows engineers to use as many of the C++ features as they feel comfortable using without having to learn the entire language at once. Code written in C++ is also more elegant and readable, because objects are easier to trace and understand than discrete functions.
Look at the following example of code that initializes a UART and sends one character. The first block is written in C with STMicro's Standard Peripheral Library. The second block is written in C++ with the MBed library.
STMicro's Standard Peripheral Library code for initializing a UART and sending the letter A.
MBed code for initializing a UART and sending the letter A.
If you had to explain what each line of this code did to someone who doesn't code, the C++ snippet would no doubt be easier to explain, because it uses more English and less syntax.
The object-oriented approach of C++ also makes code safer and more reusable. Using classes for data structures instead of structs allows the engineer to hide vulnerable pieces of data and retain more control over what functions can act on data. Classes also allow for inheritance. In C, if several modules use the same function, you usually have to copy and paste it between modules and accept the larger code size. In C++, you can write a class that contains the shared code, and the modules can inherit this common code.
The object-oriented approach could change the way engineers think about problems. Things that connect to microcontrollers, such as sensors or LEDs, can be modeled as objects instead of a loose framework of functions. You could create a standard set of microcontroller peripheral objects (such as an SPI object) with defined methods (such as read, write, and an interrupt method) that could be implemented on any microcontroller using those peripherals. This way, if an SPI-based EEPROM driver were written in C++ and contained the standard SPI object, the driver code would be completely decoupled from the target processor and could be retargeted without changing a single line. Making code modular is no new concept, but C++ facilitates modularity by treating objects as things that can interact, instead of functions that can interact.
Like everything else in engineering, C++ is a tradeoff. It is possible to save engineering hours by using object-oriented coding, but this may increase program size or decrease program performance, so it may require a more expensive target. As more powerful microcontrollers become available, though, are embedded engineers taking full advantage of their power? If Arduino uses C++ on an eight-bit 24MHz processor, why shouldn't more engineers use this powerful language while developing professional systems?
As an analogy, compare two-, three-, or four-blade cartridge razor systems with double-edged safety razors. Even though double-edged safety razors are much cheaper and generally provide a closer shave than cartridge razors, they take much longer to use and are less safe if you don't know how to use them. A vast majority of people have switched to cartridge razors for the time savings and convenience.
Now that the cartridge razor of programming is available for microcontrollers, perhaps it is time for more people to embrace a switch to C++. If you have used C++ for embedded systems, how was your experience? If you still haven't tried C++ for microcontrollers, what is holding you back from switching?
Tweet This
