När och varför väljer ni olika seriekommunikation?

[Magnus_K]

Sitter som vanligt och grubblar lite och nu blev det kommunikation mellan enheter som föll i smaken.

Vad är det för fördelar respektive nackdelar med de olika protokollen och hur tänker du när du väljer? Nu är det en nog en ganska öppen fråga men jag tänker mig typ kommunikation mellan mikrokontrollers eller omgivande sensorer/IC:s (tex ADC:er).
Väger ni t.ex. in vilket protkoll en extern ADC kommunicerar med eller blir det vad det blir?

Jag har försökt göra en liten förenklad sammanställning nedan men håll i hatten för jag mycket väl förstått något fel.

UART:
+ 2 kablar, en för sänding och en för mottagning
+ Valfri spänningsnivå (så länge komponenterna tillåter)
+ Möjlighet att till långa avstånd mellan enheterna. Speciellt vid +12V och -12V (RS-232)
+ Ofta möjlighet att använda en extra klockpuls genom "uppgradering" till USART och därmed göra kommunikation mindre timingkänslig
- Ej möjligt att hantera flera slavar under samma bus (stämmer det?)
- Timingkritiskt

SPI:
+ Mindre timingkritiskt än UART då den har en klockpuls
+ Kan hantera flera slavar under samma bus
- 3 kablar, SCK, MOSI och MISO

I²C:
+ 2 kablar, SCL och SDA
+ Kan hantera flera slavar under samma bus
+ Mindre timingkritiskt än UART då den har en klockpuls
- "Korta" avstånd mellan enheterna. Kanske 1 eller 2m.

[TomasL]

Av de du nämner är det bara I2C som är ett protokoll.
Varken SPI eller UART är ett protokoll, enbart en hårdvarufunktion.
Hur man väljer, beror helt på vad man skall göra.
SPI och I2C är i princip enbart lokal kommunikation på samma kort (eller mellan olika kort i samma låda)
Vilket man väljer, beror helt och hållet på vilka kretsar man skall kommunicera med.
SPI går att köra väldigt fort vid korta avstånd och noggrann kretsdesign, klockhastigheter på 40MHz är i regel inga problem.
Dock går det åt många processorpinnar om man skall kunna kommunicera med flera enheter, i vissa fall kan man dock Daisy-chaina enheterna (seriekoppla på svenska) och på så sätt spara pinnar och ledningar.
SPI är dock ett helsike då det inte finns någon egentlig standard, där man har flera olika moder på klocka och data, vilka ofta är inkompatibla med varandra.
SPI är relativt enkel att "BitBanga" om man saknar HW-Stöd.
SPI är i princip bara ett seriellt shiftregister, inget annat, så det är enkelt att realisera i hårdvara om man vill.

I2C används på samma sätt som SPI, men är adresserbar (kräver då bara 2 signaler), och arbetar med betydligt lägre klockhastighet, ett helsike att Bitbanga då den har ett något komplicerat protokoll, dock har de flesta processorer stöd för I2C i hårdvara så man behöver inte fundera så mycket på det.
I2C är svårt att själv realisera i hårdvara, då det är mycket timing och speciella start/stoppsekvenser inblandade.
En variant av I2C är SM-Bus (SMB), med något annorlunda elektriska specifikationer, men i princip helt kompatibel med I2C.

UART, tja om man skall köra serieport mot en PC eller något annat.
Om man vill köra RS485/RS422 över längre sträckor osv.

Med UART (och SPI) måste man själv konstruera sitt protokoll, om man inte vill använda sig av ett befintligt, till exempelvis MODBUS eller SLIP eller liknande.

Vidare, vill man kommunicera mot en serieport på en PC behöver man för det mesta komplementera med en RS232-krets, så man får korrekta elektriska nivåer.
Observera att RS232/RS422/RS485/V24 etc INTE är några kommunikationsprotokoll utan elektriska specifikationer över vilka signaler som skall finnas, spänningsnivåer, kontaktdonens utseende osv.

Förutom dessa ovanstående olika typerna av seriella interface finns ju naturligtvis en mängd ytterligare, en del enbart elektriska specifikationer och en del kombination av elektriska och data, till exempelvis LON-bus, OW-bus, CAN-Bus, LIN-bus, ETHERNET osv

Rent generellt, under 0,5m inom samma hölje I2C/SPI, längre avstånd eller utanför höljet RS232/RS485/RS422 osv.

[Micke_s]

Uart när pc:n är inblandad eller flera processorer.

Spi när man vill ha lite hastighet, denna buss är oftast enklare att få fungera än i2c.

I2c: massa givare mm kör i2c, mellan processorer har jag kört några ggr, dock skulle jag inte rekommendera i2c mellan två processorer. Denna buss brukar också ge mest olustkännslor hos mig av dessa tre.

I2C och MCU EERATA verkar nästan vara synonymer.

[TomasL]

Så här gör vi:
AD/DA-omvandlare DIG-IO mm SPI (eftersom kretsarna bara finns med SPI)
Minnen, lite blandad kompott, en del minnen finns bara i SPI och en del bara i I2C.
Även I2C till andra grejjor, typ OW-brygga mm, då dessa enbart finns i I2C.
Mellan olika processorer i samma Hölje, ren pin2pin UART med lite HW-handskakning interrupt osv, för det mesta så snabbt som UARTarna kan hantera det.
Mellan olika enheter UART och RS485/RS232 med lite olika protokoll, dels MODBUS och dels eget protokoll.
Till Ethernet MAC/PHY 40MHz SPI.
Display/CF/knappsats(tangentbord) 16 bitars 8080-bus
De enda bussarna som når utanför höljet är RS232/RS485 bussarna samt OW-bussarna.

[baron3d]

När det gäller antal anslutningar kan det variera.

SPI har normalt 4 signaler, SCK, MOSI, MISO och CS/SS.
Med extra komponenter går det att reducera till 3 och till och med ner till 2 anslutningar.
Där CS styrs med extra komponenter samt MOSI och MISO kombineras.

UART kan variera mellan 1 till 4 anslutningar i normala fall.
t.ex. har RS485 full duplex 4 anslutningar.
TX och RX går att kombinera till en anslutning.

I en CAN-bus är TX och RX kombinerade till en balanserad två tråds bus.
Det går att köra med samma elektriska interface med UART.

Både SPI och UART går att köra multi-master beroende på hur det elektriska interfacet är konstruerat.

[Magnus_K]

Ni ska ha stort tack för riktigt bra inlägg. Jättebra riktlinjer!
Ändrar titeln till kanske mer korrekt "seriekommunikation" istället för "serieprotokoll" efter Tomas påpekande.

Förstår också att min lilla lista var lite väl generell när det kommer till antal anslutningar.

Med all den här informationen så känns det för min egna del som att jag ska fokusera ett tag på SPI. I²C är säkert ett måste framöver men eftersom det ändå finns så mycket enheter som har stöd för SPI så blir fokus där ett tag.

[ojz0r]

Jag har programmerat (på hobbybasis dock) rätt mycket SPI genom bit bangning och det är smidigt att många komponenter man köper för SPI brukar ha valfri adressering, vilket sparar I/O.
Så man skickar först ut adressen på slaven och sedan skickar/tar du emot meddelandet.
SPI går teoretiskt att köra på långa avstånd om man drar ned klockhastigheten.

[xxargs]

För längre sträckor och högre hastighet så handlar det alltid någon form av driver (tex. RS485) och en transmissionsledare (tex tvinnad par) och en mottagare och kabeln skall termineras med en motstånd samma som kabelns karaktäriska impedans för att undvika reflexer.


Det finns inga genvägar för detta och hur fort man i verkligheten kan köra beror på hur förfinat och kontrollerad miljö för överföringen man kan skapa i avseende driver, mottagare och använd transmissionsmedium (kabel) och inte minst - aktuell längd mellan enheterna.

på tex SATA kör man uppemot 6 Gbit/s på en trådpar med resonabel längd på kabeln

en gammal version byggd med enkla transistorer som Open Collector och TTL-ingångar är tex SCSI-bussen och där körde man typ 10 Mbit/par på vanlig bandkabeln upp till 15 meter (varannan ledare jord/återledare för att skapa en hyffsat impedans-kontrollerad transmissionsledare) och i ändarna terminerades med mittpunkten på 220 och 330 Ohm spänningsdelare mellan +5V och jord och den vägen skapar en termineringsimpedans på 132 Ohm (AC-mässigt så är plus och minus ihopkopplad och därför betraktas 220 och 330 Ohm som parallellkopplade)

Det finns inget som heter 'gemensam jordledare' om man skall köra data snabbt i en kabel och därmed är tex. RS232 felkonstruerad med gemensam jord - den är inte gjord för att köra snabbt eller över längre sträckor mer än några meter och 115200 bit/s som mest och kanske 25 meter vid 9600 bit/s. - vid längre sträckor så körde man strömloopar om man skulle behålla fungerande hastigheten kvar vid 9600 Bit/s

