Puesta En Marcha Del Protocolo Para Automoción LIN

Introducción

Existen infinidad protocolos de comunicación diferentes, muchos son dependientes del campo de aplicación. En automoción conviven varios protocolos que intercambian datos entre sí dentro del mismo coche. Algunos ejemplos son LIN, CAN, FlexRay, SENT o MOST. En esta entrada se va a explicar la puesta en marcha del protocolo para automoción LIN.

Los coches han dejado de ser puramente mecánicos para convertirse en nada menos que un conjunto de sistemas embebidos en movimiento. Durante décadas, ha habido una incorporación continuada de nuevos elementos electrónicos, desde autorradios hasta complejos elementos de seguridad (como el ABS, ESC, AEB…), pasando por el control electrónico de inyección y llegando a los ADAS, que se acercan a la conducción autónoma.

La electrónica no sólo llega a los elementos críticos del vehículo, sino que está presente en muchos otros aspectos, desde la eficiencia del vehículo hasta el confort. Y es que podemos encontrar elementos electrónicos que mejoren la aerodinámica, que iluminen la carretera para que el conductor tenga la mejor visibilidad posible sin cegar al resto de usuarios de la vía, que regulen la posición de los asientos y espejos, o que faciliten la interacción con el sistema de infotenimiento sin que el conductor aparte la mirada de la carretera.

Dicho esto, los diferentes sistemas tienen diferentes necesidades. Hay elementos que deben tener un tiempo de respuesta muy bajo y cuya probabilidad de fallo ha de ser nula (como por ejemplo el airbag) y hay otros que necesitan de un gran ancho de banda, pero que los fallos no son críticos (como la cámara de visión trasera). Que se pierda un fotograma o que la imagen tenga alguna interferencia no es algo crítico, pero que ante una colisión no salte el airbag, sí que puede tener serias consecuencias. Esto da lugar a que convivan diferentes protocolos de comunicación dentro del vehículo, y la elección de uno u otro depende de la aplicación y parámetros como la tolerancia a fallos, la velocidad de transmisión, el ancho de banda o el coste.

Protocolo LIN: Local Interconnect Network

¿Qué es?

LIN es un protocolo de comunicaciones de automoción. Tiene un bajo coste y está orientado hacia aplicaciones que no tengan requisitos de seguridad. Su velocidad y ancho de banda son bajos. Tal y como se ve en la siguiente imagen, las comunicaciones LIN son una subred de CAN.

La ventaja de LIN reside en que permite reducir costes respecto a un sistema CAN para aquellas aplicaciones que no requieran una velocidad de transmisión elevada. Además, es una comunicación determinista, es el maestro el que tiene que iniciar la comunicación, y se dirige al esclavo a través de su identificador. La longitud de las tramas y el tiempo de transferencia se puede conocer de antemano.

En el siguiente ejemplo se muestra una trama de LIN 2.2:

La línea del protocolo está activa a ‘1’, se pone a ‘0’ mediante un Sync Break, que suele ser de una duración superior a 13 bits. Inmediatamente después se manda un campo de sincronización, equivale al envío del número hexadecimal 0x55. Es una comunicación que no usa un reloj, por lo que el esclavo se sincroniza a partir de esa velocidad. Lo que se le manda a continuación es el identificador, en la versión 2.2 del protocolo consta de 6 bits del PID y otros 2 bits de paridad, más adelante se explicará cómo obtener este dato. Por último, se manda la trama y se termina con el checksum. En caso de que no se envíe un comando, si no que se espere recibir una respuesta, será el esclavo el que envíe el dato solicitado. Un mismo dispositivo puede responder a más de un ID, dependiendo de la acción que se quiera obtener de él.

Cabe añadir que, al igual que en una comunicación UART, por cada Byte hay un bit de start y otro de stop.

Cálculo del identificador

Como se ha comentado anteriormente, en la versión 2.2 de LIN la cabecera consta de los campos break, sincronización e identificador.

