Pilote ISO-TP : implémentation et tests pour CAN

Décomposition pratique du pilote ISO-TP de Raccoon Developers pour les réseaux CAN

ISO-TP (ISO 15765-2) résout la limitation du CAN classique à 8 octets par trame en fragmentant les grands ensembles de données. Le pilote de Raccoon Developers implémente le protocole via quatre fonctions clés : initialisation, envoi, mise en file d'attente des trames entrantes et traitement. Il prend en charge des paquets jusqu'à 4094 octets en utilisant des files FIFO pour l'assemblage des trames.

API du pilote :

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

L'initialisation nécessite des callbacks pour le temps écoulé, l'envoi de trames, la gestion des erreurs et l'indication de réception. BS (taille de bloc), STmin (temps de séparation), type d'adressage et taille maximale de paquet sont configurables.

Dépendances et architecture interne

Le pilote dépend de la file d'attente universelle iqueue pour stocker les trames CAN entrantes. La constante I15765_QUEUE_ELMS définit la profondeur du tampon.

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

La réception réassemble les données issues de FirstFrame et ConsecutiveFrame en une charge utile complète. À la fin, le callback indn() est appelé avec la charge utile complète. Les données sont effacées après traitement dans le callback.

L'envoi via iso15765_send() prend en charge jusqu'à 4094 octets (champ de longueur de 12 bits). Trame unique jusqu'à 8 octets, multi-trames avec blocs séquentiels et accusés de réception.

Tests sans matériel

Les tests modulaires simulent les échanges entre trois instances ISO-TP dans un seul programme. Le callback d'envoi est redirigé vers la mise en file d'attente du récepteur. Le CRC32 de la charge utile envoyée et reçue est comparé.

Exemple de journal d'un test d'envoi de 24 octets :

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

Le test confirme l'assemblage et la vérification corrects. Durée : ~863 ms.

Validation matérielle sur USB-CAN

Pour du trafic réel, l'adaptateur USB2CANFD_V1 est utilisé. CANcat est une utilitaire en ligne de commande semblable à netcat pour ISO-TP.

Exemples réussis :

• Transmission de 0x3344556656565656565656 entre processus.
• Trame jumbo 0x11223344556677889900aabbccddeeff de 0xd à 0xc.
• Trame unique dans les deux sens.

Les journaux montrent une gestion correcte de FirstFrame (FS=0, BS=3), ConsecutiveFrame et contrôle de flux.

Avantages clés et limitations

Avantages :

• Plusieurs instances avec configuration indépendante (CAN, UART).
• C pur, ~1000 lignes de code principal.
• Mode bidirectionnel sans recompilation.

Limitations :

• Ne se compile pas avec -Werror=strict-prototypes.
• Pas de Tx/Rx simultané — l'envoi interrompt la réception.
• Attente infinie pour ConsecutiveFrame si le maître est perdu.
• Trame unique en CAN classic interprète 8-15 octets littéralement, sans vérification.

Points importants

• Le pilote convient aux projets embarqués avec CAN où UDS sur ISO-TP est requis.
• Traitement en superboucle : mise en file sur Rx, traitement à haute fréquence, envoi sur demande.
• La charge utile est effacée après indn() — copier les données dans le callback.
• Tester de manière modulaire avant le matériel pour vérifier l'algorithme.
• Maximum 4094 octets par session en raison du champ de longueur de 12 bits.

— Editorial Team