Drei Fallstricke in I2C, von denen sich jeder wünscht, sie wären nicht vorhanden

Das Beste an I2C ist, dass es sich um einen Bus handelt, der fast überall verfügbar ist und ein riesiges Ökosystem von Geräten abdeckt, die ihn als hardwaredefinierte Schnittstelle anbieten, und gleichzeitig so unkompliziert ist, dass er auch rein in Software auf einfachem GPIO implementiert werden kann Stifte. Trotz dieser Beliebtheit ist I2C einer dieser berühmten informellen Standards, der einige beliebte Implementierungen aufweist, während viele Details wie das genaue Timing, die Buskapazität und andere mühsame Details dem armen Kerl überlassen werden, der die Produktentwicklung übernimmt. So kommt es, dass wir am Ende mit Artikeln wie einem kürzlich auf dem Zungenbrecher-Blog [pair of pared pears] enden, in dem es um Probleme geht, die bei der Implementierung eines I2C-Slaves festgestellt wurden.

Wie bei jedem gemeinsam genutzten Bus, ob Multi-Master oder nicht, ist es ein unterhaltsames Thema, herauszufinden, wann der Bus frei ist, aber auch endlose Kopfschmerzen bereiten kann. Ein Problem ergibt sich hier aus einer Funktion, die die SMBus-Version von I2C als schnelles Lesen/Schreiben bezeichnet. Dies ermöglicht die schnelle Übertragung einiger Daten. Abhängig von den vom Slave zurückgegebenen Daten kann es für den Master dennoch so aussehen, als ob noch nichts passiert, da SDA vom Slave bis zum Stoppzustand auf Low gehalten wird, wodurch der Bus im Wesentlichen gesperrt wird.

Noch aufregender wird es im Allgemeinen in Form dessen, was Logikanalysatoren gerne traumatisch als „falsche Start-/Stopp-Bedingung“ bezeichnen. Dies bezieht sich auf das Verhalten von SDA und SCL, wobei SDA vor SCL auf Low geht und einen Fehler anzeigt. Dies kann auf eine zu kurze Haltezeit zurückzuführen sein, die dazu führt, dass andere Geräte am Bus den Übergang verpassen. Hier definiert SMBus eine Übergangszeit von 300 ns, während I2C 0 Sekunden aufruft, aber es wird jetzt empfohlen, den Aufruf einer Start-/Stopp-Bedingung zu verzögern, bis eine Verzögerung von 300 ns verstrichen ist. Im Wesentlichen scheint es, dass die Einführung einer Haltezeit der richtige Weg ist, bis Beweise für das Gegenteil vorliegen.

Die dritte Gefahr betrifft die schnelleren Modi von I2C, darunter Fast-Mode (FM) und Fast-Mode Plus (FM+). Die Abwärtskompatibilität mit diesen schnelleren Versionen ist nicht oder nur lückenhaft. Obwohl FM+ (eingeführt von NXP im Jahr 2007) mit langsameren Geschwindigkeiten abwärtskompatibel sein soll, sind die Unterschiede in den Timing-Anforderungen zwischen den FM+- und FM-Standards tatsächlich zu groß, um sie auszugleichen. Zumindest in den aktuellen Versionen der Standards, aber eine der Freuden von I2C ist, dass es immer wieder neue Revisionen gibt, auf die man sich freuen kann.