I'm looking for a small, 32KB or so SRAM device that two MCUs can read or write (at two different times; I don't need simultaneous reading/writing.) It would be good if it used a serial interface as well.
The problem I'm trying to solve is sending data between two devices without the other device having to pause to receive this. I would transfer an audio sample into the buffer, then the other chip, as required, would read the audio out, and do something with it.
I've found serial SRAM's like Microchip's 23A256/23K256, however, they seem to have a single serial interface. Is there any way to have two chips accessing this?
Additionally, the receiving device only has 2KB data memory free (maximum) so it looks like using DMA or some similar transfer mechanism through I2C or other interface will not work.
Best Answer
You don't need dual-port RAM or even a serial RAM with two interfaces; For SPI it's a little trickier, but I2C allows multiple masters "out of the box." Either way, your software will have to monitor the bus conditions to see if it lost the bus and if so, wait for another opportunity.
For SPI, the MOSI, CS and CLK lines must be tri-stated (or open-collector) with pull-up resistors to keep the lines from floating. You will also need some kind of bus arbitration. This can be as simple as a single GPIO between the two masters so that the one with higher priority signals the lower-priority master that the bus is unavailable, but a more elegant solution would be a single open-collector line between the masters. When the bus is idle, neither master is yanking the line down so it floats high with a pull-up. The logic is that if the line is high, the bus is available. The master that wants to use the memory would look at the "bus available" line and if it's high, drive the line low and wait a few ms to make sure the other master didn't grab the bus at the same time. If the RAM SPI CS line is still inactive, it can be safe to assume that the bus is yours. Do the transfer, tri-state your MOSI/CLK lines and let go of the "bus active" signal.
The "wait a few ms after yanking the bus request line low" is necessary since it is possible for both masters to grab the line at the same time.
If you are only ever using one shared device and that device does not require multiple transfers, you could use its CS line as the "bus available" signal, but this isn't quite as robust.