Komunikacja między wieloma mikrokontrolerami

20

Chciałbym zacząć wdrażać system składający się z N mikrokontrolerów (N> = 2 MCU), ale chciałbym wiedzieć, jakie są możliwości komunikacji między nimi.

Idealnie, mikrokontrolery (N-1) są umieszczone w domu, działając jako klienci, podczas gdy ostatni („serwer”) jest podłączony do komputera PC przez USB. Problem, który mam teraz, to sposób połączenia tych mikrokontrolerów (N-1) z „serwerem”. MCU klientów wykonują bardzo proste zadania, więc może nie być dobrym rozwiązaniem użycie ARM do wykonywania tak prostych zadań tylko dlatego, że zapewniają CAN / PHY-MAC .

Komunikacja nie będzie się powtarzać częściej niż raz na kilka minut dla większości urządzeń i na żądanie dla innych. Szybkość nie jest bardzo krytyczna (wiadomość jest krótka): 1 Mbit / s Myślę, że jest to MOŻLIWA przesada w moich celach.

MCU, których zamierzam używać, są następujące.

  • Atmel AVR Tiny / Mega
  • TI MSP430
  • ARM Cortex M3 / M4
  • (Prawdopodobnie Atmel AVR UC3 - 32-bit)

Chciałbym unikać PIC, jeśli to możliwe (osobisty wybór), po prostu dlatego, że są mniejsze możliwości ich programowania (wszystkie powyższe mają mniej lub więcej narzędzi open source, a także niektórych oficjalnych narzędzi).

Wiem, że niektóre ARM zapewniają funkcjonalność CAN i nie jestem pewien co do innych.

W tej chwili wymyśliłem te możliwości:

  1. Proste GPIO do wysyłania danych (powiedzmy> 16 bitów przy WYSOKIM, aby wskazać początek wiadomości,> 16 bitów przy NISKIM, aby wskazać koniec wiadomości). Jednak musi być na standardowej częstotliwości << (częstotliwość_klient, częstotliwość_serwer), aby móc wykryć wszystkie bity. Potrzebuję tylko jednego kabla na MCU klienta.
  2. RS-232 : Myślę, że jest to zdecydowanie najczęściej używany protokół komunikacyjny, ale nie wiem, jak dobrze się skaluje. Rozważam obecnie do 64 MCU klienta (prawdopodobnie później)
  3. USB: AFAIK jest to w większości jak RS-232, ale nie sądzę, aby skalowało się w tym przypadku bardzo dobrze (chociaż USB obsługuje wiele urządzeń - 255, jeśli dobrze pamiętam - może być zbyt skomplikowane dla tej aplikacji)
  4. RJ45 / Ethernet: właśnie tego chciałbym używać, ponieważ pozwala na przesyłanie bez problemu na duże odległości (przynajmniej z ekranowanym kablem > Cat 6 ). Problemem jest koszt (PHY, MAC, transformator, ...). Nie wiem jednak, czy da się to dobrze lutować w domu. W ten sposób nie potrzebowałbym MCU klienta
  5. Wireless / ZigBee : moduły są bardzo drogie, choć może to być dobry sposób, aby uniknąć „spaghetti” za biurkiem
  6. Moduły RF / nadajniki-odbiorniki: Mówię o tych w paśmie 300 MHz - 1 GHz, więc powinny być trudne do lutowania w domu. Wszystkie moduły są wbudowane, ale są tak samo drogie jak ZigBee (przynajmniej moduły RF w Mouser, w Sparkfun wydają się być tańsze).
  7. MOGĄ? Wydaje się być bardzo solidny. Mimo że nie planuję używać go w aplikacjach motoryzacyjnych, może być dobrą alternatywą.
  8. I²C / SPI / UART ? Znowu - lepiej unikać „spaghetti” z kablami, jeśli to możliwe
  9. Sterowniki PLC nie są tak naprawdę opcją. Wydajność spada dość szybko wraz ze wzrostem długości i zależy od obciążenia pojemnościowego sieci energetycznej. Myślę, że pod względem ceny jest mniej więcej taki sam jak Ethernet.

