Solltest du I2C- oder SPI-Geräte für dein Projekt verwenden?

Es hängt davon ab, was du erreichen möchtest.

Beachte, dass einige Geräte nur als I2C- oder als SPI-Gerät verfügbar sind und oft die beste Lösung darin besteht, sowohl I2C als auch SPI zu verwenden, wenn du genug Pins an deinem Mikrocontroller übrig hast. Viele Designer gehen davon aus, dass der Bus das primäre Auswahlkriterium für die Bauteilsuche ist, aber oft sind Leistung und Preis eines Bauteils wichtiger als die Schnittstelle, die es verwendet!

Vorteile von I2C:

• I2C verwendet nur zwei Pins (im Gegensatz zu SPIs drei Pins plus einem Adress-Pin pro Gerät für die meisten Konfigurationen)
• I2C kann mehrere Geräte mit denselben zwei Pins unterstützen, wenn jedes eine unterschiedliche Adresse hat.
• Der I2C-Standard definiert, wie man von/an eine bestimmte Adresse liest/schreibt, daher musst du das Datenblatt nicht für jedes einzelne Gerät so gründlich prüfen. Beachte, dass viele komplexe Geräte diesen Standard bis zu einem gewissen Grad erweitern, z.B. haben größere EEPROMs mehrere I2C-Adressen, um den Zugriff auf den gesamten Speicher zu ermöglichen.
• I2C hat weniger zu konfigurierende Parameter, da Geschwindigkeiten und andere Attribute im Standard festgelegt sind (100 kbit/s, 400 kbit/s oder 1 MBit/s = FM+). Daher musst du dir keine Gedanken über SPI-Modi oder die korrekte Konfiguration der SPI-Geschwindigkeit für jedes Gerät machen.
• Die standardmäßig langsamere Geschwindigkeit von I2C macht es wahrscheinlicher, dass I2C über längere Leiterbahnen/Kabel out-of-the-box funktioniert. SPI ist anfälliger für intermittierende Probleme, wenn es an oder nahe der physikalischen Geschwindigkeitsgrenze eines PCB-Designs betrieben wird. Bei I2C ist es typischerweise sicher anzunehmen, dass es über 50cm lange Leiterbahnen funktioniert (bei der Standardgeschwindigkeit von 400 kbit/s). Der einzige Grund, warum I2C über längere Leiterbahnen als SPI funktioniert, ist seine langsamere spezifizierte Geschwindigkeit. SPI funktioniert genauso gut, wenn du die Geschwindigkeit ausreichend niedrig einstellst.

Vorteile von SPI:

• SPI ist viel schneller. Während I2C typischerweise mit 400 kbit/s kommuniziert (im Fast Mode Plus = FM+: 1 Mbit/s), kommuniziert SPI mit etwa 20-50 MBit/s (variiert je nach Konfiguration und unterstützter Geschwindigkeit jedes Bauteils). Für viele Anwendungen benötigst du jedoch nicht so viel Geschwindigkeit.
• Bei SPI musst du dir keine Gedanken über die Zuweisung von I2C-Adressen machen, da jedes Gerät seinen eigenen Chip-Select-Pin hat. Siehe unseren Leitfaden zur Zuweisung von I2C-Adressen für weitere Details.
• SPI ist flexibler darin, welche Daten übertragen werden können, da das Kommunikationsnachrichtenformat nicht so stark standardisiert ist wie bei I2C.
• Jeder SPI-Pin kommuniziert nur in eine Richtung. Daher ist SPI viel einfacher galvanisch zu isolieren mit Optokopplern oder ähnlichen Geräten. I2C erfordert spezielle (und daher teure) Isolator-Bausteine wie den TI ISO1541.
• SPI ist typischerweise etwas einfacher mit einem Oszilloskop zu debuggen, da du weißt, von welchem Gerät die Daten für jeden einzelnen Pin kommen. Bei I2C musst du dir die gesendeten Daten ansehen, um herauszufinden, welches Gerät Daten senden möchte.
• I2C erlebt manchmal Probleme durch blockierte Geräte, wenn eine I2C-Kommunikation mitten in einem Byte unterbrochen wird (z.B. durch einen Mikrocontroller-Neustart) und dadurch der Zustandsautomat eines Geräts in einem Zustand verbleibt, der nicht zum Zustand des I2C-Masters passt. Die meisten Designer anticipate dieses Problem nicht und enthalten keine I2C-Lockup-Mitigation in ihrer Firmware. Das bedeutet, dass oft ein kompletter Power-Cycle des Systems erforderlich ist, um die Bus-Blockade zu beseitigen. Das Problem tritt häufiger während der Firmware-Entwicklung auf, wenn Mikrocontroller-Neustarts aufgrund von Reprogrammierung, Abstürzen und Breakpoints häufiger sind und in Produktionstests ist es oft schwer, die spezifischen Bedingungen zu erzeugen, die eine Blockade im Einsatz verursachen. SPI kann nie blockieren, weil es zurückgesetzt wird, sobald der Chip-Select-Pin deaktiviert wird.
• SPI kann oft verwendet werden, um Logik-ICs wie die 74HC-Serie zu steuern, sodass du keine separaten Pins zur Steuerung von Logikgeräten benötigst. Beachte, ob dies funktioniert

