I3C-Mobile-Header

I3C in Mobilen Geräten

Wieso wird I3C benötigt?

Smartphones und andere Geräte verfügen über eine schnell wachsende Anzahl von mechanischen, Bewegungs-, biometrischen und Umgebungssensoren, die eine Vielzahl von Funktionen und Anwendungsfällen ermöglichen, mit denen Unternehmen ihre Produkte differenzieren. Diese Sensorverbreitung schafft erhebliche Designherausforderungen, insbesondere für Softwareentwickler. Ohne eine gemeinsame Methode zur Anbindung muss beispielsweise jeder Host-Controller über eine eigene Systemsoftware oder einen eigenen Treiber verfügen, um diese Hardware zu unterstützen. Jede Host-Controller-Implementierung kann auch andere Funktionen und Optimierungen bereitstellen.

Was Ist I3C und welche Vorteile bietet dieses bei Smartphones?

I3C ist eine skalierbare, schnelle Dienstprogramm- und Steuerbusschnittstelle zum Anschließen von Peripheriegeräten an einen Anwendungsprozessor, zur Optimierung der Integration und zur Verbesserung der Kosteneffizienz. Es bietet Entwicklern beispiellose Möglichkeiten, innovative Designs für jedes mobile Produkt zu entwickeln - von Smartphones über Wearables bis hin zu Systemen in Automobilen.

I3C ermöglicht das Anschließen von Peripheriegeräten an einen Anwendungsprozessor in jedem mobilen Gerät und vereinfachen dabei das Anschließen und Verwalten mehrerer Sensoren in einem Gerät. I3C ist vor allem für leistungsfähige Sensoren gedacht. Außerdem überträgt I3C Interrupts ohne zusätzliche Leitungen als Nachricht im Protokoll. Mit 10,6 MBit/s übertrifft I3C I2C um mehr als das Dreifache. Der High-Data-Rate-Modus erreicht 33 MBit/s. So kann I3C in manchen Fällen auch das leistungsfähigere Serial Peripheral Interface (SPI) ersetzen. Die Vorteile der I3C Spezifikation sind der geringere Stromverbrauch, die reduzierte Anzahl der Pins sowie Singalpfade sowie die hohe Übertragungsgeschwindigkeit bei gleichzeitiger Abwärtskompatibilität zu I2C. Zudem lassen sich Geräteadressen dynamisch allozieren.
Touch over I3C ist eine konvergierte Schnittstellenoption für verarbeitete und rohe Touch-Daten. CCI over I3C bietet eine schnellere, geringere Latenz und eine effizientere Kamerasteuerung. 

I3C-Design

I3C Signalpins

I3C verwendet dieselben zwei Signalpins wie I²C, die als SCL (serielle Uhr) und SDA (serielle Daten) bezeichnet werden. Der Hauptunterschied besteht darin , dass sie als I²C arbeitet Open-Drain - Ausgänge zu jeder Zeit, so dass seine Geschwindigkeit durch die resultierende langsame Signal begrenzt Anstiegszeit . I3C verwendet aus Gründen der Kompatibilität den Open-Drain-Modus, wechselt jedoch nach Möglichkeit zu Push-Pull-Ausgängen und enthält Protokolländerungen, um dies häufiger als in I²C zu ermöglichen. SCL ist ein herkömmliches digitales Taktsignal , das während der Datenübertragung vom aktuellen Busstrommaster mit einem Gegentaktausgang angesteuert wird. (Clock Stretching, eine selten verwendete I²C-Funktion, wird nicht unterstützt.) Bei Transaktionen mit I²C-Slave-Geräten hat dieses Taktsignal im Allgemeinen ein Tastverhältnis von ca. 50%. Bei der Kommunikation mit bekannten I3C-Slaves kann der Busmaster jedoch auf umschalten eine höhere Frequenz und / oder eine Änderung des Arbeitszyklus, so dass die SCL-Hochperiode auf höchstens 40 ns begrenzt ist. SDA überträgt den seriellen Datenstrom, der entweder vom Master oder vom Slave angesteuert werden kann, jedoch mit einer Rate, die durch das SCL-Signal des Masters bestimmt wird.

