A significant factor in getting any job done properly is having the right tools. This is true whether you are building a kitchen, fixing your car or developing embedded software. Of course, it is the last of these that I am interested in here. I have been evangelizing on this topic for years (decades!). The problem is that there is a similarity – arguably superficial – between programming an embedded system and programming a desktop computer. The same (kind of) languages are used and software design techniques are fairly universal. However, there are really some major differences … Read the rest of Embedded tools – the third way

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 … Read the rest of OS migration

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 … Read the rest of Memory signature

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 … Read the rest of Choosing an embedded operating system

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 … Read the rest of USB – class drivers

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 … Read the rest of Device registers in C

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 … Read the rest of Shared code in embedded systems

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 …
Read the rest of C++ reference parameters – the downside

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? …
Read the rest of C++ – for loops

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 …
Read the rest of Firmly in line