Sterownik ISO-TP: implementacja i testy dla CAN

Praktyczny rozbór sterownika ISO-TP od Razrabotciki-Enoty dla sieci CAN

ISO-TP (ISO 15765-2) rozwiązuje problem ograniczenia klasycznego CAN do 8 bajtów na ramkę, fragmentując duże tablice danych. Sterownik od Razrabotciki-Enoty implementuje protokół za pomocą czterech kluczowych funkcji: inicjalizacji, wysyłania, kolejkowania przychodzących ramek i przetwarzania. Obsługuje pakiety do 4094 bajtów z wykorzystaniem kolejki FIFO do składania ramek.

API sterownika:

n_rslt iso15765_init(iso15765_t* instance);
n_rslt iso15765_send(iso15765_t* instance, n_req_t* frame);
n_rslt iso15765_enqueue(iso15765_t* instance, canbus_frame_t* frame);
n_rslt iso15765_process(iso15765_t* instance);

Inicjalizacja wymaga callbacków dla uptime, wysyłania ramek, obsługi błędów i sygnalizacji odbioru. Konfigurowane są BS (block size), STmin (separation time), typ adresowania i maksymalny rozmiar pakietu.

Zależności i wewnętrzna architektura

Sterownik zależy od uniwersalnej kolejki iqueue do przechowywania przychodzących ramek CAN. Stała I15765_QUEUE_ELMS określa głębokość bufora.

i_status iqueue_init(iqueue_t* _queue, uint32_t _max_elements, 
                     size_t _element_size, void* _storage);
i_status iqueue_enqueue(iqueue_t* _queue, void* _element);
i_status iqueue_dequeue(iqueue_t* _queue, void* _element);

Odbiór składa dane z FirstFrame i ConsecutiveFrame w całość. Po zakończeniu wywoływany jest callback indn() z pełnym payloadem. Dane są usuwane po przetworzeniu w callbacku.

Wysyłanie za pomocą iso15765_send() obsługuje do 4094 bajtów (12-bitowe pole długości). Single frame do 8 bajtów, multi-frame — sekwencyjne bloki z potwierdzeniami.

Testowanie bez części sprzętowej

Modułowe testy symulują wymianę między trzema instancjami ISO-TP w jednym programie. Callback send jest przekierowywany na enqueue odbiornika. Porównywane jest CRC32 wysłanego i odebranego payloadu.

Przykład logu testu wysyłania 24 bajtów:

• TxSize:24 Byte, TxCrc32:0x8295A696
• RxFirstFrame: MesgSize:24 Byte
• ConsecutiveFrame: SN=1, Payload:000102...17181920212223
• DataMatch! Size:24 Byte

Test potwierdza poprawną składkę i weryfikację. Czas trwania: ~863 ms.

Walidacja sprzętowa na USB-CAN

Do rzeczywistego ruchu używany jest adapter USB2CANFD_V1. CANcat — konsolowa użyteczność analogiczna do netcat dla ISO-TP.

Udane przykłady:

• Przesyłanie 0x3344556656565656565656 między procesami.
• Jumbo-frame 0x11223344556677889900aabbccddeeff od 0xd do 0xc.
• Single frame w obie strony.

Logi pokazują poprawną obsługę FirstFrame (FS=0, BS=3), ConsecutiveFrame i flow control.

Kluczowe zalety i ograniczenia

Zalety:

• Wiele instancji z niezależną konfiguracją (CAN, UART).
• Czyste C, ~1000 linii rdzenia.
• Dwukierunkowy tryb bez przebudowy.

Ograniczenia:

• Nie kompiluje się z -Werror=strict-prototypes.
• Brak jednoczesnego Tx/Rx — wysyłanie przerywa odbiór.
• Nieskończone oczekiwanie na ConsecutiveFrame przy utracie mastera.
• Single frame w klasycznym CAN interpretuje 8-15 bajtów dosłownie, bez sprawdzania.

Co ważne

• Sterownik nadaje się do projektów embedded z CAN, gdzie wymagane jest UDS na ISO-TP.
• Przetwarzanie w superpętli: enqueue na Rx, process z wysoką częstotliwością, send na żądanie.
• Payload jest czyszczony po indn() — kopiuj dane wewnątrz callbacka.
• Testuj modułowo przed hardwarem w celu weryfikacji algorytmu.
• Maksymalnie 4094 bajtów na sesję ze względu na 12-bitowe pole długości.

— Editorial Team