Embedded Software 
Colin Walls
Colin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor … More » Using an MMUMay 20th, 2015 by Colin Walls
Many microprocessors and microcontrollers incorporate a memory management unit (MMU) or have one available as an option. Equally, there are some devices that 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 a lightweight process model (also called “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. A lightweight process model is available as an option with a number of popular RTOS products, including Nucleus. |
|
|
|||||
|
|
|||||
|
|||||
