Segmentacja ramek diagnostycznych na CAN i LIN

Zdjęcie: segmentacja can

Segmentacja – podobieństwa miedzy protokołami

Segmentacja to inaczej podzielenie komunikatu diagnostycznego na wiele kawałków po to, aby można było je wysłać pojedynczymi ramkami CAN albo LIN.

Omówię temat najpierw zbiorczo, tłumacząc mechanizmy, które są wspólne dla protokołów takich jak LIN, CAN, j1939 i wiele innych, ponieważ zasady segmentacji są dla nich bardzo podobne.

Do czego wogóle jest segmentacja?

Ramki diagnostyczne, różnią się od zwykłych ramek. W zwykłych ramkach mamy określoną strukturę w sekcji DATA ramki, tzn. dokładny Layout występujących w niej sygnałów.

Standardowa ramka CAN ze zdefiniowanymi sygnałami w sekcji DATA

Ramki diagnostyczne są jednak inne. Służą do przesyłania ciągów bajtów, które są interpretowane jako całość. Ramka diagnostyczna ma zawsze 8 bajtów w sekcji DATA, i nie posiada żadnej struktury danych:

Nie będę wchodził w to jakie wartości mają bajty i jak wygląda komunikacja diagnostyczna. Popatrzymy sobie w jaki sposób dane są transmitowane.

W związku z tym przyjmiemy takie oznaczenia, iż bajty które mają być przetransmitowane na magistrali opiszemy kolejno jako [X01, X02, .. ]

W jednej klasycznej ramce CAN mieści się do 8 bajtów danych. Gdy więc komunikat jest krótki, nie ma żadnego problemu – po prostu umieszczamy te bajty w ramce. Jest to jednak rzadkość, zwykle mamy tych bajtów więcej, niż mieści się w jednej ramce.

BA!

Za pomocą requestów diagnostycznych możemy przesyłać cały kod binarny aplikacji, który ma być wgrany jako SW update.

Wtedy, żeby zachować porządek i spójność danych, potrzebna jest segmentacja.

Segmentacja określana jest również jako Transport Layer, Transport Protocol (np. CAN TP) lub po prostu segmentation.

Rodzaje ramek w segmentacji

Mamy kilka rodzajów ramek: Single Frame, First Frame, Consecutive Frame, a w niektórych protokołach mamy jeszcze Flow Control.
Często wykorzystywane są skrótowe zapisy tych nazw tzn. SF, FF, CF i FC.

UWAGA! Zwracam jednak uwagę na kolizję oznaczeń, ponieważ FF może oznaczać zarówno First Frame, jak i wartość pojedynczego bajtu wypełnionego samym jedynkami (0xFF), więc może tu dochodzić do zabawnych nieporozumień.

SF – Single Frame

Jeśli mamy krótki komunikat mieszczący się na – zwykle – 7 bajtach, to leci po prostu Single Frame i po temacie.

FF + CF czyli First Frame i seria Consecutive Frame

Jeśli mamy dłuższy komunikat to najpierw leci First Frame, a następnie seria CF-ów, czyli Consecutive Frame’ów. Liczba kolejnych ramek zależy oczywiście od długości komunikatu.

FC – Flow Control

Flow control używane jest jako informacja zwrotna do nadawcy: w jak dużych paczkach może przesyłać dane i z jakimi odstępami czasu. Odbiorca sygnalizuje tym samym swoją zdolność do przetwarzania danych i tego jak gwałtownie może je skonsumować.

Rozpoznawanie ramek

A skąd wiadomo, jaki rodzaj ramki wleciał na magistralę?
Patrzymy zawsze na pierwszy bajt nazywany PCI, a w zadzie na pierwszego Nibla, czyli połówkę bajtu.
Jeśli mamy na początku:

0X – to na pewno jest Single Frame
1X – to First Frame
2X – to Consecutive Frame,
3X – to Flow Control

No więc skoro pierwsze mamy 0, to mamy do czynienia z Single Frame, czyli pojedynczą ramką. Kolejne pół bajtu określa liczbę bajtów, która będzie przesłana w komunikacie. Naturalnie nie może ona być większa niż 7, ponieważ jeden bajt ( z dostępnych ośmiu) już wykorzystaliśmy.

