SPI to jeden z tych interfejsów, które świetnie sprawdzają się wtedy, gdy mikrokontroler ma szybko i przewidywalnie rozmawiać z pamięcią, czujnikiem albo wyświetlaczem. Angielska nazwa spi interface odnosi się do tego samego rozwiązania, choć w praktyce najczęściej mówi się po prostu SPI.
W tym artykule rozkładam ten protokół na konkretne elementy: pokazuję, jak działa transmisja, co oznaczają linie MOSI, MISO, SCK i CS, jak czytać tryby CPOL/CPHA oraz kiedy SPI ma przewagę nad I2C i UART. Dorzucam też rzeczy, które w projektach sprawiają najwięcej kłopotów, bo właśnie na nich najczęściej wykłada się pierwsze uruchomienie.
Najważniejsze rzeczy o SPI w kilku punktach
- SPI to synchroniczna magistrala szeregowa z zegarem generowanym przez urządzenie nadrzędne.
- Komunikacja jest pełnodupleksowa, więc dane mogą płynąć jednocześnie w obu kierunkach.
- Najczęściej używa czterech linii: SCK, MOSI, MISO i CS, a każdy układ podrzędny zwykle ma własny CS.
- Tryb pracy ma znaczenie: błędny dobór CPOL i CPHA daje zniekształcone lub przesunięte dane.
- SPI jest szybkie, ale lokalne - najlepiej działa na krótkich połączeniach na tej samej płytce lub bardzo blisko niej.
- To dobry wybór do pamięci, przetworników i wyświetlaczy, gdy liczy się przepustowość i prosty protokół.
Czym jest interfejs SPI i dlaczego wciąż jest tak popularny
SPI to prosty, synchroniczny interfejs szeregowy. Master generuje zegar, a oba urządzenia przesuwają dane bit po bicie zgodnie z tym zegarem, więc komunikacja jest bardzo przewidywalna. W praktyce to rozwiązanie lubię wtedy, gdy nie chcę tracić czasu na skomplikowaną warstwę protokołu, tylko potrzebuję szybkiego i stabilnego połączenia między układami.
W klasycznej wersji SPI korzysta z czterech sygnałów:
- SCK - zegar wysyłany przez mastera.
- MOSI - dane z mastera do układu podrzędnego.
- MISO - dane z układu podrzędnego do mastera.
- CS lub SS - wybór konkretnego układu, zwykle aktywny stan niski.
Najważniejsza zaleta jest prosta: nie ma adresowania na poziomie magistrali. Jeśli na jednej linii masz kilka układów, każdy z nich dostaje zwykle osobny sygnał CS, a wspólne pozostają linie zegara i danych. To upraszcza logikę i daje dużą szybkość, ale wymaga więcej przewodów niż I2C.
Z mojego doświadczenia SPI najczęściej wygrywa tam, gdzie liczy się mała latencja i wysoka przepustowość: pamięci flash, przetworniki ADC/DAC, sterowniki wyświetlaczy, moduły RF czy szybkie czujniki. To prowadzi wprost do pytania, jak dokładnie wygląda jedna transmisja i co dzieje się na przewodach w trakcie wymiany danych.
Jak przebiega pojedyncza transmisja
W SPI transfer nie zaczyna się sam z siebie. Master najpierw aktywuje linię CS dla wybranego układu, a dopiero potem podaje zegar. Od tej chwili obie strony przesuwają bity zgodnie z ustalonym trybem pracy, a każdy takt zegara może jednocześnie wypchnąć bit na MOSI i odczytać bit z MISO.
Najprościej wygląda to tak:
- Master wybiera jeden układ, ściągając CS do stanu aktywnego.
- Ustawia częstotliwość zegara i tryb zgodny z dokumentacją peryferium.
- Wysyła bajt lub serię bajtów, a równocześnie odbiera odpowiedź.
- Po zakończeniu ramki podnosi CS, zamykając transakcję.
To właśnie dlatego SPI jest pełnodupleksowe: w czasie jednego transferu możesz coś wysłać i coś odebrać. W praktyce bywa to bardzo wygodne, ale trzeba pamiętać, że niektóre układy zwracają sensowne dane dopiero po pierwszym bajcie albo po dodatkowych cyklach zegara. Ja przy uruchamianiu nowych peryferiów zawsze zakładam, że pierwszy odebrany bajt może być „roboczy”, dopóki dokumentacja nie powie czegoś innego.
Warto też pamiętać, że SPI nie narzuca jednej długości ramki. W zależności od układu transfer może mieć 8, 16 albo więcej bitów, a niektóre kontrolery pozwalają konfigurować ten parametr programowo. Gdy rozumiesz już sam przebieg transakcji, naturalnym kolejnym krokiem są tryby pracy, bo to one decydują o tym, na której krawędzi zegara dane są próbkowane.
Tryby pracy i sygnały czasowe, które trzeba ustawić bez zgadywania
Najwięcej błędów w SPI nie wynika z samego okablowania, tylko z niezgodności czasowej. Dwa bity konfiguracji - CPOL i CPHA - określają, jaki jest stan spoczynkowy zegara i na której krawędzi dane są próbkowane. Jeśli ustawisz je źle, transfer często wygląda „prawie dobrze”, ale w praktyce zwraca przesunięte lub kompletnie bezsensowne dane.
| Tryb | CPOL | CPHA | Stan zegara w spoczynku | Kiedy dane są próbkowane |
|---|---|---|---|---|
| Mode 0 | 0 | 0 | Niski | Na zboczu narastającym |
| Mode 1 | 0 | 1 | Niski | Na zboczu opadającym |
| Mode 2 | 1 | 0 | Wysoki | Na zboczu opadającym |
| Mode 3 | 1 | 1 | Wysoki | Na zboczu narastającym |
W praktyce nie ma jednego „najlepszego” trybu SPI. Układ nadrzędny i podrzędny muszą zgodzić się co do tej samej kombinacji CPOL i CPHA, a czasem producent dopuszcza tylko jeden albo dwa warianty. Jeśli odczyt wygląda jak przesunięty o jeden bit albo o cały bajt, ja w pierwszej kolejności sprawdzam właśnie tryb, a dopiero potem szukam problemów w lutach czy przewodach.
Tu wychodzi też różnica między SPI a bardziej „samowystarczalnymi” magistralami. Żeby lepiej zobaczyć kompromisy, dobrze porównać SPI z I2C i UART, bo wtedy łatwiej dobrać właściwy interfejs do konkretnego zadania. Właśnie to robi najwięcej porządku w projektach, które na papierze wyglądają podobnie.
SPI kontra I2C i UART w praktyce
Nie ma jednego interfejsu, który byłby najlepszy we wszystkim. SPI wygrywa szybkością i prostym timingiem, I2C oszczędza piny, a UART jest wygodny do punkt-punkt i diagnostyki. W praktyce wybór najczęściej sprowadza się do tego, czy ważniejsza jest przepustowość, liczba przewodów, czy prostota połączenia.
| Cecha | SPI | I2C | UART |
|---|---|---|---|
| Liczba linii | 3 sygnały wspólne + osobny CS dla każdego układu | 2 linie wspólne | 2 linie |
| Szybkość | Bardzo wysoka | Średnia | Zależna od konfiguracji, zwykle niższa niż SPI |
| Adresowanie | Brak na poziomie magistrali | Tak | Brak |
| Typowa topologia | Lokalna magistrala na jednej płytce | Wspólna magistrala z wieloma urządzeniami | Połączenie punkt-punkt |
| Najlepsze zastosowanie | Pamięci, wyświetlacze, szybkie czujniki, przetworniki | Czujniki i układy konfiguracyjne | Konsola, debug, moduły komunikacyjne |
Ja wybieram SPI wtedy, gdy mam krótki dystans, potrzebuję deterministycznego czasu odpowiedzi i nie chcę walczyć z ograniczeniami przepustowości. I2C jest wygodniejsze przy wielu prostych peryferiach, a UART nadal wygrywa tam, gdzie chodzi o prosty kanał komunikacyjny lub debug. Po wyborze interfejsu zaczyna się jednak najważniejsza część: poprawne wdrożenie na płytce i w oprogramowaniu.
Jak wdrożyć SPI w projekcie bez typowych potknięć
Dobierz poziomy napięć i logikę
Pierwszy krok to sprawdzenie poziomów logicznych. Układ 1,8 V nie zawsze będzie bezpośrednio współpracował z peryferium 3,3 V, a 5 V to już osobna historia. Jeśli napięcia się nie zgadzają, potrzebujesz konwertera poziomów albo przynajmniej świadomego projektu po stronie pinów. To nie jest detal - to jedna z najczęstszych przyczyn „martwego” SPI na stole testowym.
Ustal tryb i częstotliwość z dokumentacją urządzenia
W kodzie trzeba ustawić dokładnie ten tryb, który dopuszcza układ podrzędny. Częstotliwość zegara też nie jest dowolna: w realnych projektach często zaczyna się od niższej wartości, a dopiero potem podnosi ją do poziomu, który rzeczywiście działa stabilnie. W zależności od mikrokontrolera i peryferium można spotkać konfiguracje od pojedynczych megaherców aż do dziesiątek megaherców, ale to zawsze zależy od konkretnego sprzętu i jakości połączeń.
Zaprojektuj CS tak, żeby każdy układ miał własny wybór
Jeśli na jednej magistrali pracuje kilka układów, każdy z nich powinien mieć niezależny sygnał CS, o ile dokumentacja nie przewiduje innego mechanizmu. To upraszcza diagnostykę i zmniejsza ryzyko konfliktu na linii MISO. W projektach z większą liczbą peryferiów czasem stosuje się też dekodowanie linii wyboru albo łańcuch daisy-chain, ale wtedy trzeba dokładnie rozumieć, jak zachowuje się ramka danych.
Przeczytaj również: RFID z Arduino - Jak podłączyć czytnik i uniknąć błędów?
Zadbaj o ścieżki, masę i testy
SPI nie lubi długich, przypadkowo prowadzonych przewodów. Im wyższy zegar, tym bardziej rośnie znaczenie krótkich ścieżek, wspólnej masy i sensownego prowadzenia sygnałów. Na etapie uruchomienia bardzo pomaga analizator stanów logicznych, bo od razu pokazuje, czy problem leży w trybie pracy, w CS, czy w samym przesyle bitów. Jeśli układ ma sygnał gotowości albo busy, warto go też uwzględnić, zamiast zakładać, że każde peryferium odpowie natychmiast.
Gdy te cztery rzeczy są dopięte, SPI zwykle działa stabilnie i bez niespodzianek. Następny krok to szybka diagnoza objawów, które pojawiają się najczęściej podczas pierwszych testów.
Najczęstsze problemy i co zwykle jest ich przyczyną
| Objaw | Najbardziej prawdopodobna przyczyna | Co sprawdzam najpierw |
|---|---|---|
| Wszystkie odczyty mają wartość 0xFF albo 0x00 | CS nie jest aktywny, MISO jest źle podłączone albo linia jest w stanie pływającym | Poziom CS, mapę pinów i stan MISO podczas transferu |
| Dane wyglądają jak przesunięte o bit lub o bajt | Nieprawidłowy CPOL/CPHA | Tryb SPI w kontrolerze i w datasheet urządzenia |
| Układ działa tylko przy bardzo niskim zegarze | Za długie połączenia, słaba masa albo za duża pojemność linii | Długość ścieżek, jakość połączeń i częstotliwość SCK |
| Pierwszy bajt jest błędny, kolejne są poprawne | Układ potrzebuje bajtu „dummy” albo ma opóźnienie odpowiedzi | Sekwencję transakcji i opis protokołu w dokumentacji |
| Jeden slave zakłóca drugi | Konflikt na MISO albo niewłaściwe sterowanie CS | Stany nieaktywne CS i to, czy układy poprawnie zwalniają wyjście |
W praktyce najwięcej czasu oszczędza mi połączenie dwóch narzędzi: analizatora logicznego i spokojnego czytania timing diagramu. Bez tego łatwo jest zgadywać, a w SPI zgadywanie prawie zawsze kończy się kolejną rundą testów. Zostaje jeszcze ostatnia rzecz: krótka lista kontroli, którą warto przejść, zanim uznasz projekt za gotowy.
Co sprawdzam, zanim uznam magistralę za gotową do pracy
- Czy tryb CPOL/CPHA zgadza się z dokumentacją dla każdego układu na magistrali.
- Czy każdy slave ma osobny i poprawnie sterowany CS, a linia nie zmienia stanu przypadkiem podczas transmisji.
- Czy poziomy napięć są zgodne i nie potrzebują dodatkowego tłumaczenia logiki.
- Czy zegar nie jest ustawiony zbyt agresywnie jak na długość połączeń i jakość płytki.
- Czy MISO rzeczywiście przechodzi w stan wysokiej impedancji, gdy układ nie jest wybrany.
- Czy urządzenie nie wymaga bajtów zerowych lub dodatkowych cykli przed poprawnym odczytem danych.
Jeśli te punkty są spełnione, SPI daje bardzo stabilną i przewidywalną komunikację, a debugowanie przestaje być walką z przypadkowymi objawami. Właśnie dlatego ten interfejs nadal jest jednym z najpraktyczniejszych narzędzi w elektronice wbudowanej: nie jest najoszczędniejszy w przewody, ale za to daje szybkość, prostotę i bardzo czytelne zachowanie.
