Wybór między I2C a SPI zwykle nie sprowadza się do teorii, tylko do bardzo konkretnych ograniczeń: liczby dostępnych pinów, szybkości odczytu, długości ścieżek na PCB i liczby urządzeń na jednej magistrali. W praktyce i2c vs spi to kompromis między prostotą okablowania a przepustowością oraz przewidywalnością transmisji. Poniżej rozbijam różnice tak, jak patrzę na nie przy projektowaniu elektroniki: od topologii i adresacji, przez prędkość, aż po typowe błędy, które najczęściej psują komunikację.
Najkrótsza odpowiedź brzmi tak
- I2C wybieram, gdy liczy się mała liczba przewodów i kilka lub kilkanaście peryferiów na jednej płytce.
- SPI wybieram, gdy potrzebuję wyższej przepustowości, niższych opóźnień i pełnego dupleksu.
- I2C działa na dwóch wspólnych liniach SDA i SCL, ale wymaga rezystorów podciągających oraz unikalnych adresów urządzeń.
- SPI zwykle potrzebuje osobnej linii CS dla każdego układu, za to jest prostsze czasowo i lepiej znosi szybkie transfery.
- Standardowe tryby I2C obejmują 100 kbit/s, 400 kbit/s, 1 Mbit/s, 3,4 Mbit/s i 5 Mbit/s w Ultra-Fast mode.
- Jeśli projekt ma dużo czujników i mało miejsca na PCB, częściej wygrywa I2C; jeśli obsługuje wyświetlacz, pamięć Flash albo szybki ADC, zwykle lepszy jest SPI.
Na czym naprawdę polega różnica między I2C i SPI
Na poziomie idei oba interfejsy robią podobną rzecz: łączą mikrokontroler z peryferiami bez szerokiej magistrali równoległej. Różnica zaczyna się w szczegółach. I2C to wspólna magistrala dwuprzewodowa z adresowaniem urządzeń i arbitrażem, a SPI to synchroniczny interfejs pełnodupleksowy, w którym host wybiera układ linią CS i wymienia dane bez pośredniego adresu. Właśnie dlatego w praktyce nie chodzi o „lepszy standard”, tylko o właściwy kompromis dla danego projektu.
| Cecha | I2C | SPI | Co to oznacza w praktyce |
|---|---|---|---|
| Linie sygnałowe | 2 wspólne linie: SDA i SCL | Zwykle SCLK, MOSI, MISO i osobny CS dla każdego układu | I2C oszczędza piny, SPI szybciej rośnie liczbowo wraz z liczbą urządzeń |
| Model transmisji | Najczęściej half-duplex | Full-duplex | SPI potrafi jednocześnie wysyłać i odbierać dane |
| Adresowanie | Tak, zwykle 7 bitów, czasem 10 | Brak adresowania w samym protokole | I2C lepiej skaluje się przy wielu małych układach, SPI wymaga selekcji CS |
| Warstwa elektryczna | Open-drain z rezystorami podciągającymi | Typowo wyjścia push-pull | I2C wymaga doboru pull-upów, SPI bardziej zależy od jakości layoutu |
| Arbitraż | Wbudowany | Zwykle brak | I2C lepiej radzi sobie z wieloma kontrolerami na jednej linii |
| Typowa rola | Konfiguracja, czujniki, ekspandery, RTC | Wyświetlacze, pamięci, ADC/DAC, szybkie sensory | Wybór często wynika z charakteru danych, a nie z przyzwyczajenia |
Jak opisuje NXP w specyfikacji I2C, wspólna magistrala ma własne tryby prędkości, ale jej zachowanie zawsze trzeba czytać razem z ograniczeniami elektrycznymi i z tym, co robią najwolniejsze urządzenia. To ważne, bo od tego punktu zaczyna się już nie teoria, tylko realny projekt PCB. Jeśli rozumiem ten fundament, łatwiej mi ocenić, czy problemem będzie liczba pinów, czy raczej tempo danych i jakość sygnału.
Okablowanie i adresowanie przesądzają o wygodzie projektu
I2C wygrywa wtedy, gdy liczba przewodów ma znaczenie. Dwie linie sygnałowe, SDA i SCL, mogą obsłużyć wiele urządzeń, o ile każde ma unikalny adres. To daje dużą oszczędność na małych płytkach, ale wymaga rezystorów podciągających i uważnego pilnowania adresów. W SPI sprawa jest prostsza logicznie, ale mniej oszczędna pinowo: linie zegara i danych są wspólne, a każdy dodatkowy układ zwykle dokłada osobny CS. W praktyce oznacza to, że przy kilku peryferiach SPI szybciej zużywa GPIO niż I2C.
- W I2C domyślnie pracuje adresowanie 7-bitowe, a 10-bitowe jest raczej wyjątkiem niż regułą.
- W SPI nie ma adresu w protokole, więc selekcję urządzenia robi linia CS.
- Przy wielu układach I2C trzeba uważać na konflikt adresów, bo dwa identyczne sensory potrafią unieruchomić cały bus.
- Przy wielu układach SPI rośnie liczba ścieżek i pinów, ale sama logika pozostaje bardzo przejrzysta.
W projektach z większą liczbą peryferiów lubię patrzeć na to brutalnie praktycznie: jeśli mam 6 czy 8 układów i każdy ma własne możliwe adresy, I2C oszczędza mi bardzo dużo miejsca. Jeśli za to dwa urządzenia mają ten sam adres albo potrzebuję rozbudowy w przyszłości, zaczynam się zastanawiać nad SPI albo nad dodatkowym multiplekserem. Z tej różnicy wynika też kolejny temat, czyli prędkość i stabilność sygnału.
Prędkość, opóźnienie i jakość sygnału nie są równoważne
Jeżeli projekt ma przenosić tylko konfigurację, I2C zwykle wystarcza. Gdy jednak pojawiają się strumienie danych, odczyty z szybkiego przetwornika albo częste aktualizacje rejestrów, przewagę zyskuje SPI. I2C ma zdefiniowane tryby 100 kbit/s, 400 kbit/s, 1 Mbit/s, 3,4 Mbit/s i 5 Mbit/s w Ultra-Fast mode, ale ten ostatni jest jednokierunkowy, więc nie zastąpi każdej implementacji. W dodatku przy magistrali mieszanej tempo całego połączenia ogranicza najwolniejsze urządzenie.
W I2C najczęściej nie sam protokół, tylko fizyka linii spowalnia projekt: rezystory podciągające, pojemność ścieżek i zbyt wolne zbocza. Za słabe podciąganie daje za wolne narastanie sygnału, za mocne zwiększa pobór prądu i obciąża układy. Clock stretching pomaga, bo urządzenie podrzędne może chwilowo zatrzymać SCL, ale nie rozwiązuje źle dobranej topologii ani nie naprawia kiepskiego layoutu. To jest protokół odporny, ale nie magiczny.
SPI działa inaczej. Jak opisuje Microchip, to synchroniczny interfejs zazwyczaj z trzema lub czterema przewodami, zaprojektowany do szybkiej transmisji między hostem a peryferium. Nie ma jednej „urzędowej” szybkości tak jak w I2C, bo limit zależy od konkretnego układu i projektu płytki. Zaletą jest pełny dupleks i proste ramkowanie: jeden takt zegara przenosi bit w obie strony, a host sam decyduje, kiedy zaznacza dany układ CS. Minusem jest większa wrażliwość na długość ścieżek, przesłuchy i zły wybór trybu CPOL/CPHA, czyli ustawienia polaryzacji i fazy zegara.
Jeśli sygnał zaczyna się sypać, w I2C zwykle pierwsze podejrzenie pada na pull-upy i pojemność magistrali, a w SPI na tryb pracy albo jakość połączeń. To prowadzi naturalnie do pytania, w jakich zastosowaniach każdy z interfejsów rzeczywiście ma sens.Kiedy lepszy będzie I2C
Z mojego doświadczenia I2C sprawdza się najlepiej tam, gdzie danych nie ma dużo, za to peryferiów jest sporo. Czujniki temperatury, wilgotności i ciśnienia, układy RTC, ekspandery GPIO, kontrolery zasilania i część pamięci EEPROM to klasyczne przykłady. W takich projektach oszczędność pinów i prostsze prowadzenie ścieżek często są ważniejsze niż maksymalna przepustowość.
- Wiele małych układów na jednej płytce - jeden bus może obsłużyć cały zestaw sensorów i pomocniczych układów.
- Konfiguracja i diagnostyka - I2C dobrze nadaje się do odczytu rejestrów statusu i ustawień.
- Mały koszt połączeń - dwa sygnały zamiast kilku osobnych linii do każdego peryferium.
Warunek jest jednak prosty: adresy muszą się nie pokrywać, a obciążenie magistrali nie może być zbyt duże. Jeśli dwa układy mają ten sam adres, zaczyna się kombinowanie z pinami adresowymi, przełączaniem zasilania albo dodatkowym multiplekserem I2C. Jeśli na przewodzie robi się zbyt dużo pojemności, trzeba wrócić do pull-upów i długości ścieżek. W praktyce większość problemów z I2C nie wynika z samej idei interfejsu, tylko z ignorowania tych ograniczeń.
Gdy jednak rosną wymagania czasowe albo trzeba przerzucać więcej danych, wchodzę już w świat SPI, bo tam kompromisy wyglądają inaczej.
Kiedy lepszy będzie SPI
SPI wybieram wtedy, gdy ważniejsza jest szybkość niż minimalna liczba przewodów. Ekrany, pamięci Flash, przetworniki ADC i DAC, szybkie czujniki oraz układy, które trzeba aktualizować często i z małym opóźnieniem, korzystają z tego, że SPI jest pełnodupleksowe i nie wymaga adresowania w obrębie magistrali. Host nie czeka, aż urządzenie „odpowie” w stylu I2C; po prostu zaznacza CS i zaczyna transfer.
- Strumienie danych - SPI lepiej znosi częste, regularne transfery.
- Deterministyczny timing - łatwiej przewidzieć moment pobrania i wysłania bitu.
- Pełny dupleks - jednoczesny odczyt i zapis jest naturalną cechą interfejsu.
W zamian płacisz liczbą pinów i większą dyscypliną layoutu. Każdy dodatkowy układ zwykle oznacza kolejny CS, a przy kilku peryferiach łatwo też pomylić tryb pracy albo kolejność bitów. Są też układy 3-przewodowe i połączenia łańcuchowe, ale traktuję je jako wyjątki, nie regułę. Jeśli projekt ma rosnąć, warto od początku sprawdzić, czy wybrany układ wspiera taki model, bo nie każdy go obsługuje. Dlatego przed wdrożeniem dobrze jest wyłapać najczęstsze błędy, zanim trafią na płytkę.
Najczęstsze błędy, które psują komunikację
- I2C bez poprawnych pull-upów - linia podnosi się za wolno, a komunikacja zaczyna gubić bity.
- Zakładanie, że każdy układ ma unikalny adres - dwa identyczne sensory potrafią odpowiedzieć jednocześnie i zablokować bus.
- Ignorowanie pojemności magistrali - zbyt długie ścieżki i źle prowadzone przewody psują zbocza sygnału.
- SPI z błędnym CPOL lub CPHA - host i peryferium próbują próbkuować dane w innych momentach.
- Za dużo aktywnych CS jednocześnie - w SPI to prosta droga do konfliktu na linii danych.
- Przekonanie, że SPI rozwiązuje problem adresacji - nie rozwiązuje, tylko przenosi selekcję urządzeń na osobne linie CS.
Jeśli po stronie I2C widzę NACK, losowe odczyty albo zawieszanie magistrali, zaczynam od adresu, pull-upów i czasu narastania. Gdy SPI zwraca śmieci albo przesunięte bity, najczęściej sprawdzam tryb pracy, selekcję CS i długość ścieżek. To są nudne rzeczy, ale właśnie one najczęściej robią różnicę w praktyce.
Jak dobrać magistralę do własnej płytki bez zgadywania
- Policz wolne GPIO i liczbę urządzeń, które naprawdę muszą być podłączone.
- Oceń, czy dane mają być przesyłane okazjonalnie, czy w regularnym strumieniu.
- Sprawdź adresy, tryby i wymagania elektryczne w datasheetach peryferiów.
- Zastanów się nad długością ścieżek, jakością masy i tym, czy sygnały będą prowadzone na jednej płytce, czy przez przewody.
- Jeśli po tym nadal masz remis, wybierz I2C dla konfiguracji i SPI dla danych.
W praktyce bardzo często nie wybieram jednego interfejsu „na wszystko”. W jednym projekcie I2C obsługuje czujniki i rejestry konfiguracyjne, a SPI przenosi szybkie próbki lub steruje wyświetlaczem. To zwykle najrozsądniejszy układ, bo wykorzystuje moc obu protokołów zamiast próbować nagiąć jeden do wszystkiego. Jeśli mam trzymać się jednej reguły, brzmi ona tak: I2C dla gęstych, prostych i oszczędnych połączeń, SPI dla szybkich i przewidywalnych transferów.
