One of the great things about software, compared with hardware, is the ease with which it may be changed and updated. The big downside of software is also the ease with which it can be changed. This ease can make software developers lazy, as they know that they can always fix things later. This is a sharp contrast to chip developers who are fearful of errors, as an ASIC respin is both time consuming and very expensive.

On a desktop computer, updates to system and application software seem to come thick and fast, giving vendors the opportunity to provide us with new features, fix old bugs and introduce new and interesting ones. For embedded systems, the matter is a little more complex … (more…)

I always find it satisfying to see simple solutions to apparently complex problems and the world of embedded software certainly lends itself to some creativity. My concept of “simple” is quite broad, but essentially encompasses anything that is easy to understand [for me] and ideally avoids reinvention of any wheels.

A while ago, I wrote about incorporating a Web server [HTTP server actually] into an embedded device so that information might be displayed on any connected Web browser. Along the same lines, I have been thinking about using email … (more…)

In almost all modern embedded systems, memory is organized into bytes. CPUs, however, process data as 8-, 16- or 32-bit words. As soon as this word size is larger than a byte, a decision needs to be made with regard to how the bytes in a word are stored in memory. There are two obvious options and a number of other variations. The property that describes this byte ordering is called “endianness” [or, sometimes, “endianity”].

Broadly speaking, the endianness in use is determined by the CPU. Because there are a number of options, it is unsurprising that different semiconductor vendors have chosen different endianness for their CPUs. The questions, from an embedded software engineers perspective are “Does endianness matter?” and “If so, how much?” … (more…)

In my last posting, I illustrated the use of C++ to encapsulate the necessary coding nastiness of dealing with write-only ports. However, one aspect of the solution was not addressed: the proposed code was not reentrant … (more…)

I recently wrote about write-only ports and discussed how they worked and the challenges presented to software developers who need to program them. The solutions proposed were quite straightforward, but the challenge remained to ensure that all the code utilizing the ports complied with the requirements.

I commented at the time that there are several ways to mandate the correct handing of write-only ports, but an approach that interested me was the use of C++ … (more…)

First up, please remember that I am a software guy, not a chip designer. Please read this posting with that in mind.

I was chatting with someone at a conference recently and they planted an idea in my brain. I am not sure what to do with the idea, so I thought that I would exercise it here. The topic was the consideration of power consumption in embedded systems – a subject I have written about before, but this was a new angle … (more…)

I often joke that my job puts me in a difficult position, as I am a software guy and a very large proportion of Mentor employees are hardware design specialists; I am consorting with the “the enemy”. Although I am making a light-hearted comment, there is, sadly, something of an “us and them” attitude between software and hardware teams in many companies. It is in everybody’s interest to make this a thing of the past.

Sometimes, it seems as if this view is reasonable, when hardware seems to be designed specifically to make life hard for software developers … (more…)

I like simple things. In particular, I like clean and simple ways to solve a problem. For example, user interaction with an embedded system might be something very slick – touch screen LCDs seem to be fitted to everything nowadays. But sometimes a simple LED indicator is enough. It is amazing how useful a simple blinking light can be … (more…)

Nowadays, most embedded systems are built using 32-bit CPUs. These devices give plenty of scope for performing the arithmetical processing required for various applications. Calculations can be performed on signed or unsigned integers and 32 bits gives a good range of values: +/- 2 billion or up to 4 billion respectively. Extending to 64 bits is reasonably straightforward.

If you need to stray outside of these ranges of values or perform more sophisticated operations, then you need to think in terms of floating point and this presents a range of new challenges … (more…)

Most of the time, I subscribe to the view that “the only stupid question is the one you did not ask”. However, I do have trouble with a question that I have been asked countless times at trade-shows, seminars etc. The question is “How much memory does Nucleus RTOS need?”

It is not that this is a stupid question. It is very sensible to be fully aware of resource utilization with deeply embedded systems. The problem is that I am rarely sure how to give a meaningful and useful answer, so I resort to generalities and this is often viewed with suspicion. The reason for this is that the answer is dependent upon a great many variables … (more…)