Aus Gründen der Kompatibilität mit dem I²C-Protokoll beginnt jede Transaktion damit, dass SDA als Open-Drain-Ausgang fungiert, wodurch die Übertragungsgeschwindigkeit begrenzt wird. Bei Nachrichten, die an einen I3C-Slave adressiert sind, wechselt der SDA-Treibermodus nach den ersten Bits in der Transaktion auf Push-Pull, sodass der Takt weiter auf 12,5 MHz erhöht werden kann. Diese Funktion mit mittlerer Geschwindigkeit wird als SDR-Modus (Standard Data Rate) bezeichnet. Im Allgemeinen wird SDA unmittelbar nach der fallenden Flanke von SCL geändert, und der resultierende Wert wird an der folgenden ansteigenden Flanke empfangen. Wenn der Master SDA an den Slave übergibt, geschieht dies ebenfalls an der fallenden Flanke von SCL. Wenn der Slave jedoch die Steuerung von SDA an den Master zurückgibt (z. B. nachdem er seine Adresse vor einem Schreibvorgang bestätigt hat), gibt er SDA bei der ansteigenden Flanke von SCL frei, und der Master ist dafür verantwortlich, den empfangenen Wert für die Dauer von SCL zu halten hoch. (Da der Master SCL ansteuert, wird zuerst die ansteigende Flanke angezeigt, sodass es zu einer kurzen Überlappungsperiode kommt, wenn beide SDA steuern . Da beide jedoch denselben Wert steuern, tritt kein Buskonflikt auf.)

I3C Framing?

Wie I²C verwendet I3C 9 Taktzyklen, um jedes 8-Bit-Byte zu senden. Der 9. Zyklus wird jedoch anders verwendet. I²C verwendet den letzten Zyklus für eine Bestätigung, die entgegengesetzt zu den ersten 8 Bits gesendet wird. I3C funktioniert für das erste (Adress-) Byte jeder Nachricht und für I²C-kompatible Nachrichten auf die gleiche Weise. Bei der Kommunikation mit I3C-Slaves sind Nachrichtenbytes nach der ersten Verwendung das 9. Bit ein ungerades Paritätsbit beim Schreiben und ein Ende -of-Daten-Flag beim Lesen. Schreibvorgänge dürfen nur vom Master beendet werden. Entweder der Master oder der Slave können einen Lesevorgang beenden. Der Slave setzt SDA auf niedrig, um anzuzeigen, dass keine Daten mehr verfügbar sind. Der Master übernimmt daraufhin SDA und generiert einen STOP oder einen wiederholten START. Damit ein Lesevorgang fortgesetzt werden kann, treibt der Slave SDA hoch, während SCL vor dem 9. Bit niedrig ist, lässt SDA jedoch schweben (Open-Drain), während SCL hoch ist. Der Master kann zu diesem Zeitpunkt SDA niedrig fahren (eine wiederholte START-Bedingung), um den Lesevorgang abzubrechen. 

Neuntes Bit I3C

Wie I²C verwendet I3C 9 Taktzyklen, um jedes 8-Bit-Byte zu senden. Der 9. Zyklus wird jedoch anders verwendet. I²C verwendet den letzten Zyklus für eine Bestätigung, die entgegengesetzt zu den ersten 8 Bits gesendet wird. I3C funktioniert für das erste (Adress-) Byte jeder Nachricht und für I²C-kompatible Nachrichten auf die gleiche Weise. Bei der Kommunikation mit I3C-Slaves sind Nachrichtenbytes nach der ersten Verwendung das 9. Bit ein ungerades Paritätsbit beim Schreiben und ein Ende -of-Daten-Flag beim Lesen. Schreibvorgänge dürfen nur vom Master beendet werden. Entweder der Master oder der Slave können einen Lesevorgang beenden. Der Slave setzt SDA auf niedrig, um anzuzeigen, dass keine Daten mehr verfügbar sind. Der Master übernimmt daraufhin SDA und generiert einen STOP oder einen wiederholten START. Damit ein Lesevorgang fortgesetzt werden kann, treibt der Slave SDA hoch, während SCL vor dem 9. Bit niedrig ist, lässt SDA jedoch schweben (Open-Drain), während SCL hoch ist. Der Master kann zu diesem Zeitpunkt SDA niedrig fahren (eine wiederholte START-Bedingung), um den Lesevorgang abzubrechen. 

