Jak wygląda ramka CAN

systemywbudowane.pl 1 rok temu

Zdjęcie: ramka can

Na Skróty

Jeśli chcesz wprowadzenia “na skróty” – zajrzyj do poniższego materiału:

Wprowadzenie

Ramka CAN to najmniejsza porcja danych, która jest nadawana na magistrali i jako taka ma swoją strukturę.

Struktura ramki

Ramkę CANową możemy podzielić na następujące bloki:

I teraz nieco kontrowersyjna opinia, którą przedstawiam młodym adeptom sztuki automotive:

Jeśli po raz pierwszy spotykasz się z tematem ramek CAN, na początek wystarczy, iż zapoznasz się tylko z blokami ID oraz DATA.

Dlaczego?

Ponieważ wszystkie pozostałe bloki są obsługiwane przez kontrolery sprzętowe i dopóki nie potrzebujesz przeprowadzać zaawansowanych testów, nie warto zaśmiecać sobie głowy szczegółami.

W uproszczeniu, o ile będziesz nadawać ramkę na magistralę, będzie się to odbywać podobnie do wywołania funkcji

void nadaj_ramke(int ID, byte data[]) { /* ta funkcja nada ramke o identyfikatorze ID z zawartością data[] */ }

to samo dotyczy odczytu komunikacji występującej na magistrali. Gdy będziesz przeglądać logi lub zapis sniffera, tylko te dwie wartości (id oraz data) będą dla Ciebie istotne:

Tak moim zdaniem powinna wyglądać nauka – od ogólnego obrazu do szczegółów (gdy będą potrzebne).

Opis bloków

SOF – Start of Frame

To pojedynczy bit dominujący, który jest znakiem rozpoczęcia ramki CAN.

Normalnie, pomiędzy ramkami magistrala CAN utrzymywana jest w stanie recesywnym. Pojedynczy bit dominujący jest sygnałem, iż teraz zacznie się nadawanie ramki.

ID – Pole arbitracji

Blok o długości 11 lub 29 bitów.

Jest to unikatowy numer dla wiadomości (nie dla nadawcy!), który określa również priorytet wiadomości.

Im niższa jest wartośc ID (im mniejszy jest numer) tym wiadomość ma wyższy priorytet. Ma to znaczenie jedynie wtedy, gdy dwa różne węzły próbują nadać swoje ramki w dokładnie tym samym czasie wtedy “wygra” ramka o wyższym priorytecie. Dlatego też pole to nazywa się polem arbitracji i zapobiega powstawaniu tzw. rejsów (ang. race conditions).

Obejrzyj nagranie o tym jak wygląda rozwiązywanie konfliktów, czyli arbitracja na CANie:

CAN2.0A vs CAN2.0B

Dawniej używane były jedynie identyfikatory 11-bitowe(CAN2.0A), z czasem wprowadzono identyfikatory 29-bitowe (CAN2.0B). W związku z tym ramka CAN z 11-bitowym identyfikatorem określane są mianem Standard, zaś te z 29-bitowym identyfikatorem mianem Extended.

Struktura ramki różni się nieznacznie pomiędzy tymi dwoma standardami w obrębie pól ID oraz Control. W przypadku identyfikatorów 29-bitowych, są one (dość brzydko) podzielone na dwie części: 11 + 18 bitów.

Ramka Standard

Ramka extended

RTR – Remote Transmission Request

Czasami zamiast wysyłać danych możemy zażądać danych. Działa to mniej więcej, tak jakbyśmy pytali:

heej, czy jest ktoś, kto mógłby wysłać ramkę z takim ID?

Ramka CAN z bitem RTR na 1 nazywana jest Remote Frame.

Control Field

Zawiera informację o tym, czy mamy do czynienia z krótką czy z długą ramką, oraz jaka będzie liczba bajtów przesłana w polu Data (DLC = Data Length Count).

Data

Właściwe “mięso”, czyli dane adekwatne, które przesyłamy.

Długość tego pola to od 0 do 8 bajtów.

Jak to od zera? Po co ktoś miałby przesyłać ramkę bez żadnego payloadu?

Dzieje się tak przy wysyłaniu Remote Frames, czyli ramki z żądaniem danych. Wtedy DLC musi równać się zero, co skutkuje tym, iż pole Data w tej ramce nie istnieje.

CRC – Suma kontrolna

Cyclic redundancy check – cykliczne sprawdzenie redundancji

Nadawca przeprowadza pewną operację matematyczną na części bitów przesyłanej wiadomości, a następnie wynik umieszcza w polu CRC.

Następnie odbiorca wiadomości również przelicza CRC po swojej stronie i porównuje ją z wartością CRC otrzymaną od nadawcy.

Jeśli wartości się nie zgadzają oznacza to błąd (zakłócenie) transmisji danych, a sama ramka CAN nie zostanie wykorzystana przez odbiorcę (zostanie zignorowana).

ACK – czy ktoś mnie słyszy?

Po przesłaniu poprzedniego bloku, nadawca czeka na feedback od innych węzłów na magistrali.

Ustawia on stan recesywny na magistrali, zaś każdy z węzłów, który usłyszał ramkę o prawidłowym formacie ustawia w tym momencie bit dominujący jako sygnał dla nadawcy, iż ramka CAN została usłyszana. Nie ma przy tym znaczenia, do kogo była kierowana ramka, każdy węzeł daje znać, iż widzi poprawnie przesłaną ramkę.

Sprawdzana jest więc nie treść wiadomości, tylko sam format oraz zgodność CRC.

A co, jeżeli nikt nie słyszy?

Jeśli po jakiejś liczbie przesłanych ramek (zazwyczaj 16) urządzenie nie dostanie potwierdzenia w polu ACK, przejdzie do trybu błędu, przestanie nadawać ramki lub choćby może przejść do trybu sleep.

Protip:

Dlatego choćby mając urządzenie, które po podaniu zasilania samo zaczyna “siać” ramki na magistralę, do jego poprawnego działania potrzebujemy wpiąć na magistralę choć jedno inne urządzenie pracujące na tym samym bitrate-cie.

Nawet jeżeli jest to produkt z zupełnie innej bajki, to wystarczy aby nasze testowane i wyizolowane urządzenie utrzymało się w prawidłowym trybie nadawania.

EOF – to by było na tyle

EOF to ciąg bitów recesywnych na koniec ramki, które są miejscem na to, by odbiorcy wiadomości lub jej nadawca wystawili dominujące flagi, które sygnalizują błędy transmisji (Error Active, Error Passive, Bus-off). To jest jednak dosyć złożona kwestia i omówię ją przy okazji innego wpisu.