Share this article:
Using a Memory Management Unit (MMU)
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.
Read more from Colin on SciTech Connect:
OS Influence on Power Consumption
Vintage Multi-core – the IPC
Staying Inline
Thanks for the Memory
Embedded Optimization: Small or Fast?
C, C++ and the Family Tree
Agile Embedded
Colin’s most recent publication, Embedded Software: The Works is available now on the Elsevier Store.
Save 30% on his book and other Newnes Press and embedded systems books. Use discount code “STC3014″ at checkout.
About the Author
Colin Walls (@Colin_Walls) is an embedded software technologist at Mentor Graphics (@mentor_graphics), the leading EDA software company.
You can read more about Colin and his work on embedded systems at The Colin Walls Blog at Mentor Graphics here. Connect with Colin online here:
Computing functionality is ubiquitous. Today this logic is built into almost any machine you can think of, from home electronics and appliances to motor vehicles, and it governs the infrastructures we depend on daily — telecommunication, public utilities, transportation.
Maintaining it all and driving it forward are professionals and researchers in computer science, across disciplines including:
- Computer Architecture and Computer Organization and Design
- Data Management, Big Data, Data Warehousing, Data Mining, and Business Intelligence (BI)
- Human Computer Interaction (HCI), User Experience (UX), User Interface (UI), Interaction Design and Usability
- Artificial intelligence (AI)
- Peter Pacheco’s An Introduction to Parallel Programming
- Carol Barnum’s Usability Testing Essentials
- Peterson and Davie’s Computer Networks
2 thoughts on “Using a Memory Management Unit (MMU)”
Comments are closed.