I3C Bus Arbitration

Zu Beginn eines Rahmens können mehrere Geräte um die Verwendung des Busses kämpfen, und der Bus-Arbitrierungsprozess dient dazu, auszuwählen, welches Gerät die Steuerung der SDA-Leitung erhält. Sowohl in I²C als auch in I3C wird die Busarbitrierung mit der SDA-Leitung im Open-Drain-Modus durchgeführt, wodurch Geräte, die eine binäre 0 (niedrig) übertragen, Geräte überschreiben können, die eine binäre 1 übertragen. Konkurrierende Geräte überwachen die SDA-Leitung, während sie im offenen Modus betrieben werden. Drain-Modus. Immer wenn ein Gerät beim Senden eines hohen Zustands (1 Bit) einen niedrigen Zustand (0 Bit) auf dem SDA erkennt, hat es die Arbitrierung verloren und muss den Wettbewerb einstellen, bis die nächste Transaktion beginnt.

Jede Transaktion beginnt mit der Zieladresse, und die Implementierung gibt Zieladressen mit niedrigerer Nummer Priorität. Der Unterschied besteht darin, dass I²C keine Begrenzung für die Dauer der Schiedsgerichtsbarkeit hat (in der seltenen, aber rechtlichen Situation mehrerer Geräte, die versuchen, eine Nachricht an dasselbe Gerät zu senden, wird der Konflikt erst nach dem Adressbyte erkannt). I3C garantiert jedoch, dass das Schiedsverfahren spätestens am Ende des ersten Bytes abgeschlossen ist. Dadurch können Push-Pull-Treiber und schnellere Taktraten die meiste Zeit verwendet werden. Dies geschieht auf verschiedene Arten: I3C unterstützt mehrere Master, diese sind jedoch nicht symmetrisch. Einer ist der aktuelle Master und für die Erzeugung der Uhr verantwortlich.

Andere Geräte, die eine Nachricht auf dem Bus senden (In-Band-Interrupts oder sekundäre Master, die den Bus verwenden möchten), müssen vor dem Senden anderer Daten unter Verwendung ihrer eigenen Adresse entscheiden. Somit teilen sich keine zwei legalen Busnachrichten dasselbe erste Byte, außer wenn der Master und ein anderes Gerät gleichzeitig miteinander kommunizieren. I3C ermöglicht wie I²C mehrere Nachrichten pro Transaktion, die durch "wiederholte START" -Symbole getrennt sind. Die Schiedsgerichtsbarkeit erfolgt pro Transaktion, sodass diese nachfolgenden Nachrichten niemals einer Schiedsgerichtsbarkeit unterliegen. Die meisten I3C-Mastertransaktionen beginnen mit der reservierten Adresse 0x7E (1111110 2 ).

Da dies eine niedrigere Priorität als jedes I3C-Gerät hat, weiß der Master nach bestandener Arbitrierung, dass kein anderes Gerät um den Bus kämpft. Wenn I3C-Geräten als Sonderfall niedrige Adressen zugewiesen werden (I3C unterstützt die dynamische, vom Master gesteuerte Adresszuweisung), 0x7E kennt der Master diese Arbitrierung , sobald die Adresse eine Arbitrierung für genügend führende Bits gewonnen hat, um sie von einer zugewiesenen Adresse zu unterscheiden ist abgeschlossen und es kann auf Push-Pull-Betrieb auf SDA umgeschaltet werden. Wenn alle zugewiesenen Adressen kleiner als sind 0x40 , erfolgt dies nach dem ersten Bit. Wenn alle Adressen kleiner als sind 0x60 , erfolgt dies nach dem zweiten Bit und so weiter.

