Komunikacja między wieloma mikrokontrolerami

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.

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.

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.

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.

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:

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.

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

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

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ę.

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.