CAN i CAN FD w UAV

CAN jest wielowęzłową magistralą szeregową z arbitrażem, rozbudowanym wykrywaniem błędów i różnicową warstwą fizyczną. W UAV łączy flight controller z ESC, odbiornikami GNSS, czujnikami air-data, modułami zasilania i innymi inteligentnymi węzłami. Odporność CAN nie wynika jednak z samego złącza: wymaga poprawnego bit timingu, liniowej topologii, dwóch terminatorów, właściwych transceiverów oraz świadomego zarządzania priorytetami i stanem bus-off.

Spis treści#

Kontroler, transceiver i protokół
Stan dominujący i recesywny
Arbitraż bez utraty ramki
Identyfikatory 11- i 29-bitowe
Ramka Classical CAN
Bit stuffing i synchronizacja
CAN FD
Bit timing
Latency, obciążenie i priorytety
Wykrywanie błędów
Liczniki i stany błędowe
Topologia przewodu
Terminacja
Masa, common-mode i ochrona
Zasilanie na tym samym złączu
Sterownik MCU
Recovery i redundancja
Diagnostyka
Lista uruchomieniowa
Powiązane tematy
Przypisy

Kontroler, transceiver i protokół#

Kontroler CAN w MCU buduje ramki, wykonuje arbitraż, bit stuffing, CRC, retransmisję i prowadzi liczniki błędów. Nie powinien być bezpośrednio łączony z przewodem CAN_H/CAN_L.

Transceiver zamienia logiczne TX/RX kontrolera na sygnał różnicowy, zapewnia zakres common-mode i steruje stanami dominant/recessive. Różne układy mają inne napięcie zasilania, próg wejścia logicznego, szybkość, tryb standby, zabezpieczenia i obsługę CAN FD.

Protokół wyższej warstwy — DroneCAN, Cyphal/CAN, CANopen albo rozwiązanie producenta — nadaje identyfikatorom i payloadom znaczenie. Dwa urządzenia z poprawnym CAN 2.0B nadal się nie porozumieją, jeśli używają innych definicji wiadomości i bitrate.

Projekt dokumentuje trzy warstwy oddzielnie. Określenie „port CAN” bez napięcia zasilania, pinoutu, terminacji, bitrate i protokołu jest niepełne.

Stan dominujący i recesywny#

Gdy nikt aktywnie nie nadaje, magistrala jest recesywna. Nadajnik stanu dominującego tworzy różnicę napięć między CAN_H i CAN_L. Dominant logicznie wygrywa z recessive, co umożliwia arbitraż typu wired-AND.

Nadajnik stale obserwuje magistralę. Jeżeli wysyła bit recesywny, a odczytuje dominujący, inny węzeł ma wyższy priorytet albo wystąpił błąd — znaczenie zależy od pola ramki. W polu arbitrażu przegrany legalnie wycofuje się; w polu danych rozbieżność jest bit error.

CAN_H i CAN_L nie są dwoma niezależnymi sygnałami logicznymi. Diagnostyka powinna oglądać napięcie różnicowe V_CANH - V_CANL oraz common-mode. Sam przebieg jednej żyły względem lokalnej masy może wprowadzać w błąd.

Arbitraż bez utraty ramki#

Węzły mogą zacząć nadawanie, kiedy magistrala jest wolna. Jeśli kilka wykryje ten sam SOF, porównują bity identyfikatora. Zero jest dominujące, więc niższa wartość numeryczna identyfikatora ma wyższy priorytet.

Węzeł wysyłający recessive i odczytujący dominant przestaje nadawać, lecz nie niszczy ramki zwycięzcy. Może ponowić próbę po zwolnieniu magistrali. To „non-destructive arbitration”.

Konsekwencje:

priorytet jest zakodowany w identyfikatorze, a nie w kolejności kolejki CPU;
stały strumień wysokiego priorytetu może zagłodzić niższy;
przegrany arbitraż nie jest błędem transmisji;
identyczne identyfikatory nadawane równocześnie wymagają identycznych danych aż do końca arbitrażu; różne payloady wywołają błąd;
czas oczekiwania zależy od najdłuższych ramek o wyższym priorytecie i ich okresu.

Identyfikatora nie przydziela się przypadkowo według numeru urządzenia. Protokół wyższej warstwy powinien mapować priorytet do krytyczności i deadline wiadomości.

Identyfikatory 11- i 29-bitowe#

Standard frame format używa identyfikatora 11-bitowego, extended frame format — 29-bitowego. DroneCAN korzysta z formatu rozszerzonego. Format nie jest po prostu większym adresem; protokół może kodować w identyfikatorze typ danych, priorytet, źródło i cel.

