Qu es CAN y cmo funciona el

mdulo del microcontrolador

dsPIC30F4013

Grupos 03-04

Relacin de alumnos que han participado:

Alepuz Soriano, Hctor Nazario

Gimnez Espinosa de los Monteros, Hctor
Jord Fernndez, Jorge Manuel
Ripoll Gisbert, Felipe
Saval Sendra, Pablo Miguel
Serrano Reche, Juan
Talens Noguera, Juan Vicente

ndice
1. INTRODUCCIN
1.1. Motivacin histrica .................................................. pag. 4
1.2. Caractersticas bsicas del bus CAN ....................... pag. 7
1.3. Competencia y futuro ............................................. pag. 10
1.4. Campos de aplicacin .............................................. pag. 13
1.5. Ejemplo de aplicacin prctica: Domtica ................ pag. 14
2. TRANSMISIN DE DATOS
2.1. Arquitectura de capas
2.1.1. Capa fsica................................................. pag.
2.1.2. Capa de enlace de datos ........................... pag.
2.2. Estructura de un nodo CAN.................................... pag.
2.3. Formato de codificacin y sincronizacin 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 mltiple y abitraje de acceso al bus ........... pag.
2.6. Deteccin de errores
2.6.1. Deteccin 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. Caractersticas bsicas ........................................... pag.
3.2. Transceptor (transceiver) ........................................ pag.
3.3. Modos de funcionamiento ....................................... pag.
3.4. Recepcin de mensajes .......................................... pag.
3.5. Transmisin de mensajes........................................ pag.
3.6. Temporizacin y sincronizacin de bits
3.6.1. Temporizacin de bits................................ pag.
3.6.2. Sincronizacin de bits................................ pag.
3.6.3. Parmetros del tiempo de bit nominal ....... pag.
3.7. Programacin
3.7.1. MPLAB ...................................................... pag.
3.7.2. Funciones .................................................. pag.
3.7.3. Ejemplo de aplicacin de cdigo ............... pag.

39
41
43
46
48
51
52
53
55
56
69

4. ANEXO: Dispositivos CAN ....................................................... pag. 72

5. BIBLIOGRAFA......................................................................... pag. 80

1. INTRODUCCIN

1.1. Motivacin histrica

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 (ms conocido como Bosch a secas) lo present en el congreso de la
Sociedad de Ingeniera de la Automocin. Desde entonces, CAN se ha
convertido en uno de los protocolos lderes en la utilizacin 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 satisfacan 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 reduccin del peso y la complejidad de los
automviles a travs de la reduccin del cableado iban a favorecer este hecho.
Ingenieros de Mercedes-Benz pronto se involucraron en las primeras fases de
creacin del nuevo sistema, y pronto lo hizo tambin Intel como potencial
vendedor de semiconductores. El profesor Wolfhard Lawrenz de la universidad
de ciencias aplicadas de Brunswick-Wolfenbttel, Alemania, fue quin 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 despus, Semiconductores Philips presentara el
82C200. Estos dos antepasados primigenios de los controladores CAN
actuales eran completamente distintos en cuanto a filtros de aceptacin y
control de mensajes:
Intel adopt el concepto de FullCAN; este requera menos carga de la CPU del
microcontrolador que la implementacin BasicCAN elegida por Philips. Pero por
otra parte, el dispositivo de FullCAN era limitado con respecto al nmero de los
mensajes que podan ser recibidos. Adems, el controlador de BasicCAN
requera menos silicio, lo que abarataba aun ms su coste. Actualmente, los
trminos BasicCAN y FullCAN han quedado obsoletos.

