Kommunikation zwischen 2 µC mit I²C oder SPI?

[Boxer (Gast)]

Hallo,

ich stehe vor der Frage ob ich zur Kommunikation zwischen zwei 
Mikrocontrollern den I²C oder SPI Bus verwenden soll...

Was spricht dafür und was spricht dagegen? Welchen Bus würdet ihr mir 
empfehlen dafür zu benutzen?

DANKE

[Johann L. (gjlayde)]

Wenn es nur 2µC sind, bietet sich SPI an, da es einfacher  zu 
implementieren ist. Zudem geht es (etwa auf AVR) schneller. Allerdings 
brauchst Du ne Strippe mehr.

[Nico E. (masta79)]

Alles eine Frage der Anforderungen und der Umgebung. Hast du noch genug 
Pins frei und musst die Daten schnell übertragen? Dann ist SPI meist die 
bessere Wahl.

Hast du sonst schon I²C Slaves und musst Pins sparen? Dann nimm I²C.

Ganz so pauschal kann man das meist nicht sagen, ich persönlich nehme 
aber lieber SPI solange es die Umgebung zulässt.

[Andreas K. (a-k)]

Wenn du AVRs meinst, dann I2C. Deren SPI ist im Slave-Mode mangels 
Sendepuffer ziemlich hirnverbrannt.

[Boxer (Gast)]

Andreas, kannst du bitte genauer erklären, was du mit dem Sendepuffer 
meinst, und warum I²C zu bevorziehen ist?

[Nico E. (masta79)]

Naja, das Problem ist ganz einfach das der Slave warten muss bis das 
aktuelle Byte komplett beim Master ist, bevor er das nächste byte 
einstellen kann.

Bei 8MHz Systemtakt und 1MHz SPI-Takt würde das im schlimmsten Fall 
bedeuten das man maximal 8 Takte zur Verfügung hat um das nächste Byte 
zur Verfügung zu stellen. Im Normalfall eher weniger. Das ganze führt 
dazu das der Master zwischen den Bytes kleinere Pausen einlegen muss in 
denen kein weiterer Takt gegeben wird um dem Slave ein wenig Zeit zu 
geben. Damit das ganze dann aber wiederum sicher klappt darf der Slave 
sich in dem moment nicht in einem anderen Interrupt befinden etc. Eine 
andere Möglichkeit wäre wenn der Slave dem Master signalisiert wann die 
Daten bereitstehen.

Ein Sendepuffer auf Seiten des Slaves würde das ganze vereinfachen. Die 
eleganteste Lösung wäre aber wohl wenn man dem SPI einen Speicherbereich 
angeben könnte den es dann ausliest.

Bei I²C hat der Slave die Möglichkeit des Clockstretchings um dem Master 
in solchen Fällen zu signalisieren das er noch ein wenig Zeit braucht.

[Simon K. (simon)]

Nico Erfurth wrote:
> Naja, das Problem ist ganz einfach das der Slave warten muss bis das
> aktuelle Byte komplett beim Master ist, bevor er das nächste byte
> einstellen kann.
>
> Bei 8MHz Systemtakt und 1MHz SPI-Takt würde das im schlimmsten Fall
> bedeuten das man maximal 8 Takte zur Verfügung hat um das nächste Byte
> zur Verfügung zu stellen.

Ne, das stimmt nicht. Man hat 8x8 = 64 Takte zur Verfügung.

[Nico E. (masta79)]

Simon K. wrote:

> Ne, das stimmt nicht. Man hat 8x8 = 64 Takte zur Verfügung.

Um das nächste Byte vorzubereiten, ja, aber nicht um es der SPI 
bereitzustellen. Wie Andreas schrieb, die SPI ist fürs senden nur single 
buffered. Dadurch bleibt dir nur zeit zwischen zwei takten. (Ausser ich 
hab da jetzt einen massiven Denkfehler.)

[Andreas K. (a-k)]

Exakt so ist es. Ohne zusätzliche Leitung für einen "busy/ready" Status 
oder einen Interrupt zwischen Master und Slave ist es für den Slave 
schwierig, einen wasserdicht sicheren Zeitpunkt zu finden um ins 
Schieberegister zu schreiben ohne in einen grad laufenden Transfer zu 
laufen und sich damit nur WCOL einzuhandeln.

Bei niedriger Bitrate ist das kein Problem, wohl aber bei hoher.

Manch andere einfache Implementierung von SPI besitzt einen separaten 
Sendepuffer. Dadurch wird zwar der Masterbetrieb eine Spur komplizierter 
als bei den AVRs, aber der Slavebetrieb wird so wesentlich vereinfacht.

Bei I2C oder UART entsteht dieses Problem nicht.