Vraag:
SPI of I2C: te gebruiken voor een vrij lange bus
edebill
2009-12-27 22:46:47 UTC
view on stackexchange narkive permalink

Ik overweeg een project waarbij meerdere AVR's via een bus met elkaar moeten praten. Ze zouden wel 1,8 meter van elkaar verwijderd zijn.

Het lijkt erop dat zowel I2C als SPI een reeks micros kunnen laten communiceren via een bus, maar ik heb niets gezien over hoe lang dat zou duren. worden. Heeft iemand geprobeerd deze protocollen te verbinden over afstanden van enkele meters?

[Ik heb een keer een I2C-bus via een kabel laten lopen.] (Http://reconvolution.blogspot.com/2014/11/memoirs-of-overgrown-i2c-bus.html) Achteraf gezien had ik CAN ofRS-485 in plaats daarvan (had microcontrollers aan beide uiteinden).
Tien antwoorden:
#1
+19
DrAl
2009-12-28 18:23:05 UTC
view on stackexchange narkive permalink

Zoals anderen al hebben gezegd, kunnen SPI en I2C over lange afstanden worden gebruikt, zolang de pull-up-weerstanden, klokfrequenties, enzovoort.

De belangrijkste alternatieven (die zorgen voor een betere immuniteit tegen ruis) zijn RS485 en CAN. Beide gebruiken differentiële lijnen om ruisproblemen te minimaliseren en zijn beter geschikt voor deze lengte van gegevensoverdracht dan I2C of SPI. Ik denk echter niet dat veel (enige?) AVR's worden geleverd met ingebouwde CAN-randapparatuur, waardoor CAN-gebruik veel gemakkelijker wordt.

Ik zou zeggen dat het belangrijkste om rekening mee te houden bij het kiezen van een bus is om ervoor te zorgen dat het protocol dat u gebruikt voor communicatie tussen apparaten een CRC of equivalent bevat, zodat u kunt bepalen of een bericht correct is ontvangen (CAN heeft dit als onderdeel van het pakket). Met het oog hierop is het ook handig om een ​​ACK / NACK-type antwoord te hebben als onderdeel van het protocol, zodat een beschadigd bericht opnieuw kan worden verzonden.

Het klinkt alsof beide zullen werken. Ik denk voornamelijk aan deze twee specifieke protocollen omdat de meeste AVR's ze native ondersteunen, zonder extra componenten toe te voegen. Anders zou RS485 of CAN een goede keuze zijn.
Als u niet beperkt bent tot doorlopende pakketten, dan heeft ST hun kosteneffectieve en krachtige STM32- en STM8-microcontrollers met CAN, heeft NXP een reeks LPC17xx-microcontrollers en er zijn er ook nog een paar. CAN komt steeds vaker (en betaalbaar) voor op veel microcontrollers.
Er zijn inderdaad enkele AVR's met ingebouwde CAN-ontvangers, maar net als de andere leveranciers zit het alleen in een beperkte subset van hun chips.
Microchip heeft een paar PIC's met CAN. http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010302. Ik moet toegeven dat ze een beetje "funky" zijn om te programmeren, vooral in Microchip's C18 / C30-bibliotheken. In de codebeoordeling hebben we een bibliotheekcode gezien die erg moeilijk te lezen was vanwege de details van de implementatie - een verzendbuffer die wordt gebruikt als een ontvangstbuffer, vlagnamen die eigenlijk het tegenovergestelde zijn van wat ze vertegenwoordigen. Zeker niet iets dat ik zou aanraden voor iemand die nieuw is in de ontwikkeling van microcontrollers.
CAN en RS-485 zijn echt appels en sinaasappels. CAN definieert zowel het bitniveau-protocol als de fysieke elektrische laag (PHY). RS-485 is slechts een specificatie van de fysieke laag, het specificeert niets over het protocol. Het is geheel aan jou om een ​​echt protocol te vinden of te implementeren bovenop de RS-485 PHY. CAN is ontworpen voor omgevingen met veel lawaai en wordt voornamelijk gebruikt in de auto- en productie-industrie. Het protocol is een vrij complex systeem voor het doorgeven van berichten en heeft een zeer hoge overhead (lage feitelijke gegevenssnelheid) maar heeft een hoge gegevensintegriteit.
I2C kan niet over willekeurige lengtes worden gebruikt, zoals uw eerste regel suggereert. De maximale lengte is een functie van lijncapaciteit, minimale pull-up waarde en minimale slew rate.
#2
+10
Jason S
2009-12-27 23:26:03 UTC
view on stackexchange narkive permalink

Meerdere voeten zouden geen probleem moeten zijn, gebruik gewoon gedraaide draden als je kunt. SPI is veel gemakkelijker te bufferen (als dat nodig is) dan I2C, aangezien SPI-signalen allemaal unidirectioneel zijn, terwijl de signalen van I2C zich op gedeelde lijnen bevinden.

Kunnen de AVR-microcontrollers zowel I2C- en SPI-slaafmodi als master modi? (je hebt beide nodig)

gedraaide draden ?? Verdraai NOOIT de I2C data en kloklijnen! Met SPI is dit waarschijnlijk minder een probleem, maar ik zou de signaallijnen nooit verdraaien tenzij het een gebalanceerd paar is, in welk geval draaien een heel goed idee is.
zeg nooit nooit; Ik zou een kleine capacitieve koppeling nemen (vanwege draaien) tussen data + klok elke dag in plaats van een kleine inductieve koppeling naar lawaaierige vermogenselektronica (vanwege niet draaien)
Sorry, ik ben het er absoluut niet mee eens. In de 1-stand hebben de lijnen een vrij hoge impedantie. Gezien het gedaan, gezien het falen. De beste optie is om aardleidingen met lage stroomsterkte tussen of zelfs beter aan beide zijden van de I2C-lijnen te hebben.
#3
+10
bpijls
2009-12-28 05:47:21 UTC
view on stackexchange narkive permalink

Voor I2C over lange afstanden wil je misschien wat "I2C bus repeater" oplossingen zoeken. Houd er rekening mee dat elke maximale afstand die u voor I2C- of SPI-communicatie vindt, meestal verwijst naar de totale busafstand en niet naar de afstand tussen twee knooppunten in een bus.

Misschien wilt u RS485 bekijken voor dit soort problemen. Het is een serieel busprotocol dat communiceert via differentiële lijnen, dus bij gebruik van gedraaide draden wordt de kans op ruis geminimaliseerd. Op deze manier kunnen zeer lange afstanden worden bereikt. Het nadeel zou zijn dat je een extra RS485-encoder-IC (zoals een MAX485, niet erg duur) in je circuit nodig hebt.

RS485 is absoluut een goede manier om voor zoiets te gaan.
Houd er rekening mee dat RS485 twee aspecten heeft die verschillen van RS232 die enigszins onafhankelijk zijn: de fysieke differentiële logische niveaus en het multimaster-aspect. U kunt deze kiezen + kiezen, we hebben zowel LVDS- als RS485-vertalers met UART (RS232) gebruikt voor point-to-point zonder in de multidrop-delen van RS485 te komen.
btw RS485 is geen protocol! het definieert alleen de fysieke laag. Dat gezegd hebbende, je kunt SPI zeker gebruiken via RS485 !!! Het zou een nette oplossing zijn om de communicatie indien nodig in SPI-modus te houden (ik neem aan dat dit zo is, mogelijk is verbonden met een externe ADC of iets dergelijks). Als u SPI over RS485 gebruikt, moet u controleren of de zwenksnelheden van de transceiver compatibel zijn met de voorgestelde SPI-datarates
#4
+8
supercat
2011-02-25 23:15:42 UTC
view on stackexchange narkive permalink

Een nog niet genoemd voordeel van SPI ten opzichte van I2C is dat alle SPI-draden unidirectioneel zijn en altijd hoog of laag worden aangestuurd. Dit maakt veel snellere communicatie mogelijk dan mogelijk is met I2C, vermindert de gevoeligheid voor ruis en maakt het mogelijk dat eenvoudige poorten als repeaters worden gebruikt. Een andere handige optie is eenvoudige asynchrone communicatie (één draad in elke richting). Het enige nadeel dat ik aan async-communicatie kan zien, is dat het over het algemeen vereist dat beide partijen "wakker" zijn, met een stabiele klok, om gegevens uit te wisselen.

Voor een eigen project gebruikte ik een 3- wire licht gewijzigd SPI-protocol en hebben de resultaten bevredigend gevonden. Ik stuur bitmap-gegevens (waar incidentele gegevenscorruptie geen probleem zou zijn) zonder problemen met 10 Mbps en andere gegevens met 2,5 Mbps zonder problemen.

Dit is een heel oud antwoord, maar zou u zeggen over welke afstand u uw aangepaste SPI-protocol verstuurde?(Dat is het punt van de vraag ...)
@DanielGriscom: Ongeveer 1 meter typisch, over niet erg indrukwekkende bekabeling, maar soms langer.
#5
+7
tcrosley
2010-07-02 05:36:02 UTC
view on stackexchange narkive permalink

Even ter informatie, de interface tussen de draadloze Nintendo Wii-afstandsbediening en zijn Nunchuck-metgezel gebruikt I2C via een kabel die ongeveer 90 cm lang is. Er zijn ook verlengkabels van 1 meter lang die de totale lengte tot ongeveer 1,8 meter verlengen. Niet precies hetzelfde als uw opstelling (slechts twee apparaten met elkaar verbonden), maar het is een voorbeeld van I2C via een kabel in een veelgebruikt consumentenproduct.

#6
+6
shutterdrone
2009-12-28 03:06:53 UTC
view on stackexchange narkive permalink

Hoewel zowel I2C als SPI zijn ontworpen voor korte afstanden (enkele centimeters), kunnen beide worden gebruikt op langere afstanden met de juiste kabel en aandacht voor de algehele buscapaciteit.

Hoewel ik weinig ervaring heb met SPI is I2C niet erg moeilijk, aangezien je altijd de juiste maat voor je pull-up-weerstand moet berekenen. Bovendien zijn er speciale en goedkope I2C-buffers die vrij eenvoudig te gebruiken zijn. Je zult echter nog steeds een pull-up-weerstand van de juiste grootte voor je netwerk moeten gebruiken.

Ik heb I2C gebruikt om te netwerken tussen twee AVR's op een afstand van 2,4 meter, met alleen pull-up-weerstanden en hoogwaardige, goed afgeschermde, getwiste kabel.

je moet oppassen met I2C met meeraderige kabels, de capaciteit kan ervoor zorgen dat de bus aanzienlijk vertraagt.
#7
+6
Nate
2010-07-02 04:29:21 UTC
view on stackexchange narkive permalink

Zoals velen hebben gesuggereerd, kunnen I2C en SPI het beste worden gebruikt voor korte afstanden. Hoewel het misschien mogelijk is om een ​​oplossing te implementeren met deze interfaces, zou ik u ten zeerste aanbevelen om op zoek te gaan naar een andere, "meer standaard" oplossing (bijv. Ethernet, RS485, CAN, enz.). - Vooral als u van plan bent kabels te gebruiken om de 1,8 m afstand tussen microcontrollers te bereiken.

#8
+4
terrace
2009-12-29 06:14:30 UTC
view on stackexchange narkive permalink

Ik werkte aan een project met ongeveer 80 AVR-gebaseerde knooppunten in een sternetwerk dat communiceerde via I2C. Het was een totale puinhoop en werkte uiteindelijk niet. Updates krijgen voor alle knooppunten duurde seconden en één defecte verbinding zou het hele netwerk verstoren. Als laatste sprak ik met de man die de knooppunten heeft gemaakt, hij zei dat hij gestopt is met het gebruik van I2C voor projecten als deze. Helaas weet ik niet waarom specifiek I2C hier onvoldoende was.

I2C is veel langzamer dan SPI ... het had ook kunnen zitten in de manier waarop je project arbitrage beheerde in geval van botsingen ... of de capaciteit was misschien hoog genoeg met al die knooppunten die je gewoon een lage kloksnelheid moest gebruiken.
#9
+2
tissit
2010-05-18 13:40:54 UTC
view on stackexchange narkive permalink

Het zou gemakkelijk moeten zijn met die korte afstanden. Wat je zou kunnen doen, is uitzoeken wat die afstanden en je bekabeling betekenen in termen van capaciteit en lijnimpedantie en kijken wat voor soort frequenties (stijg- / daaltijden) je er doorheen kunt halen. Voorbij een bepaald punt is het het beste om ze als transmissielijnen te behandelen. Als het er slecht uitziet, zou je inderdaad kunnen overschakelen naar een andere seriële lijn zoals EIA-232 of 422. Dat zou een extra chip aan beide uiteinden kunnen betekenen, maar het zal ver gaan. Als je echt snel en ver moet gaan, heb je iets meer nodig (ethernet, tel radio of laser niet mee :).

#10
+2
ajs410
2010-05-18 23:09:26 UTC
view on stackexchange narkive permalink

Als u de kloksnelheid kunt regelen en u geen gegevensoverdracht met hoge snelheid nodig heeft, moet u proberen de klok te vertragen. Dit maakt het minder gevoelig voor ruis.



Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 2.0-licentie waaronder het wordt gedistribueerd.
Loading...