Estandardizacin
La especificacin CAN (versin 2.0) de Bosch fue sometida a la
estandardizacin internacional a comienzos de los 90.
Concretamente en Noviembre de 1993, despus de diversos
conflictos polticos, se public el estndar ISO 11898, que defina
adems una capa fsica 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 estndar se ampli con la descripcin del identificador
CAN de 29 bits.
Desafortunadamente, todas las especificaciones y estandarizaciones
publicadas acerca de CAN contenan errores o estaban incompletas. Para
evitar incompatibilidades, Bosch se cercior, y sigue hacindolo, 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 transmisin de datos CAN'; la ISO 11898-2 la capa fsica
CAN no tolerante a fallos'; y la ISO 11898-3 la capa fsica CAN tolerante a
fallos. Los estndares de ISO 11992 (referente a la interfaz para camiones y
remolques) e ISO 11783 (referente a la maquinaria agrcola 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 nmero de las primeras aplicaciones llegaran desde otros segmentos
de mercado distintos:
Entre otros, el fabricante finlands de ascensores Kone, fue uno de los
primeros en aprovecharse de sus ventajas.
La oficina de ingeniera Suiza Kyaser lo introdujo a los fabricantes de
maquinaria textil del pas, que acabaron fundando el Grupo de usuarios textiles
CAN, bajo el liderazgo de Lars-Berno Frediksson.
En Holanda, Sistemas mdicos Philips lo utiliz para las redes internas de sus
mquinas de Rayos X. La especificacin para mensajes de Philips (PMS),
desarrollada principalmente por Tom Suters, represent la primera capa de
aplicacin para redes CAN.
Tambin se sucedieron todo tipo de propuestas acadmicas, como por
ejemplo, la creacin a finales de los 80 de un sistema de bus basado en CAN,
para vehculos agrcolas (LBS).

Ya en 1992, Mercedes-Benz implant CAN en sus automviles de clase alta. Y

aunque en un principio el bus se limitaba a interconectar las unidades de
control electrnico que cuidaban del control del motor, pronto conectaran
adems las unidades de control necesarias para los componentes electrnicos.
Para ello, se implementaron dos sistemas de bus CAN separados fsicamente,
y conectados a travs 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 ao, usuarios internacionales y
grupos de fabricantes fundaron oficialmente la organizacin
'CAN en la Automocin (CiA).
La primera publicacin tcnica, que trataba acerca de la capa fsica, fue emitida
solo unas semanas despus: CiA recomendaba utilizar solamente
transceptores CAN que cumplieran la normativa ISO 11898. A da de hoy, son
los transceptores RS485 los utilizados ms comnmente.
Otra de las primeras tareas de la CiA fue la especificacin de la capa de
aplicacin CAN (CAL), que se desarroll a partir del material existente de los
Sistemas mdicos de Philips y de STZP.

Capas de aplicacin
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 produccin. En 1995, se public el perfil
totalmente revisado de las comunicaciones de CANopen, que en el plazo de
cinco aos ya se haba convertido en la red integrada estandarizada ms
importante de Europa, puesto que ofreca una gran flexibilidad y un gran
nmero de opciones de configuracin, as como diversos perfiles de dispositivo,
interfaz y uso.
Actualmente, CANopen se sigue utilizando especialmente en Europa:
mquinas de moldeado por inyeccin en Italia, mquinas expendedoras en
Inglaterra, gras en Francia, control de maquinaria en Austria, o maquinaria de
fabricacin de relojes en Suiza... Mientras que en Estados Unidos CANopen se
abre camino en el mbito de los toros mecnicos y las mquinas clasificadoras.
Poco despus de aquello, a comienzos de 1994, Allen-Bradley desarroll la
tecnologa DeviceNet, enfocada esencialmente a la automatizacin de las
fbricas. Pronto ganara adeptos en Estados Unidos debido sobretodo a su
funcionamiento plug & play (enchufar y listo).

Pero no fueron las nicas. Desde el momento de la creacin de CAL, se fue

sucediendo la creacin de diferentes estndares que definan la capa de
aplicacin; algunos son muy especficos y estn relacionados casi
exclusivamente con sus campos de aplicacin. Dejando de lado las 3
mencionadas anteriormente, entre los protocolos de alto nivel y las capas de
aplicacin ms utilizadas cabe mencionar: SDS, OSEK y CANKingdom.
Por una parte, SDS (Smart Distributed System), fue creado por Honeywell
durante la gestacin de DeviceNet, y de hecho era muy similar a este, as que
no entraremos en detalle. OSEK, que estaba basado adems en TCP/IP y
algoritmos DSP, rpidamente enfocara su aplicacin 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 electrnica martima.
Ya por ltimo, en el ao 2000, ISO form un grupo de trabajo que agrupaba
empleados de Bosch, acadmicos 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 extensin permita tanto
la transmisin de mensajes simultneos, como la implementacin de un bucle
cerrado para el control del bus. Y gracias a que el protocolo del bus no fue
modificado, este tipo de mensajes podan seguir siendo enviados con el mismo
sistema fsico de bus.

1.2. Caractersticas bsicas del bus CAN

Econmico 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
automovilstico.

Estandarizado: Se trata de un estndar 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 transmisin adaptable: El cableado, como ya hemos dicho, es

muy reducido a comparacin de otros sistemas. Adems, a pesar de que
por diversas razones el estndar de hardware de transmisin sea un par
trenzado de cables, el sistema de bus CAN tambin 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 informacin que circula entre las unidades a

travs de los dos cables (bus) son paquetes de bits (0s y 1s) con una
longitud limitada y con una estructura definida de campos que
conforman el mensaje.

Programacin sencilla.

Nmero de nodos: Es posible conectar hasta 110 dispositivos en una

sola red CAN.

Garanta 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 especfico de
tiempo. Adems, la transmisin siempre ser en tiempo real.

Optimizacin del ancho de banda: Los mtodos utilizados para distribuir

los mensajes en la red, como el envo de estos segn su prioridad,
contribuyen a un mejor empleo del ancho de banda disponible.

Desconexin autnoma 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, tambin se
pueden aadir nodos al bus sin afectar al resto del sistema, y sin
necesidad de reprogramacin.

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.

Relacin velocidad-distancia: Al punto anterior habra que aadir que la

velocidad tambin depende de la distancia hasta un mximo 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 mxima de bus

(m)
30
50
100
250
500
1000
2500
5000

Adems podemos hablar de otras caractersticas tcnicas en las que

profundizaremos ms adelante:

Orientado a mensajes: Se trata de un protocolo orientado a mensajes, y

no a direcciones, es decir, la informacin que se va a intercambiar se
descompone en mensajes, a los cuales se les asigna un identificador y
son encapsulados en tramas para su transmisin. Cada mensaje tiene
un identificador nico dentro de la red, a partir del cual los nodos
deciden aceptar o no dicho mensaje. Adems estn priorizados.

Multidifusin (multicast): Permite que todos los nodos puedan acceder al

bus de forma simultnea con sincronizacin de tiempos.

Medio compartido (broadcasting): La informacin es enviada en la red a

todos los destinos de forma simultnea. As que los destinos habrn de
saber si la informacin les concierne o deben rechazarla.

Deteccin y sealizacin de errores: CAN posee una gran capacidad de

deteccin de errores, tanto temporales, como permanentes, lograda a
travs de cinco mecanismos de deteccin, 3 al nivel de mensaje y 2 a
nivel de bit. Los errores adems pueden ser sealizados.

Retransmisin automtica de tramas errneas: Junto a la deteccin y

sealizacin de errores la retransmisin automtica de tramas errneas
aporta la integridad de los datos. Adems ambos procesos son
transparentes al usuario.

Jerarqua multimaestro: CAN es un sistema multimaestro en el cual

puede haber ms 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.

1.3. Competencia y futuro

Realmente CAN se encuentra en una posicin privilegiada en el mercado.
El siguiente grfico traza una comparativa entre diferentes tecnologas respecto
al coste por nodo.

Vemos que J1850, pero sobretodo LIN, que tiene una mayor presencia en la
industria, son opciones ms econmicas, pero hasta qu punto son estas
tecnologas competidoras de CAN?
En la siguiente tabla, se exponen las diferentes caractersticas de LIN y CAN (y
de cmo extra el I2C de Philips), para detallar la similitud entre ellas:
CAN
Compaa que lo desarroll
Bosh
1Mb/s
Velocidad
Tamao de datos
Prioridad de mensajes
Garanta de latencia
Flexibilidad en la configuracin
Sistema Multimaestro
Deteccin y sealizacin de
errores
Retransmisin 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

automtica

No

programable

Se puede llegar a la conclusin fcilmente, de que cada una va a ser til en un

mbito de manufactura distinto, ya que sus caractersticas son distintas.
La diferencia principal, adems de la econmica, va a resultar ser la velocidad.

10

Dentro de la industria automovilstica por ejemplo, CAN es empleado como bus

de comunicaciones para los elementos ms importantes de este, que van a
requerir una seguridad y velocidad mayores. Para otro tipo de visicitudes, como
los elevalunas elctricos 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, ms que competir, lo que hacen es repartirse el pastel, ya que al

tener diferentes caractersticas, 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 ms importantes que
hay entre estos, aunque no sean competidores directos:

CAN Ethernet
Aun cuando las similitudes entre CAN y Ethernet son obvias, CAN posee algn
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 ms alta no se destruye y se
retransmite; slo 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 mximo 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 caractersticas muy predecibles. Con
Ethernet, ambos transmisores se detienen cuando se detecta una colisin y
una cantidad de tiempo aleatorio se permite pasar antes de que ambos
prueben de la retransmisin. Con este elemento aleatorio de tiempo eliminado
de la funcin del bus, es posible lograr casi el 100% de eficacia en trminos de
utilizacin del ancho de banda.

Futuro
A da de hoy, el futuro de CAN se prev esperanzador, ya que incluso las
estimaciones ms 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 prximos diez o quince aos.

12

1.4. Campos de aplicacin

El 80% de las aplicaciones modernas del bus CAN se pueden encontrar en la
ingeniera del automvil y otro tipo de vehculos como autobuses, trenes y
aviones. En el caso de los automviles por ejemplo, CAN es el encargado de la
comunicacin y automatizacin del sistema de freno, los faros, el ABS, o el
ordenador de abordo, del cual vemos su esquema en el siguiente grfico:

Sin embargo, tambin se puede encontrar el bus CAN en aplicaciones de

diversa ndole debido a su naturaleza, que le aporta robustez, economa y un
altsimo grado de seguridad y fiabilidad; entre las ms comunes:

Control y automatizacin industrial:

- Redes entre diversas mquinas y elementos de las mismas.
- Redes de supervisin.
- Redes de seguridad.
Control y automatizacin de edificios:
- Control de ascensores, puertas mecnicas, aspersores y diversos
elementos mecnicos.
- Control de iluminacin.
Aplicaciones especficas:
- Control de mquinas expendedoras (en Inglaterra est muy
extendido su uso).
- Control de equipamiento mdico.
- Control de sistemas automticos de almacenaje.
- Control de electrodomsticos.

13

1.5. Ejemplo de aplicacin prctica: Domtica

La lnea que vamos a tratar, permite una gran versatilidad de interconexionado
de los mdulos que la componen, ya que la topologa en la que se basa el
sistema de instalacin es en modo rbol. Esta caracterstica facilita las posibles
ampliaciones del sistema y en consecuencia reduce el coste de instalacin
porque el cableado y el tiempo necesario para la instalacin, es menor que en
las instalaciones convencionales.
Se trata de un sistema modular distribuido. Modular, porque el sistema consta
de distintos mdulos que permiten una fcil instalacin y configuracin.
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; adems la prdida de comunicacin entre mdulos no impide el
desarrollo de las decisiones locales.
La instalacin consta como mnimo 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 (comunicacin principal). Tambin se encarga de
controlar al bus local (bus I2C4H) transmitiendo las rdenes procedentes de
otros CI a los distintos mdulos de ampliacin que se le pueden conectar y de
reenviar la informacin captada por estos mdulos al resto de CI si procede
(comunicacin local).

CI

Dimensiones:
4 mdulos DIN
Frontal:
LED de estatus de alimentacin
7 LED's de reconocimiento de nodo
de expansin Botn 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
expansin
Comunicaciones externas:
Puerto RS-232

14

La comunicacin principal basada en CAN, aprovecha todas las caractersticas

de este ya explicadas a lo largo del trabajo: comunicacin tipo "broadcast",
donde todos los CI estn escuchando y si el mensaje les afecta toman la
decisin de actuar o no, por lo que no hay posibilidad de colisin; 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 acta de forma parecida con la diferencia de que si que
existe una direccin de remitente y de destino en los mensajes, tambin el flujo
de informacin es menor a nivel local y el CI gestiona este trfico.
Por otra parte, encontramos el derivador, elemento que hace de ladrn entre
los distintos CI, y que incorpora la alimentacin al bus principal y permite la
activacin de la resistencia final de lnea en cada una de las terminaciones.
Derivador

Dimensiones:
2 mdulos DIN
Lateral:
Interruptor final de bus
Entradas / Salidas:
3 conectores bus CAN, configurable
segn topologa
1 entrada alimentacin 24 VCD
1 entrada para lnea de telfono
1 entada aux.
1 salida de bus IEE para nodos de
expansin
Comunicaciones externas:
No

Vamos a ver algunos ejemplos de montaje:

Este es un ejemplo tpico de vivienda con un nico CI y dos ampliaciones, una
para ocho entradas y ocho salidas en modo encendido y apagado y una
segunda ampliacin para el control de cuatro zonas reguladas.

15

En este otro ejemplo de topologa podemos ver una instalacin tpica para un
adosado con tres CI, uno por planta de la vivienda, uno de los cuales (el
primero de ellos) se encontrara al lmite de su capacidad; podra ser el que se
encontrara en la primera planta del adosado, por ser esta planta la que
mayores controles requiere.

Para una mejor compresin en este ejemplo solo se han representado los CI y
no sus respectivos mdulos de ampliacin. Este sera un ejemplo de aplicacin
en un edificio de oficinas, residencia o en un hotel, donde tenemos distintas
plantas que controlar. En funcin de la totalidad de elementos que vamos a
controlar dispondremos de una mayor o menor cantidad de CI por planta.

16

2. TRANSMISIN
DE DATOS

17

2.1. Arquitectura de capas

Las implementaciones hardware de CAN cubren de forma estandarizada las
capas fsicas y de enlace del modelo de comunicaciones OSI (Open Systems
Interconection), mientras diversas soluciones de software no estandarizadas
cubren la capa de aplicacin.
Las estandarizaciones ISO (International Standard Organization), a diferencia
de las normas BOSCH, especifican tambin el medio de comunicacin. Por lo
tanto una implementacin CAN a partir de las especificaciones de BOSCH no
siempre ser compatible con las normas ISO.

2.1.1. Capa fsica

La capa fsica de CAN, es responsable de la transferencia de bits entre los
distintos nodos que componen la red. Define aspectos como niveles de seal,
codificacin, sincronizacin y tiempos en que los bits se transfieren al bus.
En la especificacin original de CAN , la capa fsica no fue definida, permitiendo
diferentes opciones para la eleccin del medio y niveles elctricos de
transmisin. Las caractersticas de la seales elctricas en el bus, fueron
establecidas ms tarde por el ISO 11898 para las aplicaciones de alta
velocidad y, por el estndar ISO 11519 para las aplicaciones de baja velocidad

18

Estndar 11519

Los nodos conectados en este bus interpretan dos niveles lgicos

denominados: Dominante y Recesivo.
-

Dominante: la tensin 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 tensin 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 seal CAN_H y RTL para la
seal CAN_L. Esta configuracin 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

Estndar 11898

Los nodos conectados en este bus interpretan los siguientes niveles lgicos:
-

Dominante: la tensin 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 tensin 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 transmisin de

lnea. Si dicha transmisin de lnea no est configurada con los valores
correctos, cada trama transferida causa una reflexin que puede originar fallos
de comunicacin. Como la comunicacin en el bus CAN fluye en ambos
sentidos, ambos extremos de red deben de estar cerrados mediante una
resistencia de 120. Ambas resistencias deberan 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
lgico 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 administracin de la
recuperacin.

El subnivel MAC (Medium Acces Control): Es el ncleo 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
sealizacin, el aislamiento de fallos en unidades de control y la
identificacin del estado libre del bus para iniciar una transmisin o
recepcin de un nuevo mensaje.

21

2.2. Estructura de un nodo CAN

Dentro de un nodo CAN, se pueden distinguir una serie de mdulos
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 aplicacin y el controlador de red de alto nivel),
los dispositivos de entrada y salida y, la interfaz de comunicacin.
Desde el punto de vista del controlador, la interfaz de comunicacin se puede
ver como un conjunto de buzones, donde cada uno de estos sirve como
registro lgico de interfaz entre el controlador local y los nodos remotos. Si un
nodo quiere comunicarse,
tiene que dar de alta los correspondientes buzones de recepcin y transmisin
antes de hacer ninguna operacin.