Ponadto, który protokół byłby „lepszy” w przypadku jednoczesnych transmisji (załóżmy rzadki przypadek, że w tym samym momencie dwa urządzenia zaczynają transmitować: który protokół zapewnia najlepszy „system zarządzania konfliktami” / „system zarządzania kolizjami”?

Podsumowując : chciałbym usłyszeć, jakie może być najlepsze rozwiązanie dla rozproszonego systemu klienta, który zapewnia bardzo lekką komunikację danych, biorąc pod uwagę zarówno elastyczność (maksymalna liczba urządzeń, system zarządzania konfliktami / kolizjami, ...), cenę , łatwe do zrobienia w domu (lutowanie), ... Chciałbym uniknąć wydawania 20 $ na sam moduł komunikacyjny, ale jednocześnie posiadanie 30 przewodów za biurkiem byłoby do bani.

Rozwiązaniem, które teraz obrazuję, byłoby wykonanie podstawowej komunikacji między bliskimi MCU przez GPIO lub RS-232 ( tanio !) I użycie Ethernet / ZigBee / Wi-Fi na jednym MCU na „strefę” do komunikacji z serwerem ( drogie , ale wciąż jest znacznie tańszy niż jeden moduł Ethernet na każdy MCU klienta).

Zamiast kabli można równie dobrze zastosować włókna światłowodowe / światłowodowe. Chociaż konieczne są dodatkowe konwersje i nie jestem pewien, czy byłoby to najlepsze rozwiązanie w tym przypadku. Chciałbym usłyszeć o nich dodatkowe szczegóły.

użytkownik51166
źródło
2
Istnieją PIC z funkcją CAN i istnieją bezpłatne oficjalne narzędzia do programowania ich z dokumentacją.
AndrejaKo
@AndrejaKo PIC tak naprawdę nie ma kompilatora typu open source, takiego jak AVR lub przynajmniej MSP430. Prawdą jest, że często oferują one więcej funkcji niż MCU wymienione powyżej w tej samej cenie. Naprawdę nie lubię tych dużych różnic między rodzinami 12/16/18/24/32 i że niektóre z nich w ogóle nie mają darmowego kompilatora (myślę, że to PIC18).
user51166
2
W rzeczywistości PIC18 ma darmowy kompilator, podobnie jak inne. Główną zaletą innych rodzin jest to, że współpracują z GCC. W obozie open source znajduje się kompilator Small device C, który powinien obsługiwać urządzenia PIC 16 i PIC 18.
AndrejaKo
2
Jeśli nie masz jeszcze doświadczenia z żadnym z wymienionych wyżej sterowników, ostrzegaj, że ARM jest znacznie trudniejszy do rozpoczęcia niż np. PIC lub AVR, szczególnie jeśli chcesz przejść na open source. Dzięki ARM dostawcy nie projektują rdzenia, a także ogólnie nie zapewniają IDE, co może sprawić, że całość stanie się nieco bardziej złożona. Miło jest mieć np. Microchip zapewniający i obsługujący wszystko w przypadku PIC.
Oli Glaser,
@OliGlaser Cóż ... chociaż prawdą jest, że narzędzia open source dla ARM mogą być nieco trudne w użyciu (próbowałem płyty STM32 Discovery i nie działało to zbyt dobrze), wielu dostawców oferuje IDE, które jest - z zalety i wady - na przykład zaćmienie środowiska i bezpłatne: LPCXpresso (NXP) i Code Composer Studio (TI) (na przykład nie open-source, ale przynajmniej obsługiwane). Z drugiej strony AVR są dość dobrze obsługiwane po stronie open source, a także w ATMEL STUDIO 6. Brak doświadczenia z PIC. Kodowane tylko AVR (asembler) i ARM (C, na NDS).
user51166

Odpowiedzi:

22

CAN brzmi najlepiej w tym przypadku. Odległości w domu mogą być obsługiwane przez CAN przy 500 kbitach / s, co brzmi jak duża przepustowość dla twoich potrzeb. Ostatni węzeł może być gotowym interfejsem USB do CAN. Dzięki temu oprogramowanie komputera może wysyłać wiadomości CAN i wyświetlać wszystkie komunikaty w magistrali. Reszta to oprogramowanie, jeśli chcesz przedstawić to światu zewnętrznemu jako serwer TCP lub coś takiego.

CAN to jedyny sposób komunikacji, o którym wspomniałeś, że tak naprawdę jest to autobus, z wyjątkiem zwijania własnego za pomocą linii we / wy. Wszystkie pozostałe są punkt-punkt, w tym Ethernet. Ethernet może wyglądać logicznie jak magistrala z przełącznikami, ale poszczególne połączenia są nadal punkt do punktu, a uzyskanie logicznej topologii magistrali będzie kosztowne. Narzut oprogramowania wewnętrznego na każdym procesorze jest również znacznie większy niż CAN.

Zaletą CAN jest to, że kilka najniższych warstw protokołu jest obsługiwanych przez sprzęt. Na przykład wiele węzłów może próbować transmitować w tym samym czasie, ale sprzęt zajmuje się wykrywaniem kolizji i radzeniem sobie z nimi. Sprzęt zajmuje się wysyłaniem i odbieraniem całych pakietów, w tym generowaniem i sprawdzaniem sumy kontrolnej CRC.

Twoje powody unikania PIC nie mają żadnego sensu. Istnieje wiele projektów dla programistów do budowania własnych. Jednym z nich jest mój LProg , ze schematem dostępnym na dole tej strony. Jednak zbudowanie własnego nie będzie opłacalne, chyba że cenisz swój czas w pensach / godzinę. To także coś więcej niż tylko programista. Potrzebujesz czegoś, co pomoże w debugowaniu. Microchip PicKit 2 lub 3 to bardzo tanie programiści i debuggery. Chociaż nie mam z nimi osobistego doświadczenia, słyszę o innych, którzy używają ich rutynowo.

Dodany:

Widzę kilka rekomendacji dla RS-485, ale to nie jest dobry pomysł w porównaniu z CAN. RS-485 jest standardem wyłącznie elektrycznym. Jest to szyna różnicowa, więc pozwala na wiele węzłów i ma dobrą odporność na zakłócenia. Jednak CAN ma to wszystko i wiele więcej. CAN jest zwykle implementowany jako magistrala różnicowa. Niektórzy twierdzą, że interfejs RS-485 można łatwo podłączyć elektrycznie. To prawda, ale i CAN. Tak czy inaczej, robi to pojedynczy układ. W przypadku CAN dobrym przykładem jest MCP2551.

CAN i RS-485 mają więc te same zalety elektryczne. Dużą zaletą CAN jest ponad tę warstwę. W RS-485 nie ma nic powyżej tej warstwy. Jesteś na swoim. Możliwe jest zaprojektowanie protokołu, który zajmie się arbitrażem magistrali, weryfikacją pakietów, limitami czasu, ponownymi próbami itp., Ale uzyskanie tego poprawnie jest o wiele trudniejsze niż większość ludzi zdaje sobie sprawę.

Protokół CAN definiuje pakiety, sumy kontrolne, obsługę kolizji, próby itp. Nie tylko już tam jest, jest przemyślany i przetestowany, ale naprawdę dużą zaletą jest to, że jest on implementowany bezpośrednio w krzemie na wielu mikrokontrolerach. Oprogramowanie układowe łączy się z urządzeniami peryferyjnymi CAN na poziomie wysyłania i odbierania pakietów. W celu wysłania sprzęt wykonuje wykrywanie kolizji, wycofywanie, ponawianie i generowanie sumy kontrolnej CRC. W celu odebrania wykonuje wykrywanie pakietów, dostosowywanie przesunięcia zegara i sprawdzanie sumy kontrolnej CRC. Tak, urządzenie peryferyjne CAN zajmie więcej napędu niż UART, taki jak jest często używany z RS-485, ale ogólnie zajmuje dużo mniej kodu, ponieważ krzem obsługuje tak wiele szczegółów protokołu niskiego poziomu.

Krótko mówiąc, RS-485 pochodzi z minionej epoki i obecnie nie ma większego sensu w przypadku nowych systemów. Głównym problemem wydają się być ludzie, którzy używali RS-485 w przeszłości, przywiązując się do niego i myśląc, że CAN jest w jakiś sposób „skomplikowane”. Niski poziom CAN jest skomplikowany, ale podobnie jak każda kompetentna implementacja RS-485. Zauważ, że kilka dobrze znanych protokołów opartych na RS-485 zostało zastąpionych nowszymi wersjami opartymi na CAN. NMEA2000 jest jednym z przykładów takiego nowszego standardu opartego na CAN. Istnieje inny standard motoryzacyjny J-J1708 (oparty na RS-485), który jest już prawie przestarzały w przypadku OBD-II i J-1939 opartych na CAN.

Olin Lathrop
źródło
zbudowanie własnej niestandardowej płyty jest przydatne podczas integracji MCU ze sprzętem, który ma wokół niej. Dla celów programistycznych zgadzam się, że zestaw programistyczny jest lepszym sposobem. Moim powodem unikania PIC jest ich brak kompilatorów open source (niektóre są bezpłatne, ale nie na przykład dla PIC18), a nie brak dostępnych publicznie schematów, chociaż zapewniają one dodatkowe funkcje, których możesz nie znaleźć w innych MCU (Ethernet, MOGĄ, ...). A I2C to autobus AFAIK.
user51166
@ user51166 - Istnieją bezpłatne kompilatory PIC18 dostarczane przez microchip. Zobacz stronę produktu Kompilatory MPLAB XC . Zawiera także listę kompilatorów dla 16-bitowego i 32-bitowego interfejsu użytkownika.
PetPaulsen
@ user51166 Jest też bezpłatny kompilator C18 .
AndrejaKo
@PetPaulsen Strange. Jestem prawie pewien, że miesiąc temu widziałem stronę z listą wszystkich kompilatorów dostępnych bezpłatnie do pobrania (PIC16 / 24/32), z wyjątkiem PIC18, który nie był spowodowany jakimś problemem licencyjnym. Prawdopodobnie zostało to rozwiązane dzięki kompilatorowi przejścia MPLAB C -> Kompilator MPLAB XC, chociaż nie jestem pewien. Ponadto „tylko” oferują bezpłatną edycję, która nie optymalizuje kodu, a nie w pełni kompilator open source. Nadal jest to lepsze niż nic;)
user51166
@ użytkownik: Wierzę, że wszystkie kompilatory Microchip mają darmowe wersje, które różnią się od pełnych tylko tym, że niektóre optymalizacje są wyłączone. Asembler, bibliotekarz, linker i symulator są zawarte w darmowym pakiecie MPLAB. Naprawdę nie ma tutaj problemu.
Olin Lathrop
6

