Documente Academic
Documente Profesional
Documente Cultură
Grupos 03-04
Relación de alumnos que han participado:
1
Índice
1. INTRODUCCIÓN
2. TRANSMISIÓN DE DATOS
5. BIBLIOGRAFÍA......................................................................... pag. 80
2
1. INTRODUCCIÓN
3
1.1. Motivación histórica
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.
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
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:
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.
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.
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.
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
• Programación sencilla.
• 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:
9
1.3. Competencia y futuro
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:
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.
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
12
1.4. Campos de aplicació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
Dimensiones:
CI 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
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
18
• Estándar 11519
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.
19
• Estándar 11898
Los nodos conectados en este bus interpretan los siguientes niveles lógicos:
20
2.1.2. Capa de enlace de datos
21
2.2. Estructura de un nodo CAN
22
Teniendo en cuenta esta arquitectura, el funcionamiento sigue los siguientes
pasos:
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
24
2.4.2. Trama de datos
25
En formato extendido serán 11 bits de identificador base y 18 de
extendido. El bit SRR substituye al RTR y será recesivo.
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.
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.
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 Indicador de error es distinto según el estado de error del nodo que detecta
el 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:
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.
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.
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.
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.
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.
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):
2.8. Implementaciones
Es la arquitectura más simple, para llevar a cabo una comunicación en una red
CAN será necesario:
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.
36
• Single-chip CAN Node
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.
39
• Capacidad de señalización a través de interrupciones por parte de todos
los receptores y transmisores de estados de error CAN.
40
3.2. Transceptor (transceiver)
- 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.
42
3.3. Modos de funcionamiento
43
Modo deshabilitado (Disable mode)
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.
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.
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.
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:
Errores de recepción
Interrupciones de recepción
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.
Bufers de transmisión:
Secuencia de transmisión:
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.
Errores de transmisión
Interrupciones de transmisión
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
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.
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:
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.
52
Puede producir el alargamiento o el acortamiento de los segmentos de
fase de los que hablamos en la siguiente sección.
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.
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:
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.
54
3.7. Programación
3.7.1. MPLAB
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: Esta función aborta inicialmente todas las
transmisiones pendientes.
Include: can.h
Prototipo: void CAN1AbortAll(void);
void CAN2AbortAll(void);
Argumentos: Ninguno
Valores de retorno: Ninguno
Comentarios:
Archivo de origen: CAN1AbortAll.c
CAN2AbortAll.c
Ejemplo de código: CAN1AbortAll();
CAN1GetRXErrorCount
CAN2GetRXErrorCount
Descripción: Esta función devuelve la cuenta del valor del
error al recibir.
Include: can.h
Prototipo: Unsigned char CAN1GetRXErrorCount(void);
Unsigned char CAN2GetRXErrorCount(void);
Argumentos: Ninguno
Valores de retorno: El contenido de CIRERRCNT, que son 8 bits
Comentarios: Esta función devuelve el contenido de
CIRERRCNT (el bit más bajo del registro CiEC)
que indica la cuenta de errores recibidos.
Archivo de origen: CAN1GetRXErrorCount.c
CAN2GetRXErrorCount.c
Ejemplo de código: unsigned char rx_error_count;
rx_error_count = CAN1GetRXErrorCount();
56
CAN1GetTXErrorCount
CAN2GetTXErrorCount
Descripción: Esta función devuelve la cuenta del valor del
error al enviar.
Include: can.h
Prototipo: Unsigned char CAN1GetTXErrorCount(void);
Unsigned char CAN2GetTXErrorCount(void);
Argumentos: Ninguno
Valores de retorno: El contenido de CIRERRCNT, que son 8 bits
Comentarios: Esta función devuelve el contenido de
CIRERRCNT (el bit superior del registro CiEC)
que indica la cuenta de errores al transmitir.
Archivo de origen: CAN1GetTXErrorCount.c
CAN2GetTXErrorCount.c
Ejemplo de código: unsigned char tx_error_count;
tx_error_count = CAN1GetTXErrorCount();
CAN1sBusOff
CAN2sBusOff
Descripción: Esta función determina cuando el nodo CAN
está en modo Bus Off.
Include: can.h
Prototipo: Char CAN1IsBusOff(void);
Char CAN2IsBusOff(void);
Argumentos: Ninguno
Valores de retorno: 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.
Comentarios: Esta función devuelve el estado del bit TXBO
del registro CilNTF.
Archivo de origen: CAN1IsBusOff.c
CAN2IsBusOff.c
Ejemplo de código: While (CAN1IsBusOff());
CAN1sRXReady
CAN2sRXReady
Descripción: Esta función devuelve el estado del búfer de
recepción.
Include: can.h
Prototipo: Char CAN1IsRXReady(char);
Char CAN2IsRXReady(char);
Argumentos: Buffno: el valor de buffno indica cual es el
estado requerido para el bufer de recepción.
Valores de retorno: 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
nuevo.
Comentarios: Esta función devuelve el estado del bit RXFUL
del registro de control de recepción (control
register)
Archivo de origen: CAN1IsRXReady.c
CAN2IsRXReady.c
Ejemplo de código: char rx_1_status;
rx_1_status = CAN1IsRXReady(1);
CAN1sRXPassive
CAN2sRXPassive
Descripción: Esta función determina si la recepción se
encuentra en estado Error Pasivo.
Include: can.h
Prototipo: char CAN1IsRXPassive(void);
char CAN2IsRXPassive(void);
Argumentos: Ninguno
Valores de retorno: 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.
Comentarios: Esta función devuelve el estado del bit RXEP
del registro CiiNTF.
Archivo de origen: CAN1IsRXPassive.c
CAN2IsRXPassive.c
Ejemplo de código: char rx_bus_status;
rx_bus_status = CAN1sRXPassive();
CAN1sTXPassive
CAN2sTXPassive
Descripción: Esta función determina si la transmisión se
encuentra en estado Error Pasivo.
Include: can.h
Prototipo: char CAN1IsTXPassive(void);
char CAN2IsTXPassive(void);
Argumentos: Ninguno
Valores de retorno: 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.
Comentarios: Esta función devuelve el estado del bit TXEP en
el registro CiiNTF.
Archivo de origen: CAN1IsTXPassive.c
CAN2IsTXPassive.c
Ejemplo de código: char tx_bus_status;
tx_bus_status = CAN1IsTXPassive();
58
CAN1lsTXReady
CAN2lsTXReady
Descripción: Esta función devuelve que el estado del
transmisor indica si el nodo CAN esta preparado
para la próxima transmisión.
Include: can.h
Prototipo: Char CAN1IsTXReady(char);
Char CAN2IsTXReady(char);
Argumentos: Buffno: el valor de buffno indica cual es el
estado requerido para el búfer de transmisión.
Valores de retorno: 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.
Comentarios: Esta función devuelve el estado del bit TXREQ
del registro de control de transmisión (control
transmit)
Archivo de origen: CAN1IsTXReady.c
CAN2IsTXReady.c
Ejemplo de código: char tx_2_status;
tx_2_status = CAN1IsTXReady(2);
CAN1RecieveMessage
CAN2RecieveMessage
Descripción: Esta función lee el dato del buffer de recepción.
Include: can.h
Prototipo: void CAN1RecieveMessage(unsigned char *
data, unsigned char datalen, char MsgFlag);
void CAN2RecieveMessage(unsigned char *
data, unsigned char datalen, char MsgFlag);
Argumentos: 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.
59
CAN1SendMessage
CAN2SendMessage
Descripción: Esta función escribe datos para ser transmitidos
a registros de transmisión, pone la longitud de
los datos e inicia la transmisión.
Include: can.h
Prototipo: 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);
60
(CAN_SUB_NOR_TX_REQ),
(CAN_TX_EID(12344)) &
(CAN_NOR_TX_REQ),
Txdata, datalen, tx_rx_no);
CAN1SetFilter
CAN2SetFilter
Descripción: Esta función pone a 1 los valores (SID y EID)
con filtro de aceptación para el filtro
especificado.
Include: can.h
Prototipo: void CAN1SetFilter(char filter_no, unsigned int
sid,
unsigned long eid);
void CAN2SetFilter(char filter_no, unsigned int
sid,
unsigned long eid);
61
CAN1SetMask
CAN2SetMask
Descripción: Esta función pone a 1 el valor de la máscara de
aceptación (SID y EID) para la máscara
especificada.
Include: can.h
Prototipo: void CAN1SetMask(char mask_no, unsigned int
sid,
unsigned long eid);
void CAN2SetMask(char mask_no, unsigned int
sid,
unsigned long eid);
CAN1SetOperationMode
CAN2SetOperationMode
Descripción: Esta función configura el módulo CAN
Include: can.h
Prototipo: void CAN1SetOperationMode(unsigned int
config);
void CAN2SetOperationMode(unsigned int
config);
Argumentos: 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
CAN1SetOperationModeNoWait
CAN2SetOperationModeNoWait
Descripción: Esta función aborta las transmisiones pendientes y
configura el módulo CAN
Include: can.h
Prototipo: void CAN1SetOperationModeNoWait(
unsigned int config);
void CAN2SetOperationModeNoWait(
unsigned int config);
Argumentos: Config: valor de 16 bits que serán cargados en el
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
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
CAN1SetRXMode
CAN2SetRXMode
Descripción: Esta función configura el receptor CAN.
Include: can.h
Prototipo: void CAN1SetRXMode(char buffno, unsigned int
config);
void CAN2SetRXMode(char buffno, unsigned int
config);
Argumentos: 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.
64
CAN1SetTXMode (función)
CAN2SetTXMode
Descripción: Esta función configura el transmisor del módulo
CAN.
Include: can.h
Prototipo: void CAN1SetTXMode(char buffno, unsigned int
config);
void CAN2SetTXMode(char buffno, unsigned int
config);
Argumentos: 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.
CAN1Initialize
CAN2Initialize
Descripción: Esta función configura el módulo CAN.
Include: can.h
Prototipo: void CAN1Initialize(unsigned int config1,
unsigned int config2);
void CAN2Initialize(unsigned int config1,
unsigned int config2);
Argumentos: config1: El valor que será escrito en el registro
CiCFG1, la combinación de las siguientes
definiciones.
65
CAN_SYNC_JUMP_WIDTH4
66
ConfigIntCAN1
ConfigIntCAN2
Descripción: Esta función configura las interrupciones de
CAN.
Include: can.h
Prototipo: void ConfigIntCAN1(unsigned int config1,
unsigned int config2);
void ConfigIntCAN2(unsigned int config1,
unsigned int config2);
Argumentos: 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:
67
CAN. Y también pone las prioridades.
Archivo de origen: ConfigIntCAN1.c
ConfigIntCAN2.c
Ejemplo de código: 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: Esta macro habilita las interrupciones de CAN.
Include: can.h
Argumentos: Ninguno.
Comentarios: Esta macro pone a 1 el bit CAN Interrupt
Enable en el registro Interrupt Enable Control.
Ejemplo de código: EnableIntCAN1;
DisableIntCAN1
DisableIntCAN2
Descripción: Esta macro deshabilita la interrupción CAN
Include: can.h
Argumentos: Ninguno
Comentarios: Esta macro pone a 0 el bit de CAN Interruption
Enable del registro Interrupt Enable Control
Ejemplo de código: DisableIntCAN2;
SetPriorityIntCAN1
SetPriorityIntCAN2
Descripción: Esta macro pone prioridad a la interrupción de
CAN.
Include: can.h
Argumentos: Priority
Comentarios: Esta macro pone los bits de interrupción de CAN
en el registro Interrupt Priority Control.
Ejemplo de código: 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
SENSORES
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)
72
Codificador de eje rotatorio 5860
Características técnicas:
Características técnicas:
Características técnicas:
73
Sensores de compactación ASC (para camiones y maquinaria pesada)
Transductores BTL5-H1
74
Familia de sensores µCAN
ESCÁNERES
75
ACTUADORES
DATALOGGERS
MÓDULOS DE ENTRADA-SALIDA
76
GATEWAYS, CONVERSORES Y BRIDGES
CAN - USB
CAN - ETHERNET
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
www.port.de/pdf/CAN_Bit_Timing.pdf
http://cabierta.uchile.cl/revista/19/articulos/pdf/edu4.doc
www.microchip.com
http://www.can-cia.org/products/pg2005/html/index.htm
http://www.canusb.com/index.htm
http://www.ixxat.de/
80