It is a given that structured programming – in one form or another – is a Good Thing. For years, the spaghetti of GOTOs that arose in earlier programming languages has been abhorred by all right-thinking programmers. There are good reasons for this attitude. Firstly, structured code tends to be easier to debug and, second, the code is more readable and, hence, maintainable. Both of these are productivity improvements, so the GOTO should clearly be avoided.

But, what about the break statement in C? … Read the rest of Take a break – the break statement in

It is widely felt that C is a very good language for embedded applications, as it is expressive, compact and powerful. It is possible to write very clear, readable code, but that takes care. Even the simplest things, like the declaration of variables, have pitfalls for the unwary …

Read the rest of Variable declarations in C – plenty of pitfalls

As any software developer is well aware, the basic process for building an embedded application is quite straightforward. Normally, the code is written in some combination of C [perhaps C++] and assembly language and distributed across a number of files [modules]. Each module is compiled/assembled to produce a relocatable object module; this file contains the machine code instructions for the target processor, but with the memory addresses left open. The numerous object modules are then joined together using a linker [sometimes called a linker/locator], which resolves the memory addresses to the required final locations and produces the absolute file, which is an image of the final system memory.

That is the simple picture. There are other nuances, like incremental linking [where a number of relocatables are joined together to make another relocatable – linking, no locating] and object module libraries … Read the rest of Libraries – a good way to promote embedded code reuse?

As I write a lot of articles and publish videos etc., I often receive questions. As a result of a recent piece of Endianness, an embedded software engineer wrote to me. Read the rest of Questions on data representation

It is a very simplistic view, but, broadly speaking, there are two ways to design an embedded software application [or pretty much anything really]: either top-down or bottom-up. There are pros and cos of each approach and it is hard to say, in the general sense, that one is better than the other.

So much for design, but how development is approached is another matter … Read the rest of Why develop embedded software bottom up?

Away from my immediate professional colleagues, if I talk about my work, I am commonly asked questions like: What is an embedded system? Where can I see one? The answer to the first question can be framed in various ways – I just need to shy away from presenting a digital electronics or computer science 101; it is usually best addressed by reference to examples: mobile phone, washing machine, laser printer, etc. I normally address the second question by suggesting that my questioner imagine the start of an ordinary day. Wake up and cancel the alarm [embedded system #1]; put on the news on your smart speaker [#2]; prepare breakfast using the toaster [#3] or microwave [#4] or induction hob [#5] and coffee machine [#6]; eat your food while reading on your e-reader [#7]; get in the car to go to work [#8 …]. Before you leave the house, you have probably interacted with at least 6 embedded systems – it might be quite a few more. But, when you get into your car, things get very interesting … Read the rest of Automotive cockpit software consolidation

I have a very strong resistance to the practice of doing something [anything!] just because “it is the way we have always done it”. I love to play Devil’s Advocate [or “Devil’s Avocado” as I heard someone quip the other day] and propose change just to shake things up. It may be that the tried and tested approach is, indeed, the best, but you cannot be sure until you have considered that other options.

When it comes to embedded programming, it is easy – most people use C or similar languages. But is that the only way? … Read the rest of Time for a new programming paradigm?

A topic that I find particularly interesting, which is raised by many embedded software developers whom I meet, is dynamic memory allocation – grabbing chunks of memory as and when you need them. This seemingly simple and routine operation opens up a huge number of problems. These are not confined to embedded development – many desktop applications exhibit memory leaks that impact performance and can make system reboots common.

However, I am concerned about the embedded development context … Read the rest of malloc() – just say no

It is common for C to provide several different ways to do something, all of which are exactly equivalent. For example, given that x is a normal int variable:

x = x + 1;

is exactly equivalent to:

x += 1;

or

x++;

The only possible difference is that a less capable compiler might generate slightly better code for the second and third options [which would be a hint that getting a better compiler would be worthwhile].

However, sometimes constructs that appear to be equivalent have very subtle differences … Read the rest of Spotting the difference – subtleties of C

Demand for medical care and, hence, for all the equipment that enables the care to be delivered, has been rising exponentially in recent years. There are two, somewhat related reasons for this. Firstly, there are an increasing number of conditions that can now be treated effectively. In the past it was much more common to be told that you would just have to live with the illness and suffer or you might be told that you were going to die. Of course, all of this still happens, but it is much more likely that some treatment will be offered. The second factor is the mean age of the population in western countries is rising – we are living longer – and medical treatment requirements tend to increase with age… Read the rest of Medical embedded applications – big challenges and opportunities