TWI oder SPI für Mikrokontroller Kommunikation?

matsch Gast #154414 
Hallo

Ich muss nun erstmals für ein Projekt mehrere Mikrokontroller
miteinander vernetzen.
Und zwar soll es einen Master und zwei Slaves geben. Die Slaves sollen
eine Reglungsaufgabe übernehmen.
Der Master liefert dafür die nötigen Werte.
Ich habe nun die Frage welche Kommunikationsmethode sich besser eignet?
Welche Übertragungsart ist schnelle und besser zu realisieren. da die
Reglung (welche die Slaves übernehmen) möglichst ständig ablaufen soll,
soll es auch wenn möglich zu kurzen / keinen Unterbrechung beim Empfang
der Daten geben. Wie sieht das bei den beiden Methoden aus? Welche
Übertragungsweglängen kann man erreichen? Als Prozessoren sollen
ATmega128 Verwendung finden. (Ist aber auch noch möglich ganz andere
Modelle z.B. mit CAN zu nehmen)
Ich hoffe die Experten können mir Helfen, den rechten Pfad zu finden.


Danke Euch!
matscher
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Langsamer Modus Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Melden Danke
Tobias Schneider Gast #154417 
Hi,
ich denke, dass du bei nur zwei slaves am besten spi benuzt und ihnen
je eine cs leitung vom m128 zuordnest. spi ist meiner ansichtnach
naemlich wesentlich weniger komplex als i2c

Gruß Tobias
Antwort Zitieren Bearbeiten Löschen Melden Danke
josef Gast #154418 
Wie weit sind die Prozessoren voneinander entfernt ? Datenmenge ?
Was für Messwerte sind aufzunehmen ? Wer sendet wann ? Störsicherheit ?
Umfeld ? Glaskugel...

SG Josef
Antwort Zitieren Bearbeiten Löschen Melden Danke
Peter D. #154419 
Zuerst sollte man sich wirklich sicher sein, daß man wirklich mehrere
µCs benötigt.

Die Vernetzung ist alles andere als einfach (Protokoll,
Fehlererkennung, Datenkonsistenz, Reaktionszeit usw.) und kostet immer
ne Menge Ressourcen.


Der SPI-Bus hat den Nachteil, daß die Slave-Transmitterfunktion
ungepuffert ist. D.h. will der Master Daten vom Slave lesen, muß er
nach jedem Byte eine Wartezeit einlegen, die so groß ist, daß der Slave
auch im Worst Case genug Zeit hatte, ein neues Byte in das Senderegister
zu stellen.

Nur einige neuere Atmel 8051-er haben einen SPI Sendepuffer, d.h. sie
können schon ein neues Byte in den Sendepuffer stellen, wärend der
Master noch das vorhergehende Byte ausliest.
Obendrein haben sie 4 Interruptprioritäten, d.h. sie können so
konfiguriert werden, daß der SPI Interrupt immer Vorrang hat. Selbst
wenn andere Interrupts gerade am Laufen sind, werden die dann
unterbrochen.


Der I2C-Bus ist etwas komplizierter zu programmieren, hat aber den
Vorteil, als Multimaster (nur mit Hardware-I2C) arbeiten zu können.
Dabei kann der Master senden, wann er lustig ist und auch die Slaves
können antworten, wenn sie Zeit und Lust haben. Niemand muß also auf
den anderen warten (wie bei CAN).
Nur wenn einer mal die Arbitration verliert, muß er das Senden nochmal
starten.

Leider habe ich festgestellt, das zumindest im ATMega8 das I2C nicht
bugfrei ist, d.h. es bleibt manchmal hängen, ohne das ein Interrupt
ausgelöst wird. Deshalb habe ich den SDA-Pin mit auf einen Interupt
gelegt und prüfe im Timerinterrupt, ob er innerhalb 5ms ausgelöst wurde
oder der Pin high ist. Wenn nicht, wird das I2C disabled und wieder
enabled, um die Blockierung aufzuheben.



Peter
Antwort Zitieren Bearbeiten Löschen Melden Danke
Thread beobachten

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 21 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.

Dein Name und deine E-Mail-Adresse

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.