22

Teniendo en cuenta esta arquitectura, el funcionamiento sigue los siguientes

pasos:
-

Para inicializar, el programador especifica los parmetros de los

registros de control de interfaz de comunicacin, como las
caractersticas del controlador de red o la velocidad de
transmisin.
A continuacin, se actualizan todos los buzones. En cada buzn
se especifica si es receptor o transmisor y, su estado inicial,
inicializando su parte de datos del bfer.
Posteriormente, para transmitir un mensaje es necesario poner
los datos en el bfer de datos correspondiente al buzn de
transmisin y activar el flanco de transmisin.
Por ltimo, la interfaz de red intenta comunicar los datos a travs
de la red. El estado de la transferencia se puede comprobar en el
estatus de estado de cada buzn.

Una vez hecha la configuracin inicial a partir del software de la capa de

aplicacin de esta manera, los nodos CAN funcionarn de forma autnoma.

2.3. Formato de codificacin y sincronizacin de datos.

La codificacin de bits se realiza por el mtodo NRZ (Non-Return-to Zero) que
se caracteriza por que el nivel de seal puede permanecer constante durante
largos periodos de tiempo y habr que tomar medidas para asegurarse de que
el intervalo mximo permitido entre dos seales no es superado. Esto es
importante para la sincronizacin (Bit Timing).
Este tipo de codificacin requiere poco ancho de banda para transmitir, pero en
cambio, no puede garantizar la sincronizacin de la trama transmitida. Para
resolver esta falta de sincronismo se emplea la tcnica del bit stuffing: cada 5
bits consecutivos con el mismo estado lgico en una trama (excepto del
delimitador de final de trama y el espacio entre tramas), se inserta un bit de
diferente polaridad, no perdindose as la sincronizacin. Por otro lado este bit
extra debe ser eliminado por el receptor de la trama, que slo lo utilizar para
sincronizar la transmisin.
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 seal
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 segn le interese o no.
Existen distintos tipos de tramas predefinidas por CAN para la gestin de la
transferencia de mensajes:
-

Trama de datos: Se utiliza normalmente para poner informacin en el

bus y la pueden recibir algunos o todos los nodos.

Trama de informacin remota: Puede ser utilizada por un nodo para

solicitar la transmisin de una trama de datos con la informacin
asociada a un identificador dado. El nodo que disponga de la
informacin definida por el identificador la transmitir en una trama
de datos.

Trama de error: Se generan cuando algn nodo detecta algn error

definido.

Trama de sobrecarga: Se generan cuando algn nodo necesita ms

tiempo para procesar los mensajes recibidos.

Espaciado entre tramas: Las tramas de datos (y de interrogacin

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 informacin espontneamente con

tramas de datos, bien sea por un proceso cclico o activado ante eventos en el
nodo. La trama de interrogacin remota slo se suele utilizar para deteccin de
presencia de nodos o para puesta al da de informacin en un nodo recin
incorporado a la red. Los mensajes pueden entrar en colisin en el bus, el de
identificador de mayor prioridad sobrevivir y los dems son retransmitidos lo
antes posible.

24

2.4.2. Trama de datos

Es la utilizada por un nodo normalmente para poner informacin en el bus.

Puede incluir entre 0 y 8 bytes de informacin til.

Los mensajes de datos consisten en celdas que envan datos y aaden

informacin definida por las especificaciones CAN:

Inicio de trama (SOF): El inicio de trama es una celda de un slo bit

siempre dominante que indica el inicio del mensaje, sirve para la
sincronizacin con otros nodos.

Celda de Arbitraje (Arbitration Field): Es la celda que concede

prioridad a unos mensajes o a otros:
En formato estndar tendr 11 bits seguidos del bit RTR (Remote
Transmisin Request) que en este caso ser dominante.

25

En formato extendido sern 11 bits de identificador base y 18 de

extendido. El bit SRR substituye al RTR y ser recesivo.

NOTA: La trama en formato estndar 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 nmero de bytes de datos. En realidad el primero de estos
bits (IDE) se utiliza para indicar si la trama es de CAN Estndar (IDE
dominante) o Extendido (IDE recesivo). El segundo bit (RB0) es
siempre recesivo. Los cuatro bits de cdigo de longitud (DLC) indican
en binario el nmero 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: Cdigo de redundancia cclica: Tras comprobar este cdigo 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 mnimo de 3 bits

recesivos.

26

2.4.3 Trama remota (Remote Frame)

Los nodos tienen habilidad para requerir informacin a otros nodos. Un nodo
pide una informacin a los otros y el nodo que tiene dicha informacin enva
una comunicacin con la respuesta que puede ser recibida adems por otros
nodos si estn interesados.

Un mensaje de peticin remota tiene la siguiente forma:

En este tipo de mensajes se enva 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 enve un mensaje de datos y de peticin 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 comunicacin limpiamente tras el error.
El Indicador de error es distinto segn 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

comunicacin 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 generacin 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 delimitacin de
error formado por los 8 bits recesivos. Entonces la comunicacin se reinicia y el
nodo que haba sido interrumpido reintenta la transmisin 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 transmisin de una trama de error de tipo
pasivo no afectar a ningn nodo en la red, excepto cuando el error es
detectado por el propio nodo que est transmitiendo. En ese caso los dems
nodos detectarn una violacin de las reglas de relleno y transmitirn a su vez
tramas de error.
Tras sealar un error por medio de la trama de error apropiada cada nodo
transmite bits recesivos hasta que recibe un bit tambin recesivo, luego
transmite 7 bits recesivos consecutivos antes de finalizar el tratamiento de
error.

28

La regla de relleno de bits que aparece lneas 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 mtodo para la deteccin de errores es el chequeo de la trama:

El campo CRC contiene informacin 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
monitorizacin, 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 slo puede generarse durante el espacio
entre tramas. De esta forma se diferencia de una trama de error, que slo
puede ser transmitida durante la transmisin 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 mximo 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 recepcin de un
nuevo mensaje. De esta forma retrasa el inicio de transmisin de un nuevo
mensaje. Un nodo puede generar como mximo 2 tramas de sobrecarga
consecutivas para retrasar un mensaje. Otra razn para iniciar la transmisin
de una trama de sobrecarga es la deteccin 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 generacin
de tramas de sobrecarga por los dems nodos dando lugar, como se ha
indicado, a un mximo 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 interrogacin 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 transmisin o el bus permanecer en reposo.
Para un nodo en estado error pasivo la situacin es diferente, deber espera
una secuencia adicional de 8 bits recesivos antes de poder iniciar una
transmisin. De esta forma se asegura una ventaja en inicio de transmisin a
los nodos en estado activo frente a los nodos en estado pasivo.

30

2.5 Acceso mltiple y arbitraje de acceso al bus

Unas de las caractersticas que distingue a CAN con respecto a otras normas,
es su tcnica de acceso al medio denominada como CSMA/CD+CR o "Carrier
Sense, Multiple Access/Collision Detection + Collision Resolution" (Acceso
Mltiple con deteccin de portadora, deteccin de colisin ms Resolucin de
colisin). Cada nodo debe vigilar el bus en un periodo sin actividad antes de
enviar un mensaje (Carrier Sense) y adems, 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 unsono se
detectar la colisin.
El mtodo de acceso al medio utilizado en bus CAN aade una caracterstica
adicional: la resolucin de colisin. En la tcnica CSMA/CD utilizada en redes
Ethernet ante colisin de varias tramas, todas se pierden. CAN resuelve la
colisin con la supervivencia de una de las tramas que chocan en el bus.
Adems la trama superviviente es aquella a la que se ha identificado como de
mayor prioridad.
La resolucin de colisin se basa en una topologa elctrica que aplica una
funcin lgica 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 lgico '0' y bit recesivo al nivel lgico '1' se trata de una
funcin AND de todos los bits transmitidos simultneamente. 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 transmisin continua, finalmente el mensaje con identificador de mxima
prioridad sobrevive. Los dems nodos reintentarn la transmisin lo antes
posible.
Se ha de tener en cuenta que la especificacin CAN de Bosh no establece
cmo se ha de traducir cada nivel de bit (dominante o recesivo) a variable
fsica. Cuando se utiliza par trenzado segn ISO 11898 el nivel dominante es
una tensin diferencial positiva en el bus, el nivel recesivo es ausencia de
tensin, o cierto valor negativo, (los transceptores no generan corriente sobre
las resistencias de carga del bus). Esta tcnica aporta la combinacin de dos
factores muy deseados en aplicaciones industriales distribuidas: la posibilidad
de fijar con determinismo la latencia en la transmisin de mensajes entre nodos
y el funcionamiento en modo multimaestro sin necesidad de gestin 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
transmisin 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 automvil existe la variable
presin 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
codificacin de la informacin en el campo de datos.
En la siguiente figura se ve un ejemplo de arbitraje en un bus CAN.

