Monolithic or not

All my working life, I have had a challenge with explaining to people what I actually do for a job. It all starts with defining what is an embedded system. This is by no means easy. I thought that this might become simpler over time, as embedded systems become even more ubiquitous, but the reverse is true. The definition is getting even fuzzier.

It has reached a point where software engineers do not necessarily know whether they are working on embedded systems or not …

There are two reasons why it may be unclear [or of no concern] to a software engineer that they are working on an embedded system:

First, software teams have grown drastically in recent years, as systems have become more complex and the code content increased massively. That growth is not simply the addition of more programming “power” – it is not a question of just applying more brute force to write more code. Increasingly, developers are specialized. Some are likely to be “real” embedded engineers, who are comfortable working close to the hardware; others may get no closer than an RTOS API; some application specialists will not even be aware that an RTOS is in use, so their programming context is much like that of a desktop software developer.

The second reason is that many embedded systems are built using desktop-derived OSes, like Linux, and [some] RTOSes are becoming more like desktop OSes. The difference used to be clear. A desktop OS was a stand-alone entity, which was booted up when the machine started. Applications were then started and stopped, as and when required. An embedded OS was bound to the application code as a single, monolithic executable entity; when the device was switched on, the application code began to run [under the control of the OS]. Embedded Linux works in a similar way to its desktop relation: it boots and the application code is then loaded [from somewhere] and started. A facility for the dynamic loading and unloading of application modules is now available for many embedded OSes, which changes the programming paradigm.

So, that explains the confusion. But does it matter? I think it does, because “true” embedded software engineers are not only skilled in the low level stuff, they are very adept at squeezing the last bit of performance out of hardware. Desktop programmers attitude is that they have infinite memory and CPU power to play with. This could be one reason, at least, why my phone spends more time on charge than it does in my pocket.

This entry was posted on Tuesday, April 18th, 2017 at 5:53 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.