I2C oder SPI

Welche Datenrate? Kommt Kommunikation über Uart auch in Frage?

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

Wenn man wegen Tempo SPI braucht, dann ist ein µC mit DMA kein Fehler.

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 ;-)

Welche Datenrate?

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