Introduction

Embedded systems are often special by design. A combination of forces, the strongest of which is economic, conspire to make the life of embedded systems progammer more interesting. This document is a place to enumerate some of these features.

Its Just Memory

Applications programming rarely involves much thought about memory (unless there's a leak). In fact, high level languages intentionally attempt to hide the concept behind the walls of the language. Systems programmers must often deal with low level details of memory. Embedded systems programmers are frequently faced with even more varieties of memory issues.

• Non contiguous
• Alignments
• Cached
• Banked
• Fast/Slow
• Shared/Private
• Volatile/Non-Volatile
• Side Effects
• Redundantly Mapped
• Read-Only
• Virtual/Physical

Ignoring these attributes can quickly prevent a given piece of software from being reused in another context.

Non Contiguous

Memory which is not contiguous cannot be ignored at the systems level. Non-contiguous memory is hidden from applications programmers by a combination of the operating system and a memory management unit (MMU).

Alignment

Memory alignment restrictions must frequently be considered in a given systems software design. The restrictions may be imposed either by the CPU or by a peripheral. For example, a DMA capable peripheral may require that buffers start at 16 byte boundaries. A CPU may either require "natural" alignment for primitive data types, or it may allow unaligned accesses with a significant performance penalty.

Cached

Systems programmers must treat cached memory specially when there is more than one master within the system. Other masters include peer CPUs, and DMA capable peripherals. If coherency is either not supported by the CPU or not properly implemented by the hardware designer, then the task of maintaining synchronization between the masters becomes even more interesting. Even so, systems programmers must be aware of low level details such as cache-line size and other cache attributes. Cache flush, invalidate and other specialized instructions are tools that must be mastered by the systems programmer.

Banked

This problem is typically the result of a warped sense of saving money in a hardware design. Even if it is highly undesirable, it is still possible bank switch both RAM and ROM in a given system. The pain inflicted on the software developers, maintainers and the project schedule cannot be overstated. Thankfully, this travesty is on the wane in most of the embedded world with the advent of inexpensive micro processors that have address buses larger than 16-bits.

Fast/Slow

Performance hungry systems may have various regions of memory set asside for special purposes. Static RAM regions are sometimes provided for this reason. The program must initialize and allocate this special memory.

Shared/Private

Systems that have multiple masters sharing one or more regions of memory impose constraints upon the systems programmer. For example, a driver executing on a processor must be aware that the DMA controller can only see a particular window of its own memory space.

Volatile/Non-Volatile

Side Effects

Redundantly Mapped

Read-Only

Virtual/Physical