Controlador ISO-TP: implementación y pruebas para CAN

# Desglose práctico del controlador ISO-TP de Raccoon Developers para redes CAN

ISO-TP (ISO 15765-2) resuelve la limitación de CAN clásico de 8 bytes por trama al fragmentar arrays de datos grandes. El controlador de Raccoon Developers implementa el protocolo mediante cuatro funciones clave: inicialización, envío, encolado de tramas entrantes y procesamiento. Soporta paquetes de hasta 4094 bytes usando colas FIFO para el ensamblaje de tramas.

API del controlador:

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

La inicialización requiere callbacks para tiempo de funcionamiento, envío de tramas, manejo de errores e indicación de recepción. BS configurable (tamaño de bloque), STmin (tiempo de separación), tipo de direccionamiento y tamaño máximo de paquete.

Dependencias y arquitectura interna

El controlador depende de la cola iqueue universal para almacenar tramas CAN entrantes. La constante I15765_QUEUE_ELMS define la profundidad del búfer.

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 recepción reensambla datos de FirstFrame y ConsecutiveFrame en una carga útil completa. Al completarse, se llama al callback indn() con la carga útil completa. Los datos se limpian después del procesamiento en el callback.

El envío mediante iso15765_send() soporta hasta 4094 bytes (campo de longitud de 12 bits). Trama única hasta 8 bytes; para multi-trama se usan bloques secuenciales con confirmaciones.

Pruebas sin hardware

Las pruebas modulares simulan el intercambio entre tres instancias ISO-TP en un programa. El callback de envío se redirige al encolado del receptor. Se compara el CRC32 de la carga útil enviada y recibida.

Ejemplo de log de una prueba de envío de 24 bytes:

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

La prueba confirma el ensamblaje y verificación correctos. Duración: ~863 ms.

Validación en hardware con USB-CAN

Para tráfico real, se usa el adaptador USB2CANFD_V1. CANcat es una utilidad de consola similar a netcat para ISO-TP.

Ejemplos exitosos:

• Transmisión de 0x3344556656565656565656 entre procesos.
• Jumbo-frame 0x11223344556677889900aabbccddeeff de 0xd a 0xc.
• Trama única en ambas direcciones.

Los logs muestran el manejo correcto de FirstFrame (FS=0, BS=3), ConsecutiveFrame y control de flujo.

Ventajas clave y limitaciones

Ventajas:

• Múltiples instancias con configuración independiente (CAN, UART).
• C puro, ~1000 líneas de código principal.
• Modo bidireccional sin recompilación.

Limitaciones:

• No compila con -Werror=strict-prototypes.
• Sin Tx/Rx simultáneo: el envío interrumpe la recepción.
• Espera infinita por ConsecutiveFrame si se pierde el maestro.
• Trama única en CAN clásico interpreta 8-15 bytes literalmente, sin comprobación.

Lo importante

• El controlador es adecuado para proyectos embebidos con CAN donde se requiere UDS sobre ISO-TP.
• Procesamiento en superloop: encolar en Rx, procesar a alta frecuencia, enviar bajo demanda.
• La carga útil se limpia tras indn(): copiar datos dentro del callback.
• Probar modularmente antes del hardware para verificar el algoritmo.
• Máximo 4094 bytes por sesión debido al campo de longitud de 12 bits.

— Editorial Team