I was writing recently about my fondness for RPN [Reverse Polish Notation] and this reminded me of a programming language, designed specifically for real time and embedded applications, which has largely been forgotten: Forth. It is interesting to look at how Forth worked and the benefits it offered for embedded developers. I am not proposing that the language be revived and used for new developments, but I think there are valuable lessons to be learned.

My attention was originally draw to Forth when somebody told me that there was a programming language which facilitated the generation of code using less memory than an assembly language implementation of the same functionality. I did not believe them, but it hooked me in …

(more…)

Since the earliest days of computers, they have been used for real time control applications. In the 1960s and early ‘70s, it was common to use a small mainframe or a mini-computer to control machinery or instrumentation. These computers typically ran under the control of a specialized operating system, which was designed for real time use. Examples include RSX-11 and RT-11, which were used on DEC PDP-11 machines.

These “real time operating systems” were typically interactive and worked similarly to those used for data processing applications. An operator command would start, control and stop the real time application programs. They could also be configured to be “turn key”, so that switching on the computer would cause the OS to be booted, which would then start the applications automatically. With the advent of microprocessors and, hence, embedded systems, a new approach was needed … (more…)

I like simple things. Excessive complexity tends to annoy me. When I first started working with computers, I thought that mainframes were overly complicated, so I was pleased to discover minicomputers, where I could really understand exactly what was going on. Embedded software was a natural progression, as, again, I could grasp the entire functionality of the software. But that began to change, as commercial real time operating systems and other software IP became more common. Everything became more complex and invisible.

I am not saying that this situation is necessarily a problem or that all complexity is intrinsically bad. It is just that sometimes I yearn for the simple life. It might be suggested that perhaps the world of software is not the best place for me, but I will ignore those murmurings and consider where simplicity might still be appropriate … (more…)

I like being right. Who does not? I am also interested in programming languages. Part of their appeal is that, unlike almost all spoken languages, they have a precise definition or specification to which implementers endeavor to comply. Many languages, like C and C++, have ANSI/ISO standards, which nail down many of the details. These standards tend to be imperfect and aspects of the language can remain rather insecure, as implementers have too much latitude. This is why organizations such as MISRA publish detailed usage guidelines to avoid the problem areas. C++, in particular, gives some interesting opportunities to write obscure code, which I have written about here before.

I was concerned, when I first started to learn C++, that there was a flaw in the language. Some years later, I got the whole story … (more…)

I have pondered for some time the appropriateness of Linux for embedded applications. My initial stance was clear enough: I could see very little sense in it. Why use a desktop operating system in such a completely different context? Over the years, the popularity of embedded Linux has increased, the technology of embedded systems has moved on and I have reappraised my views accordingly. I thought it was worth revisiting the philosophical debate … (more…)

When you use a function in C/C++ (or most other programming languages) you are likely to pass it some parameters – data which may be processed by the function or give it information on what action is required. For the majority of programmers, outside of the world of embedded software, parameters are just a fact – no real issues. They are likely to be quite uninterested in how parameters are passed and how efficient and secure that process that might be. Embedded developers tend to want details. Efficient code is essential and avoiding possible bugs is always desirable. So, maybe a look at how parameter passing actually works might be useful … (more…)

I have a very basic question for you: what do you do and why do you do it? It is quite possible that, if you are reading this, you are an embedded software engineer. It is interesting to consider what that job actually entails. First off, how would you reply to the “What do you do?” question from someone you meet in a pub/bar? You would probably say Software Engineer, but they might ask you to expand on that. [Actually, such a reply can be a complete conversation killer. You might be better to reply with Airline Pilot or some such. Just invent a new persona and have some fun.]

It is easy to think of an embedded software engineer’s job as being all about writing code that programs a device to behave in a particular way. But that is a long way from the whole story… (more…)

I have always for medical electronics interesting. Part of the reason for my interest stems from an occasional feeling that so much of the electronics around me is ultimately pointless. Many Mentor Embedded customers are making consumer devices, cell phones and other gadgets. Do we really need all of these? Aren’t they really just toys – harmless toys, but toys nevertheless? (Except for my iPad, of course, which is a positive influence on my productivity and overall wellbeing.) Worse still, some customers are actually making weapons and they are not harmless at all!

However, we have many customers who make medical devices. I only have to look at a medical instrument and I have a warm feeling inside that maybe electronics can do some real good. The other aspect of medical instrumentation, that I find intriguing, is the extent to which its implementation clearly tracks the latest trends in embedded system development … (more…)

What is a compiler? Ask an average engineer and you will get an answer something like: “A software tool that translates high level language code into assembly language or machine code.” Although this definition is not incorrect, it is rather incomplete and out of date – so 1970s. A better way to think of a compiler is: “A software tool that translates an algorithm described in a high level language code into a functionally identical algorithm expressed in assembly language or machine code.” More words, yes, but a more precise definition.

The implications of this definition go beyond placating a pedant like me. It leads to a greater understanding of code generation – and just how good a job a modern compiler can do – and the effect upon debugging the compiled code …

(more…)

I often get emails from students asking me how to get started in a career in embedded software. I have to assume that they think that this is a path to a well-paid job and a corresponding glamorous lifestyle. I would hate to disillusion someone who is just setting out on life. I guess that I had great expectations too.

I am never able to give detailed advice on what to do and just comment that embedded software engineers actually come in several flavors. At one extreme, they are engineers with a deep knowledge of hardware and only do a bit of software when necessary; such skills are ideal for developing drivers and other low level code. At the other extreme, there are programmers who have no idea about embedded systems, but are focused on the application domain; their skill set is not very different from a software engineer working on applications for Windows or Linux. And, in the middle, are guys who understand real time behavior and real time operating systems.

(more…)