Moore’s law is well known in the electronics industry; it states that the number of transistors roughly doubles every two years. Since 1965 Moore’s law has proven to be true and the capabilities of digital electronics has enjoyed an exponential growth in capability. The embedded systems industry has greatly benefited from the growth in capabilities with once cumbersome 8-bit microcontrollers being replaced by modern 32-bit capabilities. With the industries focus on hardware growth, the drastic increases in capabilities and the way in which firmware is being developed is largely being overlooked.
Since the dawn of the first computers, firmware has always been necessary to run the switching the component of the hardware. Firmware can be thought of as the yin to the hardware yang; they need to coexist with each other. In the early days firmware was developed and stored on punch cards. An example can be seen in Figure 1. The firmware was written to be functional with reuse or modularity not needed or possible.
Figure 1 – IBM Punchcard (Image Source: Wikipedia)
As the hardware capabilities evolved to include programmable flash, firmware moved from the tedious punch cards to being stored as binary information that could be loaded onto the microcontroller. Despite this leap in storage capabilities the firmware itself remained simplistic and functional. Right around 1973 the first version of the C programming language came into existence, which is still the primary programming language for embedded software.
The way in embedded software in the 80’s and 90’s was developed began to drastically change from a process and procedural point of view. As far as the firmware and the embedded system itself went, the software was nearly always developed from scratch and developed in a functional and non-object oriented way. Reuse and modularity was rare but slowly techniques were development that did allow for reuse and for very robust firmware to be development.
At the turn of the century and into the first decade, the way in which firmware was developed began to change rapidly. Even though the C language was still the primary tool for the embedded software developer, code was no longer written to just be functional but instead reusable. Modularity and reuse began to take center stage as development costs and consumer demands for product features began to rapidly rise. Developing firmware from scratch every time was no longer an option.
The way in which software is being developed today is silently going through a revolution due to the embedded software challenges facing developers. Microcontroller technology has evolved to the point from both an architectural speed and storage space standpoint that firmware developers can employ advanced development techniques. Code shouldn’t be written to be functional but instead use object-oriented techniques that maximize reuse, scalability and testability. The use of object-oriented techniques allows low-level firmware to be componentized and developed through either high level tools or through automated code generation. Using frameworks, components and layered architectural design patterns allow embedded software developers to abstract out the hardware and focus on the development of product features rather than focusing on how to make a peripheral perform the function it was designed to do. The shift to abstractions and high-level tools is silently revolutionizing the way that firmware is being developed. A decade from now firmware development may be nothing more than software integration, grabbing vendor and 3rd party components and meshing their APIs together to form a final system. Firmware design may seem to evolve much slower than its hardware counterpart, but the way in which firmware is being developed is going through its own silent revolution.
Originally Published 2015 on EDN.com
Keep an eye out for MicroPython. It can displace everything else.
What follows, is a decade from now, or perhaps much sooner, firmware will reach the abysmal level of unrealiability and instability that the garder variety monkey code reached 10~15 years ago. Now consider the already historical achievemen of 100+ million lines of (de facto) firmware code in a car. As Boeing incident shows, even the aviation industry is succumbing. In a world that runs on code, unreliability and unstability so effectively achieved by ever increasing abstraction and layering of development tools means a catastrophe that is not even a little an overstatement or metaphore: firmware-saturated things will fail, break, fly apart or go up in flames. As new firmware development paradigm silently turns into norm (and it does), skills inevitably get lost due to natural replacement of old programmers with new coders. So in ten years or so, as graybeards retire, one may not be able to source a programmer capable of producing quality firmware for critical infrastructure or reliable designs — at any price.
That is the aftermath of any revolution: it kills its children.
Thanks for the comment. It’s certainly poses potential threats to the quality, cost and development times. It’s interesting that we write almost all our embedded software in C, yet C is not taught at the university and developers are forced to learn it on the fly in the field. Microcontrollers are also becoming so complex that you almost need a Phd worth of education to really understand all the details. Thanks again for the comment!
> Keep an eye out for MicroPython
Or Javascript with Duktape. The async functions are so much nicer, compared to these dreadful RTOSes
MicroPython is an interesting solution, but under the hood someone still needs to know how to write C. You also can’t write a MicroPython application without first having a processor with over 384 kB flash, 128 kB RAM and additional flash for script storage. In time, the cost for the extra processing will be trivial but in today’s design cycle with decent volumes MicroPython can be overkill. (Plus there are security and other concerns with MicroPython as well)