32

2.6. Deteccin de Errores

Una de las caractersticas ms 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
deteccin 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
errneas. 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. Deteccin 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 errnea detecta el error flan, transmite la
trama de nuevo. Los dispositivos CAN detectan los errores siguientes:
-

Error de bit: Durante la transmisin 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. Adems, no se considera error de bit la deteccin 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

deteccin de 6 bits consecutivos del mismo signo, en cualquier
campo que siga la tcnica de relleno de bits, donde por cada 5 bits
iguales se aade 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 deteccin de 5 bits errneos por
mensaje. Estas medidas sirven para detectar errores de transmisin
debido a posible incidencias en el medio fsico 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 ningn nodo cambia a dominante el bit de reconocimiento.

33

Si un nodo advierte alguno de los fallos mencionados, iniciar la transmisin de

una trama de error. El protocolo CAN especifica diversos fallos en la lnea fsica
de comunicacin, como por ejemplo lnea desconectada, problemas con la
terminacin de los cables o lneas 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 especificacin 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 relacin a la gestin
de errores:
-

Error Activo (Error Active): Es el estado normal de un nodo. Participa

en la comunicacin y en caso de deteccin de error enva una trama
de error activa

Error pasivo (Error Passive): Un nodo en estado de error pasivo

participa en la comunicacin, sin embargo ha de esperar una
secuencia adicional de bits recesivos antes de transmitir y slo puede
sealar errores con una trama de error pasiva.

Anulado (Bus Off): En este estado, deshabilitar su transceptor y no

participar en la comunicacin.

La evolucin entre estos estados se basa en dos contadores incluidos en el

controlador de comunicaciones. Contador de errores de transmisin (TEC) y
Contador de errores de recepcin (REC).

Evolucin entre estados de error.

34

