Do you need a memory management unit?
A memory management unit [MMU] does what its name suggests – almost. It does not actually manage memory – it manages the addressing of memory. Most 32-bit CPUs have an MMU or can have one as an option. In some cases a developer may elect to not use the MMU; in other designs it may be deployed in a number of ways …
Memory is, of course, always accessed by means of an address. In the absence of an MMU, the address used by code to read from, write to or execute from memory is the physical address of that memory, which is decoded by hard-wired logic. If an MMU is used, the address may be modified in some way so that the logical address asserted by the software differs from the physical address of the memory. This sounds illogical and counter intuitive. However, it turns out to be useful in a number of contexts. Broadly, there are two ways to utilize an MMU.
An MMU is commonly deployed to support “process model”. This is a way to organize tasks in an operating system and is the one used by most “heavyweight” operating systems. In the world of embedded systems, this means Linux. Most desktop operating systems also employ process model. The idea is simple: each task [we will now call them processes] uses memory from address zero upwards, as if it were running by itself on the CPU. The MMU maps the addresses onto a specific area of real, physical memory. Each time there is a context switch – i.e. a different process takes control – the MMU mapping is changed. This simplifies the development of each process and provides a high level of safety and security as each process cannot access the memory that “belongs” to other processes. The downside of this approach is that each context switch includes an additional overhead: MMU remapping. If you want to use Linux, you need to have an MMU.
Most real-time operating systems [RTOSes] do not use process model. They use thread model, where logical and physical addresses are identical. So, an MMU is not required. This has the advantage of quicker context swap, but less safety and security as all memory is accessible to all tasks.
Some RTOS products [including Nucleus RTOS] have an option to use the MMU in a simple, but useful, way. This mode of operation may be called “lightweight process model” or “thread-protected mode”. This approach does not remap any memory, but it protects memory that does not belong to the current task [by making it invisible]. If a task attempts to access memory outside of its designated area, a trap occurs and this is usually an indication of a fault in the code. Overall, this approach gives a good level of safety and security, but with a lower overhead than process model.
