What is exactly does it mean when someone says "memory-mapping","IO Mapping","Memory Mapped IO" & "Port Mapped IO"?

Question

All these words become a little bit confusing to me as I am a newbie. I understand that bascially a microcontroller is processor + memory to store data(RAM) + data memory OR from where the instructions get executed(ROM/Flash) + Peripherals.

1. How I am supposed to visualize the mapping?
2. Is the mapping done on the RAM?
3. If yes, Isn't it memory itself? How does the processor know about it?
4. Is this mapping done when I switch on the Controller or is done by the person/Company that manufatured the controller?

if it is really a stupid question or a broad one, let me know. I would try to narrow in.

Answer 1

I think these terms are primarily used with microprocessors, rather than microcontrollers.

"Memory-mapped" I/O devices just appear as normal memory locations, and can be read or written by any instructions that can read or write normal data memory. Memory-mapped I/O can be used by any microprocessor.

Some microprocessors (Intel 8085 and relatives) have a separate address space for I/O device use, not part of the normal memory space, and a limited number of instructions to read from, or write to that address space. I/O devices using this space would be "IO Mapped".

Answer 2

Nobody seems to have directly said this, so I will; it basically means the two types of mapping have different control lines. Consider the well loved (at least by me, heh) Z80 architecture, which has separate IO and memory.

Both types of mapping use the same address (16 lines) and data (8 lines) bus. To tell external logic whether you are addressing memory or IO, the processor has two pins; one is called MREQ and the other is IORQ. When the processor pulls MREQ low, external logic is configured to recognise that this is a memory address on the address bus, and connects the memory to the data bus after decoding the address bus, for data reads or writes (which are controlled by the RD (read) and WR (write) pins, one of which will go low for the read or write operation.

If the processor pulls IORQ low, your external logic recognises this as an IO request and connects some external device to the data bus, after decoding the address bus. The memory stays unconnected. In practice, most memory chips do the address decoding and connecting/disconnecting using internal control logic.

If the processor pulls both MREQ and IORQ low at the same time, it's broken. Throw it away. Which it pulls low depends on distinct instructions in the instruction set used by the programmer.

So it's all down to whether there are control lines on the processor to distinguish more than one mode for the buses. The advantage being that you can use all the address space for memory, and still have a means to connect to external devices, which are free to use many address locations for ease of interfacing as there are potentially 64k of them available (with a 16 bit bus).

A curious oddity with the Z80 is that its specification claims it only uses 8 bits of the address bus for IO, controlled by the C register, but in fact it encodes all 16, using the pair BC (in the in and out instructions). Which is nice.

Answer 3

Mapping is generally done with dedicated hardware in silicon, usually under the auspices of the CPU. Let's look at your four phrases really quickly:

• memory-mapping
• IO Mapping
• Memory Mapped IO
• Port Mapped IO

My gut says that your usage of memory-mapping and IO mapping stems from the dual memory spaces of x86-based system -- the 64K of IO Space that is essentially deprecated, and then the much larger memory-space, which I think ranges into the exabytes now with 64-bit machines.

EDIT: I'm going to add this paragraph to my answer, guessing that what you're asking is more microcontroller (PIC, AVR, etc.) focused. I touched on that a bit to answer your number four question. The mapping / addresses here are basically fixed by the chip architects, and generally there's an address decoder / memory management unit (not in the strict MMU sense) that sends data to the right place on the internal bus. I.E., if you write to an UART control register, it affects the flip-flops that are physically responsible for those bits, if you read from a SRAM address, it returns the data directly from that.

Either way, mapping is the same general task -- take a specific address, and give it special meaning / route it somewhere. For instance, on a x86-platform, I/O space address 0x3F8 points to the register for the serial port on the system. When you write to or read from this address (outb()/inb()), you are physically changing the state of 8 bits (implemented likely as SRAM or flip-flops) that contain data on that serial port.

Likewise, for memory-mapped I/O, you may have a PCI device that requests some amount of memory. I could design a device where if you write a byte to a specific address, that changes the state of 8 LEDs -- 0x00, all off, 0xFF, all on. Your MMU (memory management unit) is responsible for recognizing that the memory address you wrote too is destined for something on the PCI bus.

I'm not going to dive into virtual memory here -- in modern OSes, it's generally only kernel code / privileged code that has the opportunity to directly read/write from physical memory addresses. There is infrastructure / abstraction layers built in to control this access for user applications. You could read up on page tables, for example.

So, back to your questions --

1) How I am supposed to visualize the mapping?

