It is becoming common for embedded designs to incorporate more than one CPU – maybe multiple cores on a chip or multiple chips on a board or any combination of these. Indeed, it has been suggested that it will soon be the norm to build systems that way.

The use of multiple cores has spawned various technologies and, of course, much terminology and jargon. When new technical terms and acronyms appear, there is inevitable misuse and misunderstanding. This seems to be the case with AMP and SMP, so maybe I can set the record straight … (more…)

Many microprocessors and microcontrollers incorporate a memory management unit (MMU) or have one available as an option. Equally, there are some devices that have no MMU support and many systems are built without one anyway. Having met some engineers recently, who could not conceive of the idea of no MMU, clarification may be necessary … (more…)

Power consumption is an issue. With portable devices this affects battery life. [I am irritated by the short intervals between necessary charging sessions with my smartphone, for example.] With mains powered equipment, power consumption is also a concern for environmental reasons. The matter of power has always been seen as a “hardware issue”, but, of late, there has been an increasing interest in the role of software … (more…)

Last time, I wrote about a “multi-core” project that I was working on 30 years ago. To be fair, it was actually “multi-CPU” rather than “multi-core”, but many of the challenges were similar, as was the initial design decision to take the approach of distributing the processing capacity. It is interesting to draw a comparison between the system that we were developing all those years ago and modern ideas for multi-core design. A common approach is to use one core for real time functionality (running an RTOS like Nucleus perhaps) and another for non-real-time activity (maybe running Android or Linux).

Using multiple CPUs (or cores) presents a variety of challenges. One is the division of labor, which was reasonably straightforward in this case. Another is communication between the processors … (more…)

Sometimes I think that there is nothing truly new in the world. With technology, it is often a question of the time being right. It occurred to me that the current enthusiasm for multi-core designs is really nothing new. I browsed some of the literature and titles like “Multi-core is here now” have been appearing for at least 5 years. But it goes back further still. I was working on a multi-core system in 1980 … (more…)

The term “real time” is widely used nowadays. Although it is a technical term, it finds its way into quite normal conversation. I might be heard to say “I do not watch much real-time TV”, meaning that I record programs to watch at my convenience. So, colloquially, real time means “immediate” or “occurring now”. How does this align with its precise meaning when we refer to a real time operating system, for example? … (more…)

The idea of inlining code – placing the actual code of a small function at each call site – is a well known compiler optimization, which I have discussed before. This technique can provide significant performance improvements, due to the elimination of the call/return sequence. Also, stack usage is reduced. There is a possible cost in terms of increased program memory requirement.

It is reasonable to expect a good C or C++ compiler, when told to compile for speed, to perform inlining automatically. Some C compilers have extensions to give more control over this, but C++ has intrinsic support for inlining within the language … (more…)

The computer world is often accused of being mired in jargon and I think that is a fair criticism. In some ways it gets worse when an everyday word is “hijacked” to have a new meaning. A good example is “program”, which had several meanings before it was applied to software. Interestingly, in the UK we use the US spelling (“program”) to refer to software, but retain the English version (“programme”) for everything else.

Another re-purposed word is “memory”, which is interesting because it has acquired a number of meanings in a computing context. Historically, the term referred to the place that a program and data resided during execution – it still does have this meaning. But it was also used to refer to bulk storage like disk drives. Even today, when someone tells me how much memory their PC has, I have to make sure that they are not telling me about disk storage. For embedded systems, memory has always been a term with a number of meanings … (more…)

There are two aspects of any product that give me great pleasure: good design and quality of manufacture. This applies to just about anything: a pair of shoes, a car, a house, a piece of software … Assessing both these parameters can be hard. A pair of shoes must look good, be comfortable to wear and last well; this takes time to evaluate. A car needs to be enjoyable to ride in, drive well and offer long term reliability and economy; again, not something to be measured quickly. A house can be even more difficult, as you need to live in it through a full year of seasons at least and, even then, you may still be evolving the way that you use the space, which will establish how good the original design was.
(more…)

Life is often about compromise, but embedded developers really are not good at that. Code generation is a context in which compromise is somewhat inevitable and we call it “optimization”. All modern compilers perform optimization, of course. Some do a better job than others. A lot of the time, the compiler simply guesses which optimization will produce the best result without knowing what the designer really wants. For desktop applications, this is OK. Speed is the only important criterion, as memory is effectively free. But embedded is different … (more…)