Diskussion:I²C

Überschrift

Gibt es eine Begründung, warum dieser Artikel immer noch unter I2C liegt. Schließlich wird die Schreibweise I²C ja - soweit ich das sehe - inzwischen unterstützt; in der englischen und spanischen Wiki sind die Namen der Artikel auch entsprechend gestaltet... IMHO sollte man den Artikel nach I²C verschieben und unter I2C einen Redirect belassen - oder spricht da was gegen? Wenn es keine Einwände - besonders von Jed, der ja erst vor einem Monat den Schreibweise-Hinweis angebracht hat - gibt, würde ich den Artikel in den nächsten Tagen mal verschieben... --Polykarbon 19:56, 26. Sep 2005 (CEST)

tu das... --Spongo ⇄ 14:22, 27. Sep 2005 (CEST)

Is wohl ein bissl veraltet, der Vorschlag. 84.161.228.55 17:58, 22. Apr. 2024 (CEST)

Microwire

Wo liegen denn die Unterschiede/Gemeinsamkeiten zum Microwire-Bus? --84.137.233.55 18:01, 12. Apr 2006 (CEST)

Die einzige Gemeinsamkeit ist die, daß es sich bei beiden um einen seriellen Bus handelt. Ansonsten sind sie ziemlich verschieden strukturiert, Microwire ist dem SPI sehr ähnlich. --Axel Farr 20.9.2006

Schaltbild

Die Widerstände im Schaltbild sollten nicht schwarz ausgefüllt sein -- das ist für Induktivitäten reserviert.

Hallo Thomask, Vorschlag aufgegriffen. Gruss, Dantor 17:09, 7. Mai 2006 (CEST)

Sprechweise

Soweit ich weiß, sagt man "squared", wenn etwas quadriert wurde. Sollte es dann nicht "I-squared-C" ausgesprochen werden? --Stimpson 10:20, 22. Aug 2006 (CEST)

erledigtErledigt -- Emdee 14:08, 13. Apr. 2009 (CEST)

Also ich kenne das auch als I-two-C, wer noch? 79.233.125.232 11:54, 7. Jun. 2009 (CEST)

Ich kenne "Ih zwei Zeh", "Ih Quadrat Zeh" (beides üblich) und "Ih ih Zeh" (eher selten). Auch gehört: "Ei skwärd ßi", aber das war in einem ansonsten bullshitbingo-verdächtigem Umfeld. -- Pemu (Diskussion) 12:17, 8. Mär. 2012 (CET)

Definition

Würde es Sinn machen, den Absatz "Definition" mal etwas besser zu strukturieren? Im Moment ist er einfach nur eine Ansammlung von Fachbegriffen mit ganz wenig Fleisch. Ich hätte mir das etwa so vorgestellt:

• anfangen mit elektrischen Spezifikationen, Takt
• Zustände des Busses (Start-, Stop-, wiederholte Start-Bedingung, Funktion des ACK-Bits, Arbitrierung)
• Zum Schluß kann man einige typische Zugriffsvarianten vorstellen, z.B. Schreiben auf einen Baustein mit Start, Adresse, Subadresse, Daten, Stopp und Lesen von einem Baustein mit Start, Adresse, (evtl. Subadresse), Wiederholte Startbedingung, Daten vom Slave, Stopp.

Man sollte natürlich nicht die komplette I²C-Spezifikation rezitieren, aber eine Übersicht über die Funktionsweise wie sie z.B. praktisch jedes IC-Datenblatt für I²C-Peripherie bietet wäre in meinen Augen besser als der jetzige Text. --Axel Farr 20.9.2006

TWI

Es gibt einige Links, in denen TWI als Abkürzung für „Two-wire Interface“ verwendet wird und die auf diesen Artikel verweisen. Im Artikel wird TWI aber nicht erwähnt. Per Google konnte ich herausfinden, dass es sich wohl um eine irgendwie kompatible Konkurrenzimplementierung handelt. Könnte jemand, der sich damit auskennt, dazu mal zwei Sätze verlieren? Danke. --jpp ?! 12:09, 22. Dez. 2006 (CET)

Auf der verlinkten Seite unter sprut.de lese ich auch "2-Draht-Bus" bzw. "synchrone serielle 2-Drahtverbindung". Haben die die beiden Drähte für Uo und Masse unterschlagen .. oder gibt´s noch nen Schaltungskniff die beiden Drähte überflüssig zu machen? -- 87.162.188.244 22:56, 23. Dez. 2006 (CET)