Polecam kontroler z CAN, ponieważ ta funkcja jest przeznaczona właśnie do celów sieciowych kontrolera.

RS232 może być łatwo zaimplementowany, ale stanie się prawdziwym wyzwaniem, jeśli spróbujesz zaimplementować komunikację więcej niż 2 węzły (ponieważ nie jest budowany do tego celu).

Ethernet może być również dobrą opcją, ponieważ wspomniałeś o niektórych połączeniach hosta i klienta, co jest naturalne dla implementacji Ethernetu.

JeeShen Lee
źródło
Jakie są na przykład zalety CAN nad Ethernetem? Prawdopodobnie tańsze, ale poza tym, co jeszcze?
user51166
@ user51166 - CAN jest nie tylko tańszy, ale znacznie tańszy. To jest nie tylko łatwiejsze, ale znacznie łatwiejsze.
Rocketmagnet
@Rocketmagnet: proszę wyjaśnić trochę więcej. W większości przypadków i tak potrzebujesz zintegrowanego układu scalonego (chociaż PIC i ARM i inne? Często integrują funkcję CAN, są nieco drogie). Z punktu widzenia sprzętowego nie rozumiem, jak może być to o wiele tańsze, ponieważ układy scalone można znaleźć za 0,5-1,0 $ za sztukę. Podejrzewam, że masz na myśli łatwiej z punktu widzenia oprogramowania, prawda? CAN ma maksymalną odległość ~ 500 metrów, co z pewnością jest wystarczające w moim przypadku, ale - tylko dla informacji - czy byłyby podobne alternatywy dla większych odległości (może światłowód)?
user51166,
4

