SPI lub I2C: do użycia w przypadku długiej magistrali


36

Zastanawiam się nad projektem, który wymagałby kilku AVR-ów rozmawiających ze sobą przez autobus. Zostałyby rozdzielone nawet o 6 stóp.

Wygląda na to, że zarówno I2C, jak i SPI mogą pozwolić na komunikację szeregu mikroprocesorów za pośrednictwem magistrali, ale nic nie widziałem o tym, jak długo by to trwało. Czy ktoś próbował połączyć te protokoły na odległości kilku stóp?


Pewnego razu uruchomiłem magistralę I2C za pomocą kabla. Z perspektywy czasu powinienem był użyć CAN lub RS-485 (miał mikrokontrolery na obu końcach).
Nick Alexeev

Odpowiedzi:


19

Jak powiedzieli inni, SPI i I2C można stosować na duże odległości, o ile rezystory podciągające, częstotliwości zegara i tak dalej.

Głównymi alternatywami (które zapewnią lepszą odporność na zakłócenia) są RS485 i CAN . Obie wykorzystują linie różnicowe w celu zminimalizowania problemów z szumem i są lepiej dostosowane do tej długości transmisji danych niż I2C lub SPI. Nie wydaje mi się jednak, aby wiele AVR miało wbudowane urządzenia peryferyjne CAN, które znacznie ułatwiają korzystanie z CAN.

Powiedziałbym, że najważniejszą rzeczą do rozważenia przy wyborze magistrali jest upewnienie się, że protokół używany do komunikacji między urządzeniami zawiera CRC lub równoważny, aby można było ustalić, czy wiadomość została poprawnie odebrana (CAN ma to jako część pakiet). Biorąc to pod uwagę, przydatne jest również posiadanie odpowiedzi typu ACK / NACK jako części protokołu, aby uszkodzona wiadomość mogła zostać ponownie przesłana.


Wygląda na to, że jedno z nich będzie działać. Myślę głównie o tych dwóch konkretnych protokołach, ponieważ większość AVR obsługuje je natywnie, bez dodawania dodatkowych komponentów. W przeciwnym razie dobrym wyborem byłby RS485 lub CAN.
edebill

Jeśli nie jesteś ograniczony do pakietów przelotowych, wówczas ST ma opłacalne i wydajne mikrokontrolery STM32 i STM8 z CAN, NXP ma szereg mikrokontrolerów LPC17xx, a także kilka innych. CAN staje się coraz bardziej popularny (i niedrogi) na wielu mikrokontrolerach.
DrAl

1
Rzeczywiście jest kilka AVR-ów z wbudowanymi odbiornikami CAN, ale podobnie jak inni dostawcy, jest to tylko ograniczona część ich układów.
davr

1
Microchip ma kilka PIC z CAN. microchip.com/wwwproducts/Devices.aspx?dDocName=en010302 . Przyznam jednak, że są nieco „funky” w programowaniu, szczególnie w bibliotekach C18 / C30 Microchip. W przeglądzie kodu zaobserwowaliśmy pewien kod biblioteki, który był bardzo trudny do odczytania ze względu na szczegóły implementacji - bufor transmisji, który jest używany jako bufor odbioru, nazwy flag, które w rzeczywistości są przeciwieństwem tego, co reprezentują. Z pewnością nie jest to coś, co poleciłbym komuś nowemu w rozwoju mikrokontrolerów.
J. Polfer,

2
CAN i RS-485 to naprawdę jabłka i pomarańcze. CAN określa protokół poziomu bitów, a także fizyczną warstwę elektryczną (PHY). RS-485 jest tylko specyfikacją warstwy fizycznej, nie określa nic na temat protokołu. Od ciebie zależy znalezienie lub wdrożenie rzeczywistego protokołu na RS-485 PHY. CAN został zaprojektowany dla środowisk o wysokim poziomie hałasu, najczęściej stosowany w przemyśle motoryzacyjnym i produkcyjnym. Jego protokół jest dość złożonym systemem przekazywania wiadomości i ma bardzo wysoki narzut (niska rzeczywista szybkość transmisji danych), ale ma wysoką integralność danych.
Mark

10

Kilka stóp nie powinno być problematyczne, po prostu użyj skręconych drutów, jeśli możesz. SPI jest o wiele łatwiej buforować (jeśli trzeba) niż I2C, ponieważ wszystkie sygnały SPI są jednokierunkowe, podczas gdy sygnały I2C są na liniach wspólnych.

czy mikrokontrolery AVR mogą obsługiwać tryby podrzędne I2C i SPI, a także tryby master? (potrzebujesz obu)


2
skręcone druty? NIGDY nie skręcaj linii danych i zegara I2C! W przypadku SPI jest to prawdopodobnie mniejszy problem, ale nigdy nie przekręcałbym linii sygnałowych, chyba że jest to para zrównoważona, w którym to przypadku skręcanie jest bardzo dobrym pomysłem.
Wouter van Ooijen,

nigdy nie mów nigdy; Wziąłbym niewielkie sprzężenie pojemnościowe (z powodu skręcenia) między danymi + zegarem każdego dnia zamiast niewielkiego sprzężenia indukcyjnego z głośną elektroniką mocy (z powodu braku skręcenia)
Jason S

4
Przepraszam, zdecydowanie się nie zgadzam. W stanie 1 linie mają raczej wysoką impedancję. Widziałem to zrobione, widziałem, że zawodzi. Najlepszym rozwiązaniem jest posiadanie niskoprądowych linii uziemiających między, a nawet lepiej, po obu stronach linii I2C.
Wouter van Ooijen

10

W przypadku I2C na duże odległości możesz poszukać rozwiązań „repeater magistrali I2C”. Należy pamiętać, że każda maksymalna odległość, jaką można znaleźć w komunikacji I2C lub SPI, odnosi się głównie do całkowitej odległości magistrali, a nie do odległości między dwoma węzłami w magistrali.

Możesz zajrzeć do RS485 pod kątem tego rodzaju problemów. Jest to protokół magistrali szeregowej, który komunikuje się przez linie różnicowe, więc przy stosowaniu skręconych przewodów szanse na hałas są zminimalizowane. W ten sposób można osiągnąć bardzo duże odległości. Minusem byłoby to, że potrzebowałbyś dodatkowego układu kodującego RS485 (jak MAX485, niezbyt drogi) w swoim obwodzie.


RS485 jest zdecydowanie dobrym sposobem na uzyskanie czegoś takiego.
Scott Murphy

pamiętaj, że RS485 ma dwa niezależne od RS232 aspekty: fizyczne poziomy logiki różnicowej i aspekt multimastera. Możesz wybierać + wybierać, użyliśmy translatorów LVDS i RS485 z UART (RS232) do bezpośredniego dostępu do części RS485 z wieloma kropkami.
Jason S

2
btw RS485 to nie protokół! określa tylko warstwę fizyczną. To powiedziawszy, zdecydowanie możesz używać SPI na RS485 !!! W razie potrzeby dobrym rozwiązaniem byłoby utrzymanie komunikacji w trybie SPI (zakładam, że tak, może być podłączony do zdalnego ADC lub podobnego). Używając SPI przez RS485, musisz sprawdzić, czy prędkości narastania transiwera są zgodne z proponowanymi danymi SPI
smashtastic

8

Jedną z zalet, o których jeszcze nie wspominano o SPI w porównaniu z I2C, jest to, że wszystkie przewody SPI są jednokierunkowe i zawsze są napędzane wysoko lub nisko. Pozwala to na znacznie szybszą komunikację niż jest to możliwe w przypadku I2C, zmniejsza podatność na zakłócenia i umożliwia stosowanie prostych bramek jako repeaterów. Inną przydatną opcją jest prosta komunikacja asynchroniczna (jeden przewód w każdym kierunku). Jedynym minusem, jaki widzę w przypadku asynchronizacji komunikacji, jest to, że ogólnie wymaga, aby obie strony były „obudzone”, ze stabilnym zegarem, aby wymieniać dane.

Do własnego projektu wykorzystałem 3-żyłowy, nieznacznie zmodyfikowany protokół SPI i stwierdziłem, że wyniki są zadowalające. Wysyłam wyświetlane bitmapy (gdzie sporadyczne uszkodzenie danych nie byłoby niczym wielkim) przy 10 Mb / s, a inne dane przy 2,5 Mb / s bez trudności.


To bardzo stara odpowiedź, ale czy powiedziałbyś, na jaki dystans wysyłałeś zmodyfikowany protokół SPI? (O to chodzi w pytaniu ...)
Daniel Griscom

@DanielGriscom: Zazwyczaj około 3 stóp, przy niezbyt imponującym okablowaniu, ale czasem dłużej.
supercat

6

Podczas gdy zarówno I2C, jak i SPI są przeznaczone do krótkich dystansów (kilka cali), oba mogą być wykorzystywane na dłuższych dystansach z odpowiednim kablem i dbałością o ogólną pojemność magistrali.

Chociaż mam niewielkie doświadczenie z SPI, I2C nie jest strasznie trudne, biorąc pod uwagę, że zawsze musisz obliczyć odpowiedni rozmiar rezystora podciągającego. Ponadto istnieją dedykowane i niedrogie bufory I2C, które są dość łatwe w użyciu. Jednak nadal będziesz musiał użyć odpowiednio dobranego rezystora podciągającego dla swojej sieci.

Użyłem I2C do połączenia sieci między dwoma AVR-ami w odległości 8 stóp, używając tylko rezystorów podciągających i wysokiej jakości, dobrze ekranowanego, skręconego kabla.


musisz uważać na I / C z kablami wieloprzewodnikowymi, pojemność może spowodować znaczne spowolnienie magistrali.
Jason S,

6

Jak wielu sugerowało, I2C i SPI najlepiej stosować na krótkich dystansach. Chociaż możliwe jest wdrożenie rozwiązania z tymi interfejsami, zdecydowanie polecam poszukać innego, bardziej „standardowego” rozwiązania (np. Ethernet, RS485, CAN itp.). - Zwłaszcza jeśli planujesz używać kabli, aby osiągnąć odległość 6 stóp między mikrokontrolerami.


6

Interfejs między bezprzewodowym pilotem Nintendo Wii a towarzyszącym mu Nunchuckiem jest po prostu FYI, wykorzystuje I2C przez kabel o długości około 3 stóp. Istnieją również przedłużacze o długości 3 stóp, które przedłużają całkowitą długość do około 6 stóp. Nie do końca taki sam, jak konfiguracja (tylko dwa urządzenia połączone razem), ale jest to przykład I2C na kablu w powszechnie używanym produkcie konsumenckim.


4

Pracowałem nad projektem obejmującym około 80 węzłów opartych na AVR w sieci gwiazd komunikującej się przez I2C. To był totalny bałagan i ostatecznie nie działał. Pobieranie aktualizacji do wszystkich węzłów zajęło kilka sekund, a jedno wadliwe połączenie zrzuciłoby całą sieć. Ostatnio rozmawiałem z facetem, który stworzył węzły, powiedział, że przestał używać I2C do takich projektów. Niestety nie wiem, dlaczego konkretnie I2C był tutaj nieodpowiedni.


1
I2C jest znacznie wolniejszy niż SPI ... mogło być także w przypadku arbitrażu zarządzanego przez projekt w przypadku kolizji ... lub pojemność mogła być wystarczająco wysoka w przypadku wszystkich tych węzłów, które musiały po prostu korzystać z niskiej częstotliwości taktowania.
Jason S

2

Z tak małymi odległościami powinno być łatwo. Co możesz zrobić, to dowiedzieć się, co oznaczają te odległości i twoje okablowanie pod względem pojemności i impedancji linii, i zobaczyć, jakie częstotliwości (czasy narastania / opadania) możesz przez nie przejść. Poza pewnym punktem najlepiej traktować je jak linie przesyłowe. Jeśli źle wygląda, możesz rzeczywiście przełączyć się na inną linię szeregową, taką jak EIA-232 lub 422. Może to oznaczać dodatkowy układ na obu końcach, ale będzie się rozciągał daleko. Jeśli naprawdę chcesz iść szybko i daleko, potrzebujesz czegoś więcej (sieć Ethernet, nie licz na radio ani laser :).


2

Jeśli potrafisz kontrolować prędkość zegara i nie potrzebujesz szybkiego transferu danych, powinieneś spróbować spowolnić zegar. Dzięki temu będzie mniej podatny na hałas.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.