Power management is a hot topic – or maybe that should read “a cool topic” – among embedded developers of late. In the course of a recent conversation on the subject, I realized that there are, in effect, three kinds of power saving procedure that embedded software might effect:

1. Use dynamic voltage and frequency scaling [DVFS] to tune the CPU performance to the needs of the moment.
2. Disable [power down] currently unused peripheral circuitry.
3. Make use of the CPU's low power modes. (more…)

A majority of embedded devices nowadays are implemented using an operating system of some kind. This has not always been the case and need not be today. Historically, using an OS was less common mainly because the applications were less complex and CPUs less powerful.

Some thought is needed, at an early stage in a project, to determine which OS to use [or whether to use one at all] … (more…)

A common question I get is about the use of pointers in C and whether it is OK to store the value of a pointer [i.e. an address] in an “ordinary” variable – like an unsigned integer .. (more…)

Some technologies, it seems to me, should not really exist. They do, however, because they address a specific need. Typically, such technologies stretch something to make it perform in a way that was not originally intended. An example would be the fax machine. In a paper-based office environment, there was a frequent need to move documents from A to B. Initially, this resulted in the mail. But fax was an ingenious way to use phone lines to deliver a similar result. As soon as email became widespread, fax disappeared almost overnight.

The technology that I have in mind today is hypervisors, which are a software layer that enables multiple operating systems to be run simultaneously on a single hardware platform. They have been used for decades on mainframes, more recently on desktop computers, but are now beginning to be very relevant to embedded developers … (more…)

Stuff goes wrong – it is a fact of life. Embedded devices are typically very reliable, but not immune to failure. A common failure mode is a lock-up – the device freezes and will not respond to any user interaction. This could be caused by either a software or a hardware problem. A device might perform a self-testing and software can sometimes preempt its own failure.

But freezes happen, and what do you do? … (more…)

On desktop computers, data that you are working on right now, in an open application, is most likely just stored in RAM. When you are finished, the information is saved to disk for more permanent storage. That is the way it is for word processing, spreadsheets etc.; databases are bit different. The idea of having volatile memory for temporary use – where a power failure can cost you a morning’s work – and disks for persistent data is widely accepted. The only thing that is changing is the use of flash memory to build solid state drives [SSDs] instead of rotating magnetic disks.

Embedded systems seem to have similar needs, but there are key differences … (more…)

My Portuguese is limited. Well, non-existent actually. Last time I was in Portugal, finding myself in restaurants where no English was spoken, it was a matter of selecting things rather randomly from the menu or pointing at other people’s plates. When I first saw the name Lua, it made me think of the Hawaiian greeting “Aloha!”, but then I found out that its meaning was “moon”.

But really, it is a scripting language … (more…)

Recently, I wrote about self-testing possibilities for embedded software, where the goal was to detect and mitigate the effects of hardware failure. I commented that software failure was also a possibility. That is a topic worthy of further consideration … (more…)

Things go wrong. Electronic components die. Systems fail. This is almost inevitable and, the more complex that systems become, the more likely it is that failure will occur. In complex systems, however, that failure might be subtle; simple systems tend to just work or not work.

As an embedded system is “smart”, it seems only reasonable that this intelligence can be directed at identifying and mitigating the effects of failure … (more…)

Developing embedded software used to be easy. Actually, that is not true. It has never been easy, but certain matters were simpler. Embedded developers have always needed more control of code generation because, as I am often heard to chant, every embedded system is different, and the priorities and requirements change from one to another.

It used to be broadly a choice between speed and size of code, but it is no longer that simple … (more…)