RS-485 przy użyciu wielu przewodów może tu dobrze działać, jeśli istnieje możliwość podłączenia tej samej linii do wszystkich urządzeń.

Jeśli na przykład jest używany z tradycyjnym kablem sieciowym kategorii 5e, możesz mieć dwie pary do transmisji danych w obu kierunkach (przy użyciu modułu pełnego dupleksu), mieć jedną parę lub może nawet pojedynczy przewód jako wspólną masę, a resztę do negocjacji które urządzenie będzie transmitować w którym momencie. To trochę bardziej skomplikowane niż RS-232, ale moduły są tańsze niż CAN i Ethernet, a limit kabla wynosi 1200 m. Minusem jest to, że będziesz musiał stworzyć własny protokół rozwiązywania konfliktów. Może masz urządzenie, które chce transmitować, sprawdź jeden dedykowany przewód i sprawdź, czy jest wysoki. Jeśli nie, podnieś go i zacznij komunikować się, a jeśli tak, poczekaj na losowy okres czasu. Nadal nie jestem pewien, jak dobrze by to działało na duże odległości.

AndrejaKo
źródło
Nie martw się o zbyt duże odległości, nie planuję w tej chwili przekraczać 100 m.
user51166
Dlaczego BTW dzisiaj stackexchange nie akceptuje @ <nazwa użytkownika>? Za każdym razem, gdy jeden
wstawię
@ user51166 - Twórca odpowiedzi jest automatycznie powiadamiany, więc „\ @ - hałas” jest automatycznie usuwany. (Mój \ @ użytkownik51166 nie został usunięty, ponieważ nie jesteś twórcą tej odpowiedzi)
PetPaulsen
Interesujące jest to, że nie otrzymałem powiadomień o żadnym z komentarzy tutaj.
AndrejaKo
4

