Sistema de Comunicacion CANBus Basado en Microcontrolador

ESCUELA TCNICA SUPERIOR DE INGENIERA
Departamento de Ingeniera Electrnica,

de Sistemas Informticos y Automtica

Sistema de Comunicacin CAN-Bus
basado en Microcontrolador
Renesas R8C/23

Proyecto Fin de Carrera de:
Jos Mara Sancho Peate

Dirigido por:
Dr. Carlos Rodrigo Rubia Marcos

UNIVERSIDAD DE HUELVA
Octubre de 2011

Agradecimientos

En primer lugar quiero mostrar mi agradecimiento al Dr. Carlos Rodrigo Rubia
Marcos por su confianza, paciencia y dedicacin constante a la direccin de este
trabajo. Al Dr. Juan Antonio Gmez Galn y Manuel Pedro Carrasco por los consejos
y el inters mostrado.

As mismo deseo agradecer a mis compaeros Ismael Granado, Sergio Aparicio y
Javier Remesa, la inestimable ayuda prestada en momentos de indecisin y bloqueo en
el trascurso de este estudio.

A mi familia y a Estefana, por el cario, el nimo y el apoyo constante recibido, ya
que, sin ellos no hubiese llegado hasta aqu.

VII

NDICE DE CONTENIDOS

CAPITULO 1. PLANTEAMIENTO INICIAL .................................................................... 15

CAPITULO 2. CONTROLLER AREA NETWORK (CAN) .................................................. 17
2.1 INTRODUCCIN A CAN .................................................................................................... 17
2.1.1 Historia .............................................................................................................. 17
2.1.2 Principios bsicos de CAN ................................................................................... 17
2.1.3 CAN en el mercado actual .................................................................................. 19
2.2 PROTOCOLO DE COMUNICACIN CAN ................................................................................. 21
2.2.1 Capa Fsica ......................................................................................................... 21
2.2.1.1 Sealizacin Fsica ................................................................................................ 22
2.2.1.2 Medios de Transmisin ......................................................................................... 27
2.2.1.3 Topologa de Red .................................................................................................. 29
2.2.1.4 Acceso al Bus ........................................................................................................ 30
2.2.1.5 Estndares de Capa Fsica ..................................................................................... 31
2.2.1.6 Controlador de Protocolo CAN .............................................................................. 33
2.2.2 Capa de Enlace ................................................................................................... 36
2.2.2.1 Principio de Arbitraje del Bus ................................................................................ 36
2.2.2.2 Formatos de Trama .............................................................................................. 40
2.2.2.3 Control de Errores ................................................................................................ 49
2.2.2.4 Formato Extendido de Trama ................................................................................ 53

CAPITULO 3. HARDWARE DEL SISTEMA. .................................................................. 55
3.1 INTRODUCCIN .............................................................................................................. 55
3.2 MICROCONTROLADOR ..................................................................................................... 56
3.2.1 Renesas .............................................................................................................. 56
3.2.2 R8C/23 Group .................................................................................................... 56
3.2.3 Registros de la Unidad de Proceso. ..................................................................... 60
3.2.4 Mapa de memoria.............................................................................................. 63
3.2.5 Modulo CAN de R8C/23 ...................................................................................... 64
3.3 CAN TRANSCEIVER ......................................................................................................... 66
3.4 EMULADOR/PROGRAMADOR E8 ........................................................................................ 67
3.5 ESQUEMTICO DE CONEXIN ............................................................................................ 69
3.5.1 Esquemas Elctricos ........................................................................................... 69
3.5.2 PCB Layout. ........................................................................................................ 78
3.5.3 BOM .................................................................................................................. 79

CAPITULO 4. SOFTWARE DEL SISTEMA. ................................................................... 81
4.1 INTRODUCCIN .............................................................................................................. 81
4.2 HIGH-PERFORMANCE EMBEDDED WORKSHOP ...................................................................... 81
4.3 FLASH DEVELOPMENT TOOLKIT .......................................................................................... 82
4.4 FIRMWARE .................................................................................................................... 83
4.4.1 Algoritmos ......................................................................................................... 83
4.4.2 Cdigo C de Nodo Maestro ................................................................................. 85
4.4.3 Cdigo C de Nodos Esclavos ............................................................................... 99
4.4.4 Libreras ........................................................................................................... 113
VIII

CAPITULO 5. CONSIDERACIONES FINALES. ............................................................. 133
5.1 RESULTADOS ............................................................................................................... 133
5.2 LNEAS FUTURAS DE TRABAJO. ......................................................................................... 133

REFERENCIAS BIBLIOGRFCAS ................................................................................ 135
A) MANUALES DE CONSULTA .............................................................................................. 135
B) WEB SITES .................................................................................................................. 136
C) ARTCULOS RELACIONADOS ............................................................................................. 137

ANEXOS. .......................................................................................................... 139
A) HOJA DE CARACTERSTICAS DEL TRANSCEIVER L9616 ............................................................ 139
B) HOJA DE CARACTERSTICAS DEL MICROCONTROLADOR RENESAS R8C/23 .................................. 145
C) CONTROLADOR CAN DEL MICROCONTROLADOR R8C/23. ..................................................... 157

IX

NDICE DE FIGURAS

Figura 2.1: Ejemplo de aplicacin de CAN. ............................................................................... 20
Figura 2.2: Capas de CAN y modelo de referencia OSI. ............................................................. 21
Figura 2.3: Codificacin NRZ y Manchester. ............................................................................. 22
Figura 2.4: Tiempo de Bit. ....................................................................................................... 24
Figura 2.5: Seal del oscilador, reloj CAN y 1 tiempo de bit. ..................................................... 25
Figura 2.6: Curva aproximada Velocidad/Distancia. ................................................................ 26
Figura 2.7: a. Bus de dos hilos - b. Bus de un solo hilo. ............................................................. 28
Figura 2.8: Topologa del Bus de acuerdo a ISO 11898-2 .......................................................... 29
Figura 2.9: Conexin de un controlador CAN............................................................................ 30
Figura 2.10: Caractersticas de la Capa Fsica. ......................................................................... 31
Figura 2.11: Niveles nominales del bus. ................................................................................... 32
Figura 2.12: Nivel dominante/recesivo basado en una configuracin AND. .............................. 37
Figura 2.13: Algoritmo de arbitraje de CAN ............................................................................. 38
Figura 2.14: Ejemplo de un proceso de arbitraje. ..................................................................... 39
Figura 2.15: Formato bsico de una Trama de Datos. .............................................................. 40
Figura 2.16: Formato del Campo de Arbitraje. ......................................................................... 41
Figura 2.17: Formato del Campo de Control (Formato Estndar). ............................................ 42
Figura 2.18: Formato del Campo CRC. ..................................................................................... 42
Figura 2.19: Formato del Campo de Acuse de Recibo o ACK. .................................................... 43
Figura 2.21: Formato de la Trama de Error. ............................................................................. 44
Figura 2.22: Formato de un espacio Inter-Tramas.................................................................... 48
Figura 2.23: Diagrama de Estados de Error.............................................................................. 52
Figura 2.24: Estructura del formato extendido......................................................................... 54

Figura 3.1: Cara Top de un nodo CAN bus. ............................................................................... 55
Figura 3.2: Cara Bottom de un nodo CAN bus. ......................................................................... 55
Figura 3.3:3.2 Diagrama de bloques del R8C/23. ..................................................................... 57
Figura 3.4: Encapsulado de R8C/23 ......................................................................................... 59
Figura 3.5: Pin-out de R8C/23.................................................................................................. 59
Figura 3.6: Registros de la CPU R8C/23.................................................................................... 60
Figura 3.7: Registro de Banderas. ............................................................................................ 61
Figura 3.8: Mapa de memoria del R8C/23 ............................................................................... 63
Figura 3.9: Diagrama de bloques de modulo can del R8C/23. .................................................. 64
Figura 3.10: Diagrama de bloques del L9616. .......................................................................... 66
Figura 3.11: Pin-out del L9616. ........................................................................................ 67
Figura 3.12: Conexin del emulador E8. ................................................................................... 67
Figura 3.13: Conexin del Microcontrolador. ........................................................................... 69
Figura 3.14: Conexionado del circuito electrnico. ................................................................... 70
Figura 3.15: Circuito Reset....................................................................................................... 71
Figura 3.16: Circuito de Reloj. .................................................................................................. 71
Figura 3.17: Circuito de Alimentacin. ..................................................................................... 72
Figura 3.18: Circuito de Entradas............................................................................................. 73
Figura 3.19: Circuito de Salidas................................................................................................ 74
Figura 3.20: Conexin del Transceiver L9616. .......................................................................... 74
Figura 3.21: Conexin del interfaz Serie RS-232. ...................................................................... 75
Figura 3.22: Esquema para la conexin del bus I2C. ................................................................. 76
Figura 3.23: Conexin para emulador E8. ................................................................................ 77
Figura 3.24: Cara Top. ............................................................................................................. 78
X

Figura 3.25: Cara Bottom. ....................................................................................................... 78

Figura 4.1: Entorno de desarrollo. ........................................................................................... 81
Figura 4.2: Herramienta de descarga del firmware. ................................................................. 82
Figura 4.3: Algoritmo Nodo Maestro. ...................................................................................... 83
Figura 4.4: Algoritmos Nodos Esclavos. ................................................................................... 84
XI

NDICE DE TABLAS

Tabla 2.1: Relacin Velocidad/Distancia. ................................................................................. 27

Tabla 3.1: Gama de productos de R8C/23 Group. .................................................................... 58
Tabla 3.2: Funcin de cada pin del L9616. ............................................................................... 67
Tabla 3.3: Componentes utilizados. ......................................................................................... 79

Cada da sabemos ms
y entendemos menos

Albert Einstein

Sistema de Comunicacin CAN-bus basado en Microcontrolador Renesas R8C/23

Captulo 1. Planteamiento Inicial 15

CAPITULO 1. PLANTEAMIENTO INICIAL

El principal punto de inters, del documento que presentamos, es el estudio del bus
de comunicaciones Controller Area Network (CAN), el cual, es un protocolo que
soporta control distribuido en tiempo real con un alto nivel de seguridad y
multiplexacin. Adems, dicho protocolo est orientado a mensajes, es decir, la
informacin que se intercambia se descompone en mensajes, los cuales, se les asigna un
identificador para transmitirlos. Cada mensaje tiene un identificador nico dentro de la
red, con lo cual los nodos decidirn aceptar o no dicho mensaje.

El objetivo que se pretende, es establecer y acondicionar un sistema de
comunicacin mediante bus CAN. Para alcanzar la meta, ser necesario en primer lugar,
estudiar a fondo el protocolo y posteriormente, desarrollar y fabricar los nodos de
comunicacin necesarios. Dichos nodos, son sistemas embebidos o empotrados,
gestionados por microcontroladores Renesas y obviamente dotados con interfaz CAN
para la correcta comunicacin a travs del bus.

Cada nodo debe ser capaz de iniciar la comunicacin CAN, as como transferir y
recibir los datos que el usuario estime oportunos. Para que cada una de las unidades de
comunicacin pueda realizar estas operaciones correctamente, adems del hardware,
necesitaremos programar un conjunto de instrucciones o firmware que los nodos
almacenaran en su memoria flash interna.

Una vez descargado el firmware en la memoria de los nodos, estos se conectaran al
bus. Tras realizar los test y depuraciones oportunas del sistema, debern realizar las
siguientes operaciones:

Se colocar un nodo como maestro, cuya funcin principal ser la
monitorizacin del bus, colocando la informacin recibida en los diodos led
de datos. El maestro debe tener la posibilidad de enviar en cualquier
momento y con mayor prioridad, una peticin a los esclavos.

Captulo 1. Planteamiento Inicial 16
Tomaremos entre 4 y 6 nodos como esclavos y todos tendrn el mismo
software. El nivel de prioridad de estos nodos se asignara externamente.
La funcin principal de los esclavos ser el envo de informacin al maestro,
dicha informacin aparecer en los led de los propios esclavos.
Ocasionalmente los esclavos recibirn una peticin del maestro, la cual,
debern atenderla.

As mismo dichos circuitos estarn dotados de una interfaz UART e I2C, que
aunque nosotros no llegaremos a utilizar, estarn preparadas para posibles
ampliaciones de nuestro proyecto, en un futuro.


Captulo 2. Controller Area Network (CAN) 17

CAPITULO 2. CONTROLLER AREA NETWORK (CAN)

2.1 Introducci n a CAN

2.1.1 Historia
Durante el ao 1983 el ingeniero de Bosch, Uwe Kiencke, empez a desarrollar el
proyecto que se presentara oficialmente como Controller Area Network, en el congreso
de la SAE (Society of Automotive Engineers), en 1986.

Una vez hecho public el protocolo CAN, los fabricantes no tardaron en
implementar dicha comunicacin en algunos de sus productos, de hecho, a mediados de
1987 Intel present el primer chip de control CAN, el 82526; poco despus Philips
Semiconductors lanz al mercado su primer chip con interfaz CAN, el 80C200.

Esta primera especificacin del bus fue mejorada y ampliada (CAN 2.0) por Bosch
en 1991, lo que permiti que dicho protocolo empezara a utilizarse masivamente en la
industria automovilstica europea. Mercedes-Benz fue el primer productor de coche en
incorporar CAN, y junto a otros grandes fabricantes europeos de automviles fundaron
el grupo CiA (Can in Automotion), creadora de la capa de aplicacin para el bus.
Aunque varias empresas crearon sus especificaciones para el CAN, se public en 1993
un estndar, el ISO 11898, que fue ampliado en 1995 junto con la aparicin del
protocolo unificado de la CiA para el CAN, el CANopen.

En el ao 2000 se define y desarrolla el protocolo de comunicaciones en tiempo
real para CAN, denominado Time-Triggered Communication of CAN (TTCAN), bajo
el estndar ISO 11898-4.

2.1.2 Principios bsicos de CAN
CAN es un protocolo de mltiple acceso con deteccin de colisin no destructiva,
resuelta por prioridades. La especificacin define dos valores posibles para el estado del

bus: recesivo y dominante. Si el bus es manejado simultneamente por ms de un nodo
el valor dominante prevalece sobre el valor recesivo. Usualmente el valor recesivo est
asociado al valor lgico 1 y el valor dominante al valor lgico 0.

Los datos se intercambian en tramas que contienen un identificador (ID) y entre 0 y
8 bytes de datos. El campo ID de cada trama no identifica al nodo que enva el mensaje
sino al tipo de mensaje. Es responsabilidad del diseador de cada aplicacin definir
como se asignan los ID a las tramas generadas por los diferentes nodos del sistema.

Existen dos formatos posibles para el encabezado de las tramas, que difieren en el
campo ID y en algunos campos auxiliares de control. En el formato estndar el campo
ID es de 11 bits. Este formato era el nico disponible en la primera versin del
protocolo. En el formato extendido en cambio, el campo ID est formado por la
concatenacin del ID bsico de 11 bits con el ID extendido de 18 bits, totalizando 29
bits.

Si se produce una colisin entre dos nodos que inician la transmisin de una trama
al mismo tiempo, se utiliza un mecanismo de arbitraje por prioridad para resolver el
conflicto. El sistema compara cada bit a medida que los contendientes escriben sobre el
bus el campo ID y algunos bits adicionales del encabezado de la trama (IDE que indica
el formato de ID y RTR que indica el tipo de trama), que conjuntamente se denominan
campo de arbitraje. El nodo que escribi un valor recesivo lo detecta porque lee del bus
un valor dominante y debe retirarse de la contienda convirtindose en receptor. El nodo
que puso el valor dominante sigue adelante con la transmisin sin notar siquiera que
hubo un conflicto. El nodo perdedor podr reintentar la comunicacin una vez
finalizada la transmisin de la trama por el ganador.

El protocolo CAN fue desarrollado para ser utilizado en sistemas con fuertes
requerimientos de confiabilidad, por lo que posee mltiples mecanismos de deteccin
de errores: error de bit, error de bit de relleno (stuff), error de CRC, error de trama, error
de ACK.


