Go Down

Topic: ...a hand explaining this RAM shield please? (Read 844 times) previous topic - next topic

jtw11

So, I'm planning to add a load of external RAM to a board design I'm working on - somebody pointed me in the direction of the MegaRAM and QuadRAM shields for inspiration...

http://ruggedcircuits.com/html/megaram.html

Plugging the part numbers in, clearly - one is the RAM chip, another is a latch IC. Can somebody explain to me the purpose of the latch chip, what it does there, and why the MCU does not just communicate directly with the RAM chip on its 16 external memory pins?

Latch datasheet - http://pdf1.alldatasheet.net/datasheet-pdf/view/15229/PHILIPS/74AHCT573D/+043_-UL.hKpRudCvhxKc.H.P+/datasheet.pdf

RAM datasheet - http://www.cypress.com/?docID=25496

Grumpy_Mike

Quote
why the MCU does not just communicate directly with the RAM chip on its 16 external memory pins?

Because it needs 8 bits for data and 16 bits for the address, making 24 bits in total. The latch holds half of the address while the other half is provided by the latche's input pins.

kg4wsv

If you don't have a bajillion extra pins for the address and data lines, there are SPI interfaced RAM ICs.  I think there are libraries for some of the Microchip devices.

IIRC the microchip devices are 3.3V, so if you're running at 5V you may need a level converter.

-j

jtw11

#3
Dec 17, 2012, 04:17 pm Last Edit: Dec 17, 2012, 04:59 pm by jtw11 Reason: 1
Thanks - however, I'm using the 2560 in my board design - so have plenty of pins to interface with the chip. I'm using an SPI flash chip for storage of logged data, but I would like a true zero-wait RAM interface, hence going down this path. The 2560 has address space and alternate function pins ready for external memory.

I'm still not completely on track looking at the MegaRAM schematic however - I don't quite get the blue bus lines on the schematic...


Quote
why the MCU does not just communicate directly with the RAM chip on its 16 external memory pins?

Because it needs 8 bits for data and 16 bits for the address, making 24 bits in total. The latch holds half of the address while the other half is provided by the latche's input pins.


If I've interpreted the schematic right, it seems that the latch holds half the address, while the other half is provided by the other 8 address pins of the MCU, whilst the data bits are then provided by the latches inputs?

I've redrawn the schematic as I see it, using wires not busses - am I on the right path here? I realize I've used a 3.3v part, not identical to the MegaRAM chip - I will make a custom part when I've got this correct in terms of address and data lines.



Now I need to check what the other pins do. (clearly, something has to reset the latch)

westfw

Quote
I'm using the 2560 in my board design - so have plenty of pins to interface with the chip.

That's not an option if you want to use the "External Address Interface" of the AVR (which puts the external memory actually IN the address space so that you don't need special subroutines to access it.)  The AVR external interface is always "multiplexed" to save some pins (it probably originated on a 40pin chip.)
Quote
it seems that the latch holds half the address, while the other half is provided by the other 8 address pins of the MCU
Yes.
Quote
whilst the data bits are then provided by the latches inputs?

The data bits of the RAM are then connected to the AD0-7 pins of the AVR.  Once the address is latched from the previous clock cycle, the fact that the input to the latch is also connected to those pins is irrelevant.

You won't get "zero wait" RAM (external RAM is slower than internal RAM), but it should be faster than any other way of doing things.

The sequence looks like:
Provide A0-A15 on AD0-7 and A8-15.
Enable the Latch (ALE).  A0-A7 are now sent to the memory by the latch outputs, and A8-A15 by the AVR (still)
Either set AD0-7 to the data and signal "WR" for a write to RAM, or signal "RD" and read AD0-7 as inputs to the AVR.

jtw11


Quote
I'm using the 2560 in my board design - so have plenty of pins to interface with the chip.

That's not an option if you want to use the "External Address Interface" of the AVR (which puts the external memory actually IN the address space so that you don't need special subroutines to access it.)  The AVR external interface is always "multiplexed" to save some pins (it probably originated on a 40pin chip.)

You won't get "zero wait" RAM (external RAM is slower than internal RAM), but it should be faster than any other way of doing things.


That's not an option? Sorry, I don't follow - the 2560 supports external memory in the manner you've described.

The first 56k of external RAM however is zero wait is it not, as the external memory map leaves a 56k 'slot' directly accessible without bank selection of the RAM chip?

Or do you mean it's simply not zero wait due to the fact the address has to be latched?

Your written sequence was especially useful, many thanks.

westfw

Quote
Or do you mean it's simply not zero wait due to the fact the address has to be latched?

The datasheet says "Accessing external SRAM takes one additional clock cycle per byte compared to access of the internal SRAM." (not including any wait-states that are configured.)   It's not entirely obvious whether that's because of the multiplexing, or for some other reason.

I should add for the sake of more casual readers that the "sequence" is all done for you by the AVR internals.  You could imagine a very similar sequence done explicitly by the user program - output address to a couple of IO ports, fiddle with the memory signals using digitalWrite, read or write the data from another port, etc.  But you don't have to do that; that's what the "external memory interface" of the chip does.  (Similar to the way you COULD run SPI by doing "bit-banging", but the SPI peripheral does a lot of work for you.)

Graynomad

Quote
That's not an option? Sorry, I don't follow

What Westfw is saying is that if you are using an Arduino none of the non-Mega versions are an option, the Mega is the only one with the external memory interface.

The schematic looks correct, except that AD8:15 are only addresses so probably should be called A8:15.

_____
Rob
Rob Gray aka the GRAYnomad www.robgray.com

jtw11

#8
Dec 18, 2012, 10:55 am Last Edit: Dec 18, 2012, 10:59 am by jtw11 Reason: 1
Brilliant, thanks - I'm with you both on all accounts. I'm not actually using the Arduino IDE for this project, so it's just co incidence that I'm using the 2560 chip in the design - I had looked at using a number of the smaller chips that supported external memory, but by the time I'd added external ADCs and port expanders / multiplexers to get my required I/O, a much bigger chip was cheaper and simpler.

Quote
The datasheet says "Accessing external SRAM takes one additional clock cycle per byte compared to access of the internal SRAM." (not including any wait-states that are configured.)   It's not entirely obvious whether that's because of the multiplexing, or for some other reason.


If its one cycle per byte, and not per bit - that would say to me that's the latch signal as that is the only additional step it is taking as compared to internal SRAM is it not?

Graynomad

Quote
that would say to me that's the latch signal as that is the only additional step it is taking as compared to internal SRAM is it not?
I would assume so, but it's of academic interest only I suppose.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

Go Up