Przy wspólnym początku standardowa ramka ma przewagę arbitrażową nad rozszerzoną zgodnie z polami SRR/IDE. Projekt mieszający formaty musi policzyć rzeczywisty arbitraż na przewodzie, nie porównywać tylko liczb zapisanych w aplikacji.

Filtry sprzętowe kontrolera mogą dopuszczać zakresy identyfikatorów, maski albo listy. Filtracja redukuje obciążenie CPU, ale zbyt wąska konfiguracja może cicho ukryć nowe typy wiadomości lub odpowiedzi diagnostyczne.

Ramka Classical CAN#

Ramka danych Classical CAN zawiera w uproszczeniu:

SOF | arbitration | control/DLC | 0..8 B data | CRC | ACK | EOF

SOF synchronizuje początek. Pole arbitrażu niesie identyfikator i informacje o rodzaju ramki. DLC określa liczbę bajtów danych. CRC chroni zakodowaną sekwencję. W slocie ACK każdy poprawnie odbierający węzeł może wymusić dominant; nadajnik dzięki temu wie, że ktoś odebrał ramkę na poziomie CAN.

ACK nie potwierdza, że właściwa aplikacja zrozumiała wiadomość. Dowolny aktywny węzeł może potwierdzić poprawność ramki. Potwierdzenie operacji wymaga odpowiedzi protokołu wyższej warstwy.

Remote frame żąda danych o danym identyfikatorze, lecz współczesne protokoły UAV zwykle opierają się na ramkach danych. Error frame i overload frame są mechanizmami kontrolera, a nie zwykłymi wiadomościami aplikacji.

Osiem bajtów wymusza fragmentację większych transferów. DroneCAN dodaje własny transport wieloramkowy z numerem transferu, toggle i CRC.

Bit stuffing i synchronizacja#

CAN stosuje kodowanie NRZ. Aby zachować wystarczającą liczbę zboczy do synchronizacji, nadajnik po pięciu kolejnych bitach tej samej wartości w objętym obszarze wstawia bit przeciwny. Odbiornik usuwa go. Sześć identycznych bitów tam, gdzie obowiązuje stuffing, jest błędem.

Liczba bitów ramki zależy więc od danych. Do obliczenia maksymalnego czasu zajęcia magistrali nie wystarcza suma pól bez bitów stuff. Analiza worst case zakłada maksymalny narzut i najdłuższą dopuszczalną ramkę.

Zbocza dominant/recessive służą też do resynchronizacji lokalnego czasu bitowego. Propagacja przewodu, transceivera i optoizolacji musi zmieścić się przed sample point wraz z drogą powrotną arbitrażu.

CAN FD#

CAN FD rozszerza payload ramki do 64 bajtów i może przełączać się po arbitrażu na szybszy data bit rate przez BRS. Faza arbitrażu pozostaje wolniejsza, aby wszystkie węzły mogły porównywać bity; faza danych może być krótsza dzięki lokalnemu charakterowi transmisji jednego nadajnika.

DLC powyżej 8 nie mapuje liniowo każdego numeru na liczbę bajtów. CAN FD zmienia również CRC i format pól. Kontroler oraz transceiver muszą obsługiwać żądaną prędkość i timing.

Węzeł Classical CAN, który nie jest FD-tolerant, może potraktować ramkę FD jako błąd i zakłócać magistralę. Zgodność trzeba potwierdzić dla wszystkich węzłów. DroneCAN v0 jest definiowany nad CAN 2.0B; nie staje się automatycznie DroneCAN-FD po włączeniu peryferium FD.

64 bajty nie usuwają arbitrażu. Długa ramka wysokiego priorytetu blokuje niższe przez czas transmisji, więc nadal potrzebna jest analiza schedulability.

Bit timing#

Czas bitu składa się z jednostek time quantum: segmentu synchronizacji, propagation, phase segment 1 i phase segment 2. Kontroler tworzy je z zegara peryferium przez prescaler. Sample point leży między segmentami przed i po próbce.

bitrate = f_CAN / (prescaler · N_tq)
sample_point = (Sync + Prop + Phase1) / N_tq

Nazwy rejestrów różnią się między kontrolerami. Niektóre łączą Prop i Phase1 jako TSEG1. Wartości zapisuje się czasem jako „liczba tq minus jeden”. Konfigurator internetowy jest punktem startowym, nie zastępuje reference manual.

SJW określa maksymalną korekcję fazy podczas resynchronizacji. Zbyt mały nie skompensuje rozjazdu zegarów, zbyt duży nie naprawi złej topologii. Budżet musi uwzględniać tolerancję oscylatorów obu końców, propagację transceiverów, przewodu i izolatora.