Caractersticas principales de protocolo CAN:
La informacin circula entre unidades de comunicacin mediante un bus de dos
hilos. Dicha informacin se enva en tramas con longitud determinada y con una
estructura definida.
Uno de esos campos de las tramas, acta como identificador del tipo de mensaje
que se enva, y la prioridad de dicho mensaje para trasmitirlo respecto a otros. El
mensaje no va direccionado a ningn nodo en concreto, cada uno lo reconocer
mediante este identificador si el mensaje le interesa o no.
Todas las unidades de la red pueden actuar como transmisor o receptor, y el
nmero de mdulos conectados a la red es variable (dentro de unos lmites).
Cualquier nodo puede comenzar la transmisin, siempre que est libre el bus, si
otro lo intenta al mismo tiempo el conflicto se resuelve por la prioridad del
mensaje indicado por el identificador del mismo.
El sistema est dotado de una serie de mecanismos que aseguran que el mensaje
es trasmitido y recibido correctamente. Cuando se detecta un error, el mensaje es
anulado y vuelto a trasmitir de forma correcta (automticamente), de la misma
forma un mdulo con problemas avisa a los dems, si la situacin no se
soluciona, este mdulo queda fuera de servicio pero el sistema sigue
funcionando.

2.1.3 CAN en el mercado actual
CAN ha alcanzado un nivel muy alto de diseo robusto e implantacin, se habla de
cientos de millones de mdulos vendidos, ya que, los fabricantes estn incorporando
controladores CAN de forma bastante generalizada en sus productos.

El estado del estndar alcanzado por CAN lo convierte en una tecnologa habitual
en la industria, y numerosas firmas fabrican y distribuyen productos compatibles con
este protocolo de comunicaciones.


La industria automovilstica representa el 80% del uso total que se hace del bus
CAN, ya que, casi todos los vehculos fabricados en Europa, incorporan varios nodos
CAN en su sistema electrnico. Un automvil puede llegar a tener unas 70 Unidades de
Control Electrnico para varios subsistemas, como por ejemplo la unidad encargada del
control del motor, del ABS, del sistema de sonido, elevalunas elctricos, etc. El bus
CAN se implanta como canal de comunicacin entre todos estos sistemas.

Actualmente toda la industria aeronutica est interesada en el protocolo CAN, ya
que, la capa de aplicacin CANaerospace se utiliza para el control de los sistemas de las
aeronaves. En satlites espaciales y otras aplicaciones del mismo campo, las redes CAN
tambin aparecen; por ejemplo, la Agencia Espacial Europea, utiliza CANopen como
protocolo de capa de aplicacin en las redes de sus satlites.

Igualmente podemos encontrarnos CAN en la interconexin de los elementos en el
control del trfico, en sistemas de control industrial donde los protocolos de las capas
superiores como CANopen y DeviceNet CAN logran la integracin entre sistemas,
como son, los sistemas para el control de plantas, de maquinarias, de robots, etc.

Adems es comn ver implementado CAN en sistemas domticos, agricultura, as
como, para equipamiento mdico, donde Siemens Medical Systems ha especificado una
red para la interconexin de quirfanos de la cual ya se ha instalado la primera
implementacin en el hospital alemn de Lueneburg.

Figura 2.1: Ejemplo de aplicacin de CAN.

2.2 Protocolo de comunicacin CAN
Los sistemas distribuidos que utilizan un bus CAN en general pueden ajustarse a un
modelo simplificado de tres capas: fsica, enlace y aplicacin. La especificacin de
CAN publicada por Bosch se refiere solamente a las subcapas inferiores de la capa de
enlace.

La capa de enlaces de datos y la capa fsica del enlace de comunicacin estn
descritas en la norma internacional ISO 11519-2 para las aplicaciones de baja velocidad,
e ISO 11898 que es el estndar internacional para la comunicacin de la alta velocidad
en vehculos.

Tambin existen diferentes estandartes que definen la capa de aplicacin (Ver
Figura 2.2), algunos son muy especficos y estn relacionados con sus campos de
aplicacin. Entre las capas de aplicacin ms utilizadas cabe mencionar: CAL,
CANopen, DeviceNet, etc.

Figura 2.2: Capas de CAN y modelo de referencia OSI.

2.2.1 Capa Fsica
La capa fsica es responsable de la transferencia de bits entre los distintos mdulos
que componen la red. Define aspectos como niveles de seal, codificacin,
sincronizacin y tiempos en que los bits se transfieren al bus.


En un principio tanto la capa de enlace de datos como la capa fsica estaban
estipuladas en la norma ISO11898. Posteriormente se consider oportuno separar en
ISO11898-1 que define la capa de enlace de datos vlida para cualquier aplicacin
CAN, en ISO11898-2 slo para capa fsica de alta velocidad y en ISO 11898-3 para baja
velocidad.

La capa fsica se subdivide en tres subcapas: Sealizacin fsica, unidad de acceso
al medio y medio fsico.

2.2.1.1 Sealizacin Fsica
a) Representacin de bit
El estndar ISO 11898-2 emplea de codificacin de bit llamado No Retorno a
Cero (NRZ). Debido a que en NRZ el nivel de seal puede mantenerse constante
durante un largo periodo de tiempo, dependiendo de los datos transmitidos, deben
tomarse medidas adicionales para asegurar que el intervalo de tiempo mximo
permisible entre dos transiciones de seal no sea excedido. Esto es posible, por ejemplo
aplicando el mtodo de relleno de bits (bit stuffing). Con ste mtodo un bit de nivel
complementario es insertado en el flujo de bits despus de un nmero especfico de bits
de igual nivel.

Figura 2.3: Codificacin NRZ y Manchester.

Una seal codificada NRZ con relleno de bit y distancia de relleno de 5 aplicada en
el protocolo CAN garantiza la capacidad de transporte ms alta posible con suficiente

capacidad de sincronizacin. Este tipo de codificacin tambin provee caractersticas
muy favorables de radiacin de la seal.

b) Temporizacin y Sincronizacin de Bit
Las seales elctricas en un bus CAN entre otras cosas, sufren las alteraciones
propias de la distorsin que se produce por las caractersticas fsicas de la lnea, retardos
de propagacin, demoras producidas en los propios controladores y posibles fuentes
externas de interferencia electromagntica. Adems, cada controlador CAN en un bus
depende, normalmente, de un oscilador distinto, entre estos osciladores existen
diferencias de frecuencia que pueden dar lugar a desfases en el muestreo de tramas en
los distintos nodos. Por todo ello, los controladores CAN siguen un proceso de muestreo
y resincronizacin orientado a evitar los desajustes debidos a estos factores.

Estos desajustes se manifiestan especialmente en el arbitraje, ya que, cuando varios
nodos inician la transmisin de forma simultnea, no estarn perfectamente
sincronizados en el inicio, adems su frecuencia de oscilador puede ser ligeramente
distinta. Los receptores que se han sincronizado con el primer flanco de bajada
detectado, debern resincronizarse sucesivamente con los flancos producidos por el
transmisor que resulte vencedor en la contienda.

El bus CAN utiliza sealizacin sncrona con codificacin NRZ, por lo que necesita
una operacin de muestreo en los receptores y adems, se requiere resincronizacin
continua en el receptor. Resincronizacin es la detencin del periodo de reloj de la seal
recibida.

El tiempo de diferencia mximo posible entre los osciladores de transmisin y
recepcin durante el periodo mximo de tiempo entre dos transiciones de seal debe por
lo tanto ser compensado por suficiente espacio de tiempo (segmentos de fase) antes y
despus del punto nominal de muestreo dentro de un intervalo de bit.

Debido al tipo de arbitraje utilizado en el protocolo CAN y al bit dominante ACK
(como confirmacin de correcta recepcin) la propagacin de la seal desde un
transmisor hacia un receptor y su regreso al primero de nuevo debe ser completado
dentro de un tiempo de bit. Por lo tanto, en adicin al tiempo reservado para

resincronizacin, se requiere de un segmento adicional de tiempo (segmento de retardo
de propagacin) para compensar la propagacin de la seal sobre la lnea de bus as
como los retardos internos de la seal en los nodos transmisor y receptor.

Figura 2.4: Tiempo de Bit.

La longitud de los segmentos de tiempo en un intervalo de bit son especificados
como mltiplos de una unidad bsica de tiempo Tq (time quantum) derivado del periodo
del oscilador. Una unidad bsica de tiempo, Tq, representa el tiempo de resolucin del
mecanismo de sincronizacin y es tomado en cuenta por el segmento de sincronizacin.

En CAN se distingue dos tipos de sincronizacin: sincronizacin dura al inicio de
la trama y re-sincronizacin dentro de una trama. Despus de una sincronizacin dura,
el tiempo de bit es re-iniciado sin tomar en cuenta el segmento de sincronizacin. De
esta manera la sincronizacin dura obliga a que la transicin causante de la
sincronizacin dura se quede dentro del segmento de sincronizacin del tiempo de bit
re-iniciado. La Re-sincronizacin por su parte causa un acortamiento o alargamiento del
tiempo de bit de tal manera que la posicin del punto de muestreo es cambiada con
respecto a la transicin detectada.



Figura 2.5: Seal del oscilador, reloj CAN y 1 tiempo de bit.

Para que el controlador pueda muestrear la seal recibida con seguridad y precisin,
ha de utilizar una frecuencia de muestreo superior a la de la seal transmitida en el bus.
La frecuencia bsica del controlador es as varias veces superior a la de comunicacin
en el bus. De tal manera que los segmentos estn compuestos de un cierto nmero
programable de ciclos de reloj CAN. Estos ciclos estn definidos a partir del oscilador
de cuarzo y un valor BRP (Baud Rate Prescaler) que acta como un divisor de
frecuencia indicando cuntos ciclos de seal del oscilador tendr un ciclo de seal de
reloj CAN (Ver Figura 2.5).

El mnimo valor de BRP es de 1, y su longitud est en funcin de la frecuencia del
oscilador y de la velocidad de transmisin de tal manera que se satisfagan los
requerimientos de los segmentos en cuanto a cantidad de unidades Tq. (Tq=
BRP*T
Oscilador
)

Conceptualmente el conjunto total de Tqs que corresponden con el tiempo nominal
de bit se dividen en los siguientes subconjuntos, en este orden:

Segmento de sincronizacin (Sync_Seg): 1Tq. Es la parte de un tiempo de bit
donde se est esperado que ocurran las transiciones de seal.

Segmento de propagacin (Prop_Seg): desde 1 a 8 Tq. Provee el tiempo
necesario para el establecimiento del retardo mximo de propagacin de la seal

dentro de la red. Este retardo es la suma del retardo de lnea y el retardo interno
de los controladores.

Segmento de fase 1 (Phase_Segl): desde 1 a 8 Tq. Est orientado a la deteccin
y reajuste de desfases entre nodos. Puede alargarse en operaciones de
resincronizacin inter-trama.

Segmento de fase 2 (Phase_Seg2): mximo valor entre el Tiempo de proceso
de informacin y Phase_Segl. El tiempo de proceso de informacin es igual o
menor que 2 Tq. Puede acortarse (nunca menos del tiempo de proceso de
informacin) en las operaciones de resincronizacin intertrama.

El muestreo del bit se realiza en el momento final de Phase_Segl e inicial de
Phase_Seg2. Por otra parte se define un parmetro adicional: el salto de
resincronizacin (SJ W o "Resynchronization Jump Width") con valores de entre 1 y 4
TQ, pero no mayores que Phase_Seg2.

El nmero total de unidades Tq por bit se puede configurar desde 8 a 25.

c) Velocidad y Longitud del Bus CAN

Figura 2.6: Curva aproximada Velocidad/Distancia.

Lo normal es tener buses de corta longitud, para as un funcionamiento ptimo.
Pero si por el contrario tenemos redes de largas longitudes esto ir mermando nuestra

velocidad de transmisin, debido a los retardos en la lnea, impedancias, tolerancias de
los osciladores, etc. Para atenuar estas carencias se colocan en los extremos del bus
impedancias de carga para una mayor estabilidad.

Vel. de Transmisin Long. Mxima del Bus
1000 Kbps 40 m
500 Kbps 110 m
250 Kbps 280 m
125 Kbps 620 m
100 Kbps 790 m
50 Kbps 1640 m
Tabla 2.1: Relacin Velocidad/Distancia.

Estos resultados demuestran que CAN tambin puede ser usado para realizar redes
extendidas ya que sus posibles valores de velocidad de datos son de orden equivalente a
aquellas de otros sistemas de bus de campo.

2.2.1.2 Medios de Transmisin
Un requisito fundamental para el mtodo de arbitraje de CAN, es la habilidad para
representar un nivel de seal dominante y recesivo, es decir, que un nodo no est en
condicin dominante a no ser que el resto los nodos hayan aplicado un bit de nivel
recesivo. Tan pronto como un nodo ha iniciado la transmisin de un bit de nivel
dominante, el bus debe estar en nivel dominante. Este principio puede ser realizado en
medios elctricos y pticos.

El medio elctrico tpicamente usado para implementar redes CAN es un par
trenzado, diferencialmente manejado, de cables con retorno comn (Ver Figura 2.7a).



Figura 2.7: a. Bus de dos hilos - b. Bus de un solo hilo.

Existe tambin el uso de buses de un solo alambre ya que es particularmente til
para la electrnica del cuerpo del vehculo. Esta solucin asume una tierra comn para
los nodos (Ver Figura 2.7b). El bus de un solo cable est especificado por el estndar
SAE J 2411.

Adicionalmente se han hecho esfuerzos por desarrollar soluciones para transmisin
de seales CAN junto con el suministro de energa en las mismas lneas pero la
transmisin simultnea de energa y datos es muy problemtica debido al proceso de
arbitraje usado en el protocolo CAN.

Otro medio usado para implementar redes CAN es la fibra ptica. Las ventajas
conocidas de los medios pticos tales como transmisin libre de problemas de inmisin
(interferencia electromagntica inducida) y emisin (niveles elevados de potencia
electromagntica emitida), estn llegando a ser muy importantes para redes CAN debido
a la creciente disponibilidad de tecnologa de transmisin ptica eficiente en costo,
especialmente fibra ptica de plstico. La caracterstica de inmunidad a interferencia
elctrica del medio ptico es atractiva principalmente para aplicaciones en ambientes
potencialmente explosivos y perturbados electromagnticamente.


2.2.1.3 Topologa de Red
La topologa del cableado debe estar tan cerca como sea posible a una sola
estructura de lnea nica, para reducir al mnimo las reflexiones. Los segmentos del
cable para la conexin de los nodos del bus (lneas drop) deben ser tan cortos como sea
posible, especialmente en tasas altas de bit.

Para la correcta interpretacin de los niveles de bus recibidos por un nodo, es
necesario que las reflexiones sobrepuestas de seal sean suficientemente atenuadas en el
momento en que el nivel de bit es muestreado. Estas reflexiones de la seal pueden ser
evitadas terminando ambos extremos de las lneas de bus con una resistencia terminal
de igual valor a la impedancia de la lnea del bus.

Figura 2.8: Topologa del Bus de acuerdo a ISO 11898-2

El estndar CAN de alta velocidad ISO 11898-2 especifica una topologa como lo
muestra la anterior con resistencias de valor nominal 120 Ohms en los extremos para
una velocidad de 1Mbps, una longitud mxima de bus de 40 m y una longitud mxima
de lnea drop de 30cm. Por supuesto, con velocidades de transmisin ms bajas, pueden
obtenerse longitudes de bus as como longitudes de lneas drop ms largas.

Tambin podemos encontrar otras topologas ms complejas, mediante el uso de:

Repetidores: aaden retardo a la propagacin de la seal. Se mantiene un nico
bus lgico.
Puentes: conectan dos redes lgicas separadas a nivel de enlace. Solo
retransmiten aquellos mensajes que no son locales.
Pasarelas: conectan redes con diferentes protocolos de alto nivel cuando estn
presentes.

2.2.1.4 Acceso al Bus
La conexin de los controladores CAN al bus generalmente es realizada por medio
de un transceiver. Esto resulta en una conexin simple, no costosa y estandarizada, con
lo que se alcanza sin dificultad la interoperabilidad deseada en el nivel fsico.

Esta conexin es designada como Acceso al Medio Bus. Para la conexin de un
controlador CAN a un bus de 2 alambres, en el mercado estn disponibles una variedad
de chips transceiver CAN de acuerdo a los diferentes estndares de capa fsica.
Bsicamente, la interfaz al medio elctrico consiste de un amplificador de transmisin y
otro de recepcin.

Uno de los principales parmetros provistos por un transceiver CAN es el rango de
voltaje de modo comn. Este parmetro especifica la mxima diferencia de potencial
posible entre nodos CAN, en que los niveles de seal pueden todava ser correctamente
interpretados por la circuitera de entrada de un transceiver.

Figura 2.9: Conexin de un controlador CAN.

Una de las caractersticas de un transceiver CAN es el modo de funcionamiento
stand-by. De esta forma, la parte transmisora del transceiver es apagada. El receptor
monitorea si ocurre un nivel dominante en el bus. Y si detecta un mensaje de wake
up, el transceiver se despierta. En este modo de operacin el sistema consume muy
poca potencia.

As, aplicaciones que consumen altas cantidades de energa pueden ser apagadas y
activadas de nuevo a travs de las propias lneas del bus.

Los diferentes estndares para el interfaz fsico del bus pueden ser llevados a cabo
usando los transceivers apropiados.

2.2.1.5 Estndares de Capa Fsica
Diferentes estndares especifican los niveles de seal, topologa de red, nmero de
nodos, as como los requerimientos para el medio y conectores.
i. Estndar ISO 11898-2
El estndar ISO 11898-2, para comunicacin de alta velocidad en vehculos, es el
ms importante y tambin el recomendado por CAN-in-Automation para uso en
aplicaciones industriales.

Figura 2.10: Caractersticas de la Capa Fsica.

Los datos principales de este estndar son:
- Velocidad de transmisin de hasta 1 Mbps.
- Longitud mxima del bus de 40m a 1 Mbps.
- Mxima longitud de una lnea drop a 1 Mbps 30 cm.
- Bus de dos hilos.
- El nmero total de nodos est limitado por la carga elctrica del bus.

- Retardo de propagacin nominal de 5ns/m.
- Impedancia caracterstica de lnea de 120 Ohms.
- Rango de voltaje de modo comn desde -2V (CAN_L) a +7V (CAN_H).

Un receptor reconoce un bit recesivo si el nivel del voltaje diferencial de entrada
(V
diff
= V
canH
V
canL
) si est por debajo de 0.5V, y un nivel dominante si este valor
excede 0.9V.

- Deteccin de un Bit Recesivo:
V
diff
< 0,5V Normalmente: V
diff
= 0, con V
canH
=V
canL
=2,5V

- Deteccin de un Bit Dominante:
V
diff
> 0,9V Normalmente: V
diff
=2, con V
canH
=3,5V y V
canL
=1,5V

Figura 2.11: Niveles nominales del bus.

ii. Estndar CiA DS-102
La realizacin de redes abiertas CAN es apoyada por las recomendaciones DS-102
de la asociacin CiA (CAN-in-Automation) para acceso al bus.

Esta propuesta especfica:
Velocidades de transmisin estandarizadas de 10 Kbps a 1 Mbps con
recomendaciones para el establecimiento de parmetros de temporizacin de bit.
Recomendaciones para las lneas de buses.
Conectores y asignacin de pines.

iii. Estndar ISO11898-3 (tolerante a fallos)
Para requerimientos ms bajos con respecto a velocidad de transmisin y longitud
del bus, la especificacin de baja velocidad tolerante a fallos est disponible como
una forma alternativa de interfaz al bus.

Esta especificacin, desarrollada por las compaas Philips y Bosch, reemplaza el
estndar CAN de baja velocidad ISO-11519 y representa la tercera parte del estndar
ISO 11898.

El uso del interfaz de bus tolerante a fallos es principalmente para redes
electrnicas de confort en vehculos motorizados.

iv. Estndar ISO 11992
ISO 11992 describe una propuesta adicional para usar CAN en redes de baja
velocidad. Est basado en una conexin punto a punto para uso en vehculos de
remolque y sus trailers, tambin conocido como el estndar truck to trailer.

Un par trenzado no blindado es definido como medio para el bus. Debido a
longitudes pequeas y a la relativamente baja velocidad de transmisin, no se especifica
resistencia en los extremos de las lneas del bus.

ISO 11992 especifica la mxima capacitancia por longitud, la impedancia de lnea
as como caractersticas de los conectores.

2.2.1.6 Controlador de Protocolo CAN
Todas las funciones necesarias para el procesamiento de capa 1 y 2 del protocolo
CAN, as como, funciones adicionales de apoyo, son implementadas en los
controladores CAN (Controladores del Protocolo). A travs de una interfaz simple, el
microcontrolador solamente tiene que pasar al controlador CAN los mensajes a ser
transmitidos, o leer mensajes recibidos por ste.


La transmisin de datos a travs de redes CAN est basada en el principio de
broadcast. Esto significa que todos los mensajes transmitidos al bus estn disponibles
para todos los nodos y son recibidos por sus controladores.

En muchos casos un cierto nodo solamente estar interesado en pocos mensajes de
los que se les ha enviado. Por esta razn es apropiado implementar un mecanismo
adicional de filtrado de mensajes en el controlador que asegure que un controlador de
host sea informado de la recepcin de un nuevo mensaje solamente si ste es relevante
para el mismo. Esto se llama filtro de aceptacin. Para realizar esta funcin, el
controlador debe ser informado de todos los identificadores de mensajes en los que el
nodo est interesado.

La realizacin de todas las funciones relacionadas al protocolo en un hardware
controlador separado libera al microcontrolador de estas tareas crticas de tiempo.
Adems, los controladores CAN realizan funciones adicionales con respecto al filtrado
de mensajes, almacenamiento de mensajes y respuesta automtica a solicitudes remotas
de mensajes.

Con respecto al control de mensajes, es posible distinguir entre dos principios de
implementacin:

Basic CAN: En esta implementacin existe un vnculo muy fuerte entre el
controlador CAN y su microcontrolador asociado. El microcontrolador ser
interrumpido para tratar cada mensaje CAN que reciba.
Un controlador de Basic CAN normalmente tiene dos buffers de recepcin y un
buffer de transmisin. Los menajes se reciben en un buffer, mientras, el
microcontrolador lee la informacin recibida en el otro buffer. Si se recibe un
mensaje mientras ambos buffer de recepcin estn llenos, se rechaza dicho
mensaje, es decir, se mantienen los mensajes ms antiguos.
El microcontrolador es quin lleva el peso de las tareas haciendo as que el
controlador CAN sea ms simple y por tanto ms barato. Este mtodo es bueno
para nodos encargados de manejar informaciones espordicas, disminuyendo la
ocupacin del bus. Es la arquitectura ms simple.


Full CAN: En este caso, el controlador CAN tiene varios buffers. Adems tiene
la capacidad para filtrar exactamente los tipos de mensaje que se desee y puede
transmitir y recibir mensajes sin ayuda del microcontrolador. En definitiva, el
controlador le reduce la carga al microcontrolador. Tambin se pueden habilitar
interrupciones en el microcontrolador para notificarle la llegada de un mensaje.

Debido a los requerimientos de tecnologa la funcin del transceiver generalmente
no es integrada en el controlador CAN.


2.2.2 Capa de Enlace
2.2.2.1 Principio de Arbitraje del Bus
En redes CAN, los nodos acceden al bus de acuerdo a un esquema no centralizado
basado en contencin. Es posible que varios nodos empiecen la transferencia de una
trama simultneamente. Sin embargo no est permitido que un nodo inicie una
transmisin mientras el bus no est libre.

Un nodo cualquiera considera que el bus est libre si el campo de interrupcin de
la trama en transmisin no ha sido interrumpido por un bit dominante. Esto sucede
despus de una secuencia consecutiva de al menos 11 bits de nivel recesivo al final de la
trama. Si durante la transmisin de una trama, existe otra pendiente de ser transmitida,
sta ser iniciada a partir del primer bit despus del campo de interrupcin de la trama
anterior.

La metodologa utilizada es CSMA/CD+AMP (Carrier Sense Multiple Access, with
Collision Detection and Arbitration on Message Priority) Acceso mltiple con Escucha
de Portadora, Deteccin de Colisin y Arbitraje basado en la Prioridad del Mensaje.

Cuando varios nodos empiezan simultneamente una transmisin, el conflicto en el
bus es resuelto por un Proceso de Arbitraje no destructivo basado en contencin sobre
el Campo de Arbitraje de la trama CAN. El campo de arbitraje est compuesto por el
Identificador de Trama y por el Bit de Solicitud Remota de Transmisin RTR
(Remote Transmission Request) el cual es usado para diferenciar entre una Trama de
Datos y una Trama de Solicitud de Datos. En el formato bsico de la trama su
identificador de trama contiene 11 bits, en el formato extendido 29 bits. El bit ms
significante del identificador es transmitido primero (el del extremo izquierdo).



Figura 2.12: Nivel dominante/recesivo basado en una configuracin AND.

El arbitraje no destructivo est basado en la posibilidad de dos niveles fsicos en el
bus, dominante y recesivo. Estos niveles pueden ser representados fcilmente, por
ejemplo por un circuito transmisor en colector abierto (configuracin AND) como lo
muestra la Figura 2.12. Para conseguir un 1 lgico en el bus es necesario que todos los
nodos transmitan un 1, mientras que para tener un 0 lgico es suficiente que un solo
nodo transmita un 0. Por tanto un nivel 0 es llamado dominante, y un nivel 1
recesivo. Estos mismos estados de nivel recesivo/dominante tambin pueden ser
representados en medios de transmisin pticos. En este caso un nivel recesivo es
representado por un estado oscuro (sin luz), un nivel dominante por un estado
brillo.

El bus estar en nivel recesivo mientras se encuentre desocupado. Un nodo seala
el inicio de la transmisin de una trama transmitiendo un bit dominante de Inicio de
Trama SOF (Start Of Frame). Durante la fase de arbitraje cada nodo transmisor
monitorea el nivel del bus y lo compara con el nivel transmitido (Ver Figura 2.14).



Figura 2.13: Algoritmo de arbitraje de CAN

Cada nodo que ha transmitido un bit recesivo y monitoreado uno dominante detiene
su transmisin inmediatamente y pasa a ser receptor de la trama transmitida por otro
nodo.

La siguiente figura ilustra la secuencia de un proceso de arbitraje entre tres nodos,
en los que, los nodos 1, 2 y 3 inician el proceso al mismo tiempo (1). El nodo 2 pierde
acceso al bus al tiempo (2), el nodo1 lo propio al tiempo (3). Ambos nodos detienen su
transmisin pero continan recibiendo; solo el nodo 3 contina con el proceso y recibe

acceso al bus al final de la fase de arbitraje. Por tanto solo ste nodo puede transmitir su
trama sobre el bus.

Figura 2.14: Ejemplo de un proceso de arbitraje.

De esta manera, el arbitraje del protocolo CAN nos garantiza que solo un nodo del
bus se mantendr en el mismo cuando varios quieran acceder simultneamente.

Si la transmisin de una trama especfica de datos es iniciada simultneamente con
una solicitud de la misma trama hecha por un receptor a travs de una Trama de
Solicitud Remota de Transmisin, el conflicto de arbitraje no puede ser resuelto
solamente por el identificador de trama (ya que son los mismos). En este caso, el bit
RTR que est a continuacin del identificador resuelve el conflicto de acceso al bus. Por
esta razn, el bit RTR en una trama de datos es transmitido en nivel dominante (0) y en
una trama de solicitud remota como recesivo (1).

En definitiva, el principio de arbitraje est basado en una comparacin del nivel de
bit transmitido por el nodo, con el nivel monitoreado en el bus realizado por cualquiera
de los nodos transmisores. Durante la transmisin del campo arbitraje, el transmisor
comprueba en cada bit si todava est autorizado para transmitir o si est transmitiendo
otra estacin de mayor prioridad, los nodos transmisores con mensajes de menor
prioridad se convierten inmediatamente en receptores y posteriormente repetirn su
intento de emisin.


2.2.2.2 Formatos de Trama
a) Trama de Datos
Una trama de datos (Ver Figura 2.15) est compuesta de los siguientes campos de
bit: Inicio de trama (SOF), Campo de arbitraje, Campo de Control, Campo de Datos,
Campo CRC, Campo de Acuse de Recibo (ACK) y Campo de Fin de Trama (EOF).

i. Bit de Inicio de Trama (SOF)
Este bit marca el inicio de una trama de datos o de una trama remota y es
representado por un bit dominante. A un nodo del bus se le permite empezar el arbitraje
del bus cuando ste se encuentra libre o despus de que se ha desocupado. El fin de una
actual transmisin de trama es indicado por una sucesin mnima de 11 bits recesivos.

Figura 2.15: Formato bsico de una Trama de Datos.

ii. Campo de Arbitraje
El campo de arbitraje (Ver Figura 2.16) consiste en un campo identificador y un bit
de Solicitud Remota de Transmisin, RTR (Remote Transmission Request).

Una trama es identificada y su prioridad definida por el identificador de trama. En
el formato bsico de trama la longitud de su identificador es de 11 bits. Esto significa

que 2048 ( 2
11
) tramas diferentes son distinguibles en el formato bsico del sistema
CAN. Estos bits son transmitidos en orden desde el bit 10 al bit 0. El bit ms
significativo es el bit 10.

Figura 2.16: Formato del Campo de Arbitraje.

Ambas tramas, de datos y remota, son identificadas por el bit RTR. Como
anteriormente se explic, en caso de un proceso de arbitraje simultneo entre una trama
de datos y otra de solicitud de la misma trama (Trama RTR) es razonable priorizar a la
trama de datos, es por esto que el Bit RTR en una trama de datos es transmitido
dominantemente y en una trama RTR recesivamente.

iii. Campo de Control
El Campo de Control (Ver Figura 2.17) consiste de 6 bits, incluyendo el Cdigo de
Longitud de Datos DLC (Data Length Code). El primer bit, Bit Identificador de
Extensin IDE (Identifier Extension), distingue entre tramas de formato bsico y
extendido. Para tramas de formato bsico (identificador de 11 bits) este bit es
transmitido dominantemente. Por tanto, colisiones entre una trama de formato bsico y
otra de formato extendido, ambas con el mismo identificador bsico, son resueltas de tal
manera que la trama de formato bsico prevalece sobre la extendida. El segundo bit (r0)
es reservado para futuras extensiones del protocolo CAN y es transmitido
dominantemente hasta que su funcin sea definida. Los receptores aceptan ambos
niveles, dominante y recesivo, como bit reservado.



Figura 2.17: Formato del Campo de Control (Formato Estndar).

Con los ltimos cuatro bits del campo de control, se indica el nmero de bytes
transmitidos a continuacin en el campo de datos. Un valor de 0 corresponde a 0 bytes
de datos, un valor de 8 corresponde a 8 bytes de datos.

iv. Campo de Datos
Este campo contiene los datos a ser transferidos dentro de una trama CAN y puede
contener de 0 a 8 bytes. El bit ms significante es transmitido primero.

v. Campo CRC
El campo CRC (Ver Figura 2.18) consiste de una secuencia de chequeo de 15 bits y
un bit delimitador transmitido recesivamente. La secuencia CRC es utilizada para que
un receptor pueda saber si la trama recibida fue afectada o no por perturbaciones del
medio.

Figura 2.18: Formato del Campo CRC.

vi. Campo de Acuse de Recibo (ACK)
El campo de 2 bits de Acuse de Recibo (ACK) (Ver Figura 2.19) consiste 1 bit
llamado Slot de Acuse de Recibo seguido por el bit Delimitador de Acuse de
Recibo. En el campo de ACK, el transmisor enva dos bits recesivos.



Figura 2.19: Formato del Campo de Acuse de Recibo o ACK.

El protocolo CAN est basado en el principio de estacin-neutral, acuse de
recepcin positiva. En el que el transmisor de una trama espera por el ACK de
recepcin correcta de al menos un nodo receptor. Por tanto cualquier receptor que ha
recibido correctamente una trama lo reporta al transmisor de la misma sobre-escribiendo
el bit recesivo recibido del transmisor por un bit dominante durante el slot ACK. Con un
bit dominante durante el slot de ACK el transmisor se da por enterado que al menos uno
de los nodos ha tenido recepcin correcta de la trama transmitida.

Un bit delimitador ACK recesivo siempre va despus del slot ACK. Esto es
requerido para distinguir un ACK positivo (bit dominante durante el slot ACK) de un
posible inicio simultneo de una trama de error.

vii. Bandera de Fin de trama (EOF)
Cada trama de datos y remota es delimitada por una secuencia de 7 bits recesivos.
Juntos con el igualmente recesivo delimitador ACK resulta en una secuencia total de 8
bits recesivos al final de la trama remota o de datos.

Por tanto una secuencia de 8 bits recesivos indica que una trama ha sido transmitida
completamente libre de errores.

b) Trama Remota
Con esta trama cada nodo puede solicitar al nodo responsable el inicio de la
transmisin de una trama especfica. La trama solicitada es especificada por el
identificador transmitido con la trama remota. Mientras que una trama especfica puede
ser solicitada por todos los nodos receptores, solamente un nodo debe ser responsable
de transmitir la misma.

El formato de una trama remota corresponde a la trama de datos ilustrada en la
Figura 2.15, con la diferencia de que el bit RTR es transmitido recesivamente en una
trama remota y dominantemente en una trama de datos. As, una trama remota que
compite por el acceso al bus con una trama de datos del mismo identificador pierde en
ste proceso. Adems, el campo de datos de una trama remota est vaco. El cdigo de
longitud de datos en la trama remota debe corresponder a aquel de la trama de datos
solicitada.

c) Trama de Error
La deteccin de cualquier error durante la transmisin o recepcin de una trama de
datos o remota es sealado por una trama de error (Ver Figura 2.20) que
intencionalmente viola la regla de relleno de bits y causa que el transmisor de la trama
repita la transmisin de la misma. La deteccin de un error durante la transmisin o
recepcin de una trama de sobrecarga o de error tambin causa la transmisin de una
nueva trama de error.

Figura 2.20: Formato de la Trama de Error.

Una trama de error consiste de dos campos de bits. El primer campo est dado por
la superposicin de banderas de error transmitidas por uno o varios nodos. El segundo
campo, una secuencia de 8 bits recesivos, indica el fin de esta trama (Delimitador de
Error) anloga a la trama remota y de datos. La Figura 2.10 muestra el formato de una
trama de error activa. Esta forma de trama es transmitida por un nodo que posee
completos derechos de sealar un error detectado (Nodo Activo de Error).


i. Bandera de Error
Un nodo empieza la transmisin de una bandera de error inmediatamente despus
de detectar una condicin de fallo, esto sucede en el siguiente intervalo de bit a
continuacin de la deteccin; a no ser que se trate de un error CRC, en cuyo caso la
transmisin de una bandera de error es iniciada en el bit siguiente al delimitador ACK
para no perturbar la funcin de acuse de recibo, a menos que una bandera de error para
otra condicin de error ya haya sido iniciada.

Un nodo defectuoso que errneamente detecta un fallo puede bloquear el bus, ya
que, la transmisin de una bandera de error activa destruye la trama bajo transmisin.
Por consiguiente, dos estados de nodos son diferenciados con respecto al derecho de un
nodo en sealar errores (Ver Seccin 2.2.2.3).

El estado Activo es para los nodos con tasas de deteccin de errores por debajo
de un cierto lmite y a los que se les permite sealar errores detectados transmitiendo
una Bandera de Error Activa consistente de 6 bits dominantes. Mientras que aquellos
nodos con un promedio de tasa de deteccin de error que excede un lmite fijo son
sospechosos de tener un problema local y por ende solo tienen limitados derechos al
sealar errores, stos caen en el estado de Pasivo. Un Nodo Pasivo seala la deteccin
de una condicin de error transmitiendo una secuencia de 6 bits recesivos (Bandera de
Error Pasiva).

Un nodo en estado Activo que detecta una condicin de error seala esto
transmitiendo una bandera de error activa (sealizacin primaria de error). Esto viola
la regla de relleno de bits aplicada a todos los campos desde SOF hasta el delimitador
CRC o destruye la forma fija del campo ACK o del EOF. Como consecuencia, todos los
otros nodos tambin detectan una condicin de error e inician la transmisin de una
bandera de error (sealizacin secundaria de error) por su parte. As la secuencia de
bits dominantes que en realidad pueden ser monitoreados en el bus resulta en una
superposicin de diferentes banderas de error transmitidas por diferentes nodos.
Dependiendo del punto de tiempo en el que otros nodos detectan la condicin de error
esto resulta en una secuencia de entre 6 y 12 bits dominantes.


Si un nodo transmisor Pasivo detecta un error, ste trata de sealarlo transmitiendo
una secuencia de 6 bits recesivos (Bandera de Error Pasiva). Cuando la bandera de
error pasiva empieza dentro de un campo de trama que est codificado con relleno de
bit, los receptores reconocen un error de relleno de bit. Los bits de la Bandera de Error
Pasiva antes que sealar errores sirven para demorar al nodo Pasivo 6 tiempos de bit
antes de transmitir de nuevo (periodo en el cual otro nodo puede ganar el acceso).

ii. Delimitador de Error
Una trama de error es finalizada por una secuencia de 8 bits recesivos, la cual se
forma de la siguiente manera: Despus de transmitir una bandera de error, el nodo
transmite bits recesivos y monitorea el nivel del bus hasta reconocer un bit recesivo.
Luego inicia la transmisin de 7 bits recesivos ms (en total transmite una secuencia
mnima de 8 bits recesivos consecutivos). Con este mecanismo un nodo es capaz de
determinar si fue el primero en transmitir una bandera de error y as haber detectado
primero la condicin de error. Este mecanismo es la base para el confinamiento de
nodos errneos.

d) Trama de Sobrecarga
Esta trama es proporcionada para solicitar un retraso de la prxima trama de datos o
remota por el receptor de un nodo (Trama de Sobrecarga Solicitada) o para sealar
ciertas condiciones de error (Trama de Sobrecarga Reactiva) relacionadas al campo
de interrupcin.

Las tramas de sobrecarga reactiva son transmitidas despus de la deteccin de las
siguientes condiciones de error:

Deteccin de un bit dominante durante los primeros dos bits del campo
de interrupcin. Un bit dominante detectado en el tercer bit del campo de
interrupcin es interpretado como un SOF.


Deteccin de un bit dominante en el ltimo bit del campo EOF por un
receptor, o deteccin de un bit dominante por un receptor o transmisor en
el ltimo bit de un delimitador de trama de error o de sobrecarga.

Una trama de sobrecarga puede ser considerada como una forma especial de trama
de error (Ver Figura 2.20) y es similar a sta pues est compuesta por una bandera de
sobrecarga y de un delimitador de sobrecarga. En contraste a la transmisin de una
trama de error, la generacin de una trama de sobrecarga es limitada a condiciones muy
especficas relacionadas al campo de interrupcin. Una importante distincin adicional
es que la transmisin de una trama de sobrecarga no causa la re-transmisin de una
trama previa, como una trama de error lo hace.

La bandera de sobrecarga consiste de una secuencia de 6 bits dominantes
consecutivos y destruye la forma fija del campo de interrupcin. Como consecuencia,
todos los otros nodos tambin detectan una condicin de sobrecarga y por su parte
transmiten una bandera de sobrecarga. Despus de transmitir una bandera de
sobrecarga, cada nodo monitorea el bus hasta detectar un bit recesivo, a continuacin de
lo cual cada nodo transmite 7 bits recesivos adicionales para completar los 8 bits del
delimitador de sobrecarga.

Para retrasar tramas adicionales una trama de sobrecarga se debe iniciar en el
primer bit de un campo de interrupcin esperado. Como mximo se permite generar
sucesivamente tramas de sobrecarga para retrasar la prxima trama.

e) Espacio Inter-Tramas
Tramas remotas y de datos son separadas de todas las tramas precedentes (tramas
de datos, remotas, de error, de sobrecarga) por un Espacio Inter-Tramas. En contraste,
las tramas de error y de sobrecarga son transmitidas sucesivamente, sin un espacio inter-
tramas entre ellas. El espacio inter-tramas consiste de un campo de bits recesivos que
representa una distancia mnima de tres bits entre tramas, Campo de Interrupcin,
seguido por un campo de longitud aleatoria de nivel recesivo (bus desocupado) (Ver
Figura 2.21) hasta que una nueva transmisin de trama sea iniciada. El espacio nter-
tramas adicionalmente contiene un tiempo de impedimento de transmisin de 8 bits

(Transmisin Suspendida) para nodos pasivos de error que fueron los transmisores
de la trama precedente.

Figura 2.21: Formato de un espacio Inter-Tramas.

Con los 3 bits del campo de interrupcin, los 7 bits del delimitador de trama y el
delimitador ACK recesivo de una trama remota o de datos, la secuencia de bits
recesivos entre 2 tramas tiene una longitud mnima total de 11 bits. Por tanto, despus
de esta secuencia el bus est disponible de nuevo. Luego, la deteccin de un bit
dominante es interpretada como el bit SOF de una nueva trama.

Con respecto al acceso repetido al bus se aplica una regla especial para nodos
pasivos de error. El derecho de transmisin de nodos en este estado es reducido en
relacin a todos los otros nodos activos de error por medio de un Campo de
Transmisin Suspendida de 8 bits a continuacin del campo de interrupcin. Si
mientras un nodo en estado pasivo espera que ste campo expire, una transmisin
causada por un nodo de estado activo empieza, el primero vendr a ser un receptor del
segundo.

Ya que el bus solamente es considerado disponible para un nodo transmisor pasivo
de error, despus de completar el tiempo de transmisin suspendida, tramas de prioridad
ms baja de nodos activos de error pendientes de transmitirse pueden acceder al bus,
antes de que el nodo pasivo de error pueda hacerlo de nuevo. Esto asegura que un nodo
posiblemente defectuoso no pueda dificultar a otros nodos la transmisin de sus tramas.


2.2.2.3 Control de Errores
a) Deteccin de Errores
En la transferencia de informacin, como por ejemplo, en las aplicaciones CAN de
vehculos, necesitamos garantas de que el protocolo efecte una correcta transmisin de
los datos.
Para satisfacer estas demandas, el protocolo CAN provee varios mecanismos para
deteccin de errores, son los siguientes:
i. Error de Bit
Cada nodo transmisor monitorea si el nivel del bit enviado al bus difiere del nivel
que realmente ha llegado a ste. Si el valor de bit que ha sido transmitido es diferente
del valor de bit que es monitoreado, un error de bit es detectado. El monitoreo de bit
representa as un mecanismo muy efectivo para deteccin de todos los errores globales
y locales al transmisor.

La sobre-escritura de un nivel de bit transmitido recesivamente por un nivel
dominante durante la fase de arbitraje as como durante el slot ACK no es interpretado
como un error de bit. La sobre-escritura de una bandera de error pasiva (nivel recesivo)
tampoco es interpretada como un error de bit por un nodo transmisor.
ii. Error de Trama
Los formatos posibles de trama en el protocolo CAN contienen campos de bits de
forma fija especfica (por ejemplo los bits delimitadores recesivos) cuya estructura es
verificada por todos los nodos. Un error de forma es detectado cuando un campo de
forma fija contiene uno o ms bits no permitidos.
iii. Error de Redundancia Cclica
Para permitir a un nodo receptor verificar la integridad de los datos recibidos, el
protocolo CAN aplica el principio de chequeo de redundancia. Este mtodo
generalmente aplicado en sistemas de transmisin de datos garantiza una probabilidad
muy alta de deteccin de errores y una Probabilidad de Error Residual muy baja. En
especial, el chequeo de redundancia cclica proporciona la deteccin de errores globales.

En chequeo de redundancia cclica, la informacin del encabezado de trama y los
datos a ser transmitidos son representados como un Polinomio de Trama el cual ser

dividido por un Generador Polinomial definido. El residuo de esta divisin binaria es
la secuencia CRC (Cdigo de Redundancia Cclica) de 15 bits transmitida sobre el bus
como parte de la trama. En el nodo receptor el polinomio de trama recibido es tambin
dividido para el mismo generador polinomial. Si la trama fue transmitida libre de
errores, el FCS calculado ser idntico al recibido.
iv. Error de ACK
Un transmisor espera que en el slot ACK, al menos, un receptor confirme la
correcta recepcin de una trama transmitida. La falta de confirmacin (es decir el slot
ACK con nivel recesivo en vez de dominante) es interpretada por el transmisor de la
trama como un error de ACK.
v. Error de regla de relleno
Cada nodo encuentra una violacin de la regla de relleno de bit (Error de
Relleno) tan pronto como detecta un sexto bit consecutivo de igual nivel en un campo
de trama codificado por el mtodo de relleno de bit. Consecuentemente, cada nodo que
detecta una bandera de error interpreta esto como una violacin de la regla de relleno de
bit y por tanto genera una trama de error automticamente.

b) Confinamiento de Errores
Un sistema de bus serial est relacionado bsicamente con el problema de que un
nodo defectuoso del bus podra bloquear el sistema entero. Particularmente el principio
de sealizacin de error aplicado en el protocolo CAN implica este riesgo ya que un
nodo defectuoso podra generar continuamente banderas de error. Para eliminar este
riesgo, el protocolo CAN posee un mecanismo que detecta un nodo defectuoso y lo
desconecta del bus. Para este propsito, el protocolo CAN especifica un contador de
error de transmisin y un contador de error de recepcin para cada nodo. Cuyas
cuentas son incrementadas en un determinado valor con cada transmisin o recepcin de
trama errnea detectada, y decrementada en 1 con cada transmisin o recepcin exitosa
de una trama, de tal forma que en caso de un error el incremento de la cuenta de error
sea ms grande que el decremento en caso de un xito. El valor de incremento depende
de si un nodo fue el primero en detectar un error. Esto puede conducir a un incremento
notable de las cuentas sobre un cierto perodo de tiempo, sin embargo stas son
reducidas nuevamente durante un periodo de tiempo ms largo con una tasa de error

ms baja. Los valores de cuentas de error son as una medida para la tasa de error de
transmisin.

Si un nodo detecta un error, la bandera de error enviada por ste provoca una
subsiguiente sealizacin de error por parte de los otros nodos de una red. Los nodos
reconocen si fueron los primeros en sealar un error al finalizar su bandera de error.
Para propsitos de confinamiento de fallos, las cuentas de error de recepcin o de
transmisin del nodo que primero seal un error durante la recepcin y transmisin
respectivamente son incrementados en una cantidad significativamente ms alta (en un
valor de 9 y 8 respectivamente) que las cuentas de error de los nodos que sealaron el
error secundariamente. Un nodo que siempre es el primero en detectar un error por
consecutivas ocasiones sobre un largo periodo de tiempo puede estar teniendo
problemas consigo mismo, es decir estar defectuoso. Cuando se exceden lmites
especficos de cuentas de error, se toman medidas para restringir un efecto
presumiblemente defectuoso del nodo. Estas medidas van desde prohibir la transmisin
de banderas de error activas cuando una cuenta de error especfica es alcanzada, hasta
impedir a un nodo formar alguna interaccin con el bus cuando es alcanzado un nivel
an ms alto de cuenta de error.

Con respecto al confinamiento de error, un nodo puede estar en uno de los
siguientes tres estados de error, dependiendo de los valores de sus contadores:

Error-Activo (Estado Activo)
Error-Pasivo (Estado Pasivo)
Bus-Off (Estado Suspendido)

Un nodo en estado Activo en una red toma parte en la comunicacin del bus y
enva una bandera de error activa cuando detecta un error. Esto destruye la trama que
estaba transmitiendo, viola la regla de relleno de bit y previene a otros nodos de aceptar
la trama errnea.

Un nodo en estado Pasivo ya ha acumulado una cuenta de error de transmisin o
de recepcin relativamente alta y ha monitoreado as una tasa de error
significativamente elevada sobre un periodo ms largo de tiempo. Un nodo en este

estado es todava totalmente capaz de comunicarse, sin embargo los errores detectados
ya no sern sealados por una bandera de error activa. En cambio ahora, un error es
sealado por una bandera de error pasiva consistente de 6 bits recesivos que no perturba
la comunicacin restante del bus. Adems, un nodo en estado pasivo debe esperar por 8
tiempos de bit antes de intentar re-transmitir la trama que fue detectada como errnea.

