Zwei oder mehr AVR auf kurze Distanz mit 1 Mbit/s kommunizieren lassen

Gast #4180954
Lesenswert?
• ▲
▼
Hi.

Wie würdet ihr folgendes angehen:

Es gibt einen "Hauptprozessor", von dem über einen kleinen, 
geräteinternen Bus mit Logikpegeln die Slave Prozessoren (maximal 8) 
abgefragt werden.

Dies soll möglichst schnell und mit geringer Latenz erfolgen und mit 
wenig Codeaufwand erfolgen.

Ob Seriell oder Parallel ist egal.
Das ganze soll mit ca 1 Mbit/s arbeiten und den "Backplane Bus" im Gerät 
darstellen, welcher mit Flachbandleitung und Schneid-Klemm-Steckern 
realisiert wird.


Die UART Schnittstellen der Prozessoren stehen nicht zur Verfügung.

SPI ginge möglicherweise.

Oder einfach 4-8 Datenleitungen und 1 Taktleitung nehmen?

Der Sendendene Prozessor schaltet seinen Port auf Ausgang, legt das 
Nibble bzw das Byte an und setzt die Bus Clock Leitung auf high, um den 
anderen Prozessoren mitzuteilen, dass Daten anstehen.

Diese lesen die Daten mit der steigenden Flanke der Clock Leitung in ein 
Register ein.

Für das nächste Nibble oder Byte wiederholt sich der Vorgang.

Im Ruhezustand sind die Ports bei allen Prozessoren auf Eingang 
geschaltet.



Oder habt ihr eine bessere Idee?
#4180987
Lesenswert?
• ▲
▼
Den i2c Takt kann man zwar so hoch drehen (und auch noch viel höher) 
allerdings muss man dann auch entsprechend niederohmige pullup 
Widerstände verwenden damit die Pegel der Leitungen in entsprechend 
kurzer Zeit auch wieder auf den high-pegel gehen. Ich würde eher zu spi 
bzw Software spi greifen. Auch mit Software spi solltest du locker auf 1 
Mbit/s kommen sofern der uC mit 16 Mhz getaktet ist
Gast #4181013
Lesenswert?
• ▲
▼
Sven schrieb:

> Die UART Schnittstellen der Prozessoren stehen nicht zur Verfügung.

Warum nicht? Es gibt ja schließlich etliche µC, die über mehr als eine 
UART verfügen.

> Oder einfach 4-8 Datenleitungen und 1 Taktleitung nehmen?

Das ist kompletter Mist, da fehlt ein Handshake-Mechanismus. Vom nötigen 
Aufwand, einen parallelen Bus ordentlich zu routen mal ganz abgesehen. 
Die Sache hat allenfalls dann eine Daseinsberechtigung, wenn alle µC 
synchron laufen, dann kann der Handshake entfallen.

> Oder habt ihr eine bessere Idee?

Ja. Man nehme µC mit zwei UARTs. Pfuff, Problem löst sich in Luft auf...
Gast #4181038
Lesenswert?
• ▲
▼
Sven schrieb:
> Es gibt einen "Hauptprozessor", von dem über einen kleinen,
> geräteinternen Bus mit Logikpegeln die Slave Prozessoren (maximal 8)
> abgefragt werden.

c-hater schrieb:
> Ja. Man nehme µC mit zwei UARTs. Pfuff, Problem löst sich in Luft auf...

Nein. Man nehme die SPI und verwende für jeden Prozessor einen
eigenen Chip Select.
Gast #4181053
Lesenswert?
• ▲
▼
SPI kann man auch "daisychainen"? Dann hat man ein langes 
Schieberegister. Notfalls hat man ein spezielles Bitmuster, das, wieder 
beim Master angekommen, konfigurationsfrei die aktuelle Länge der Kette 
zeigt. Aber für einen Flachandkabelbus bräuchte man dann sowieso 
Konfigurations-Jumper auf jedem Slave.
Gast #4181097
Lesenswert?
• ▲
▼
Also ich würde momentan dazu tendieren, SPI zu nehmen, in 
Parallelschaltung, nicht in Daisy Chain.

Wegen dem SS Signal: Kann man das auch fest verdrahten, so dass das SPI 
Interface am Prozessor immer aktiv ist, damit jeder Controller alles 
mitlesen kann? Und den Sendezweig dann einfach über einen Tristate 
Buffer führen, welcher durch den Client angesteuert wird, wenn er senden 
möchte?

Zusätzlich würde ich dann noch den TWI Bus mit verdrahten, wlcher dann 
im LowSpeed Modus betrieben wird, für die Steuerung.

Die High Speed Daten laufen dann also vom Master zu den Slaves als 
"Broadcast" über SPI, für die direkte Client to Client Kommunikation und 
Steuerung steht dann der TWI Bus zur Verfügung.

Könnte man das so machen?

Mfg
#4181239
Lesenswert?
• ▲
▼
Eine wichtige Frage ist, ob die 1 MBit/s denn kontinuierlich sind oder 
nur in Bursts gebraucht werden. Bei letzteren kann man schon mal einen 
kleinen 4 oder 8 Bit Bus machen, besonders wenn die Mikrocontroller 
parallel laufen. Du kannst so auch noch schneller Arbeiten, im Prinzip 
bis raus zu 4 Megaworte pro Sekunde auf einem 16 MHz ATMega. Dann ist 
der zwar komplett ausgelastet, muss das aber nicht die ganze Zeit 
machen.

CAN ist natürlich für so was völlig ungeeignet. Ja man kann den CAN-Bus 
mit 1MBaud laufen lassen, durch den Overhead und den winzigen 
Paketgrößen kriegt man da nur einen kleinen Teil als Nutzdatenrate. 
Sprich auf maximal 64 Bits kommen 43 Bits für die Verwaltung. (plus 
Stopfbits natürlich)

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren