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

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?

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.

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)

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.

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.

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.

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.

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.

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.

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 :).

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.