I2C-Kommunikation mit dem PIC ist eine der praktischsten Fähigkeiten, wenn Sie Sensoren, IO-Expander oder serielle EEPROMs einfach und zuverlässig anbinden möchten. Der große Vorteil: Mit nur zwei Leitungen – SDA (Daten) und SCL (Takt) – lassen sich mehrere Bausteine parallel betreiben, solange Adressen eindeutig sind und die Hardware sauber ausgelegt ist. Gleichzeitig ist I²C ein Protokoll, das im Embedded-Alltag für typische Stolperfallen bekannt ist: falsche Pull-up-Widerstände, zu hohe Buskapazität, fehlende Pegelkompatibilität, ungünstiges Layout oder ein Bus, der nach einem Fehler „hängen bleibt“, weil ein Teilnehmer SDA dauerhaft low hält. Wer hier nur Code kopiert, bekommt oft ein System, das im Labor funktioniert, aber im Feld sporadisch ausfällt. In diesem Beitrag lernen Sie I²C systematisch: von den elektrischen Grundlagen (Open-Drain, Pull-ups, Rise Time) über die PIC-Hardware (MSSP bzw. Stand-Alone-I²C) bis zur robusten Software-Logik für typische Anwendungen wie das Auslesen von Sensorregistern und das Schreiben/Lesen von I²C-EEPROMs. Ziel ist, dass Sie Sensoren und EEPROMs nicht nur „irgendwie“ zum Laufen bringen, sondern die I²C-Kommunikation mit dem PIC stabil, nachvollziehbar und skalierbar aufbauen.
I²C in der Praxis: Was das Protokoll so besonders macht
I²C ist ein synchroner, bidirektionaler Zwei-Draht-Bus. Entscheidend ist das elektrische Prinzip: SDA und SCL sind in der Regel Open-Drain/Open-Collector-Leitungen. Kein Teilnehmer treibt die Leitung aktiv auf High – stattdessen ziehen Pull-up-Widerstände die Leitungen in den High-Zustand, wenn niemand sie auf Low zieht. Dadurch können mehrere Teilnehmer „wired-and“ zusammenarbeiten, und auch Clock-Stretching (ein Client hält SCL low, um Zeit zu gewinnen) ist möglich. Für PIC-Projekte heißt das: I²C ist nicht nur Firmware, sondern immer auch Hardware-Design.
- Multi-Device: Mehrere Sensoren/EEPROMs am gleichen Bus, sofern Adressen passen.
- Bus statt Punkt-zu-Punkt: Leitungen werden geteilt, was Layout und Pull-ups wichtiger macht.
- Fehlerbilder sind oft elektrisch: „Kein ACK“, „Bus hängt“, „nur bei langer Leitung instabil“.
Die PIC-Seite: MSSP vs. Stand-Alone-I²C und warum das wichtig ist
Viele PICs nutzen das MSSP-Modul (Master Synchronous Serial Port), das sowohl SPI als auch I²C unterstützt. Microchip beschreibt das MSSP-I²C-Konzept in der Online-Dokumentation und betont, dass damit beide Protokolle mit derselben Hardware implementiert werden können (I2C im MSSP (Microchip Online Docs)). Neuere 8-Bit-PICs können zusätzlich ein Stand-Alone-I²C-Modul haben, das gegenüber MSSP Varianten und neue Features bietet; Microchip stellt dazu ein Migrationsdokument bereit (MSSP zu Stand-Alone-I²C Migration (PDF)).
- MSSP (klassisch): weit verbreitet, solide, typische Registerlogik für I²C Master/Slave.
- Stand-Alone-I²C (neu): mehr Flexibilität, potenziell weniger Software-Overhead (geräteabhängig).
- Konsequenz für Sie: Prüfen Sie im Datenblatt, welches I²C-Modul Ihr PIC tatsächlich hat, bevor Sie Registerbeispiele übernehmen.
Hardware-Basics: Pull-up-Widerstände sind kein „Optional-Zubehör“
Ohne Pull-ups funktioniert I²C nicht zuverlässig. Die Widerstände bestimmen, wie schnell die Leitungen wieder auf High kommen (Rise Time) und wie stark die Teilnehmer Low ziehen müssen (Sink Current). Microchip bietet eine kompakte und praxisnahe Erklärung zur Dimensionierung von I²C-Pull-ups (I2C Pull-Up Resistor Sizing (Microchip Support)) und erläutert in der Online-Dokumentation zudem die Formeln zur Auswahl externer Pull-ups (External Pull-up Resistor Selection (Microchip Online Docs)).
Pull-up-Minimum: Strombegrenzung beim Low-Pegel
Der Pull-up darf nicht zu klein sein, sonst muss ein Teilnehmer zu viel Strom sinken, um Low sicher zu erreichen. Ein häufig verwendetes Minimum basiert auf Versorgung, maximalem Low-Pegel und dem garantierten Sink-Strom:
Damit stellen Sie sicher, dass ein Client die Leitung ausreichend weit nach unten ziehen kann, ohne außerhalb seiner Spezifikation zu arbeiten.
Pull-up-Maximum: Rise Time und Buskapazität
Ist der Pull-up zu groß, steigen SDA/SCL zu langsam an. Dann werden Flanken unklar, und bei höheren I²C-Geschwindigkeiten treten ACK-Probleme, Bitfehler oder scheinbar „zufällige“ Ausfälle auf. Ein gebräuchlicher Zusammenhang ist die RC-basierte Annäherung zwischen Rise Time
Umgestellt ergibt sich eine grobe Obergrenze für den Pull-up:
In der Praxis heißt das: Lange Leitungen, viele Teilnehmer und ungünstiges Layout erhöhen
Bus-Topologie und Layout: So vermeiden Sie typische I²C-Ausfälle
I²C ist empfindlicher als viele erwarten, weil es nicht als Hochgeschwindigkeits-Leitungssystem gedacht ist. Mit guter Verdrahtung und passenden Pull-ups läuft es aber sehr zuverlässig. Die wichtigsten Layout- und Topologie-Regeln:
- Kurze Leitungen bevorzugen: Je länger die Leitung, desto höher die Kapazität und Störanfälligkeit.
- Sternverteilung vermeiden: Lieber eine „Buslinie“ als viele lange Abzweige.
- Saubere Masseführung: Sensoren brauchen eine stabile Bezugsmassse; sonst „wandern“ Pegel.
- Entkopplung pro Baustein: Lokaler Kondensator nahe VDD/VSS reduziert Störungen beim ACK.
- Pegelkompatibilität prüfen: 3,3 V und 5 V mischen nur mit Level-Shifter oder tolerantem IO-Design.
Wenn Sie mehrere Module (z. B. Sensorboard + EEPROM) verbinden, ist die Summe aus Kapazitäten das entscheidende Maß. In vielen Fällen ist es besser, auf 100 kHz zu gehen und dafür stabil zu bleiben, als „400 kHz um jeden Preis“ zu erzwingen.
Adressierung und Datenformat: 7-Bit, 10-Bit und Registerzugriffe
In den meisten Anwendungen nutzen Sensoren und EEPROMs 7-Bit-Adressen. Die Adresse wird auf dem Bus zusammen mit einem R/W-Bit übertragen. In Datenblättern finden Sie oft eine „8-Bit-Adresse“ (inklusive R/W-Bit), was in der Firmware zu Verwirrung führt. Bewährt ist diese Praxis:
- In Firmware: 7-Bit-Adresse als Basis speichern.
- Beim Senden: R/W-Bit explizit setzen (Write = 0, Read = 1), je nach API/Driver.
- Datenblatt lesen: Prüfen, ob eine Adresse bereits „shifted“ dargestellt ist.
Sensoren werden meist über Register angesprochen: Sie schreiben zunächst eine Registeradresse, dann lesen Sie Datenbytes. Das typische Muster ist „Write Register Pointer“ gefolgt von „Repeated Start“ und Read. Viele PIC-Beispiele zeigen genau diesen Ablauf mit MSSP als Host (Master), etwa im Technical Brief „Getting Started with I2C Using MSSP on PIC18“ (Getting Started with I2C Using MSSP on PIC18 (PDF)).
Die I²C-Sequenz verstehen: Start, Address, ACK, Data, Stop
Ein stabiler PIC-I²C-Treiber folgt immer denselben Grundbausteinen. Wenn Sie diese Sequenz klar im Kopf haben, finden Sie Fehler schneller:
- Start Condition: Master signalisiert Busbeginn.
- Address + R/W: Zieladresse, Richtung wählen.
- ACK/NACK: Empfänger bestätigt (ACK) oder lehnt ab (NACK).
- Data Bytes: Transfer, jedes Byte wird bestätigt.
- Stop Condition: Busfreigabe.
Wenn Sie „kein ACK“ bekommen, ist das fast immer eine von vier Ursachen: falsche Adresse (7/8-Bit-Verwechslung), falsche Pull-ups/Rise Time, Pegelinkompatibilität oder der Bus ist nicht frei (SDA/SCL hängen low). Solche Ursachen sind schneller behoben, wenn Sie die Sequenz gezielt mit Logic Analyzer prüfen.
Software-Ansatz: Polling oder Interrupts – was ist sinnvoll?
Für Einsteiger ist Polling oft leichter: Sie führen jeden Schritt aus und warten auf das entsprechende Statusflag. Für robuste Systeme – insbesondere wenn UART, Timer und PWM parallel laufen – sind Interrupt- oder State-Machine-Ansätze häufig stabiler, weil Sie nicht blockieren und Timeouts sauber handhaben können. Microchip stellt dazu konkrete Beispielprojekte bereit, in denen I²C-Read/Write mit Interrupts umgesetzt wird (PIC18F47Q10 I2C Read/Write mit Interrupts (Microchip GitHub)) sowie Tutorials, die I²C mit MCC konfigurieren und dann in der Anwendung nutzen (Demonstrating 8-bit I2C Controller Read (Microchip Developer Help)).
- Polling: einfacher Ablauf, gut für kleine Projekte und Debugging.
- Interrupt/State Machine: besser für Echtzeit, vermeidet Blockaden, benötigt saubere Zustandslogik.
- Timeouts: in beiden Varianten Pflicht, um „Bus hängt“-Zustände zu erkennen und zu verlassen.
Sensoren am I²C-Bus: Register lesen und typische Muster
Die meisten I²C-Sensoren (Temperatur, Druck, Luftfeuchte, IMU) arbeiten registerbasiert. Drei Muster sind besonders häufig:
- Single Register Read: Registerpointer setzen, 1–2 Bytes lesen (z. B. Temperaturwert).
- Burst Read: Registerpointer setzen, mehrere Bytes am Stück lesen (z. B. XYZ-Achsen).
- Write Configuration: Konfigurationsregister schreiben, dann Messdaten periodisch lesen.
Repeated Start korrekt nutzen
Viele Sensoren erwarten für Register-Lesezugriffe einen Repeated Start (ohne Stop dazwischen). Der Ablauf ist: Start → Adresse+Write → Registeradresse → Repeated Start → Adresse+Read → Daten… → Stop. Wenn Sie stattdessen Stop/Start trennen, funktioniert es bei manchen Sensoren dennoch, bei anderen jedoch nicht. Daher lohnt es sich, die Sequenz im Datenblatt des Sensors exakt nachzuvollziehen und die MSSP-Statusbits sauber auszuwerten.
Richtiger Umgang mit NACK beim letzten Byte
Beim Lesen mehrerer Bytes sendet der Master meist ACK nach jedem Byte, um „mehr Daten“ anzufordern. Beim letzten Byte sendet er NACK, um die Übertragung zu beenden, und setzt danach Stop. Wenn Sie fälschlich ein ACK senden, kann der Sensor ein weiteres Byte bereitstellen, und Ihre Firmware gerät aus dem Takt.
I²C-EEPROMs anbinden: Warum sie sich anders verhalten als Sensoren
Serielle EEPROMs (z. B. 24xx-Familie) sehen auf den ersten Blick wie „einfacher Speicher“ aus, haben aber eine Besonderheit: Schreibvorgänge passieren intern zeitverzögert. Nach einem Page-Write ist das EEPROM für eine gewisse Zeit im Write Cycle beschäftigt und antwortet nicht mit ACK. Microchip beschreibt dieses Verhalten und empfiehlt ACK-Polling, um den Abschluss des Schreibzyklus zu erkennen (24AA256/24LC256/24FC256 Datasheet – ACK Polling (PDF)).
Page Write verstehen: schneller schreiben, aber nur innerhalb einer Page
Viele EEPROMs erlauben Page Writes (z. B. bis 64 Bytes bei 24LC256). Sie senden Start → Adresse+Write → Word Address (High/Low) → Datenbytes… → Stop. Intern schreibt das EEPROM die Daten in einem Rutsch. Wichtig: Wenn Sie über das Page-Ende hinaus schreiben, „wrappt“ das EEPROM oft innerhalb der Page, und Daten werden überschrieben. Das ist einer der häufigsten Fehler bei Logging- oder Parameterblöcken.
ACK Polling als robustes Abschlusskriterium
Nach dem Stop beginnt der interne Write Cycle. Währenddessen antwortet das EEPROM nicht mit ACK. Beim ACK Polling senden Sie wiederholt Start + Adresse+Write und prüfen, ob ACK kommt. Sobald ACK kommt, ist der Write Cycle fertig, und Sie können weitermachen. Genau dieses Verfahren ist im Microchip-Datenblatt als Standardmechanismus beschrieben (24LC256 – Acknowledge Polling (PDF)).
Praktische Robustheit: Bus-Recovery und „hängt SDA low“
Ein realer I²C-Bus kann in einen Zustand geraten, in dem SDA dauerhaft low bleibt. Ursachen sind z. B. ein unterbrochener Transfer, ein Reset eines Teilnehmers mitten in der Kommunikation oder ein Sensor, der Clock-Stretching „nicht sauber beendet“. Für robuste Systeme sollten Sie daher mindestens zwei Mechanismen planen:
- Timeouts: Jeder Transfer muss ein Zeitbudget haben; wird es überschritten, wird abgebrochen.
- Bus-Recovery: SCL als GPIO takten (z. B. 9 Pulse), um einen blockierenden Client „freizuschieben“, danach Stop erzeugen.
Das Bus-Recovery-Muster ist besonders wichtig, wenn Ihr Gerät im Feld ohne manuelles Eingreifen wieder stabil werden muss. Der Boot-Prozess kann einen Bus-Check machen: Wenn SDA oder SCL low ist, Recovery versuchen, dann erst die normale Initialisierung starten.
MCC und Beispielprojekte: Schneller Start ohne Registerstress
Für viele PICs lässt sich I²C über MPLAB Code Configurator (MCC) sehr schnell konfigurieren. Microchip zeigt in aktuellen Tutorials, wie ein PIC im I²C-Host-Mode mit Client-Geräten interagiert, inklusive Interrupt-Varianten (Getting Started with I2C (Microchip Online Docs)). Zusätzlich helfen Beispiel-Repositories, um eine saubere Projektstruktur zu übernehmen (I2C Read/Write Interrupt Example mit MCC).
- Vorteil MCC: korrekte Pin-/Peripherie-Zuordnung, konsistente Initialisierung, schneller Proof-of-Concept.
- Wichtig: Generierten Treiber als Basis nutzen, Applikationslogik in eigenen Modulen halten.
- Nachvollziehbarkeit: Pull-ups, Busgeschwindigkeit und Timeouts bleiben Ihre Verantwortung – MCC löst keine elektrischen Probleme.
Geschwindigkeit wählen: 100 kHz, 400 kHz und die realistische Entscheidung
I²C-Geschwindigkeit ist eine Systementscheidung. Häufig wird 400 kHz gewählt, weil es „schneller“ ist. In vielen Sensor-/EEPROM-Anwendungen ist 100 kHz jedoch stabiler und völlig ausreichend. Entscheidend sind:
- Buskapazität: Je größer
C bus , desto schwerer erreichen Sie schnelle Rise Times. - Pull-up-Werte: Zu große Pull-ups begrenzen die Flankensteilheit.
- Teilnehmerfähigkeiten: Nicht jeder Client unterstützt 400 kHz über den gesamten Spannungsbereich.
- EMV/Umgebung: Lange Kabel, Störungen, Steckverbinder sprechen oft für niedrigere Frequenzen.
Eine pragmatische Vorgehensweise: Starten Sie bei 100 kHz, verifizieren Sie Stabilität (inkl. Worst-Case-Last), und erhöhen Sie erst dann, wenn ein messbarer Nutzen entsteht.
Typische Debugging-Checkliste: Wenn I²C nicht funktioniert
- Pull-ups vorhanden und passend? SDA/SCL müssen im Idle sauber High sein; Pull-up-Berechnung gegen Rise-Time prüfen (Microchip Pull-up Sizing).
- Adresse korrekt? 7-Bit vs. 8-Bit-Verwechslung ausschließen.
- Pegel kompatibel? 3,3-V-Sensor an 5-V-PIC nur mit Level-Shifter oder tolerantem IO.
- Bus frei? SDA/SCL dürfen nicht dauerhaft low sein; ggf. Bus-Recovery.
- ACK/NACK-Logik korrekt? Letztes Read-Byte muss oft NACK bekommen.
- EEPROM Write Cycle berücksichtigt? Nach Write ACK Polling nutzen (24LC256 Datasheet (ACK Polling)).
- Mit Logic Analyzer prüfen: Start/Stop, Adresse, ACK-Bits, Wiederholungen sichtbar machen.
Weiterführende Outbound-Links: Offizielle Anleitungen und Beispiele
- Microchip: Getting Started with I2C Using MSSP on PIC18 (PDF)
- Microchip Online Docs: I2C im MSSP
- Microchip Support: I2C Pull-Up Resistor Sizing
- Microchip Online Docs: External Pull-up Resistor Selection
- Microchip Developer Help: I2C Controller Read Tutorial
- Microchip Online Docs: Getting Started with I2C (Beispiele)
- Microchip GitHub: I2C Read/Write mit Interrupts und MCC
- Microchip Datasheet: 24AA256/24LC256/24FC256 I2C EEPROM (PDF)
- Microchip: MSSP zu Stand-Alone-I²C Migration (PDF)
IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung
PCB Design • Arduino • Embedded Systems • Firmware
Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.
Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.
Leistungsumfang:
-
IoT-PCB-Design & Schaltplanerstellung
-
Leiterplattenlayout (mehrlagig, produktionstauglich)
-
Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)
-
Firmware-Entwicklung für Embedded Systems
-
Sensor- & Aktor-Integration
-
Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART
-
Optimierung für Leistung, Stabilität & Energieeffizienz
Lieferumfang:
-
Schaltpläne & PCB-Layouts
-
Gerber- & Produktionsdaten
-
Quellcode & Firmware
-
Dokumentation & Support zur Integration
Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert
CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.