Wybrałbym magistralę RS-485 pracującą z danymi kodowania Manchester .

RS-485, ponieważ:

  • Jest tanie
  • Jest łatwy do wdrożenia
  • Czy używa lo mocy
  • Pozwala na duże odległości (do 1200 metrów)
  • Wysokie prędkości transmisji danych (do 10 Mb / s)
  • Wysoka odporność na zakłócenia
  • Istnieją nadajniki-odbiorniki, które umożliwiają do 256 urządzeń na tej samej magistrali
  • Niska liczba części

Kodowanie Manchester, ponieważ:

  • Jest łatwy do wdrożenia
  • Jest samosynchronizujący

W celu zapewnienia integralności danych komunikat może zawierać długość i pole CRC.

Przykład funkcji CRC:

unsigned char crc_calc(unsigned char buffer[], unsigned short size)
{
  unsigned long i;
  unsigned char crc;

  crc = CRC_INIT;

  for (i=0;i<size * 8;i++)
  {
    crc = (crc << 1) | (crc >> (7));

    if (buffer[i/8] & (0x80 >> (i%8)))
    {
      crc ^= CRC_POLY;
    }
  }

  return crc;
}

CRC_INITi CRC_POLYsą arbitralnymi wartościami używanymi do obliczania CRC.

Przykład wiadomości z polami długości i CRC:

Przykład wiadomości

Bruno Ferreira
źródło
Wszelkie sugestie dotyczące tak dobrych nadajników-odbiorników, być może tanich?
user51166
Ponadto, jak sugeruje @AndrejaKo, RS-485 nie wydaje się oferować protokołu rozwiązywania konfliktów.
user51166
Wybór nadajników-odbiorników zależy od napięcia, które zamierzasz zastosować. Rozwiązanie konfliktu musi być wykonane w oprogramowaniu z kontrolą CRC, monitorowaniem linii lub jednym i drugim.
Bruno Ferreira,
Jeśli masz jednego mistrza, możesz również zastosować jakieś adresowanie lub transmisję zwrotną.
Bruno Ferreira,
Niezupełnie mistrz. Po prostu „serwer”, który działa jak interfejs do komputera przez USB. Klienci muszą jednak wysyłać mu wiadomości automatycznie ...
user51166
3

