Share this article:
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.
Colin’s most recent publication, Embedded Software: The Works is available now on the Elsevier Store.
Save 30% on his book and other Newnes Press and embedded systems books. Use discount code “STC317″ at checkout.
About the Author
You can read more about Colin and his work on embedded systems at The Colin Walls Blog at Mentor Graphics here. Connect with Colin online here:
Computing functionality is ubiquitous. Today this logic is built into almost any machine you can think of, from home electronics and appliances to motor vehicles, and it governs the infrastructures we depend on daily — telecommunication, public utilities, transportation. Maintaining it all and driving it forward are professionals and researchers in computer science, across disciplines including:
- Computer Architecture and Computer Organization and Design
- Data Management, Big Data, Data Warehousing, Data Mining, and Business Intelligence (BI)
- Human Computer Interaction (HCI), User Experience (UX), User Interface (UI), Interaction Design and Usability
- Artificial intelligence (AI)