Ich muss für die Schule die Vor und Nachteile von I2C und SPI und deren Anweundungsgebiete zusammenfassen, habe schon gegoogelt und habe folgendes gefunden:
Spi:
Vorteil: fuer kleine Systeme geeignet (weiß jedoch nicht warun)
Nachteil: keine Fehlerabsicherung bei der Datenübertragung
Anwendung: Audiobereich, kommunikation zwischen mehreren Microcontroller, Pontiometer
I2C:
Vorteil: kostengünstigst, einfach zu erweitern, wenige leitungen
Bei I2C hat jeder Teilnehmer eine eigene Adresse. Das kann zu Problemen führen wenn du mehrere gleichartige Geräte hast. Bei manchen ICs kann man über Pins die Adresse einstellen. Aber nicht bei allen. Da braucht man dann I2C Multiplexer was wieder mehr Hardware ist.
SPI hat das Problem nicht, da jeder Teilnehmer über einen Chip Select Pin aktiviert wird. Das heißt aber auch dass man dafür auf dem µC Pins belegt. Deshalb ist es für viele Teilnehmer schlecht.
SPI erlaubt generell höhere Geschwindigkeiten
kommunikation zwischen mehreren Microcontroller
Das geht auch mit I2C einfach. Es wurde ja auch ursprünglich für die Kommunikation zwischen verschiedenen ICs entwickelt
Die Geschwindigkeit liegt eher daran wie es spezifiziert ist. Wobei wenn ich auf Wikipedia schaue dann gibt es da wohl auch inzwischen Hochgeschwindigkeits-Modi mit bis zu 5 MHz. Das ist aber ziemlich neu und 400 oder 800 kHz ist bei Peripherie-Bausteinen üblich
Das wird auch der Grund sein weshalb man bei ICs wo es auf Geschwindigkeit ankommt eher SPI als I2C sieht. z.B. ADCs. Ist aber Spekulation
Ich hätte noch eine Frage das Taktsignal(Clock) gibt an wan die bits abgetastet werden entweder bei steigender oder fallender Flanke oder ? .... Sowohl bei SPI und auch bei I2C bei I2C wird das Taktsignal vom aktuellen Busmaster erzeugt und bei SPI gibt es ja sowieso nur einen Master --> lege ich da mit der Annahme richtig?
Beide, SPI und I2C haben keine implementierte Fehlerabsicherung bei der Datenübertragung. Natürlich kannst Du über die übertragenen Daten ein Quersumme erzeugen und diese kontrollieren. Das ist aber nicht Teil der Schnittstellenspezifikation.
Der SPI ist schneller da die Ausgänge Totem Pole Schaltung haben ( ein Transistor zieht auf Masse und ein zweiter auf Versorgungsspannung). I2C hat den Zweiten transistor nicht. Da ist ein Widerstand für HIGH zuständig. Dieser muß die Leitungskapazitäten nach einem LOW laden und muß den (geringen) Strom für die Eingänge liefern; er darf nicht zu klein sein da ansonsten der andere Transistor kaputtgeht.
I2C hat Geschwindigkeiten von 100k, 400k und 3,4M Hz zertifiziert.
SPI kann bis mehrere 10MHz gehen.
Viele Bauteile gibt es als SPI und I2C Version. Auch haben verschiedene Baugruppen wie zB Displays beide Schnittstellen.
PAXON999:
Ich hätte noch eine Frage das Taktsignal(Clock) gibt an wan die bits abgetastet werden entweder bei steigender oder fallender Flanke oder ? .... Sowohl bei SPI und auch bei I2C bei I2C wird das Taktsignal vom aktuellen Busmaster erzeugt und bei SPI gibt es ja sowieso nur einen Master --> lege ich da mit der Annahme richtig?
SPI kann mit steigender oder fallender Taktsignalflanke funktionieren. Auch kann LOW bzw HIGH als Idle Zustand (Leerlauf) des Taktes definiert werden. Daren können MSB (Höchstewertigstes Bit zuerst) oder LSB gesendet werden.
Genaues verrät der Wikipedia Artikel: Serial Peripheral Interface – Wikipedia
I2C sind die Daten während der HIGH Zustandes des Taktes gültig. I2C beherrscht nur MSB. I²C – Wikipedia
Bei I2C gibt es ja eigentlich schon eine Fehlerabsicherung oder? Anfangs wird ja eine Start condition von dem master gesendet dann wird eine 7 Bit Adresse übertragen mit dem 8 Bit wird dem Slave mitgeteilt ob er Daten empfangen oder senden soll und mit dem 8 Bit bestätigt doch der slave und erst dan werden die Daten übertragen. Wenn der Slave nicht bestätigt ist ein Fehler passiert oder ?
Bei I2C hat der Slave die Möglichkeit, logische Fehler zu melden (NACK), dann soll die aktuelle Übertragung abgebrochen und irgendwie repariert werden. So ist auch die Erkennung möglich, ob überhaupt ein Slave unter der angegebenen Adresse reagiert. Im Prinzip kann sogar eine Übertragung durch den Slave verzögert werden, und diese Zusammenarbeit (auf SCL) geht nur mit open collecor (o.c.) Ausgängen, was die maximale Übertragungsrate begrenzt - oft auch garnicht implementiert. Genauso sind spezielle bidirektionale Pegelwandler notwendig, wenn Teilnehmer mit 3,3V und 5V benutzt werden sollen.
Je nach Anwendungsfall können die Unterschiede zwischen SPI und I2C Vor- oder Nachteile darstellen, es gibt also keinen Testsieger.
Bei Beiden gibt es keine Prüfung der Daten.
Die Daten werden bitweise verschickt, damit war's Das.
Wenn man auf Fehlerfreiheit Wert legt, muß man sich selber um eine Prüfung kümmern und beim Fehlschlag die Daten erneut anfordern - also selber ein eigenes Protokoll entwickeln, Was Alles, Was wir gerade brauchen, abdeckt.
Es kann ja auch schon bei der Adresse ein Fehler passieren - dann antwortet halt ein ganz anderer Teilnehmer, wenn's Diesen gibt.
Da Du aber durchaus auch struct's übertragen kannst (also Datenansammlungen), kann man dort auch eine Prüfsumme oder so Zeug integrieren.
Der Sender berechnet Diese und packt Die auch in das struct - der Empfänger liest den ganzen Kram ein und prüft, ob diese Prüfsumme zu den Daten passt - wenn Ja, haben wir valide Daten - wenn Nein, ist irgend etwas faul.
Aber Das muß die Library mitbringen (oder von Hand/zu Fuß implementiert werden), die Übertragungswege I²C/SPI haben damit Nichts am Hut.
Eine Fehlerkontrolle über irgend eine Quersumme hat kein I2C Slave implementiert.
Das könnte höchstens funktionieren wenn Du als Slave einen Microcontroller hast den Du frei programmieren kannst.
Grüße Uwe
Bei I2C gibt es ja eigentlich schon eine Fehlerabsicherung oder?
Der Master erkennt immerhin, ob der Slave vorhanden ist und etwas empfangen hat, also mit ACK geantwortet hat. Das ist schonmal erheblich mehr als "nichts"
Bei SPI senden übrigens Master und Slave gleichzeitig. (Noch ein Unterschied)