2.7. Especificaciones
CAN tiene dos formatos diferentes para transmitir datos: el formato de trama
estndar (Standard Frame), segn la especificacin CAN 2.0A y, el formato de
trama extendida (Extended Frame) segn la especificacin CAN 2.0B. La
principal diferencia entre ambos es la longitud del identificador del mensaje
(ID), que en el caso de la trama estndar es de 11 bits (2032 identificadores, ya
que los 16 bits identificadores de menor prioridad estn 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 estndar. Si el formato es extendido se producir un error.

Controladores 2.0B pasivos: nicamente transmiten y reciben

mensajes en formato estndar, pero admiten la recepcin 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 ms simple, para llevar a cabo una comunicacin 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 pgina 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 sera 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 especfica para este tipo de
comunicaciones, que desarrolla adems este tipo de arquitectura y que se
puede conseguir tambin a travs de la pgina web de microchip.

Integrated CAN Controller

Este tipo de arquitectura consiste en un microcontrolador que incluya, no slo

sus caractersticas propias sino adems un mdulo CAN con las caractersticas
de un microcontrolador CAN. El transceiver se sita de manera separada. Este
es el caso de nuestro microcontrolador dSPIC30F4013. El mdulo del
transceptor acta como un controlador de lnea, balanceando la seal, esto es,
adecuando los niveles de tensin 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. Caractersticas bsicas

Se trata de una interfaz serie, utilizada para la comunicacin con otros mdulos
CAN u otros dispositivos del propio microcontrolador.
El mdulo 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 travs del
bus. El estado y los errores de la transmisin pueden consultarse leyendo en
los registros apropiados. Adems, como ya sabemos, cualquier mensaje
detectado en el bus es sometido a un control de errores y despus es filtrado
para comprobar si debera ser recibido y almacenado en uno de los registros
de recepcin, o debera por lo contrario ser rechazado.
Bsicamente las caractersticas tcnicas del mdulo 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 estndar 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 bfer, con dos bufers de almacenamiento de

mensajes con prioridad recibidos (cada bfer puede contener hasta 8
bytes de datos).

6 filtros de aceptacin completa (full acceptance filter), tanto para

mensajes con identificador estndar como extendido. De ellos, 2 estn
asociados con el bfer de recepcin de prioridad alta y 4 lo estn
asociados con el bfer de recepcin de prioridad baja.

2 mscaras de filtro de aceptacin completa (full acceptance filter

masks), cada una de ellas asociada a los bufers de recepcin de alta o
de baja prioridad.

3 bufers de transmisin con asignacin de prioridades especficas y

capacidad de aborto (cada bfer puede contener hasta 8 bytes de datos)

Funcin de despertador (wake-up) programable con filtros paso-bajo

integrados.

Modo Loopback programable con operacin de auto-test (self-test).

39

Capacidad de sealizacin a travs de interrupciones por parte de todos

los receptores y transmisores de estados de error CAN.

Reloj fuente (clock source) programable.

Enlace programable al mdulo de captura de entrada (IC2, tanto para

CAN1 como para CAN2) para la funcin time-stamping (marcas de
tiempo) y sincronizacin 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 tensin
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 nmero en el mercado, hemos escogido un modelo
compatible para explicar como seran las conexiones y una breve explicacin
de su funcionamiento.

Este transceptor puede direccionar

una carga mnima de 45 Ohms,
permitiendo conectarse a un mximo
de 112 nodos.
La entrada del transceptor, RXD,
proporciona el diferencial de tensin
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 electromagnticas disminuyendo los
tiempos de subida y de cada de CANH y CANL. Este control se logra mediante
una resistencia entre Rs y Ground (masa). La tasa de ralentizacin 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 ms lenta.
41

La conexin fsica sera a travs de los pines C1RX (recepcin CAN del micro),
C1TX (transmisin CAN del micro) del microcontrolador, con los pines RXD y
TXD del transceptor. Recordar que la funcin del transceptor es la de adecuar
la seal de entrada del bus a la del sistema. Esta entrada de seal del bus se
efecta a travs de los patillas CANH y CANL del transceptor.
Aqu vemos la conexin 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 mdulo puede trabajar en uno de entre varios modos de funcionamiento,
previamente escogido por el usuario entre:
-

Modo de inicializacin (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 travs de los bits RXM<1:0> (CiRXnCON<6:5>, donde n=0 o n=1
representan un bfer de recepcin en particular). La entrada en un modo se
reconoce observando los bits del registro OPMODE<2:0> (CiCTRL<7:5>). El
mdulo 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 envan al menos 11 bits recesivos consecutivos.

Modo de inicializacin (Initialization mode)

En este modo, el mdulo no puede transmitir ni recibir datos. Al seleccionarlo,
los contadores de error se ponen a 0 y las banderas de interrupcin (interrupt
flags) permanecen inalterables. A la hora de programar, desde l tendremos
acceso a ciertos registros de configuracin a los cuales no se puede acceder
desde ningn otro modo. Adems, el mdulo nos proteger de violaciones
accidentales del protocolo CAN que podamos causar durante la programacin.
Para poder acceder al modo de configuracin (Configuration mode) no se
puede estar en mitad de una transmisin; es por ello que ninguno de los
registros que controlan la configuracin del mdulo puede ser modificado
mientras el mdulo est conectado. El susodicho modo de configuracin ejerce
de cerrojo para proteger los siguientes registros:
-

Registros de control del mdulo (Module control registers)

Registros de tasa (velocidad de transmisin) en baudios (Baud rate
registers) y registros de configuracin de interrupciones (Interrupt
configuration registers)
Registros de temporizacin del bus (Bus timing registers)
Registros identificadores de los filtros de aceptacin (Identifier
acceptance filter registers)
Registros identificadores de las mscaras de aceptacin (Identifier
acceptance mask registers).

43

Modo deshabilitado (Disable mode)

En este modo, el mdulo tampoco transmite ni recibe datos.
Si hay actividad en el bus, el mdulo 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 mdulo entrar en el modo
deshabilitado. Si en ese momento el mdulo 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); despus aceptar el
comando de mdulo deshabilitado (module disable command). Cuando los bits
OPMODE<2:0> (CiCTRL<7:5>) = 001, el mdulo habr entrado
satisfactoriamente al modo. Los pins de entrada/salida (I/O) volvern a su
funcin normal cuando el mdulo est en el modo de mdulo inutilizado
(Module Disable mode).
El mdulo puede ser programado para aplicar un filtro paso-bajo a la lnea de
entrada CiRX, mientras el mdulo o la CPU estn en modo dormido (Sleep
mode). El bit WAKFIL (CiCFG2<14>) es el que activa o desactiva este filtro.
NOTA:
Si el mdulo va a trabajar en un modo de funcionamiento particular y es
solicitada una transmisin inmediatamente despus de que el mdulo CAN se
haya colocado en ese modo de funcionamiento, esperar 11 bits recesivos
consecutivos en el bus antes de empezar la transmisin. Si el usuario decide
cambiar al modo deshabilitado (disable mode) dentro del periodo de esos 11
bits recesivos, la transmisin 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 mdulo se activa y los pins de
entrada/salida (I/O) asumen las funciones del bus CAN, es decir, el mdulo
transmitir y recibir mensajes del bus a travs de los pins CxTX y CxRX.

Modo de solo escucha (Listen only mode)

Cuando activamos este modo, el mdulo est pasivo. Los bufers de
transmisin funcionan como puertos de entrada/salida (I/O), y los pins
receptores por su parte, continan como entradas. El receptor deja de enviar
banderas de error (error flags) y seales 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 transmisin) 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 mdulo es fijado para ignorar todos los errores y poder recibir as
cualquier mensaje que se ha enviado a travs del bus. Para activarlo, debemos
poner los bits de REQOP<2:0> = 111. En este modo, los datos que estn en
el buffer de ensamblado de mensajes (message assembly buffer) hasta que
ocurre un error, son copiados en el bfer de recepcin y pueden ser ledos a
travs de la interfaz de la CPU.

Modo loopback (Loopback mode)

Cuando el modo loopback se activa, la seal interna de transmisin y la seal
interna de recepcin se conectan en el lmite del mdulo, formando una
especie de bucle cerrado. Los pins de transmisin y de recepcin vuelven a sus
funciones de puerto de entrada/salida I/O.

45

3.4. Recepcin de mensajes

Bufers de recepcin
El mdulo del bus CAN tiene 3 bufers de recepcin. No obstante, uno de los
bufers de recepcin se dedica continuamente a escuchar el bus en espera de
mensajes entrantes. Este bfer se llama Bfer de ensamblado de mensajes
(Message Assembly Buffer o MAB). Por tanto hay 2 bufers de recepcin
visibles, RXB0 y RXB1, que pueden recibir simultneamente 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 aceptacin. 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 bfer. Si el bit RXiIE (CiINTE <0> o CiINTE <1>) est a 1, se
generar una interrupcin cuando se reciba un mensaje. Los filtros RXF0 y
RXF1 con la mscara RXM0 estn asociados con RXB0. Los filtros RXF2,
RXF3, RXF4 y RXF5 y la mscara RXM1 estn asociados con RXB1.

Filtros de aceptacin de mensajes

Los filtros y mascaras de aceptacin de mensajes se usan para determinar si
un mensaje del bfer de ensamblado de mensajes debe ser cargado en alguno
de los bufers de recepcin. Una vez un mensaje vlido ha sido recibido por el
MAB, los campos de identificacin del mensaje son comparados con los
valores de los filtros. Si hay una coincidencia, ese mensaje ser cargado en el
bfer de recepcin apropiado.
El filtro de aceptacin 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 estndar 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.

Mscaras de filtro de aceptacin de mensajes

Los bits de mscara determinan que bits se han de aplicar en el filtro. Si un bit
de mscara est a cero, entonces este bit ser aceptado automticamente
independientemente del bit de filtro. Hay 2 mscaras de filtro de aceptacin
programables, asociadas con los bufers de recepcin, una por cada bfer.

46

Sobrecarga de recepcin:
Esta condicin de sobrecarga se da cuando el MAB ha ensamblado un
mensaje recibido vlido, cuando el mensaje es aceptado a travs del filtro de
aceptacin, y cuando el bfer de recepcin asociado con el filtro no ha sido
designado como vaco 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 ledo 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 vlido 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 estn llenos, por lo tanto, el mensaje se
perder y se generar un mensaje de error de sobrecarga para RXB1.

Errores de recepcin
El Modulo CAN puede detectar los siguientes errores de recepcin:
- Error de Chequeo de Redundancia Cclica (CRC)
- Error de Relleno de Bits (Bit Stuffing Error)
- Error de Mensaje Invlido Recibido
Estos errores de recepcin no generan una interrupcin. Sin embargo, si que
se incrementa el contador de errores de recepcin. El bit RXWAR (CiINTF<9>)
indica que el contador de errores de recepcin ha alcanzado el lmite de
advertencia de la CPU (este lmite es 96) y se genera una interrupcin.

Interrupciones de recepcin
Las Interrupciones de recepcin se pueden dividir en 3 grandes grupos, cada
uno de ellos incluye varias condiciones que generan interrupciones:
- Interrupcin de recepcin: Un mensaje se ha recibido correctamente
y se ha cargado en uno de los bufers de recepcin. Esta interrupcin
se activa inmediatamente despus de recibir el campo Fin de Trama
(EOF). El flag RXnIF indica que buffer de recepcin ha causado la
interrupcin.
- Interrupcin de despertador (Wake-up Interrupt): El mdulo CAN se
ha despertado del modo Deshabilitado (Disable) o el dispositivo se
ha despertado del modo Durmiendo (Sleep)
- Interrupcin de error de recepcin: Una interrupcin de error de
recepcin se seala en el bit ERRIF. La fuente del error puede ser
determinada comprobando los bits del registro Estatus de
Interrupcin CAN, CiINTF.

47

Mensaje Invlido Recibido: Si ocurre algn tipo de error durante la

recepcin 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 recepcin (RERRCNT<7:0>) ha alcanzado el lmite de
advertencia de 96.
Error de Recepcin Pasivo: El bit RXEP indica que el contador de
errores de recepcin ha excedido el lmite de error pasivo de 127 y el
mdulo ha entrado en el estado error pasivo.

3.5. Transmisin de mensajes

Bufers de transmisin:
El mdulo CAN tiene 3 bufers de transmisin. Cada uno de los 3 bufers de
transmisin ocupa 14 bytes de datos. Ocho de los bytes son los 8 bytes que
puede ocupar como mximo el mensaje transmitido. Cinco bytes son los
identificadores estndar y extendidos y otra informacin de control del mensaje.

Prioridad de transmisin del mensaje:

La prioridad de transmisin es una priorizacin dentro de cada nodo de los
mensajes pendientes de transmitir. Hay 4 niveles de prioridad de transmisin.
Si TXPRI<1:0> (CiTXnCON<1:0>, donde n = 0, 1 o 2 representa el bfer de
transmisin en particular) para un bfer de mensaje en particular se establece a
11, ese bfer tiene la mxima prioridad. Si TXPRI<1:0> para un bfer de
mensaje en particular se establece a 10 o a 01, ese bfer tiene una prioridad
intermedia. Si TXPRI<1:0> para un bfer de mensaje en particular se establece
a 00, ese bfer tiene la mnima prioridad.

Secuencia de transmisin:
Para iniciar la transmisin del mensaje, el bit TXREQ (CiTXnCON<3>) debe
ponerse a 1. El mdulo 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 automticamente.
Poner a 1 el bit TXREQ simplemente marca un bfer de mensaje como puesto
en cola para transmisin. Cuando el mdulo detecta el bus disponible, empieza
a transmitir el mensaje que tiene mayor prioridad.

48

Si la transmisin se completa satisfactoriamente en el primer intento, el bit

TXREQ se pone a 0 automticamente y se genera una interrupcin si TXIE
haba sido activado.
Si la transmisin del mensaje falla, se activa uno de los avisos de condicin de
error y el bit TXREQ permanece a 1, indicando que el mensaje est an
pendiente de transmisin. Si el mensaje encuentra una condicin de error
durante el intento de transmisin, el bit TXERR se pone a 1 y puede causar una
interrupcin. Si el mensaje pierde arbitraje durante el intento de transmisin, se
pone a 1 el bit TXLARB. No se genera interrupcin para indicar la perdida de
arbitraje.

Abortando la transmisin del mensaje:

El sistema tambin puede abortar el envo de un mensaje poniendo a 0 el bit
TXREQ asociado con cada bfer de mensaje. Poniendo a 1 el bit ABAT
(CiCTRL<12>) se solicita abortar todos los mensajes pendientes. Si el mensaje
an no ha iniciado la transmisin, o si el mensaje la ha iniciado pero es
interrumpida por prdida 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 automticamente.

Errores de transmisin
El modulo CAN detecta los siguientes errores de transmisin:
- Error de Ack
- Error de forma
- Error de bit
Estos errores de transmisin no generan necesariamente una interrupcin,
pero son indicados por el contador de errores de transmisin, incrementndolo
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. Adems, se
genera una interrupcin y se pone a 1 el bit TXWAR del registro de banderas
de error.

Interrupciones de transmisin
Las Interrupciones de transmisin se pueden dividir en 2 grandes grupos, cada
uno de estos incluye varias condiciones que generan interrupciones:
-

Interrupciones de transmisin: Al menos uno de los tres bufers de

transmisin est vaco y puede ser cargado para programar una
transmisin de mensaje. Los flags TXnIF indican que bfer de
transmisin est disponible y ha sido el causante de la interrupcin.
Interrupciones de errores de transmisin: Una interrupcin error de
transmisin 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 Interrupcin del CAN, CiINTF. Los flags de este registro estn

relacionados con los errores de transmisin y de recepcin.
Interrupcin de Advertencia del Transmisor: El bit TXWAR indica que
el contador de errores de transmisin ha alcanzado el lmite de
advertencia de la CPU (96).
Error Pasivo del Transmisor: El bit TXEP (CiINTF<12>) indica que el
contador de errores de transmisin ha superado el lmite 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 transmisin ha superado 255 y el mdulo ha entrado en el estado
de bus off.

50

3.6. Temporizacin y sincronizacin de bits

