ISO-TP-Treiber: Implementierung und Tests für CAN

Praktische Aufschlüsselung des ISO-TP-Treibers von Raccoon Developers für CAN-Netzwerke

ISO-TP (ISO 15765-2) umgeht die CAN-Classic-Beschränkung von 8 Bytes pro Frame, indem es große Datenarrays fragmentiert. Der Treiber von Raccoon Developers implementiert das Protokoll über vier zentrale Funktionen: Initialisierung, Senden, Einreihen eingehender Frames und Verarbeiten. Er unterstützt Pakete bis zu 4094 Bytes unter Verwendung von FIFO-Warteschlangen für die Frame-Montage.

API des Treibers:

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);

Die Initialisierung erfordert Callbacks für Uptime, Frame-Versand, Fehlerbehandlung und Empfangsanzeige. Konfigurierbar sind BS (Blockgröße), STmin (Trennzeit), Adresstyp und maximale Paketgröße.

Abhängigkeiten und interne Architektur

Der Treiber basiert auf der universellen iqueue-Warteschlange zur Speicherung eingehender CAN-Frames. Die Konstante I15765_QUEUE_ELMS definiert die Puffertiefe.

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);

Beim Empfang werden Daten aus FirstFrame und ConsecutiveFrame zu einem vollständigen Payload zusammengesetzt. Nach Fertigstellung wird der indn()-Callback mit dem vollständigen Payload aufgerufen. Die Daten werden nach der Verarbeitung im Callback gelöscht.

Das Senden über iso15765_send() unterstützt bis zu 4094 Bytes (12-Bit-Längenfeld). Single Frame bis 8 Bytes, Multi-Frame verwendet sequenzielle Blöcke mit Bestätigungen.

Testen ohne Hardware

Modulare Tests simulieren den Austausch zwischen drei ISO-TP-Instanzen in einem Programm. Der Send-Callback wird auf den Enqueue des Empfängers umgeleitet. CRC32 des gesendeten und empfangenen Payloads wird verglichen.

Beispielprotokoll aus einem 24-Byte-Sendtest:

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

Der Test bestätigt korrekte Montage und Überprüfung. Dauer: ~863 ms.

Hardwarevalidierung mit USB-CAN

Für realen Datenverkehr kommt der USB2CANFD_V1-Adapter zum Einsatz. CANcat ist ein Konsolenprogramm ähnlich netcat für ISO-TP.

Erfolgreiche Beispiele:

• Übertragung von 0x3344556656565656565656 zwischen Prozessen.
• Jumbo-Frame 0x11223344556677889900aabbccddeeff von 0xd nach 0xc.
• Single Frame in beide Richtungen.

Die Protokolle zeigen korrekte Handhabung von FirstFrame (FS=0, BS=3), ConsecutiveFrame und Flow Control.

Wichtige Vorteile und Einschränkungen

Vorteile:

• Mehrere Instanzen mit unabhängiger Konfiguration (CAN, UART).
• Reines C, ~1000 Zeilen Kerncode.
• Bidirektionaler Modus ohne Neukompilierung.

Einschränkungen:

• Kompiliert nicht mit -Werror=strict-prototypes.
• Kein gleichzeitiges Tx/Rx – Senden unterbricht Empfang.
• Endloswarten auf ConsecutiveFrame, wenn Master verloren geht.
• Single Frame in CAN classic interpretiert 8-15 Bytes wörtlich, ohne Prüfung.

Wichtige Hinweise

• Der Treiber eignet sich für eingebettete Projekte mit CAN, wo UDS über ISO-TP benötigt wird.
• Verarbeitung im Superloop: Enqueue bei Rx, Process in hoher Frequenz, Send auf Anfrage.
• Payload wird nach indn() gelöscht – Daten im Callback kopieren.
• Modular testen vor Hardware, um Algorithmus zu verifizieren.
• Maximal 4094 Bytes pro Sitzung aufgrund 12-Bit-Längenfeld.

— Editorial Team