In dem oben beschriebenen Fall, in dem der aktuelle Master eine Transaktion mit der Adresse eines Geräts beginnt, das selbst um die Verwendung des Busses kämpft, übertragen beide ihre Adressbytes erfolgreich. Jeder erwartet jedoch, dass der andere die Adresse (durch Ziehen von SDA niedrig) für das folgende Bestätigungsbit bestätigt. Folglich wird keiner und beide den Mangel an Anerkennung bemerken. In diesem Fall wird die Nachricht nicht gesendet, aber der Master gewinnt die Schiedsgerichtsbarkeit: Möglicherweise wird ein wiederholter Start gesendet, gefolgt von einem erneuten Versuch, der erfolgreich sein wird.

Allgemeine Befehlscodes

Ein an die reservierte Adresse adressierter Schreibvorgang 0x7E wird verwendet, um eine Reihe von Spezialoperationen in I3C auszuführen. Alle I3C-Geräte müssen zusätzlich zu ihren individuellen Adressen Schreibvorgänge an diese Adresse empfangen und interpretieren. Erstens hat ein Schreibvorgang, der nur aus dem Adressbyte und keinen Datenbytes besteht, keine Auswirkung auf I3C-Slaves, kann jedoch zur Vereinfachung der I3C-Arbitrierung verwendet werden. Wie oben beschrieben, kann dieses Präfix die Arbitrierung beschleunigen (wenn der Master die Optimierung des Umschaltens auf Push-Pull-Midbyte unterstützt), und es vereinfacht den Master, indem ein etwas kniffliger Arbitrierungsfall vermieden wird. Wenn auf das Schreiben ein Datenbyte folgt, codiert das Byte einen "allgemeinen Befehlscode", eine standardisierte I3C-Operation. Befehlscodes 0–0x7F sind Broadcast-Befehle, die an alle I3C-Slaves gerichtet sind.

Ihnen können zusätzliche befehlsspezifische Parameter folgen. Befehlscodes 0x80–0xFE sind direkte Befehle, die an einzelne Slaves gerichtet sind. Darauf folgt eine Reihe wiederholter STARTs und das Schreiben oder Lesen in bestimmte Slaves. Während ein direkter Befehl ausgeführt wird, übermitteln Schreib- oder Lesevorgänge pro Slave befehlsspezifische Parameter. Diese Operation ersetzt die normale Antwort des Slaves auf eine I3C-Nachricht. Auf einen direkten Befehl können mehrere Nachrichten pro Slave folgen, denen jeweils ein wiederholter START vorausgeht. Dieser spezielle Modus endet am Ende der Transaktion (STOP-Symbol) oder der nächsten an adressierten Nachricht 0x7E . Einige Befehlscodes existieren sowohl in Broadcast- als auch in Direktform. Beispielsweise können die Befehle zum Aktivieren oder Deaktivieren von In-Band-Interrupts an einzelne Slaves gesendet oder an alle gesendet werden. Befehle zum Abrufen von Parametern von einem Slave (z. B. der Befehl GETHDRCAP, um ein Gerät zu fragen, welche Modi mit hoher Datenrate unterstützt werden) sind nur in direkter Form vorhanden.

HDR-Optionen (High Data Rate)

