Hallo, ich steh vor der Frage ob I2C oder doch besser SPI. Und zwar möchte ich zwei Controller miteinander kommunizieren lassen. Dabei itses wichtig das es zu keinen Datenverlusten bzw. Übertragungsfehlern kommt. Bei meiner bisherigen recherche konnte ich dazu leider keine Angaben finden. Hat von euch vielleicht jemand eine passende Quelle parat?
irge schrieb: > ich steh vor der Frage ob I2C oder doch besser SPI. > Dabei itses wichtig das es zu keinen Datenverlusten bzw. > Übertragungsfehlern kommt. Übertragungs-Fehler sind nicht ausschließbar, die Herausforderung ist es diese zu korregieren. Das ist aber Aufgabe der physikalsichen Schnittslette sonden drüber liegenden Schichten. Es ist also die Frage , welche Fehlerkorrektur man einsetzt und nicht ob I2C oder SPI. Gruß,
Also das in Bezug auf die Datenrate der SPI besser ist ist mir bewusst. Für mich ist jetzt besonders wichtig wie es mit der Übertragungssicherheit aussihet. Ja theoretisch kommt auch UART in betracht
irge schrieb: > Für mich ist jetzt besonders wichtig wie es mit der > Übertragungssicherheit aussihet. Da würde ich tendenziell auch sagen das SPI besser ist, da hier beide Pegel (H/L) aktiv getrieben werden, während bei I2C nur das L-Signal aktiv generiert wird, das H-Signal kommt über die typischen Pull-Up's. irge schrieb: > Ja theoretisch kommt auch UART in betracht Ich würde SPI vorziehen, da hier auch nicht das Takt-Problem auftaucht, da der Slave den Takt vom Master vorgegeben bekommt und es so nicht zu Unstimmigkeiten kommen sollte.
Ein SPI Slave kann einen SPI Master nicht so einfach ausbremsen und die SPI-Module mancher µCs sind für Slaves nicht grad gut geeignet - beispielsweise bei den AVRs. Beim Zeitverhalten ist I2C verträglicher. Möglicher Datenverlust und Störungen lassen sich in beiden Fällen nur mit Kontrolle per Software sicher verhindern.
Ich gehe im Folgenden von einfachen Architekturen wie z.B. dem ATmega aus: Als Slave ist Uart wesentlich unproblematischer als SPI, weil der UART doppelt gepuffert ist. Das heisst: der Sender kann das 2.Byte direkt nach dem 1.Byte losschicken. Der Empfänger hat dann die Übertragungszeit des 2.Bytes Zeit, um das 1.Byte abzuholen. Beim SPI muss der Slave das 1.Byte holen, bevor der Sender das 2.Byte beginnt. In der Praxis muss de Sender zwischen den Bytes deshalb Delays einfügen. Bei IIC ist der Aufwand ziemlich abhängig vom verwendeten Controller. Eine IIC-Slave-Implementierung ist deutlich komplexer als UART oder SPI. Eine Fehlerkorrektur ist in keinem dieser Protokolle auf Hardware-Ebene implementiert. CAN hat eine hardwareseitig eien CRC-Checksumme eingebaut. Die Fehlerkorrektur ist also der Job Deines Protokolls. Gruß, Stefan
irge schrieb: > Dabei itses wichtig das es zu keinen Datenverlusten bzw. > Übertragungsfehlern kommt. Dann scheidet SPI aber aus, da oft kein Sendepuffer im Slave ist. D.h. der Master hat keine Chance, zu erkennen, ob der Slave gültige Daten oder Mumitz sendet.
@Peter: Alte Wandergruppen-Weisheit: die Pausen haben sich am schwächsten Gruppenmitglied zu orientieren ;-)
Stefan K. schrieb: > Alte Wandergruppen-Weisheit: die Pausen haben sich am schwächsten > Gruppenmitglied zu orientieren ;-) Was aber besser funktioniert, wenn man miteinander redet. Wenn man das aber nicht kann, weil das über die gleiche Schnittstelle liefe, muss man auf Verdacht so lange warten, bis unter allen widrigsten Umständen genug Zeit bleibt. Oder muss eben doch Quittungen für Meldungen einbauen.
>> Alte Wandergruppen-Weisheit: die Pausen haben sich am schwächsten >> Gruppenmitglied zu orientieren ;-) > >Was aber besser funktioniert, wenn man miteinander redet. Das schwächste Mitglied der Gruppe wird aber meistens nicht zugeben, daß es nicht mehr kann... Spaß beiseite, ich stimme Dir und Peter voll zu (wie oben bereits angedeutet). Gruß, Stefan
Als ich würde auch SPI nehmen, ohne ausführliche Begründung. Was mich eigentlich interessieren würde, wie planst du zu kommunizieren? Ich hatte auch schonmal das Problem, hab es aber dann gelassen, weil ich es zu komplex fande mit dem Slave Daten zu übermitteln, wenn man in beiden Controllern alle Umstände beachten muss ( also der normale Programmablauf ) plus ggf. auch TX RX Interrupts zu reagieren, weil ich nie genau wusste wann der Slave senden wird, bzw da nicht einfach abwarten konnte, vielleicht ist es bei dir ja anders oder du hast eine hübsche Lösung dafür gefunden, wenn du darüber mehr schreiben magst, würde mich freuen. Viele Grüße.
Stefan K. schrieb: > Alte Wandergruppen-Weisheit: die Pausen haben sich am schwächsten > Gruppenmitglied zu orientieren ;-) Und das ist im I2C bereits eingebaut, nennt sich Clock-Stretching. Der Master muß die Wartezeit nichtmal sinnlos vergeuden, er kriegt den Interrupt erst, wenn der Slave bereit ist. Bei SPI muß der Master Annahmen treffen, wieviel Pause nach jedem Byte gebraucht wird. Und zwar für den Worst-Case, d.h. oftmals viel länger als nötig.
@Peter: Das sehe ich auch so. SPI halte ich für ungeeignet. I2C funktioniert je nach Controller gut, hat aber einen (je nach Controller) nicht unerheblichen Firmware-Aufwand. UART finde ich am einfachsten, wenn bei Master/Slave diese noch frei sind. Ohne die Beantwortung von: Welche Datenrate? Welche Controller? finde ich eine weitere Diskussion aber ziemlich sinnlos. Gruß, Stefan
Peter D. schrieb: > Bei SPI muß der Master Annahmen treffen, wieviel Pause nach jedem Byte > gebraucht wird. Und zwar für den Worst-Case, d.h. oftmals viel länger > als nötig. Nööö nicht wirklich. Man muss die SPI nicht im puren 3 Wire Modus betreiben. Nimm den 5 Wire Modus und schön können beiden sich gegenseitig signalisieren. Viel interessanter für die Auswahl sind jedoch andere Punkte. 1. Benötigte Datenrate 2. Entfernung 3. Störungssicherheit 4. Anzahl der Teilnehmer in der Verbindung 5. In welcher Umgebung soll das ganze später laufen. Can zb ist durchaus auf den Einsatz in störungsreicher Umgebung( AUTO) ausgelegt. I2C dagegen überhaupt nicht, das ist für Kommunikation auf einer Platine ausgelegt. SPI ist da schon flexibler, kann mit symetrischen Treiberbausteinen auf ganz erstaunlicher Längen mit recht flotter Übertragungsrate in störungsreicher Umgebung funktionieren.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.