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
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
Wie weit sind die Prozessoren voneinander entfernt ? Datenmenge ? Was für Messwerte sind aufzunehmen ? Wer sendet wann ? Störsicherheit ? Umfeld ? Glaskugel... SG Josef
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.