Ambas medidas aseguran que un nodo que ha estado detectando una tasa de error
significativamente ms alta sobre un periodo de tiempo ms largo ya no pueda interferir
con la comunicacin restante del bus.

A un nodo en estado Suspendido no se le permite tener ningn tipo de influencia
sobre el bus. Este nodo no transmitir ninguna trama, ni siquiera aquellas de sobrecarga,
error ni tampoco ACKs. Dependiendo de la implementacin tal nodo podra recibir
tramas.

La Figura 2.22 muestra el diagrama de estados de error de un nodo CAN.

Figura 2.22: Diagrama de Estados de Error.

Una cuenta de error de recepcin generalmente es incrementada en 9 por cada error
de recepcin detectado primero y en 1 por cada error de recepcin detectado
simultneamente con otros nodos, y es decrementado en 1 por cada trama recibida

exitosamente. Cuando la cuenta de error sobrepasa 96 se le indica al microcontrolador, a
pesar de ello el nodo sigue siendo de estado Activo.

Cuando el error sobrepasa el valor 127, el nodo pasa a estado Pasivo. As un nodo
indicara una tasa de error incrementada despus de la dcimo primera recepcin
errnea consecutiva y vendra a ser Pasivo despus de la dcimo quinta recepcin
consecutiva errnea. Un nodo no puede llegar al estado Suspendido debido a errores de
recepcin. Cuando el contador de recepcin sobrepasa el valor 127, en la prxima
recepcin exitosa de una trama ste ser establecido en un valor por debajo del lmite
del estado Pasivo.

La cuenta de error de transmisin es incrementada en un valor de 8 por cada error
de transmisin detectado y es decrementado en 1 por cada trama transmitida
exitosamente. Si el contador sobrepasa el valor de 96 una indicacin de taza de error
incrementada es establecida; si el contador sobrepasa 127 el estado del nodo cambia a
Pasivo, si el contador es ms grande que 255 el nodo pasa a estado Suspendido. En caso
de que cada intento de un nodo por transmitir sea errneo, el nodo se establecer en
estado Suspendido despus de 32 intentos de transmisin.

2.2.2.4 Formato Extendido de Trama
En la especificacin CAN ISO 11898-1 existe dos formato definidos: CAN 2.0A y
CAN 2.0B.

La diferencia entre CAN 2.0A y CAN 2.0B radica principalmente en la forma del
identificador. La especificacin CAN 2.0A define sistemas CAN con un estndar de 11
bit en el campo identificador (CAN estndar). CAN 2.0B especifica la trama extendida
con 29 bit en el identificador (CAN Extendido). Basado en el identificador de 29 bits
podemos distinguir hasta 512 millones de tramas posibles.

Los formatos de trama bsico y extendido son compatibles, es decir tramas de
ambos formatos pueden coexistir en la misma red y nodo. Los dos formatos son
distinguidos por el Bit Identificador de Extensin IDE, en el campo de control.


En el formato de trama extendido (Ver Figura 2.23), el identificador de 29 bits
comprende dos secciones, el Identificador Bsico de 11 bits (ID Bsico) as como un
Identificador Extendido de 18 bits (ID Extendido).

Figura 2.23: Estructura del formato extendido.


Captulo 3. Hardware del Sistema 55

CAPITULO 3. HARDWARE DEL SISTEMA

3.1 Introducci n
Los nodos construidos (Ver Figura 3.1) son gestionados por el microcontrolador
Renesas R8C/23 de 8bit, concretamente el R5F2138DFP. Adems dichas unidades de
comunicacin estn dotadas de interfaz CAN, RS-232 y un puerto de expansin I2C.

Figura 3.1: Cara Top de un nodo CAN bus.

Figura 3.2: Cara Bottom de un nodo CAN bus.

3.2 Microcontrol ador

3.2.1 Renesas
Renesas Technology Corporation es una empresa de inversin conjunta, entre las
compaas Hitachi y Mitsubishi Electric Corporation. Con sede en Tokio, fue creada el
1 de abril de 2003.

Se dedica al sector de los semiconductores, y se encarga del diseo, desarrollo y
fabricacin de una lnea de productos que se compone por sistemas digitales y
analgicos, microcontroladores, DSP, SoC, memorias, controladores LCD, ICs
estndar, ICs para aplicaciones especficas...

Su actividad la ha colocado entre las 20 empresas con mayor volumen de ventas de
semiconductores.

3.2.2 R8C/23 Group
La serie R8C/23 Group consiste en una extensa diversidad de microcontroladores
de 8 bits con arquitectura CISC que posee una alta velocidad de procesado y un
consumo de energa muy bajo. Se construye utilizando silicio de alto
rendimiento mediante proceso CMOS y est envasado en un encapsulado de 48 pines
Low-profile Quad Flat Package (LQFP o encapsulado cuadrado plano de perfil bajo).

Tiene una frecuencia mxima de operaciones de 20 MHz y soporta voltajes de
funcionamiento 2,2 a 5,5V. Entre sus principales interfaces destacan: UART, I2C,
convertidor 10-bit A/D, adems de mdulo hardware LIN y CAN. El uso de esta serie
de microcontroladores de Renesas est indicado para electrodomsticos, equipos de
oficina, equipos de potencia, automocin, industria etc.



Figura 3.3:3.2 Diagrama de bloques del R8C/23.

De la serie R8C/23 de Renesas destacaremos la versin R5F2138DFP, ya que, es el
microprocesador que utilizaremos en nuestro diseo. La diferencia de versiones del
R8C/23 Group se centra principalmente en el tamao de la memoria ROM. Por ejemplo
nuestro microcontrolador tiene un tamao de memoria ROM de 48Kbytes y 3Kbytes de
RAM.



Tabla 3.1: Gama de productos de R8C/23 Group.

Las principales caractersticas del R8C/23 son:
- Juego bsico de 89 instrucciones.
- 41 pines I/O y 3 pines de Input.
- Timer de 8 Bit con prescaler (Timer RA and RB): 2 canales.
- Timer de 16 Bit (Timer RD): 2 canales.
- Timer con funcin de comparacin (Timer RE): 1 canal.
- UART funciones sncronas: 1 canal.
- UART funciones asncronas: 1 canal.
- Interface I2C: 1 canal.
- Modulo LIN: 1 canal (Timer RA, UART0).
- Modulo CAN (2.0B): 1 canal, 16 slots.
- 10-bit A/D Converter: 12 canales.
- Watchdog Timer
- Circuitos de generacin de reloj: XIN Clock Generation Circuit, On-chip
Oscillator (High/Low Speed).
- Data Flash: 2 KB.
- Temperatura: 40 to 85C.



Figura 3.4: Encapsulado de R8C/23

El R5F2138DFP presenta 48 pines tipo LQFP, de los cuales, muchas tiene
funciones multiplexadas. Por ejemplo, en los pines 26 y 27 (Ver Figura 3.5: Pin-out de
R8C/23Figura 3.5Error! No se encuentra el origen de la referencia.) se encuentra la
entrada y la salida para la comunicacin serie, pero al mismo tiempo tambin utilizamos
esas patillas para el puerto P6 y para interrupciones. En el Anexo se encuentra
especificado todo el pin-out del dispositivo integrado, que segn la funcionalidad de
cada patilla podrn ser configuradas como entrada o salida.

Figura 3.5: Pin-out de R8C/23



3.2.3 Registros de la Unidad de Proceso.
La CPU del R8C contiene 13 registros, de los cuales R0, R1, R2, R3, A0, A1, y FB
estn agrupados formando un Banco de Registros.

Figura 3.6: Registros de la CPU R8C/23.

Registros de datos (R0, R1, R2 y R3): Son registros de 16 bits para la
transferencia de datos y en operaciones lgicas. R0 se puede dividir en bits de
orden superior (R0H) y en bit de orden inferior (R0L) para ser utilizadas por
separado. Lo mismo sucede con R1H y R1L. R2 se puede combinar con R0 para
ser utilizado como un registro de datos de 32 bit (R2R0).

Registros de Direccin (A1 y A0): A0 es un registro de 16 bits para el
direccionamiento indirecto y direccionamiento relativo. Tambin se utilizan para
la transferencia y las operaciones lgicas. Lo mismo ocurre con A1. El cual se

puede combinar con A0 para utilizar un registro de direcciones de 32 bits (A1,
A0).

Frame Base Register (FB): El registro FB tiene 16 bits y se usa para el
direccionamiento relativo a FB.

Tabla del registro de interrupcin (INTB): INTB es un registro de 20 bits, el
cual, indica la direccin de inicio de la tabla del vector de interrupcin.

Contador Programa (PC): El registro PC contiene 20 bits de ancho e indica la
direccin de una instruccin que va a ser ejecutada.

Stack Pointer (USP) y Interrupt Stack Pointer (ISP): El puntero de pila (SP),
USP y la ISP, son de 16 bits de ancho cada uno. La bandera U del registro FLG
se utiliza para alternar entre el USP y el ISP.

Static Base Register (SB): El SB es un registro de 16 bits para direccionamiento
relativo SB.

Registro de bandera (FLG): FLG es un registro de 11 bits que indica el estado de la
CPU.

Figura 3.7: Registro de Banderas.


- Carry Flag (C): Esta bandera, se pondr a 1 si se ha producido acarreo
(carry) en una instruccin de suma, de resta (borrow), o de
desplazamiento de bits en la unidad aritmtico/lgica.

- Debug Flag (D): La bandera D es slo para depuracin. Se establece en
0.

- Zero Flag (Z): La bandera Z se pone a 1 cuando una operacin aritmtica
da como resultado 0.

- Sign Flag (S): La bandera S se establece en 1 cuando una operacin
aritmtica obtiene como resultado un valor negativo.

- Register Bank Select Flag (B): El banco de registro 0 se selecciona
cuando la bandera B est a 0. El banco del registro 1 es seleccionado
cuando esta bandera se establece en 1.

- Overflow Flag (O): La bandera O se pone a 1 cuando la operacin dio
lugar a un desbordamiento, de lo contrario estar a 0.

- Interrupt Enable Flag (I): Esta bandera permite una interrupcin
enmascarable. La interrupcin se desactiva cuando la bandera se
establece en 0, y se activa cuando la bandera se establece a 1. Esta
bandera cambiar automticamente a 0 cuando la peticin de
interrupcin es aceptada.

- Stack Pointer Select Flag (U): El ISP es seleccionado cuando la bandera
U se establece en 0; el USP se selecciona cuando el indicador U se
establece en 1. La bandera U se establece en 0, cuando la solicitud de
interrupcin de hardware es aceptada o cuando se ejecuta una instruccin
INT para las interrupciones software Nos. 0 a 31.


- Processor Interrupt Priority Level (IPL): El IPL es de 3 bits y asigna los
niveles de interrupcin del procesador prioridad del nivel 0 al nivel 7. Si
solicita una interrupcin que tiene mayor prioridad que la IPL, la
interrupcin ser habilitada.

- Reserved Bit: Cuando escribamos este bit, escribiremos un 0. Cuando lo
leamos su contenido ser indefinido.

3.2.4 Mapa de memoria

Figura 3.8: Mapa de memoria del R8C/23

La serie R8C/23 tiene 1 MB de espacio de direcciones desde 00000h hasta
FFFFFH.

La ROM interna (ROM del programa) se asigna empezando por la direccin
0FFFFh. Para el vector de interrupcin se asigna direcciones desde 0FFDCh hasta
0FFFFh, en las cuales se almacenan la direccin de inicio de cada rutina de
interrupcin.


La ROM interna de datos (tipo flash) se asigna direcciones desde 02400h hasta
02BFFh. La memoria RAM interna se asigna direcciones desde 00400h.

As por ejemplo, 2,5Kbyte RAM interna se asignara direcciones de 00400h a
00DFFh. La RAM interna se utiliza no slo para almacenar datos, sino tambin para
llamar a subrutinas y para las solicitudes de interrupciones.

Los registros de funciones especiales (SFR) se asignan las direcciones desde
00000h hasta 002FFh y de 01300h a 0147Fh. Todas las direcciones dentro de la SFR no
estn asignadas, pero si estn reservadas para uso futuro y por tanto, el usuario no puede
acceder.

3.2.5 Modulo CAN de R8C/23

Figura 3.9: Diagrama de bloques de modulo can del R8C/23.

Este microcontrolador dispone de un completo mdulo de CAN, el cual, puede
transmitir y recibir mensajes, tanto en modo estndar (11bits) como en modo de
identificacin extendida (29 bits).


El mdulo CAN dispone de 16 espacios (slots) para almacenar los mensajes que se
enva o los que recibimos, estos 16 slots se llaman "message box".

A continuacin se describen los diferentes bloques del mdulo CAN:
CTx/CRx: pines entrada-salida de CAN.
Protocol controller: Este controlador maneja el arbitraje del bus y los servicios
de protocolo de la CAN, es decir, bit timing, stuffing, error status etc.
Message box: Este bloque de memoria consta de 16 ranuras o espacios, que se
pueden configurar como transmisor o receptor. Cada espacio contiene un
identificador (ID) individual, el cdigo del tamao de los datos que tendr el
mensaje, un campo de datos de 8 bits y un "time stamp".
Acceptence filter: Este bloque filtra los identificadores (ID) de los mensajes
recibidos. Para hacer esta tarea de filtrado, se utilizan los registros C0GMR,
C0LMAR y C0LMBR.
16 bit timer: Se utiliza para la funcin "time stamp. Cuando recibimos un
mensaje, este se almacena en la memoria y el valor del timer se queda guardado
en el "timer stamp".
Wake up function: La interrupcin de "CAN 0 wake up" se genera mediante un
mensaje desde el CAN bus.
Interrupt generator function: Los eventos de interrupcin provienen del mdulo
CAN 0. Los tipos de interrupcin pueden ser por recepcin, transmisin, error y
wake up.


3.3 CAN Transcei ver
Como se vio en la seccin 2.2.1.4, necesitamos un transceiver para acceder al bus y
poder comunicarnos. En nuestro sistema empotrado utilizaremos el circuito integrado
L9616 del fabricante STMicroelectronics.

El L9616 es la interfaz entre el modulo CAN del microcontrolador y el bus fsico,
el cual, acta principalmente como un transmisor-receptor bidireccional, aunque
tambin protege al bus de cortocircuitos y ruido elctrico.

En caso de cortocircuito, el circuito de proteccin reconoce el fallo y las etapas de
salida del transmisor se desactivan para evitar la destruccin del mdulo controlador de
CAN Bus.

Figura 3.10: Diagrama de bloques del L9616.



Figura 3.11: Pin-out del L9616. Tabla 3.2: Funcin de cada pin del L9616.

3.4 Emulador/Programador E8

Figura 3.12: Conexin del emulador E8.

El emulador E8, es un dispositivo cuya unidad principal est conectada a travs de
un interfaz al sistema de usuario que estemos programando.

El emulador se conecta a un PC mediante el puerto USB. Una vez conectado, el
usuario del sistema puede realizar una emulacin cercana a las operaciones reales de
producto final. As mismo, el E8 puede ser usado para descargar los programas de
usuario al microcontrolador mediante la herramienta Flash Development Toolkit de
Renesas.

Para la programacin del firmware el fabricante ofrece un entorno de desarrollo
integrado llamado High-performance Embedded Workshop, el cual proporciona enlaces
sin problemas entre el E8 y una variedad de herramientas de desarrollo de software,
tales como el compilador de C y simuladores. El resultado es la creacin de una
herramienta que permite el desarrollo de programas a travs de interfaces integradas,
desde la codificacin hasta la construccin y depuracin.

El E8 suministrar la alimentacin al sistema durante la conexin, podremos seleccionar
3,3V o 5V.


3.5 Esquemtico de Conexi n
3.5.1 Esquemas Elctricos

Figura 3.13: Conexin del Microcontrolador.


Figura 3.14: Conexionado del circuito electrnico.

a) Circuito de reset

Figura 3.15: Circuito Reset.

Nuestro sistema consta de un circuito reset, para que en caso necesario, los registros
se pongan a cero y se reinicialice todo el sistema.

