Schnelle kommunikation zwischen mehr als AVRs ?

Gast #455226
Hallo,

fuer einen Versuch moechte ich 3 AVRs ueber einen Bus miteinander 
kommunizieren lassen, jeder soll aber jedem Nachrichten schicken 
koennen. Mit I2C habe ich schon ein wenig Erfahrung, aber das laeuft ja 
maximal mit 400 kHz (richtig? also, 400kHz-overhead(?) /8 bits -> n 
byte/sec), andereseits kann ich die Zeit gut im uC selbst nutzen, da das 
versenden der bits ja in HW erledigt wird. Hat jemand schon Erfahungen 
mit Multimaster I2C Netzen (mehr als 2 Master)?
Oder gibt es eine bessere Methode? Den USART moechte ich eigentlich 
nicht dafuer verwenden, den nutze ich zzt fuers Debugging.
Ein eigenes Protokoll waere natuerlich auch moeglich, aber dann 
verzichte ich auf jegliche HW-Unterstuetzung und muss alles in SW 
machen, ob ich dann noch schneller bin als I2C? Hat jemand schon soetwas 
gemacht, unter welchem Begriff kann ich solche und aehnliche Themen 
finden?

Gruss,
Michael
Gast
Hi,

habe eine Kommunikation zwischen 5 Fujitsu-Mikrocontrollern und 2 
externen I2C Bauteilen mal aufgebaut. Letztendlich nur mit einem Master 
und 6 Slaves. Aber Mit Multimaster klappt das natürlich auch.
400k ist aber normalerweise schon recht viel. Was hast du denn für eine 
Übertragung vor (Daten/Zeit)?

Marc989
Gast
Hallo Marc989,

sind die 400k bei I2C nicht die maximale Clockfrequenz? da kaem ich so 
auf 24 byte/sec. Da jeder einzelne AVR nicht viel mit den Daten arbeitet 
(jeder nur einen Teilschritt) wird viel uebrtragen und (relativ) wenig 
gerechnet.
Bekommt der AVR im I2C slave Modus fuer jede Zieladdresse einen 
Interrupt, oder nur wenn er explizit angesprochen wird?

Gruss,
Michael
Gast
Die Durchsatzrate bei USART und RS485 dürfte allemal höher als bei I2C 
sein, da so gut wie nur Rohdaten übertragen werden, ohne die ganze 
Steuer- und Bestätigungskinematik.
Gast
Hi TravelRec,

bei der Kommunikation ueber RS485 muss ich mich dann aber selbst um die 
Adressierung kuemmern, also jeder Controller muss alle Daten empfangen 
und dann selbst entscheiden, ob sie fuer ihn bestimmt waren. Wenn sich 
an einem Bus also zwei Controller unterhalten, wird der Dritte immer 
wieder gestoert. Ist das so Richtig?
Bei I2C macht das doch (hoffentlich) die HW? Ich hab allerdings noch nie 
einen AVR als I2C Slave betrieben, weiss also nicht ob das so stimmt 
(ich such mal im Datenblatt)

Gruss,
Lothar
Gast
Beim USART kann man das 9te Bit für Mulitprozessorkommunikation 
benutzen. Das ist genau für diesen Fall entwickelt worden. Die 
Prozessoren, bei denen die Adresse bei gesetztem 9ten Bit nicht paßt, 
machen in Ruhe weiter ihre Arbeit und ignorieren den folgenden 
Datenstrom, bis wieder mal das 9te Bit gesetzt ist. Der jeweils 
angesprochende Prozessor empfängt dann die Daten. Die genaue Verwendung 
des 9ten Bits ist super im Datenblatt beschrieben.
Gast
> da kaem ich so auf 24 byte/sec.

Rechenfehler, Schreibfehler oder Systemfehler ?
Selbst wenn es 'nur' 24kB/s sind, viel schneller können die AVRs die 
Daten auch nicht bearbeiten, mal von trivialen Manipulationen abgesehen. 
Aber dafür bräuchte man nicht mehrere AVRs. (Systemfehler ?)

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 19 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.