Does anyone know of an Idiot's Guide to this topic? In particular, how does a processor with no special I/O instructions issue a request, e.g. to a serial output device to output "Hello, World"? And how does Memory-Mapped I/O work in detail? Where is the Memory Map stored? What are the actual contents of Device Memory? And where do AMBA/AXI (or ACE) fit in? (I did say it had to be an Idiot's Guide!)
I like the idea very much.
We have quite a few employees, like myself, who have been STEM ambassadors. I have usually done drawings on a whiteboard, showing the path the information is following.
When you say a serial output device, do you consider that the device has a module dedicated to that (UART/RS232 type) or should the explanation just use a normal I/O to emulate what is usually done in a dedicated module?
Here is on the right an interestingly simple diagram which locates the on-chip bus. You can click on the image to see it bigger.
Chris, would you happen to have written (or know of) such document about processor basics within ARM?
The simpler the example, the better, Alban; if that means normal I/O, fine. Although, UART is in itself an interesting example, having Synchronous versus Asynchronous versions (the latter being akin to what we used to call "Start/Stop Comms". And, unfortunately, I didn't receive your diagram.
I am not aware of any simple documentation within ARM on this topic - mainly because it is not ARM-specific in anyway. Memory-mapped IO works in exactly the same way on almost any architecture or platform you care to mention.
It really works the way it sounds - control/status registers in the device are mapped (in the hardware, by mechanisms that you don't need to understand!) to memory addresses. You access the registers simply by accessing memory locations. Unless you are designing chips (or working with an extremely complex system), you don't really need to factor in any knowledge of AXI/AHB or the bus topology. The contents and behaviour of device memory is defined by the device which is mapped to those particular memory locations.
If you look for example code on pretty much any of hundreds of development boards available from the major silicon vendors, I am sure you will find simple examples of drivers for memory-mapped devices which will show you how it all works.
Hope this helps.
Chris
Chris Shore wrote: Unless you are designing chips (or working with an extremely complex system), you don't really need to factor in any knowledge of AXI/AHB or the bus topology.
Chris Shore wrote:
Unless you are designing chips (or working with an extremely complex system), you don't really need to factor in any knowledge of AXI/AHB or the bus topology.
Well, knowing the topology and the characteristics of the various protocols can obviously also be quite relevant for performance optimization. And, on non-coherent multicore SoCs (and there are plenty of those) knowing the topology can actually be essential for reasoning about ordering of transactions (and therefore of software correctness). For example, on the one I'm using, if a core writes data to location A, performs a full data sync barrier, then writes &A to B, I'm pretty sure another core which reads B and dereferences it to read A is not always guaranteed to read the new data there (when A and B are in different memories).