Wszystkie węzły potrzebują zgodnego nominalnego bitrate. Różny sample point może czasem działać na krótkim stole, a zawieść na pełnym kablu lub w temperaturze. Parametry zapisuje się jako część profilu sieci.

Latency, obciążenie i priorytety#

Obciążenie magistrali jest sumą rzeczywistych czasów ramek z narzutem, stuffingiem i przerwą międzyramkową. Średnie 30% nie gwarantuje deadline, jeśli wiele periodycznych wiadomości fazuje się w tym samym momencie.

Najgorszy czas odpowiedzi ramki obejmuje:

blokowanie przez jedną rozpoczętą ramkę niższego priorytetu;
interferencję wszystkich ramek wyższego priorytetu, które mogą pojawić się w oknie;
własny czas transmisji;
retransmisje w przyjętym modelu błędów;
kolejkę kontrolera i oprogramowania.

CAN nie przerywa ramki w połowie. Krótkie, krytyczne dane powinny mieć odpowiedni priorytet i ograniczony payload. Duży transfer pliku otrzymuje niższy priorytet i kontrolę pasma.

Priorytet nie jest synonimem częstotliwości. Heartbeat o wysokim znaczeniu może być rzadki, a szybka telemetria niskiego znaczenia — częsta. Źle dobrany identyfikator szybkiego strumienia może stale opóźniać sterowanie.

Wykrywanie błędów#

CAN wykrywa kilka klas błędów:

bit error — nadajnik odczytuje inną wartość niż wysłał poza legalnym arbitrażem/ACK;
stuff error — naruszona reguła bit stuffing;
CRC error — nie zgadza się sekwencja kontrolna;
form error — stałe pole ma niewłaściwą wartość;
ACK error — nikt nie potwierdził ramki.

Węzeł wykrywający błąd emituje error flag, przez co pozostałe odrzucają ramkę. Nadajnik zwykle próbuje ponownie automatycznie. Ta własność daje spójność odbioru, ale przy trwałej usterce może zwiększyć obciążenie.

CRC chroni transmisję przewodową, nie złośliwą modyfikację przez legalny węzeł. Standard CAN nie zapewnia uwierzytelnienia ani szyfrowania. Granica zaufania sieci pokładowej musi być częścią architektury systemu.

Liczniki i stany błędowe#

Kontroler utrzymuje Transmit Error Counter i Receive Error Counter. W zależności od historii przechodzi przez error-active, error-passive i bus-off. Węzeł error-passive ogranicza sposób sygnalizacji błędów; bus-off odłącza nadajnik logicznie od magistrali, aby trwale uszkodzony węzeł jej nie blokował.

Firmware powinien logować:

TEC/REC lub dostępne ich przybliżenia;
liczbę lost arbitration oddzielnie od transmisyjnych błędów;
error warning/passive/bus-off;
ostatni kod błędu i stan magistrali;
liczbę restartów oraz czas od ostatniego zdarzenia;
przeciążenia RX FIFO i brak mailbox TX.

Automatyczny natychmiastowy restart po bus-off może stworzyć pętlę: wadliwy węzeł wraca, generuje błędy i ponownie wypada. Polityka recovery uwzględnia wymagany czas bezczynności, limit prób, backoff oraz przejście systemu w tryb zdegradowany.

Topologia przewodu#

Klasyczny CAN jest magistralą liniową z krótkimi odgałęzieniami. Główny przewód ma parę skręconą, a węzły dołączają przez stubs. Gwiazda tworzy wiele nieciągłości impedancji i odbić.

Maksymalna długość zależy od bitrate, czasu propagacji przewodu, opóźnienia transceiverów, sample point i tolerancji zegara. Nie ma jednej tabeli ważnej dla każdego projektu. W małym UAV długość jest niewielka, lecz odgałęzienia, złącza i agresywne zbocza nadal mają znaczenie.

Parę CAN_H/CAN_L prowadzi się razem z kontrolowaną geometrią. Nie rozdziela się jej wokół złącza ani nie tworzy wielkich pętli. Stub do transceivera jest możliwie krótki. Złącza pośrednie i adaptery laboratoryjne wlicza się do topologii.

Wiązka powinna być oddalona od faz silników, przewodów baterii i węzłów przełączających ESC. Skrętka zmniejsza indukowaną różnicę, ale nie chroni przed przekroczeniem common-mode na skutek złej referencji mas.

Terminacja#

