Monday, January 16th, 2017
I have often talked about the process that might be applied to the selection of an embedded operating system and I hope that I can provide some guidance. However, developers tend to stick with a specific OS [or, at least, with a particular OS vendor] – recent research suggested that only about 20% of developers anticipated a change of OS for their next project.
I started thinking about why there is this apparently high degree of loyalty … (more…)
Thursday, December 15th, 2016
I am often asked questions about embedded software. Sometimes they are complex; other times they are simple. But frequently, the simplest ones are what leads to an interesting train of thought. The one that set my brain working recently was something like this: “I have some non-volatile memory in my design, which is used to retain specific parameters through power cycling. The first time the device is used, the memory contains garbage and needs to be initialized. When the software starts up, how can I detect that this is the first time it has executed and an initialization sequence needs to be run?”
My first thought was to suggest that simple inspection of the data would show whether it was valid or not. In some applications, that would certainly be true. In others, perfectly valid data could look like a jumble of ones and zeros. There must a be simple, reliable way to make it clear that the memory/data has been initialized … (more…)
Tuesday, November 15th, 2016
I was recently approached for help by a Mentor Graphics customer, who was planning a new project and needed to select an operating system. They wanted guidance with that choice. Of course, one is tempted to say that it does not matter which of our products they chose (as, between them, Nucleus RTOS and Mentor Embedded Linux do cover most possibilities), but I felt they needed something more objective.
There is actually a huge choice. Given that it is decided to purchase an OS, instead of developing something in-house (an expensive option which rarely makes sense), there is the choice between the “heavyweight” OSes, like Windows CE and various flavors of Linux, and around 200 other, mostly real time (RTOS), products. What the customer was after was a simple decision driven process, like a flowchart … (more…)
Monday, October 17th, 2016
I have frequently written about various aspects of USB and presented many seminar and conference sessions on the topic. I find it interesting that, considering that USB is such a straightforward technology for most users to utilize, its deployment in devices can be quite challenging.
A particular area of confusion is USB Class Drivers. The word “class” is very overloaded in the software world – it has numerous meanings. And the term “driver” is far from precise. So, it is unsurprising that the subject provokes discussion … (more…)
Monday, September 19th, 2016
Mentor Graphics has historically been dedicated to providing tools for electronic hardware designers and that still represents a very large proportion of the business. Ever since I was acquired into the company, I have found that the hardware focused guys have a healthy interest in software – embedded software in particular. Often, they are specifically concerned with the boundary between software and hardware … (more…)
Monday, August 15th, 2016
A constant challenge I have found, when teaching or mentoring people, is to avoid making assumptions about what they know. I have found that it is so easy to assume that, because something is obvious to me, it is clearly apparent to everyone else. On numerous occasions I have discovered that this not to be the case. Of course, the best response to this realization is not to treat everyone else as stupid, but try to explain something clearly and then listen to the echo back of the explanation.
In developing software – embedded software in particular – there are certain things that are fundamental, particularly around the conservation of resources. More than once I have been surprised by engineers’ inability to focus on this issue … (more…)
Monday, July 18th, 2016
Something that I have discovered over the years is a great pleasure. When I am giving information – presenting, teaching, writing an article or a blog – it is not necessarily a one-way process. I often receive useful and interesting information back. I have commented that I learn as much from delivering a class as I might from attending one.
I was recently talking about C++ for embedded at a conference and considering some of the features that I felt resulted in better, clearer and more bug-free code. One of these was the option to pass parameters by reference. Then someone explained a drawback of this feature …
Thursday, June 16th, 2016
I am [mostly] a fan of using C++ for embedded applications. I believe its use needs care, but broadly, I feel that it offers many simple improvements over C and appropriate use of object oriented techniques can be very beneficial. Today I want to talk about the place of C++ as a “better C language”. There are numerous syntactical improvements that can be leveraged to make code just a little more readable and maintainable.
However, there are some minor “quirks” that can catch the unwary programmer. Who would have thought that you could go wrong with a plain old for loop? …
Monday, May 16th, 2016
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 …
Monday, April 18th, 2016
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 …