Auf welche verschiedenen Arten kann ein I2C-Bus hängen bleiben?

Ich bin sehr neu in der Elektronik und habe das Gebiet des I2C-Busses betreten. Sie möchten das Verhalten konformer Geräte gemäß der I2C-Protokollspezifikation verstehen.

Eine Bedingung gemäß dem Link unten ist, wenn ein Master-Controller während einer Transaktion zurückgesetzt wird. Das heißt, der verlobte Sklave weiß nicht, was er jetzt tun soll.

https://www.i2c-bus.org/i2c-primer/analysing-obscure-problems/blocked-bus/

  1. Ich verstehe nicht, wie diese Anrufe für den Bus hängen? Der neu gestartete Master könnte immer eine neue Transaktion starten und die Slaves sollten sie lesen können.

  2. Gibt es eine andere Möglichkeit zusätzlich zu dem, was oben erklärt wurde, um ein Hängenbleiben des Busses zu verursachen?

  3. Kann ein solches Problem durch einen Softwaretreiber verursacht werden?

Alles, was eine der I2C-Leitungen herunterzieht (wenn dies nicht der Fall sein sollte), blockiert den Bus. So einfach ist das.
@EugeneSh., empfehlen Sie, den Kommentar in eine Antwort umzuwandeln, viel mehr steckt nicht dahinter.
Es ist auch erwähnenswert, dass I2C und SMBus unterschiedlich sind. IIRC, SMBus hat ein Zeitlimit für die Taktdehnung, das nicht in I2C enthalten ist. Ein I2C-Bus kann also hängen bleiben und tatsächlich kompatibel sein, während SMBus dies nicht kann.
@EugeneSh - Danke. Ich denke, ich verstehe diesen Teil - aber ich verstehe nicht, was dazu führen würde, dass eine Leitung dauerhaft heruntergezogen wird - und was sie dann dazu bringt, sie freizugeben.

Antworten (1)

Der Master kann keine Start- oder Stoppbedingung ausgeben, während irgendein Slave SCL oder SDA antreibt. Wenn sich nur ein Slave auf dem Bus befindet, wäre das Worst-Case-Szenario, wenn der Master zurückgesetzt wird, nachdem der Slave gerade eine "Lese" -Anforderung erhalten hat, diese gerade bestätigt hat und vollständig eingestellt ist als Antwort eine "0" senden. In diesem Szenario würde der erste Takt über die Bestätigung hinausgehen, und die nächsten acht würden über die Datenbits hinausgehen, und das Gerät würde SDA kontinuierlich treiben, bis es den neunten Takt empfängt. Nachdem die Uhr zum neunten Mal hoch und dann wieder niedrig geht, würde das Gerät den Bus schweben lassen (wenn es dies nicht schon vorher getan hätte), um nach einer Bestätigung vom Master zu suchen.

Wenn mehrere Slave-Geräte vorhanden sind, könnte ein Bus dauerhaft gesperrt werden, wenn zwei Geräte beide glauben, dass sie Befehle zum Auslesen einer Zeichenfolge von Null-Bytes erhalten haben, aber (möglicherweise weil der Master zu einem Zeitpunkt zurückgesetzt wurde, der zu einem "Runt " Puls auf SCL, der lang genug war, um von einem Slave gesehen zu werden, aber nicht vom anderen) geben die beiden Slaves den Bus zu unterschiedlichen Zeiten frei, wenn sie nach Bestätigungen vom Master suchen.

Vielen Dank für Ihre Mühe, aber ich bin neu in Elektronik und I2C. Können Sie bitte klarstellen: "In diesem Szenario würde die erste Uhr über die Bestätigung hinausgehen und die nächsten acht ....". Was ist in dem Zusammenhang „erste Uhr“ und was „nächste acht“? Auch wenn Sie antworten könnten, wie dies durch einen Softwaretreiber verursacht werden könnte? (unpassender Reset?)
Trotz Ihres besten Versuchs ist mir auch der zweite Teil für mehrere Sklavenfälle etwas unklar. Zwei Slaves, die den Bus zu unterschiedlichen Zeiten freigeben, verursachen Hängenbleiben? Wie können zwei Slaves gleichzeitig anfangen zu antworten, wenn die Adresse möglicherweise nur mit einer übereinstimmt?
@ultimatecause: Die potenzielle Problemsituation wäre, wenn der Master irgendwie einen Taktimpuls ausgibt, der nicht der Mindestimpulsbreitenspezifikation entspricht, mit dem Effekt, dass ein Slave ihn sieht und der andere nicht. Je nachdem, wie empfindlich die Slaves auf unterschiedliche Impulsbreiten reagieren, kann es sehr unwahrscheinlich sein, dass ein solches Problem auftritt. Wenn es andererseits auftritt, kann eine Wiederherstellung unmöglich sein.
Auf welche verschiedenen Arten kann ein I2C-Bus hängen bleiben?
AntwortenHierDatenschutz-Bestimmungen1y, 0v