Allowing Multiple AVR Microcontrollers to Share SRAM

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I'm a hobbyhist -- and relatively new to microcontrollers -- and I'd
like to set up two or more AVR microcontrollers (90S8515s, if it
matters) such that they can both read and write to some shared SRAM.
I'd like to know to how I should build the circuit so the micros don't
interfere with each other (e.g., prevent two of them from writing at
the same time, etc.).  I'm interested in both typical and low-cost
methods (in case they are not the same ;-) ) of designing such a
system.

If my question is easily answered in an undergrad textbook, please
forgive me.  If such is the case, I'd appreciate book suggestions and
the relevant topics.

Thank you for your help.

Re: Allowing Multiple AVR Microcontrollers to Share SRAM
Quoted text here. Click to load it

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



Re: Allowing Multiple AVR Microcontrollers to Share SRAM
Quoted text here. Click to load it

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.

Re: Allowing Multiple AVR Microcontrollers to Share SRAM

Quoted text here. Click to load it
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.



Re: Allowing Multiple AVR Microcontrollers to Share SRAM

 > Some other systems may only access on a particular phase of a given clock
Quoted text here. Click to load it

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

Ralph




Re: Allowing Multiple AVR Microcontrollers to Share SRAM
Quoted text here. Click to load it
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.



Re: Allowing Multiple AVR Microcontrollers to Share SRAM
Quoted text here. Click to load it

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



Re: Allowing Multiple AVR Microcontrollers to Share SRAM
Quoted text here. Click to load it
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.

Quoted text here. Click to load it
CD4532)
Quoted text here. Click to load it
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).



Re: Allowing Multiple AVR Microcontrollers to Share SRAM
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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



Re: Allowing Multiple AVR Microcontrollers to Share SRAM
Quoted text here. Click to load it
common
CD4532)
Quoted text here. Click to load it
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.



Re: Allowing Multiple AVR Microcontrollers to Share SRAM

Quoted text here. Click to load it
it

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

Ralph



Re: Allowing Multiple AVR Microcontrollers to Share SRAM
Quoted text here. Click to load it

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



Re: Allowing Multiple AVR Microcontrollers to Share SRAM

Quoted text here. Click to load it

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
http://www.zws.com /
Buy my book! (Amazon.com product link shortened)

Re: Allowing Multiple AVR Microcontrollers to Share SRAM

Quoted text here. Click to load it

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.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Allowing Multiple AVR Microcontrollers to Share SRAM
snipped-for-privacy@yahoo.com (Brian Nichols) wrote in message
Quoted text here. Click to load it


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!

Re: Allowing Multiple AVR Microcontrollers to Share SRAM
In article snipped-for-privacy@yahoo.com says...
Quoted text here. Click to load it

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 http://www.jrok.com
------------------------------


Re: Allowing Multiple AVR Microcontrollers to Share SRAM

Quoted text here. Click to load it

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
http://www.gigahertzelectronics.com







Re: Allowing Multiple AVR Microcontrollers to Share SRAM
In article "matt" says...
Quoted text here. Click to load it

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

- James

-------------------------------
 JrokLand  http://www.jrok.com
-------------------------------


Re: Allowing Multiple AVR Microcontrollers to Share SRAM
Quoted text here. Click to load it

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.



Re: Allowing Multiple AVR Microcontrollers to Share SRAM
Quoted text here. Click to load it
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.



Site Timeline