Frank (Diskussion | Beiträge) (→Siehe auch) |
Luma (Diskussion | Beiträge) K |
||
| (4 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 3: | Zeile 3: | ||
Der [[I2C ]] benutzt lediglich zwei bidirektionale Pins [ TaktSCL und DatenSDA] sowie GND. Takt- und Datenleitung sind meist mit Pull-Up-Widerständen an die positive Versorgungsspannung angeschlossen [Wired-AND] . Der Bus arbeitet meist mit 100 kbit/s im ''Standard-Modus'', lässt sich jedoch auch in einen langsamen Modus schalten, bei dem dann 10 kbit/s uebertragen werden können. Modernere Implementierungen und entsprechende Chips lassen Datenraten von 400 kbit/s bis ueber 3,4 Mbit/s zu. | Der [[I2C ]] benutzt lediglich zwei bidirektionale Pins [ TaktSCL und DatenSDA] sowie GND. Takt- und Datenleitung sind meist mit Pull-Up-Widerständen an die positive Versorgungsspannung angeschlossen [Wired-AND] . Der Bus arbeitet meist mit 100 kbit/s im ''Standard-Modus'', lässt sich jedoch auch in einen langsamen Modus schalten, bei dem dann 10 kbit/s uebertragen werden können. Modernere Implementierungen und entsprechende Chips lassen Datenraten von 400 kbit/s bis ueber 3,4 Mbit/s zu. | ||
| − | Der Bus ist als Master-Slave-Bus konzipiert. Der Master sendet und ein Slave reagiert darauf. Mehrere Master sind möglich [Multimaster-Mode] . Die Buszuteilung [Arbitrierung] ist dabei per Spezifikation geregelt. Prinzipiell können verschieden schnelle Busteilnehmer [Geräte/Boards] parallel an einem Bus betrieben werden. Ist ein Slave-Gerät langsamer als der immer durch den Master vorgegebene Bustakt SCL kann es durch ''clock stretching'' den Master während des Bit-Transfers definiert bremsen. Dabei wird die SCL-Leitung vom Slave solange auf logisch Null gehalten, bis | + | Der Bus ist als Master-Slave-Bus konzipiert. Der Master sendet und ein Slave reagiert darauf. Mehrere Master sind möglich [Multimaster-Mode] . Die Buszuteilung [Arbitrierung] ist dabei per Spezifikation geregelt. Prinzipiell können verschieden schnelle Busteilnehmer [Geräte/Boards] parallel an einem Bus betrieben werden. Ist ein Slave-Gerät langsamer als der immer durch den Master vorgegebene Bustakt SCL kann es durch ''clock stretching'' den Master während des Bit-Transfers definiert bremsen. Dabei wird die SCL-Leitung vom Slave solange auf logisch Null gehalten, bis er das nächste Bit empfangen bzw. senden kann. Dies ist wegen der Wired-AND-Verschaltung von SDA und SCL jedem Gerät am Bus möglich. Voraussetzung ist dabei jedoch, dass die Start- und Stopp-Bedingungen [d.h. eine Pegelaenderung an SDA während SCL logisch 1 ist] vom langsamen Gerät auch dekodiert werden können. |
| − | Da ''Clock Stretching'' anfangs nur von weniger Schaltkreisen / Geräten benutzt wurde, sind viele [[I2C]]-Routinen entstanden, die diesen Modus nicht berücksichtigen. Insbesondere im Hobby-Bereich wurde die notwendige Überwachung der I2C-Leitung Clock einfach weggelassen. Das Master | + | Da ''Clock Stretching'' anfangs nur von weniger Schaltkreisen / Geräten benutzt wurde, sind viele [[I2C]]-Routinen entstanden, die diesen Modus nicht berücksichtigen. Insbesondere im Hobby-Bereich wurde die notwendige Überwachung der I2C-Leitung Clock einfach weggelassen. Das Master verlässt sich somit darauf, dass nach Freigabe der Clock Leitung diese sofort wieder über einen Pullup-Widerstand auf High gezogen wird. Es wird nicht hinterfragt, ob der Slave die Leitung weiterhin auf Low zieht, um noch etwas Zeit für seine Operation zu haben. Solche I2C-Routinen sind leider noch in sehr vielen Libraries oder Programmen enthalten, was letztlich bei Geräten, die ''Clock Streching'' nutzen, zu erheblichen Problemen führt. |
Neuere Compiler-Versionen wie z.B. [[Bascom ]] berücksichtigen Clock Stretching. | Neuere Compiler-Versionen wie z.B. [[Bascom ]] berücksichtigen Clock Stretching. | ||
| Zeile 15: | Zeile 15: | ||
[[Kategorie:Microcontroller]] | [[Kategorie:Microcontroller]] | ||
| − | [[Kategorie: | + | [[Kategorie:Kommunikation]] |
[[Kategorie:Grundlagen]] | [[Kategorie:Grundlagen]] | ||
[[Kategorie:Elektronik]] | [[Kategorie:Elektronik]] | ||
Aktuelle Version vom 19. Januar 2006, 15:41 Uhr
Clock Stretching ist ein Begriff, der bei dem I2C-Bus eine wichtige Rolle spielt.
Der I2C benutzt lediglich zwei bidirektionale Pins [ TaktSCL und DatenSDA] sowie GND. Takt- und Datenleitung sind meist mit Pull-Up-Widerständen an die positive Versorgungsspannung angeschlossen [Wired-AND] . Der Bus arbeitet meist mit 100 kbit/s im Standard-Modus, lässt sich jedoch auch in einen langsamen Modus schalten, bei dem dann 10 kbit/s uebertragen werden können. Modernere Implementierungen und entsprechende Chips lassen Datenraten von 400 kbit/s bis ueber 3,4 Mbit/s zu.
Der Bus ist als Master-Slave-Bus konzipiert. Der Master sendet und ein Slave reagiert darauf. Mehrere Master sind möglich [Multimaster-Mode] . Die Buszuteilung [Arbitrierung] ist dabei per Spezifikation geregelt. Prinzipiell können verschieden schnelle Busteilnehmer [Geräte/Boards] parallel an einem Bus betrieben werden. Ist ein Slave-Gerät langsamer als der immer durch den Master vorgegebene Bustakt SCL kann es durch clock stretching den Master während des Bit-Transfers definiert bremsen. Dabei wird die SCL-Leitung vom Slave solange auf logisch Null gehalten, bis er das nächste Bit empfangen bzw. senden kann. Dies ist wegen der Wired-AND-Verschaltung von SDA und SCL jedem Gerät am Bus möglich. Voraussetzung ist dabei jedoch, dass die Start- und Stopp-Bedingungen [d.h. eine Pegelaenderung an SDA während SCL logisch 1 ist] vom langsamen Gerät auch dekodiert werden können.
Da Clock Stretching anfangs nur von weniger Schaltkreisen / Geräten benutzt wurde, sind viele I2C-Routinen entstanden, die diesen Modus nicht berücksichtigen. Insbesondere im Hobby-Bereich wurde die notwendige Überwachung der I2C-Leitung Clock einfach weggelassen. Das Master verlässt sich somit darauf, dass nach Freigabe der Clock Leitung diese sofort wieder über einen Pullup-Widerstand auf High gezogen wird. Es wird nicht hinterfragt, ob der Slave die Leitung weiterhin auf Low zieht, um noch etwas Zeit für seine Operation zu haben. Solche I2C-Routinen sind leider noch in sehr vielen Libraries oder Programmen enthalten, was letztlich bei Geräten, die Clock Streching nutzen, zu erheblichen Problemen führt.
Neuere Compiler-Versionen wie z.B. Bascom berücksichtigen Clock Stretching.
Siehe auch