El identificador protegido (PID) se obtiene a través del ID de la trama de LIN y dos bits de paridad. Para ello se toman los seis bits menos significativos del ID y se hacen las siguientes operaciones para obtener los bits de paridad (P0 y P1).

Para comprenderlo mejor se va a poner un ejemplo práctico. Vamos a poner que el ID del esclavo sea 0x10, y vamos a descomponerlo para ver cómo se obtiene su PID.

0x10 = 0001 0000

Quitando los dos bits menos significativos queda lo siguiente:

Binario	ID 5	ID 4	ID 3	ID 2	ID 1	ID 0
010000	0	1	0	0	0	0

P0 = 0 ⊕ 0 ⊕ 0 ⊕ 1 = 1

P1 = ¬(0 ⊕ 0 ⊕ 1 ⊕ 0) = 0

Cambiamos la disposición y queda de la siguiente forma:

PID	P1	P0	ID 5	ID 4	ID 3	ID 2	ID 1	ID 0
01010000	1	0	0	1	0	0	0	0

El PID en binario es 0b01010000, que en hexadecimal se traduce en 0x50.

Cálculo del checksum

Una vez que conocemos el PID y tenemos ya una trama de datos para enviar, el último campo de la trama es el checksum. Este se forma a partir del PID y de los datos a enviar. Este método se denomina “enhanced”.

Para obtener el checksum se hace el sumatorio del PID y los bytes de datos. Cuando se supera el valor 0xFF, se le resta. Cuando se llega al último dato, con el resultado obtenido, se hace la función inversa. A continuación, se explica con un ejemplo:

PID = 0x50

Data = 0x52, 0xC3, 0x32

0x50 + 0x52 = 0xA2;

0xA2 + 0xC3 = 0x165; (Hay overflow, 0x165>0xFF. Hay que restarle a ese valor 0xFF)

0x165 – 0xFF = 0x66;

0x66 + 0x32 = 0x98;

¬(0x98) = 0x67;

El campo checksum es 0x67. Existen herramientas que son capaces de calcular estos resultados de forma automática. Un ejemplo se encuentra en esta calculadora en línea, aunque también se ha creado un programa en C que hace eso mismo. Se encuentra en mi repositorio de GitHub dedicado a LIN.

En la siguiente imagen se muestra cómo se han introducido los datos en la calculadora y el resultado obtenido. Como se aprecia, tanto en el método manual como en el automático, llegamos a la misma conclusión.

Hardware

El protocolo LIN funciona a 12V, que es uno de los valores estándares en automoción. Para esta comunicación es necesario en transceptor de LIN, como el TJA1020. Se encarga de adaptar los valores para que los microcontroladores (µC) que interpreten los datos puedan transmitir y recibir datos. Desde el lado del µC, una comunicación de este tipo podría resumirse (muy a grandes rasgos) en una UART con un transceptor.

Puesta En Marcha

Se ha puesto en marcha el protocolo LIN utilizando la familia PSoC 4 de Cypress. Se han utilizado las siguientes placas de evaluación y software:

Hardware:

• 2x CY8CKIT-042
• 1x CY8CKIT-026

Software:

• PSoC Creator 4.2

Arquitectura Hardware

Las tarjetas CY8CKIT-026 y CY8CKIT-042 están pensadas para usarse conjuntamente, y el pin-out está hecho para que puedan montarse como un sándwich. También tiene compatibilidad con Arduino.

La 026 es simplemente una tarjeta que monta dos interfaces CAN y LIN. Al haber dos interfaces de LIN, se puede configurar una como maestro y otra como esclavo. Mientras que la 042 monta un µC PSoC4. Lo que se ha hecho es utilizar una tarjeta para conectarla a la interfaz de esclavo y la otra usarla como maestro.

Lo primero que ha habido que hacer es cambiar algunos de los componentes electrónicos de la interfaz de LIN para convertirla en maestro, ya que por defecto ambas interfaces están configuradas como esclavos. Se ha dejado de la siguiente forma:

Interfaz	Diodo	Resistencia	Condensador
LIN 1 (Maestro)	D4 = PMLL4148L	R22 = 1 kW	C20 = 220 pF
LIN 2 (Esclavo)	D2 = –	R7 = –	C13 = 1 nF

El conexionado entre las tarjetas de evaluación se ha hecho de la siguiente forma:

Como se quiere establecer una comunicación maestro-esclavo, el conjunto de 026+042 en sándwich actúa como esclavo, y la otra tarjeta, envía una trama a través de la UART a la interfaz LIN1, configurada como maestro en la placa 026. Cabe mencionar que se han puesto ambas tarjetas para que sus pines funcionen a 5VDC. Las dos tienen un jumper para configurar el voltaje a 3V3 o a 5V. Se ha puesto GND en común entre ambas tarjetas. El pin de NSLP tiene que estar activo a ‘1’. Se ha conectado directamente a 5V.

Arquitectura Software

Como se ha explicado anteriormente, el protocolo LIN funciona como una UART, lo único que se necesita es un transductor, ya que funciona a diferentes niveles de voltaje. Además, ese elemento permite convertir las líneas de RX y TX en una única línea.

Simplificándolo mucho, lo que se va a hacer es usar una UART en el maestro para enviar y recibir tramas y la API de LIN que proporciona Cypress en el esclavo. No existe actualmente una API de LIN para el maestro, es por eso por lo que se recurre a la UART, de la que también existe una API.

Maestro:

En el maestro se añade la API de UART. Servirá para enviar la trama de datos a la interfaz LIN.

El código que se ha escrito para el envío del mensaje es el siguiente:

UART_MASTER_UartSendBreakBlocking(13);		// Break
UART_MASTER_UartPutChar(sync);			// Sync (0x55)
UART_MASTER_UartPutChar(pid);			// Protected ID (PID). 
for(int i=0; i<8; i++){
      	UART_MASTER_UartPutChar(packet[i]);	// Command Frame
	}
UART_MASTER_UartPutChar(checksum);		// Checksum. LIN 2.2

Tanto el PID como el contenido del paquete a enviar y el checksum, se definen y calculan previamente al envío.

Esclavo:

Para el esclavo, lo primero que se ha hecho ha sido utilizar el ejemplo que proporciona Cypress. Aunque a partir de ese ejemplo, posteriormente se han hecho otros nuevos y se ha ido incrementando la complejidad.

El ejemplo de LIN que se ha tomado es el “Basic LIN Slave Implementation in PSoC 4”. En resumen, es un programa al que le llega un código a través de LIN y en función de la trama recibida cambia los colores del led (o lo apaga por completo) o envía el estado del led informando de su color actual (o de si está apagado).

Dado que se ha modificado la tarjeta CY8CKIT-026 para que la interfaz LIN 1 se comporte como maestro, se ha tenido que modificar también el pin-out del µC.

La estructura de LIN se hace mediante una API. Está previamente configurada:

En la configuración de LIN se ha elegido el estándar 2.2. Los ID que vienen por defecto son el 0x10 para solicitar el cambio de color (que al hallar el PID en el maestro habrá que enviar un mensaje con el valor 0x50) y para obtener una respuesta del estado del esclavo hay que mandarle el ID 0x11, cuyo PID casualmente coincide.

Hacia diseños más complejos

Los pasos que se han dado posteriormente para comprender el protocolo han sido los siguientes:

-Cambiar la velocidad de transmisión.

-Crear nuevas tramas.

-Introducir tramas de distintos tamaños.

-Utilizar el deep-sleep para bajar el consumo del µC.

-Controlar la señal NSLP para evitar que esté constantemente a 5VDC.

-Añadir interrupciones.

Código

Si quieres acceder a proyectos en los que uso el protocolo LIN, puedes echar un vistazo en el siguiente repositorio de GitHub:

• LIN Automotive

Proximamente, siguiendo con la temática Automotive, dedicaré una entrada dedicada al protocolo SENT.

Galería