El reset se produce usando el pin 7 del microcontrolador, aplicando una seal baja.
Al detectarse la transicin de valor 0 a 1 la CPU y los registros SFR son inicializados, y
el programa se ejecuta comenzando en la direccin indicada por el vector de reset.

El circuito montado est formado por un pulsador en paralelo con un condensador
cermico de 100nF, de esta forma estabilizaremos la seal y eliminaremos el ruido que
introduce el pulsador. El resto son resistencias de pull-up y un diodo 1N4007 necesario
para descargar el condensador rpidamente cuando se presiona el pulsador.

b) Circuito de Reloj

Figura 3.16: Circuito de Reloj.

El Reloj es un elemento fundamental en un sistema empotrado. Todos los
microcontroladores llevan integrado un oscilador y slo necesitan un elemento externo
para fijar la frecuencia y as poder funcionar dicho reloj interno.


Nuestro circuito oscilador est compuesto por un cristal de cuarzo, que genera una
onda de 20Mhz, adems dos condensadores cermicos de 6pF que estabilizan la seal.

c) Circuito de Alimentacin

Figura 3.17: Circuito de Alimentacin.

Para que funcione el circuito correctamente necesitaremos una tensin de
alimentacin de +5V. Para ello, conectaremos un transformador a la red elctrica, el
cual, debe facilitar una tensin entre 7 y 12 voltios. Mediante una tornillera enlazaremos
dicho transformador con el regulador de tensin para obtener los 5V que se necesitan.
Se utilizara el regulador 78049 de National Semiconductor Corporation, el cual
posee un montaje con dos condensadores de Tntalo, recomendado por el fabricante.

Tambin se ha colocado un diodo led rojo con su correspondiente resistencia 1,6K
para indicar cuando se encuentra activa la alimentacin en el circuito.


d) Circuito de entradas y salidas

Figura 3.18: Circuito de Entradas.

Segn los requerimientos del diseo del sistema, se ha colocado un pulsador y dos
switch de 3 pines cada uno. Posteriormente, mediante software asignaremos el puerto 1
del microcontrolador en modo entrada, de este modo realizaremos la lectura de los
pulsadores o switchs.

El switch asignado para introducir direcciones, pertenecer a los bits p1_0, p1_1,
p1_2 del puerto 1; de la misma forma que el switch correspondiente para introducir
datos estar conectado a los bits p1_3, p1_4 y p1_5 del mismo puerto. El pulsador se
conectara al bit p1_7. (Ver Figura 3.13).


Figura 3.19: Circuito de Salidas.

En cada nodo existen 6 diodos led, para la interpretacin de datos recibidos y otras
posibles indicaciones. Como podemos ver en el esquema anterior, dichos led estarn
conectados en la configuracin de nodo comn y con una resistencia de regulacin de
corriente de 1,6k.

Estos diodos led estn conectados al puerto 2 (desde p2_1 hasta p2_6),
obviamente, dicho puerto deber estar configurado como salida. (Ver Figura 3.13)

e) Circuito transceiver CAN

Figura 3.20: Conexin del Transceiver L9616.


La conexin del transceiver es tal como se observa en el esquema anterior, de este
modo, podremos comunicarnos con el bus de transmisin. (Ver Seccin 3.3)

El pin 1 (TXD) del transceiver ir conectado a la patilla nmero 43 (CTX0) de
nuestro microcontrolador. Del mismo modo, el RXD del transceiver se interconectara
con la patilla 42 (CRX0).

Las salidas CANH y CANL son el par diferencial, (Ver Seccin 2.2.1.3Topologa
de Red) por lo que estos pines irn directamente conectados al medio fsico. Como se
mencion en la seccin 2.2.1.3, se necesitan resistencias de terminacin del bus, para
evitar posibles reflexiones de la seal, por ello, el jumper (J2) cuando est en
cortocircuito, se activar la resistencia de 120 Ohms.

f) Circuito Puerto Serie

Figura 3.21: Conexin del interfaz Serie RS-232.

Como previsin para futuras aplicaciones de nuestro sistema (por ejemplo:
comunicacin con PC mediante Labview), se ha implementado en cada nodo el
hardware necesario para una comunicacin serie RS-232. El driver utilizado es el
integrado MAX3222, el cual se conecta segn las especificaciones del datasheet del
fabricante.


Como se puede ver en la Figura 3.21 la patilla DIN1 del MAX3222 se conectar al
pin numero 26 (TXD1) de nuestro microcontrolador, del mismo modo que la patilla
ROUT1 de MAX3222 se conecta al pin numero 27 (RXD1). La entrada R1IN y salida
D1OUT del MAX3222 se conectaran al conector DB9-F para la interconexin con el
medio fsico.

g) - Puerto de expansin I2C

Figura 3.22: Esquema para la conexin del bus I2C.

Igual que en el apartado anterior, y as obtener un sistema abierto, es recomendable
implementar un circuito para la conexin del bus I2C en futuras aplicaciones (por
ejemplo: lectura de sensores de temperatura).

En la figura anterior, existe 2 pines que corresponden al hilo SCL y SDA del bus
I2C, los cuales, irn conectados a las patillas 1 y 3 del microcontrolador (Ver Figura
3.13).

As mismo, se ha colocado pines de alimentacin y tierra para el posible suministro
de tensin de circuitos externos.


h) Circuito conector E8

Figura 3.23: Conexin para emulador E8.

Como se vio en la seccin 3.4, se utiliza un conector de 14 pines para la
interconexin del emulador/Programador E8 de Renesas. Segn las especificaciones del
fabricante, el pin P16 se conecta a la patilla mode (pin 4) del microcontrolador y el pin
RESn del conector se une con la patilla 7 (reset) del microcontrolador.


3.5.2 PCB Layout.
En la siguiente figura se encuentra el diseo de las placas de cobre, que
posteriormente, sern los nodos de comunicacin que el sistema requiere.

Para su mejor apreciacin, se ha eliminado el plano de tierra de las Figura 3.24 y
Figura 3.25.

Figura 3.24: Cara Top.

El boceto de los circuitos impreso se ha realizado mediante el software de diseo PCAD
2006, de Altium.

Figura 3.25: Cara Bottom.

3.5.3 BOM

COMPONENTES 1 NODO COMPONENTES 1 NODO
Pulsadores 2 Resistencia 100 2
Cristal 20Mhz 1 Led Rojo 1
Diodo 1N4007 1 Led Verde 3
Switch Slide 3 spst dip 2 Led Naranja 3
Bornes de conexin 4 Pines acodados 4
Capacidad tntalo 10uF 2 Pines no acodados 2
Capacidad ceram 100nF 14 Conector E8 1
Capacidad ceram 6pF 2 Conector DB9 F 1
Capacidad ceram 56pF 2 R8C/23 1
Resistencia 50k 8 Max 232 1
Resistencia 4,7k 5 L9616 1
Resistencia 1,6k 7 78049 1
Resistencia 120 1
Resistencia 10k 2
Tabla 3.3: Componentes utilizados.


Captulo 4. Software del Sistema 81

CAPITULO 4. SOFTWARE DEL SISTEMA.

4.1 Introducci n
A continuacin se describe todo lo concerniente al proceso de desarrollo del
firmware, as como las herramientas necesarias para su implementacin.

Como se ha mencionado en otras ocasiones, el entorno de desarrollo software ser
el High-performance Embedded Workshop 4.09 (HEW), el cual ser el encargado de
compilar, ensamblar y linkar los archivos con las lneas de cdigo en un nico fichero.
Durante la programacin, el cdigo fuente ser dividido en mltiples ficheros o
libreras, para que sea ms legible y entendible. Renesas proporciona ciertas libreras
para facilitar la programacin de sus microcontroladores. En nuestro caso, se utilizarn
las libreras, disponibles en la propia pgina web, para aplicaciones CAN bus
compatibles con el microcontrolador R8C/23.

Una vez linkado el cdigo, se utilizar la aplicacin Flash Development Toolkit,
para la descarga del firmware en la memoria del microcontrolador.

4.2 High-performance Embedded Workshop

Figura 4.1: Entorno de desarrollo.

HEW es un acrnimo de High-performance Embedded Workshop (Taller de alto
rendimiento para sistemas empotrados). ste integra varias herramientas como el
compilador, ensamblador, depurador y editor en un mismo interfaz grfico. Adems,
mediante el programador/emulador E8 (Ver seccin 3.4) se comunica con el Programa
monitor de ROM (en la flash del microcontrolador) para depurar el firmware creado.

El paquete HEW incluye lo siguiente:
- Compilador NC30: Compilador C. Se ajusta al estndar ANSI C.
- Ensamblador AS30: Ensamblador reubicable. Soporta lenguaje ensamblador
estructurado y una gran variedad de macroinstrucciones.
- Linker LN30: Linkador.
- Programador E8: Software de programacin para flash de microcontroladores
Renesas.

4.3 Flash Devel opment Toolkit

Figura 4.2: Herramienta de descarga del firmware.

Flash Development Toolkit (FDT), es el kit de programacin Flash suministrado
por Renesas.


El FDT nos permite la programacin, borrado y lectura de la memoria flash del
microcontrolador. De este modo, podemos alojar de forma permanente la ltima versin
del firmware desarrollado para el R8C/23.

4.4 Firmware

4.4.1 Algoritmos

Figura 4.3: Algoritmo Nodo Maestro.


Figura 4.4: Algoritmos Nodos Esclavos.

4.4.2 Cdigo C de Nodo Maestro
/**********************************************************************
**Proyecto CANBus **
**Jos Mara Sancho **
**Ingeniera Tcnica Industrial en Electrnica Industrial **
** **
**Escuela Tcnica Superior de Ingeniera **
**UNIVERSIDAD DE HUELVA **
** **
**Septiembre 2011 **
**********************************************************************
**Firmware Nodo Maestro **
**Versin del Nodo: 1.0 **
**********************************************************************
**********************************************************************
Nombre del Archivo: main.c
Descripcin:
Maestro:
Cuando el pulsador SW2 se encuentre activo, se enviara un dato con
mayor prioridad a los esclavos, estos deben responder con otro mensaje.
Cuando el maestro reciba un dato de cualquiera de sus esclavos se
actualizara los leds.

Hay que tener en cuenta que la versin de los nodos maestros es la 1.0,
es anterior a la de los nodos esclavos. La diferencia est en el nmero de
Leds y numero de pulsadores, por lo que hay que prestar especial atencin al
configurar las entradas y salidas. El resto de hardware no vara en nada donde
influya la programacin del firmware.
**********************************************************************/
/**********************************************************************
System Includes
**********************************************************************/
#include <string.h>
/**********************************************************************

User Includes
**********************************************************************/
/* sfr_r823.h provides common defines for widely used items. */
#include "sfr_r823.h"
#include "delay.h"
#include "RSKR8C23Def.h"
#include "main.h"
#include "can0.h"

/*Se designan las cadena de caracteres que se utilizaran*/
unsigned char RxRespuestaSclavo[2] ={"r"};
unsigned char TxPeticionMaestro[2] ={"p"};
unsigned char TxDataBuff_0[2] ={"a"};
unsigned char TxDataBuff_1[2] ={"b"};
unsigned char TxDataBuff_2[2] ={"c"};
unsigned char TxDataBuff_3[2] ={"d"};
unsigned char TxDataBuff_4[2] ={"e"};
unsigned char TxDataBuff_5[2] ={"f"};
unsigned char TxDataBuff_6[2] ={"g"};
unsigned char TxDataBuff_7[2] ={"h"};
/*Vector de memoria para guardar la informacin recibida*/
unsigned char RxDataBuff[2];
int iStatus =NO_ERROR;

void main(void){
/*Configuracin de puertos*/
pd2 =0xff; //Leds, Output
pd1_7 =0; //Pulsador, Input
pd4_5 =0; //Pulsador, Input

/*Iniciar con leds apagados*/
p2_6=1; /*L0*/
p2_5=1; /*L1*/
p2_4=1; /*L2*/

InitCAN0(); //Iniciar modulo CAN
SetCAN0Id( 0, 0x00000000 );
SetCAN0Id( 2, 0x000000CC );
SetCAN0Id( 3, 0x000000DD );
SetCAN0Id( 4, 0x000000EE );
SetCAN0Id( 5, 0x000000FF );
/*Configuracin de ID de los slot de transmisin
y de recepcin.*/

/* El modo de funcionamiento es FullCAN, por lo que tenemos 16 slot
de tiempo para la transmisin o recepcin de los mensajes.
Utilizaremos el slot 0 para la transmisin y los
slot 2, 3, 4, 5 (cuatro nodos) para la recepcin. Para el resto de slots
es indiferente su configuracin.

Cada slot tiene asociado un ID, lo que quiere decir que a ese
espacio de memoria
llegar el mensaje con idntico ID.
ID slot 0: 0x00000000H, Mxima prioridad
ID slot 2: 0x000000CCH
ID slot 3: 0x000000DDH
ID slot 4: 0x000000EEH
ID slot 5: 0x000000FFH, Menor prioridad */

/* While bloqueante, comienzo de las operaciones con CAN*/
while(1){
iStatus =PollCAN0Message (RX_SLOT_02);
/*PollCAN0Message () Comprueba si existe algn dato nuevo en el
slot2,
en caso de haber datos nuevos, devolver la variable
iStatus=NO_ERROR */

if(NO_ERROR ==iStatus ){


c0mctl2.receive.newdata='0';
//bandera de dato recibido a 0, para recibir otros

iStatus =ReadCAN0Message(RX_SLOT_02, RxDataBuff);
/* ReadCAN0Message () lee el mensaje que se ha recibido en el slot 2 y
almacena la informacin en el vector RxDataBuff. Si se realiza
la operacin correctamente, devolver la variable
iStatus=NO_ERROR*/

if( 0 ==strcmp(TxDataBuff_1, RxDataBuff) ){
//Compara para saber la informacin recibida
//si RxDataBuff ==b -->muestra en leds 001
p2_4=1; //off
p2_5=1; //off
p2_6=0; //on
}//fin 001

else if( 0 ==strcmp(TxDataBuff_2, RxDataBuff) ){
//si RxDataBuff ==c -->muestra en leds 010
p2_4=1; //off
p2_5=0; //on
p2_6=1; //off
}//fin 010

//si RxDataBuff ==d -->muestra en leds 011
p2_4=1; //off
p2_5=0; //on
p2_6=0; //on
}//fin 011


//si RxDataBuff ==e -->muestra en leds 100
p2_4=0; //on
p2_5=1; //off
p2_6=1; //off
}//fin 100

//si RxDataBuff ==f -->muestra en leds 101
p2_4=0; //on
p2_5=1; //off
p2_6=0; //on
}//fin 101

//si RxDataBuff ==g -->muestra en leds 110
p2_4=0; //on
p2_5=0; //on
p2_6=1; //off
}//fin 110

//si RxDataBuff ==h -->muestra en leds 111
p2_4=0; //on
p2_5=0; //on
p2_6=0; //on
}//fin 111

} //Fin escribir mostrar informacin recibida en los leds
}//Fin de leer mensaje de RX_SLOT_02 (slot 2)

/*PollCAN0Message () Comprueba si existe algn dato nuevo en el slot 3,
en caso de haber datos nuevos, devolver la variable iStatus=NO_ERROR */


//bandera de dato recibido a 0, para poder recibir otros

iStatus=NO_ERROR*/

p2_4=1;
p2_5=1;
p2_6=0;
}//fin 001

p2_4=1;
p2_5=0;
p2_6=1;
}//fin 010

p2_4=1;
p2_5=0;
p2_6=0;
}//fin 011


p2_4=0;
p2_5=1;
p2_6=1;
}//fin 100

p2_4=0;
p2_5=1;
p2_6=0;
}//fin 101

p2_4=0;
p2_5=0;
p2_6=1;
}//fin 110

p2_4=0;
p2_5=0;
p2_6=0;
}//fin 111

} //Fin mostrar informacin recibida en los leds



//bandera de dato recibido a 0, para recibir otros

iStatus=NO_ERROR*/

p2_4=1; //off
p2_5=1; //off
p2_6=0; //on
}//fin 001

p2_4=1; //off
p2_5=0; //on
p2_6=1; //off
}//fin 010

p2_4=1; //off
p2_5=0; //on
p2_6=0; //on
}//fin 011


