Special "features" encountered in systems and embedded systems programming.
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.
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.
Ignoring these attributes can quickly prevent a given piece of software from being reused in another context.
- Non contiguous
- Side Effects
- Redundantly Mapped
Non ContiguousMemory 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).
AlignmentMemory 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.
CachedSystems 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.
BankedThis 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/SlowPerformance 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/PrivateSystems 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.