Pozwól mi porównać twój preferowany wybór, Ethernet, z moim preferowanym wyborem, CAN.

Wymagane komponenty:

  • Ethernet: złącze RJ45, magnesy, układ Phy (o ile nie jest zintegrowany z MCU). Potrzebuję także przełączników i kabla od przełącznika do każdego węzła. Każda płytka drukowana potrzebuje sporo kondensatorów i oporników końcowych, być może również ferrytów. Potrzebuje dobrego projektu płytki drukowanej.
  • CAN: Układ nadawczo-odbiorczy (tani), dowolne złącze, tani kabel może przeskakiwać z jednego węzła do drugiego w pętli wokół witryny. Potrzebujesz tylko jednego kondensatora do transiwera i jednego opornika końcowego na każdym końcu magistrali.

Mówisz o mikrokontrolerach za 1 USD. Koszt autobusu to znacznie więcej niż MCU. Będziesz musiał zsumować całkowity koszt każdego rozwiązania, aby wiedzieć, które z nich jest tańsze. Zsumuj koszty MCU, złącz, transiwerów, elementów pasywnych, PCB, kabli itp.

Rocketmagnet
źródło
0

LPC11C24 firmy NXP ma również zintegrowany transceiver CAN, a CANOpen jest obsługiwany w pamięci ROM (nie zjada pamięci Flash o pojemności 32 K). Płyta LPCXpresso 11c24 kosztuje 20 EUR (zapewniła miejsce na złącze DB9), więc naprawdę dodajesz przewody :-)

Drazen Cika
źródło
0

Odpowiedź z innego podobnego pytania. Niska cena prosta komunikacja między dwoma mikrokontrolerami

TLDR : Niezbyt tani, ale niezawodny w niektórych przypadkach.

Patrząc nieszablonowo, mogą tu być inne rozwiązania, takie jak śledzenie chipa, na który ostatnio wpadłem. Oczywiście wszystko zależy od tego, co chcesz zrobić. Coś w rodzaju UART przychodzi na myśl, jeśli masz oba MCU na tej samej płycie, a nawet planujesz ESD chronić je ręcznie, jeśli zostaną rozdzielone.

Rozwiązanie główne i urządzenia dla aplikacji IO-Link

L6360   Master
L6362A  Device

wprowadź opis zdjęcia tutaj

Kiedy rozważasz takie rozwiązanie:

  1. Chipy graniczne są w pełni chronione, co byłoby ważne, jeśli każdy MCU znajduje się na osobnej płycie i ma do czynienia z odsłoniętymi pinami, np. Zaciskiem śrubowym.
    • Odwrotna polaryzacja
    • Przeciążenie z funkcją odcinania
    • Powyżej temperatury
    • Podnapięcie i przepięcie
    • Przewód otwarty GND i VCC
  2. Interoperacyjność Jeśli ktoś zamierza zaprojektować drugą stronę, wszystko, co musi wiedzieć, to przesłać dane przez IO-Link.
  3. Zintegrowany regulator Vcc(in) 7~30v, Vdd(out) 3.3/5v

Brzmiało to dla mnie interesująco, więc pomyślałem, że go tam opublikuję.

Mehrad
źródło
-3

To zależy od skali Twojej aplikacji i mikrokontrolerów. Wspomniałeś o Atmel tiny / mega, są one dość małe. W ich przypadku I2C / SPI / UART mają tę zaletę, że są zaimplementowane sprzętowo i dlatego są łatwe w użyciu.

vsz
źródło
3
OK, ale jak to rozwiązuje problem PO? IIC to autobus, ale tak naprawdę nie nadaje się w ogóle na duże odległości, np. Przez dom. Jest to single-ended i stosunkowo wysoka impedancja. SPI jest magistralą, ale kontrolowaną przez jednego mastera z osobną linią wyboru slave do każdego urządzenia. Możesz zaimplementować każdą linię jako parę różnicową ze sterownikami linii i odbiornikiem, ale nadal masz problem z wyborem punktu nadrzędnego do podrzędnego. UART jest ściśle punkt-punkt. Nie jest jasne, w jaki sposób zamierzasz je wykorzystać w sytuacji PO.
Olin Lathrop,