# Use Raspberry Pi Gpio Header as Memory Mapped Interface

Raspberry Pi is really an interesting device for its support of so many features in such a small and simple formfactor. If the GPIO expansion header can be accessed in the same way as a normal memory-mapped interface, more projects will be able to use it as a development platform. A few questions regarding this:

1. Can the GPIO pins on the header be aggregated into a single memory access instruction in its hardward (chip)? If not (that I assume), can some expansion board/circuit be attached to the connector to modify the behavior such that it can have support to such an access method? How do you see such a design?

2. If all these seem to be impossible or too much hassle, I see a viable solution is to wrap the access into a library or abstraction layer. Has such kind of work existed? Is there any similar work? I'm not looking at the userland access, I'm thinking of some kind of kernel library that makes it easy to develop kernel level drivers based on R-Pi.

• SPI is likely to be the best way. Looking around though it appears that 32MHz is the maximum speed that works so throughput will be around 4MB/s max. You might be better just using USB FLASH and paging or perhaps memory mapped files. Jan 27 '13 at 0:03
• Peter, Any suggestion how to map SPI back to memory bus on the peripheral side? Jan 27 '13 at 2:38
• Not specifically, but the main thing that comes to mind is a kernel memory management mod to load page faults from your SPI RAM. Keep in mind the CPU won't be able to natively access the data, it will need to be loaded into 'real' memory first. That's why I thought putting a page file on a USB memory stick would be a good deal faster although write times / endurance may be a problem. I guess you could also look at making a USB MSD device that used RAM instead of FLASH. Jan 27 '13 at 2:58
• Peter, Excellent explanation about the page fault and handling part. I'm not sure you understand I like to access external memory-mapped devices, not real memory. Jan 27 '13 at 5:34

The Raspberry Pi exposes 17 GPIO pins on P1, and the Rev. 2 board exposes 4 more on P5. These pins cannot be used directly as a memory-mapped I/O bus, such as you might have found on an old-time microprocessor-based system.

I suppose you could bit-bang such a bus, but the limited number of pins would be a problem. You could, for example, define an 8-bit data bus, a read strobe, a write strobe, and use the remaining 7 (or 11) bits as an address bus. However, since the available GPIO bits are nonsequential, this would be slow to operate; the driver on the RPi would have to set and clear bits individually.

A better approach would be to use the I2C and/or SPI (serial) busses that are available on the P1 header to implement external memory and/or memory-mapped I/O.

• Dave, Good points. Any idea which chip can be used to map the the I2C or SPI back to memory bus? I know on the host side adding a MMU page and modify the fault handler can map a memory access to SPI or I2C transaction. Jan 27 '13 at 2:40
• specify what memory bus you are interested in. there are many. (harvard is not an answer). Generally the I/O provided is there already memory mapped into the raspi address space so you dont have to do what you are trying to do. simply connect the peripheral and use the i/o for the peripherals bus (spi, i2c, etc). there are rams and roms that use these busses (spi, i2c, etc) if it is just memory you are after Jan 29 '13 at 5:18

Actually, you can do memory based I/O, just take a look at the WiringPI example at http://elinux.org/RPi_Low-level_peripherals.

There are some caveats, though, you have to open the /dev/mem device, which means you must be root. I know that there are some people planning to create a special /dev/gpio-mem device to make only this part of the address space accessible (to a lesser privileged user/group).

To look at actual code that already does this, take a look at Wiring Pi (https://projects.drogon.net/raspberry-pi/wiringpi/) or LogAn (https://github.com/r42/logan).

LogAn reads all the GPIO pins in just one memory access - It was already used to debug/diagnose the SPI protocol on the RPI (see https://github.com/R42/pinokia). Note that Pinokia uses memory based I/O to write to the pins.

For examples of boards that make extensive usage of the GPIO look at the Gertboard (http://www.element14.com/community/docs/DOC-51726?ICID=hp-gertboard-banner) and the PiFace (http://uk.farnell.com/jsp/search/productdetail.jsp?SKU=2218566&MER=baynote-2218566-pr).