Allowing Multiple AVR Microcontrollers to Share SRAM

As the AVR has no bus control features you have a little bit of a battle on your hands.

I would guess you could hook all the buses ALE and Rd / Wr lines together and go to one SRAM. You will need to arbitrate accesses to it by enabling sram access on the chip accessing the ram and disabling it on the rest. You could use SPI for this between the chips and have a master that grants access to the RAM to another chip.

Doesn't like a very good design to me. I can't think of anything useful you would accomplish, that you could not do more simply of better another way.

Ralph

Thanks for the information. My motivation for this exercise is pure curiousity as opposed to any practical application.

But please let me ask you this: What are good designs for allowing multiple microcontrollers to share a relatively large amount of data? As a example scenario, say one micro operates on a large array of values, such as a graphical bitmap, which must be persistent throughout the micro's program's execution. At the same time, another micro periodically requires this array of values for some task, such as modulating a video signal. My (inexperienced) thinking is that a shared SRAM would be a good solution because the data can be kept in one place and accessed by all. What solutions do you think are better, and why?

Thanks for your help.

You need some form of arbitration..

How about adding a very small Dual port SRAM, or a latch register that can be read/written by all AVR's? Assign each AVR a unique ID, and use a common 'SRAM Idle ID'. When an AVR wants access to SRAM, it first checks the register if any other AVR has control. When it find the SRAM Idle ID, it writes it's own ID to the register. The AVR then reads it back to see if it 'won arbitration', in case more than one AVR attempts access. If it does win, it uses SRAM as it likes. When done, it writes SRAM Idle back into the register.

The same can be done even easier with a cheap 8-to-3 line (74148 or CD4532) priority encoder. Each AVR gets one of the 8 input lines, and all can read the 3 output lines. When it wants SRAM access, it pulls it's own line down. Whichever ID shows up gets access.

Rob

common

it

the

Consider the scenario from the latch's perspective.

Register contains IDLE AVR1 reads, gets IDLE AVR2 reads, gets IDLE AVR1 writes 1 AVR1 reads 1 At this point, AVR1 believes it owns the RAM, and AVR2 believes it is still idle. AVR2 writes 2 AVR2 reads 2 Now they both believe they own it, and will merrily trash each other.

There is a huge body of literature on "mutual exclusion" and on software- and hardware-based implementations. Do a search. Start by searching for "Dekker's Algorithm". If you can find Peterson's paper demystifying Dekker's Algorithm, that's even better. Also read the section in the Hacker Dictionary about AOSE. Read the various discourses about Test-and-Set instructions. Read the VMEbus stuff about RMW cycles.

CD4532)

down.

This is a start. It isn't nearly this simple in practice. You have to allow for an AVR wanting to read or write more than one byte while holding access, you want to PREVENT the other AVR from accessing the device, but you don't want a dead AVR to retain access forever (and lock everyone else out forever).

By using a bit pattern with single bits for ID's you can tell garbage from genuine ID's. It won't prevent the problem but should be detectable. Both AVR's then back off for a random short time and try again. It compares a bit to Ethernet CSMA/CD, multiple devices sharing a single resource. It's basically the priority encoder below implemented in software.

Before asserting a line, each AVR should read the encoder and make sure it reads 'no lines asserted'. After pulling their line, each AVR should wait a few cycles (arbitration delay) before reading back. If an AVR with higher 'priority' has also pulled its line, the lower priority AVR will not read back it's own priority and therefor 'lost' arbitration.

John Strohm mentions the problem of a hung AVR deadlocking the entire system. That's indeed a risk which needs to be considered, but an entirely different subject ;-)

Rob

don't

and

battle

rest.

useful

so

Not possible directly because reads and writes take place over 3 cycles... Though it could be done using a creative setup.

In case the other replies haven't convinced you of this, yet: this means you're going to open the box of Pandora. Trying to share memory between processors that are not prepared for multi-processor setups with shared memory is going to be a nightmare. Micros simply don't expect such a thing as "memory temporarily not available, please try again later" type of situations to ever occur.

In the essence, that SRAM cannot possibly be attached directly to all the processors in the way you would normally attach SRAM to a micro. You will either have to bit-bang some of the control lines, or hide the RAM behind a special multi-port controller that does nothing but arbitrate accesses to the ram between all those chips.

In the effect, whatever approach you choose, access to this shared RAM will never work the normal way from the software side --- it'll have to be handled more like you would usually handle a large EEPROM chip attached to the micro via I2C or SPI: every access is a subroutine call or assembler macro instead of a simple native opcode.

Thanks to everyone for your help. As I said earlier, my motivation for this question was curiosity as opposed to any specific design goal. From what I can see, shared SRAM can certainly be done, but with some special considerations. In any event, I've got some good seeds for research and experimenting, so thank you for your assistance!

Note the word OTHER, as in not AVR's.

Ralph

clock

cycles...

and systems. The "systems" could plausibly refer to the method by which the desired results are achieved. As in dual port sram, arbitration, etc.

Here's an idea I've seen successfully implemented on a z80 based system, very simple and effective.

Basically to keep the CPU off the data and address bus, because another device needed to access is, the clock to the z80 was stopped !! It was held low ( IIRC ) for as long as the second device needed the bus. When the other device had finished the clock was restored.

I have no idea if this would work for the AVR's, might be worth an experiment or two.

- James

------------------------------ JrokLand

------------------------------

I only know of one system which did that, it was the old Sinclair Spectrum of a quarter century ago , when Z80 was sharing the upper 16k RAM with the Ferranti ULA (remember _that_) . Is that the system you were referring to ?

Regards, Matt Tudor , MSEE

Bingo !! I wondered if anyone would recognise where that came from ;-)

- James

------------------------------- JrokLand

-------------------------------

I am pretty sure this would be suitable on a AVR since it uses multiple cycles to do a memory access. You would be likly just to stop it while it was driving the lines.

As with any gated clock you would need to be careful not to generate a runt pulse when you restart it.

Ralph.

runt

You could use a token, same as an earlier post but now the other way around: get a counter and a 3 to 8 decoder and a clocksource, the cpu's check the output of their 3 to 8 feedingline and if its high block the counter and get on with it. When they are finished, release the clock and the next cpu has access if it takes control of the clock.

common

CD4532)

read

down.

PLEASE PLEASE PLEASE don't try to design mutual exclusion algorithms or hardware at the keyboard!!!

SPEND SOME TIME to do the library research and learn how to do it right.

it

Whats use are wheels if you can't reinvent them?

Ralph

Sorry for the typo I missed the last 'word'.

It should read:

"What use are wheels if you can't reinvent them ;-)"

Is the a tounge in cheek simily? :^)

Ralph

Oh, I inferred the existence of the smiley. I was just commenting that the quality of the forum in which one asks a question determines the quality of the answer. Online forums do not encourage exhaustive research. Nevertheless, I do believe my ad-hoc solution was superior to the original ad-hoc solution. Of course if I was actually being called upon to build a real product for someone, I would take rather more effort with it than two minutes of unresearched thought.

-- Lewin A.R.W. Edwards