Kann ich I2C-Bus oder GPIOs als I2C verwenden, um I2C-Geräte anzuschließen?

Diese Frage bezieht sich auf die Verwendung von I2C-Bus/GPIOs als I2C.

Mein Anwendungsprozessor hat drei I2C-Controller. Ist es vorzuziehen, alle I2C-Geräte (offensichtlich können wir nicht mehr als 128 Geräte an I2C anschließen) an diesen Bussen anzuschließen?

Oder ist es vorzuziehen, GPIOs als I2C zu verwenden? (Mein Anwendungsprozessor hat auch GPIO-Leitungen, die ich für I2C-Zwecke verwenden kann.)

Wann ist es vorzuziehen, I2C-Controller und wann GPIO-Leitungen für die I2C-Schnittstelle zu verwenden?

Welchen "Anwendungsprozessor" verwenden Sie?
Bevor Sie in die 128-Geräte-Beschränkung geraten, sind Sie möglicherweise durch die Buskapazität eingeschränkt.

Antworten (3)

Abhängig davon, wie viele Daten über den Bus laufen, und wenn es "Konflikte" von Geräte-IDs gibt oder Daten gleichzeitig übertragen werden, ist es kein Problem, alle Ihre Geräte an einen Bus zu hängen. Dafür wurde I2C entwickelt.

Um die Last zu verteilen, kann die Verwendung von 2 oder 3 I2C-Bussen die Dinge vereinfachen (z. B. verschiedene Systeme getrennt halten), aber es kann bedeuten, dass Sie dasselbe dreimal in der Software tun müssen. Sie können beispielsweise einen Bus für die "Hochgeschwindigkeits" -Übertragung vieler Daten (z. B. zu / von einem Speichergerät) und einen anderen Bus verwenden, der viel langsamer läuft, um weniger kritische Aktivitäten auszuführen, z. B. das Lesen eines Temperatursensors jede Sekunde oder das Einschalten einer LED an aus.

Bit-Banging I2C mit GPIO-Pins ist ein "letzter Ausweg", da es normalerweise viel einfacher ist, das eingebaute I2C-Gerät zu verwenden, und die meisten Prozessoren Dinge wie Interrupt-Handler und DMA haben, um die Arbeit viel einfacher zu machen, die Übertragungen zu automatisieren, zu sparen Prozessorlast / Software-Overhead etc.

Es ist viel schöner, die Kommunikation über Interrupts abzuwickeln, als zu versuchen, dies über GPIO + Waits/Timer usw. zu tun, insbesondere wenn Sie viel zu tun / viele Daten zu verschieben haben.

Zum Hinzufügen bearbeitet: Es kann auch praktisch sein, einen Bus für Geräte zu verwenden, die einen Pegelumsetzer benötigen (z. B. 5-V-Geräte, die an einem Bus an 3,3-V-Mikro angeschlossen sind, 3,3-V-native Geräte am anderen Bus).

Wenn Sie einen I2C-Master für ein Single-Master-System implementieren, würde ich vorschlagen, dass Bit-Banging dem Versuch vorzuziehen ist, integrierte Hardware zu verwenden. Unter anderem:

  1. Wenn Geräte auf dem I2C-Bus "verwirrt" werden, kann es manchmal schwierig sein, Hardware-Master-Implementierungen davon zu überzeugen, die besten Wellenformen zu generieren, um sie "loszulösen" (empfohlener Ansatz: wenn SDA nicht schwebt oder wenn Ihr Gerät fährt SCK niedrig, SDA aktivieren, CLK aktivieren, SDA freigeben, CLK freigeben und warten, bis CLK hoch geht; bei Bedarf wiederholen und dann SDA mit SCK hoch aktivieren und freigeben). Beachten Sie, dass, wenn ein EEPROM-Gerät dachte, es sei mitten in einem Schreibzyklus, diese Wellenform dazu führt, dass es den laufenden Schreibvorgang abbricht; Wenn der Prozessor nicht weiß, warum das EEPROM erwarten würde, Daten zu schreiben, ist es wahrscheinlich besser, das Schreiben abzubrechen, als Daten zu schreiben, von denen der Prozessor nichts weiß. Einfach mit Bit-Banging zu tun; schwieriger (wenn überhaupt möglich) bei vielen Hardware-I2C-Implementierungen.
  2. Viele Hardware-I2C-Implementierungen erfordern, dass der Prozessor vor dem Lesen jedes Bytes entscheidet, ob es positiv oder negativ bestätigt werden soll oder nicht. In vielen Fällen wäre es bequemer, eine "Byte lesen"-Routine zu haben, die eine positive Bestätigung sendet, das vorherige Byte (falls vorhanden) bestätigt, das nächste Byte liest und die Bestätigung nicht ausführt, bis das nächste Byte benötigt wird; Sobald keine Daten mehr benötigt werden, rufe eine "Ende-Lese"-Routine auf, um eine negative Bestätigung zu senden. Ein solcher Ansatz ist beim Bit-Banging einfach, aber ich kenne keine Hardware-I2C-Implementierungen, die es einem ermöglichen, ein Byte zu lesen, ohne im Voraus wissen zu müssen, ob es das letzte sein wird.

Die Leichtigkeit oder Schwierigkeit, eine Bit-Bang-I2C-Master-Implementierung zu schreiben, ist im Wesentlichen unabhängig von der Anzahl der Geräte am Bus. I2C-Slave-Implementierungen sind im Allgemeinen ohne zumindest ein gewisses Maß an Hardwareunterstützung schwierig oder unmöglich, aber das Big-Banging eines I2C-Masters ist einfach.

Wenn Ihr Anwendungsprozessor über I2C-Hardware verfügt, die im Master-Modus arbeiten kann, können Sie ihn sicherlich zur Kommunikation mit Slave-Geräten verwenden.

Im Vergleich zu Bit-Bang-GPIO-Implementierungen kann es in Bezug auf die Entwicklungszeit schneller sein, die On-Board-Hardware zu verwenden. Höchstwahrscheinlich wird es einige Bibliotheken geben, die die Moduseinstellung und die allgemeine Aktivität vereinfachen, die der I2C-Master ausführen muss (Lesen, Schreiben, ACKs, NACKs, allgemeiner Aufruf, Serialisierung von ein- und ausgehenden Bytes usw.).

Wenn die I2C-Hardware jedoch fehlerhaft ist oder die Bibliotheken Ihnen nicht die Funktionalität bieten, die Sie benötigen, finden Sie es möglicherweise besser, mit GPIO-Bit-Bang-I2C zu arbeiten und die Verwendung der I2C-Hardware zu vermeiden. Der Nachteil ist natürlich, dass viel mehr Code geschrieben werden muss.