p2_4=0; //on
p2_5=1; //off
p2_6=1; //off
}//fin 100

p2_4=0; //on
p2_5=1; //off
p2_6=0; //on
}//fin 101

p2_4=0; //on
p2_5=0; //on
p2_6=1; //off
}//fin 110

p2_4=0; //on
p2_5=0; //on
p2_6=0; //on
}//fin 111

} //Fin mostrar informacin recibida en los leds



//bandera de dato recibido a 0, para recibir otros datos

iStatus=NO_ERROR*/

p2_4=1; //off
p2_5=1; //off
p2_6=0; //on
}//fin 001

p2_4=1; //off
p2_5=0; //on
p2_6=1; //off
}//fin 010

p2_4=1; //off
p2_5=0; //on
p2_6=0; //on
}//fin 011


p2_4=0; //on
p2_5=1; //off
p2_6=1; //off
}//fin 100

p2_4=0; //on
p2_5=1; //off
p2_6=0; //on
}//fin 101

p2_4=0; //on
p2_5=0; //on
p2_6=1; //off
}//fin 110

p2_4=0; //on
p2_5=0; //on
p2_6=0; //on
}//fin 111

} //Fin escribir mostrar informacin recibida en los leds

/*Final de lectura de slot*/

/*Comienzo de escritura de mensajes en el bus con mxima prioridad*/
if (p4_5==0){ //Pulsador sw2 activo

//En los leds se indica que se ha pulsado sw2
p2_6=1; //L0 off
p2_5=0; //L1 on
p2_4=1; //L2 off

WriteCAN0Message(TX_SLOT_00,DATA_LEN_2,
TxPeticionMaestro);
/* WriteCAN0Message () escribe en el slot de
Transmisin (slot 0) el mensaje que deseamos transmitir,
al subprograma se enva el nmero de slot,
el tamao de la informacin (en nuestro caso son 2 bytes)
y dicha informacin en si */

SendCAN0Message(TX_SLOT_00);
/* Transmisin del mensaje */

iStatus =Check_err_can01();
/* Comprueba de que no existan errores en la transmisin */

if(NO_ERROR !=iStatus ){
/*Encuentra un error, entonces mostramos una seal en los leds*/
p2_6=0; //on
p2_5=0; //on
p2_4=0; //on
DelayS(1); //espera 1seg
p2_6=1; //off
p2_5=1; //off
p2_4=1; //off
DelayS(1);
p2_6=0; //on
p2_5=0; //on
p2_4=0; //on
continue;
}

else if(NO_ERROR ==iStatus ){
/*Si no hay errores en la transmisin,
esperamos a que responda algn esclavo*/

p2_5=0; //encendemos led de confirmacin de transmisin

/*PollCAN0Message()Comprueba si existe algn dato
nuevo en el slot 2, en caso de haber datos nuevos, devolver la
variable iStatus=NO_ERROR */
/*Comprobamos que al menos el nodo 2 ha respondido a la
peticin hecha por el maestro*/

if(NO_ERROR ==iStatus){

ReadCAN0Message(RX_SLOT_02, RxDataBuff);
/* ReadCAN0Message () lee el mensaje que se ha
recibido en el slot 2 y almacena la informacin en
el vector RxDataBuff. Si se realiza la operacin
correctamente, devolver la variable
iStatus=NO_ERROR*/

If (0==strcmp(RxRespuestaSclavo, RxDataBuff)){
/*Si el dato ledo es la respuesta que debe dar el
esclavo, entonces:*/
p2_6=0; //L0 on
p2_5=1; //L1 off
p2_4=0; //L2 on
DelayS(1); //Espera 1seg
p2_6=1; //off
p2_5=0; //on
p2_4=1; //off
DelayS(1); //Espera 1seg
p2_6=0; //on

p2_5=1; //off
p2_4=0; //on
} //Fin escritura en led
}//Fin lectura de la informacin
continue;
}
}//Fin if del sw2
} //Fin while(1)
}
/**********************************************************************
Firmware Nodo Maestro 1.0
Septiembre 2011
**********************************************************************/


4.4.3 Cdigo C de Nodos Esclavos

/**********************************************************************
**Proyecto CANBus **
**Jos Mara Sancho **
**Ingeniera Tcnica Industrial en Electrnica Industrial **
** **
**Escuela Tcnica Superior de Ingeniera **
**UNIVERSIDAD DE HUELVA **
** **
**Septiembre 2011 **
**********************************************************************
** Firmware Nodos Esclavos **
** Versin del Nodo: 2.0 **
**********************************************************************
**********************************************************************
Nombre del Archivo: main.c
Descripcin:
Esclavo:
Ocasionalmente cuando los esclavos reciban un dato del maestro,
estos transmitirn un respuesta programada al maestro y se
actualizarn los leds.
El funcionamiento habitual es cuando se selecciona un dato en lo switch
y al presionar SW1 se enva los datos y los muestra en los leds.

Hay que tener en cuenta que la versin de los nodos esclavos es la 2.2,
es posterior a la del nodo maestro. La diferencia est en el nmero de
Leds y numero de pulsadores, por lo que hay que prestar especial atencin al
configurar las entradas y salidas. El resto de hardware no vara en nada donde
influya la programacin del firmware.
**********************************************************************/
/**********************************************************************
System Includes
**********************************************************************/

#include <string.h>
/**********************************************************************
User Includes
**********************************************************************/
/* sfr_r823.h provides common defines for widely used items. */
#include "sfr_r823.h"
#include "RSKR8C23Def.h"
#include "main.h"
#include "can0.h"
#include "delay.h"

#pragma SECTION program expanded_program
/*Activar memoria extendida este programa tiene muchas lneas de cdigo y
necesitamos usar la memoria extendida. En sect30.inc tambin se han incluido unas
lneas para la memoria extendida*/

/*Declaramos las cadenas de caracteres que contendr la
informacin que enviaremos o recibiremos a travs del bus*/
unsigned char TxRespuestaSclavo[2] ={"r"};
unsigned char RxPeticionMaestro[2] ={"p"};
unsigned char TxDataBuff_0[2] ={"a"};
unsigned char TxDataBuff_1[2] ={"b"};
unsigned char TxDataBuff_2[2] ={"c"};
unsigned char TxDataBuff_3[2] ={"d"};
unsigned char TxDataBuff_4[2] ={"e"};
unsigned char TxDataBuff_5[2] ={"f"};
unsigned char TxDataBuff_6[2] ={"g"};
unsigned char TxDataBuff_7[2] ={"h"};
/*Vector de memoria para guardar la informacin recibida*/
unsigned char RxDataBuff[2];
unsigned char cuent=0;
unsigned char espero=0;


void main(void){

/*Configuracin de puertos*/
pd2 =0xff; //Leds, output
pd1 =0x00; //Switchs y pulsador, input
p2=0xff; //Iniciar con leds apagados

InitCAN0(); //Iniciar modulo CAN
SetCAN0Id( 1, 0x00000000 );
/*Configuracin del ID del slot 1,
se utiliza como recepcin de mensajes del maestro.
El slot de transmisin se configura a continuacin*/

/* El modo de funcionamiento es FullCAN, por lo que tenemos 16 slot
de tiempo para la transmisin o recepcin de los mensajes.
Utilizaremos el slot 0 para la transmisin y el
slot 1 (solo tenemos que recibir informacin del maestro)para
la recepcin. Para el resto de slots es indiferente su configuracin.

Este firmware tiene que servir para todos los nodos esclavos, por lo
que al principio esperaremos a que el usuario seleccione el numero
de nodo. Despus de saber el nmero de nodo, sabremos el ID con que
podr enviar los mensajes dicho nodo.

Cada slot tiene asociado un ID, lo que quiere decir que a ese espacio
de memoria llegar el mensaje con idntico ID. El ID se ha configurado
en cano.h
ID slot 0: 0x000000--H, depender del nmero de nodo que seleccionemos
ID slot 1: 0x00000000H, Mxima prioridad */

/*Espero a que el usuario indique el nmero de nodo*/
while (espero==0){
if (p1_7==0){
/*Cuando el usuario presione SW1, debe estar

seleccionado el nmero de nodo*/

/*Configuro ID del slot 0*/
if (p1_0==0 && p1_1==0 && p1_2==1){ //nodo 1 -->001
SetCAN0Id( 0, 0x000000CCL );
/*Los mensajes que salga por el slot 0
tendrn el ID 0x000000CC*/
}
else if (p1_0==0 && p1_1==1 && p1_2==0){ //nodo 2 -->010
SetCAN0Id( 0, 0x000000DD );
tendrn el ID 0x000000DD*/
}
else if (p1_0==0 && p1_1==1 && p1_2==1){ //nodo 3 -->011
SetCAN0Id( 0, 0x000000EE );
tendrn el ID 0x000000EE*/
}
else if (p1_0==1 && p1_1==0 && p1_2==0){ //nodo 4 -->100
SetCAN0Id( 0, 0x000000FF );
tendrn el ID 0x000000FF*/
}
espero=1; //Ya se puede salir del bucle
}//Fin if de pulsador activo
}//Fin while de esperar al usuario

/* While bloqueante, comienzo de las operaciones con CAN*/
while(1) {

iStatus =PollCAN0Message(RX_SLOT_01);



//bandera de dato recibido a 0, para recibir otros datos

/* ReadCAN0Message()lee el mensaje que se ha recibido en el slot 1 y
iStatus=NO_ERROR*/

if( 0 ==strcmp(RxPeticionMaestro, RxDataBuff) ){
/*Compara para saber la informacin recibida
si RxDataBuff ==p -->he recibido una peticin
del maestro por lo que hay que enviar respuesta*/

WriteCAN0Message(TX_SLOT_00,
DATA_LEN_2, TxRespuestaSclavo);
/*Se escribe la respuesta que enviaremos a travs
del slot 0*/

//Se enva el mensaje

iStatus =Check_err_can01(); //Check errores

/*Si hay errores en la transmisin, los leds
parpadean*/
p2=0x00; //on
DelayS(1);
p2=0xff; //off

DelayS(1);
p2=0x00; //on
continue;
}
else if (NO_ERROR ==iStatus ){
/*No hay error en la transmisin,
parpadean algunos leds*/
p2=0xDB;
//11011011, enciende 2 led del centro
DelayS(1);
p2=0xA5;
//10100101, enciende los 4 led extremos
DelayS(1);
p2=0xDB;
//11011011, enciende 2 led del centro
DelayS(1);
p2=0xA5;
//10100101, enciende los 4 led extremos
continue;
}
}//Fin de envo de peticin de maestro
} //Fin if
}//Fin if

/*Comienza la fase de lectura de datos en los switch y envi de estos.
Cuando se pulse SW1 debe estar seleccionado el dato en el switch DATO*/

if (p1_7==0){
p2=0xff; //leds apagados
if (p1_3==0 && p1_4==0 && p1_5==1) {
/* Se ha seleccionado en el switch el dato 001, por lo que le
enviamos al maestro la informacin*/


DATA_LEN_2, TxDataBuff_1);
/*Escribimos el dato que deseamos mandar, 001 -->b*/

SendCAN0Message(TX_SLOT_00); //Inicia la transmisin


parpadearan*/
p2=0x00; //on
DelayS(1);
p2=0xff; //off
DelayS(1);
p2=0x00; //on
continue;
}

se muestra el dato enviado en los leds, 001*/
p2_6=1; //off
p2_5=1; //off
p2_4=0; //on
DelayS(1);
p2_4=1; //off
DelayS(1);
p2_4=0; //on
DelayS(1);
p2_4=1; //off
DelayS(1);
p2_4=0; //on
continue;
}

} //Fin dato 011

if (p1_3==0 && p1_4==1 && p1_5==0) {
/*Se ha seleccionado en el switch el dato 010, por lo que le

/*Escribimos el dato que deseamos mandar, 010 -->c*/

SendCAN0Message(TX_SLOT_00); //Inicio transmisin


parpadean*/
p2=0x00; //on
DelayS(1);
p2=0xff; //off
DelayS(1);
p2=0x00; //on
continue;
}
p2_6=1; //off
p2_5=0; //on
p2_4=1; //off
DelayS(1);
p2_5=1; //off
DelayS(1);
p2_5=0; //on

DelayS(1);
p2_5=1; //off
DelayS(1);
p2_5=0; //on
continue;
}
}//Fin 010

if (p1_3==0 && p1_4==1 && p1_5==1) {

/*Escribimos el dato que deseamos mandar, 011 -->d*/

SendCAN0Message(TX_SLOT_00); //Inicia transmisin


parpadean*/
p2=0x00; //on
DelayS(1);
p2=0xff; //off
DelayS(1);
p2=0x00; //on
continue;
}
p2_6=1;

p2_5=0;
p2_4=0;
DelayS(1);
p2_5=1;
p2_4=1;
DelayS(1);
p2_5=0;
p2_4=0;
DelayS(1);
p2_5=1;
p2_4=1;
DelayS(1);
p2_5=0;
p2_4=0;
continue;
}
} //Fin if 011

if (p1_3==1 && p1_4==0 && p1_5==0) {

/*Escribimos el dato que deseamos mandar, 100 -->e*/

SendCAN0Message(TX_SLOT_00);//Inicia la transmisin


parpadean*/
p2=0x00; //on

DelayS(1);
p2=0xff; //off
DelayS(1);
p2=0x00; //on
continue;
}
p2_6=0; //on
p2_5=1; //off
p2_4=1; //off
DelayS(1);
p2_6=1;
DelayS(1);
p2_6=0;
DelayS(1);
p2_6=1;
DelayS(1);
p2_6=0;
continue;
}
} //Fin if 100

if (p1_3==1 && p1_4==0 && p1_5==1) {

/*Escribimos el dato que deseamos mandar, 101 -->f*/

//Inicio de la transmisin


parpadean*/
p2=0x00; //on
DelayS(1);
p2=0xff; //off
DelayS(1);
p2=0x00; //on
continue;
}
p2_6=0; //on
p2_5=1; //off
p2_4=0; //on
DelayS(1);
p2_6=1;
p2_4=1;
DelayS(1);
p2_6=0;
p2_4=0;
DelayS(1);
p2_6=1;
p2_4=1;
DelayS(1);
p2_6=0;
p2_4=0;
continue;
}
} //Fin if 101


if (p1_3==1 && p1_4==1 && p1_5==0) {

/*Escribimos el dato que deseamos mandar, 110 -->g*/



parpadean*/
p2=0x00; //on
DelayS(1);
p2=0xff; //off
DelayS(1);
p2=0x00; //on
continue;
}
p2_6=0; //on
p2_5=0; //on
p2_4=1; //off
DelayS(1);
p2_6=1;
p2_5=1;
DelayS(1);
p2_6=0;

p2_5=0;
DelayS(1);
p2_6=1;
p2_5=1;
DelayS(1);
p2_6=0;
p2_5=0;
continue;
}
} //Fin if 110

if (p1_3==1 && p1_4==1 && p1_5==1) { /*datos=111*/

/*Escribimos el dato que deseamos mandar, 111 -->h*/



parpadean*/
p2=0x00; //on
DelayS(1);
p2=0xff; //off
DelayS(1);
p2=0x00; //on
continue;
}

p2_6=0; //on
p2_5=0; //on
p2_4=0; //on
DelayS(1);
p2_6=1;
p2_5=1;
p2_4=1;
DelayS(1);
p2_6=0;
p2_5=0;
p2_4=0;
DelayS(1);
p2_6=1;
p2_5=1;
p2_4=1;
DelayS(1);
p2_6=0;
p2_5=0;
p2_4=0;
continue;
}
} //Fin if 111
} //Fin de envo de la informacin capturada en SW1
} //Fin while bloqueante
} //Fin main

/**********************************************************************
Firmware Nodos Esclavos 2.2
Septiembre 2011
**********************************************************************/
4.4.4 Libreras

Como se mencion anteriormente, para la programacin del firmware de los nodos,
se ha utilizado las libreras para CAN de Renesas (can0.c y el archivo de cabecera
can0.h).

A continuacin se muestras los subprogramas, ms utilizados en nuestro sistema,
contenido en dicha librera.