Jede I3C-Bustransaktion beginnt im SDR-Modus, aber der I3C-Master kann einen CCC-Broadcast-Befehl "Enter HDR" ausgeben, der allen I3C-Slaves mitteilt, dass die Transaktion in einem bestimmten HDR-Modus fortgesetzt wird. I3C-Slaves, die HDR nicht unterstützen, können dann den Busverkehr ignorieren, bis sie eine bestimmte "HDR-Exit" -Sequenz sehen, die sie darüber informiert, dass es Zeit ist, den Bus erneut zu hören. (Der Master weiß, welche Slaves HDR unterstützen, und wird daher niemals versuchen, HDR für die Kommunikation mit einem Slave zu verwenden, der dies nicht unterstützt.) Einige HDR-Modi sind auch mit I²C-Geräten kompatibel, wenn die I²C-Geräte über einen 50-ns-Spike-Filter in der SCL-Leitung verfügen. Das heißt, sie ignorieren einen hohen Pegel auf der SCL-Leitung, der weniger als 50 ns dauert. Dies ist in der I²C-Spezifikation erforderlich, jedoch nicht universell implementiert, und nicht alle Implementierungen ignorieren häufig wiederholte Spitzen.

Daher muss die I3C-HDR-Kompatibilität überprüft werden. Die kompatiblen HDR-Modi verwenden SCL-Impulse von höchstens 45 ns, sodass I²C-Geräte diese ignorieren. Der HDR-DDR-Modus verwendet eine Signalisierung mit doppelter Datenrate mit einem 12,5-MHz-Takt, um eine Rohdatenrate von 25 Mbit / s (effektiv 20 Mbit / s) zu erreichen. Dies erfordert das Ändern der SDA-Leitung, während SCK hoch ist, eine Verletzung des I²C-Protokolls, aber I²C-Geräte sehen den kurzen Hochimpuls auf SCL nicht und bemerken daher die Verletzung nicht. Die Modi HDR-TSP und HDR-TSL verwenden eines von drei Symbolen als ternäre Ziffern (Trits):

Ein Übergang von SDA und SCL (innerhalb von 12,8 ns voneinander empfangen), Nur ein Übergang von SCL oder Nur ein Übergang von SDA. Zwei Bytes plus zwei Paritätsbits (insgesamt 18 Bits) werden in sechs 3-Bit-Tripletts aufgeteilt, und jedes Triplett wird als zwei Trits codiert. Bei einer Geschwindigkeit von 25 Mtrit / s wird eine effektive Datenrate von 33,3 Mbit / s erreicht. Das Trit-Paar, das nur aus zwei Übergängen von SDA besteht, wird nicht zum Codieren von Daten verwendet, sondern zum Einrahmen, um das Ende einer HDR-Sequenz zu markieren. Obwohl dies die maximale Zeit zwischen SCL-Übergängen auf drei Trit-Zeiten begrenzt, überschreitet dies die 50-ns-Grenze für ältere I²C-Geräte. Daher kann der HDR-TSP-Modus (ternäres Symbol, rein) nur auf einem Bus ohne ältere I²C-Geräte verwendet werden. Um Busse mit I²C-Geräten (mit einem Spitzenfilter) zuzulassen, muss der HDR-TSL-Modus (ternäres Symbol, Legacy) verwendet werden. Dadurch bleibt die I²C-Kompatibilität durch Trit-Stuffing erhalten : Wenn nach einer steigenden Flanke bei SCL der folgende Trit nicht 0 ist, wird vom Sender ein 1-Trit (nur Übergang bei SCL) eingefügt und vom Empfänger ignoriert. Dies stellt sicher, dass der SCL niemals länger als eine Trit-Zeit hoch ist. 

Geräteklassen

Auf einem I3C-Bus im Standardmodus (SDR) können vier verschiedene Geräteklassen unterstützt werden:

  • I3C Hauptmaster
  • I3C Secondary Master
  • I3C-Slave
  • I²C-Slave (ältere Geräte).

Folgende I²C-Funktionen werden in I3C nicht unterstützt

Pull-up-Widerstände werden vom I3C-Master bereitgestellt. Externe Pull-up-Widerstände werden nicht mehr benötigt. Clock Stretching - Es wird erwartet, dass Geräte schnell genug sind, um mit Busgeschwindigkeit zu arbeiten. Der I3C-Master ist die einzige Taktquelle. Erweiterte I²C-Adressen (10 Bit). Alle Geräte an einem I3C-Bus werden mit einer 7-Bit-Adresse adressiert. Native I3C-Geräte verfügen über eine eindeutige 48-Bit-Adresse, die nur bei dynamischen Adresszuweisungen verwendet wird.

