Der Begriff spi mode 0 beschreibt die Grundkonfiguration eines SPI-Takts, bei der der Clock im Leerlauf low bleibt und Daten an der steigenden Flanke abgetastet werden. Genau an dieser Stelle entstehen in der Praxis die meisten Fehler: nicht am Bus selbst, sondern an der Frage, ob Master und Slave wirklich dieselbe Timing-Vereinbarung sprechen. In diesem Artikel zeige ich, wie ich CPOL und CPHA lese, wie man ein Timing-Diagramm sauber interpretiert und worauf ich bei der Inbetriebnahme in Mess-, Funk- und Steuerplatinen besonders achte.
Die wichtigsten Punkte auf einen Blick
- CPOL = 0 bedeutet: Der Takt steht im Idle auf low.
- CPHA = 0 bedeutet: Gesampelt wird an der ersten aktiven Flanke, also bei Mode 0 an der steigenden Flanke.
- Bei diesem Modus ändert der Sender die Daten typischerweise an der fallenden Flanke, damit sie zur nächsten steigenden Flanke stabil sind.
- Master und Slave müssen den gleichen Modus verwenden, sonst entstehen Bitverschiebungen oder scheinbar zufällige Registerwerte.
- Das Datenblatt des Zielbausteins ist wichtiger als die Bezeichnung des Modus allein, weil Setup- und Hold-Zeiten je nach Gerät abweichen können.
Was der SPI-Modus 0 elektrisch bedeutet
Der SPI-Modus 0 ist kein Sonderfall, sondern die klar definierte Kombination aus CPOL = 0 und CPHA = 0. Ich lese das immer so: Der Takt liegt im Ruhezustand auf low, und die Nutzdaten werden an der steigenden Flanke übernommen. Zwischen zwei aktiven Flanken bleibt das Bit stabil genug, damit der Empfänger es zuverlässig lesen kann.
Wichtig ist dabei die Reihenfolge im Kopf. Zuerst wird Chip Select aktiv, dann beginnt der Takt, und erst dann läuft die Bitübertragung los. In vielen Bausteinen wird das erste Bit, meist das MSB, bereits vor der ersten Sampling-Flanke vorbereitet. Genau deshalb ist der Modus nur dann stabil, wenn auch die Vorlaufzeit des Datenpins und die Reaktionszeit des Slaves passen. Damit ist klar, warum man bei SPI nie nur auf den Modusnamen schauen sollte, sondern immer auf das komplette Timing. Das führt direkt zur Frage, was CPOL und CPHA im Detail voneinander trennt.
CPOL und CPHA ohne Missverständnisse
Die beiden Einstellungen werden oft in einen Topf geworfen, obwohl sie zwei unterschiedliche Dinge beschreiben. CPOL legt fest, auf welchem Pegel die Clocklinie im Leerlauf steht. CPHA bestimmt, auf welcher Flanke abgetastet wird. Erst aus beiden Werten ergibt sich der Modus.
| Parameter | Bedeutung | Auswirkung in Mode 0 |
|---|---|---|
| CPOL | Clock-Ruhepegel | Idle low |
| CPHA | Abtastzeitpunkt relativ zur Clockflanke | Abtastung an der ersten aktiven Flanke |
| Mode 0 | Kombination aus CPOL = 0 und CPHA = 0 | Gesampelt wird an der steigenden Flanke, geändert typischerweise an der fallenden Flanke |
Ich halte mir noch eine zweite Regel parat: Der Modus sagt etwas über das Timing, nicht über die Übertragungsqualität. Ein gut gesetzter Modus kann bei 1 MHz stabil laufen und bei 20 MHz scheitern, wenn die Leitung zu lang ist oder der Baustein träge reagiert. Darum lohnt es sich, das Timing-Diagramm nicht nur zu lesen, sondern wirklich zu interpretieren. Genau das mache ich im nächsten Schritt.
So lese ich ein Timing-Diagramm
Wenn ich ein SPI-Diagramm prüfe, gehe ich immer in derselben Reihenfolge vor. Das verhindert, dass man sich von der Taktform ablenken lässt und am Ende die falsche Flanke für das eigentliche Problem hält.
- Chip Select aktivieren. Erst wenn `CS` low ist, darf die Übertragung als gültig gelten.
- Ruhezustand der Clock prüfen. Bei Mode 0 muss `SCLK` vor dem Start low sein.
- Erste Flanke identifizieren. Die erste aktive Flanke ist die steigende Flanke.
- Sample-Zeitpunkt festlegen. Genau dort liest der Empfänger das Bit ein.
- Wechselpunkt des Senders ansehen. Zwischen zwei steigenden Flanken wird das nächste Bit vorbereitet, oft an der fallenden Flanke.
- Bytegrenzen und Bitreihenfolge prüfen. Ob MSB first oder LSB first läuft, ist eine separate Einstellung und nicht automatisch Teil des Modus.
Praktisch heißt das: Wenn ein erster Bitwert zu spät anliegt, kippt nicht nur ein Byte, sondern oft die komplette Folge. Deshalb suche ich bei Messungen zuerst nach dem ersten sauberen Übergang und nicht erst nach dem fünften oder sechsten Bit. Diese Sichtweise ist besonders nützlich bei Modulen in Kommunikations- und Infrastrukturprojekten, weil dort oft mehrere Bausteine mit denselben Leitungen arbeiten. Daraus ergibt sich die Frage, in welchen Fällen Mode 0 tatsächlich die beste Wahl ist.
Wann dieser Modus in der Praxis sinnvoll ist
Der SPI-Modus 0 ist in vielen Designs ein sehr guter Startpunkt, weil er breit unterstützt wird und sich für einen großen Teil von Sensoren, Wandlern, Speicherbausteinen und Interface-Modulen eignet. Ich sehe ihn häufig in Steuerplatinen, Messknoten und Kommunikationsmodulen, also dort, wo digitale Daten zuverlässig und ohne viel Protokolloverhead fließen sollen. Gerade in Infrastruktur- und Funkumgebungen ist das hilfreich, weil einfache und robuste Timing-Modelle die Fehlersuche verkürzen.
| Einsatzfall | Warum Mode 0 oft passt | Worauf ich achte |
|---|---|---|
| Sensoren und ADCs | Viele Bausteine erwarten Idle-low und Sampling auf der steigenden Flanke | Datenblatt, maximale Clockfrequenz, Setup- und Hold-Zeiten |
| Kommunikationsmodule | Einfaches Timing erleichtert die Integration in Controller und Gateways | CS-Verhalten und Latenz des ersten Antwortbytes |
| Displays und Peripherie | Mode 0 ist oft die verbreitetste Werkseinstellung | Bitreihenfolge und Wortlänge |
| Mess- und Diagnosesysteme | Gut lesbares Timing erleichtert Scope- und Logic-Analyzer-Checks | Signalqualität auf kurzen und längeren Leitungen |
Trotzdem würde ich nie sagen, dass dieser Modus automatisch richtig ist. Manche Bausteine verlangen Mode 1, 2 oder 3, und manche Geräte reagieren zwar irgendwie auf Mode 0, liefern aber nur unter Laborbedingungen saubere Werte. Genau dort beginnen die typischen Fehler, die ich im Feld am häufigsten sehe.
Typische Fehler bei der Inbetriebnahme
- Falscher Modus am Controller. Der Master läuft im Default oft nicht in dem Modus, den der Slave erwartet. Das äußert sich dann nicht immer als Totalausfall, sondern oft als verschobene Bits.
- Zu frühes Freigeben von `CS`. Wenn Chip Select zu schnell wieder high geht, wird das letzte Bit oder das Antwortbyte abgeschnitten.
- Falsche Annahme über die erste Flanke. Viele Debugger zeigen nur die Clock, nicht aber, ob an der ersten Flanke schon gültige Daten anlagen.
- Bitreihenfolge verwechselt. Mode 0 sagt nichts über MSB first oder LSB first aus. Diese Einstellung muss separat stimmen.
- Zu hohe Taktfrequenz für Leitung und Bauteil. Bei längeren Leitungen oder langsamen Treibern sieht Mode 0 auf dem Papier gut aus, im Signal aber nicht mehr.
- Bitbanging mit ungenauen Flanken. Softwaretaktung wirkt oft stabil, ist aber bei höherer Last oder Interrupts deutlich störanfälliger als Hardware-SPI.
Wenn ich ein Problem suche, prüfe ich zuerst die erste Flanke, dann `CS`, dann die Taktfrequenz. Diese Reihenfolge spart Zeit, weil sie die häufigsten Fehlerquellen früh trifft. Aus dieser Diagnose ergibt sich auch meine kurze Prüfliste für den ersten sauberen Transfer.
Die drei Messpunkte, die ich vor dem ersten stabilen Transfer prüfe
- Konfiguration im Datenblatt. Ich gleiche CPOL, CPHA, Bitreihenfolge, Wortlänge und maximale Clock direkt mit dem Zielbaustein ab.
- Signalbild auf dem Oszilloskop oder Logic Analyzer. Ich schaue, ob `SCLK` im Idle low bleibt, ob die erste aktive Flanke wirklich rising ist und ob `MISO` beziehungsweise `MOSI` rechtzeitig stabil werden.
- Erster Byteaustausch bei niedriger Frequenz. Ich starte bewusst langsam, oft im unteren Bereich, und erhöhe erst danach die Geschwindigkeit. So trenne ich Timingfehler von reinen Signalproblemen.
Mein Fazit ist schlicht: Wer den SPI-Modus 0 versteht, denkt nicht nur in einer Zahl, sondern in einem Timingvertrag zwischen zwei Bausteinen. Genau diese Sichtweise macht den Unterschied zwischen einem Prototypen, der nur zufällig läuft, und einer Schnittstelle, die auch unter realen Bedingungen stabil bleibt. Wenn ich ein Board debugge, beginne ich deshalb immer mit der Clock, nicht mit dem Datenwort.
