Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Message

Re: [AVR-Chat] 2 ATmega128 sharing one external SRAM?

2005-03-27 by Philipp Adelt

David Kelly schrieb:
> How fast must each CPU access the shared RAM? Not video speeds, I 
> presume?

This is correct. The speed itself is not that much a problem. But 
latency may become a problem.
Let me give you a short introduction into the idea: The system consists 
of several nodes that are physically attached to each other via a 
proprietary parallel and asynchronous bus that transfers on the order of 
5MBytes/s. As the bus will be completey timing invariant, slow nodes 
(that I count the AVR based ones to) slow down the bus but will work. To 
keep the slowdown small I need to achieve low latencies in transfers 
that incorporate AVR based nodes.

Two AVRs on the board share the load associated with the nodes' tasks. 
One AVR will be responsible for keeping up communication over the 
bus(es). This will be quiet a challenge for a 16MIPS 8bit device but in 
the current state it seems feasible.

The other AVR will do "real system" interaction. A/D, digital I/O with 
synchronous timing and a bunch of calculations upon this data. As this 
will have some tight timing constraints that require interrupt use for 
almost all of the inputs, it will be hard to join both AVRs.

> Then why not consider a serial RAM? Put it on the SPI bus on each CPU. 

An interesting idea. I will have a look at speeds that are achievable. I 
am somewhat concerned that the number of CPU cycles it takes to write a 
set of bytes will be too high, but I'll see.

> Then if you can't accept only one AVR as master the other as slave you 
> only have to deal with a voting scheme to determine which AVR gets 
> master status.

I will have to do this in every case I guess. There will be a simple 
round robin mechanism to ensure mutual exclusive accesses to the 
external RAM on software level.

> Would be interested in why you think you need two CPUs rather that one 
> CPU twice as fast.

Guess most of what I wrote above applies here. In fact, latency and 
number of usuable interrupts are the limiting factors. Number of I/O 
pins (with edge level interrupt) is interesting, too.
Not to forget that I have designed a lot of working real life devices in 
the <=16MHz area but so far have never touched real high speed systems. 
Being a non-electrical engineer I would prefer to keep the board design 
issues simple (and in my area of expertise so far).

Regards,
Philipp

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.