Das Two-Wire-Protokoll (auch kurz 2-Wire, 2Wire oder 2W genannt) ist was anderes als das I²C-Protokoll, obwohl beides synchrone, serielle Protokolle sind, die zwei Datenleitungen verwenden. Masse und Versorgungsspannung werden wohl einfach nicht mitgezählt, sind aber trotzdem vorhanden (soweit mir zumindest bekannt ist). Es gibt mehrere serielle Protokolle, die zwei Drähte verwenden. Der Name 2-Wire ist deshalb in meinen Augen etwas unglücklich gewählt, weil es den Leser leicht irritieren kann, aber vielleicht war das ja auch die Absicht des Namensgebers.

Das ist Quatsch, lies zb. das Datenblatt eines Atmel Mikrokontrollers und du wirst sehen, dass das exakt I2C entspricht.

Naja, ob sie immer exakt gleich sind, da bin ich mir nicht so sicher. Z.B. listet das Datenblatt von einem AVR32 Mikrocontroller auf Seite 220 (Kapitel TWI) die genauen Unterschiede der Atmel-Implementierung zum I2C-Standard auf. Below, Table 24-1 lists the compatibility level of the Atmel Two-wire Interface in Master Mode and a full I2C compatible device. Es mag in der Praxis für die meisten Anwendungen wohl keine große Rolle spielen (daher auch "I2C compatible device"), die Unterschiede sind aber durchaus vorhanden. --Uwe Hermann 02:15, 3. Nov. 2009 (CET)

Ich habe mal ein "praktisch" vor das "gleich" eingefügt samt einer Anmerkung. Ebenso einen Hinweis auf die "zwei Drähte". -- Pemu (Diskussion) 22:52, 1. Mai 2019 (CEST)

Extended I²C

Es sollte vielleicht erwähnt werden, dass es auch das Extended I²C-Protokoll gibt, bei dem im Unterschied zum normalen I²C-Protkoll nicht nur eines sondern zwei Adressbytes verwendet werden, was die Adressierung von 2^18 Einheiten zulässt. Damit lassen sich I²C-EEPROMs mit bis zu 256 kByte Speicher über den I²C-Bus anbinden.

Ein "Extended I²C-Protokoll" gibt es nicht. Es gibt nur die 10Bit Adressierung und die ist im Artikel beschrieben. Wie die einzelnen Speicherbereiche eines EEPROM angesprochen werden hat mit der eigentlichen I²C-Spezifikation nichts zu tun. Die I²C Adresse für ein EEPROM ist (meist) eine 7bit Adresse. --KrautiS 22:05, 22 Jul 2008

Synchron

Was unbedingt in den Artikel hinein muss, ist der Hinwis, dass es sich beim I²C-Protokoll um ein synchrones, serielles Protokoll handelt. Die üblichen seriellen Schnittstellen, die man so vom eigenen PC kennt (Netzwerk, USB, COM-Ports) sind ja asynchron. Master und Slave beim I²C-Bus sind über eine gemeinsame Daten- und Taktleitung miteinander verbunden, wobei der Master den Takt angibt. Und im Gegensatz zu asynchronen Protokollen, ist die Taktfrequenz völlig egal, so lange sie unterhalb der Maximalfrequenz liegt. Genaugenommen ist es sogar falsch, von einer Frequenz zu sprechen, weil der Abstand zwischen zwei Zustandswechseln auf der Taktleitung nach Belieben schwanken kann. Daher eignet sich das I²C-Protokoll übrigens auch hervorragend für Lehrübungen.

Wenn das target clock streching betreibt, ist das sofort nicht mehr synchron. 84.161.228.55 17:58, 22. Apr. 2024 (CEST)

In Datenblättern findet sich aber dennoch die Angabe für die Frequenz. z.B. SCL frequency = ... Und dies ist auch solange so, solange eben z.B. kein Clockstreching stattfindet. (nicht signierter Beitrag von 84.152.246.10 (Diskussion | Beiträge) 18:12, 28. Jul 2009 (CEST))

Imho ist das Wort Clock in der Bezeichnung SCL unglücklich gewählt, da das entsprechende Signal eher eine Art Bit-Handshake ist. Nach meinem Verständnis von synchron ist I²C ein asynchroner Bus, so wie der 68000 ein asynchrones Busprotokoll hat (mit DTACK, BG und DS, oder wie das alles hieß).

