.
1.- ¿Qué es el bus CAN?
Se trata de un protocolo serie de comunicaciones con topología de bus que inicialmente fue desarrollado para automoción, aunque ahora es una de las opciones más seleccionadas en redes de sistemas embebidos. La mayor ventaja es el ratio entre precio/rendimiento.
En las redes CAN no hay direccionamiento, ni maestros o esclavos en el sentido tradicional. Cada nodo envía un mensaje a todos los demás nodos, y son estos últimos los que deciden en base al identificador si lo procesan o no. Dicho identificador, también determina la prioridad del mensaje.
Existen muchas capas de aplicación para CAN, como puede ser CANOpen, ISO 15765, etc , aunque es muy sencillo hacerse un protocolo propio que encaje a nuestras necesidades.
El protocolo dispone de una capa física y capa de mensaje (Niveles OSI).
Dispone de muchas más ventajas que el RS485 y resulta más "sencillo" de implementar, ya que el controlador se encarga de "manejar" el bus de forma transparente para el microcontrolador/usuario. El RS485 sólo define la capa física.
Aplicaciones:
- Automoción
- Domótica.
- Redes industriales.
- Control distribuido.
- Automatización.
- etc.
2.- ¿Qué necesito para poder conectarme/crear una red CAN con Arduino?
Los microcontroladores usados en las placas Arduino, no disponen de controlador CAN integrado, por lo que es necesario tener uno externo (por ejemplo MCP2515 ó SJA1000).
Este dispositivo se encarga de manejar independientemente las comunicaciones. Tan sólo hay que configurarlo adecuadamente y nos informará si existe nuevos datos en el bus. Arduino tan sólo tendrá que leer dicho/s mensaje/s. El propio controlador dispone de un pequeño buffer para almacenar mensajes.
También dispone de un mecanismo de filtro para poder ignorar mensajes no deseados y liberar al microcontrolador (Arduino) dicha tarea.
También se necesita un driver para transformar las señales eléctricas a los niveles apropiados (ej: MCP2551).
En la sección BUY dispones de una placa preparada para empezar a funcionar en cuestión de minutos!!! Todas las tareas de aribitraje del bus, errores, bit timing y sincronizacion,etc son realizadas por el controlador, por lo que es más sencillo de lo que parece.
3.- ¿Cuales son las características principales de un bus CAN?
4.- ¿En qué consiste una red CAN?
En el segundo diagrama, se puede observar un esquema en alto nivel para entender como hacer el cableado.
Se recomienda cablear el bus con : par trenzado para las comunicaciones, masa y alimentacion (4 cables).
Por ejemplo, se podría usar cable tipo Cat 5 para la instalación.
Cada dispositivo dispone de una ramificacion en formato "Y" con la misma clase de conectores: uno hembra y otro macho. La unión en dicha "Y" debe ser lo mas corta posible (<30 cm). Si sigues estas recomendaciones, te será muy sencillo añadir nuevos dispositivos(nodos) a la red.
La controladora CAN que puedes encontrar en BUY, dispone en la placa la posibilidad de habilitar la resistencia terminadora,aunque es un buen método disponer de conectores con la resistencia terminadora soldada entre ambos pines del bus para evitar errores.
5.- ¿Qué velocidad uso?
Es fácil encontrarse en automoción redes a 500 kbps (bus tracción).
La velocidad máxima depende de varios factores como la longitud total, la longitud de la conexión del dispositivo al bus, la calidad de los conectores y cableado, interferencias externas sometidas,…
La recomendación en entornos industriales es:
Longitud Bit Rate
25 metros 1000 kbit/s
50 metros 800 kbit/s
100 metros 500 kbit/s
250 metros 250 kbit/s
500 metros 125 kbit/s
1000 metros 50 kbit/s
2500 metros 20 kbit/s
7.- ¿Qué información hay en un mensaje CAN?
El protocolo CAN define 4 tipos de mensajes (tramas): Data, Remote, Error y Overload frames.
Dentro del mensaje existen multitud de campos, pero aquí veremos los importantes para el usuario, ya que el controlador se encarga de rellenar el resto por nosotros (como por ejemplo el CRC o el ACK).
Por ejemplo, un coche tiene:
- Centralita motor
- Centralita ABS (frenos)
- Display
La centralita ABS manda el mensaje, pongamos 0x100 con las velocidades de las 4 ruedas. Como diseño, se elige que el mensaje con ID=0x100,va a contener dicha información.
Todas las demás centralitas escuchan todos los mensajes de la red, y eligen si quieren usar dicha información o no. Están monitorizando el bus, y cuando llega un mensaje que tiene ID=0x100, saben que dentro va a estar las 4 velocidades de rueda.
Por ejemplo, el Display la usa para mostrarte la Velocidad del coche.
Y la centralita motor lo usa para el control de velocidad, control de tracción,.....
Por otro lado, el ID también sirve para indicar prioridades. Si dos dispositivos intentan enviar a la vez información, aquel que envia un mensaje con ID mas baja, será el que "gana" y el otro esperará a que el bus este libre para reenviar el otro mensaje (ID mayor).
Es decir, se usan las ID más bajas, para aquella información que quieres que se procese la primera. Imagina que tienes un accidente, que se detecta por la centralita del Airbag (con un acelerómetro). Pues esta envía un mensaje de alta prioridad (ID baja) para que otros dispositivos actuen (como por ejemplo parar el motor, desenchufar las bombas de gasolina,....)
11.- ¿Qué es formato Intel o Motorola usado en automoción?
El formato Intel ("Little Endian") indica que el LSB se encuentra en la dirección más baja de memoria.
El formato Motorola ("Big Endian") indica que el MSB se encuentra en la dirección más baja de memoria.
Truco: Motorola empieza por M al igual que empieza su formato (primero MSB).
Ejemplo:
Tenemos dos tramas CAN con ID=100 en las que se está transmitiendo exactamente el mismo dato de 16 bits (2 bytes) y en las mismas posiciones (byte0-1) , pero la primera en formato Motorola y la segunda en Intel.
Id | Byte0 | Byte 1 | Byte 2 ...... Byte 8
100 | High byte | Low byte | x ...... x
100 | Low byte | High byte | x ...... x
En automoción, no existen un "estandar". Algunos fabricantes usan un formato y otros el otro. Cada fabricante usa diferentes ID para las mismas señales, al igual que diferentes formatos de datos (intel/motorola).
Un mensaje de cierto fabricante podría ser:
Id | Byte0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | ...
100 | RPM | RPM | THROTTLE | TEMP | TEMP | ...
Es decir, se necesita saber la ID de los datos que nos interesan, la longitud de dicho dato y el formato del mismo (intel/motorola). Ya que se observa que en cada trama, vienen encapsulados varias señales. Otros datos como si es signed/unsigned, la ganancia y offset son importantes, ya que en muchas ocasiones las señales no son enviadas físicas.
12.- Bit Timing recomendados (avanzado) :
13.- Generalidades bus CAN (avanzado) :
El controlador se encarga de todo este trabajo, siendo transparente para el usuario. Pero siempre conviene conocer un poco el funcionamiento del bus.
14.- Mensaje CAN Standard:
Veámos una captura con un analizador lógico de las diferentes partes de un mensaje CAN standard. El mensaje de ejemplo es ID=0x100, 8 bytes de datos cuyos valores son 0x01,0x02,....,0x08.
En nuestro programa de Arduino, sólo hemos tenido que preocuparnos de configurar lo siguiente del mensaje:
CAN_TxMsg.id=0x100;
Por último nos queda el campo ACK (2 bits), que el transmisor pone como recesivos ("1") y que el primero de dichos bits, es sobreescrito por un bit dominante ("0"), por los nodos que han recibido correctamente dicho mensaje. Por lo tanto, dicho bit queda delimitado entre dos bits recesivos ("1").
1.- ¿Qué es el bus CAN?
Se trata de un protocolo serie de comunicaciones con topología de bus que inicialmente fue desarrollado para automoción, aunque ahora es una de las opciones más seleccionadas en redes de sistemas embebidos. La mayor ventaja es el ratio entre precio/rendimiento.
En las redes CAN no hay direccionamiento, ni maestros o esclavos en el sentido tradicional. Cada nodo envía un mensaje a todos los demás nodos, y son estos últimos los que deciden en base al identificador si lo procesan o no. Dicho identificador, también determina la prioridad del mensaje.
Existen muchas capas de aplicación para CAN, como puede ser CANOpen, ISO 15765, etc , aunque es muy sencillo hacerse un protocolo propio que encaje a nuestras necesidades.
El protocolo dispone de una capa física y capa de mensaje (Niveles OSI).
Dispone de muchas más ventajas que el RS485 y resulta más "sencillo" de implementar, ya que el controlador se encarga de "manejar" el bus de forma transparente para el microcontrolador/usuario. El RS485 sólo define la capa física.
Aplicaciones:
- Automoción
- Domótica.
- Redes industriales.
- Control distribuido.
- Automatización.
- etc.
2.- ¿Qué necesito para poder conectarme/crear una red CAN con Arduino?
Los microcontroladores usados en las placas Arduino, no disponen de controlador CAN integrado, por lo que es necesario tener uno externo (por ejemplo MCP2515 ó SJA1000).
Este dispositivo se encarga de manejar independientemente las comunicaciones. Tan sólo hay que configurarlo adecuadamente y nos informará si existe nuevos datos en el bus. Arduino tan sólo tendrá que leer dicho/s mensaje/s. El propio controlador dispone de un pequeño buffer para almacenar mensajes.
También dispone de un mecanismo de filtro para poder ignorar mensajes no deseados y liberar al microcontrolador (Arduino) dicha tarea.
También se necesita un driver para transformar las señales eléctricas a los niveles apropiados (ej: MCP2551).
En la sección BUY dispones de una placa preparada para empezar a funcionar en cuestión de minutos!!! Todas las tareas de aribitraje del bus, errores, bit timing y sincronizacion,etc son realizadas por el controlador, por lo que es más sencillo de lo que parece.
3.- ¿Cuales son las características principales de un bus CAN?
- Sencillo y barato de cablear.
- Muy fácil añadir nuevos dispositivos a la red.
- Buena opción para un control distribuido en tiempo real (¡ divide y vencerás !).
- No hay límite de dispositivos en el bus.
- Multitud de productos en el mercado que utilizan dicho protocolo.
- Protocolo orientado a mensajes (Multicast). Todos los dispositivos pueden "escuchar" los mensajes enviados por el resto de dispositivos (menos los enviados por si mismo). Son los propios dispositivos los que deciden la utilización de los mismos.
- Los mensajes se identifican por el campo ID del mensaje. Es decir, es el identificador lo que nos da la información del contenido del mensaje.
- Protocolo con prioridad. Una menor ID dispone de mayor prioridad sobre el bus.
- Garantizada la recepción del mensaje por uno o varios dispostivos (nodos) de la red.
- Estructura "multimaestro". Cuando el bus esta libre, cualquier dispositivo puede transmitir un mensaje. El mensaje con mayor prioridad (menor ID) ganara el acceso al bus.
- Retransmisión automática de mensajes "defectuosos".
- Un dispositivo dejará de transmitir, si está generando muchos errores.
- Bus diferencial con alta inmunidad al ruido. La red puede trabajar con los dispositivos a diferentes niveles de masa…. ¡ Incluso sin masa común !
- Velocidades hasta de 1Mbps (para longitudes del bus menores a 40 metros).
- Detección de errores. Es una de las ventajas del protocolo, ya que el controlador manejará sofisticados algoritmos de fallos y la retransmisión de mensajes.
- Reglas de arbitraje del bus. Se asegura que no hay pérdida de información y/o tiempo.
4.- ¿En qué consiste una red CAN?
Se trata de dos o mas dispositivos (nodos) conectados a través de un par trenzado de cables. Un tercer cable de masa puede estar acompañando a dicho par o separado como parte del chasis.
Un trenzado cada 20-25mm sera suficiente (distancia entre crestas).
La longitud máxima del bus, depende del número de dispositivos y de la velocidad del mismo.
Es necesario disponer de resistencias terminadoras (120 ohm) en ambos extremos del bus. Es decir, midiendo la resistencia entre ambos cables del bus nos debería dar 60 ohm en cualquier parte del mismo.
Un trenzado cada 20-25mm sera suficiente (distancia entre crestas).
La longitud máxima del bus, depende del número de dispositivos y de la velocidad del mismo.
Es necesario disponer de resistencias terminadoras (120 ohm) en ambos extremos del bus. Es decir, midiendo la resistencia entre ambos cables del bus nos debería dar 60 ohm en cualquier parte del mismo.
(click sobre el diagrama para ampliar)
En el segundo diagrama, se puede observar un esquema en alto nivel para entender como hacer el cableado.
Se recomienda cablear el bus con : par trenzado para las comunicaciones, masa y alimentacion (4 cables).
Por ejemplo, se podría usar cable tipo Cat 5 para la instalación.
Cada dispositivo dispone de una ramificacion en formato "Y" con la misma clase de conectores: uno hembra y otro macho. La unión en dicha "Y" debe ser lo mas corta posible (<30 cm). Si sigues estas recomendaciones, te será muy sencillo añadir nuevos dispositivos(nodos) a la red.
La controladora CAN que puedes encontrar en BUY, dispone en la placa la posibilidad de habilitar la resistencia terminadora,aunque es un buen método disponer de conectores con la resistencia terminadora soldada entre ambos pines del bus para evitar errores.
5.- ¿Qué velocidad uso?
Es fácil encontrarse en automoción redes a 500 kbps (bus tracción).
La velocidad máxima depende de varios factores como la longitud total, la longitud de la conexión del dispositivo al bus, la calidad de los conectores y cableado, interferencias externas sometidas,…
La recomendación en entornos industriales es:
Longitud Bit Rate
25 metros 1000 kbit/s
50 metros 800 kbit/s
100 metros 500 kbit/s
250 metros 250 kbit/s
500 metros 125 kbit/s
1000 metros 50 kbit/s
2500 metros 20 kbit/s
6.- ¿Cuáles son los niveles?
Logico "1" es cero voltios diferencial.
Logico "0" es dos voltios diferencial. Dicho estado es el dominante. Se trata de un bus en formato de AND, ya que el "0" es el estado dominante.
Logico "1" es cero voltios diferencial.
Logico "0" es dos voltios diferencial. Dicho estado es el dominante. Se trata de un bus en formato de AND, ya que el "0" es el estado dominante.
7.- ¿Qué información hay en un mensaje CAN?
El protocolo CAN define 4 tipos de mensajes (tramas): Data, Remote, Error y Overload frames.
Dentro del mensaje existen multitud de campos, pero aquí veremos los importantes para el usuario, ya que el controlador se encarga de rellenar el resto por nosotros (como por ejemplo el CRC o el ACK).
El mensaje más común del protocolo es el Data Frame. Los campos más importantes de dicho mensaje es la ID (Standard=11 ó Extendida 29 bits),RTR , DLC (longitud), DATA (0 a 8 bytes).
Usando siempre la misma longitud de datos, se simplifica enórmemente tu programa.
Asegurate que dos de tus dispositivos (nodos) no manden mensajes usando la misma ID.
Usando siempre la misma longitud de datos, se simplifica enórmemente tu programa.
Asegurate que dos de tus dispositivos (nodos) no manden mensajes usando la misma ID.
Remote => No es muy utilizado,pero básicamente se trata de hacer una petición a la red de un determinado mensaje (a través de la ID) e indicando el número de datos esperados (DLC). No se envian datos en este tipo de trama. El nodo que reconoce dicha petición, transmitirá dicho mensaje convencional.
Error => Si un dispostivo detecta un fallo, dicho mensaje es transmitido y el resto de nodos son informados del error. El transmisor del mensaje, volverá a intentar retransmitir el mensaje.
Existe un elaborado método de contadores de errores para asegurar que un nodo que continuamente esta creando errores, no destruya el tráfico del bus.
Existen 5 mecanismos de fallos: bit monitoring, bit Stuffing, Frame Check, Acknowledgement Check y Cyclic Redundancy Check.
8.- ¿Qué conectores uso?
No existe una norma, pero en el ambito industrial el DB9 es el estandard.
Siendo:
Existe un elaborado método de contadores de errores para asegurar que un nodo que continuamente esta creando errores, no destruya el tráfico del bus.
Existen 5 mecanismos de fallos: bit monitoring, bit Stuffing, Frame Check, Acknowledgement Check y Cyclic Redundancy Check.
8.- ¿Qué conectores uso?
No existe una norma, pero en el ambito industrial el DB9 es el estandard.
Siendo:
- pin 2, CAN_L
- pin 3, CAN_GROUND
- pin 5, Shield (opcional)
- pin 6, Ground (opcional)
- pin 7, CAN_H
- pin 9, Power (opcional)
9.- ¿Qué es el ID en un mensaje CAN ?
El protocolo CAN esta orientado a mensaje. Es decir, cuando se envía un mensaje no se especifica a quien va destinado. Es el identificador lo que es usado para saber el contenido de dicho mensaje.
El protocolo CAN esta orientado a mensaje. Es decir, cuando se envía un mensaje no se especifica a quien va destinado. Es el identificador lo que es usado para saber el contenido de dicho mensaje.
Por ejemplo, un coche tiene:
- Centralita motor
- Centralita ABS (frenos)
- Display
La centralita ABS manda el mensaje, pongamos 0x100 con las velocidades de las 4 ruedas. Como diseño, se elige que el mensaje con ID=0x100,va a contener dicha información.
Todas las demás centralitas escuchan todos los mensajes de la red, y eligen si quieren usar dicha información o no. Están monitorizando el bus, y cuando llega un mensaje que tiene ID=0x100, saben que dentro va a estar las 4 velocidades de rueda.
Por ejemplo, el Display la usa para mostrarte la Velocidad del coche.
Y la centralita motor lo usa para el control de velocidad, control de tracción,.....
Por otro lado, el ID también sirve para indicar prioridades. Si dos dispositivos intentan enviar a la vez información, aquel que envia un mensaje con ID mas baja, será el que "gana" y el otro esperará a que el bus este libre para reenviar el otro mensaje (ID mayor).
Es decir, se usan las ID más bajas, para aquella información que quieres que se procese la primera. Imagina que tienes un accidente, que se detecta por la centralita del Airbag (con un acelerómetro). Pues esta envía un mensaje de alta prioridad (ID baja) para que otros dispositivos actuen (como por ejemplo parar el motor, desenchufar las bombas de gasolina,....)
10.- Sin entrar en tecnicismos...¿cuales son las partes importantes de un mensaje CAN estandar?
- ID = Identificador (libreria creada para usar 11 bits)
- DLC= Número de datos enviados en la trama (0 a 8)
- DATA= Hasta 8 bytes de datos.
Para trabajar con bus CAN, no hay que preocuparse como se genera la trama, ya que de esto se encarga el hardware (controlador).
11.- ¿Qué es formato Intel o Motorola usado en automoción?
El formato Intel ("Little Endian") indica que el LSB se encuentra en la dirección más baja de memoria.
El formato Motorola ("Big Endian") indica que el MSB se encuentra en la dirección más baja de memoria.
Truco: Motorola empieza por M al igual que empieza su formato (primero MSB).
Ejemplo:
Tenemos dos tramas CAN con ID=100 en las que se está transmitiendo exactamente el mismo dato de 16 bits (2 bytes) y en las mismas posiciones (byte0-1) , pero la primera en formato Motorola y la segunda en Intel.
Id | Byte0 | Byte 1 | Byte 2 ...... Byte 8
100 | High byte | Low byte | x ...... x
100 | Low byte | High byte | x ...... x
En automoción, no existen un "estandar". Algunos fabricantes usan un formato y otros el otro. Cada fabricante usa diferentes ID para las mismas señales, al igual que diferentes formatos de datos (intel/motorola).
Un mensaje de cierto fabricante podría ser:
Id | Byte0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | ...
100 | RPM | RPM | THROTTLE | TEMP | TEMP | ...
Es decir, se necesita saber la ID de los datos que nos interesan, la longitud de dicho dato y el formato del mismo (intel/motorola). Ya que se observa que en cada trama, vienen encapsulados varias señales. Otros datos como si es signed/unsigned, la ganancia y offset son importantes, ya que en muchas ocasiones las señales no son enviadas físicas.
12.- Bit Timing recomendados (avanzado) :
- 1 Mbps => Long max 25 metros => Bit Time= 1us => Time quanta por bit=8 => Longitud 1 quanta= 125ns => Sample Point= 6TQ( 75%)
- 800 Kbps => Long max 50 metros => Bit Time= 1.25us => Time quanta por bit=10 => Longitud 1 quanta= 125ns => Sample Point= 8TQ( 80%)
- 500 Kbps => Long max 100 metros => Bit Time= 2us => Time quanta por bit=16 => Longitud 1 quanta= 125ns => Sample Point= 14TQ( 87.5%)
- 250 Kbps => Long max 250 metros => Bit Time= 4us => Time quanta por bit=16 => Longitud 1 quanta= 250ns => Sample Point= 14TQ( 87.5%)
13.- Generalidades bus CAN (avanzado) :
El controlador se encarga de todo este trabajo, siendo transparente para el usuario. Pero siempre conviene conocer un poco el funcionamiento del bus.
- Todos los nodos escuchan los mensajes. Si un nodo detecta un error, envia un NACK al bus. Cuando los nodos reciben un NACK para un mensaje, todos los nodos ignoran dicho mensaje aunque ellos mismos no hayan detectado el problema en dicho mensaje. El emisor, reenvia el mensaje que obtuvo NACK.
- Un nodo que crea muchos mensajes NACK o aquel que envia dichos mensajes que son procesados como NACK, pasan a un estado de prueba (Error Passive). En dicho estado, la actividad del nodo esta restringida. Si continua el problema, el nodo para de transmitir e ignora los mensajes que llegan.
- Un nodo no empieza la transmisión a no ser que el bus no este ocupado por al menos el tiempo equivalente a 3 bits.
- Si dos nodos intentan transmitir a la vez, el nodo con menor ID (mayor prioridad) ganará el acceso al bus.
- En un bus mensajes de ID 11 bits o 29 bits pueden coexistir.
- La velocidad puede llegar hasta 1 Mbps.
- El Start of Frame es usado por el receptor para determinar la velocidad.
- Stuffed bit => Cada 5 bits a consecutivos iguales, se envia un extra bit con la polarización inversa. El receptor ignora dichos bits. Si el receptor detecta 6 bits consecutivos iguales, se considera erroneo el mensaje.
- Se puede configurar el controlador hardware para que filtre sólo aquellos mensajes en los cuales se estan interesados. Gracias a ésto, se evita sobrecargar al microcontrolador cuando sólo se está interesado en unos determinados mensajes.
14.- Mensaje CAN Standard:
Veámos una captura con un analizador lógico de las diferentes partes de un mensaje CAN standard. El mensaje de ejemplo es ID=0x100, 8 bytes de datos cuyos valores son 0x01,0x02,....,0x08.
En nuestro programa de Arduino, sólo hemos tenido que preocuparnos de configurar lo siguiente del mensaje:
CAN_TxMsg.id=0x100;
CAN_TxMsg.header.rtr=0;
CAN_TxMsg.header.length=8;
CAN_TxMsg.data[0]=0x01;
CAN_TxMsg.data[1]=0x02;
CAN_TxMsg.data[2]=0x03;
CAN_TxMsg.data[3]=0x04;
CAN_TxMsg.data[4]=0x05;
CAN_TxMsg.data[5]=0x06;
CAN_TxMsg.data[6]=0x07;
CAN_TxMsg.data[7]=0x08;
Y enviar el mensaje con la orden=> CAN.send(&CAN_TxMsg);
La trama completa es generada de forma transparente por el controlador externo CAN.
Vamos a ir ampliando cada una de las partes. Empezamos con SOF (Start of Frame) y el Identificador.
El bit SOF sirve para sincronización e indicar a la red que un mensaje empieza.
Aprovechamos este ejemplo, para ver el bit stuffing. Como se puede observar en la figura anterior, cada 5 bits de la misma polaridad, se inserta un bit de polaridad inversa. El bus CAN se trata de un protocolo asíncrono, por lo que necesita de un mecanismo para asegurar que con el envio de largas cadenas de bits, el receptor no se quede fuera de fase.
Se observa que ID=0x100h=b00100000000. El controlador CAN ha introducido un "1" después de los primeros 5 bits a "0".
Ahora veámos RTR,IDE y DLC:
Bytes de datos (de 0 a 8 bytes):
En el ejemplo de la figura, es el primer byte de la trama de datos, que contiene el valor 0x01=0b00000001.
El resto de bytes es similar concepto.
Ahora el campo CRC, el cual es el código de redundancia cíclica. Se trata de un valor generado por el transmisor usando los bits precedentes de la trama. Los receptores realiza la misma operación para detectar si ha habido algún cambio accidental en la misma (por ejemplo, debido a ruido eléctrico). Después de dicho campo, se envía el CRC delimiter (1 bit) siempre recesivo ("1").CAN_TxMsg.data[0]=0x01;
CAN_TxMsg.data[1]=0x02;
CAN_TxMsg.data[2]=0x03;
CAN_TxMsg.data[3]=0x04;
CAN_TxMsg.data[4]=0x05;
CAN_TxMsg.data[5]=0x06;
CAN_TxMsg.data[6]=0x07;
CAN_TxMsg.data[7]=0x08;
Y enviar el mensaje con la orden=> CAN.send(&CAN_TxMsg);
La trama completa es generada de forma transparente por el controlador externo CAN.
(click para ampliar)
Vamos a ir ampliando cada una de las partes. Empezamos con SOF (Start of Frame) y el Identificador.
El bit SOF sirve para sincronización e indicar a la red que un mensaje empieza.
(click para ampliar)
Aprovechamos este ejemplo, para ver el bit stuffing. Como se puede observar en la figura anterior, cada 5 bits de la misma polaridad, se inserta un bit de polaridad inversa. El bus CAN se trata de un protocolo asíncrono, por lo que necesita de un mecanismo para asegurar que con el envio de largas cadenas de bits, el receptor no se quede fuera de fase.
Se observa que ID=0x100h=b00100000000. El controlador CAN ha introducido un "1" después de los primeros 5 bits a "0".
Ahora veámos RTR,IDE y DLC:
(click para ampliar)
- RTR (1 bit) = Remote Transmision Request. Petición de datos usando trama RTR.
- IDE (1 bit) =Identifier extension bit. Indica si es una trama Standard(ID de 11bits) o Extendida (ID de 29 bits). "0"=Standard y "1" Extendida.
- r (1 bit) =Reserved bit. Siempre recesivo= "0".
- DLC (4 bit) =Data length code.Indican el número de bytes (de 0 a 8 bytes). Vemos que son 8 bytes=0b100=8d.
Bytes de datos (de 0 a 8 bytes):
(click para ampliar)
En el ejemplo de la figura, es el primer byte de la trama de datos, que contiene el valor 0x01=0b00000001.
El resto de bytes es similar concepto.
(click para ampliar)
Por último nos queda el campo ACK (2 bits), que el transmisor pone como recesivos ("1") y que el primero de dichos bits, es sobreescrito por un bit dominante ("0"), por los nodos que han recibido correctamente dicho mensaje. Por lo tanto, dicho bit queda delimitado entre dos bits recesivos ("1").
(click para ampliar)
