Jak magistrala w robocie?

[pawel2604]

Witam wszystkich.

Pracuję na robotem wielozadaniowy ( platforma testowa) na pokładzie którego będzie co najmniej dwa mikrokontrolery. Zastanawiam się teraz jaka będzie najlepsza metoda komunikacji miedzy nim. Oczywiście uwzgledniając możliwości rozbudowy i podłączenia kolejnych mikrokontrolerów.

Co polecacie jako bardziej doświadczeni konstruktorzy?

[MirekCz]

Zależy od prędkości i ilości podłączonych urządzeń.

Dla kilku i dużej ilości danych polecam SPI.

Dla małej ilości danych i jak nie chcesz ciągnąć wielu połączeń to I2C.

W obu wypadkach zasięg jest dosyć mocno ograniczony (nie polecam przekroczyć kilkudziesięciu cm, szczególnie dla I2C).

Zostaje też zwykły rs232 w TTL, ale tutaj musiałbyś trochę więcej pokombinować, bo teoretycznie służy tylko do łączenia dwóch urządzeń.

Podałeś za mało informacji żeby coś stwierdzić bardziej autorytatywnie.

[marek1707]

A może dwudrutowy RS485? Wydaje się, że koszt na starcie jest większy niż np. I2C bo i sam transceiver kosztuje (choć bez przesady) to i protokół trzeba oprogramować ale w sytuacji gdy wiele (i na razie nie wiadomo ile) różnych płytek będzie chciało ze sobą rozmawiać, będą połączone jakimiś kablami, jedne będa sterować silnikami, serwami, kamerami, czujnikami a jeszcze inne być może będą całkiem sporymi komputerami do np. analizy obrazu to 485 może się sprawdzić. Jest odporny na zakłócenia na masie, różnicowy więc i zakłócenia przychodzące "przez powietrze" nie są mu straszne, w miarę szybki, umożliwia połączenie do kilkudziesięciu węzłów i wymaga tylko UARTa - dzisiaj chyba każdy go ma na pokładzie. Jeżeli szybkość do kilkuset kb/s nie jest ograniczeniem to chyba warto rozważyć.

Jest jeszcze LIN, CAN - to z tych "lokalnych" ale dużo bardziej odpornych niż I2C. Tego ostatniego to bym poza jedną PCB nie wypuszczał. Niby są jakieś rozwiązania buforów/repeaterów ale ideą tego interfejsu była jednak komunikacja w ramach jednego, spójnego urządzenia lub PCB.

Ważne, by teraz dokonany wybór od razu rozwiązywał problemy z ew. zakłóceniami, dużymi prądami i spadkami napięcia na masach bo wtedy nie musimy już się przejmować tak bardzo okablowaniem i nie trzeba co chwilę wracać do "badań podstawowych" bo wciąż coś nie działa - to bardzo zniechęca. W rozbudowanym robocie takie rzeczy jak duże prądy i plątanina kabli będą na porządku dziennym

W swoim czasie AVT miało serię klocków na RS485 - można by się na tym troszkę wzorować a nawet coś wykorzystać jeśli przypasuje.

[pawel2604]

Dziekuje za wszystkie podpowiedzie. Na razie w planach sa tylko 3 mikrokontrolery. Pierwszy tylko do monitorowania stanu akumulatora ( 7 ogniw li pol połączonych szeregowo). Drugi do sterowania ramieniem i trzeci jako najwazniejszy, sterujacy robotem.

Najlepiej na etapie projektowania wybrać najlepsza metode komunikacji, żeby wraz z rozwojem nie stwarzała problemów.

[danioto]

Jest jeszcze LIN, CAN - to z tych "lokalnych" ale dużo bardziej odpornych niż I2C. Tego ostatniego to bym poza jedną PCB nie wypuszczał. Niby są jakieś rozwiązania buforów/repeaterów ale ideą tego interfejsu była jednak komunikacja w ramach jednego, spójnego urządzenia lub PCB.

Marku, coś chyba Ci się pomyliło z tym CANem : nie jest to magistrala tylko w ramach jednej płytki PCB.

Odpowiadając, mogę podzielić się moim tokiem myślenia po tym, jak robiłem rozeznanie interfejsów do robota kroczącego. Na pokładzie mam RPi oraz 2x STM jako urządzenia wykonawcze/sterowniki niskopoziomowych elementów systemu (serwa, czujniki).

