Colin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor … More »
May 16th, 2016 by Colin Walls
A common compiler optimization is the inclusion of a function’s code at the location(s) from where the function is called, instead of just having calls to the code located elsewhere: inlining. This provides a speed advantage, as the call/return sequence is eliminated, but may increase the memory footprint, if the function is more than a few instructions and is called more than once. I have written about this topic before, here and here.
I have an enduring interest in code generation and compiler optimizations and my consideration of inlining was piqued by a recent comment on one of my earlier posts. I realized that there are two implementation related aspects of inlining which are particularly relevant to embedded software developers …
April 18th, 2016 by Colin Walls
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 …
March 15th, 2016 by Colin Walls
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 … Read the rest of RTOS deployment
February 15th, 2016 by Colin Walls
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 … Read the rest of The one line RTOS
January 14th, 2016 by Colin Walls
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 … Read the rest of C++ at fault
December 15th, 2015 by Colin Walls
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 … Read the rest of Embedded Linux – why?
November 16th, 2015 by Colin Walls
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 … Read the rest of Function parameters
October 15th, 2015 by Colin Walls
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… Read the rest of Why write code?
September 16th, 2015 by Colin Walls
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 … Read the rest of Electronics for the sick
August 17th, 2015 by Colin Walls
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 …