/**********************************************************************
FILE NAME : CAN.C
DESCRIPTION : Controller Area Network

Copyright : 2006 Renesas Technology Europe Ltd.
All Rights Reserved
**********************************************************************
Revision History
DD.MM.YYYY OSO-UID Description
10.07.2006 RTE-NPS First Release
**********************************************************************/

/**********************************************************************
Function Name: WriteCAN0Message
Description: Write message to CAN.
Parameters : Slot : Slot / Message box No.(Valid 0 to 15 only)
Length : Message length (Valid 1 to 8 only)
ptrData: Pointer to Write Data buffer

Return value : Error Status
NO_ERROR : on successful write.
LENGTH_ERROR: if error lenght is invalid (Valid 1 to 8 only)
SLOT_ERROR: if slot is not correct (Valid 0 to 15 only)
**********************************************************************/

int WriteCAN0Message(unsigned char Slot, unsigned char Length, unsigned char
*ptrData)
{
unsigned char Count;

if( Length >8 || Length <=0 )
{
/* Length Error*/
iStatus =LENGTH_ERROR;
}
else
{
/* Write or copy data into relevant slot depending on Data Length */

switch(Slot)
{
case 0:
{
if(Length >0)
{
c0slot0.ba.dlc =Length;
c0mctl0.transmit.remote =0;
for(Count=0; Count <Length; Count++)
{
c0slot0.ba.data[Count] =*ptrData++;
}
}
break;
}

case 1:
{
if(Length >0)
{
{
}
}
break;
}

case 2:
{
if(Length >0)
{
{
}
}
break;
}

case 3:
{
if(Length >0)
{

{
}
}
break;
}

case 4:
{
if(Length >0)
{
{
}
}
break;
}

case 5:
{
if(Length >0) {
for(Count=0; Count <Length; Count++) {
}
}
break;
}

case 6:
{
if(Length >0)
{
{
}
}
break;
}

case 7:
{

if(Length >0)
{
{
}
}
break;
}

case 8:
{
if(Length >0)
{
{
}
}
break;
}

case 9:
{
if(Length >0)
{
{
}
}
break;
}

case 10:
{
if(Length >0)
{
{
}

}
break;
}

case 11:
{
if(Length >0)
{
{
}
}
break;
}
case 12:
{
if(Length >0)
{
{
}
}
break;
}
case 13:
{
if(Length >0)
{
{
}
}
break;
}
case 14:
{
if(Length >0)
{

{
}
}
break;
}
case 15:
{
if(Length >0)
{
{
}
}
break;
}
default:
{
/* Slot Error*/
iStatus =SLOT_ERROR;
}
break;
} /* End of switch*/
} /* End of if*/

return(iStatus);
}
/**********************************************************************
End of function WriteCAN0Message
**********************************************************************/


/**********************************************************************
Function Name: SendCAN0Message
Description: Starts actual message transmission on CAN bus.
Parameters: Slot : Slot / Message box No.(Valid 0 to 15 only)

Return value: Error Status
**********************************************************************/

int SendCAN0Message(unsigned char Slot)
{
unsigned long ulSendDelay =SENDING_DELAY;

/* When starting next transmission, set the SentData and TrmReq bits to "0"
And set TrmReq bit to "1" after checking that the SentData and TrmReq bits
are set to "0". */

switch(Slot)
{
case 0:
{
c0mctl0.transmit.trmreq =0;
c0mctl0.transmit.sentdata =0;
/*Wait for transmission slot to become empty */
while( (c0mctl0.transmit.trmactive ==1) && (--ulSendDelay));
if(ulSendDelay ==0)
{
iStatus =TIMEOUT_ERROR;
}
else
{
}
break;
}
case 1:
{
if(ulSendDelay ==0)
{
}
else
{

}
break;
}
case 2:
{
if(ulSendDelay ==0)
{
}
else
{
}
break;
}
case 3:
{
if(ulSendDelay ==0)
{
}
else
{
}
break;
}
case 4:
{
if(ulSendDelay ==0)
{
}
else
{
}
break;

}
case 5:
{
if(ulSendDelay ==0)
{
}
else
{
}
break;
}
case 6:
{
if(ulSendDelay ==0)
{
}
else
{
}
break;
}
case 7:
{
if(ulSendDelay ==0)
{
}
else
{
}
break;
}
case 8:

{
if(ulSendDelay ==0)
{
}
else
{
}
break;
}
case 9:
{
if(ulSendDelay ==0)
{
}
else
{
}
break;
}
case 10:
{
if(ulSendDelay ==0)
{
}
else
{
}
break;
}
case 11:
{

if(ulSendDelay ==0)
{
}
else
{
}
break;
}
case 12:
{
if(ulSendDelay ==0)
{
}
else
{
}
break;
}
case 13:
{
if(ulSendDelay ==0)
{
}
else
{
}
break;
}
case 14:
{

if(ulSendDelay ==0)
{
}
else
{
}
break;
}
case 15:
{
if(ulSendDelay ==0)
{
}
else
{
}
break;
}
default:
{
break;
}
}

return(iStatus);
}
/**********************************************************************
End of function SendCAN0Message
**********************************************************************/


/**********************************************************************
Function Name: ReadCAN0Message
Description: Strats actual message transmission on CAN bus.
Parameters: Slot: Slot / Message box No.(Valid 0 to 15 only)
pRxDataBuff: Receive data buffer( pre allocated memory)

**********************************************************************/

int ReadCAN0Message(unsigned char Slot, unsigned char* pRxDataBuff)
{
/* Copy received data from message slots to memory */

unsigned char Count;

/* Read or copy data from relevant slot depending on Data Length */
switch(Slot)
{
case 0:
for(Count=0; Count<c0slot0.ba.dlc; Count++)
{
pRxDataBuff[Count] =c0slot0.ba.data[Count];
}
break;

case 1:
{
}
break;

case 2:
{
}
break;

case 3:
{
}
break;

case 4:

{
}
break;

case 5:
{
}
break;

case 6:
{
}
break;

case 7:
{
}
break;

case 8:
{
}
break;

case 9:
{
}
break;

case 10:
{
}
break;

case 11:

{
}
break;

case 12:
{
}
break;

case 13:
{
}
break;

case 14:
{
}
break;

case 15:
{
}
break;

default:
break;
}
return(iStatus);
}
/**********************************************************************
End of function ReadCAN0Message
**********************************************************************/


/**********************************************************************
Function Name: PollCAN0Message
Description: Polls actual message on CAN bus.
Parameters: Slot: Slot / Message box No.(Valid 0 to 15 only)

NO_ERROR: on successful write.
TIMEOUT_ERROR: if time out
**********************************************************************/

int PollCAN0Message(unsigned char Slot)
{
unsigned long ulPollDelay =POLLING_DELAY;

/* Wait till new data receive or time out for relevant slot */
switch(Slot)
{
case 0:
while((c0mctl0.receive.newdata ==0) && (--
ulPollDelay));
if(ulPollDelay ==0) iStatus =TIMEOUT_ERROR;
break;
case 1:
ulPollDelay));
break;
case 2:
ulPollDelay));
break;
case 3:
ulPollDelay));
break;
case 4:
ulPollDelay));
break;
case 5:
ulPollDelay));
break;
case 6:

ulPollDelay));
break;
case 7:
ulPollDelay));
break;
case 8:
ulPollDelay));
break;
case 9:
ulPollDelay));
break;
case 10:
ulPollDelay));
break;
case 11:
ulPollDelay));
break;
case 12:
ulPollDelay));
break;
case 13:
ulPollDelay));
break;
case 14:
ulPollDelay));
break;
case 15:
ulPollDelay));
break;
default:

break;
}

return(iStatus);
}
/**********************************************************************
End of function PollCAN0Message
**********************************************************************/

/**********************************************************************
Function Name: Check_err_can01
Description: Checks CAN error status.
Parameters: None
0 : No error occur
1 : can0 bus error
2 : can0 is in error passive state
4 : can0 is in bus-off state
**********************************************************************/

int Check_err_can01(void)
{
int iStatus =NO_ERROR; /* Store return value */

/* Check CAN0 error state */
if(c0str_addr.b.state_buserror)
{
iStatus |=0x0001;

/* Check error-passive state */
if(c0str_addr.b.state_errpas)
{
iStatus |=0x0002;
}

/* Check bus-off state */
else if(c0str_addr.b.state_busoff)
{
iStatus |=0x0004;
}
}
return(iStatus);
}
/**********************************************************************
End of function Check_err_can01
**********************************************************************/


Captulo 5. Consideraciones Finales 133

CAPITULO 5. CONSIDERACIONES FINALES

5.1 Resultados

Despus del estudio realizado del protocolo CAN, podemos destacar que las
principales ventajas que representa este protocolo es la robustez en la consistencia de
datos, la flexibilidad de la configuracin, el aislamiento de nodos defectuosos, etc. Lo
que nos permite obtener un bus de comunicaciones que supera con creces a otras
implementaciones ms caras.

Conocido a fondo dicho protocolo, se ha logrado implementar la comunicacin de
un bus Maestro/Esclavo, controlado por microcontroladores Renesas. El mencionado
sistema es un prototipo de una red CAN, que permite comunicar los distintos elementos
de la red y aadir nuevos nodos de forma fcil.

El sistema implementado est compuesto por un nodo principal que funcionara
como maestro y 4 nodos esclavos. El nodo maestro recibir constantemente los
mensajes de los nodos esclavos, ocasionalmente el maestro podr realizar una peticin y
los esclavos respondern inmediatamente. Como ya sabemos, el protocolo de
comunicaciones CAN bus funciona mediante prioridad de mensajes (Ver seccin
2.2.2.1), por lo que, debemos asignar al Maestro la prioridad ms alta, as mismo, los
esclavo tendrn diferentes prioridades pero siempre menores que la del propio maestro.

5.2 Lneas futuras de trabaj o.

Tras el estudio, diseo y desarrollo, cabe destacar, que nuestro sistema proporciona
mucho margen de mejoras, adems de posibles ampliaciones e incorporaciones.

El sistema desarrollado es un molde bsico a partir del cual se puede continuar
dndole forma, lo que implica que las futuras lneas de trabajo pueden ser numerosas.
Por este motivo, desde un principio se ha tenido muy presente la posibilidad de no dejar

Captulo 5. Consideraciones Finales 134
totalmente cerrado el proyecto. De hecho, cada uno de los nodos tiene incorporado un
puerto de comunicaciones RS-232 y un circuito de expansin I2C, lo cual, nos
proporcionan un diverso abanico de posibles ampliaciones.

Como lneas futuras de continuacin de este trabajo podemos resaltar:

1. Bus de control industrial. Dado las caractersticas del protocolo puede
implementarse un bus industrial para entornos de alto ruido con diversas
aplicaciones en el campo industrial.

2. Red de sensores cableada. Aprovechando las caractersticas de bus industrial
puede ser implementada una red de sensores que puedan realizar diversos tipos
de sensorizacin que permitan una amplia implementacin de aplicaciones.


Referencias Bibliogrficas 135

REFERENCIAS BIBLIOGRFICAS

a) Manuales de Consulta

i. ISO 11898-1:2003.
Part 1: Data link layer and physical signaling.

ii. ISO 11898-2:2003.
Part 2: High-speed medium access unit.

iii. ISO 11898-3:2006.
Part 3: Low-speed, fault-tolerant, medium-dependent interface.

iv. CAN specification.
Bosch, Versin 2.0, 1991.

v. A Comprehensible Guide to Controller Area Network.
Wilfried Voss, Copperhill Media, 2005.

vi. Embedded Networking with CAN and CANopen.
Olaf Pfeiffer, Andrew Ayre, Christian Keydel. Copperhill Media, 2008.

vii. Nodo de comunicacin basado en el bus can.
Jos Antonio Lpez Fresno. Universidad Rovira i Virgili (Tarragona). 2004

viii. Sistema de diagnstico y sincronizacin de los buses de campo can.
Dr. Hctor Kaschel. Universidad de Santiago de Chile.

ix. Bus Can y J1939.
Manuel Moreno. Escuela Tcnica Superior de Ingeniera Industrial de Barcelona.


x. Estudio del protocolo CAN y su aplicacin en redes de control.
Mario Luis Defaz Andrango, Escuela de Ingeniera de Quito, 2007.

xi. Controller Area Network (CAN).
K. Etschberger, Hanser-Verlag, 2002.

xii. The Configuration of the CAN Bit Timing.
F. Hartwich, A. Bassemir, 6th International CAN Conference, 1999; Turin.

b) Web Si tes

i. http://www.sae.org/

ii. http://www.can-cia.org/

iii. http://www.ixxat.com

iv. http://www.can-expo.ru/

v. http://www.semiconductors.bosch.de

vi. http://www.keil.com/can/

vii. http://www.can-wiki.info/

viii. http://www.canbus.us/

ix. http://www.cs-group.de/CAN-osi-1.62.0.html

x. http://www.microcontrol.net/en/know-how/can.html

xi. http://www.renesasrulz.com


xii. http://www.softing.com

xiii. http://www.renesas.com

xiv. http://es.wikipedia.org/wiki/Bus_CAN

xv. http://www.8052.com/users/Navin/

c) Artculos Relacionados

i. CANopen - The standardized embedded control network.
Autor: Holger Zeltwanger.
Engineering review, Enero 2011 (www.engrreview.com)
http://www.can-cia.org/uploads/media/engrreview_1-2011_01.pdf

ii. CAN, CANopen find new applications, including wind power.
Autor: Renee Robbins.
Control Engineering, Julio 2009 (www.controleng.com)
http://www.can-cia.org/uploads/media/Control_Engineering_July2009.pdf

iii. CAN, LIN, FlexRay - status and prospects of the bus.
Autor: Thomas Kuther.
Elektronikpraxis, Marzo 2008 (http://www.elektronikpraxis.vogel.de)
http://www.elektronikpraxis.vogel.de/themen/hardwareentwicklung/datenkommunikatio
nsics/articles/111425/

iv. Insulation protects digital CAN-bus systems.
Autor: Wayne Scott.
Elektronikpraxis, Octubre 2006 (http://www.elektronikpraxis.vogel.de)
http://www.elektronikpraxis.vogel.de/analogtechnik/articles/48273/


v. The sensible way forward for integrating electronic controls in off highway
vehicles.
IVT International, Mayo 2006 (www.ukintpress.com)
http://www.can-cia.org/uploads/media/ivt-2-06.pdf

vi. CAN: Network for Thousands of Applications Outside Automotive.
Autor: Jack Shandle.
EE Time, Julio 2003 (http://www.eetimes.com)
http://www.eetimes.com/design/automotive-design/4017872/CAN-Network-for-
Thousands-of-Applications-Outside-Automotive

vii. Controller Area Network and CANopen in Medical Equipment.
Business Briefing, 2002 (www.business-briefings.com)
http://www.can-cia.org/uploads/media/medical.pdf

viii. Connecting CANopen and Ethernet POWERLINK.
Autor: Christian Schlegel.
IXXAT Automation (http://www.ixxat.com/)
http://www.ixxat.com/article-powerlink-canopen-gateway_en.html?markierung=can


Anexos 139

ANEXOS

a) Hoja de caractersti cas del transceiver L9616


Anexos 140


Anexos 141


Anexos 142


Anexos 143


Anexos 145
b) Hoja de caractersti cas del mi crocontrolador Renesas
R8C/23


Anexos 146


Anexos 147


Anexos 148


Anexos 149


Anexos 150


Anexos 151


Anexos 152


Anexos 153


Anexos 154


Anexos 155


Anexos 156


Anexos 157
c) Control ador CAN del microcontrol ador R8C/23.


Anexos 158


Anexos 159


Anexos 160


Anexos 161


Anexos 162


Anexos 163


Anexos 164


Anexos 165


Anexos 166


Anexos 167


Anexos 168


Anexos 169


Anexos 170

Escuela Tcnica Superior de Ingeniera

Ingeniera Tcnica Industrial en Electrnica Industrial

josemasancho@gmail.com

Octubre de 2011

Sistema de Comunicacion CANBus Basado en Microcontrolador

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistema de Comunicacion CANBus Basado en Microcontrolador

Cargado por

Copyright:

Formatos disponibles

ESCUELA TCNICA SUPERIOR DE INGENIERA

Departamento de Ingeniera Electrnica,

También podría gustarte