I3C Host Controller Interface

I3C HCI definiert einen gemeinsamen Satz von Funktionen für den Host-Controller und die Softwareschnittstelle, mit denen Klassendefinitionen basierend auf einem gemeinsamen Satz von Funktionen erstellt werden können. Die Definition ermöglicht herstellerspezifische Erweiterungen und Optimierungen, um Mehrwertfunktionen für Smartphones, Wearables, Internet of Things (IoT) und Automobile einfacher zu integrieren und mehr. Die Spezifikation bietet der Plattformsoftware ein effizientes Mittel, um mit den Funktionen des Master-Geräts auf dem I3C-Bus zu kommunizieren, und stellt einen stromsparenden Betrieb des Host-Controllers sicher. Das Endergebnis: Entwickler haben Zeit, sich auf die Integration von Kamera, Touch und anderen Komponenten und Funktionen zu konzentrieren, um ihre Produkte zu differenzieren. “

I3C Touch und Camera

I3C enthält zahlreiche speziell für die mobil Industrie entworfenen Spezifikationen. Diese Spezifikationserweiterungen für spezielle Anwendungsfällen erstrecken sich z.B. von Touch bis zu Kameraanbindungen und ermöglichen den Entwicklern eine leichtere Implementierung sowie kosten Ersparnis bei der Entwicklung.
I3C HCI, ist auch in der I3C  Touch- Spezifikationsfamilie enthalten, sodass Touch-Befehle und mehrere Datenströme verwendet werden können, um einem Design differenzierende Touch-Funktionen hinzuzufügen. Anwendungsprozessorunternehmen können die Spezifikation anwenden, um die in ihren Geräten verwendete HCI-Methode zu standardisieren. Die Spezifikation definiert mehrere Optimierungen basierend auf der typischen Verwendung. Beispielsweise ermöglicht die Kombinationsbefehlsfunktion die effiziente einmalige Übertragung von Schreib- und dann Leseübertragungen auf dem Bus. Ein weiteres Beispiel ist der automatische Befehl, mit dem ein großer Datenpuffer im Zusammenhang mit In-Band-Interrupts effizient gelesen werden kann.

I3C Protocol Analyzer und Host Adapter

PGY-I3C-EX-PD ist das führende Instrument, mit dem Konstrukteure und Testingenieure die I3C-Konstruktionen auf ihre Spezifikationen testen können, indem sie PGY-I3C-EX-ED als Master / Slave konfigurieren, I3C-Verkehr mit Fehlerinjektionsfunktion generieren und I3C dekodieren Protokolldecodierungspakete.

PGY-I3C-EX-PD I3C Protocol-Analyzer Product Picture 800
I3C Protokoll Exerciser und Analyzer
PGY-I3C-EX-PD
Der I3C Protokoll Analyzer and Exerciser ermöglicht die Dekodierung und Analyse des I3C-Protokolls sowie die Fehlersuche im I3C-Protokoll.

Preis auf Anfrage

Tektronix Oszilloskop I3C Protokoll Trigger & Dekode SoftwareTektronix Oszilloskop I3C Protokoll Trigger & Dekode Software
Tektronix Oszilloskop I3C Protokoll Trigger & Dekode Software
PGY-I3C-PD
Die I3C-Protokoll-Trigger- und Dekodiersoftware ermöglicht die schnelle Dekodierung I3C-Signalen und damit die Fehlersuche bei I3C-Protokollproblemen.

Preis auf Anfrage

Logic Analyzer für Embedded InterfacesLogic Analyzer für Embedded Interfaces
Logic Analyzer für Embedded Interfaces
PGY-LA-EMBD
Sparen Sie Zeit bei der Entwicklung. Der Logic Analyzer ermöglicht Protokollanalyse und Debugging auf Systemebene für I2C, SPI, UART, I3C, SPMI, CAN/CAN FD und RFFE

1.399,00 €*