Så länge man håller sig inom apparathölje så kan SPI och I2C fungera med relativt höga hastigheter och inte alltid så noggrann ledningsdragning (dock att låta en jordledare följa varje signalledare eller alla tillsammans över jordplan är en bra sätt att minska överhöring - skall signaleringen utanför kapselhöljet så måste man börja tänka till med kanske galvanisk isolation - ingen DC-signalering och använd transmissionsledare (tex CAT5-kabel) och förstås passande driver och mottagarkretsar för detta - till detta skall man också ha ett protokoll som hanterar trafiken med samtalsregler när och hur man pratar och när man bara skall lyssna (tex ethernet-protokoll)

Skall signaleringen gå mellan apparater i samma stativ (jordade i samma...) så kan man klara sig med galvanisk koppling mellan enheterna typ RS232/USB/osiolerad RS485 (eller all inkopplad RS485-utrustning är friflytande och dubbelisolerat i alla målenheter) men redan när det skall kopplas till stativet bredvid så bör det vara galvaniskt skilt just för att olika nollor på olika faser från olika säkringsskåp etc. kan ställa till med vagabonderande strömmar som helt kan överrösta datatrafiken i kabeln och också bränna drivstegen när det kommer omkopplingstransienter utifrån - inget man ser i labbänken men ute hos kund gör att man måste byta grejor hela tiden om detta är dåligt designat - kort sagt all signalering och protokoll mellan apparater _bör_ vara baserat att det kan gå över en ferrittransformator (typ Ethernettransformator) utan beroende av DC-signalering (Dc-neutral modulering) - just för att kunna klämma in en isolerande signaltransformator den dagen då man har bekymmer med störande strömmar i kablarna mellan apparater.

att köra med optisk isolerad datalänk i efterhand för att man är beroende av DC-signalering är dyrt (och ger inte så hög prestanda eller bittakt i regel och kräver egen strömförsörjning - och komplicerat om man kör dubbelrikta trafik på enkel par (tex RS485) eller tom. samtidigt åt båda hållen med en hybridkoppling) om man skall göra sådan åtgärd på många ställen och med lite tanke före i signalering, modulation och protokoll så att man klarar att passera tex. en ethernettrafo så har man byggd det framtidssäkert om systemen skulle växa mycket.

[stekern]

I2C är svårt att själv realisera i hårdvara, då det är mycket timing och speciella start/stoppsekvenser inblandade.

Svårt? naah, svårare möjligtvis, men *så* komplicerat är det inte.

[limpan4all]

Ethernet självklart, med rätt processor från början så blir merkostnaden bara runt 30:- per nod och det är i stort sett obegränsat skalbart. Detta är i stort sett lika dyrt som en UART lösning om man vill ha det hela galvaniskt åtskilt. Om det är strikt internt så kör vi direkt på paketnivå mellan egna kort (inga IP nummer endast MAC adresserna), UDP mellan boxar och om vi inte har koll på hur det är byggt TCP/IP. 10/100 för det mesta men Gb kommer... SPI och I2C bara mellan kretsar på samma kort. UART (RS232/RS485) är bara så 1900-tal
Alla USB prylar är bara för volymkonsumentmarknaden.

[ronnylov]

limpan4all: Vilka processorer rekommenderar du om man vill köra Ethernet?
Gissar på att ARM-baserade kan ha bra inbyggt nätverksstöd?

[TomasL]

Även så PIC32 har inbyggd MAC, PHY'n brukar man köra man separat.

[MiaM]

Captain obvious hälsar att givetvis är tillgången på olika typer av färdiga kretsar ofta seller/dealbreaker vid val av protokoll. Det verkar t.ex. dumt att inte välja 1-wire om man ska ha en tempsensor 20 meter från ens mikrokontroller. Åtminstone förr var I2C rätt så förhärskande kring "hemelektronikkretsar", fast jag vet inte riktigt hur det ser ut idag. Då fanns motsvarande kretsar i princip inte över huvud taget med någon annan standardiserad buss, utan antingen I2C eller helt proprietärt.

Vissa varianter är lättare att debugga än andra. Om man använder en uart som kör på en klocka som även en vanlig dator kan köra så är det lätt att avlyssna kommunikationen. Detsamma kan nog också sägas om man som föreslagits kör ethernet.

I2C är rätt enkelt att implementera en busmaster för i ren mjukvara med bit-bangande av i/o-pinnar, men slavarna behöver i princip vara konstruerade i hårdvara. Det gör protokollet rätt lämpligt för att köra några enstaka i/o-kretsar mot valfri mikrokontroller ifall man har tillräckligt med processortid för att styra bussen med mjukvara.

I vissa fall kan ett "hemsnickrat" protokoll vara enklast, t.ex. att skicka ut klocka+data+latch-signal till en radda seriekopplade 74595. Om man vill så kan man generera latch från en monovippa som ger latchning när klocksignalen stängts av en stund. Lämpligt om man vill ha rätt många parallella signaler och inte har så bråttom, och dessutom vill ha lång kabel med få ledare och/eller galvaniskt skiljt.

[limpan4all]

Jag skulle valt http://www.ti.com/product/tm4c1294ncpdt om jag inte redan hade startat med Freescale Kinetics familjen K64.
Främsta orsaken är att att den har tillräckligt FLASH/RAM/SPI/I2C/PWM och resten av "bra att ha" "on-chip" redan från början inklusive integrerat Ethernet PHY och en flyttalscoprocessor.
Drygt 8 till 10 USD i tusenkvantiteter är inte särskilt mycket att bry sig om.
Som reflektion kan nämnas att en Z80 som jobbade i 1M instruktioner/s som absolut mest och helt utan FLASH/RAM eller peripherienheter kostade det dubbla under 80 talet... Och det är alltid lättare och bättre att göra en "Cost Reduktion Redesign" om det behövs än att mitt i ett projekt vara tvungen att byta till en kraftfullare processor, dessutom så går det att räkna på om det är lönsamt att göra det alls.