1. Ciencia

Qué es CAN y cómo funciona el
módulo del microcontrolador
dsPIC30F4013
Grupos 03-04
Relación de alumnos que han participado:
Alepuz Soriano, Héctor Nazario
Giménez Espinosa de los Monteros, Héctor
Jordá Fernández, Jorge Manuel
Ripoll Gisbert, Felipe
Saval Sendra, Pablo Miguel
Serrano Reche, Juan
Talens Noguera, Juan Vicente
1
Índice
1. INTRODUCCIÓN
1.1. Motivación histórica .................................................. pag. 4
1.2. Características básicas del bus CAN ....................... pag. 7
1.3. Competencia y futuro ............................................. pag. 10
1.4. Campos de aplicación .............................................. pag. 13
1.5. Ejemplo de aplicación práctica: Domótica ................ pag. 14
2. TRANSMISIÓN DE DATOS
2.1. Arquitectura de capas
2.1.1. Capa física................................................. pag.
2.1.2. Capa de enlace de datos ........................... pag.
2.2. Estructura de un nodo CAN.................................... pag.
2.3. Formato de codificación y sincronización de datos...pag.
2.4. Tramas
2.4.1. Tipos de tramas ......................................... pag.
2.4.2. Trama de datos ......................................... pag.
2.4.3. Trama remota ............................................ pag.
2.4.4. Trama de error........................................... pag.
2.4.5. Trama de sobrecarga ................................ pag.
2.4.6. Espacio entre tramas................................. pag.
2.5. Acceso múltiple y abitraje de acceso al bus ........... pag.
2.6. Detección de errores
2.6.1. Detección de errores ................................. pag.
2.6.2. Aislamiento de nodos defectuosos ............ pag.
2.7. Especificaciones..................................................... pag.
2.8. Implementaciones .................................................. pag.
18
21
22
23
24
25
27
28
30
30
31
33
34
35
35
3. CAN DEL MICRO dsPIC30F4013
3.1. Características básicas ........................................... pag.
3.2. Transceptor (transceiver) ........................................ pag.
3.3. Modos de funcionamiento ....................................... pag.
3.4. Recepción de mensajes .......................................... pag.
3.5. Transmisión de mensajes........................................ pag.
3.6. Temporización y sincronización de bits
3.6.1. Temporización de bits................................ pag.
3.6.2. Sincronización de bits................................ pag.
3.6.3. Parámetros del tiempo de bit nominal ....... pag.
3.7. Programación
3.7.1. MPLAB ...................................................... pag.
3.7.2. Funciones .................................................. pag.
3.7.3. Ejemplo de aplicación de código ............... pag.
39
41
43
46
48
51
52
53
55
56
69
4. ANEXO: Dispositivos CAN ....................................................... pag. 72
5. BIBLIOGRAFÍA......................................................................... pag. 80
2
1. INTRODUCCIÓN
3
1.1. Motivación histórica
El sistema de bus serie CAN, siglas cuyo significado en castellano es “Control
de Área de Red”, nació en febrero de 1986, cuando el grupo “Robert Bosch
GmbH” (más conocido como “Bosch” a secas) lo presentó en el congreso de la
“Sociedad de Ingeniería de la Automoción”. Desde entonces, CAN se ha
convertido en uno de los protocolos líderes en la utilización del bus serie.
Razones
A comienzos de los 80, los ingenieros de Bosch evaluaron el posible uso de los
sistemas de bus serie existentes en los coches de pasajeros, pero ninguno de
los protocolos de red disponibles satisfacían los requisitos de estos.
El ingeniero Uwe Kiencke fue quien inició el desarrollo del
nuevo sistema en 1983.
Este protocolo de bus serie se ideó principalmente para aportar mayor
funcionalidad, seguridad y fiabilidad, junto a una mayor eficiencia en el gasto
del combustible, ya que la reducción del peso y la complejidad de los
automóviles a través de la reducción del cableado iban a favorecer este hecho.
Ingenieros de “Mercedes-Benz” pronto se involucraron en las primeras fases de
creación del nuevo sistema, y pronto lo hizo también “Intel” como potencial
vendedor de semiconductores. El profesor Wolfhard Lawrenz de la universidad
de ciencias aplicadas de Brunswick-Wolfenbüttel, Alemania, fue quién dio al
nuevo protocolo de red el nombre de “Controller Area Network” (CAN).
A mediados de 1987, “Intel” presentó el primer chip de controlador CAN: el
82526. Poco tiempo después, “Semiconductores Philips” presentaría el
82C200. Estos dos antepasados primigenios de los controladores CAN
actuales eran completamente distintos en cuanto a filtros de aceptación y
control de mensajes:
Intel adoptó el concepto de FullCAN; este requería menos carga de la CPU del
microcontrolador que la implementación BasicCAN elegida por Philips. Pero por
otra parte, el dispositivo de FullCAN era limitado con respecto al número de los
mensajes que podían ser recibidos. Además, el controlador de BasicCAN
requería menos silicio, lo que abarataba aun más su coste. Actualmente, los
términos ‘BasicCAN’ y ‘FullCAN’ han quedado obsoletos.
4
Estandardización
La especificación CAN (versión 2.0) de “Bosch” fue sometida a la
estandardización internacional a comienzos de los 90.
Concretamente en Noviembre de 1993, después de diversos
conflictos políticos, se publicó el estándar ISO 11898, que definía
además una capa física para velocidades de hasta 1 Mbit/s.
Paralelamente, un formato de CAN ‘tolerante a fallos’ se incluyó en la ISO
11519-2. En 1995, el estándar se amplió con la descripción del identificador
CAN de 29 bits.
Desafortunadamente, todas las especificaciones y estandarizaciones
publicadas acerca de CAN contenían errores o estaban incompletas. Para
evitar incompatibilidades, “Bosch” se cercioró, y sigue haciéndolo, de que todos
los micros CAN cumplen con el modelo de referencia que ellos definieron.
De todas formas, las especificaciones CAN han sido revisadas y
estandarizadas con el tiempo en diferentes secciones: la norma ISO 11898-1
describe la 'capa de transmisión de datos CAN'; la ISO 11898-2 la ‘capa física
CAN no tolerante a fallos'; y la ISO 11898-3 la ‘capa física CAN tolerante a
fallos’. Los estándares de ISO 11992 (referente a la interfaz para camiones y
remolques) e ISO 11783 (referente a la maquinaria agrícola y forestal) definen
los perfiles del uso de CAN basados en el US-protocol J1939.
Pioneros
A pesar de que CAN surgió con la idea de ser utilizado en coches de pasajeros,
un gran número de las primeras aplicaciones llegarían desde otros segmentos
de mercado distintos:
Entre otros, el fabricante finlandés de ascensores “Kone”, fue uno de los
primeros en aprovecharse de sus ventajas.
La oficina de ingeniería Suiza “Kyaser” lo introdujo a los fabricantes de
maquinaria textil del país, que acabaron fundando el ‘Grupo de usuarios textiles
CAN’, bajo el liderazgo de ‘Lars-Berno Frediksson’.
En Holanda, “Sistemas médicos Philips” lo utilizó para las redes internas de sus
máquinas de Rayos X. La ‘especificación para mensajes de Philips’ (PMS),
desarrollada principalmente por Tom Suters, representó la primera capa de
aplicación para redes CAN.
También se sucedieron todo tipo de propuestas académicas, como por
ejemplo, la creación a finales de los 80 de un sistema de bus basado en CAN,
para vehículos agrícolas (LBS).
5
Ya en 1992, Mercedes-Benz implantó CAN en sus automóviles de clase alta. Y
aunque en un principio el bus se limitaba a interconectar las unidades de
control electrónico que cuidaban del control del motor, pronto conectarían
además las unidades de control necesarias para los componentes electrónicos.
Para ello, se implementaron dos sistemas de bus CAN separados físicamente,
y conectados a través de ‘gateways’. Actualmente, muchos otros fabricantes de
coches como ”BMW”, “Renault”, “Fiat”, “Saab”, “Volkswagen” o “Volvo”, han
seguido su ejemplo y suelen implementar dos redes CAN en sus coches.
En Marzo de ese mismo año, usuarios internacionales y
grupos de fabricantes fundaron oficialmente la organización
'CAN en la Automoción’ (CiA).
La primera publicación técnica, que trataba acerca de la capa física, fue emitida
solo unas semanas después: ‘CiA’ recomendaba utilizar solamente
transceptores CAN que cumplieran la normativa ISO 11898. A día de hoy, son
los transceptores RS485 los utilizados más comúnmente.
Otra de las primeras tareas de la CiA fue la especificación de la ‘capa de
aplicación CAN’ (CAL), que se desarrolló a partir del material existente de los
“Sistemas médicos de Philips” y de “STZP”.
Capas de aplicación
Desde 1993, dentro del alcance del proyecto ‘ASPIC’, un consorcio europeo
liderado por “BOSCH”, desarrolló un prototipo conocido como CANopen para
las redes internas de las celdas de producción. En 1995, se publicó el perfil
totalmente revisado de las comunicaciones de CANopen, que en el plazo de
cinco años ya se había convertido en la red integrada estandarizada más
importante de Europa, puesto que ofrecía una gran flexibilidad y un gran
número de opciones de configuración, así como diversos perfiles de dispositivo,
interfaz y uso.
Actualmente, CANopen se sigue utilizando especialmente en Europa:
máquinas de moldeado por inyección en Italia, máquinas expendedoras en
Inglaterra, grúas en Francia, control de maquinaria en Austria, o maquinaria de
fabricación de relojes en Suiza... Mientras que en Estados Unidos CANopen se
abre camino en el ámbito de los toros mecánicos y las máquinas clasificadoras.
Poco después de aquello, a comienzos de 1994, “Allen-Bradley” desarrolló la
tecnología DeviceNet, enfocada esencialmente a la automatización de las
fábricas. Pronto ganaría adeptos en Estados Unidos debido sobretodo a su
funcionamiento “plug & play” (enchufar y listo).
6
Pero no fueron las únicas. Desde el momento de la creación de CAL, se fue
sucediendo la creación de diferentes estándares que definían la capa de
aplicación; algunos son muy específicos y están relacionados casi
exclusivamente con sus campos de aplicación. Dejando de lado las 3
mencionadas anteriormente, entre los protocolos de alto nivel y las capas de
aplicación más utilizadas cabe mencionar: SDS, OSEK y CANKingdom.
Por una parte, SDS (Smart Distributed System), fue creado por Honeywell
durante la gestación de DeviceNet, y de hecho era muy similar a este, así que
no entraremos en detalle. OSEK, que estaba basado además en TCP/IP y
algoritmos DSP, rápidamente enfocaría su aplicación a una gran cantidad de
usos en los turismos. Mientras que CANKingdom se enfocó a aplicaciones con
una necesidad alta de aplicaciones en tiempo real, como pueda ser por ejemplo
la electrónica marítima.
Ya por último, en el año 2000, ISO formó un grupo de trabajo que agrupaba
empleados de “Bosch”, académicos y expertos de la industria de los
semiconductores, que definió un nuevo protocolo basado en CAN, el llamado
TTCAN (Time-tiggered communication on CAN). Esta extensión permitía tanto
la transmisión de mensajes simultáneos, como la implementación de un bucle
cerrado para el control del bus. Y gracias a que el protocolo del bus no fue
modificado, este tipo de mensajes podían seguir siendo enviados con el mismo
sistema físico de bus.
7
1.2. Características básicas del bus CAN
•
Económico y sencillo: Dos de las razones que motivaron su desarrollo
fueron precisamente la necesidad de economizar el coste monetario y el
de minimizar la complejidad del cableado, por parte del sector
automovilístico.
•
Estandarizado: Se trata de un estándar definido en las normas ISO
(Internacional Organization for Standardization), concretamente la ISO
11898, que se divide a su vez en varias partes, cada una de las cuales
aborda diferentes aspectos de CAN.
•
Medio de transmisión adaptable: El cableado, como ya hemos dicho, es
muy reducido a comparación de otros sistemas. Además, a pesar de que
por diversas razones el estándar de hardware de transmisión sea un par
trenzado de cables, el sistema de bus CAN también es capaz de trabajar
con un solo cable. Esta particularidad es empleada en diversos tipos de
enlaces, como los enlaces ópticos o los enlaces de radio.
•
Estructura definida: La información que circula entre las unidades a
través de los dos cables (bus) son paquetes de bits (0’s y 1’s) con una
longitud limitada y con una estructura definida de campos que
conforman el mensaje.
•
Programación sencilla.
•
Número de nodos: Es posible conectar hasta 110 dispositivos en una
sola red CAN.
•
Garantía de tiempos de latencia: CAN aporta la seguridad de que se
transmitirá cierta cantidad de datos en un tiempo concreto, es decir, que
la latencia de extremo a extremo no excederá un nivel específico de
tiempo. Además, la transmisión siempre será en tiempo real.
•
Optimización del ancho de banda: Los métodos utilizados para distribuir
los mensajes en la red, como el envío de estos según su prioridad,
contribuyen a un mejor empleo del ancho de banda disponible.
•
Desconexión autónoma de nodos defectuosos: Si un nodo de red cae,
sea cual sea la causa, la red puede seguir funcionado, ya que es capaz
de desconectarlo o aislarlo del resto. De forma contraria, también se
pueden añadir nodos al bus sin afectar al resto del sistema, y sin
necesidad de reprogramación.
•
Velocidad flexible: ISO define dos tipos de redes CAN: una red de alta
velocidad (de hasta 1 Mbps) definida por la ISO 11898-2, y una red de
baja velocidad tolerante a fallos (menor o igual a 125 Kbps) definida por
la ISO 11898-3.
8
•
Relación velocidad-distancia: Al punto anterior habría que añadir que la
velocidad también depende de la distancia hasta un máximo de 1000
metros (aunque podemos aumentar la distancia con bridges o
repetidores), como podemos corroborar en la siguiente tabla
comparativa:
Velocidad
(Kbps)
1000
800
500
250
125
50
20
10
Tiempo de bit
(µS)
1
1.25
2
4
8
20
50
100
Longitud máxima de bus
(m)
30
50
100
250
500
1000
2500
5000
Además podemos hablar de otras características técnicas en las que
profundizaremos más adelante:
•
Orientado a mensajes: Se trata de un protocolo orientado a mensajes, y
no a direcciones, es decir, la información que se va a intercambiar se
descompone en mensajes, a los cuales se les asigna un identificador y
son encapsulados en tramas para su transmisión. Cada mensaje tiene
un identificador único dentro de la red, a partir del cual los nodos
deciden aceptar o no dicho mensaje. Además están priorizados.
•
Multidifusión (multicast): Permite que todos los nodos puedan acceder al
bus de forma simultánea con sincronización de tiempos.
•
Medio compartido (broadcasting): La información es enviada en la red a
todos los destinos de forma simultánea. Así que los destinos habrán de
saber si la información les concierne o deben rechazarla.
•
Detección y señalización de errores: CAN posee una gran capacidad de
detección de errores, tanto temporales, como permanentes, lograda a
través de cinco mecanismos de detección, 3 al nivel de mensaje y 2 a
nivel de bit. Los errores además pueden ser señalizados.
•
Retransmisión automática de tramas erróneas: Junto a la detección y
señalización de errores la retransmisión automática de tramas erróneas
aporta la integridad de los datos. Además ambos procesos son
transparentes al usuario.
•
Jerarquía multimaestro: CAN es un sistema multimaestro en el cual
puede haber más de un maestro (o master) al mismo tiempo y sobre la
misma red, es decir, todos los nodos son capaces de transmitir, hecho
que permite construir sistemas inteligentes y redundantes.
9
1.3. Competencia y futuro
Realmente CAN se encuentra en una posición privilegiada en el mercado.
El siguiente gráfico traza una comparativa entre diferentes tecnologías respecto
al coste por nodo.
Vemos que J1850, pero sobretodo LIN, que tiene una mayor presencia en la
industria, son opciones más económicas, ¿pero hasta qué punto son estas
tecnologías competidoras de CAN?
En la siguiente tabla, se exponen las diferentes características de LIN y CAN (y
de cómo extra el I2C de “Philips”), para detallar la similitud entre ellas:
CAN
Compañía que lo desarrolló
Bosh
1Mb/s
Velocidad
Tamaño de datos
Prioridad de mensajes
Garantía de latencia
Flexibilidad en la configuración
Sistema Multimaestro
Detección y señalización de
errores
Retransmisión de tramas
LIN
Open source
20 Kb/s
I2C
64bits
Si
Si
Si
Si
Si
8bits
No
***
***
No
Si
Philips
0.1Mb/s /
0.4Mb/s
8bits
No
No
Si
Si
Si
automática
No
programable
Se puede llegar a la conclusión fácilmente, de que cada una va a ser útil en un
ámbito de manufactura distinto, ya que sus características son distintas.
La diferencia principal, además de la económica, va a resultar ser la velocidad.
10
Dentro de la industria automovilística por ejemplo, CAN es empleado como bus
de comunicaciones para los elementos más importantes de este, que van a
requerir una seguridad y velocidad mayores. Para otro tipo de visicitudes, como
los elevalunas eléctricos por ejemplo, que tienen mucha menos importancia
que la que puedan tener los frenos o el estado del motor, se emplea el bus LIN.
Uso general del bus CAN en los coches:
Uso general del bus LIN en los coches:
En definitiva, más que competir, lo que hacen es repartirse el pastel, ya que al
tener diferentes características, el fabricante va a poder adaptarse en todo
momento de la mejor forma a las exigencias del mercado, eligiendo uno u otro
para cada necesidad.
11
Ya que otro grupo de la clase ha optado por hacer un trabajo acerca de
Ethernet, vamos a nombrar algunas de las diferencias más importantes que
hay entre estos, aunque no sean competidores directos:
CAN – Ethernet
Aun cuando las similitudes entre CAN y Ethernet son obvias, CAN posee algún
beneficio clave cuando se compara con el protocolo Ethernet. El esquema de
arbitraje que usa el protocolo CAN es de bit inteligente no destructivo. Esto
significa que se comparan los mensajes con cada bit en un momento
determinado, pero el mensaje con la prioridad más alta no se destruye y se
retransmite; sólo el mensaje que no gana el arbitraje de bus se detiene y se
retransmite. Éste es un punto importante que ayuda a minimizar el tiempo de
fuera de servicio del bus y aumentan al máximo uso eficaz del ancho de banda
disponible.
Otra ventaja importante del arbitraje del bit inteligente no destructivo, que usa
CAN, es el hecho que esto da al bus características muy predecibles. Con
Ethernet, ambos transmisores se detienen cuando se detecta una colisión y
una cantidad de tiempo aleatorio se permite pasar antes de que ambos
prueben de la retransmisión. Con este elemento aleatorio de tiempo eliminado
de la función del bus, es posible lograr casi el 100% de eficacia en términos de
utilización del ancho de banda.
Futuro
A día de hoy, el futuro de CAN se prevé esperanzador, ya que incluso las
estimaciones más conservadoras coinciden en que la presencia de CAN en el
mercado y en diversos campos de la industria, va a seguir en aumento durante
los próximos diez o quince años.
12
1.4. Campos de aplicación
El 80% de las aplicaciones modernas del bus CAN se pueden encontrar en la
ingeniería del automóvil y otro tipo de vehículos como autobuses, trenes y
aviones. En el caso de los automóviles por ejemplo, CAN es el encargado de la
comunicación y automatización del sistema de freno, los faros, el ABS, o el
ordenador de abordo, del cual vemos su esquema en el siguiente gráfico:
Sin embargo, también se puede encontrar el bus CAN en aplicaciones de
diversa índole debido a su naturaleza, que le aporta robustez, economía y un
altísimo grado de seguridad y fiabilidad; entre las más comunes:
Control y automatización industrial:
- Redes entre diversas máquinas y elementos de las mismas.
- Redes de supervisión.
- Redes de seguridad.
Control y automatización de edificios:
- Control de ascensores, puertas mecánicas, aspersores y diversos
elementos mecánicos.
- Control de iluminación.
Aplicaciones específicas:
- Control de máquinas expendedoras (en Inglaterra está muy
extendido su uso).
- Control de equipamiento médico.
- Control de sistemas automáticos de almacenaje.
- Control de electrodomésticos.
13
1.5. Ejemplo de aplicación práctica: Domótica
La línea que vamos a tratar, permite una gran versatilidad de interconexionado
de los módulos que la componen, ya que la topología en la que se basa el
sistema de instalación es en modo árbol. Esta característica facilita las posibles
ampliaciones del sistema y en consecuencia reduce el coste de instalación
porque el cableado y el tiempo necesario para la instalación, es menor que en
las instalaciones convencionales.
Se trata de un sistema modular distribuido. Modular, porque el sistema consta
de distintos módulos que permiten una fácil instalación y configuración.
Distribuido, porque cada Controlador Inteligente (CI) es capaz de tomar sus
propias decisiones y actuar en consecuencia, es decir, no existe una única
unidad central; además la pérdida de comunicación entre módulos no impide el
desarrollo de las decisiones locales.
La instalación consta como mínimo de un controlador inteligente. Este CI
controla los distintos elementos que se conectan directamente a él (como
sondas de temperatura, lectores de llaves, etc...) y es el encargado de
gestionar el bus principal (bus CAN) que es el bus que utilizan los distintos CI
para comunicarse entre sí (comunicación principal). También se encarga de
controlar al bus local (bus I2C4H) transmitiendo las órdenes procedentes de
otros CI a los distintos módulos de ampliación que se le pueden conectar y de
reenviar la información captada por estos módulos al resto de CI si procede
(comunicación local).
CI
Dimensiones:
4 módulos DIN
Frontal:
LED de estatus de alimentación
7 LED's de reconocimiento de nodo
de expansión Botón de RESET
Entradas / Salidas:
1 entrada de bus CAN
1 entrada para 5 sondas de
temperatura
1 entrada para 2 receptores IR
1 salida para 4 emisores de IR
1 salida de bus IEE para nodos de
expansión
Comunicaciones externas:
Puerto RS-232
14
La comunicación principal basada en CAN, aprovecha todas las características
de este ya explicadas a lo largo del trabajo: comunicación tipo "broadcast",
donde todos los CI están escuchando y si el mensaje les afecta toman la
decisión de actuar o no, por lo que no hay posibilidad de colisión; la cabecera
de los mensajes está compuesta por un nivel de prioridad de tal forma que es
el mensaje de menor prioridad el que cede el bus al mensaje de mayor
prioridad.
El bus local I2C4H actúa de forma parecida con la diferencia de que si que
existe una dirección de remitente y de destino en los mensajes, también el flujo
de información es menor a nivel local y el CI gestiona este tráfico.
Por otra parte, encontramos el derivador, elemento que hace de ladrón entre
los distintos CI, y que incorpora la alimentación al bus principal y permite la
activación de la resistencia final de línea en cada una de las terminaciones.
Derivador
Dimensiones:
2 módulos DIN
Lateral:
Interruptor final de bus
Entradas / Salidas:
3 conectores bus CAN, configurable
según topología
1 entrada alimentación 24 VCD
1 entrada para línea de teléfono
1 entada aux.
1 salida de bus IEE para nodos de
expansión
Comunicaciones externas:
No
Vamos a ver algunos ejemplos de montaje:
Este es un ejemplo típico de vivienda con un único CI y dos ampliaciones, una
para ocho entradas y ocho salidas en modo encendido y apagado y una
segunda ampliación para el control de cuatro zonas reguladas.
15
En este otro ejemplo de topología podemos ver una instalación típica para un
adosado con tres CI, uno por planta de la vivienda, uno de los cuales (el
primero de ellos) se encontraría al límite de su capacidad; podría ser el que se
encontrara en la primera planta del adosado, por ser esta planta la que
mayores controles requiere.
Para una mejor compresión en este ejemplo solo se han representado los CI y
no sus respectivos módulos de ampliación. Este sería un ejemplo de aplicación
en un edificio de oficinas, residencia o en un hotel, donde tenemos distintas
plantas que controlar. En función de la totalidad de elementos que vamos a
controlar dispondremos de una mayor o menor cantidad de CI por planta.
16
2. TRANSMISIÓN
DE DATOS
17
2.1. Arquitectura de capas
Las implementaciones hardware de CAN cubren de forma estandarizada las
capas físicas y de enlace del modelo de comunicaciones OSI (Open Systems
Interconection), mientras diversas soluciones de software no estandarizadas
cubren la capa de aplicación.
Las estandarizaciones ISO (International Standard Organization), a diferencia
de las normas BOSCH, especifican también el medio de comunicación. Por lo
tanto una implementación CAN a partir de las especificaciones de BOSCH no
siempre será compatible con las normas ISO.
2.1.1. Capa física
La capa física de CAN, es responsable de la transferencia de bits entre los
distintos nodos que componen la red. Define aspectos como niveles de señal,
codificación, sincronización y tiempos en que los bits se transfieren al bus.
En la especificación original de CAN , la capa física no fue definida, permitiendo
diferentes opciones para la elección del medio y niveles eléctricos de
transmisión. Las características de la señales eléctricas en el bus, fueron
establecidas más tarde por el ISO 11898 para las aplicaciones de alta
velocidad y, por el estándar ISO 11519 para las aplicaciones de baja velocidad
18
•
Estándar 11519
Los nodos conectados en este bus interpretan dos niveles lógicos
denominados: Dominante y Recesivo.
-
Dominante: la tensión diferencial (CAN_H - CAN_L) es del orden de
2.0 V con CAN_H = 3.5V y CAN_L = 1.5V (nominales).
-
Recesivo: la tensión diferencial (CAN_H - CAN_L) es del orden de 5V
con CAN_H = 0V y CAN_L = 5V (nominales).
A diferencia del bus de alta velocidad, el bus de baja velocidad requiere dos
resistencias en cada transceptor: RTH para la señal CAN_H y RTL para la
señal CAN_L. Esta configuración permite al transceptor de bus de baja
velocidad (fault-tolerant) detectar fallas en la red. La suma de todas las
resistencias en paralelo, debe estar en el rango de 100-500.
Red Bus CAN de Baja Velocidad ( Fault Tolerant).
19
•
Estándar 11898
Los nodos conectados en este bus interpretan los siguientes niveles lógicos:
-
Dominante: la tensión diferencial (CAN_H - CAN_L) es del orden de
2.0 V con CAN_H = 3.5V y CAN_L = 1.5V (nominales).
-
Recesivo: la tensión diferencial (CAN_H - CAN_L) es del orden de 0V
con CAN_H = CAN_L = 2.5V (nominales).
El par de cables trenzados (CAN_H y CAN_L) constituyen una transmisión de
línea. Si dicha transmisión de línea no está configurada con los valores
correctos, cada trama transferida causa una reflexión que puede originar fallos
de comunicación. Como la comunicación en el bus CAN fluye en ambos
sentidos, ambos extremos de red deben de estar cerrados mediante una
resistencia de 120. Ambas resistencias deberían poder disipar 0.25 w. de
potencia.
Red Bus CAN de Alta Velocidad.
20
2.1.2. Capa de enlace de datos
La capa de enlace de datos es responsable del acceso al medio y el control
lógico y está dividida a su vez en dos niveles.
-
El subnivel LLC (Logical Link Control): Gestiona el filtrado de los
mensajes, las notificaciones de sobrecarga y la administración de la
recuperación.
-
El subnivel MAC (Medium Acces Control): Es el núcleo del protocolo
CAN y gestiona el tramado y desentramado de los mensajes, el
arbitraje a la hora de acceder al bus y el reconocimiento de los
mensajes, así como el chequeo de posibles errores y su
señalización, el aislamiento de fallos en unidades de control y la
identificación del estado libre del bus para iniciar una transmisión o
recepción de un nuevo mensaje.
21
2.2. Estructura de un nodo CAN
Dentro de un nodo CAN, se pueden distinguir una serie de módulos
interconectados entre ellos: un bus de direcciones, datos y un control (paralelo)
enlazando el controlador central, la memoria de los datos y el programa(donde
esta almacenado el software de aplicación y el controlador de red de alto nivel),
los dispositivos de entrada y salida y, la interfaz de comunicación.
Desde el punto de vista del controlador, la interfaz de comunicación se puede
ver como un conjunto de buzones, donde cada uno de estos sirve como
registro lógico de interfaz entre el controlador local y los nodos remotos. Si un
nodo quiere comunicarse,
tiene que dar de alta los correspondientes buzones de recepción y transmisión
antes de hacer ninguna operación.
22
Teniendo en cuenta esta arquitectura, el funcionamiento sigue los siguientes
pasos:
-
-
Para inicializar, el programador especifica los parámetros de los
registros de control de interfaz de comunicación, como las
características del controlador de red o la velocidad de
transmisión.
A continuación, se actualizan todos los buzones. En cada buzón
se especifica si es receptor o transmisor y, su estado inicial,
inicializando su parte de datos del búfer.
Posteriormente, para transmitir un mensaje es necesario poner
los datos en el búfer de datos correspondiente al buzón de
transmisión y activar el flanco de transmisión.
Por último, la interfaz de red intenta comunicar los datos a través
de la red. El estado de la transferencia se puede comprobar en el
estatus de estado de cada buzón.
Una vez hecha la configuración inicial a partir del software de la capa de
aplicación de esta manera, los nodos CAN funcionarán de forma autónoma.
2.3. Formato de codificación y sincronización de datos.
La codificación de bits se realiza por el método NRZ (Non-Return-to Zero) que
se caracteriza por que el nivel de señal puede permanecer constante durante
largos periodos de tiempo y habrá que tomar medidas para asegurarse de que
el intervalo máximo permitido entre dos señales no es superado. Esto es
importante para la sincronización (Bit Timing).
Este tipo de codificación requiere poco ancho de banda para transmitir, pero en
cambio, no puede garantizar la sincronización de la trama transmitida. Para
resolver esta falta de sincronismo se emplea la técnica del “bit stuffing”: cada 5
bits consecutivos con el mismo estado lógico en una trama (excepto del
delimitador de final de trama y el espacio entre tramas), se inserta un bit de
diferente polaridad, no perdiéndose así la sincronización. Por otro lado este bit
extra debe ser eliminado por el receptor de la trama, que sólo lo utilizará para
sincronizar la transmisión.
No hay flanco de subida ni de bajada para cada bit, durante el tiempo de bit hay
bits dominantes (“0”) y recesivos (“1”) y disminuye la frecuencia de señal
respecto a otras codificaciones .
23
2.4 Tramas
2.4.1.Tipo de tramas
El protocolo CAN está basado en mensajes, no en direcciones. El nodo emisor
transmite el mensaje a todos los nodos de la red sin especificar un destino y
todos ellos escuchan el mensaje para luego filtrarlo según le interese o no.
Existen distintos tipos de tramas predefinidas por CAN para la gestión de la
transferencia de mensajes:
-
Trama de datos: Se utiliza normalmente para poner información en el
bus y la pueden recibir algunos o todos los nodos.
-
Trama de información remota: Puede ser utilizada por un nodo para
solicitar la transmisión de una trama de datos con la información
asociada a un identificador dado. El nodo que disponga de la
información definida por el identificador la transmitirá en una trama
de datos.
-
Trama de error: Se generan cuando algún nodo detecta algún error
definido.
-
Trama de sobrecarga: Se generan cuando algún nodo necesita más
tiempo para procesar los mensajes recibidos.
-
Espaciado entre tramas: Las tramas de datos (y de interrogación
remota) se separan entre sí por una secuencia predefinida que se
denomina espaciado inter-trama.
-
Bus en reposo: En los intervalos de inactividad se mantiene
constantemente el nivel recesivo del bus.
En un bus CAN los nodos transmiten la información espontáneamente con
tramas de datos, bien sea por un proceso cíclico o activado ante eventos en el
nodo. La trama de interrogación remota sólo se suele utilizar para detección de
presencia de nodos o para puesta al día de información en un nodo recién
incorporado a la red. Los mensajes pueden entrar en colisión en el bus, el de
identificador de mayor prioridad sobrevivirá y los demás son retransmitidos lo
antes posible.
24
2.4.2. Trama de datos
Es la utilizada por un nodo normalmente para poner información en el bus.
Puede incluir entre 0 y 8 bytes de información útil.
Los mensajes de datos consisten en celdas que envían datos y añaden
información definida por las especificaciones CAN:
-
Inicio de trama (SOF): El inicio de trama es una celda de un sólo bit
siempre dominante que indica el inicio del mensaje, sirve para la
sincronización con otros nodos.
-
Celda de Arbitraje (Arbitration Field): Es la celda que concede
prioridad a unos mensajes o a otros:
En formato estándar tendrá 11 bits seguidos del bit RTR (Remote
Transmisión Request) que en este caso será dominante.
25
En formato extendido serán 11 bits de identificador base y 18 de
extendido. El bit SRR substituye al RTR y será recesivo.
NOTA: La trama en formato estándar prevalece sobre la extendida
-
Celda de control (Control Field): El campo de control está formado
por dos bits reservados para uso futuro y cuatro bits adicionales que
indican el número de bytes de datos. En realidad el primero de estos
bits (IDE) se utiliza para indicar si la trama es de CAN Estándar (IDE
dominante) o Extendido (IDE recesivo). El segundo bit (RB0) es
siempre recesivo. Los cuatro bits de código de longitud (DLC) indican
en binario el número de bytes de datos en el mensaje (0 a 8)
-
Celda de Datos (Data Field): Es el campo de datos de 0 a 8 bytes.
-
CRC: Código de redundancia cíclica: Tras comprobar este código se
podrá comprobar si se han producido errores.
-
Celda de reconocimiento (ACK): es un campo de 2 bits que indica si
el mensaje ha sido recibido correctamente. El nodo transmisor pone
este bit como recesivo y cualquier nodo que reciba el mensaje lo
pone como dominante para indicar que el mensaje ha sido recibido.
-
Fin de trama (EOF): Consiste en 7 bits recesivos sucesivos e indica
el final de la trama.
-
Espaciado entre tramas (IFS): Consta de un mínimo de 3 bits
recesivos.
26
2.4.3 Trama remota (Remote Frame)
Los nodos tienen habilidad para requerir información a otros nodos. Un nodo
pide una información a los otros y el nodo que tiene dicha información envía
una comunicación con la respuesta que puede ser recibida además por otros
nodos si están interesados.
Un mensaje de petición remota tiene la siguiente forma:
En este tipo de mensajes se envía una trama con el identificador del nodo
requerido, a diferencia con los mensajes de datos, el bit RTR toma valor
recesivo y no hay campo de datos.
En caso de que se envíe un mensaje de datos y de petición remota con el
mismo identificador, el de datos ganará el acceso al bus puesto que el RTR
lleva valor dominante.
27
2.4.4. Trama de error
Las tramas de error son generadas por cualquier nodo que detecta un error.
Consiste en dos campos: Indicador de error ("Error Flag") y Delimitador de
error(“Error Delimeter”).
El delimitador de error consta de 8 bits recesivos consecutivos y permite a los
nodos reiniciar la comunicación limpiamente tras el error.
El Indicador de error es distinto según el estado de error del nodo que detecta
el error:
Si un nodo en estado de error "Activo" detecta un error en el bus interrumpe la
comunicación del mensaje en proceso generando un "Indicador de error activo"
que consiste en una secuencia de 6 bits dominantes sucesivos. Esta secuencia
rompe la regla de relleno de bits y provocará la generación de tramas de error
en otros nodos. Por tanto el indicador de error puede extenderse entre 6 y 12
bits dominantes sucesivos. Finalmente se recibe el campo de delimitación de
error formado por los 8 bits recesivos. Entonces la comunicación se reinicia y el
nodo que había sido interrumpido reintenta la transmisión del mensaje.
Si un nodo en estado de error "Pasivo" detecta un error, el nodo transmite un
"Indicador de error pasivo" seguido, de nuevo, por el campo delimitador de
error. El indicador de error de tipo pasivo consiste en 6 bits recesivos seguidos
y, por tanto, la trama de error para un nodo pasivo es una secuencia de 14 bits
recesivos. De aquí se deduce que la transmisión de una trama de error de tipo
pasivo no afectará a ningún nodo en la red, excepto cuando el error es
detectado por el propio nodo que está transmitiendo. En ese caso los demás
nodos detectarán una violación de las reglas de relleno y transmitirán a su vez
tramas de error.
Tras señalar un error por medio de la trama de error apropiada cada nodo
transmite bits recesivos hasta que recibe un bit también recesivo, luego
transmite 7 bits recesivos consecutivos antes de finalizar el tratamiento de
error.
28
La regla de relleno de bits que aparece líneas superiores, consiste en que cada
cinco bits de igual valor se introduce uno de valor inverso tal y como se ve en la
figura siguiente:
Otro método para la detección de errores es el chequeo de la trama:
El campo CRC contiene información adicional a la trama, éste se calcula con
un polinomio generador de igual manera en el receptor y en el emisor. Esto
permite detectar errores aleatorios en hasta 5 bits o una secuencia seguida de
15 bits corruptos.
El campo ACK, en el caso del emisor será recesivo y el receptor deberá
sobrescribirlo como dominante y el primero comprobará, mediante la
monitorización, que el mensaje ha sido escuchado. Si no sucede así, la trama
se considerará corrupta.
29
2.4.5. Trama de sobrecarga
Una trama de sobrecarga tiene el mismo formato que una trama de error activo.
Sin embargo, la trama de sobrecarga sólo puede generarse durante el espacio
entre tramas. De esta forma se diferencia de una trama de error, que sólo
puede ser transmitida durante la transmisión de un mensaje. La trama de
sobrecarga consta de dos campos, el Indicador de Sobrecarga, y el delimitador.
El indicador de sobrecarga consta de 6 bits dominantes que pueden ser
seguidos por los generados por otros nodos, dando lugar a un máximo de 12
bits dominantes. El delimitador es de 8 bits recesivos.
Una trama de sobrecarga puede ser generada por cualquier nodo que debido a
sus condiciones internas no está en condiciones de iniciar la recepción de un
nuevo mensaje. De esta forma retrasa el inicio de transmisión de un nuevo
mensaje. Un nodo puede generar como máximo 2 tramas de sobrecarga
consecutivas para retrasar un mensaje. Otra razón para iniciar la transmisión
de una trama de sobrecarga es la detección por cualquier nodo de un bit
dominante en los 3 bits de "intermission". Por todo ello una trama de
sobrecarga de 5 generada por un nodo dará normalmente lugar a la generación
de tramas de sobrecarga por los demás nodos dando lugar, como se ha
indicado, a un máximo de 12 bits dominantes de indicador de sobrecarga.
2.4.6. Espacio entre tramas
El espacio entre tramas separa una trama (de cualquier tipo) de la siguiente
trama de datos o interrogación remota. El espacio entre tramas ha de constar
de, al menos, 3 bits recesivos. Esta secuencia de bits se denomina
"íntermission". Una vez transcurrida esta secuencia un nodo en estado de error
activo puede iniciar una nueva transmisión o el bus permanecerá en reposo.
Para un nodo en estado error pasivo la situación es diferente, deberá espera
una secuencia adicional de 8 bits recesivos antes de poder iniciar una
transmisión. De esta forma se asegura una ventaja en inicio de transmisión a
los nodos en estado activo frente a los nodos en estado pasivo.
30
2.5 Acceso múltiple y arbitraje de acceso al bus
Unas de las características que distingue a CAN con respecto a otras normas,
es su técnica de acceso al medio denominada como CSMA/CD+CR o "Carrier
Sense, Multiple Access/Collision Detection + Collision Resolution" (Acceso
Múltiple con detección de portadora, detección de colisión más Resolución de
colisión). Cada nodo debe vigilar el bus en un periodo sin actividad antes de
enviar un mensaje (Carrier Sense) y además, una vez que ocurre el periodo sin
actividad cada nodo tiene la misma oportunidad de enviar un mensaje (Multiple
Access). En caso de que dos nodos comiencen a transmitir al unísono se
detectará la colisión.
El método de acceso al medio utilizado en bus CAN añade una característica
adicional: la resolución de colisión. En la técnica CSMA/CD utilizada en redes
Ethernet ante colisión de varias tramas, todas se pierden. CAN resuelve la
colisión con la supervivencia de una de las tramas que chocan en el bus.
Además la trama superviviente es aquella a la que se ha identificado como de
mayor prioridad.
La resolución de colisión se basa en una topología eléctrica que aplica una
función lógica determinista a cada bit, que se resuelve con la prioridad del nivel
definido como bit de tipo dominante. Definiendo el bit dominante como
equivalente al valor lógico '0' y bit recesivo al nivel lógico '1' se trata de una
función AND de todos los bits transmitidos simultáneamente. Cada transmisor
escucha continuamente el valor presente en el bus, y se retira cuando ese valor
no coincide con el que dicho transmisor ha forzado. Mientras hay coincidencia
la transmisión continua, finalmente el mensaje con identificador de máxima
prioridad sobrevive. Los demás nodos reintentarán la transmisión lo antes
posible.
Se ha de tener en cuenta que la especificación CAN de Bosh no establece
cómo se ha de traducir cada nivel de bit (dominante o recesivo) a variable
física. Cuando se utiliza par trenzado según ISO 11898 el nivel dominante es
una tensión diferencial positiva en el bus, el nivel recesivo es ausencia de
tensión, o cierto valor negativo, (los transceptores no generan corriente sobre
las resistencias de carga del bus). Esta técnica aporta la combinación de dos
factores muy deseados en aplicaciones industriales distribuidas: la posibilidad
de fijar con determinismo la latencia en la transmisión de mensajes entre nodos
y el funcionamiento en modo multimaestro sin necesidad de gestión del
arbitraje, es decir control de acceso al medio, desde las capas de software de
protocolo. La prioridad queda así determinada por el contenido del mensaje,
en CAN es un campo determinado, el identificador de mensaje, el que
determina la prioridad
31
En un bus único, un identificador de mensaje ha de ser asignado a un solo
nodo concreto, es decir, se ha de evitar que dos nodos puedan iniciar la
transmisión simultanea de mensajes con el mismo identificador y datos
diferentes. El protocolo CAN establece que cada mensaje es único en el
sistema, de manera que por ejemplo, si en un automóvil existe la variable
“presión de aceite”, esta variable ha de ser transmitida por un nodo concreto,
con un identificador concreto, con una longitud fija concreta y coherente con la
codificación de la información en el campo de datos.
En la siguiente figura se ve un ejemplo de arbitraje en un bus CAN.
32
2.6. Detección de Errores
Una de las características mÁs importantes y útiles de CAN es su alta
fiabilidad, incluso en entornos de ruido extremos, el protocolo CAN proporciona
una gran variedad de mecanismos para detectar errores en las tramas. Esta
detección de error es utilizada para retransmitir la trama hasta que sea recibida
con éxito. Otro tipo de error es el de aislamiento, y se produce cuando un
dispositivo no funciona correctamente y un alto por ciento de sus tramas son
erróneas. Este error de aislamiento impide que el mal funcionamiento de un
dispositivo condicione el funcionamiento del resto de nodos implicados en la
red.
2.6.1. Detección de errores
En el momento en que un dispositivo detecta un error en una trama, este
dispositivo transmite una secuencia especial de bits, “el error flag”.Cuando el
dispositivo que ha transmitido la trama errónea detecta el error flan, transmite la
trama de nuevo. Los dispositivos CAN detectan los errores siguientes:
-
Error de bit: Durante la transmisión de una trama, el nodo que
transmite monitoriza el bus. Cualquier bit que reciba con polaridad
inversa a la que ha transmitido se considera un error de bit, excepto
cuando se recibe durante el campo de arbitraje o en el bit de
reconocimiento. Además, no se considera error de bit la detección de
bit dominante por un nodo en estado de error pasivo que retransmite
una trama de error pasivo.
-
Error de relleno (Stuff Error): Se considera error de relleno la
detección de 6 bits consecutivos del mismo signo, en cualquier
campo que siga la técnica de relleno de bits, donde por cada 5 bits
iguales se añade uno diferente.
-
Error de CRC: Se produce cuando el calculo de CRC realizado por
un receptor no coincide con el recibido en la trama. El campo CRC
(Cyclic Redundant Code) contiene 15 bits y una distancia de
Hamming de 6, lo que asegura la detección de 5 bits erróneos por
mensaje. Estas medidas sirven para detectar errores de transmisión
debido a posible incidencias en el medio físico como por ejemplo el
ruido.
-
Error de forma (Form Error): Se produce cuando un campo de
formato fijo se recibe alterado como bit.
-
Error de reconocimiento (Acknowledgement Error): Se produce
cuando ningún nodo cambia a dominante el bit de reconocimiento.
33
Si un nodo advierte alguno de los fallos mencionados, iniciará la transmisión de
una trama de error. El protocolo CAN especifica diversos fallos en la línea física
de comunicación, como por ejemplo línea desconectada, problemas con la
terminación de los cables o líneas cortocircuitadas. Sin embargo, no
especificará como reaccionar en caso de que se produzca alguno de estos
errores.
2.6.2. Aislamiento de nodos defectuosos
Para evitar que un nodo en problemas condicione el funcionamiento del resto
de la red, se han incorporado a la especificación CAN medidas de aislamiento
de nodos defectuosos que son gestionadas por los controladores. Un nodo
pude encontrarse en uno de los tres estados siguientes en relación a la gestión
de errores:
-
Error Activo (Error Active): Es el estado normal de un nodo. Participa
en la comunicación y en caso de detección de error envía una trama
de error activa
-
Error pasivo (Error Passive): Un nodo en estado de error pasivo
participa en la comunicación, sin embargo ha de esperar una
secuencia adicional de bits recesivos antes de transmitir y sólo puede
señalar errores con una trama de error pasiva.
-
Anulado (Bus Off): En este estado, deshabilitará su transceptor y no
participará en la comunicación.
La evolución entre estos estados se basa en dos contadores incluidos en el
controlador de comunicaciones. Contador de errores de transmisión (TEC) y
Contador de errores de recepción (REC).
Evolución entre estados de error.
34
2.7. Especificaciones
CAN tiene dos formatos diferentes para transmitir datos: el formato de trama
estándar (Standard Frame), según la especificación CAN 2.0A y, el formato de
trama extendida (Extended Frame) según la especificación CAN 2.0B. La
principal diferencia entre ambos es la longitud del identificador del mensaje
(ID), que en el caso de la trama estándar es de 11 bits (2032 identificadores, ya
que los 16 bits identificadores de menor prioridad están reservados) y en el
caso de la extendida es de 29 bits (mas de 536 millones de identificadores):
-
Controladores 2.0A: únicamente transmiten y reciben mensajes en
formato estándar. Si el formato es extendido se producirá un error.
-
Controladores 2.0B pasivos: únicamente transmiten y reciben
mensajes en formato estándar, pero admiten la recepción de
mensajes en formato extendido, aunque los ignora posteriormente.
-
Controladores 2.0B activos: transmiten y reciben mensajes en ambos
formatos.
2.8. Implementaciones
Existen tres tipos de arquitecturas en microcontroladores: Stand-Alone CAN
controller, Integrated CAN Controller y Single-Chip CAN Node.
•
Stand-Alone CAN Controller
Es la arquitectura más simple, para llevar a cabo una comunicación en una red
CAN será necesario:
1. Un microcontrolador como puede ser el 16F877, con el que se ha venido
trabajando a lo largo de todo este proyecto.
2. Un controlador CAN que introduzca el protocolo CAN, filtro de mensajes,… y
todo el interface necesario para las comunicaciones. Un ejemplo de controlador
CAN es el MCP2510 cuya DATA SHEET se puede encontrar en la página web
de microchip.
3. Un transceiver CAN, esto es, un transmisor/receptor que puede ser por
ejemplo el MCP2551 desarrollado por microchip.
35
Así pues, si de alguna manera se pretende trabajar en una red CAN con una
placa de pruebas, en un principio no sería factible a no ser que de alguna
manera se le acoplasen el controlador y el transceptor CAN correspondiente.
Pero Microchip ha creado una placa de pruebas específica para este tipo de
comunicaciones, que desarrolla además este tipo de arquitectura y que se
puede conseguir también a través de la página web de microchip.
•
Integrated CAN Controller
Este tipo de arquitectura consiste en un microcontrolador que incluya, no sólo
sus características propias sino además un módulo CAN con las características
de un microcontrolador CAN. El transceiver se sitúa de manera separada. Este
es el caso de nuestro microcontrolador dSPIC30F4013. El módulo del
transceptor actúa como un controlador de línea, balanceando la señal, esto es,
adecuando los niveles de tensión de esta al exterior.
36
•
Single-chip CAN Node
Se trata de un chip que incluye en su interior los tres elementos necesarios
para llevar a cabo las comunicaciones en un entorno CAN.
37
2. CAN DEL MICRO
dsPIC30F4013
38
3.1. Características básicas
Se trata de una interfaz serie, utilizada para la comunicación con otros módulos
CAN u otros dispositivos del propio microcontrolador.
El módulo está formado por un ‘motor de protocolo’ (protocol engine) y por un
control y almacenamiento de los mensajes. El motor de protocolo CAN maneja
todas las funciones encargadas de recibir y transmitir mensajes a través del
bus. El estado y los errores de la transmisión pueden consultarse leyendo en
los registros apropiados. Además, como ya sabemos, cualquier mensaje
detectado en el bus es sometido a un control de errores y después es filtrado
para comprobar si debería ser recibido y almacenado en uno de los registros
de recepción, o debería por lo contrario ser rechazado.
Básicamente las características técnicas del módulo son las siguientes:
•
Implementa el protocolo ‘CAN 2.0 A/B’ tal y como lo define Bosch, es
decir, soporta CAN 1.2, CAN 2.0A, CAN 2.0B Pasivo y CAN 2.0B Activo.
•
Soporta tramas de datos estándar y extendidas.
•
De 0 a 8 bytes de longitud de datos.
•
Velocidad de transferencia de datos programable hasta 1 Mbit/segundo.
•
Admite tramas remotas.
•
Receptor de doble búfer, con dos bufers de almacenamiento de
mensajes con prioridad recibidos (cada búfer puede contener hasta 8
bytes de datos).
•
6 ‘filtros de aceptación completa’ (full acceptance filter), tanto para
mensajes con identificador estándar como extendido. De ellos, 2 están
asociados con el búfer de recepción de prioridad alta y 4 lo están
asociados con el búfer de recepción de prioridad baja.
•
2 ‘máscaras de filtro de aceptación completa’ (full acceptance filter
masks), cada una de ellas asociada a los bufers de recepción de alta o
de baja prioridad.
•
3 bufers de transmisión con asignación de prioridades específicas y
capacidad de aborto (cada búfer puede contener hasta 8 bytes de datos)
•
Función de ‘despertador’ (wake-up) programable con filtros paso-bajo
integrados.
•
Modo Loopback programable con operación de ‘auto-test’ (self-test).
39
•
Capacidad de señalización a través de interrupciones por parte de todos
los receptores y transmisores de estados de error CAN.
•
Reloj fuente (clock source) programable.
•
Enlace programable al módulo de captura de entrada (IC2, tanto para
CAN1 como para CAN2) para la función “time-stamping” (marcas de
tiempo) y sincronización de red.
•
2 modos de baja potencia: Sleep (dormido) e Idle (parado).
40
3.2. Transceptor (transceiver)
Como ya hemos visto anteriormente, dsPIC30F4013 implementa un controlador
CAN integrado, y en este tipo de implementaciones el transceptor (transceiver)
no está dentro del propio microcontrolador.
En definitiva, para poder trabajar con él deberemos conectar uno de estos
transceptores al microcontrolador.
A pesar de que los transceptores pueden funcionar a diferentes tensiones,
tendremos que elegir uno que pueda funcionar a 3.3 voltios, que es la tensión
con la que vamos a alimentar al microcontrolador a la hora de utilizarlo.
Ejemplo de Transceptor CAN de alta velocidad: MCP2551
Aunque existen un gran número en el mercado, hemos escogido un modelo
compatible para explicar como serían las conexiones y una breve explicación
de su funcionamiento.
Este transceptor puede direccionar
una carga mínima de 45 Ohms,
permitiendo conectarse a un máximo
de 112 nodos.
La entrada del transceptor, RXD,
proporciona el diferencial de tensión
entre CANH y CANL.
El pin Rs permite elegir entre 3
modos de funcionamiento:
- High Speed mode:
Se consigue conectando el pin Rs a Vdd.
- Slope Control::
Reduce enormemente las emisiones electromagnéticas disminuyendo los
tiempos de subida y de caída de CANH y CANL. Este control se logra mediante
una resistencia entre Rs y Ground (masa). La tasa de ralentización es
proporcional a la salida actual en Rs.
- Standby mode:
Se consigue poniendo a nivel alto la patilla Rs. En este modo, el transmisor
está apagado, y el receptor funciona ralentizado, es decir, el pin del receptor
RXD seguirá operativo, pero de forma más lenta.
41
La conexión física sería a través de los pines C1RX (recepción CAN del micro),
C1TX (transmisión CAN del micro) del microcontrolador, con los pines RXD y
TXD del transceptor. Recordar que la función del transceptor es la de adecuar
la señal de entrada del bus a la del sistema. Esta entrada de señal del bus se
efectúa a través de los patillas CANH y CANL del transceptor.
Aquí vemos la conexión entre el micro y el transceptor, representado esta vez
por un diagrama de bloques:
Encapsulado del microcontrolador dsPIC30F4013
Diagrama de bloques del transceptor
42
3.3. Modos de funcionamiento
El módulo puede trabajar en uno de entre varios modos de funcionamiento,
previamente escogido por el usuario entre:
-
Modo de inicialización (Initialization mode)
Modo deshabilitado (Disable mode)
Modo de funcionamiento normal (Normal operation mode)
Modo de solo escucha (Listen only mode)
Modo en bucle (Loopback mode)
Modo de reconocimiento de errores (Error recognition mode)
Los modos se solicitan poniendo los bits del registro REQOP<2:0>
(CiCTRL<10:8>), excepto el modo de reconocimiento de errores que se
selecciona a través de los bits RXM<1:0> (CiRXnCON<6:5>, donde n=0 o n=1
representan un búfer de recepción en particular). La entrada en un modo se
reconoce observando los bits del registro OPMODE<2:0> (CiCTRL<7:5>). El
módulo no cambiará de modo, ni tampoco cambiará los bits OPMODE mientras
el cambio de modo no sea correcto. Generalmente, para que sea correcto ha
de hacerse durante el tiempo en que el bus está parado (Idle time), es decir,
cuando se envían al menos 11 bits recesivos consecutivos.
Modo de inicialización (Initialization mode)
En este modo, el módulo no puede transmitir ni recibir datos. Al seleccionarlo,
los contadores de error se ponen a 0 y las ‘banderas de interrupción’ (interrupt
flags) permanecen inalterables. A la hora de programar, desde él tendremos
acceso a ciertos registros de configuración a los cuales no se puede acceder
desde ningún otro modo. Además, el módulo nos protegerá de violaciones
accidentales del protocolo CAN que podamos causar durante la programación.
Para poder acceder al modo de configuración (Configuration mode) no se
puede estar en mitad de una transmisión; es por ello que ninguno de los
registros que controlan la configuración del módulo puede ser modificado
mientras el módulo esté conectado. El susodicho modo de configuración ejerce
de cerrojo para proteger los siguientes registros:
-
Registros de control del módulo (Module control registers)
Registros de tasa (velocidad de transmisión) en baudios (Baud rate
registers) y registros de configuración de interrupciones (Interrupt
configuration registers)
Registros de temporización del bus (Bus timing registers)
Registros identificadores de los filtros de aceptación (Identifier
acceptance filter registers)
Registros identificadores de las máscaras de aceptación (Identifier
acceptance mask registers).
43
Modo deshabilitado (Disable mode)
En este modo, el módulo tampoco transmite ni recibe datos.
Si hay actividad en el bus, el módulo pondrá a 1 los bits del registro WAKIF,
mientras que las interrupciones sin ejecutar quedaran pendientes y los
contadores de error conservaran su valor.
Si los bits REQOP<2:0> (CiCTRL<10:8>) = 001, el módulo entrará en el modo
deshabilitado. Si en ese momento el módulo está activo, entonces esperará
hasta que le lleguen 11 bits recesivos desde el bus, los cuales detectará e
interpretará como a que el bus está sin utilizar (Idle bus); después aceptará el
comando de módulo deshabilitado (module disable command). Cuando los bits
OPMODE<2:0> (CiCTRL<7:5>) = 001, el módulo habrá entrado
satisfactoriamente al modo. Los pins de entrada/salida (I/O) volverán a su
función normal cuando el módulo esté en el modo de módulo inutilizado
(Module Disable mode).
El módulo puede ser programado para aplicar un filtro paso-bajo a la línea de
entrada CiRX, mientras el módulo o la CPU estén en modo dormido (Sleep
mode). El bit WAKFIL (CiCFG2<14>) es el que activa o desactiva este filtro.
NOTA:
Si el módulo va a trabajar en un modo de funcionamiento particular y es
solicitada una transmisión inmediatamente después de que el módulo CAN se
haya colocado en ese modo de funcionamiento, esperará 11 bits recesivos
consecutivos en el bus antes de empezar la transmisión. Si el usuario decide
cambiar al modo deshabilitado (disable mode) dentro del periodo de esos 11
bits recesivos, la transmisión será cancelada y se colocará el bit TXABT y será
borrado el bit TXREQ.
Modo de funcionamiento normal (Normal operation mode)
Para seleccionar el modo de funcionamiento normal, debemos poner los bits
REQOP<2:0> = 000. Al entrar en este modo, el módulo se activa y los pins de
entrada/salida (I/O) asumen las funciones del bus CAN, es decir, el módulo
transmitirá y recibirá mensajes del bus a través de los pins CxTX y CxRX.
Modo de solo escucha (Listen only mode)
Cuando activamos este modo, el módulo está pasivo. Los bufers de
transmisión funcionan como puertos de entrada/salida (I/O), y los pins
receptores por su parte, continúan como entradas. El receptor deja de enviar
‘banderas de error’ (error flags) y ‘señales de reconocimiento’ (acknowledge
signals), y los contadores de error se desactivan. El modo de solo escucha
puede ser utilizado para detectar la tasa (velocidad de transmisión) en baudios
sobre el bus. Parece evidente que para poder utilizarlo, es necesario que haya
al menos dos nodos remotos que se comuniquen el uno con el otro.
44
Modo de escucha de todos los mensajes (Listen all messages mode)
En él, el módulo es fijado para ignorar todos los errores y poder recibir así
cualquier mensaje que se ha enviado a través del bus. Para activarlo, debemos
poner los bits de REQOP<2:0> = ‘111’. En este modo, los datos que están en
el buffer de ensamblado de mensajes (message assembly buffer) hasta que
ocurre un error, son copiados en el búfer de recepción y pueden ser leídos a
través de la interfaz de la CPU.
Modo loopback (Loopback mode)
Cuando el modo loopback se activa, la señal interna de transmisión y la señal
interna de recepción se conectan en el límite del módulo, formando una
especie de bucle cerrado. Los pins de transmisión y de recepción vuelven a sus
funciones de puerto de entrada/salida I/O.
45
3.4. Recepción de mensajes
Bufers de recepción
El módulo del bus CAN tiene 3 bufers de recepción. No obstante, uno de los
bufers de recepción se dedica continuamente a escuchar el bus en espera de
mensajes entrantes. Este búfer se llama ‘Búfer de ensamblado de mensajes’
(Message Assembly Buffer o MAB). Por tanto hay 2 bufers de recepción
visibles, RXB0 y RXB1, que pueden recibir simultáneamente un mensaje
completo desde el motor de protocolo.
Todos los mensajes son montados por el MAB y son transferidos a los bufers
RXBn solo si se encuentran los filtros de criterios de aceptación. Cuando se
recibe un mensaje, la bandera (flag) RXnIF (CiINTF <0> o CiINTF <1>) se pone
a 1. Este bit solo puede ser activado por el modulo cuando se recibe un
mensaje. La CPU pone el bit a cero cuando ha completado el procesado del
mensaje en el búfer. Si el bit RXiIE (CiINTE <0> o CiINTE <1>) está a 1, se
generará una interrupción cuando se reciba un mensaje. Los filtros RXF0 y
RXF1 con la máscara RXM0 están asociados con RXB0. Los filtros RXF2,
RXF3, RXF4 y RXF5 y la máscara RXM1 están asociados con RXB1.
Filtros de aceptación de mensajes
Los filtros y mascaras de aceptación de mensajes se usan para determinar si
un mensaje del búfer de ensamblado de mensajes debe ser cargado en alguno
de los bufers de recepción. Una vez un mensaje válido ha sido recibido por el
MAB, los campos de identificación del mensaje son comparados con los
valores de los filtros. Si hay una coincidencia, ese mensaje será cargado en el
búfer de recepción apropiado.
El filtro de aceptación busca en los mensajes entrantes el bit RXIDE
(CiRXnSID<0>) para determinar como comparar los identificadores. Si el bit
RXIDE esta desactivado, el mensaje es una trama estándar y solo se
comparan los filtros con el bit EXIDE (CiRXFnSID<0>) a cero. Si el bit RXIDE
está puesto a 1, el mensaje es una trama extendida, y solo son comparados los
filtros con el EXIDE a 1. Configurando los bits RXM<1:0> a ‘01’ ó a ‘10’ se
puede borrar el bit EXIDE.
Máscaras de filtro de aceptación de mensajes
Los bits de máscara determinan que bits se han de aplicar en el filtro. Si un bit
de máscara está a cero, entonces este bit será aceptado automáticamente
independientemente del bit de filtro. Hay 2 máscaras de filtro de aceptación
programables, asociadas con los bufers de recepción, una por cada búfer.
46
Sobrecarga de recepción:
Esta condición de sobrecarga se da cuando el MAB ha ensamblado un
mensaje recibido válido, cuando el mensaje es aceptado a través del filtro de
aceptación, y cuando el búfer de recepción asociado con el filtro no ha sido
designado como vacío por el mensaje previo.
El flag de error de sobrecarga, RXnOVR (CiINTF<15> o CiINTF<14>), y el bit
ERRIF (CiINTF<5>) son puestos a 1 y el mensaje del MAB es descartado. Si el
bit DBEN está desactivado, RXB1 y RXB0 operan independientemente.
Cuando esto ocurre, un mensaje dirigido a RXB0 no es desviado a RXB1 si el
RXB0 contiene un mensaje no leído y el RX0OVR se pone a 1.
Si el bit DBEN esta activado, la sobrecarga del RXB0 se trata de forma
diferente. Si se recibe un mensaje válido para RXB0 y el bit RXFUL = 0, el
mensaje para RXB0 se carga en RXB1. No se genera un mensaje de error de
sobrecarga para RXB0. Si se recibe un mensaje valido para RXB0 y el bit
RXFUL = 1, tanto RXB0 como RXB1 están llenos, por lo tanto, el mensaje se
perderá y se generará un mensaje de error de sobrecarga para RXB1.
Errores de recepción
El Modulo CAN puede detectar los siguientes errores de recepción:
- Error de Chequeo de Redundancia Cíclica (CRC)
- Error de Relleno de Bits (Bit Stuffing Error)
- Error de Mensaje Inválido Recibido
Estos errores de recepción no generan una interrupción. Sin embargo, si que
se incrementa el contador de errores de recepción. El bit RXWAR (CiINTF<9>)
indica que el contador de errores de recepción ha alcanzado el límite de
advertencia de la CPU (este límite es 96) y se genera una interrupción.
Interrupciones de recepción
Las Interrupciones de recepción se pueden dividir en 3 grandes grupos, cada
uno de ellos incluye varias condiciones que generan interrupciones:
- Interrupción de recepción: Un mensaje se ha recibido correctamente
y se ha cargado en uno de los bufers de recepción. Esta interrupción
se activa inmediatamente después de recibir el campo Fin de Trama
(EOF). El flag RXnIF indica que buffer de recepción ha causado la
interrupción.
- Interrupción de despertador (Wake-up Interrupt): El módulo CAN se
ha despertado del modo Deshabilitado (Disable) o el dispositivo se
ha despertado del modo Durmiendo (Sleep)
- Interrupción de error de recepción: Una interrupción de error de
recepción se señala en el bit ERRIF. La fuente del error puede ser
determinada comprobando los bits del registro Estatus de
Interrupción CAN, CiINTF.
47
-
Mensaje Inválido Recibido: Si ocurre algún tipo de error durante la
recepción del ultimo mensaje, se indicará un error mediante el bit
IVRIF.
Sobrecarga de Receptor: El bit RXnOVR indica que ha ocurrido un
error de sobrecarga.
Advertencia del Receptor: El bit RXWAR indica que el contador de
errores de recepción (RERRCNT<7:0>) ha alcanzado el límite de
advertencia de 96.
Error de Recepción Pasivo: El bit RXEP indica que el contador de
errores de recepción ha excedido el límite de error pasivo de 127 y el
módulo ha entrado en el estado error pasivo.
3.5. Transmisión de mensajes
Bufers de transmisión:
El módulo CAN tiene 3 bufers de transmisión. Cada uno de los 3 bufers de
transmisión ocupa 14 bytes de datos. Ocho de los bytes son los 8 bytes que
puede ocupar como máximo el mensaje transmitido. Cinco bytes son los
identificadores estándar y extendidos y otra información de control del mensaje.
Prioridad de transmisión del mensaje:
La prioridad de transmisión es una priorización dentro de cada nodo de los
mensajes pendientes de transmitir. Hay 4 niveles de prioridad de transmisión.
Si TXPRI<1:0> (CiTXnCON<1:0>, donde n = 0, 1 o 2 representa el búfer de
transmisión en particular) para un búfer de mensaje en particular se establece a
‘11’, ese búfer tiene la máxima prioridad. Si TXPRI<1:0> para un búfer de
mensaje en particular se establece a ‘10’ o a ‘01’, ese búfer tiene una prioridad
intermedia. Si TXPRI<1:0> para un búfer de mensaje en particular se establece
a ‘00’, ese búfer tiene la mínima prioridad.
Secuencia de transmisión:
Para iniciar la transmisión del mensaje, el bit TXREQ (CiTXnCON<3>) debe
ponerse a 1. El módulo del bus CAN resuelve cualquier conflicto de tiempo
entre el establecimiento del bit TXREQ y el Inicio de Trama (SOF), asegurando
que si la prioridad ha sido cambiada, se ha resuelto correctamente antes de
llegar al SOF. Cuando se pone a 1 TXREQ, los bits del flag TXABT
(CiTXnCON<6>), TXLARB (CiTXnCON<5>) y TXERR (CiTXnCON<4>) son
puestos a 0 automáticamente.
Poner a 1 el bit TXREQ simplemente marca un búfer de mensaje como puesto
en cola para transmisión. Cuando el módulo detecta el bus disponible, empieza
a transmitir el mensaje que tiene mayor prioridad.
48
Si la transmisión se completa satisfactoriamente en el primer intento, el bit
TXREQ se pone a 0 automáticamente y se genera una interrupción si TXIE
había sido activado.
Si la transmisión del mensaje falla, se activa uno de los avisos de condición de
error y el bit TXREQ permanece a 1, indicando que el mensaje está aún
pendiente de transmisión. Si el mensaje encuentra una condición de error
durante el intento de transmisión, el bit TXERR se pone a 1 y puede causar una
interrupción. Si el mensaje pierde arbitraje durante el intento de transmisión, se
pone a 1 el bit TXLARB. No se genera interrupción para indicar la perdida de
arbitraje.
Abortando la transmisión del mensaje:
El sistema también puede abortar el envío de un mensaje poniendo a 0 el bit
TXREQ asociado con cada búfer de mensaje. Poniendo a 1 el bit ABAT
(CiCTRL<12>) se solicita abortar todos los mensajes pendientes. Si el mensaje
aún no ha iniciado la transmisión, o si el mensaje la ha iniciado pero es
interrumpida por pérdida de arbitraje o por un error, se procesa el aborto. El
aborto se indica poniendo a 1 el bit TXABT y la bandera (flag) TXnIF no se
activa automáticamente.
Errores de transmisión
El modulo CAN detecta los siguientes errores de transmisión:
- Error de Ack
- Error de forma
- Error de bit
Estos errores de transmisión no generan necesariamente una interrupción,
pero son indicados por el contador de errores de transmisión, incrementándolo
en uno. Una vez que el contador de errores supera el valor de 96, los bits
ERRIF (CiINTF<5>) y TXWAR (CiINTF<10>) son puestos a 1. Además, se
genera una interrupción y se pone a 1 el bit TXWAR del registro de banderas
de error.
Interrupciones de transmisión
Las Interrupciones de transmisión se pueden dividir en 2 grandes grupos, cada
uno de estos incluye varias condiciones que generan interrupciones:
-
-
Interrupciones de transmisión: Al menos uno de los tres bufers de
transmisión está vacío y puede ser cargado para programar una
transmisión de mensaje. Los flags TXnIF indican que búfer de
transmisión está disponible y ha sido el causante de la interrupción.
Interrupciones de errores de transmisión: Una interrupción error de
transmisión se indica con el flag ERRIF. La fuente del error se puede
determinar comprobando los flags de error en el registro de Estatus
49
-
de Interrupción del CAN, CiINTF. Los flags de este registro están
relacionados con los errores de transmisión y de recepción.
Interrupción de Advertencia del Transmisor: El bit TXWAR indica que
el contador de errores de transmisión ha alcanzado el límite de
advertencia de la CPU (96).
Error Pasivo del Transmisor: El bit TXEP (CiINTF<12>) indica que el
contador de errores de transmisión ha superado el límite de error
pasivo de 127 y el modulo ha entrado en el estado de error pasivo.
Bus Off: El bit TXBO (CiINTF<13>) indica que el contador de errores
de transmisión ha superado 255 y el módulo ha entrado en el estado
de bus off.
50
3.6. Temporización y sincronización de bits
3.6.1. Temporización de bits
Las señales eléctricas del bus sufren las alteraciones propias de la distorsión
que se produce, tanto por las características físicas de la línea, los retardos de
propagación, y los retardos producidos en los propios controladores, como por
las posibles fuentes externas de interferencia electromagnética.
Por otra parte, cada controlador CAN depende, normalmente, de un oscilador
distinto, lo que provoca diferencias de frecuencia que pueden dar lugar a
desfases en el muestreo de tramas de los distintos nodos. Por ello, los
controladores siguen un proceso de muestreo y resincronización orientado a
evitar los desajustes debidos a estas circunstancias adversas.
Estos desajustes se manifiestan especialmente en el arbitraje de mensajes,
cuando varios nodos transmiten de forma simultánea, ya que es prácticamente
imposible que esten completamente sincronizados; y además la frecuencia del
oscilador de ambos puede ser ligeramente distinta. Los receptores que se han
sincronizado con el primer flanco de bajada detectado, deberán ir
resincronizándose sucesivamente a los flancos producidos por el nodo que
acabe transmitiendo.
CAN utiliza señalización asíncrona y un tipo de codificación NRZ, en la que
normalmente 0V representa un ‘0’ lógico, y 5V representa un ‘1’ lógico. Es
necesaria, por tanto, una operación de muestreo por parte de los receptores,
que se han de resincronizar periódicamente. Además, la tasa de transmisión
(desde menos de 1 kbps hasta 1 Mbps) también es un factor determinante.
Todos estos parámetros pueden programarse individualmente y ser ejecutados
por el reloj lógico de CAN (Bit Timing Logic).
Para que el controlador, que es un sistema digital síncrono con una frecuencia
de reloj generada por un oscilador (generalmente un oscilador de cuarzo),
pueda muestrear la señal asíncrona recibida con seguridad y precisión ha de
utilizar una frecuencia de muestreo superior a la de la señal transmitida.
Por otra parte, el controlador ha de utilizar una frecuencia de reloj que sea
múltiplo de la ‘frecuencia nominal de bit’ (número de bis transmitidos en
ausencia de resincronizaciones por un transmisor ideal). Esta frecuencia se
obtiene como cociente de la frecuencia del oscilador.
La velocidad de comunicación a la que queda configurado el controlador, para
un oscilador de cierta frecuencia, queda definida por el valor del ‘divisor de
frecuencia’ (BRP), también configurable, y por el número de ‘TQ’ por bit.
TQ (quantum de tiempo) es una unidad de tiempo fija, derivada del periodo del
oscilador.
51
Debemos, por tanto, cambiar de escala para bajar la frecuencia del reloj, y así
poder adecuar el sistema a nuestras necesidades. Este valor para nuestro
dsPIC30F4013, se define en su correspondiente manual como ‘ajuste de
preescalado’ (prescaler setting) y se obtiene a partir de la siguiente ecuación:
TQ =
2·( BRP < 5 : 0 > +1)
FCAN
donde FCAN es FCY (si el bit CANKS está puesto a 1) o 4·FCY (si CANKS
está puesto a 0). Además, FCAN no debe sobrepasar nunca los 30 MHz, es
decir que si CANKS = 0, FCY no debe exceder de 7.5 MHz, ya que como
hemos dicho FCAN=4·FCY en este caso.
Además, para asegurar la funcionalidad de la red, se incluye en una posición
concreta del ‘tiempo de bit’ (del cual hablaremos más adelante), un ‘punto de
muestreo’ (sample point en inglés). Este es el punto exacto en el que el nivel de
bus es leído e interpretado como el valor de ese respectivo bit.
En algunos microcontroladores, entre los que se incluye dsPIC30F4013, si la
temporización de bits se retrasa y contiene muchos TQ, es posible realizar
también, un muestreo múltiple sobre el bus. En este caso, las muestras para
realizar el cálculo pueden ser tomadas en el punto de muestreo o en dos
posiciones anteriores a este con una distancia de TQ/2. Además, el módulo
CAN permite al usuario elegir entre muestrear tres veces en el mismo punto o
una vez en cada uno de los tres puntos, según pongamos a ‘0’ o a ‘1’ el bit
SAM (CiCFG2<6>).
Es decir, en este tipo de muestreo el nivel determinado por el bus corresponde
al resultado por mayoría de tres valores. Para asegurar la validez del cálculo,
este muestreo debe ocupar del 60 al 70 por ciento del tiempo de bit,
dependiendo de los parámetros del sistema.
3.6.2. Resincronización de bits (Resynchronization)
La resincronización consiste en el acortamiento o alargamiento del tiempo de
bit (o número de TQ por bit) para que el punto de muestreo se desplace con
relación al último flanco recesivo-dominante detectado. Esta decisión la toma el
controlador tras detectar el flanco y evaluar el error.
En CAN se siguen dos métodos de sincronización del muestreo con la
secuencia de bits de la trama:
-
Sincronización de trama ("Hard Synchronization"): Es la reinicialización
de la lógica de muestreo de bit que ocurre ante el flanco de bajada (paso
de recesivo a dominante) producido por un bit de inicio de trama.
-
Resincronización o sincronización intra-trama ("Soft Synchronization" o
“Resyncronization): Es un proceso de sincronización que ocurre en cada
flanco de bajada que se produce durante la transmisión de la trama.
52
Puede producir el alargamiento o el acortamiento de los segmentos de
fase de los que hablamos en la siguiente sección.
3.6.3. Parámetros del tiempo de bit nominal
El tiempo de bit nominal se ideó como una división del tiempo en segmentos
separados y no superpuestos. El microcontrolador dsPIC30F4013 define para
el tiempo de bit nominal un mínimo de 8 TQ y un máximo de 25 TQ, mientras
que define el mínimo tiempo de bit nominal como 1 µsegundo, correspondiente
a una tasa máxima (velocidad de transmisión máxima) en bits de 1 MHz.
Su esquema gráfico es el siguiente:
Se puede observar como el punto de muestreo del bit (sample point) se realiza
inmediatamente después del segmento Phase_Seg1 y antes de Phase_Seg2.
Las funciones y los tiempos de cada uno de los segmentos son los siguientes:
-
Segmento de sincronización (Sync_Seg): En este intervalo se espera
que se produzca cualquier cambio de recesivo a dominante en el bus.
Su duración es de 1 TQ.
-
Segmento de propagación (Prop_Seg): Está orientado a la
compensación del retardo de tiempo de la red. Este retardo es la suma
del provocado por la línea y el debido a la electrónica de la interfaz de
los controladores. El segmento puede configurarse como de 1 a 8 TQ de
duración poniendo a 1 los bits PRSEG<2:0> (CiCFG2<2:0>).
-
Segmento de fase 1 (Phase_Seg1): Este segmento está orientado a la
detección y reajuste de desfases entre nodos. Puede configurarse como
de 1 a 8 TQ de duración poniendo a 1 los bits SEG1PH<2:0>
(CiCFG2<5:3>), aunque puede alargarse en operaciones de
resincronización.
53
-
Segmento de fase 2 (Phase_Seg2): Es el encargado de retrasar la
siguiente transición de datos a transmitir. Su valor máximo puede ser
igual al segmento de fase 1 más grande o al tiempo de procesado de la
información (2 TQ). El segmento es programable desde 1TQ hasta 8 TQ
de duración poniendo a 1 los bits SEG2PH<2:0> (CiCFG2<10:8>).
Puede acortarse (nunca menos del tiempo de procesado de la
información) en las operaciones de resincronización.
Un requisito imprescindible que deben cumplir los segmentos de fase para el
ajuste de sus respectivas longitudes es el siguiente:
Prop Seg + Phase 1 Seg >= Phase 2 Seg
Y ya por último, en cuanto al cambio de longitudes por la resincronización, se
define un parámetro adicional: el ‘salto de resincronización’ (Sjw o
Resynchronization jump width) que establece el valor del salto máximo que se
pueda llegar a efectuar como producto de la resincronización. En
dsPIC30F4013 se especifica a través de los bits del registro SJW<1:0>
(CiCFG1<7:6>), con valores de entre 1 y 4 TQ, pero no mayores que
Phase_Seg2, ya que durante el proceso, el valor de este parámetro o bien será
añadido al segmento de fase 1 o bien recortado del segmento de fase 2. Es
decir, ha de cumplirse que:
Phase2 Seg > Synchronization Jump Width
54
3.7. Programación
3.7.1. MPLAB
MPLAB es un software que junto con un emulador y un programador de los
múltiples que existen en el mercado, forman un conjunto de herramientas de
desarrollo muy completo para el trabajo y/o el diseño con los
microcontroladores PIC y dsPIC desarrollados y fabricados por la empresa
“Arizona Microchip Technology” (AMT). MPLAB incorpora todas las utilidades
necesarias para la realización de cualquier proyecto y, si no se dispone de un
emulador, el programa permite editar el archivo fuente en lenguaje
ensamblador de nuestro proyecto, además de ensamblarlo y simularlo en
pantalla, pudiendo ejecutarlo posteriormente en modo paso a paso y ver como
evolucionarían de forma real tanto sus registros internos, la memoria RAM y/o
EEPROM de usuario como la memoria de programa, según se fueran
ejecutando las instrucciones. Además el entorno que se utiliza es el mismo que
si se estuviera utilizando un emulador.
Nosotros, durante el desarrollo de la asignatura, utilizaremos la versión ‘MpLab
30 v2 student edition’ (edición gratuita que podemos adquirir en la página oficial
de Microchip) la cual presenta algunas limitaciones respecto al software original
pero que para nuestro trabajo es más que suficiente ya que permite simular
directamente sobre la placa de pruebas.
Como ya hemos comentado, la utilización de MpLab requiere un emulador de
lenguajes de alto nivel, para evitar la utilización del lenguaje de ensamblador
que incluye el mismo MpLab. Nosotros utilizaremos el compilador c30.
Para conectar la placa con el ordenador
y poder simular nuestros programas,
utilizaremos el hardware y esquema de
conexiones de la fotografía.
55
3.7.2. Funciones
Esta sección contiene una lista de las funciones para CAN y un ejemplo de uso
de las funciones. El uso de las funciones, nos ahorra tener que conocer en
profundidad las estructuras del módulo CAN, ya que a través de ellas podemos
realizar acciones sin tener que cambiar manualmente los valores de los bits de
ciertos registros. Además, pueden ser puestas en práctica como macros.
Las siguientes funciones definen a toda la familia dsPIC30f, en nuestro caso el
dsPIC30F4013 solamente tiene un CAN.
•
Funciones individuales
CAN1AbortAll
CAN2AbortAll
Descripción:
Include:
Prototipo:
Argumentos:
Valores de retorno:
Comentarios:
Archivo de origen:
Ejemplo de código:
CAN1GetRXErrorCount
CAN2GetRXErrorCount
Descripción:
Include:
Prototipo:
Argumentos:
Valores de retorno:
Comentarios:
Archivo de origen:
Ejemplo de código:
Esta función aborta inicialmente todas las
transmisiones pendientes.
can.h
void CAN1AbortAll(void);
void CAN2AbortAll(void);
Ninguno
Ninguno
CAN1AbortAll.c
CAN2AbortAll.c
CAN1AbortAll();
Esta función devuelve la cuenta del valor del
error al recibir.
can.h
Unsigned char CAN1GetRXErrorCount(void);
Unsigned char CAN2GetRXErrorCount(void);
Ninguno
El contenido de CIRERRCNT, que son 8 bits
Esta función devuelve el contenido de
CIRERRCNT (el bit más bajo del registro CiEC)
que indica la cuenta de errores recibidos.
CAN1GetRXErrorCount.c
CAN2GetRXErrorCount.c
unsigned char rx_error_count;
rx_error_count = CAN1GetRXErrorCount();
56
CAN1GetTXErrorCount
CAN2GetTXErrorCount
Descripción:
Include:
Prototipo:
Argumentos:
Valores de retorno:
Comentarios:
Archivo de origen:
Ejemplo de código:
CAN1sBusOff
CAN2sBusOff
Descripción:
Include:
Prototipo:
Argumentos:
Valores de retorno:
Comentarios:
Archivo de origen:
Ejemplo de código:
CAN1sRXReady
CAN2sRXReady
Descripción:
Include:
Prototipo:
Argumentos:
Valores de retorno:
Esta función devuelve la cuenta del valor del
error al enviar.
can.h
Unsigned char CAN1GetTXErrorCount(void);
Unsigned char CAN2GetTXErrorCount(void);
Ninguno
El contenido de CIRERRCNT, que son 8 bits
Esta función devuelve el contenido de
CIRERRCNT (el bit superior del registro CiEC)
que indica la cuenta de errores al transmitir.
CAN1GetTXErrorCount.c
CAN2GetTXErrorCount.c
unsigned char tx_error_count;
tx_error_count = CAN1GetTXErrorCount();
Esta función determina cuando el nodo CAN
está en modo Bus Off.
can.h
Char CAN1IsBusOff(void);
Char CAN2IsBusOff(void);
Ninguno
Si el valor de TXBO es 1, ese 1 es devuelto,
indicando que el bus está siendo cambiado a off
debido a un error de transmisión.
Si el valor de TXBO es 0, ese 0 es devuelto,
indicando que el bus no será cambiado a off.
Esta función devuelve el estado del bit TXBO
del registro CilNTF.
CAN1IsBusOff.c
CAN2IsBusOff.c
While (CAN1IsBusOff());
Esta función devuelve el estado del búfer de
recepción.
can.h
Char CAN1IsRXReady(char);
Char CAN2IsRXReady(char);
Buffno: el valor de buffno indica cual es el
estado requerido para el bufer de recepción.
Si RXFUL es 1, esto indica que el buffer de
recepción contiene un mensaje recibido.
Si RXFUL es 0, esto indica que el bufer de
recepción esta abierto para recibir un mensaje
57
Comentarios:
Archivo de origen:
Ejemplo de código:
CAN1sRXPassive
CAN2sRXPassive
Descripción:
Include:
Prototipo:
Argumentos:
Valores de retorno:
Comentarios:
Archivo de origen:
Ejemplo de código:
CAN1sTXPassive
CAN2sTXPassive
Descripción:
Include:
Prototipo:
Argumentos:
Valores de retorno:
Comentarios:
Archivo de origen:
Ejemplo de código:
nuevo.
Esta función devuelve el estado del bit RXFUL
del registro de control de recepción (control
register)
CAN1IsRXReady.c
CAN2IsRXReady.c
char rx_1_status;
rx_1_status = CAN1IsRXReady(1);
Esta función determina si la recepción se
encuentra en estado Error Pasivo.
can.h
char CAN1IsRXPassive(void);
char CAN2IsRXPassive(void);
Ninguno
Si el valor de RXEP es 1, el uno es devuelto,
indicando que el nodo pasivo previsto será un
error en recepción.
Si el valor de RXEP es 0, el cero es devuelto,
indicando que no hay error en el bus.
Esta función devuelve el estado del bit RXEP
del registro CiiNTF.
CAN1IsRXPassive.c
CAN2IsRXPassive.c
char rx_bus_status;
rx_bus_status = CAN1sRXPassive();
Esta función determina si la transmisión se
encuentra en estado Error Pasivo.
can.h
char CAN1IsTXPassive(void);
char CAN2IsTXPassive(void);
Ninguno
Si el valor de TXEP es 1, el uno es devuelto,
indicando error en el bus de transmisión y que el
bus será pasivo.
Si el valor de TXEP es 0, el cero es devuelto,
indicando que no hay error en el bus de
transmisión.
Esta función devuelve el estado del bit TXEP en
el registro CiiNTF.
CAN1IsTXPassive.c
CAN2IsTXPassive.c
char tx_bus_status;
tx_bus_status = CAN1IsTXPassive();
58
CAN1lsTXReady
CAN2lsTXReady
Descripción:
Include:
Prototipo:
Argumentos:
Valores de retorno:
Comentarios:
Archivo de origen:
Ejemplo de código:
CAN1RecieveMessage
CAN2RecieveMessage
Descripción:
Include:
Prototipo:
Argumentos:
Valores de retorno:
Comentarios:
Archivo de origen:
Ejemplo de código:
Esta función devuelve que el estado del
transmisor indica si el nodo CAN esta preparado
para la próxima transmisión.
can.h
Char CAN1IsTXReady(char);
Char CAN2IsTXReady(char);
Buffno: el valor de buffno indica cual es el
estado requerido para el búfer de transmisión.
Si TXREQ es 1, devuelve un 0 indicando que el
búfer de transmisión no esta vacío.
Si TXREQ es 0, devuelve un 1 indicando que el
búfer de transmisión esta vacío, y que el
transmisor esta preparado para la próxima
transmisión.
Esta función devuelve el estado del bit TXREQ
del registro de control de transmisión (control
transmit)
CAN1IsTXReady.c
CAN2IsTXReady.c
char tx_2_status;
tx_2_status = CAN1IsTXReady(2);
Esta función lee el dato del buffer de recepción.
can.h
void CAN1RecieveMessage(unsigned char *
data, unsigned char datalen, char MsgFlag);
void CAN2RecieveMessage(unsigned char *
data, unsigned char datalen, char MsgFlag);
Data: El puntero con la localización donde los
datos recibidos deben ser almacenados.
Datalen: El número de bytes de datos
esperados.
MsFlag: El número de buffer donde el dato es
recibido. Si es 1, el dato de CiRX1B1 a
CiRX1B4 es leído. Si es 0, el dato de CiRX0B1
a CiRX0B4 es leído.
Ninguno
Esta función lee los datos recibidos dentro de la
dirección del puntero por el parámetro de
entrada data.
CAN1RecieveMessage.c
CAN2RecieveMessage.c
Unsigned char*rx_data;
CAN1RecieveMessage(rx_data, 5, 0);
59
CAN1SendMessage
CAN2SendMessage
Descripción:
Include:
Prototipo:
Esta función escribe datos para ser transmitidos
a registros de transmisión, pone la longitud de
los datos e inicia la transmisión.
can.h
void CAN1SendMessage(unsigned int sid,
unsigned long eid, unsigned char *data,
unsigned char datalen, char MsgFlag);
void CAN2SendMessage(unsigned int sid,
unsigned long eid, unsigned char *data,
unsigned char datalen, char MsgFlag);
Argumentos:
sid: El valor de 16 bits para ser escrito en
CiTXnSID.
CAN_TX_SID(x) x es el valor de SID requerido.
Sustituto de respuesta remota
CAN_SUB_REM_TX_REQ
CAN_SUB_NOR_TX_REQ
Mensaje tipo ID
CAN_TX_EID_EN
CAN_TX_EID_DIS
eid: El valor de 32 bits para ser escrito en los
registros CiTXnEID y CiTXnDLC.
CAN_TX_EID(x) x es el valor de EID requerido.
Sustituto de respuesta remota
CAN_REM_TX_REQ
CAN_NOR_TX_REQ
data: El puntero con la localización donde los
datos transmitidos serán almacenados.
datalen: Número de bytes de datos a transmitir.
MsgFlag: El número del búfer (0, 1 o 2) desde
donde los datos serán transmitidos.
Si es 1, los datos se escriben en CiTX1B1 a
CiTX1B4.
Si es 2, los datos se escriben en CiTX2B1 a
CiTX2B4.
Si es 0 (o otro valor), los datos se escriben en
CiTX0B1 a CiTX0B4.
Valores de retorno:
Comentarios:
Ninguno
Esta función escribe el valor identificador en los
registros SID y EID, los datos que serán
transmitidos en el registro TX, pone la longitud
de los datos e inicializa la transmisión por el bit
TXREQ.
CAN1SendMessage.c
CAN2SendMessage.c
CAN1SendMessage((CAN_TX_SID(1920)) &
(CAN_TX_EID_EN) &
Archivo de origen:
Ejemplo de código:
60
(CAN_SUB_NOR_TX_REQ),
(CAN_TX_EID(12344)) &
(CAN_NOR_TX_REQ),
Txdata, datalen, tx_rx_no);
CAN1SetFilter
CAN2SetFilter
Descripción:
Include:
Prototipo:
Esta función pone a 1 los valores (SID y EID)
con filtro de aceptación para el filtro
especificado.
can.h
void CAN1SetFilter(char filter_no, unsigned int
sid,
unsigned long eid);
void CAN2SetFilter(char filter_no, unsigned int
sid,
unsigned long eid);
Argumentos:
filter_no: El filtro (0, 1, 2, 3, 4 o 5) para el cual
los nuevos valores deben ser configurados.
sid: el valor de 16 bits para escribir en los
registros CiRXFnSID.
CAN_FILTER_SID(x) x es valor de SID
requerido.
Tipo de mensaje a recibir
CAN_RX_EID_EN
CAN_RX_EID_DIS
Eid: El valor de 32bits para ser escritos en los
registros CiRXFnEIDH yCiRXFnEIDL.
CAN_FILTER_EID(x) x es el valor de EID
requerido.
Valores de retorno:
Comentarios:
ninguno
Esta función escribe el valor de 16 bits de sid en
el registro CiRXFnSID y el valor de 32 bits en
CiRXFnEIDH y CiRXFnEIDL, registros
correspondientes al filtro especificado por
filter_no. El filtro 0 es tomado como falta.
CAN1SetFilter.c
CAN2SetFilter.c
CAN1SetFilter(1, CAN_FILTER_SID(7) &
CAN_RX_EID_EN, CAN_FILTER_EID(3));
Archivo de origen:
Ejemplo de código:
61
CAN1SetMask
CAN2SetMask
Descripción:
Include:
Prototipo:
Esta función pone a 1 el valor de la máscara de
aceptación (SID y EID) para la máscara
especificada.
can.h
void CAN1SetMask(char mask_no, unsigned int
sid,
unsigned long eid);
void CAN2SetMask(char mask_no, unsigned int
sid,
unsigned long eid);
Argumentos:
mask_no: La máscara (‘0’ or ‘1’) para el cual los
valores de máscara tienen que ser configurados
sid: El valor de 16 bits que se escribirán en el
registro CiRXMnSID.
CAN_MASK_SID(x) x es el valor de SID
requerido.
Match/ignore message type specified in filter
CAN_MATCH_FILTER_TYPE
CAN_IGNORE_FILTER_TYPE
Eid: El valor de 32 bits que serán escritos en los
registros CiRXMnEIDH y CiRXMnEIDL.
CAN_MASK_EID(x) x es el valor de EID
requerido.
Valores de retorno:
Comentarios:
Ninguno
Esta función escribe el valor de 16 bits de sid en
el registro CiRXFnSID y otro valor de 32 bits de
eid en CiRXFnEIDH y CiRXFnEIDL, registros
correspondientes a la máscara especificada por
mask_no. El filtro 0 es tomado como falta.
CAN1SetMask.c
CAN2SetMask.c
CAN1SetMask(1, CAN_MASK_SID(7) &
CAN_MATCH_FILTER_TYPE,
CAN_MASK_EID(3));
Archivo de origen:
Ejemplo de código:
CAN1SetOperationMode
CAN2SetOperationMode
Descripción:
Include:
Prototipo:
Argumentos:
Esta función configura el módulo CAN
can.h
void CAN1SetOperationMode(unsigned int
config);
void CAN2SetOperationMode(unsigned int
config);
Config valor de 16 bits que serán cargados en el
registro CiCTRL , la combinación de la
siguientes definiciones.
62
CAN_IDLE_CON CAN On in Idle mode
CAN_IDLE_STOP CAN Stop in Idle mode
CAN_MASTERCLOCK_1 FCAN is FCY
CAN_MASTERCLOCK_0 FCAN is 4 FCY
Modos de operación de CAN
CAN_REQ_OPERMODE_NOR
CAN_REQ_OPERMODE_DIS
CAN_REQ_OPERMODE_LOOPBK
CAN_REQ_OPERMODE_LISTENONLY
CAN_REQ_OPERMODE_CONFIG
CAN_REQ_OPERMODE_LISTENALL
CAN Capture Enable/Disable
CAN_CAPTURE_EN
CAN_CAPTURE_DIS
Valores de retorno:
Comentarios:
Ninguno
Esta función configura los siguientes bits de
CiCTRL:-CSIDL, REQOP<2:0> y CANCKS
Archivo de origen:
CAN1SetOperationMode.c
CAN2SetOperationMode.c
CAN1SetOperationMode(CAN_IDLE_STOP &
CAN_MASTERCLOCK_0 &
CAN_REQ_OPERMODE_DIS &
CAN_CAPTURE_DIS);
Ejemplo de código:
CAN1SetOperationModeNoWait
CAN2SetOperationModeNoWait
Esta función aborta las transmisiones pendientes y
Descripción:
configura el módulo CAN
can.h
Include:
void CAN1SetOperationModeNoWait(
Prototipo:
unsigned int config);
void CAN2SetOperationModeNoWait(
unsigned int config);
Config: valor de 16 bits que serán cargados en el
Argumentos:
registro CiCTRL , la combinación de la siguientes
definiciones.
CAN_IDLE_CON_NO_WAIT CAN On in Idle mode
CAN_IDLE_STOP_NO_WAIT CAN Stop in Idle
mode
CAN_MASTERCLOCK_1_NO_WAIT FCAN is FCY
CAN_MASTERCLOCK_0_NO_WAIT FCAN is 4
FCY
Modos de operación de CAN
CAN_REQ_OPERMODE_NOR_NO_WAIT
CAN_REQ_OPERMODE_DIS_NO_WAIT
63
CAN_REQ_OPERMODE_LOOPBK_NO_WAIT
CAN_REQ_OPERMODE_LISTENONLY_NO_WAIT
CAN_REQ_OPERMODE_CONFIG_NO_WAIT
CAN_REQ_OPERMODE_LISTENALL_NO_WAIT
Valores de retorno:
Comentarios:
Archivo de origen:
Ejemplo de código:
CAN Capture Enable/Disable
CAN_CAPTURE_EN_NO_WAIT
CAN_CAPTURE_DIS_NO_WAIT
Ninguno
Esta función pone a 1 el bit de aborto así aborta la
iniciación de todos las transmisiones pendientes y
configura los siguientes bits CiCTRL:-CSIDL,
REQOP<2:0> y CANCKS
CAN1SetOperationModeNoWait.c
CAN2SetOperationModeNoWait.c
CAN1SetOperationModeNoWait(CAN_IDLE_CON
&
CAN_MASTERCLOCK_1 &
CAN_REQ_OPERMODE_LISTEN &
CAN_CAPTURE_DIS_NO_WAIT);
CAN1SetRXMode
CAN2SetRXMode
Descripción:
Include:
Prototipo:
Argumentos:
Esta función configura el receptor CAN.
can.h
void CAN1SetRXMode(char buffno, unsigned int
config);
void CAN2SetRXMode(char buffno, unsigned int
config);
buffno: indica el registro de control que será
configurado.
config: El valor que será escrito en el registro
CiRXnCON , la combinación de las siguientes
definiciones.
Clear RXFUL bit
CAN_RXFUL_CLEAR
Valores de retorno:
Comentarios:
Archivo de origen:
Ejemplo de código:
Double buffer enable/disable
CAN_BUF0_DBLBUFFER_EN
CAN_BUF0_DBLBUFFER_DIS
Ninguno.
Esta función configura los siguientes bits del
registro CiRXnCON:
RXRTR, RXFUL (only 0), RXM<1:0> and DBEN
CAN1SetRXMode.c
CAN2SetRXMode.c
CAN1SetRXMode(0,CAN_RXFUL_CLEAR &
CAN_BUF0_DBLBUFFER_EN);
64
CAN1SetTXMode (función)
CAN2SetTXMode
Descripción:
Include:
Prototipo:
Argumentos:
Esta función configura el transmisor del módulo
CAN.
can.h
void CAN1SetTXMode(char buffno, unsigned int
config);
void CAN2SetTXMode(char buffno, unsigned int
config);
buffno: buffno indica el registro de control que
será configurado.
config: El valor que será escrito en el registro
CiTXnCON, la combinación de las siguientes
definiciones.
Message send request
CAN_TX_REQ
CAN_TX_STOP_REQ
Valores de retorno:
Comentarios:
Archivo de origen:
Ejemplo de código:
CAN1Initialize
CAN2Initialize
Descripción:
Include:
Prototipo:
Argumentos:
Message transmission priority
CAN_TX_PRIORITY_HIGH
CAN_TX_PRIORITY_HIGH_INTER
CAN_TX_PRIORITY_LOW_INTER
CAN_TX_PRIORITY_LOW
Ninguno.
Esta función configura los bits siguientes del
registro CiTXnCON:
TXRTR, TXREQ, DLC, TXPRI<1:0>
CAN1SetTXMode.c
CAN2SetTXMode.c
CAN1SetTXMode(1, CAN_TX_STOP_REQ &
CAN_TX_PRIORITY_HIGH);
Esta función configura el módulo CAN.
can.h
void CAN1Initialize(unsigned int config1,
unsigned int config2);
void CAN2Initialize(unsigned int config1,
unsigned int config2);
config1: El valor que será escrito en el registro
CiCFG1, la combinación de las siguientes
definiciones.
Sync jump width
CAN_SYNC_JUMP_WIDTH1
CAN_SYNC_JUMP_WIDTH2
CAN_SYNC_JUMP_WIDTH3
65
CAN_SYNC_JUMP_WIDTH4
Baud Rate prescaler
CAN_BAUD_PRE_SCALE(x) (((x-1) & 0x3f) |
0xC0)
config2: El valor que será escrito en el registro
CiCFG2, la combinación de las siguientes
definiciones.
CAN bus line filter selection for wake-up
CAN_WAKEUP_BY_FILTER_EN
CAN_WAKEUP_BY_FILTER_DIS
CAN propagation segment length
CAN_PROPAGATIONTIME_SEG_TQ(x)
(((x-1) & 0x7) | 0xC7F8)
CAN phase segment 1 length
CAN_PHASE_SEG1_TQ(x)
((((x-1) & 0x7) *0x8) | 0xC7C7)
CAN phase segment 2 length
CAN_PHASE_SEG2_TQ(x)
((((x-1) & 0x7) *0x100) | 0xC0FF)
CAN phase segment 2 mode
CAN_SEG2_FREE_PROG
CAN_SEG2_TIME_LIMIT_SET
Valores de retorno:
Comentarios:
Archivo de origen:
Ejemplo de código:
Sample of the CAN bus line
CAN_SAMPLE3TIMES
CAN_SAMPLE1TIME
Ninguno.
Esta función configura los bits siguientes de los
registros CiCFG1 y CiCFG2.
SJW<1:0>, BRP<5:0>, CANCAP, WAKEFIL,
SEG2PH<2:0>,
SEGPHTS, SAM, SEG1PH<2:0>, PRSEG<2:0>
CAN1Initialize.c
CAN2Initialize.c
CAN1Initialize(CAN_SYNC_JUMP_WIDTH2 &
CAN_BAUD_PRE_SCALE(2),
CAN_WAKEUP_BY_FILTER_DIS &
CAN_PHASE_SEG2_TQ(5) &
CAN_PHASE_SEG1_TQ(4) &
CAN_PROPAGATIONTIME_SEG_TQ(4) &
CAN_SEG2_FREE_PROG &
CAN_SAMPLE1TIME);
66
ConfigIntCAN1
ConfigIntCAN2
Descripción:
Include:
Prototipo:
Argumentos:
Esta función configura las interrupciones de
CAN.
can.h
void ConfigIntCAN1(unsigned int config1,
unsigned int config2);
void ConfigIntCAN2(unsigned int config1,
unsigned int config2);
config1: La información de interrupción
enable/disable se define:
Interrupt enable
CAN_INDI_INVMESS_EN
CAN_INDI_WAK_EN
CAN_INDI_ERR_EN
CAN_INDI_TXB2_EN
CAN_INDI_TXB1_EN
CAN_INDI_TXB0_EN
CAN_INDI_RXB1_EN
CAN_INDI_RXB0_EN
Interrupt disable
CAN_INDI_INVMESS_DIS
CAN_INDI_WAK_DIS
CAN_INDI_ERR_DIS
CAN_INDI_TXB2_DIS
CAN_INDI_TXB1_DIS
CAN_INDI_TXB0_DIS
CAN_INDI_RXB1_DIS
CAN_INDI_RXB0_DIS
config2: La información de Prioridad de
interrupción de CAN y Enable/disable se define:
CAN Interrupt enable/disable
CAN_INT_ENABLE
CAN_INT_DISABLE
Valores de retorno:
Comentarios:
CAN Interrupt priority
CAN_INT_PRI_0
CAN_INT_PRI_1
CAN_INT_PRI_2
CAN_INT_PRI_3
CAN_INT_PRI_4
CAN_INT_PRI_5
CAN_INT_PRI_6
CAN_INT_PRI_7
Ninguno.
Esta función configura las Interrupciones CAN.
Es el enable/disables de las interrupciones de
67
Archivo de origen:
Ejemplo de código:
CAN. Y también pone las prioridades.
ConfigIntCAN1.c
ConfigIntCAN2.c
ConfigIntCAN1(CAN_INDI_INVMESS_EN &
CAN_INDI_WAK_DIS &
CAN_INDI_ERR_DIS &
CAN_INDI_TXB2_DIS &
CAN_INDI_TXB1_DIS &
CAN_INDI_TXB0_DIS &
CAN_INDI_RXB1_DIS &
CAN_INDI_RXB0_DIS ,
CAN_INT_PRI_3 &
CAN_INT_ENABLE);
• Macros individuales
EnableIntCAN1
EnableIntCAN2
Descripción:
Include:
Argumentos:
Comentarios:
Ejemplo de código:
DisableIntCAN1
DisableIntCAN2
Descripción:
Include:
Argumentos:
Comentarios:
Ejemplo de código:
SetPriorityIntCAN1
SetPriorityIntCAN2
Descripción:
Include:
Argumentos:
Comentarios:
Ejemplo de código:
Esta macro habilita las interrupciones de CAN.
can.h
Ninguno.
Esta macro pone a 1 el bit CAN Interrupt
Enable en el registro Interrupt Enable Control.
EnableIntCAN1;
Esta macro deshabilita la interrupción CAN
can.h
Ninguno
Esta macro pone a 0 el bit de CAN Interruption
Enable del registro Interrupt Enable Control
DisableIntCAN2;
Esta macro pone prioridad a la interrupción de
CAN.
can.h
Priority
Esta macro pone los bits de interrupción de CAN
en el registro Interrupt Priority Control.
SetPriorityIntCAN1(2);
68
3.7.3. Ejemplo de aplicación de código
#define __dsPIC30F4013__
#include<p30fxxxx.h>
#include<can.h>
#define dataarray 0x1820
int main(void)
{
/* Longitud de los datos que serán transmitidos */
unsigned char datalen;
unsigned char Txdata[] =
{'M','I','C','R','O','C','H','I','P','\0'};
unsigned int TXConfig, RXConfig;
unsigned long MaskID,MessageID;
char FilterNo,tx_rx_no;
unsigned char * datareceived = (unsigned char *)
dataarray; /* Holds the data received */
/* pone la respuesta en el modo de configuración */
CAN1SetOperationMode(CAN_IDLE_CON &
CAN_MASTERCLOCK_1 &
CAN_REQ_OPERMODE_CONFIG &
CAN_CAPTURE_DIS);
while(C1CTRLbits.OPMODE <=3);
/* Carga el registro de configuración */
CAN1Initialize(CAN_SYNC_JUMP_WIDTH2 &
CAN_BAUD_PRE_SCALE(2),
CAN_WAKEUP_BY_FILTER_DIS &
CAN_PHASE_SEG2_TQ(5) &
CAN_PHASE_SEG1_TQ(4) &
CAN_PROPAGATIONTIME_SEG_TQ(4) &
CAN_SEG2_FREE_PROG &
CAN_SAMPLE1TIME);
/* Carga el registro de filtro de Aceptación*/
FilterNo = 0;
CAN1SetFilter(FilterNo, CAN_FILTER_SID(1920) &
CAN_RX_EID_EN, CAN_FILTER_EID(12345));
/* Carga el registro de filtro de Máscara */
CAN1SetMask(FilterNo, CAN_MASK_SID(1920) &
CAN_MATCH_FILTER_TYPE, CAN_MASK_EID(12344));
/* Pone el modo de transmisor y receptor */
tx_rx_no = 0;
CAN1SetTXMode(tx_rx_no,
CAN_TX_STOP_REQ &
CAN_TX_PRIORITY_HIGH );
CAN1SetRXMode(tx_rx_no,
CAN_RXFUL_CLEAR &
CAN_BUF0_DBLBUFFER_EN);
/* Carga el mensaje ID , datos dentro del buffer de transmisión y pone el
bit de respuesta de transmisión */
69
datalen = 8;
CAN1SendMessage((CAN_TX_SID(1920)) & CAN_TX_EID_EN &
CAN_SUB_NOR_TX_REQ,
(CAN_TX_EID(12344)) & CAN_NOR_TX_REQ,
Txdata,datalen,tx_rx_no);
/* Pone la respuesta en modo Loopback */
CAN1SetOperationMode(CAN_IDLE_CON & CAN_CAPTURE_DIS &
CAN_MASTERCLOCK_1 &
CAN_REQ_OPERMODE_LOOPBK);
while(C1CTRLbits.OPMODE !=2);
/* Espera que el mensaje se transmita completamente */
while(!CAN1IsTXReady(0))
/* Espera que el buffer de recepción contenga el mensaje válido */
while(!CAN1IsRXReady(0));
/* Lee los datos recibidos del buffer de recepción*/
CAN1ReceiveMessage(datareceived, datalen, tx_rx_no);
while(1);
return 0;
}
70
4. ANEXO:
Dispositivos CAN
71
4. Dispositivos CAN
Evidentemente enumerar todos los dispositivos que podemos conectar a CAN
nos es imposible, pero sí podemos mostrar algunos de estos productos, para
comprobar la versatilidad y el gran número de estos que se encuentran en el
mercado. Nos centraremos principalmente en los sensores, ya que nos van a
ser más útiles a la hora de realizar nuestro trabajo en el dsPIC30F4013.
SENSORES
Sensor digital de presión “HDA 4000 CAN”
Características técnicas:
-
Interfaz CAN
Rango de medida: presiones
de 40 bar a 600 bar.
Precisión ≤ ± 0.25 %
Rango de temperatura
soportable: –25 °C a +85 °C
Tensión: de 10 a 35 VDC
Tasa de transmisión de 10kbit
a 1Mbit (configurable)
Sensores MDT CAN + IDA CAN
- La señal digital tiene una
resolución de 13 bits sobre los
dos cables del bus CAN.
- El tiempo de medida y de
conversión de la señal de
presión es de 20 milisegundos,
más que suficiente para la
mayoría de las aplicaciones
industriales.
- El cableado interno de CAN,
supervisa de forma automática
que las funciones del
transductor de presión sean las
correctas, y envía una señal de
alarma en caso contrario.
72
Codificador de eje rotatorio 5860
Características técnicas:
-
Todos los valores obtenidos son
enviados a través del interfaz
CAN.
Parámetros programables vía
CAN
Rotación: 6000 rpm.
Rango de temperatura
soportable: -20 °C a +85 °C
Tensión: 10 a 30 VDC
Codificador magnético ATM 60
Características técnicas:
-
Interfaz Bus CAN de alta
velocidad
8192 medidas por vuelta
Octoacoplador para aislar del
bus la corriente continua.
Alta resistencia a vibraciones y
golpes
Familia de inclinómetros AnguSens
Características técnicas:
-
Todos los valores obtenidos son
enviados a través del interfaz
CAN.
Parámetros programables vía
CAN
Rango de medida: ±15° o ± 30°
Precisión: hasta 0.001°
Máximo dos ejes de medida.
73
Sensores de compactación ASC (para camiones y maquinaria pesada)
-
-
Utilizado para medir lo compacto de un terreno
Un sensor de aceleración empotrado mide la reacción del tambor,
mientras que un microregulador calcula la frecuencia de vibración y
otros parámetros que son transferidos vía CAN, por ejemplo a un
display.
Memoria EEPROM disponible, con diccionario CAN.
Rango de medida: ±41 g
Temperatura soportable: -40°C a +85°C
Tensión: 8V a 32V DC
Consumo: 80mA a 12V aprox.
Transductores BTL5-H1
-
Transmite las medidas de posición y velocidad del sistema de control
obtenidas a otro nodo a través del Bus CAN.
Los hay disponibles de tres formas, según el transductor que lleven: un
imán de posición, dos imanes de posición, o FMM (modo magnético
flexible) con de 1 a 4 imanes de posición.
Gran precisión: 5 µm para la posición y 0.1 mm/s para la velocidad.
Rango de temperatura soportable: de -40°C a +85°C
Muy lineales e insensibles a las vibraciones, los golpes y los ruidos.
74
Familia de sensores µCAN
Además de una gran cantidad de sensores, podemos encontrar esta familia de
módulos para sensores µCAN, que esta especialmente diseñada para los
fabricantes de sensores que quieran añadir una interfaz CAN a estos, ya sean
sensores de tensión, de corriente, presión, calor, esfuerzo…
Todos estos módulos tienen un rango de temperatura soportable que va de 40 °C a + 85 °C y un rango de tensión de 8 V a 60 V de corriente continua.
Otro tipo de dispositivos
ESCÁNERES
75
ACTUADORES
DATALOGGERS
MÓDULOS DE ENTRADA-SALIDA
76
GATEWAYS, CONVERSORES Y BRIDGES
CAN - USB
CAN - ETHERNET
CAN-RS232
CAN-CBM-DP / CAN-DP
77
CAN-Wireless
CAN-GSM
CAN-GPRS
CAN-Bluetooth
REPETIDORES
78
5. BIBLIOGRAFÍA
79
Bibliografía básica:
1. INTRODUCCIÓN
www.can-cia.org/can/
www.can-cia.org/can/protocol/history/history.html
www.can-cia.org/applications/cankingdom/
www.serconet.com/usr/laureanog/HPV1B_31.HTM
www.semiconductors.bosch.de/de/20/can/index.asp
www.can.bosch.com
http://es.wikipedia.org/wiki/CAN_bus
www.canbus.galeon.com/electronica/canbus.htm
www.ihs.com.es/
2. TRANSMISIÓN DE DATOS
http://www.kvaser.com/index.htm
www.unavarra.es
3. CAN DEL MICRO dsPIC30F4013
www.port.de/pdf/CAN_Bit_Timing.pdf
http://cabierta.uchile.cl/revista/19/articulos/pdf/edu4.doc
www.microchip.com
4. ANEXO: Dispositivos CAN
http://www.can-cia.org/products/pg2005/html/index.htm
http://www.canusb.com/index.htm
http://www.ixxat.de/
80