Nach Artikel Synchrone Datenübertragung kann ich es nicht entscheiden. Einerseits werden die Bits "mit einem Taktsignal" (eben SCL) "zeitlich synchronisiert". Andererseits besteht keine "starre Phasenbeziehung über mehrere Symbolzeichen hinweg". Insbesondere trifft aber "Das Gegenstück ist die asynchrone Datenübertragung, bei der zwischen den Symbolzeichen beliebig lange (oder auch zufällig lange) Pausen auftreten können, womit keine starre Phasenbeziehung mehr vorliegt" zu.

Für mich am entscheidendsten ist aber, dass die Busteilnehmer keine gemeinsame Taktversorgung (damit meine ich jetzt nicht SCL, sondern einen 'richtigen' Takt) brauchen.

-- Pemu (Diskussion) 12:08, 8. Mär. 2012 (CET)

Pegel

Hi, hab hier noch nichts über die zu verwendenen Pegel gelesen. Z.B. Low =0 - 1.7V / High = 2.7-5V oder so. Weis aber im moment nicht was richtig ist. Das sollte noch erwänt werden.

Meiner Meinung sind die Pegel im Artikel falsch beschrieben. Laut Spezifikation ist alles unter 0,3*Vdd ein Low und alles über 0,7*Vdd ein High. Die Versorgundsspannung ist dabei nicht definiert, da verschiedene Technologien eingesetzt werden können (CMOS,NMOS etc). (nicht signierter Beitrag von 134.108.60.179 (Diskussion | Beiträge) 10:47, 11. Mai 2010 (CEST))

Gebe meinem Vorredner Recht. Im Moment steht es falsch! Eine relative Angabe wäre laut 1. Quelle bzw. Bus-Spezifikation richtig. Eine Angabe in Volt ist irreführend. --85.183.154.78 18:28, 22. Mär. 2011 (CET)

I2C is vom Pegel nicht definiert. Die laufen inter-Chip auf 2,5 aber auch 3,3V. 84.161.228.55 17:58, 22. Apr. 2024 (CEST)

Adressierung

