Embedded Computing Design

Developing software for embedded systems takes time – generally more time than initially expected.

Every embedded system is different. And so, as multicore designs become increasingly common, almost to the point of being mainstream, different hardware and software architectures are evolving.

In the early days of programming, the first high-level languages very much followed the pattern of assembly language.

C is the most commonly used language for embedded, with good reason. It is expressive, compact and powerful. With care, it is possible to write very clear, readable code. But there are pitfalls.

When writing code, your first priority should be readability. A lot of time is spent debugging and maintaining code, often far more than was spent writing it in the first place.

The "free apps" folks are so surprised when I pay, say $1.99 for an app. I commonly think, generally I know, that I am getting a bargain.

The word "library" is used and abused in a variety of contexts. Its meaning here is well defined. A library file may be presented to the linker, along with relocatable object files.

There are, broadly speaking, two distinct approaches to the design of software: bottom-up or top-down.

Increasingly, embedded software developers are realizing that dynamic memory allocation is fraught with problems.

I feel very strongly that a software developer has a great responsibility, which should be manifest in a priority: write code that is easy to understand.

Although I would normally talk to embedded software developers about the technology and processes around that software, understanding the background to why their products are needed is useful.

There is an increasing focus on safety and security in a variety of embedded applications. This, in turn, drives a demand for certification of such systems.

Most software is obtained as a binary executable. The program may run and does what it does, but the user has no knowledge of its inner workings and has no opportunity to modify its functionality.

OS selection is quite a large subject and there are many nuances, and this is a matter that I have written about many times. Today I wanted to ponder the matter of time; what model of time is relevant

Almost all modern embedded systems are built using an operating system (OS) of some sort. This means that the selection of that OS tends to occur early in the design process. How do you choose an OS?

There are a great many embedded CPUs on the market today, so selecting the right one for a given project is a challenge.

Power management's importance is largely driven by the requirements to extend battery life for handheld devices, but environmental hazards, heat dissipation, etc., are raising concerns.

Some technologies stand the test of time. Hypervisors have been around for a long time, but have recently come into their own.

A device can perform a self-test and sometimes software can preempt its own failure, but freezes happen, and what do you do?

Obviously, well designed software is likely to have fewer bugs and the application of modern embedded software development tools can keep them to a minimum.