Forum: Mikrocontroller und Digitale Elektronik TWI oder SPI für Mikrokontroller Kommunikation?


von matsch (Gast)


Lesenswert?

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

von matsch (Gast)


Lesenswert?

keiner einen tipp für mich?

von Jörn (Gast)


Lesenswert?


von Tobias Schneider (Gast)


Lesenswert?

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

von josef (Gast)


Lesenswert?

Wie weit sind die Prozessoren voneinander entfernt ? Datenmenge ?
Was für Messwerte sind aufzunehmen ? Wer sendet wann ? Störsicherheit ?
Umfeld ? Glaskugel...

SG Josef

von Peter D. (peda)


Lesenswert?

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

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.