1. Es sind nicht 8 Adressen reserviert, sondern 16, nämlich alle die mit "0000" und "1111" beginnen. Steht in der Spezifikation (Rev. 03 - 19 June 2007) auf Seite 17. Deshalb sind es nicht 120, sondern nur 112 Knoten. (Dies wird übrigens auch auf der unten angegebenen Seite http://www.i2c-bus.org/addressing/ ausgesagt.) Es ist theoretisch aber möglich auch die reservierten Adressen zu verwenden, solange garantiert wird, dass diese niemals für ihren eigentlichen Zweck verwendet werden. Da dies m.E. aber eine Insellösung darstellt finde ich nicht, dass darauf näher eingegangen werden sollte.

2. Die Angabe der maximalen Knoten bei der 10-bit-Adressierung ist falsch. Es stehen NICHT wie bislang aufgeführt 2^10-7=1017 Adressen zur Verfügung, vielmehr können ALLE 10 Bits genutzt werden, womit 1024 Adressen zur Verfügung stehen. Dies kommt dadurch, dass diese Erweiterung eine Untermenge der bereits erwähnten reservierten Adressen ist und die 7 anderen "Reservierungen" (die ja eigentlich sowieso 12 wären, s.o.) nicht erneut abgezogen werden müssen. Eine auf zwei Byte verteilte 10-bit-Adresse beginnt immer mit "1111 0". Zudem können beide Adressierungsarten gemischt werden und man erhält eine maximale Adresszahl von 1024+112=1136 Adressen.

Ich habe beides mal korrigiert.

Patente

Die Angabe IIC sei komplett frei von Patenten stimmt so nicht. NXP hält noch gültige Patente für die 10 Bit Slave Adresse und ein paar andere Details. Der 1.10.2006 war übrigens auch kein Ablauftag für irgend ein Patent zum IIC. 14:40, 10. Jun. 2009 (CEST) Nachsigniert, hab übersehen, dass ich nicht angemeldet war TheBug 00:09, 11. Jun. 2009 (CEST)

Abgelaufen, oder ? 84.161.228.55 17:58, 22. Apr. 2024 (CEST)

Abschnitt Elektrische Definition: Wired-AND?

Wired-AND macht irgendwie keinen Sinn, denn das würde ja bedeuten, daß alle Devices ihren Ausgang aktivieren müßten.

Wired-OR ist hingegen wohl eher die Funktionalität...

da der Krams 'ne Weile her ist und ich mich da gerade nicht mit intensiver beschäftigen kann, um es 100%ig zu verifizieren, hoffe ich mal auf jemanden, der/die das nochmal gegencheckt und dann entsprechend ändert (nicht signierter Beitrag von 77.8.90.142 (Diskussion) 11:51, 4. Jun. 2012 (CEST))

Die Spezifikation spricht selbst von "This procedure relies on the wired-AND connection of all I2C interfaces to the I2C-bus". Das ist auch richtig, denn alle Devices, die nichts zu sagen haben, halten ihr Signal auf "High" = "1". Wenn nichts los ist auf dem Bus sind alle Ausgänge auf "1" und nur wenn einer etwas zu sagen hat, setzt er seinen Ausgang auf "Low" = "0". Also müssen ALLE (A "und" B "und" C...) auf "1" sein, um das Gesamtsignal (über den Pull-Up Widerstand) auf "1" zu belassen. Das ist genau die UND-Funktion. --Wosch21149 (Diskussion) 12:47, 4. Jun. 2012 (CEST)

Es ist ein "wired not and" und damit logisch in "OR". Siehe boolsche Operationen. 84.161.228.55 17:58, 22. Apr. 2024 (CEST)

Wiederholung des Falschen macht es nicht richtiger. I2C verwendet positive Logik, d.h., eine "1" ist "High". Die aktive Phase des Clocks SCL ist die "1" und die Daten (SDA) sind "1" bei "High"-Pegel.

Der Denkfehler ensteht durch den Ansatz, dass jedes "Nicht 1" das Signal auf "0" zieht, also "Nicht-Signal" = "Nicht A" ODER "Nicht B" ODER "Nicht C"... Doch damit sind die Eingangssignale und das Ausgangssignal invertiert. Und invertierte Eingänge ver"ODER"t mit invertiertem Ausgang ergibt: AND! --Wosch21149 (Diskussion) 09:45, 23. Apr. 2024 (CEST)

Vermutlich kommt die Verwirrung daher, dass die Daten zwar positive Logik verwenden, aber die Bussignale dennoch mit Fug und Recht als active-low bezeichnet werden könnten (bspw. ACK = Low, NACK = High). -- Pemu (Diskussion) 00:13, 25. Apr. 2024 (CEST)

Entfernter Weblink

Eine IP hat einen Weblink auf die Application note 460 von Philips/NXP gelöscht, weil der Link tot war (vermutlich seit 2005). Da es sich um eine relativ beliebige AN handelt kann der Artikel imho den Verlust problemlos verschmerzen. Falls jemand andere Meinung ist, der möge bitte den Wayback-Link von 2004 einfügen. --Wassertraeger  10:50, 16. Mär. 2015 (CET)

Fehlende Tabelle? Text fehlerhaft?

Ein von mir eingesetzter I²C-Bus hat eine Taktrate (?) von 400 kHz. In der Tabelle, die auf „Die folgende Tabelle listet die maximal erlaubten Taktraten auf“ folgt, stehen jedoch keine Taktraten drin. (nicht signierter Beitrag von 91.19.201.214 (Diskussion) 18:05, 12. Jan. 2016 (CET))

Wegen der besseren Übersichtlichkeit sind alle Werte in Mbit/s angegeben. 400 kbit/s (400kHz) entspricht also dem Wert 0,4 Mbit/s in der Tabelle. --Wosch21149 (Diskussion) 23:56, 12. Jan. 2016 (CET)

Unverständlich

Was ist gemeint mit:

Lediglich bei geringen, zeitlich begrenzten Störungen, z. B. weit oberhalb der Signalfrequenz, kann das System mittels Signalverarbeitung stabiler gemacht werden.

-- Pemu (Diskussion) 18:40, 6. Sep. 2016 (CEST)

Filterung auf der Empfängerseite. Geht analog und digital 84.161.228.55 17:58, 22. Apr. 2024 (CEST)

User manual wo?

Das als Quelle verlinkte User Manual UM10204 unter http://www.nxp.com/docs/en/user-guide/UM10204.pdf scheint hinter einer Anmeldeschranke verschwunden zu sein. Hab mal den letzten Archiv-Link rausgesucht. Datum und Versionsbezeichnung im Dokument stimmen mit den Angaben bei den Beleg-Vorlagen-Parametern überein, so dass ich glaube, dass es das gemeinte Dokument ist. Ansonsten bitte meine letzte Änderung rückgängig machen – dann wird das archivierte Dokument nurmehr an einer Stelle verwendet, für die die Belegkraft von mir überprüft wurde. -- Pemu (Diskussion) 00:26, 27. Feb. 2023 (CET)