In welchen Fällen musst du eine andere Schnittstelle (nicht I2C oder SPI) verwenden?

• Lange Kabel/Leitungen. SPI und I2C arbeiten zuverlässig bis zu einigen zehn Zentimetern, abhängig von deinem Layout und der Geschwindigkeit des Busses. Bei längeren Leiterbahnen musst du den Bus möglicherweise verlangsamen (besonders bei SPI). Das Hauptproblem hier ist Clock-Skew: Eine Änderung des Spannungspegels am Clock-Pin dauert zu lange, um am Gerät anzukommen, daher „antwortet das Gerät zu spät“ (zusätzlich dauert die Antwort vom Gerät zu lange, um am Master anzukommen). Wenn du überprüfen möchtest, ob dies bei deinem Design der Fall ist, verlangsame deinen Bus auf extrem langsame Geschwindigkeiten (wie 20 kbit/s). Wenn das Problem weiterhin besteht, hast du kein Problem mit Clock-Skew. Du kannst dies auch mit einem Oszilloskop debuggen.
• Elektromagnetischer Lärm aus der Umgebung, z.B. große Motoren, die in der Nähe deines Geräts starten. Da sowohl I2C als auch SPI keine differentiellen Leitungen verwenden
• Multi-Master-Kommunikation: I2C und SPI kommunizieren typischerweise nur, wenn ein (vordefinierter) Master die Kommunikation initiiert. In den meisten Konfigurationen ist es nicht möglich für ein Gerät, die Kommunikation nur über den I2C- oder SPI-Bus zu initiieren, daher musst du oft ein Gerät mehrmals pro Sekunde abfragen, um zu prüfen, ob sich ein Status geändert hat. I2C und SPI haben keinen eingebauten Kollisionserkennungsmechanismus, der erkennt, ob mehrere Geräte gleichzeitig auf den Bus schreiben möchten.
• Asynchrone Kommunikation: Wenn du Daten unabhängig voneinander senden/empfangen möchtest, solltest du UART, Ethernet oder einen ähnlichen Bus verwenden, der komplett unabhängige Sende-/Empfangssubsysteme hat, die nicht von einem gemeinsamen Clock abhängen.
• Sehr schnelle Kommunikation: FPGAs, schnelle ADCs/DACs, Flash-Speicher etc. könnten z.B. verwenden:
  • QSPI: SPI mit mehreren Daten-Pins (typischerweise 4 Daten-Pins - daher der Name Quad SPI).
  • LVDS: Hochgeschwindigkeits-Differentiellbus-System
  • JESD204B: Ultrahochgeschwindigkeits-(Multi-Gigabit)-Datenverbindungssystem für ICs. Nicht anfassen, wenn du nicht weißt, was du tust!
  • Parallel: Einfach viele Pins ohne etwas Besonderes.

Welche anderen Schnittstellen solltest du für die Kommunikation außerhalb der Platine in Betracht ziehen?

• RS485/RS422: Robuster Hochgeschwindigkeits-Industrie-Bus (nur physikalische Schicht, verwendet in Systemen wie Profibus). Schnell (15 MBit/s). RS422 ist wie UART, aber differentiell. RS485 betreibt Empfang/Sendung auf derselben differentiellen Leitung.
• RS232: Altes Industrie-Busssystem, nicht differentiell, erfordert +-15V zur Kommunikation (und erfordert daher einen speziellen IC, um diese Spannungspegel zu erzeugen). Ziemlich robust, aber nicht so robust, wie es scheint. Langsam (0,1 MBit/s typisch, funktioniert aber meist bis ~0,5 Mbit/s unter den meisten Umständen, wenn alle Geräte es unterstützen), unterstützt keine langen Kabel, besonders nicht in elektromagnetisch verrauschten Umgebungen.
• LVDS: Hohe Geschwindigkeit, aber nicht über lange Strecken (höchstens einige Meter). Differentiell und ziemlich robust, aber nicht so geeignet für verrauschte Industrieumgebungen bei Verwendung mit längeren Kabeln. Erfordert Kenntnisse im Hochgeschwindigkeits-Schaltungsdesign für korrekte Implementierung.
• Ethernet: Sehr komplex vom PCB-Standpunkt aus richtig zu implementieren (du benötigst einen speziellen PHY = Physical-Layer-Transceiver-IC und einen Mikrocontroller, der die MAC-Schicht unterstützt, die die Ethernet-Nachrichten = Frames erzeugt), aber sehr schnell (100 Mbit/s max für die meisten Mikrocontroller, aber FPGAs, Prozessoren etc.) und sehr robust (differentiell, 32-Bit-CRC-Prüfsummen). Sehr bequem für die Anbindung an Computer; schaltbar. Unterstützt TCP/IP. PHYs und andere Hardware sind sehr günstig, da sie in großen Mengen produziert werden. Hinweis: PHYs sind recht komplex und wenn du nicht einige Grundlagen des Hochgeschwindigkeits-Schaltungsdesigns verstehst und alle Datenblätter sehr sorgfältig liest, hast du eine hohe Wahrscheinlichkeit, dass dein Design nicht funktioniert - was oft schwer zu debuggen ist, besonders wenn du kein Mehrkanal-Oszilloskop mit mindestens 50 MHz Bandbreite und etwas Erfahrung im Hochgeschwindigkeits-Schaltungsdebugging hast. Die Schnittstelle vom PHY zu deinem Mikrocontroller ist typischerweise RMII für 100 MBit/s-Ethernet, zusätzlich benötigst du eine SMC-Schnittstelle, die wie I2C ist, um den PHY zu konfigurieren.
• USB: Schnell, aber erreicht nur unter idealen Bedingungen 480 MBit/s, wenn dein IC dies tatsächlich unterstützt (viele benötigen einen externen Transceiver = USB HS PHY). Die meisten Mikrocontroller unterstützen nur bis zu 12 MBit/s. Komplex, es sei denn, du verwendest fertige ICs. Debugging ist in der Praxis ziemlich schwer, da USB-Firmware auf viele nicht offensichtliche Arten fehlschlagen kann (außer wieder bei fertigen ICs, die nur USB-to-X-Konversion durchführen). Ich empfehle, einen USB-to-UART-Converter-IC wie den FT230XQ zu verwenden. USB an Mikrocontrollern funktioniert manchmal nicht mit einigen Computern, wenn es nicht komplett richtig implementiert ist. Verwende wenn möglich ein professionell erstelltes USB-Beispiel, das mit einer Vielzahl von Geräten getestet wurde, und versuche, es nicht zu sehr zu modifizieren. Oder verwende von vornherein einfach einen fertigen Converter-IC.
• UART: Nützlich zum Debuggen, aber nicht robust. UART-to-USB-ICs sind weit verbreitet (ich empfehle derzeit den FT230XQ) zur Anbindung an Computer. Ziemlich schnell (kann bis zu ~12 MBit/s mit vielen modernen Mikrocontrollern, aber es ist nicht immer machbar, ihn mit dieser Geschwindigkeit zu verwenden, besonders nicht mit langen Leiterbahnen/Kabeln aufgrund von Signalverschlechterung). USB-to-UART-Adapter zum Debuggen sind readily verfügbar und sehr günstig in China.
• CAN: Hauptsächlich in Automobilsystemen verwendet. Nicht sehr schnell (1 MBit/s), aber hat ein Prioritätssystem, das es hochprioritären Nachrichten erlaubt, während der Übertragung niederpriorer Nachrichten gesendet zu werden (welche unterbrochen und später erneut gesendet werden). Differentiell und ziemlich robust. Meist einfach auf IC-Ebene zu verwenden, aber schwer auf Firmware-Ebene komplett richtig zu implementieren (es gibt viele nicht offensichtliche Konfigurationsoptionen).