Monolithic or not
All my working life, I have had a challenge with explaining to people what I actually do. It all starts with defining what is an embedded system. As I have discussed before, 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.
Comments
Leave a Reply
You must be logged in to post a comment.
Colin, I’ve noticed a trend over the last !10 years of so, based on conferences, customers, forums, etc.
There was a time when a lot of “low level” guys (I’d count myself in that group) – often Electrical Engineers or Computer Engineers – would also learn how to develop “higher level” software, usually on the job. Pretty much everything I learned about version control, software design & architecture, real-time multitasking, OOD & OOP, and a multitude of languages (C++, Perl, Python, etc.) were all learned by necessity at work, or in my own time.
Nowadays it seems that many companies are moving their “application programmers” down into working on their embedded products. And the mistakes are pretty predictable – lack of understanding of “volatile”, inability to consider/estimate memory, CPU and power usage, no ability to read and/or step through assembly code, etc. These developers are no more suited to do embedded work than I was to write anything above a driver. I’ve seen of these guys make the jump, and some fail.
I think the issue is that we’re all lumped into the same big basket by upper management – “programmers”, or perhaps more accurately, “programming resources”, and we’re viewed as being interchangeable. I mean, isn’t writing VHDL the same as writing Javascript for a shopping cart? (insert smiley here)
Depending on what level you’re working at, there is definitely some skill re-use and task overlap, but I don’t think I could slip right into a Java Enterprise developer role. Similarly, I think a Web 2.0 AJAX coder would be terrified to sit down at my lab bench and debug an interface problem between a microcontroller and a DSP. I think the wires, LEDs, test equipment and assembly listing in the debugger window would be enough to send most people running.
I gravitate towards difficult problems and projects (safety-critical systems, resource-constrained systems, low-power systems) because those require both a “big picture” perspective and a lot of attention to detail – keeps me on my toes. You can’t make a system rock-solid safe, or reduce its overall power consumption, without understanding how the pieces fit together as a whole, but you also have to be able to drill down and “dot every I” and “cross every T” to accomplish the final goal.
Good input Dan. Thanks.
The metaphor I use to describe what I do (working with low-end embedded systems) is that I program invisible computers. When someone looks at them, they don’t see a computer. They see a pipe bender, or an exercise machine, or a traffic light.
I think that is a very good way to phrase it Steven.