3.6.1. Temporizacin de bits
Las seales elctricas del bus sufren las alteraciones propias de la distorsin
que se produce, tanto por las caractersticas fsicas de la lnea, los retardos de
propagacin, y los retardos producidos en los propios controladores, como por
las posibles fuentes externas de interferencia electromagntica.
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 resincronizacin 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 simultnea, ya que es prcticamente
imposible que esten completamente sincronizados; y adems la frecuencia del
oscilador de ambos puede ser ligeramente distinta. Los receptores que se han
sincronizado con el primer flanco de bajada detectado, debern ir
resincronizndose sucesivamente a los flancos producidos por el nodo que
acabe transmitiendo.
CAN utiliza sealizacin asncrona y un tipo de codificacin NRZ, en la que
normalmente 0V representa un 0 lgico, y 5V representa un 1 lgico. Es
necesaria, por tanto, una operacin de muestreo por parte de los receptores,
que se han de resincronizar peridicamente. Adems, la tasa de transmisin
(desde menos de 1 kbps hasta 1 Mbps) tambin es un factor determinante.
Todos estos parmetros pueden programarse individualmente y ser ejecutados
por el reloj lgico de CAN (Bit Timing Logic).
Para que el controlador, que es un sistema digital sncrono con una frecuencia
de reloj generada por un oscilador (generalmente un oscilador de cuarzo),
pueda muestrear la seal asncrona recibida con seguridad y precisin ha de
utilizar una frecuencia de muestreo superior a la de la seal transmitida.
Por otra parte, el controlador ha de utilizar una frecuencia de reloj que sea
mltiplo de la frecuencia nominal de bit (nmero 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 comunicacin a la que queda configurado el controlador, para
un oscilador de cierta frecuencia, queda definida por el valor del divisor de
frecuencia (BRP), tambin configurable, y por el nmero 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 ecuacin:

TQ =

2( BRP < 5 : 0 > +1)

FCAN

donde FCAN es FCY (si el bit CANKS est puesto a 1) o 4FCY (si CANKS
est puesto a 0). Adems, 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=4FCY en este caso.
Adems, para asegurar la funcionalidad de la red, se incluye en una posicin
concreta del tiempo de bit (del cual hablaremos ms adelante), un punto de
muestreo (sample point en ingls). Este es el punto exacto en el que el nivel de
bus es ledo e interpretado como el valor de ese respectivo bit.
En algunos microcontroladores, entre los que se incluye dsPIC30F4013, si la
temporizacin de bits se retrasa y contiene muchos TQ, es posible realizar
tambin, un muestreo mltiple sobre el bus. En este caso, las muestras para
realizar el clculo pueden ser tomadas en el punto de muestreo o en dos
posiciones anteriores a este con una distancia de TQ/2. Adems, el mdulo
CAN permite al usuario elegir entre muestrear tres veces en el mismo punto o
una vez en cada uno de los tres puntos, segn 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 mayora de tres valores. Para asegurar la validez del clculo,
este muestreo debe ocupar del 60 al 70 por ciento del tiempo de bit,
dependiendo de los parmetros del sistema.

3.6.2. Resincronizacin de bits (Resynchronization)

La resincronizacin consiste en el acortamiento o alargamiento del tiempo de
bit (o nmero de TQ por bit) para que el punto de muestreo se desplace con
relacin al ltimo flanco recesivo-dominante detectado. Esta decisin la toma el
controlador tras detectar el flanco y evaluar el error.
En CAN se siguen dos mtodos de sincronizacin del muestreo con la
secuencia de bits de la trama:
-

Sincronizacin de trama ("Hard Synchronization"): Es la reinicializacin

de la lgica de muestreo de bit que ocurre ante el flanco de bajada (paso
de recesivo a dominante) producido por un bit de inicio de trama.

Resincronizacin o sincronizacin intra-trama ("Soft Synchronization" o

Resyncronization): Es un proceso de sincronizacin que ocurre en cada
flanco de bajada que se produce durante la transmisin de la trama.

52

Puede producir el alargamiento o el acortamiento de los segmentos de

fase de los que hablamos en la siguiente seccin.

3.6.3. Parmetros del tiempo de bit nominal

El tiempo de bit nominal se ide como una divisin del tiempo en segmentos
separados y no superpuestos. El microcontrolador dsPIC30F4013 define para
el tiempo de bit nominal un mnimo de 8 TQ y un mximo de 25 TQ, mientras
que define el mnimo tiempo de bit nominal como 1 segundo, correspondiente
a una tasa mxima (velocidad de transmisin mxima) en bits de 1 MHz.
Su esquema grfico es el siguiente:

Se puede observar como el punto de muestreo del bit (sample point) se realiza
inmediatamente despus 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 sincronizacin (Sync_Seg): En este intervalo se espera

que se produzca cualquier cambio de recesivo a dominante en el bus.
Su duracin es de 1 TQ.

Segmento de propagacin (Prop_Seg): Est orientado a la

compensacin del retardo de tiempo de la red. Este retardo es la suma
del provocado por la lnea y el debido a la electrnica de la interfaz de
los controladores. El segmento puede configurarse como de 1 a 8 TQ de
duracin poniendo a 1 los bits PRSEG<2:0> (CiCFG2<2:0>).

Segmento de fase 1 (Phase_Seg1): Este segmento est orientado a la

deteccin y reajuste de desfases entre nodos. Puede configurarse como
de 1 a 8 TQ de duracin poniendo a 1 los bits SEG1PH<2:0>
(CiCFG2<5:3>), aunque puede alargarse en operaciones de
resincronizacin.

53

Segmento de fase 2 (Phase_Seg2): Es el encargado de retrasar la

siguiente transicin de datos a transmitir. Su valor mximo puede ser
igual al segmento de fase 1 ms grande o al tiempo de procesado de la
informacin (2 TQ). El segmento es programable desde 1TQ hasta 8 TQ
de duracin poniendo a 1 los bits SEG2PH<2:0> (CiCFG2<10:8>).
Puede acortarse (nunca menos del tiempo de procesado de la
informacin) en las operaciones de resincronizacin.

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 resincronizacin, se
define un parmetro adicional: el salto de resincronizacin (Sjw o
Resynchronization jump width) que establece el valor del salto mximo que se
pueda llegar a efectuar como producto de la resincronizacin. En
dsPIC30F4013 se especifica a travs 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 parmetro o bien ser
aadido 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. Programacin
3.7.1. MPLAB
MPLAB es un software que junto con un emulador y un programador de los
mltiples que existen en el mercado, forman un conjunto de herramientas de
desarrollo muy completo para el trabajo y/o el diseo con los
microcontroladores PIC y dsPIC desarrollados y fabricados por la empresa
Arizona Microchip Technology (AMT). MPLAB incorpora todas las utilidades
necesarias para la realizacin de cualquier proyecto y, si no se dispone de un
emulador, el programa permite editar el archivo fuente en lenguaje
ensamblador de nuestro proyecto, adems de ensamblarlo y simularlo en
pantalla, pudiendo ejecutarlo posteriormente en modo paso a paso y ver como
evolucionaran de forma real tanto sus registros internos, la memoria RAM y/o
EEPROM de usuario como la memoria de programa, segn se fueran
ejecutando las instrucciones. Adems el entorno que se utiliza es el mismo que
si se estuviera utilizando un emulador.
Nosotros, durante el desarrollo de la asignatura, utilizaremos la versin MpLab
30 v2 student edition (edicin gratuita que podemos adquirir en la pgina oficial
de Microchip) la cual presenta algunas limitaciones respecto al software original
pero que para nuestro trabajo es ms que suficiente ya que permite simular
directamente sobre la placa de pruebas.
Como ya hemos comentado, la utilizacin de MpLab requiere un emulador de
lenguajes de alto nivel, para evitar la utilizacin 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 fotografa.

55

3.7.2. Funciones
Esta seccin 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 mdulo CAN, ya que a travs de ellas podemos
realizar acciones sin tener que cambiar manualmente los valores de los bits de
ciertos registros. Adems, pueden ser puestas en prctica como macros.
Las siguientes funciones definen a toda la familia dsPIC30f, en nuestro caso el
dsPIC30F4013 solamente tiene un CAN.

Funciones individuales

CAN1AbortAll
CAN2AbortAll
Descripcin:
Include:
Prototipo:
Argumentos:
Valores de retorno:
Comentarios:
Archivo de origen:
Ejemplo de cdigo:

CAN1GetRXErrorCount
CAN2GetRXErrorCount
Descripcin:
Include:
Prototipo:
Argumentos:
Valores de retorno:
Comentarios:

Archivo de origen:
Ejemplo de cdigo:

Esta funcin aborta inicialmente todas las

transmisiones pendientes.
can.h
void CAN1AbortAll(void);
void CAN2AbortAll(void);
Ninguno
Ninguno
CAN1AbortAll.c
CAN2AbortAll.c
CAN1AbortAll();

Esta funcin 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 funcin devuelve el contenido de
CIRERRCNT (el bit ms 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
Descripcin:
Include:
Prototipo:
Argumentos:
Valores de retorno:
Comentarios:

Archivo de origen:
Ejemplo de cdigo:

CAN1sBusOff
CAN2sBusOff
Descripcin:
Include:
Prototipo:
Argumentos:
Valores de retorno:

Comentarios:
Archivo de origen:
Ejemplo de cdigo:

CAN1sRXReady
CAN2sRXReady
Descripcin:
Include:
Prototipo:
Argumentos:
Valores de retorno:

Esta funcin 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 funcin 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 funcin 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 transmisin.
Si el valor de TXBO es 0, ese 0 es devuelto,
indicando que el bus no ser cambiado a off.
Esta funcin devuelve el estado del bit TXBO
del registro CilNTF.
CAN1IsBusOff.c
CAN2IsBusOff.c
While (CAN1IsBusOff());

Esta funcin devuelve el estado del bfer de

recepcin.
can.h
Char CAN1IsRXReady(char);
Char CAN2IsRXReady(char);
Buffno: el valor de buffno indica cual es el
estado requerido para el bufer de recepcin.
Si RXFUL es 1, esto indica que el buffer de
recepcin contiene un mensaje recibido.
Si RXFUL es 0, esto indica que el bufer de
recepcin esta abierto para recibir un mensaje

57

Comentarios:

Archivo de origen:
Ejemplo de cdigo:

CAN1sRXPassive
CAN2sRXPassive
Descripcin:
Include:
Prototipo:
Argumentos:
Valores de retorno:

Comentarios:
Archivo de origen:
Ejemplo de cdigo:

CAN1sTXPassive
CAN2sTXPassive
Descripcin:
Include:
Prototipo:
Argumentos:
Valores de retorno:

Comentarios:
Archivo de origen:
Ejemplo de cdigo:

nuevo.
Esta funcin devuelve el estado del bit RXFUL
del registro de control de recepcin (control
register)
CAN1IsRXReady.c
CAN2IsRXReady.c
char rx_1_status;
rx_1_status = CAN1IsRXReady(1);

Esta funcin determina si la recepcin 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 recepcin.
Si el valor de RXEP es 0, el cero es devuelto,
indicando que no hay error en el bus.
Esta funcin devuelve el estado del bit RXEP
del registro CiiNTF.
CAN1IsRXPassive.c
CAN2IsRXPassive.c
char rx_bus_status;
rx_bus_status = CAN1sRXPassive();

Esta funcin determina si la transmisin 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 transmisin 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
transmisin.
Esta funcin 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
Descripcin:

Include:
Prototipo:
Argumentos:
Valores de retorno:

Comentarios:

Archivo de origen:
Ejemplo de cdigo:

CAN1RecieveMessage
CAN2RecieveMessage
Descripcin:
Include:
Prototipo:

Argumentos:

Valores de retorno:
Comentarios:

Archivo de origen:
Ejemplo de cdigo:

Esta funcin devuelve que el estado del

transmisor indica si el nodo CAN esta preparado
para la prxima transmisin.
can.h
Char CAN1IsTXReady(char);
Char CAN2IsTXReady(char);
Buffno: el valor de buffno indica cual es el
estado requerido para el bfer de transmisin.
Si TXREQ es 1, devuelve un 0 indicando que el
bfer de transmisin no esta vaco.
Si TXREQ es 0, devuelve un 1 indicando que el
bfer de transmisin esta vaco, y que el
transmisor esta preparado para la prxima
transmisin.
Esta funcin devuelve el estado del bit TXREQ
del registro de control de transmisin (control
transmit)
CAN1IsTXReady.c
CAN2IsTXReady.c
char tx_2_status;
tx_2_status = CAN1IsTXReady(2);

Esta funcin lee el dato del buffer de recepcin.

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 localizacin donde los
datos recibidos deben ser almacenados.
Datalen: El nmero de bytes de datos
esperados.
MsFlag: El nmero de buffer donde el dato es
recibido. Si es 1, el dato de CiRX1B1 a
CiRX1B4 es ledo. Si es 0, el dato de CiRX0B1
a CiRX0B4 es ledo.
Ninguno
Esta funcin lee los datos recibidos dentro de la
direccin del puntero por el parmetro de
entrada data.
CAN1RecieveMessage.c
CAN2RecieveMessage.c
Unsigned char*rx_data;
CAN1RecieveMessage(rx_data, 5, 0);

59

CAN1SendMessage
CAN2SendMessage
Descripcin:

Include:
Prototipo:

Esta funcin escribe datos para ser transmitidos

a registros de transmisin, pone la longitud de
los datos e inicia la transmisin.
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 localizacin donde los
datos transmitidos sern almacenados.
datalen: Nmero de bytes de datos a transmitir.
MsgFlag: El nmero del bfer (0, 1 o 2) desde
donde los datos sern 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 funcin escribe el valor identificador en los
registros SID y EID, los datos que sern
transmitidos en el registro TX, pone la longitud
de los datos e inicializa la transmisin por el bit
TXREQ.
CAN1SendMessage.c
CAN2SendMessage.c
CAN1SendMessage((CAN_TX_SID(1920)) &
(CAN_TX_EID_EN) &

Archivo de origen:
Ejemplo de cdigo:

60

(CAN_SUB_NOR_TX_REQ),
(CAN_TX_EID(12344)) &
(CAN_NOR_TX_REQ),
Txdata, datalen, tx_rx_no);

CAN1SetFilter
CAN2SetFilter
Descripcin:

Include:
Prototipo:

Esta funcin pone a 1 los valores (SID y EID)

con filtro de aceptacin 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 funcin 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 cdigo:

61

CAN1SetMask
CAN2SetMask
Descripcin:

Include:
Prototipo:

Esta funcin pone a 1 el valor de la mscara de

aceptacin (SID y EID) para la mscara
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 mscara (0 or 1) para el cual los

valores de mscara tienen que ser configurados
sid: El valor de 16 bits que se escribirn 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 sern escritos en los
registros CiRXMnEIDH y CiRXMnEIDL.
CAN_MASK_EID(x) x es el valor de EID
requerido.

Valores de retorno:
Comentarios:

Ninguno
Esta funcin 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 mscara 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 cdigo:

CAN1SetOperationMode
CAN2SetOperationMode
Descripcin:
Include:
Prototipo:

Argumentos:

Esta funcin configura el mdulo CAN

can.h
void CAN1SetOperationMode(unsigned int
config);
void CAN2SetOperationMode(unsigned int
config);
Config valor de 16 bits que sern cargados en el
registro CiCTRL , la combinacin 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 operacin 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 funcin 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 cdigo:

CAN1SetOperationModeNoWait
CAN2SetOperationModeNoWait
Esta funcin aborta las transmisiones pendientes y
Descripcin:
configura el mdulo CAN
can.h
Include:
void CAN1SetOperationModeNoWait(
Prototipo:
unsigned int config);
void CAN2SetOperationModeNoWait(
unsigned int config);
Config: valor de 16 bits que sern cargados en el
Argumentos:
registro CiCTRL , la combinacin 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 operacin 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 cdigo:

CAN Capture Enable/Disable

CAN_CAPTURE_EN_NO_WAIT
CAN_CAPTURE_DIS_NO_WAIT
Ninguno
Esta funcin pone a 1 el bit de aborto as aborta la
iniciacin 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
Descripcin:
Include:
Prototipo:

Argumentos:

Esta funcin 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 combinacin de las siguientes
definiciones.
Clear RXFUL bit
CAN_RXFUL_CLEAR

Valores de retorno:
Comentarios:

Archivo de origen:
Ejemplo de cdigo:

Double buffer enable/disable

CAN_BUF0_DBLBUFFER_EN
CAN_BUF0_DBLBUFFER_DIS
Ninguno.
Esta funcin 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 (funcin)
CAN2SetTXMode
Descripcin:
Include:
Prototipo:

Argumentos:

Esta funcin configura el transmisor del mdulo

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 combinacin de las siguientes
definiciones.
Message send request
CAN_TX_REQ
CAN_TX_STOP_REQ

Valores de retorno:
Comentarios:

Archivo de origen:
Ejemplo de cdigo:

CAN1Initialize
CAN2Initialize
Descripcin:
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 funcin 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 funcin configura el mdulo 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 combinacin 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 combinacin 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 cdigo:

Sample of the CAN bus line

CAN_SAMPLE3TIMES
CAN_SAMPLE1TIME
Ninguno.
Esta funcin 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
Descripcin:
Include:
Prototipo:

Argumentos:

Esta funcin 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 informacin de interrupcin
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 informacin de Prioridad de
interrupcin 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 funcin configura las Interrupciones CAN.
Es el enable/disables de las interrupciones de

67

Archivo de origen:
Ejemplo de cdigo:

CAN. Y tambin 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
Descripcin:
Include:
Argumentos:
Comentarios:
Ejemplo de cdigo:
DisableIntCAN1
DisableIntCAN2
Descripcin:
Include:
Argumentos:
Comentarios:
Ejemplo de cdigo:
SetPriorityIntCAN1
SetPriorityIntCAN2
Descripcin:
Include:
Argumentos:
Comentarios:
Ejemplo de cdigo:

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 interrupcin 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 interrupcin de

CAN.
can.h
Priority
Esta macro pone los bits de interrupcin de CAN
en el registro Interrupt Priority Control.
SetPriorityIntCAN1(2);

68

3.7.3. Ejemplo de aplicacin de cdigo

#define __dsPIC30F4013__
#include<p30fxxxx.h>
#include<can.h>
#define dataarray 0x1820
int main(void)
{
/* Longitud de los datos que sern 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 configuracin */
CAN1SetOperationMode(CAN_IDLE_CON &
CAN_MASTERCLOCK_1 &
CAN_REQ_OPERMODE_CONFIG &
CAN_CAPTURE_DIS);
while(C1CTRLbits.OPMODE <=3);
/* Carga el registro de configuracin */
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 Aceptacin*/
FilterNo = 0;
CAN1SetFilter(FilterNo, CAN_FILTER_SID(1920) &
CAN_RX_EID_EN, CAN_FILTER_EID(12345));
/* Carga el registro de filtro de Mscara */
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 transmisin y pone el
bit de respuesta de transmisin */

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 recepcin contenga el mensaje vlido */
while(!CAN1IsRXReady(0));
/* Lee los datos recibidos del buffer de recepcin*/
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 nmero de estos que se encuentran en el
mercado. Nos centraremos principalmente en los sensores, ya que nos van a
ser ms tiles a la hora de realizar nuestro trabajo en el dsPIC30F4013.

SENSORES

Sensor digital de presin HDA 4000 CAN

Caractersticas tcnicas:
-

Interfaz CAN
Rango de medida: presiones
de 40 bar a 600 bar.
Precisin 0.25 %
Rango de temperatura
soportable: 25 C a +85 C
Tensin: de 10 a 35 VDC
Tasa de transmisin de 10kbit
a 1Mbit (configurable)
Sensores MDT CAN + IDA CAN
- La seal digital tiene una
resolucin de 13 bits sobre los
dos cables del bus CAN.
- El tiempo de medida y de
conversin de la seal de
presin es de 20 milisegundos,
ms que suficiente para la
mayora de las aplicaciones
industriales.
- El cableado interno de CAN,
supervisa de forma automtica
que las funciones del
transductor de presin sean las
correctas, y enva una seal de
alarma en caso contrario.

72

Codificador de eje rotatorio 5860

Caractersticas tcnicas:
-

Todos los valores obtenidos son

enviados a travs del interfaz
CAN.
Parmetros programables va
CAN
Rotacin: 6000 rpm.
Rango de temperatura
soportable: -20 C a +85 C
Tensin: 10 a 30 VDC

Codificador magntico ATM 60

Caractersticas tcnicas:
-

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 inclinmetros AnguSens

Caractersticas tcnicas:
-

Todos los valores obtenidos son

enviados a travs del interfaz
CAN.
Parmetros programables va
CAN
Rango de medida: 15 o 30
Precisin: hasta 0.001
Mximo dos ejes de medida.

73

Sensores de compactacin ASC (para camiones y maquinaria pesada)

Utilizado para medir lo compacto de un terreno

Un sensor de aceleracin empotrado mide la reaccin del tambor,
mientras que un microregulador calcula la frecuencia de vibracin y
otros parmetros que son transferidos va CAN, por ejemplo a un
display.
Memoria EEPROM disponible, con diccionario CAN.
Rango de medida: 41 g
Temperatura soportable: -40C a +85C
Tensin: 8V a 32V DC
Consumo: 80mA a 12V aprox.
Transductores BTL5-H1

Transmite las medidas de posicin y velocidad del sistema de control

obtenidas a otro nodo a travs del Bus CAN.
Los hay disponibles de tres formas, segn el transductor que lleven: un
imn de posicin, dos imanes de posicin, o FMM (modo magntico
flexible) con de 1 a 4 imanes de posicin.
Gran precisin: 5 m para la posicin y 0.1 mm/s para la velocidad.
Rango de temperatura soportable: de -40C a +85C
Muy lineales e insensibles a las vibraciones, los golpes y los ruidos.

74

Familia de sensores CAN

Adems de una gran cantidad de sensores, podemos encontrar esta familia de

mdulos para sensores CAN, que esta especialmente diseada para los
fabricantes de sensores que quieran aadir una interfaz CAN a estos, ya sean
sensores de tensin, de corriente, presin, calor, esfuerzo
Todos estos mdulos tienen un rango de temperatura soportable que va de 40 C a + 85 C y un rango de tensin de 8 V a 60 V de corriente continua.

Otro tipo de dispositivos

ESCNERES

75

ACTUADORES

DATALOGGERS

MDULOS 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. BIBLIOGRAFA

79

Bibliografa bsica:

1. INTRODUCCIN
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. TRANSMISIN 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