Memory Mapped Vs I/O Mapped Vs others

Hi,

What is the actual difference between the following : "Memory Mapped" Vs " I/O Mapped" Vs "Memory Mapped I/O" Vs " I/O Mapped Memory" ?

Kindly tell me their actual definitions/meanings . Further, Let me know some best conditions whereit should be used and other scenarios where it should not be used.

Need some clarifications / links / docs.

Thx in advans, Karthik Balaguru

Reply to
karthikbg
Loading thread data ...

The textbook for your course should provide much of the information you need to write this homework assignment. Your professor will doubtless be able to recommend other sources of information equally instructive.

Reply to
larwe

Some processors provide seperate memory and I/O address spaces by including additional control bus bit(s). For example, in addition to a read/write bit there may also be a memory/I/O bit. The hardware designer uses the latter, when available, to map memory and I/O devices to the memory and I/O spaces, as desired. When there is no seperate I/O space (or even when there is), I/O devices are (or may be) mapped to the memory space leading to the term "memory mapped I/O." "I/O mapped memory" is rare. I know of no processor that provides only an I/O space, but I suppose that one could map a specialized memory device such as a EEPROM to an I/O space, although I've never seen it done.

I/O mapping can be used only if one's processor supports if and may be used to simplify one's hardware design. The Zilog Z80, for example, provides I/O mapping. Its address bus is 16 bits wide but only the lower 8 bits are valid during I/O space accesses. This can be used to the designer's advantage because it simplifies I/O address decoding.

--
========================================================================
          Michael Kesti            |  "And like, one and one don't make
                                   |   two, one and one make one."
    mrkesti at hotmail dot com     |          - The Who, Bargain
Reply to
Michael R. Kesti

Kindly tell your prof you're going to fail his class.

pete

--
pete@fenelon.com "he just stuck to buying beer and pointing at other stuff"
Reply to
Pete Fenelon

Crikey, is that book still going? It was the freshman digital electronics text I used over 20 years ago ;P

pete

--
pete@fenelon.com "he just stuck to buying beer and pointing at other stuff"
Reply to
Pete Fenelon

When did the 1st ed of Horowitz and Hill come out? Must've been around then.... An infinitely better book than Mano, or the dreadful Senturia and Wedlock which totally soured me on analogue electronics for life!

Of course, we were taught analogue by the EE department and digital by the CS dep't so using the same book was obviously out of the question ;)

pete

--
pete@fenelon.com "he just stuck to buying beer and pointing at other stuff"
Reply to
Pete Fenelon

But you still started with that book, right? And now your experience builds on that book, ain't it?

--Himanshu

Reply to
Himanshu Chauhan