Na dwóch fizycznych końcach magistrali umieszcza się po jednym rezystorze odpowiadającym impedancji charakterystycznej przewodu, typowo 120 Ω. Przy wyłączonym zasilaniu pomiar między CAN_H i CAN_L powinien dać około 60 Ω, jeśli oba terminatory są obecne i nic innego nie wpływa na pomiar.

Nie daje się 120 Ω przy każdym urządzeniu. Trzy terminatory dają 40 Ω, nadmiernie obciążają nadajniki i zmniejszają amplitudę. Brak jednego końca daje odbicia, które mogą być niewidoczne przy małym bitrate, a ujawnić się po zmianie konfiguracji.

Split termination dzieli 120 Ω na dwa rezystory, a ich środek filtruje do referencji przez kondensator. Może zmniejszyć emisję common-mode, ale wartości i połączenie muszą odpowiadać transceiverowi oraz EMC. Terminacja przełączana programowo wymaga bezpiecznego stanu po resecie.

W modularnym UAV pozycja końca zmienia się wraz z wiązką. Terminatory powinny być jawnie oznaczone, a procedura serwisowa zawierać pomiar 60 Ω.

Masa, common-mode i ochrona#

Transmisja jest różnicowa, ale transceiver ma ograniczony zakres napięcia wspólnego. W wielu systemach prowadzi się obok pary przewód referencyjny masy, aby ograniczyć różnicę potencjałów. Nie może on nieświadomie przenosić dużego prądu zasilania sensora.

Izolowany CAN rozdziela domeny galwanicznie, lecz wymaga izolowanego zasilania po stronie magistrali i dodaje opóźnienie. Przy wysokim bitrate opóźnienie wchodzi do budżetu bit timingu.

Zewnętrzny port potrzebuje ochrony ESD/TVS dobranej do CAN, z małą pojemnością i napięciem zacisku zgodnym z transceiverem. Dławik common-mode może pomóc EMC, ale źle dobrany zniekształci sygnał. Elementy ochronne umieszcza się przy złączu z krótką drogą prądu udarowego.

Ground offset, zapad zasilania transceivera i częściowo zasilany węzeł testuje się jawnie. Układ bez zasilania nie powinien trwale obciążać pary.

Zasilanie na tym samym złączu#

Ekosystem UAV często prowadzi CAN i zasilanie w jednym kablu. To wygodne, ale napięcie, maksymalny prąd, zabezpieczenie i kierunek zasilania muszą być jednoznaczne. Dwa źródła mogą walczyć po połączeniu segmentów.

Przewody zasilania wywołują spadek napięcia i pętle masy. Rozruch modułu z dużą pojemnością może zresetować inne węzły. Każda gałąź powinna mieć budżet prądowy, ochronę przed odwrotną polaryzacją oraz ocenę inrush.

Nie wszystkie złącza o takim samym kształcie mają ten sam pinout. Przed połączeniem urządzeń różnych producentów weryfikuje się dokumentację i mierzy napięcie. CAN_H/CAN_L zamienione miejscami nie jest jedynym ryzykiem — napięcie zasilania na pinie sygnałowym może uszkodzić port.

Sterownik MCU#

Kontroler oferuje mailboxy TX, FIFO RX, filtry, timestampy i przerwania. Nowszy M_CAN używa Message RAM z konfigurowalnymi buforami i kolejkami. Sterownik musi przypisać pamięć bez nakładania regionów i zachować wymagane wyrównanie.

Kolejka programowa nie może niweczyć priorytetu CAN. Jeśli kontroler nadaje mailboxy w kolejności żądania zamiast identyfikatora, długa seria niskiego priorytetu może blokować wstawienie krytycznej ramki. Trzeba znać tryb TX queue/FIFO i politykę anulowania.

RX FIFO ma skończoną pojemność. Filtry powinny odrzucać niepotrzebny ruch, a ISR opróżniać FIFO w ograniczonym czasie. Parser wyższej warstwy działa poza ISR. Overflow jest zdarzeniem diagnostycznym, bo utrata jednej ramki może unieważnić wieloramkowy transfer.

Timestamp sprzętowy z momentu odbioru jest lepszy niż czas przetworzenia zadania. Licznik może się przepełniać; konwersja do wspólnego zegara wymaga znanej częstotliwości i atomowego rozszerzenia.

Tryb silent/listen-only pozwala obserwować bez ACK i error flag — przydatny diagnostycznie, ale pojedynczy nadajnik w sieci z samym listenerem dostanie ACK error. Loopback sprawdza kontroler, nie transceiver, terminację ani przewód.

Recovery i redundancja#

