Approaching embedded development means keeping the focus on the specifications as well as the hardware restrictions at all times. Embedded software development is a constant challenge to focus on the most efficient way to perform a set of specific tasks, but keeping in strong consideration the limited resources available. There are a number of compromises to deal with, which are uncommon in other environments. Here are some examples:

• There might be not enough space in the flash to implement a new feature
• There might not be enough RAM to store complex structures or make copies of large data buffers
• The processor might be not fast enough to accomplish all the required calculations and data processing in due time
• Battery-powered and resources-harvesting devices might require lower energy consumption to meet lifetime expectations

Moreover, PC and mobile operating systems make large use of the MMU, a component of the processor that allows runtime translations between physical and virtual addresses. The MMU is a necessary abstraction to implement address space separation among the tasks, and between the tasks and the kernel itself. Embedded microcontrollers do not have an MMU, and usually lack the amount of non-volatile memory required to store kernel, applications, and libraries. For this reason, embedded systems are often running in a single task, with a main loop performing all the data processing and communication in a specific order. Some devices can run embedded operating systems, which are far less complex than their PC counterparts.

Application developers often see the underlying system as a commodity, while embedded development often means that the entire system has to be implemented from scratch, from the boot procedure up to the application logic. In an embedded environment, the various software components are more closely related to each other, because of the lack of more complex abstractions, such as memory separations between the processes and the operating system kernel. A developer approaching embedded systems for the first time might find testing and debugging on some of the systems a bit more intricate than just running the software and reading out the results. This becomes especially true on those systems that have been designed with little or no human interaction interfaces.

A successful approach requires a healthy workflow, which includes well-defined test cases, a list of key performance indicators coming from the analysis of the specifications to identify possibilities of trade-offs, a number of tools and procedures at hand to perform all the needed measurements, and a well-established and efficient prototyping phase.

In this context, security deserves some special consideration. As usual, when writing code at the system level, it is wise to keep in mind the system-wide consequences of possible faults. Most embedded application code run with extended privileges on the hardware, and a single task misbehaving can affect the stability and the integrity of the entire firmware. As we will see, some platforms offer specific memory-protection mechanisms and built-in privilege separation, which are useful for building fail-safe systems even in the absence of a full operating system based on separating process address spaces.