This is a common misconception about the Z80. The Z80 has two types of IO instructions, using 8 bit addresses or 16 bit addresses. the 16 bit address is in registers BC. I don't have my docs handy, so I can't give the exact syntax here. Mixing the two types is problematic, since IO address decoding normally is either 8 bit or 16 bit, giving 256 mirrors in IO spave :>(

Regards, Hans

Reply to
Hans Bus

Hi,

Thx for all of your replies that gave me clarifications.

Got some good info from the net regarding this - i have placed it below ....

Generally, Processor families have two distinct address spaces through which they can communicate with these memories and peripherals. The first address space is called the memory space and is intended mainly for memory devices; the second is reserved exclusively for peripherals and is called the I/O space. However, peripherals can also be located within the memory space, at the discretion of the hardware designer. When that happens, we say that those peripherals are memory-mapped.

act very much like memory devices. However, the function of a peripheral is obviously quite different from that of a memory. Instead of simply storing the data that is provided to it, a peripheral might instead interpret it as a command or as data to be processed in some way.

If peripherals are located within the memory space, we say that the system has memory-mapped I/O.

The designers of embedded hardware often prefer to use memory-mapped I/O exclusively, because it has advantages for both the hardware and software developers. It is attractive to the hardware developer because he might be able to eliminate the I/O space, and some of its associated wires, altogether. This might not significantly reduce the production cost of theboard, but it might reduce the complexity of the hardware design.

Memory-mapped peripherals are also better for the programmer, who is able to use pointers, data structures, and unions to interact with the peripherals more easily and efficiently.

Chips are located in the processor's memory space, and the processor communicates with them by way of two sets of electrical wires called the address bus and the data bus. To read or write a particular location in memory, the processor first writes the desired address onto the address bus. The data is then transferred over the data bus. The memory map contains one entry for each of the memories and peripherals that are accessible from the processor's memory space. Mostly External RAM,ROM,FLASH memory devices come in this region.

If a separate I/O space is present, and devices are connected at that region, then it is called as I/O Mapped. Typically, a large percentage of the I/O space will be unused because most of the peripherals located there will have only a handful of registers. Devices like the peripheral control block (PCB), parallel port, and debugger port etc.... come in this region.

Unfortunately, registers within the I/O space of an 80x86 processor can be accessed only by using the assembly language instructions in and out. The C language has no built-in support for these operations. The actual algorithm is straightforward: read the contents of the register, toggle the bit that controls the I/O (LED etc) of interest, and write the new value back into the register. You will notice that although this routine is written in C, the functional part is actually implemented in assembly language. This is a handy technique, known as inline assembly.

Regards, Karthik Balaguru

Reply to
karthikbg

No, I found that the course notes were infinitely better than the book, and that Horowitz & Hill was better still. Mano is not a book I remember fondly, in fact it was one of the texts I sold off immediately I'd finished using it!

pete

--
pete@fenelon.com "he just stuck to buying beer and pointing at other stuff"
Reply to
Pete Fenelon

No, that's not "generally" true. _Some_ processors have two distinct address spaces. Some only have one. Some have three or more.

Sort of. You can put memory in I/O space if you want. The difference between the two address spaces is which instructions are used to access them. Also, some processors have multiple memory address spaces. The most common implementation of that uses one memory address space for instructions (code), and a separate one for data. That's called a Harvard architecture. Some Harvard architecture processors have a third address space for I/O peripherals.

Yes.

[...]

Yes, although there are numerous pitfalls when using memory-mapped I/O devices in the manners mentioned.

--
Grant Edwards                   grante             Yow!  Actually, what
                                  at               I'd like is a little toy
                               visi.com            spaceship!!
Reply to
Grant Edwards

I would take exception with the use of "generally". I/O-mapping seems to have been initiated by Intel way back when and only the look-alikes (Zilog, et al) ever followed that lead.

Reply to
Everett M. Greene

True, the texas 9900 series and transputers had their I/O on serial links, not mapped anywhere.

Reply to
cbarn24050

Yeah but...

DEC's PDP 8 used I/O ports for I/O and the PDP 11 used memory-mapped I/O long before Intel or Mot fabbed a single processor wafer.

Reply to
Jim Stewart

That is actually far older - predating all microprocessors.

On the first mini's, the Digital PDP-8 used separate I/O instructions (and I/O mapping), but PDP-11 used memory mapping.

In the minicomputer time, separate I/O was more often used, so the memory-mapped PDP-11 was kind of a weird bird.

--

Tauno Voipio
tauno voipio (at) iki fi
Reply to
Tauno Voipio

Well, those are definitely two ways of doing I/O, but they are far from the only ways.

Many old architectures (60's and earlier) have dedicated instructions for doing I/O to each individual peripheral. So one instruction for the paper tape punch, one for the reader, one for the console, one for the printer, etc.

There are remnants of this approach in some modern microcontrollers where there's a couple special instructions that access a very few on-chip peripherals directly without having to specify an address. This is seen in 8085's, low-end PIC's, and undoubtedly the bazillions of embedded CPU's pouring out of the far east for the past couple of decades.

Many mainframes make the more complex peripherals (generally but not always the ones that do large block transfers) go through "channel processors". Roughly this is equivalent to a DMA controller in modern micros, but there is an important difference: channel processors interlock tightly with the I/O subsystem on the mainframe, and are usually accessed via instructions that talk to channel processors only. This is brushing up against the "I/O coprocessor" as implemented in micros, and conceptually not different than say an IDE hard drive with DMA, EXCEPT that IDE hard drives are not accessed on x86 via channel-specific instructions.

Channel processors had to deal with multiple different busses: one ran from the channel processor to the device controller/formatter, and the other ran to the mainframe for channel instructions, and usually there were more to the different mainframe memory banks for DMA. The bus from the channel processor to the device controller/formatter used its own addressing scheme, specifying often a formatter # and unit #. The mainframe had to be cognizant of the formatter numbers and unit numbers to issue instructions to the channel processor, but it did not have direct access to the bus that understood those numbers, so there's yet ANOTHER example of a new addressing scheme.

Tim.

Reply to
shoppa

snip--

if you prevent me doing stupid things, then you also prevent me doing clever things

let a hundred flowers bloom...

sidd

Reply to
sidd

Right. But you won't mind if you locked into a room without access while you are doing your dangerous things :-).

/BAH

Reply to
jmfbahciv

snip re dangerous things--

indeed, i would prefer it that way. when i am doing possibly foolish and dangerous things, i hate to be interrupted

i recall a setup for an experiment where some of the last things done before beginning a (perhaps multiweek) run were

a)check shielded room integrity (20'x20'x10' Faraday cage with all modern conveniences, hot and cold running helium, nitrogen, water, air and vacuum, filtered power, isolated grounding complete with prominent signage assuring the fire marshal that yes, this is approved and correct and signed off on, so please dont f*ck with it)

b)physically disconnect all computers in that lab from networks. there were no computers or digital electronics allowed inside the shielded room. but there were (carefully isolated) computers outside it that took data, and controlled many things. One supervised the current supply for a 8 Tesla magnet that sat in liquid helium. the magnet absolutely Did Not Like Jiggles in the current supply. in the event of Jigglage, the magnet could and would express severe dipleasure through a flamboyant display called a 'quench'. the superconducting coils of the magnet would go normal, and heat up and boil tens of liters of liquid helium. the resulting vapor would vent in huge white roaring plumes out of the top of cryostat accompanied by squeaky cries of dismay from the attendants.

did i mention that this particular controller used MMIO (which is what probably brought this to memory) but worked and worked well for a decade or more.

there were several other computers associated with that experiment that could cause disasters, some annoying, some life threatening.

this is more common in research labs, but of course ought not to be tolerated outside one.

sidd

Reply to
sidd

My brother makes boxes that provide some of that functionality. I don't think he's made a Faraday cage.

You must have been allergic to sparks. What did you use for spark-prevention?

I've heard that term but I can't remember where...probably s.p.

Squeaky because of the air they breathed or because they had to scramble?

Seeing labs is so educational. Watching people work them even more so. Research labs were always the first to try innovative setups. This is because those dudes tended to work in extreme conditions.

What works in the extreme can, usually, be generalized to function for "mundane" everyday stuff.

What a kewl lab setup.

/BAH

Reply to
jmfbahciv

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.