Ramki diagnostyczne mają zawsze 8 bajtów, więc jeżeli zostają niewykorzystane bajty zapełnia się zwykle 0xFF – ami, choć rzadziej zdarzają się również zera. Dotyczy to zarówno Single Frame, jak i segmentowanych wiadomości.

W ramce First Frame zajmujemy aż dwa pierwsze bajty. Pierwszy nibble to jedynka, kolejne trzy nibble (oznaczone wyżej jako LLL – pierwsze litery słowa length) służą do określenia liczby bajtów do przesłania. Możemy więc przesłać maksymalnie 4095 bajtów danych w jednej tzw. segmentowanej sesji. Tyle wynosi maksymalna wartość trzech nibblów, czyli półtora bajta.

Zazwyczaj bajtów jest mniej niż 255, więc pierwszy bajt wygląda jak dziesiątka. Poczynając od trzeciego bajtu umieszczane są już dane, które chcemy przesłać.

Na poniższym przykładzie LLL = 15, czyli szesnastkowo 0x0F. Tym samym dajemy znać, iż cała transmisja będzie zawierała 15 bajtów z danymi adekwatnymi.

Po przejściu First Frame, zawsze następuje jedna lub więcej Consecutive Frame.
Kolejne CF-y zaczynają się od numerów: 21, 22, 23, 24 i tak dalej. Po dojściu do 2F ten licznik się przepełnia i mamy 20, 21, 22, 23, i tak dalej.

Zauważ jednak, iż po przepełnieniu mamy zero, jednak zaczynaliśmy numerację CF-ów nie od zera tylko od jedynki.

Segmentacja – różnice między protokołami

Diagnostyka i segmentacja na CAN

Po pierwsze w CANie występuje dodatkowa ramka sterująca, która nazywa się Flow Control i zaczyna się ona od Nibbla o wartości 3. Jak sama nazwa wskazuje, ramka ta służy do sterowania przepływem segmentowanej wiadomości.

Gdy jeden węzeł na CANie zaczyna nadawać segmentowaną wiadomość, nadaje swojego First Frame’a czyli mówi coś w stylu

“heej rozpoczynam nadawanie wiadomości, która będzie miała 160 bajtów długości”.

Następnie czeka aż odbiorca wyśle mu Flow Control.

Odbiorca wysyła Flow Control mówiąc:

“Dobra, jestem w stanie odbierać kolejne segmenty (czyli CFy) w paczkach po 5 i z odstępem pomiędzy nimi wynoszącym 5ms”.

No więc Nadawca rozpoczyna transmisję kolejnych 5 CFów z pięcio-miliskeundowym odstępem.

Następnie czeka na kolejny Flow Control, który jest znakiem, iż można nadawać kolejne CFy, i tak aż do końca, czyli do nadania 160 bajtów.

Struktura ramki Flow Control wygląda następująco:

Druga rzecz, która jest charakterystyczna dla CANa to to, iż każde urządzenie, które ma możliwość komunikacji diagnostycznej, ma przypisane dwa ID ramek. Jedno ID służy do nadawaniu do tego urządzenia komunikatów diagnostycznych, drugim ID urządzenie wysyła swoje komunikaty. Pozostałe zaś urządzenia na magistrali ignorują te ramki.

Diagnostyka i segmentacja na LIN

Na LINie sytuacja wygląda inaczej. Z powodu bardzo ograniczonej puli możliwych identyfikatorów ramek, requesty diagnostyczne z LIN mastera wysyłane są zawsze ramką 0x3C, zaś Slave’y wysyłają odpowiedzi ramką 0x3D.

Konieczne jest więc rozróżnienie, do którego węzła LIN master kieruje swoje zapytanie.
Każdy węzeł ma przypisany swój adres diagnostyczny, który jest nazywany NADem, od słów Node-Address.

W każdej ramce, niezależnie od tego czy jest to request czy response, na pierwszym bajcie występuje NAD, dopiero potem PCI, czyli rozróżnienie, czy jest to Single Frame, First Frame czy Consecutive Frame.
Na Linie nie występuje również ramka Flow Control.

Na skróty

Możesz zapoznać się z treścią przedstawioną w tym artykule na poniższym nagraniu: