The question posed was this:
"What advantages does an external memory interface have over driving a peripheral with GPIO?"... which immediately brings out the question, what do I mean by an external memory interface and what do I mean by GPIO?
General Purpose Input Output (GPIO)
This typically refers to a pin of the chip which is not necessary for any of the operations of the chip but is available to a system designer using the chip. Put another way if none of the GPIO are used then the chip will function just fine. The pins are under software control and can be turned into either inputs allowing data to be read from the outside world or outputs pushing data to the outside world.
External Memory Interface
In modern digital computer architecture the standard method of connecting a processor core to the outside world is with a memory interface. This is typically formed from an address bus, a data bus (either bi-directional or two uni-directional ones) and some control lines to indicate whether data is being written or read.
Normally this is present inside the chip but forever hidden from the designer inside and only a few designs allow it to be exposed. Those that do allow extra RAM or ROM memory to be added to the fixed amount of a normal microcontroller design.
Engineering Advantages of EMI
Direct memory mapped busses has a couple of advantages over GPIO so, as usual, it depends what you are doing as to whether you care (typical engineers comment!). Here are the two main differences:
- Native machine code access. Grants speed, reduced code size and I would guess lower power? No extra instructions to drive the GPIO and turn the bus around to slow you down. Simply create pointers and data structures as usual and prod the linker to place them in the external chips. Or use explicit addresses.
- Code execution from external memory. Related to the above.
2. only matters if you have run out of on-chip non-volatile memory and have to move sections of your program off chip.
[Just speculating re. 2. code execution: you could change the compiler to emit instructions to drive a GPIO for data memory accesses in a certain range. However I can't work out how to do a native instruction fetch from the external memory without a little code in internal flash copying it to an area of RAM first. Perhaps a block copy strategy held in flash as a bootloader type thing could minimize the pain of this if it was invoked as appropriate by a compiler or linker? Note that in the world of computers I have discovered that someone has always built an implementation of just about every whacky idea. If you know of a system that uses this paradigm then please let me know. PC's don't count.]
In a final summary if you are accessing a data storage area or a peripheral occasionally and don't care about 1. or 2. then a simple software wrapper around GPIO would do just fine and be relatively efficient. I would guess 3 to 5 times slower?
Educational Advantages of EMI
From an educators point of view when teaching computer architecture and interfacing and EMI is gold in terms of hammering what is happening inside all general purpose computers into the heads of students. I mean simply this basic idea:
"A CPU issues an address onto the bus with control signals and writes or reads data."
This very basic idea is surprisingly poorly understood by many students as it is completely hidden from them inside micros or PCs. In many EE or even CompE courses the students never actually physically observe it in action or build their own peripheral and code software to drive it. As long as it remains a mental exercise a substantial portion of the students will not really understand it and without understanding it their ability to understand computers and software suffers.
Myself and colleagues (past and present) have gone to great lengths to try to give them some practical experience at it - I first encountered a softcore PIC in an FPGA used to expose its pipeline and memory and databusses for the students to observe and extend. We moved to an Atmel part (an ATmega128) with a real external memory interface instead when it became available. Multiplexed address + data but designed so it could drive an 74 series 8 bit latch to generate the full bus. Much improved from our softcore PIC! We would set them the task of mapping an 8k SRAM and an 8 bit input and 8 bit latched output into the memory map of the microcontroller.
I am looking forward to developing similar exercises with a more advanced external memory interface (called the EBI, external bus interface) found on Fujitsu FM3 ARM Cortex M3 based microcontrollers. It has the following neat features, and is really designed to drive FLASH memories transparently which is no mean feat:- It does have an external wait input which could prove very useful
for custom peripherals. - It has a basic SRAM mode with configurable timing for read and write strobes.
- It can transparently split and rebuild data from 32 bit to bus widths 8 bits (or 16)
on the fly by issuing the correct sequential addresses. - It can natively drive various types of FLASH memory including NAND block erase and NOR page reads etc. while pretending to be normal memory to the software.