Liste der Anhänge anzeigen (Anzahl: 1)
Irgendwie hab ich Probleme, ein Zitat im Zitat zu erzeugen, hier mein Versuch:
Zitat:
Zunächst habe ich ein Zitat aus der mir vorliegenden Philips-I2C-Spec.: ( Ver. 2.1, Jan. 2000 )
Zitat:
I2C-bus compatible devices must reset their bus logic
on receipt of a START or repeated START condition
such that they all anticipate the sending of a slave
address, even if these START conditions are not
positioned according to the proper format.
Das besagt ja, dass eine START Condition -auch zu Unzeit angewendet- eine Resetierung der Buslogik im konformen I2C-Slave bewirkt.
Über den Busreset habe ich dort mit dem Suchbegriff "reset" nichts Einschlägiges gefunden,
dafür aber bei Freescale folgendes:
Zitat:
The sequence for a Bus Reset is as follows:
• Disable the host MCU IIC controller
• Create a START condition
• Clock SCL for at least nine clocks
• Check for SDA high
• Create a STOP condition
• Enable the host MCU IIC controller
Dieser Vorschlag legt nahe, dass der Reset des Slaves auch beim STOP erfolgt.
Hier wird mehrfach das erzeugen einer Start/Stop condition genannt. Das Problem dabei ist, daß das nicht geht, wenn der Slave SDA auf low hält. Ansonsten klingt der Freescale Vorschlag bekannt. Ich bild mir aber ein, ähnliches auch bei NXP gesehen zu haben.
Nach meiner praktischen Erfahrung gibt es zwei Probleme, die sich mit den gängigen I2C Funktionen (start(), stop(), write(), readACK(),readNAK() ) nicht leicht auflösen lassen:
- Lesen von einem Slave, der das Lesen von mehreren Bytes zulässt, ohne das letzte Byte mit einem NAK (sondern einem ACK) zu quitieren
- Abbruch eines READ durch einen Reset/Debugger/Absturz/... im Master
In beiden Fällen gewinnt der Slave die Kontrolle über SDA und der Master kann, wenn SDA low ist, weder Start noch Stop erzeugen.
Anhang 29167
Deswegen ist
Zitat:
• Create a START condition
etwas fragwürdig. Bisher bin ich mit der Strategie: SDA freigeben, SCL 8 mal takten gut gefahren. Bevor es dann richtig losgeht, kommt pflichtgemäß sowieso ein Start.
Zitat:
Beliebig viele weitere Clocks sind auch nicht statthaft, das kann kollidieren mit einer reservierten Sonderadresse (1111 1111).
Reserviert heißt ja nicht, daß die Adresse nicht auf dem Bus sein darf. Es heißt ja nur, daß kein Slave sie verwenden darf. Und es wird sich daher auch keiner angesprochen fühlen, das passt doch. Es sei denn, du hast eines dieser "Reserved for future purposes" Devices am Bus. Es geht ja hier nicht um einen gültigen I2C Datentransfer sondern um das Auflösen einer Fehlersituation ohne Poweronreset.
Zitat:
Eines ist schon eines zuviel.
Das wirst du nie vermeiden können. Es gibt sicher einige tausend I2C Devices, und daher ebensoviele oder mehr Entwickler, die die Spec für sich interpretiert haben.
Zitat:
Ich gehe diesen Thread durch und suche mir in meiner Datenblattsammlung die entsprechenden Passagen der Atmel-Application-docs, in Datenblättern, Wikis und so. Nachgucken, versuchen zu verstehen oder zu begreifen. Das bringt schon immer wieder so ein kleines "Aha!". Dann springt man - springe ich - auch mal in die THE I2C-BUS SPECIFICATION von Philips, VERSION 2.1 JANUARY 2000. Da gibts dann Dinge wie:
[CODE]Code:
1.3 Version 2.1 - 2000
Version 2.1 of the I2C-bus specification includes the following minor modifications:
· After a repeated START condition in Hs-mode, it is possible to stretch the clock signal SCLH
(see Section 13.2 and Figs 22, 25 and 32).[/CODE)
@oberallgeier
Das wird aus zwei Gründen keine wirkliche Bedeutung haben: Hs-mode wird nicht vorkommen, und die Änderung ist "minor".
Aber zusätzlich zum Lesen hilft (nicht nur hier) manchmal: Machen und Messen. Ich hab mal I2C in SW gemacht, ging zuerst garnicht. Dann in fremder SW geschmökert und neu gemacht. Und dabei erkannt, worauf es ankommt. Wenn man dann die Spec noch mal liest, versteht man sie besser. Heute mit den billigen DSOs oder LAs und den eingebauten Protokolldekodern geht das noch leichter.
MfG Klebwax