Po bus-off oprogramowanie najpierw utrwala stan błędów, potem ocenia, czy magistrala jest potrzebna do bezpiecznego lotu. Dla utraty jednego czujnika możliwa jest degradacja; dla utraty wszystkich ESC system może wymagać natychmiastowej reakcji failsafe.

Reset samego kontrolera CAN nie naprawi zwarcia przewodu, złej terminacji ani transceivera bez zasilania. Recovery ma limit, backoff i warunek stabilności. Watchdog nie może resetować całego FC przy każdym chwilowym błędzie CAN, bo to rozszerza awarię.

Dwie magistrale zwiększają odporność tylko wtedy, gdy nie współdzielą transceivera, przewodu, złącza, regulatora i sterownika programowego w sposób tworzący common cause. Dwa wejścia CAN w jednym kablu nie są redundancją fizyczną.

Węzeł redundantny musi rozstrzygać duplikaty, kolejność i rozbieżne dane. Samo nadanie tej samej wiadomości na obu magistralach może podwoić obciążenie oraz uruchomić operację dwa razy, jeśli protokół nie ma idempotencji.

Diagnostyka#

Diagnostyka zaczyna się od zasilania wyłączonego: pomiar około 60 Ω między CAN_H/CAN_L, ciągłości przewodów oraz braku zwarcia do zasilania/masy. Następnie oscyloskop różnicowy lub dwukanałowy pokazuje amplitudę, ringing, common-mode i sample point.

Typowe wzorce:

nadajnik widoczny, ciągłe retransmisje i ACK error — brak drugiego aktywnego węzła, zły bitrate albo odbiorca w silent mode;
rosnące błędy przy dużym obciążeniu — marginalny timing, topologia lub zasilanie;
działa bez jednego terminatora na stole, zawodzi po dodaniu wiązki — odbicia;
bus-off jednego modułu po rozruchu silników — EMI, ground shift albo brownout transceivera;
ramki w analizatorze, brak w aplikacji — filtry, FIFO overflow lub inny protokół wyższej warstwy;
częste lost arbitration bez error counters — legalne przeciążenie/priorities, nie usterka przewodu.

Plan testów:

potwierdź pinout, napięcia i dwa terminatory;
uruchom dwa węzły przy niskim obciążeniu;
porównaj rzeczywisty bitrate i sample point;
zmierz przebieg na obu końcach i najdłuższym stubie;
zwiększ obciążenie do wartości gorszej niż operacyjna;
testuj jednoczesne wysłanie kilku priorytetów;
rozłącz terminator, linię i zasilanie jednego węzła na stanowisku;
obserwuj TEC/REC, error-passive, bus-off i recovery;
uruchom silniki/przetwornice w kontrolowanych warunkach;
sprawdź degradację funkcjonalną oraz zawartość logu po resecie.

Lista uruchomieniowa#

Kontroler, transceiver, przewód i protokół są zgodne.
Wszystkie węzły mają ten sam bitrate i uzgodniony sample point.
Są dokładnie dwa terminatory na fizycznych końcach.
Rezystancja wyłączonej magistrali została zmierzona.
Topologia jest liniowa, a stuby krótkie.
Common-mode i różnica mas mieszczą się w specyfikacji.
Priorytety wynikają z deadline, nie z wygody numeracji.
Obciążenie policzono z narzutem i worst-case stuffing.
Lost arbitration nie jest raportowane jako błąd przewodu.
TEC/REC, overflow, ACK error i bus-off trafiają do logu.
Recovery ma backoff, limit i tryb zdegradowany.
Zasilanie na złączu ma jednoznaczny budżet i ochronę.
Test objął pełną wiązkę, EMI, brownout i restart węzła.

Powiązane tematy#

Przypisy#

Robert Bosch GmbH, CAN Specification Version 2.0 — ramki, arbitraż, kodowanie, błędy i stany węzła.
Robert Bosch GmbH, M_CAN User's Manual — współczesny kontroler CAN/CAN FD, Message RAM, filtry i obsługa błędów.
DroneCAN, Hardware design recommendations — warstwa fizyczna i praktyki sprzętowe dla sieci pokładowej UAV.

Utworzono: 15 sierpnia 2026. Ostatnia aktualizacja: 15 sierpnia 2026. Źródła zweryfikowano: 15 sierpnia 2026.

Źródła z centralnego rejestru

Bosch: CAN Specification Version 2.0 [specyfikacja protokołu]
Bosch M_CAN Controller Area Network User’s Manual [dokumentacja kontrolera CAN/CAN FD]
DroneCAN: Hardware design recommendations [zalecenia sprzętowe protokołu]