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:
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, jeżeli 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, że 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 właściwe, 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, że 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, że ramka CAN została usłyszana. Nie ma przy tym znaczenia, do kogo była kierowana ramka, każdy węzeł daje znać, że widzi poprawnie przesłaną ramkę.
Sprawdzana jest więc nie treść wiadomości, tylko sam format oraz zgodność CRC.
A co, jeśli 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 nawet może przejść do trybu sleep.
Protip:
Dlatego nawet 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śli 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.
Podsumowanie
Jeśli dotarłeś do tego miejsca – to znaczy, że jesteś na prawdę zdeterminowany 😀 Zostaw proszę komentarz ze słowem “dotrwałem“.
Więcej o budowie ramki pod kątem zawartych w niej sygnałów znajdziesz tutaj: CANoe część 2: Ramki, sygnały, baza danych DBC
Powodzenia w zabawie z magistralą CAN!
Dodaj komentarz