Na początku myślałem o I2C, z tego względu, że jest bardzo łatwo rozszerzalna - wystarczy się podpiąć do SDA oraz SCL i nic więcej do szczęścia nie trzeba, tylko jak zawsze ma to swoje wady: ma stosunkowo małą szybkość przesyłu (miałem zamiar publikować cały czas pomiary z sensorów, więc magistrala nie wyrabiałaby ze wszystkim) oraz aby przesłać jeden bajt danych potrzeba przesłać dodatkowo jeszcze kilka bajtów (adresy urządzeń, potwierdzenia), więc za darmo powiększamy ruch na magistrali - odpada w moim przypadku.

USART też nie wychodzi w rachubę: wolne toto (w przypadki RPi trzeba byłoby przekompilowywać jądro, by móc korzystać z większej liczby bodów niż 115200), a poza tym trzeba byłoby oprogramowywać całą warstwę łącza danych, co byłoby koszmarem.

Ostatecznie zdecydowałem się na SPI, głównie ze względu na duże prędkości transmisji oraz prostotę obsługi. Póki co jestem zadowolony, tylko muszę ostrzec, że jest to protokół bardzo wrażliwy na zakłócenia wraz ze zwiększaniem prędkości transmisji oraz długości przewodów (przy przewodach 200mm mam problemy z prędkością większą niż 2 Mbody).

Decyzja padła też z jednego względu: w RPi nie ma wbudowanego interfejsu CAN - gdyby był, to nie zastanawiałbym się ani chwili. CAN jest moim zdaniem czystym dobrem interfejsowym, dlatego, że jest szybki, całkowicie odporny na błędy (magistrala różnicowa robi swoje), rozbudowywanie sieci to żaden problem... Można wymieniać długo. Problemem może być tylko troszkę bardziej skomplikowana budowa i oprogramowanie sieci, jednak jeżeli ktoś miał styczność wcześniej z jakimiś interfejsami, to powinien sobie bez problemu poradzić

[marek1707]

W stwierdzeniu

Jest jeszcze LIN, CAN - to z tych "lokalnych" ale dużo bardziej odpornych niż I2C. Tego ostatniego to bym poza jedną PCB nie wypuszczał.

wyrażenie "tego ostatniego" dotyczyło I2C, jako ostatnio wymienionego. Też mi w tym coś piszczało, ale na szybko przeszło weryfikację przez czytanie i poszło. Przepraszam, mam nadzieję, że nie wprowadziłem nikogo w błąd dziwną konstrukcją zdania.

CAN to rzeczywiście strzał w dziesiątkę, ale nie rekomendowałem tego właśnie ze względu na stosunkowo dużą - w porównaniu z UARTem - wiedzę, którą trzeba posiąść zanim zacznie się coś w tej działce robić. Mając CANowy MAC na pokładzie procesora, wystarczy dodać transceiver:

http://ww1.microchip.com/downloads/en/DeviceDoc/21667e.pdf

i interfejs gotowy. Mając SPI można dospawać cały kontroler CAN:

http://ww1.microchip.com/downloads/en/DeviceDoc/21801d.pdf

i też tej magistrali zacząć używać.

Hm, właściwie Ty też tak mogłeś zrobić a być może Twoja Malina byłaby pierwszą podłączoną do CAN. Do dzisiaj miałbyś już wszystko działające i jaki fajny, kolejny artykuł byś o tym napisał (na co po cichu liczę)

Natomiast jeżeli ktoś jest początkujący to ma i tak dużo innych problemów, żeby jeszcze wnikać w zawiłości protokołów komunikacyjnych. UART i RS485 są pojęciowo dużo prostsze a już wystarczająco odporne i niezawodne by sprostać aplikacji opisywanej przez autora wątku. W konfiguracji "jednomasterowej" protokół sprowadza się do wymyślenia postaci ramek oraz obsługi zapytań-odpowiedzi. Z drugiej strony, wysłanie ramki w CAN to zapisanie bajtów danych do odpowiedniego bufora w kontrolerze. No tak, ale jest kilka rodzajów ramek, cała masa parametrów do ustawienia, mnóstwo rodzajów błędów itd.. Trudny wybór

[danioto]

Hmm, to coś źle zrozumiałem z tym CANem i I2C

Gdzieś widziałem gotowy schemat konwertera SPI <-> CAN przystosowany do maliny, więc to raczej nie byłoby pierwsze RPi w sieci CAN. Zdecydowałem się jednak na SPI z tego względu, że musiałbym się martwić o kolejną płytkę do wytworzenia, a i tak pracuję nad projektem już zdecydowanie za długo.

Jeśli chodzi o artykuł, to po cichu planuję jeszcze jedną część, ale to już pewnie w lutym po inżynierce