Just that -- a mapping. It's a map that tells you how to get from your start (an address, say, 0xE0000000) to the destination (perhaps a PCI device, perhaps a specific location in physical RAM).

2) Is the mapping done on the RAM?

No. Physical RAM -- say, at the lowest level, an individual capacitor representing a single bit in DRAM -- is one of the many destinations that could be mapped too. Every single memory address does not necessarily correspond to a physical bit stored somewhere.

If you have a processor that has an external address/data bus (or some other large parallel bus), then reads/writes will be directly translated into traffic on that interface -- most folks these days will use SPI/I2C/other serial protocols, but it was not uncommon to have large embedded systems where parallel SRAMs would be attached via a 8 or 16-bit parallel interface (AD0-AD15).

3) If yes, Isn't it memory itself? How does the processor know about it?

On x86 systems, most of the low-level management of the system memory map, which has some 20+ years of legacy on it, is done by your BIOS firmware, and then the OS initialization afterwards.

4) Is this mapping done when I switch on the Controller or is done by the person/Company that manufatured the controller?

There are fixed mappings in silicon (very true for embedded microcontrollers), where you can peruse the datasheet and get fixed addresses for control registers, peripherals, etc. The architects of the chip designed a memory map that made sense to them, and usually leaves provisions for different models with differing peripherals / amounts of memory (i.e., a 32KB and 64KB model of the same chip may have all their registers / peripherals in the same locations, and only the memory address for the RAM is different).

For more sophisticated systems where things can move around (like PCI plug and play), the memory address allocation is dynamic and executed by software.

Answer 4

This is an interesting exercise. Let me offer my variant.

1) How I am supposed to visualize the mapping? - just as a map of a street, with storage units (memory does store data!), where each unit has an unique street address. Memory can be organized in "pages". This is like the same street map with same address range, only in a different city with different ZIP code (page selector).

2) Is the mapping done on the RAM? - not sure what do you mean "on the RAM", but the mapping is done by means of a special logic unit called "address decoder". It's like a Postal Office. The CPU throws a number (storage address), and the decoder "opens" corresponding "storage unit". The CPU can then store some data, or can retrieve stored data.

3) If yes, Isn't it memory itself? - no, see (2) above. Somebody ("address decoder") must look at the number (requested address), look-up the map, and open the proper storage location ("door") for a read/write operation.

3a) How does the processor know about it? - it does not. Memory controller just delivers the data according to the "map". But the software programmer must know which area is mapped, and which "storage unit" to use.

4) Is this mapping done when I switch on the Controller or is done by the person/Company that manufactured the controller? - it depends. Smaller micro-controllers have the map hard-coded in hardware. Bigger processors with user-installable memory (like DIMMs in PC) need to determine particularities of installed memories, and configure the memory controller (set address decoder ranges, and other parameters as access time etc.) during initialization by BIOS.

Please note that memories are usually meant as internal storage units, and usually are not exposed to external (peripheral) world. The peripheral devices interact with processor internals over some dedicated I/O registers, or GPIO - general purpose input-output registers. Some processor architectures have these GPIO mapped into the same address map, to a separate remote "subdivision". Some architectures have a dedicated I/O space, and have dedicated I/O instructions. Selection of different GPIOs follows the same idea - address decoder selects pre-defined "doors".

There are other spaces, like "configuration space", which can have special restricted access mode. It also can be mapped into memory address space.