External RAM For An ATmega128

Those who are familiar with Atmel’s line of 8-bit AVR microcontrollers should already know that some of them have support for external RAM. But have you ever actually used this feature? We haven’t. Now you can learn how it’s done by reading through this guide. It touches on all of the hardware, but doesn’t dwell on it. Instead, you’ll get the background you need on how to write to, read from, and test an external module like the one sticking up in the image above. The test routine shows how to make sure everything’s working correctly with your memory mapping before you begin developing firmware around this increased capacity.

[Thanks Spman]

20 thoughts on “External RAM For An ATmega128

  1. Is it bad that the first thing I noticed were the Yageo electrolytic caps, and that my first reaction thereto was “ew”?

    Anyway, that’s seriously awesome, not least because it’s reminiscent of the computers of yesteryear, when a few hundred KB of RAM came on boards not a lot different from that one.

    Add an avr->teleprinter interface, and you’re well on the way to early 1970s computing power. :)

  2. @George

    Not exactly. The AVR can be run at 20MHz, while your ’70s era machines tended to be a third of that, perhaps less.

    However, I thought about that as well. Not just because of the memory, but because of the size of the memory board.

  3. As long as we’re thinking retro, instead of just expanding the RAM to something you’d find built-in on a better MCU; why not add a few extra I/O lines and bank switch for 128KB or more? ;)

  4. @Mike Szczys

    Accesses to external memory are well documented in the datasheet. In short, the MCU puts out the address value and a “read” signal; or, in case of writes, the address&data values and a “write” signal. FPGAs, CPLDs, even discrete logic can decode the address and map it to some function.

    For example, a few additional “remote” I/O ports :) — a nice addition when the external bus has consumed all native I/Os but there’s plenty of pins and memory remaining on the FPGA.

    Another example: a simple discrete address decoder is everything an external UART (16550A clone) needs. It has 8 internal registers that are addressed by 3 pins A0…A2. The decoder must compare A15…A3 of the external bus with some constant and route that to an appropriate “chip select” pin of the UART. A0…A2, RD, WR from the MCU can be used directly. This way all reads/writes at addresses base+0…base+7 will go to the UART.

    Of course this calls for a tutorial. Sadly I don’t have that custom-made development board anymore, and a bare theory is barely convincing.

  5. @Mike Szczys

    saimhe did a great job of explaining it. Really if you only need more RAM on a small MCU, you’d just get a bigger part. What this enables is the more open memory-mapped I/O architecture of the typical 8 bit computers of yesteryear.

    I guess I was a few steps ahead in those thoughts, when creating FPGA interface to an MCU, it can be very efficient to have it look like SRAM. Especially sometimes if you have an actual SRAM buffer in the FPGA.

  6. Yeah, a project I’ve been thinking of would memory map the BRAMs of a Xilinx Spartan such that it would appear as external memory to a USB AVR.

    This would permit a multi-universe USB-to-DMX adapter with good performance – Basically take incoming data from USB, dump it in the “external RAM” (really mem-mapped FPGA BRAMs), and hardware in the FPGA would send every 512 bytes as a DMX universe on one output pin.

    You could probably have 8-16 universes with good refresh rates without any I/O bottlenecks.

    Unfortunately, the USB AVRs that support XRAM don’t have many good boards based on them. Most people that offer USB AVR boards are offering smaller devices (like the 32U4) or have done something to make the XRAM interface unworkable.

  7. char some_buffer[256] __attribute__ ((section (“.noinit”)));
    Network debug output FIFOs, socket FIFOs, audio playback FIFOs, event log buffer, SD card write buffers… the big stuff mainly since you don’t want to put so many attributes in the code.

  8. As other’s have said this is more interesting for memory mapped peripherals than just attaching SRAM.
    With a few GPIO pins for chip selects or some address decoding logic you can attach external peripherals with a nice fat databus. You could for instance drive some of the RTL network interface chips, programmable sound generators.. if you really want you could probably get an ISA interface working and drive old school sound and graphics cards.

Leave a Reply to DarkFaderCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.