Using an MMU
On a previous occasion, I talked about using an MMU [memory management unit] for a specific, slight esoteric purpose. I thought it might be interesting to consider its more conventional use. Also, it is worth remembering that some devices have no MMU support and many systems are built without one anyway. Having met some engineers recently, who could not conceive of the idea of no MMU, clarification may be necessary …
We need to think in terms of logical addresses, which are what the software deals with, and physical addresses, which are seen by the hardware [the memory system]. If there is no MMU, logical and physical addresses are the same. An MMU changes the mapping between logical and physical addresses.
Obviously, the simplest thing an MMU can do is map the logical addresses straight on to their physical counterparts. Of course, this is pointless without further sophistication and I will come on to that.
A common use of an MMU is to implement an operating system using process model – like Linux. In this case, each task has one or more dedicated areas of memory for its code and data. When a task is made current by the scheduler, the MMU maps these physical addresses onto a logical address area starting from 0. All the physical memory belonging to other tasks [processes] and to the OS itself is hidden from view and, thus, protected. Each process behaves as if it has free use of the entire CPU. Although this mechanism is safe and elegant, it has the drawback that there is an overhead – the MMU remapping – on every context switch.
Another approach is to implement “thread protected mode”. In most RTOSes, an MMU has not been traditionally used [or available] and all memory is visible at all times. If the MMU is set up in the trivial way I mentioned earlier, parts of the mapping may be switched off as each task is scheduled. Thus, no remapping of addresses occurs, but only the memory for the current task, and relevant parts of the OS, is visible at any one time. This provides much of the protection of process model, with a lower overhead on each context switch.
Thread protected mode [which may have other names] is available as an option with a number of popular RTOS products, including Nucleus.
Posted May 17th, 2010, by Colin Walls
- Choose your weapons – options for debugging
- Dissatisfaction, customer service and surprises
- Video blog about getting into embedded software
- Embedded software article: RTOS Revealed #9
- Lost in translation
- One return from a function: a good idea?
- The A380 experience
- Embedded Software Masterclass
- How to get rich