Az SPI-t sokan busznak hívják. Pedig valójában klasszikusan nem az. Ugyanakkor kívülről akár hasonlíthat is hozzá, hiszen:
- több eszköz, és
- közös vezetékek, és
- gyors adatátvitel jellemzi.
De hiányzik belőle az, amitől egy valódi busz busz lenne:
- nincs címzés,
- nincs arbitrázs,
- nincs ütközéskezelés.
Ezért az SPI inkább valódi pont-pont kommunikáció, amit csak “buszszerűen” használunk.
Miért nem valódi busz az SPI?
Egy klasszikus busz (I²C, CAN, RS-485) jellemzője, hogy:
- több eszköz van egyetlen vezetéken,
- azonos adatvonalat használnak az eszközök, és
- valamilyen logika dönti el, ki beszél rajta.
Az SPI-nél viszont nm teljesen íg van, mert:
- a master választja ki az eszközt, amihez
- külön CS (Chip Select) vezeték kell minden slave-hez.
Azaz nem közös a kommunikáció, hanem vezérelt kiválasztás történik.
De hogyan működik több slave eszköz az SPI-n?
Az alap bekötés egyszerű. Közös vezetékek:
- MOSI,
- MISO,
- SCLK / SCK.
Külön vezetékezéssel megoldott a CS (ChipSelect, azaz a chip kiválasztás):
- CS1,
- CS2,
- CS3, …
A kiválasztás kötött szabálya, hogy:
egyszerre csak egy CS lehet aktív.
Ha kettő lenne mégis aktív, akkor:
- két slave eszköz válaszolna egyszerre, és így
- a MISO közössé vált vonal összeakad.
De z már nem “protokollhiba”, hanem fizikai konfliktus!
Miért nem szereti az SPI kialakítás a csillag topológiát?
Elsőre logikusnak is tűnik az oka, hiszen:
- egy központi MCU van benne,
- több irányba vezetékek futnak.
De az SPI esetén:
- gyors fel- és lefutó jel-élek,
- nincs differenciális jelátvitel,
- nincs jelvisszaverődés-kezelés.
A csillag topológia pedig:
- fokozott lecsengést,
- túllövést,
- instabil jelet okoz!
Ezért a kulcsmondat: SPI = rövid, rendezett vezetékek.
A CS kezelése – a legtöbb hiba forrása
Tipikus hibák, amiket tuti mindenki elkövet egyszer….
❌ Két CS egyszerre LOW → adatütközés
❌ CS túl korán felengedve → hiányzó bitek
❌ CS nincs stabil szinten resetkor → slave “összezavarodik”
Tipp: Sok SPI probléma nem a sebesség, hanem a CS miatt van.
Több slave esetén mire figyelj tervezéskor és programozáskor?
1️⃣ MISO tri-state viselkedés
A slave-nek: csak aktív CS-nél szabad meghajtani a MISO-t.Ha tartod be: a busz összeakad.
2️⃣ Időzítés CS és órajel között
Sok eszköz megköveteli: CS LOW → kis várakozás → első clock. Ha nincs betartva: az első bit elveszik.
3️⃣ Pull-up / pull-down a CS-en
Resetkor a GPIO lebeghet. A megoldás: fel- vagy lehúzó ellenállás beépítése és így determinisztikus indulás.
De mikor kezd szétesni az SPI kommunikáció?
Ha az alábbiakat sikerül külön-külön vagy akár egyszerre összehozni:
- hosszú kábel használata,
- sok slave eszköz beépítése,
- csillag topológia kialakítása,
- magas órajel használata.
Ilyenkor az SPI kommunikáció mér nem skálázható megfelelően.
Ezért az alábbiakat tarts szem előtt:
- ha sok eszköz van → I²C vagy RS-485 buszrendszer,
- ha nagy távolság → differenciális busz legyen
SPI vs. valódi busz – gyors összehasonlítási tipp
| Tulajdonság | SPI | I²C / RS-485 |
|---|---|---|
| Címzés | nincs | van |
| Ütközéskezelés | nincs | van |
| Kábelhossz | rövid | hosszabb |
| Több eszköz | CS kell | natív |
Tipp: SPI = gyors, de nem skálázható jól.
Gyakori tévhitek a SPI kommunikációnál
❌ “SPI busz” elnevezés,
❌ “Csak kössük rá még egy eszközt” hibás elve,
❌ “Majd firmware-ben kezeljük” probléma (nem) megoldás.
Az SPI működésének ugyanis a a fizikai réteg szabja meg a határát!
Rövid “SPI-iránytű”
- Sok SPI eszköz → több CS kell,
- Hosszú vezeték → SPI nem ide való,
- Random bitek → CS időzítés,
- Több slave → ellenőrizd a MISO tri-state-et,
- Skálázni kell → gondolkodj más buszrendszerben!
És egy összegző gyors zárógondolat
Az SPI:
- nagyon gyors,
- nagyon egyszerű,
- de nem busz.
Amíg:
- rövid vezeték,
- kevés slave,
- tiszta topológia,
alakítható ki – addig kiváló.
De ha elkezded “buszként” használni: a problémák törvényszerűen megjelennek.
Ez a cikk a → Buszrendszerek mikrokontroller-projektekhez mini-cikksorozat része.
← Előző: 🔀 🪢 Buszválasztó: hogyan döntsd el, melyik kommunikációs busz való a projektedbe?
