Memory Mapped I/O Physical Implementation

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

I have used memory mapped I/O and understand it from a programmer's
perspective, but I am curious as to how it gets implemented in
hardware. I basically want to know how physically(in hardware) this
memory mapping takes place.

For example, when the processor sends out 0xf000 on the address
lines(bus) as part of a read request, how does the correct peripheral
know that a read request has been issued for that address. By searching
the groups I found out that the peripherals are connected to the
address bus and listen for certain addresses where they are supposed to
be mapped and respond accordingly.

If I could get a clearer explanation of this or some references to look
at that would be great. Also, since the peripheral has to listen for a
specific address, is this address defined by the peripheral hardware
manufacturer and is it sometimes selectable? In other words, can I
choose to maybe map a peripheral to either 0xf000 or 0xa120 if the
hardware was designed with this in mind?


Re: Memory Mapped I/O Physical Implementation

Quoted text here. Click to load it

here is an example of memmory mapped device

on the lower left corner sith the uart chip
it is mapped to 0x002c8000 , real stuff starts at 0x00400000

RusH   //
We've slightly trimmed the long signature. Click to see the full one.
Re: Memory Mapped I/O Physical Implementation
Quoted text here. Click to load it

It's in exactly the same way as memory: this is what happens. When the
processor outputs an address, an address decoder (for a simple one,
google for the 74HC138) outputs a device select signal. This can be
connected to RAM, fixed code memory (EPROM/Flash etc) or to anything
else you care to tag onto it. In this case, it is a peripheral device.
With this chip select signal, this peripheral now knows that it needs to
take in the value on the data bus if it's a write cycle, or output a
value to the bus if it's a read cycle.

The decoder can be an external device like the HC138, or a programmable
logic device, or it can be internal to the processor. Sometimes the
whole caboodle is inside, as in microcontrollers, but the principle is
the same.

Here's the simplest example of all: the highest address line (say A15)
goes to an inverter. When the address is less that 0x8000, A15 is high,
and the inverter output is low. We use A15 (the chip select is usually
active low) to select the RAM, and the output of the inverter to select
the peripheral. So the RAM area is 0-0x7fff. When the address is 0x8000
or over, A15 is high and the inverter output is low. The RAM is
deselected and the peripheral is selected.

Paul Burke

Re: Memory Mapped I/O Physical Implementation

Thanks for your extremeley informative response! I did some googling
for that decoder you mentioned and understand things a lot better now.
I want to confirm something though. If you use the 74HC138, for
example, then you can obviously determine where you want to map the
different I/O devices in the processor's address space by adding your
own logic to generate the 3 decoder select inputs. Am I right about

However, on a development board since this is all wired up for you I
would have to consult the documentation to see where the different
peripherals are mapped to in the address space, right? I assume for
development boards that contain microcontrollers this depends on how
the chip selects are wired up to RAM, UART, etc. that are on the
development board, right?

Thanks for your help.

Re: Memory Mapped I/O Physical Implementation

Quoted text here. Click to load it

Of course you have to consult the documentation!  What else do you
think they wrote it for?

Hans-Bernhard Broeker (
Even if all the snow were burnt, ashes would remain.

Re: Memory Mapped I/O Physical Implementation
Quoted text here. Click to load it

Yes, in the Good Old Days when we designed our mappings with these
devices, we used to first break the map up into how much RAM, EPROM and
IO we wanted, then apply address lines to the 138s to get that mapping.
Back in about 1985 (for me- other people would have been earlier) we
started using programmable logic - PALs - and just put enough address
lines onto the inputs, then wrote the equations for the output mapping
we needed.

Quoted text here. Click to load it

Yes, and don't forget that some microcontrollers have internal address
decoders, that you have to set up in software when you boot the board.

Paul Burke

Re: Memory Mapped I/O Physical Implementation
I used to use the Z80 uP.  The Z80 had mnemonics that distinguished
between memory and I/O intructions.  When an instruction related to
memory was decoded and executed, the MEM pin on the Z80 was asserted,
as well as the appropriate RD or WR pin.  If the instruction dealt
with peripheral I/O, the IORW pin as asserted, as will as the
appropriate RD or WR pin. With I, O, MEM, IORW, ADDR, and some
appropriate decoding circuitry, one could "whomp up" CS lines for each
RAM chip or periperal in the system.  It was up to the designer to
decide "what's were".  It was of course always easier and less costly
to do those things in banks. If you're going to change or add to an
existing system, you better know what the memory map is like!  

Quoted text here. Click to load it

Re: Memory Mapped I/O Physical Implementation
Thank you all for your great responses!

Site Timeline