Diseño e implementeación de un sistema educativo del protocolo de comunicaciones CAN

UNIVERSIDAD DE SANTIAGO DE CHILE
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA ELÉCTRICA
DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA EDUCATIVO
DEL PROTOCOLO DE COMUNICACIONES CAN
ERTON ESTEBAN OSSANDÓN TAPIA
PROFESOR GUÍA:
ERNESTO ALEJANDRO PINTO LINCOÑIR
Trabajo de titulación presentado en
conformidad a los requisitos para
obtener el título de ingeniero civil en
electricidad
SANTIAGO – CHILE
2011
© Erton Esteban Ossandón Tapia
Se autoriza la reproducción parcial o total de esta obra, con fines académicos,
por cualquier forma, medio o procedimiento, siempre y cuando se incluya la
cita bibliográfica del documento.
HOJA DE CALIFICACIÓN
i
DEDICATORIA
A mi hermano Rodrigo por todo el esfuerzo que haz hecho para que yo logre
obtener mi título
“El hombre inteligente se repone fácilmente de sus fracasos;
mientras que el tonto jamás logra reponerse de sus éxitos”
Sacha Guitry
ii
AGRADECIMIENTOS
Quisiera comenzar agradeciendo a los profesores de mi comisión
evaluadora por el tiempo invertido en este trabajo de título, en particular a mi
profesor guía Ernesto Pinto y al profesor Manuel Valenzuela que sin su apoyo
no hubiese podido encaminar mi tesis y cumplir con los objetivos requeridos.
Por otra parte, y considerando el trabajo de título como la culminación
de todo mi proceso universitario, no puedo dejar de agradecer a todas las
personas que durante todos estos años han estado conmigo y que de una u
otra forma me han apoyado, en particular a:
Mis compañeros y amigos personales: Carlos (Wilson, gracias por tu
apoyo en muchos momentos de mi vida), Alexander (Klifff, gracias por tu ayuda
desinteresada y por tu papeo!), Ariel (Bacard!, gracias por ser una ayuda en las
noches interminables de estudio), Gonzalo (Tata, gracias por entregarme tu
apoyo), Rodrigo (Chamelo, gracias por haberme ayudado en momentos
difíciles) y a José (Joselote, gracias por los carretes y tus cigarros!).
Mis amigos que de una u otra forma he llegado a conocer: Alejandro
(Jani, gracias por enseñarme a Debuggear!!!), Oscar (Oskiniak, gracias por la
alegría brindada y por ayudar a superarme de forma competitiva), Felipe
(Felipín, gracias por entregar tus certeras opiniones).
A toda mi familia, en especial a mis hermanos: Rodrigo (Cokin, gracias
por ayudarme en un momento difícil en mi vida, ser un gran apoyo y ofrecerme
la tranquilidad necesaria para poder titularme) y Gustavo (Sapatín, gracias por
ser una persona incondicional conmigo); y finalmente a Carolina (Carito, gracias
por aguantarme en tu casa en las mañanas de los días sábado!).
iii
TABLA DE CONTENIDOS
TABLA DE CONTENIDOS
IV
ÍNDICE DE TABLAS
IX
ÍNDICE DE ILUSTRACIONES
XI
RESUMEN
CAPÍTULO 1.- INTRODUCCIÓN
XVI
1
1.1.- OBJETIVO GENERAL
1
1.2.- OBJETIVOS ESPECÍFICOS
1
1.3.- ORIGEN Y NECESIDAD
1
1.4.- DESARROLLO Y ALCANCES
2
CAPÍTULO 2.- CARACTERÍSTICAS DE LAS REDES INDUSTRIALES
4
2.1.- BENEFICIOS DE LAS REDES
4
2.2.- REDES DE CONTROL Y REDES DE DATOS
5
2.3.- CARACTERÍSTICAS DE LAS REDES DE CONTROL
7
2.4.- VENTAJAS DE LOS BUSES DE CAMPO
10
2.5.- COMUNICACIONES EN ENTORNOS INDUSTRIALES
12
2.6.- CLASIFICACIÓN DE LAS REDES INDUSTRIALES
12
2.6.1.- SEGÚN SU TOPOLOGÍA
13
2.6.2.- SEGÚN SU ACCESO AL MEDIO
16
2.6.3.- SEGÚN SU MODELO DE COMUNICACIÓN
18
2.6.4.- SEGÚN SUS PRESTACIONES
19
2.6.5.- SEGÚN EL TIPO DE COMUNICACIÓN
21
iv
CAPÍTULO 3.- ESTADO DEL ARTE DEL PROTOCOLO DE
COMUNICACIONES CAN
22
3.1.- PROTOCOLO DE COMUNICACIONES CAN
22
3.2.- CONCEPTOS BÁSICOS DEL BUS CAN
23
3.3.- CAPA FÍSICA (PHY)
25
3.3.1.- SUBCAPA DE SEÑALIZACIÓN FÍSICA (PLS)
26
3.3.1.1.- Representación de Bits
26
3.3.1.2.- Temporización de Bits
28
3.3.1.3.- Mecanismos de Sincronización de Bits
30
3.3.1.4.- Tipos de Sincronización
31
3.3.1.5.- Impacto de la Velocidad de Transferencia en la Longitud del Bus
33
3.3.1.6.- Tolerancia de Oscilación
35
3.3.2.- SUBCAPA DE UNIÓN AL MEDIO FÍSICO (PMA)
37
3.3.3.- SUBCAPA DE INTERFAZ DEPENDIENTE DEL MEDIO (MDI)
38
3.3.3.1.- Medio Físico
38
3.3.3.2.- Tipos de Conectores CAN
41
3.3.3.3.- Topología de Una Red CAN
44
3.3.4.- ESTÁNDARES DE LA CAPA FÍSICA
45
3.3.4.1.- Estándar ISO 11898-2
46
3.3.4.2.- Estándar ISO 11898-3
49
3.3.4.3.- Estándar SAE J2411
52
3.3.4.4.- Estándar ISO 11992
53
3.3.4.5.- Recomendación CiA DS-102
55
3.3.4.6.- Recomendaciones de Capa Física por los Estándares HLP
57
3.4.- CAPA DE ENLACE DE DATOS (DLL)
60
3.4.1.- CONTROL DE ENLACE LÓGICO (LLC)
61
3.4.2.- CONTROL DE ACCESO AL MEDIO (MAC)
62
3.4.2.1.- Arbitraje del Bus
62
3.4.2.2.- Transmisión de Mensajes
66
3.4.2.3.- Codificación de Tramas
75
3.4.2.4.- Validación de Tramas
75
3.4.2.5.- Detección y Manejo de Errores
75
3.5.- DESCRIPCIÓN DE LA SUPERVISIÓN
79
v
3.6.- CAPA DE APLICACIÓN
81
3.6.1.- CAL
83
3.6.2.- CANOPEN
84
3.6.3.- DEVICENET
86
3.6.4.- SDS
87
3.6.5.- OSEK/VDX
88
3.6.6.- CAN KINGDOM
90
CAPÍTULO 4.- REFERENCIAS PARA LA UTILIZACIÓN DEL KIT DE
DESARROLLO CAN
4.1.- DESCRIPCIÓN DEL HARDWARE
92
92
4.1.1.- MICROCONTROLADOR
94
4.1.2.- CONECTORES DE ENERGÍA
97
4.1.3.- RELOJ DEL SISTEMA
98
4.1.4.- INTERRUPTOR DE ENCENDIDO/APAGADO
98
4.1.5.- BOTÓN DE REINICIO
99
4.1.6.- BOTÓN DE INTERRUPCIÓN
99
4.1.7.- PANTALLA LCD
99
4.1.8.- BARRA DE LED’S
99
4.1.9.- PUERTO RS-232
99
4.1.10.- PUERTO CAN
100
4.2.- DESCRIPCIÓN DEL SOFTWARE
4.2.1.- ENTORNO DE DESARROLLO INTEGRADO
4.2.1.1.- Tipos de Variables
100
100
101
4.2.1.2.- Operaciones y Asignaciones a Nivel de Bits
103
4.2.1.3.- Estructura de un Programa Escrito en C
103
4.2.1.4.- Rutinas de Interrupción
104
4.2.1.5.- Crear un Programa de Referencia
106
4.2.1.6.- Agregar Opciones de Depuración
112
4.2.2.- HERRAMIENTA DE PROGRAMACIÓN DEL SISTEMA
116
4.2.2.1.- Condiciones de Hardware
116
4.2.2.2.- Uso del Programador de Sistema
119
vi
CAPÍTULO 5.- PUESTA EN FUNCIONAMIENTO DEL SISTEMA CAN
126
5.1.- INTRODUCCIÓN A LA PROGRAMACIÓN DE APLICACIONES PARA EL KIT DE
DESARROLLO
126
5.1.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE
127
5.1.2.- CONVENCIONES DE PROGRAMACIÓN
127
5.1.3.- ESTÁNDAR RS-232
129
5.1.4.- LABORATORIO Nº1.1
132
5.1.5.- LABORATORIO Nº1.2
134
5.1.6.- LABORATORIO Nº1.3
136
5.2.- ESTUDIO DE LA CAPA FÍSICA Y DE ENLACE DE DATOS DEL PROTOCOLO CAN
144
5.2.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE
145
5.2.2.- LIBRERÍA DE COMUNICACIÓN CAN
146
5.2.3.- LABORATORIO Nº2.1
153
5.2.4.- LABORATORIO Nº2.2
160
5.3.- ESTUDIO DE APLICACIONES GATILLADAS EN EL TIEMPO
162
5.3.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE
163
5.3.2.- ESTRUCTURA DE APLICACIONES GATILLADAS EN EL TIEMPO
163
5.3.3.- LABORATORIO Nº3.1
166
5.3.4.- LABORATORIO Nº3.2
168
5.3.5.- LABORATORIO Nº3.3
169
5.4.- IMPLEMENTACIÓN DE APLICACIONES QUE HAGAN USO DEL MODELO DE
COMUNICACIÓN CAN
171
5.4.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE
172
5.4.2.- FLEXIBILIDAD DEL MODELO PRODUCTOR/CONSUMIDOR
173
5.4.3.- MONTAJE DEL SISTEMA
174
5.4.4.- LABORATORIO Nº4.1
175
5.4.5.- LABORATORIO Nº4.2
176
CAPÍTULO 6.- CONCLUSIONES
178
vii
GLOSARIO
180
BIBLIOGRAFÍA
184
ANEXOS
188
ANEXO A: GUÍAS DE LABORATORIO
189
EXPERIENCIA Nº1: REFERENCIAS PARA LA UTILIZACIÓN DEL KIT DE DESARROLLO CAN
190
EXPERIENCIA Nº2: INTRODUCCIÓN A LA PROGRAMACIÓN DE APLICACIONES PARA EL KIT DE
DESARROLLO
195
EXPERIENCIA Nº3: ESTUDIO DE LA CAPA FÍSICA Y DE ENLACE DE DATOS DEL PROTOCOLO CAN
202
EXPERIENCIA Nº4: ESTUDIO DE APLICACIONES GATILLADAS EN EL TIEMPO
208
EXPERIENCIA Nº5: IMPLEMENTACIÓN DE APLICACIONES QUE HAGAN USO DEL MODELO DE
COMUNICACIÓN CAN
213
ANEXO B: HOJA DE DATOS Y LISTA DE MATERIALES DEL KIT DE DESARROLLO 218
HOJA DE DATOS DE LA TARJETA: C51 DEMO BOARD
219
LISTA DE MATERIALES DE LA TARJETA: C51 DEMO BOARD
225
HOJA DE DATOS DE LA TARJETA: CAN EXTENSION BOARD
226
LISTA DE MATERIALES DE LA TARJETA: CAN EXTENSION BOARD
227
viii
ÍNDICE DE TABLAS
Tabla 3.1.- Velocidad de transferencia de datos y longitud del bus ............................ 34
Tabla 3.2.- Asignación de terminales en el conector DB9 ........................................... 42
Tabla 3.3.- Asignación de terminales del conector tipo mini ....................................... 42
Tabla 3.4.- Asignación de terminales del conector tipo micro .................................... 43
Tabla 3.5.- Asignación de terminales del conector tipo nano...................................... 43
Tabla 3.6.- Asignación de terminales del conector tipo abierto .................................. 44
Tabla 3.7.- Niveles nominales de voltaje en el bus CAN de acuerdo al estándar
ISO 11898-2 ................................................................................................................ 47
Tabla 3.8.- Niveles de voltaje en el bus CAN de acuerdo al estándar ISO 11898-3 .... 50
Tabla 3.9.- Niveles de las señales CAN en el bus recomendados por el estándar
ISO 11992.................................................................................................................... 54
Tabla 3.10.- Velocidades de transferencia y parámetros de tiempos de bit
recomendados en DS-102 ........................................................................................... 55
Tabla 3.11.- Parámetros de tiempos de bit recomendados por DS-102 ..................... 56
Tabla 3.12.- Línea de bus interconectada de acuerdo a la recomendación DS-102 ... 57
Tabla 3.13.- Extensión de red y longitud de línea de extensión para DeviceNet ......... 59
Tabla 3.14.- Velocidades de transferencia y longitudes de línea recomendadas para
SDS ............................................................................................................................. 60
Tabla 3.15.- Representación bit a bit del arbitraje en el bus CAN ............................... 64
Tabla 3.16.- Codificación de los bits DLC según la longitud de los datos .................. 70
Tabla 3.17.- Ventajas y características de CANopen .................................................. 85
Tabla 4.1.- Características del kit de desarrollo para los microcontroladores Atmel
T89C51CC0x ............................................................................................................... 94
ix
Tabla 4.2.- Tipos de variables soportados por el compilador C51 ............................ 102
Tabla 4.3.- Tipos de SFR que maneja el compilador C51 ......................................... 103
Tabla 4.4.- Operaciones a nivel de bits que permite el lenguaje C ............................ 103
Tabla 4.5.- Asignaciones a nivel de bits que permite el lenguaje C ........................... 103
Tabla 4.6.- Detalle de los tipos de interrupciones del microcontrolador Atmel
T89C51CC01 ............................................................................................................. 105
Tabla 5.1.- Requerimientos de software y de hardware para el laboratorio nº1 ........ 127
Tabla 5.2.- Definición de tipos entregados en el archivo ‘compiler.h’ ....................... 129
Tabla 5.3.- Definición de constantes asociados a interrupciones entregados en el
archivo ‘compiler.h’ ................................................................................................... 129
Tabla 5.4.- Valores de recarga del registro TH0/TH1 para obtener distintas
velocidades de transmisión ....................................................................................... 138
Tabla 5.5.- Valores de recarga de los registros RCAP2H y RCAP2L para obtener
distintas velocidades de transmisión ......................................................................... 139
Tabla 5.6.- Velocidades de transmisión requeridas para la configuración del puerto
RS-232 ...................................................................................................................... 142
Tabla 5.7.- Requerimientos de software y de hardware para el laboratorio nº2 ........ 146
Tabla 5.8.- Velocidades de transmisión requeridas para la configuración del bus CAN
.................................................................................................................................. 158
Tabla 5.9.- Configuraciones requeridas para el nodo transmisor .............................. 159
Tabla 5.10.- Configuraciones requeridas para el nodo receptor ............................... 159
Tabla 5.11.- Requerimientos de software y de hardware para el laboratorio nº3 ...... 163
Tabla 5.12.- Requerimientos de software y de hardware para el laboratorio nº4 ...... 173
x
ÍNDICE DE ILUSTRACIONES
Figura 2.1.- Comparación de la red Ethernet ante variaciones del tamaño de los
paquetes ....................................................................................................................... 6
Figura 2.2.- Topologías de red .................................................................................... 16
Figura 2.3.- Clasificación de protocolos según su acceso al medio ........................... 17
Figura 2.4.- Clasificación de los diversos buses de campo según sus prestaciones .. 21
Figura 3.1.- Arquitectura de capas del protocolo CAN ............................................... 23
Figura 3.2.- Arquitectura de la capa física del protocolo CAN .................................... 26
Figura 3.3.- Comparación de la representación de bits del código NRZ y el código
Manchester.................................................................................................................. 27
Figura 3.4.- Ejemplo del procedimiento de inserción de bit ........................................ 27
Figura 3.5.- Principio de derivación del periodo de bit................................................ 28
Figura 3.6.- Segmentos del tiempo de bit ................................................................... 29
Figura 3.7.- Ejemplo de definición de un tiempo de bit ............................................... 30
Figura 3.8.- Relación entre velocidad de transferencia y longitud del bus .................. 35
Figura 3.9.- Arquitectura de un nodo CAN con transceptor ........................................ 37
Figura 3.10.- Medio de transmisión eléctrico .............................................................. 39
Figura 3.11.- Conector tipo DB9 ................................................................................. 42
Figura 3.12.- Conector tipo mini ................................................................................. 42
Figura 3.13.- Conector tipo micro ............................................................................... 43
Figura 3.14.- Conector tipo nano ................................................................................ 44
Figura 3.15.- Conector tipo abierto ............................................................................. 44
Figura 3.16.- Niveles nominales de señal en el bus CAN recomendados por el
estándar ISO 11898-2 ................................................................................................. 47
xi
Figura 3.17.- Niveles nominales de las señales presentes en un transceptor CAN ..... 49
Figura 3.18.- Niveles de señal en el bus CAN recomendados por el estándar
ISO 11898-3 ................................................................................................................ 50
Figura 3.19.- Interfaz para bus CAN utilizando un transceptor TJA 1054 de la firma
Philips .......................................................................................................................... 51
Figura 3.20.- Niveles nominales de la señal CAN en el bus de acuerdo al estándar
SAE J2411 ................................................................................................................... 53
Figura 3.21.- Niveles nominales de las señales CAN en el bus de acuerdo con el
estándar ISO 11992 ..................................................................................................... 54
Figura 3.22.- Arquitectura de la capa de enlace de datos del protocolo CAN ............ 60
Figura 3.23.- Arbitraje del bus CAN ............................................................................ 65
Figura 3.24.- Formato de una trama de datos ............................................................ 67
Figura 3.25.- Campo de arbitraje, trama estándar y extendida ................................... 67
Figura 3.26.- Campo de control .................................................................................. 69
Figura 3.27.- Campo CRC .......................................................................................... 70
Figura 3.28.- Campo de aceptación ........................................................................... 71
Figura 3.29.- Formato de una trama remota ............................................................... 72
Figura 3.30.- Formato de una trama de error .............................................................. 72
Figura 3.31.- Formato de una trama de sobrecarga ................................................... 74
Figura 3.32.- Diagrama de flujo para el manejo de errores ......................................... 77
Figura 3.33.- Diagrama de estados de error de un nodo CAN .................................... 81
Figura 3.34.- Arquitectura general de un sistema basado en CAL .............................. 84
Figura 3.35.- Arquitectura general de un sistema basado en CANopen ..................... 86
Figura 3.36.- Arquitectura de protocolos DeviceNet ................................................... 87
xii
Figura 3.37.- Arquitectura de protocolos SDS ............................................................ 88
Figura 3.38.- Arquitectura OSEK/VDX......................................................................... 90
Figura 3.39.- Representación de una red CAN con CAN Kingdom ............................. 91
Figura 4.1.- Tarjeta de demostración C51 conectada a la tarjeta de extensión CAN .. 92
Figura 4.2.- Diagrama de bloques del microcontrolador Atmel T89C51CC01 ............ 95
Figura 4.3.- Distribución de pines del microcontrolador Atmel T89C51CC01 en
formato PLCC44 .......................................................................................................... 95
Figura 4.4.- Esquema de la tarjeta de demostración C51 ........................................... 97
Figura 4.5.- Tarjeta de demostración C51 energizado en los conectores J1 y J2 ....... 98
Figura 4.6.- Estructura general de un programa escrito en C para sistemas
empotrados ............................................................................................................... 104
Figura 4.7.- Estructura general del código escrito en C de una rutina de interrupción
.................................................................................................................................. 105
Figura 4.8.- Interfaz gráfica de inicio del IDE Keil μVision3 ....................................... 106
Figura 4.9.- Ventana de selección de dispositivo...................................................... 107
Figura 4.10.- Menú desplegable ‘Options for Target’................................................ 108
Figura 4.11.- Pestaña ‘Target’ de la ventana ‘Options for Target’ ............................. 109
Figura 4.12.- Pestaña ‘Output’ de la ventana ‘Options for Target’ ............................ 110
Figura 4.13.- Menú desplegable ‘Add Files to Group’............................................... 111
Figura 4.14.- Menú desplegable ‘Build target’ .......................................................... 112
Figura 4.15.- Pestaña ‘Debug’ de la ventana ‘Options for Target’ ............................ 113
Figura 4.16.- Menú desplegable ‘New Group’ .......................................................... 114
Figura 4.17.- Menú desplegable ‘Add Files to Group’............................................... 115
Figura 4.18.- Estructura del proyecto ‘my_project’ ................................................... 116
xiii
Figura 4.19.- Conexión entre el PC y el kit de desarrollo CAN mediante RS-232 ..... 117
Figura 4.20.- Condición de hardware configurado para arrancar en modo ‘Gestor de
Arranque’ ................................................................................................................... 118
Figura 4.21.- Condición de hardware configurado para arrancar en modo ‘Aplicación
de Usuario’ ................................................................................................................ 119
Figura 4.22.- Interfaz gráfica de inicio del programador FLIP ................................... 120
Figura 4.23.- Ventana del programador FLIP con el dispositivo T89C51CC01
seleccionado ............................................................................................................. 121
Figura 4.24.- Configuración del puerto RS-232 ........................................................ 122
Figura 4.25.- Conexión exitosa del kit de desarrollo ................................................. 123
Figura 4.26.- Archivo hexadecimal debidamente cargado ........................................ 124
Figura 4.27.- Programación exitosa del microcontrolador ........................................ 125
Figura 5.1.- Ejemplo de utilización del archivo ‘config.h’ incluido en las rutinas ....... 128
Figura 5.2.- Ejemplo de utilización de la librería de la pantalla LCD .......................... 133
Figura 5.3.- Estructura del proyecto ‘display’ ........................................................... 133
Figura 5.4.- Ejemplo de utilización de la librería de la barra de LED’s....................... 135
Figura 5.5.- Estructura del proyecto ‘bargraph’ ........................................................ 136
Figura 5.6.- Ejemplo de utilización de la librería ‘stdio.h’ .......................................... 140
Figura 5.7.- Estructura del proyecto ‘rs232’.............................................................. 141
Figura 5.8.- Conexión entre el PC y el kit de desarrollo CAN para visualizar mensajes
mediante RS-232....................................................................................................... 143
Figura 5.9.- Configuración del puerto RS-232 .......................................................... 144
Figura 5.10.- Ejemplo de utilización del archivo ‘config.h’ para la definición de rutinas
.................................................................................................................................. 151
Figura 5.11.- Código de las rutinas de interrupción de la librería CAN...................... 152
xiv
Figura 5.12.- Ejemplo de utilización de la librería CAN para la transmisión de mensajes
.................................................................................................................................. 154
Figura 5.13.- Ejemplo de utilización de la librería CAN para la recepción de mensajes
.................................................................................................................................. 155
Figura 5.14.- Estructura de los proyectos ‘can_tx’ y ‘can_rx’ ................................... 157
Figura 5.15.- Utilidad para calcular la velocidad de bit para el bus CAN en el kit de
desarrollo................................................................................................................... 158
Figura 5.16.- Conexión entre el PC y el kit de desarrollo CAN para visualizar los
mensajes de los nodos trasmisor y receptor mediante RS-232 ................................. 160
Figura 5.17.- Serie de datos mostrados en el panel LCD.......................................... 161
Figura 5.18.- Estructura general del programa principal escrito en C para aplicaciones
gatilladas en el tiempo ............................................................................................... 164
Figura 5.19.- Estructura general del itinerario de tareas escrito en C para aplicaciones
gatilladas en el tiempo ............................................................................................... 166
Figura 5.20.- Estructura de los proyectos ‘bargraph’, ‘display’ y ‘rs232’ .................. 167
Figura 5.21.- Estructura de los proyectos ‘can_tx’ y ‘can_rx’ ................................... 169
Figura 5.22.- Conexión entre el PC y el kit de desarrollo CAN para visualizar los
mensajes de los nodos trasmisores/receptores mediante RS-232 ............................ 171
Figura 5.23.- Resumen de la flexibilidad del modelo productor/consumidor ............ 174
Figura 5.24.- Formato de mensajes en los modelos: a) cliente/servidor y b)
productor/consumidor ............................................................................................... 174
Figura 5.25.- Montaje para los laboratorios Nodo1/Nodo2 y Maestro/Esclavo ......... 175
xv
TÍTULO: Diseño e implementación de un sistema educativo del protocolo de
comunicaciones CAN.
CLASIFICACIÓN TEMÁTICA: Protocolos: redes industriales;
Comunicaciones aplicadas al control; Control automático;
Microcontroladores; Software; Hardware.
AUTOR: Ossandón Tapia, Erton Esteban
CARRERA: Ingeniería Civil en Electricidad
PROFESOR GUÍA: Pinto Lincoñir, Ernesto Alejandro
AÑO: 2011
CÓDIGO DE UBICACIÓN BIBLIOTECA:
2011 / E / 040
RESUMEN
El presente trabajo propone potenciar a los estudiantes en el
conocimiento de los buses CAN (Controller Area Network) a través del
desarrollo de una serie de experiencias de laboratorio empleando un kit de
desarrollo.
En un comienzo, y para interiorizarse en los distintos protocolos de
comunicaciones de control, se hace un análisis de las características y
clasificación de los buses de campo. Luego, se hace un estudio minucioso
del protocolo CAN abarcando los aspectos más relevantes: la capa física, la
capa de enlace de datos y los estándares de la capa de aplicación. A
continuación, se hace un estudio de los componentes de hardware y de
software necesarios para la puesta en funcionamiento del kit de desarrollo.
Finalmente, se crean las experiencias de laboratorio que ayudarán al alumno
a entender en profundidad el bus CAN.
xvi
CAPÍTULO 1.- INTRODUCCIÓN
1.1.- OBJETIVO GENERAL
El objetivo general de este proyecto es diseñar e implementar un sistema
educativo del protocolo de comunicaciones CAN (Controller Area Network)
para ser una herramienta de apoyo didáctico en la enseñanza de este
protocolo.
1.2.- OBJETIVOS ESPECÍFICOS
Para cumplir el objetivo general, a continuación se detallan objetivos
más específicos, que se derivan del general y lo complementan:
1.- Realizar un análisis del estado del arte de la evolución de protocolos y
normativas de transporte en redes industriales para comprender el
protocolo de comunicaciones CAN.
2.- Definir los requisitos para implementar una red de tales características,
así como también describir los módulos necesarios que conforman las
comunicaciones en redes industriales a través del protocolo de
comunicaciones CAN.
3.- Diseñar una serie de laboratorios utilizando un kit de desarrollo para
enseñar el protocolo CAN considerando aspectos académicos.
4.- Comprobar la validez de los laboratorios implementados. Realizar
pruebas en cuánto a funcionamiento y calidad.
1.3.- ORIGEN Y NECESIDAD
Debido a que los alumnos de la carrera de telecomunicaciones no tienen
una clara visión del concepto de buses de campo, se origina la necesidad de
potenciar a los estudiantes en el conocimiento de dicho concepto; en particular
1
del bus de campo CAN, donde no sólo en la industria de control automotriz se
está utilizando este protocolo, sino que también se está expandiendo a la
automatización de edificios, aeronáutica, control industrial, equipamiento
médico, entre otros.
1.4.- DESARROLLO Y ALCANCES
A continuación se realiza una breve descripción de los temas abordados
en este trabajo de título, además del desarrollo de los contenidos y alcances de
éstos.
En el capítulo 2, Características de las Redes Industriales, se hace un
análisis de los buses de campo, mostrando aspectos de: beneficios,
comparativas, características, ventajas, estandarización y clasificaciones que
se pueden realizar en torno a ellos.
En el capítulo 3, Estado del Arte del Protocolo de Comunicaciones CAN,
se realiza un estudio de requisitos para implementar un sistema de transmisión
en redes industriales a través del protocolo de comunicaciones CAN, tanto en
el aspecto de módulos requeridos como la disponibilidad de equipos que
reúnan tales características.
En el capítulo 4, Referencias para la Utilización del Kit del Desarrollo
CAN, describe los componentes de software y de hardware necesarios para la
utilización del kit de desarrollo, detallándose los procedimientos de
programación y creación de aplicaciones para el sistema.
En el capítulo 5, Puesta en Funcionamiento del Sistema CAN, se diseña
una serie de experiencias de laboratorio para ayudar al alumno a entender en
profundidad el bus CAN, se propone una metodología para crear aplicaciones
2
utilizando un kit de desarrollo, y paralelamente, se enseñan los aspectos más
relevantes del protocolo CAN.
Finalmente, en el capítulo 6, Conclusiones, se comentan los resultados
obtenidos y se establecen las conclusiones derivadas de la realización de este
trabajo de título.
3
CAPÍTULO 2.- CARACTERÍSTICAS DE LAS REDES
INDUSTRIALES
El propósito de este capítulo es hacer un análisis de los buses de
campo, mostrando aspectos de: beneficios, comparativas, características,
ventajas, estandarización y clasificaciones que se pueden realizar en torno a
ellos.
2.1.- BENEFICIOS DE LAS REDES
El concepto básico de un sistema de red es que todos los dispositivos
están conectados y se comunican entre ellos usando un único sistema
estándar. El grado en el que esto afecto a cada dispositivo depende de la
simplicidad del sistema en términos de su implementación y su uso. El permitir
a los dispositivos sencillos comunicarse por medio de una red puede causar un
incremento significativo en la complejidad y sofisticación del dispositivo, lo que
significa un costo extra, mientras que el beneficio extra para el propio
dispositivo puede ser mínimo. Sin embargo, la capacidad de integración con
otros expandirá la funcionalidad del sistema convirtiéndolo un todo; ésta es la
mayor ventaja de usar un sistema de red.
Las áreas principales en las redes traen beneficios son:
•
Estandarizado del cableado mínimo entre dispositivos y reducir los
costos de implementación.
•
Capacidad de los sistemas de control de expandirse sobre grandes
áreas geográficas.
•
Capacidad de añadir más dispositivos al sistema sin necesidad de
rediseñarlo.
•
Un estándar de comunicaciones básico único, para que los ingenieros
4
puedan aprenderlo y mantenerlo.
•
Independencia del vendedor, si el estándar está ampliamente aceptado
en la industria, por ejemplo, protocolos abiertos.
Otro beneficio asociado a las redes es que permiten transmitir datos a
través de un sistema estándar de cableado que es compartido por múltiples
dispositivos, por lo que cualquier sistema estándar de cableado, como un
cable de par trenzado entre dispositivos, tendrá el beneficio inmediato del
recorte de costos con respecto a la cantidad requerida, instalación e
implementación. Además se suma otro beneficio, que es la reducción de
costos de mantenimiento y predicción de fallos.
Los sistemas de redes pueden, en general, expandirse fácilmente.
Además, cuando se utilizan dispositivos estándar, la tarea de expansión
conllevará únicamente unos pocos conectores y unos pocos metros de cables
de red.
2.2.- REDES DE CONTROL Y REDES DE DATOS
Debido a que existen diferentes niveles de comunicación orientados a
diferentes necesidades, se puede hablar de dos tipos de redes: redes de
control y redes de datos. En general, las redes de datos están orientadas al
transporte de grandes paquetes de datos, que aparecen de forma esporádica
(baja carga) y con un gran ancho de banda para permitir el envío rápido de una
gran cantidad de datos. En contraste, las redes de control se enfrentan a un
tráfico formado por un gran número de pequeños paquetes, intercambiados
con frecuencia (alta carga) entre un alto número de estaciones que forman la
red y que muchas veces trabajan en tiempo real.
5
En principio, las redes de datos podrían emplearse para su uso como
redes de control, sin embargo, es evidente que no resultan adecuadas para las
necesidades de este tipo de aplicaciones. Por ejemplo, es sabido que la red
Ethernet tiene una gran eficiencia, hasta el 90-95% de la capacidad del canal
cuando los mensajes son largos y suficientemente espaciados. Sin embargo, la
cantidad de información que una red Ethernet es capaz de transportar cae
bruscamente cuando se utiliza por encima del 35% de la capacidad del canal,
si el tamaño de los mensajes es pequeño, como puede verse en la Figura 2.1.
En las redes de control es habitual encontrar este tipo de carga, porque el
tráfico de la red depende directamente de eventos externos que están siendo
controlados (o monitorizados) por los diferentes nodos que la componen. A
menudo, varios nodos necesitan enviar información simultáneamente en
función de uno o más eventos externos. Este hecho, junto con el gran número
de nodos que suelen estar presentes, implica la existencia de frecuentes
periodos en los que muchas estaciones envían pequeños paquetes de
información.
Figura 2.1.- Comparación de la red Ethernet ante variaciones del tamaño de los paquetes
6
2.3.- CARACTERÍSTICAS DE LAS REDES DE CONTROL
Por las razones expuestas anteriormente, es necesario diseñar una
arquitectura de red adaptada a las características particulares de este tipo de
tráfico. En el diseño se deberán tener en cuenta aspectos como los tipos de
protocolos utilizados, la interoperabilidad, la topología y la facilidad de
administración.
Por lo que se refiere al tipo de topología que deben adoptar las redes de
control, cabe destacar que cualquiera de las topologías clásicas de las redes
de datos es válida. Cada una de ellas con sus propias ventajas y limitaciones.
Cualquiera puede satisfacer las necesidades de cableado, prestaciones y costo
de algún tipo de aplicación. La elección está determinada fundamentalmente
por el control de acceso al medio y el tipo de medio que se emplea. El conjunto
formado por el medio, el control de acceso y la topología, afecta prácticamente
a cualquier otro aspecto de la red de control: costo, facilidad de instalación,
fiabilidad, prestaciones, facilidad de mantenimiento y expansión.
El control de acceso al medio es vital. Elegida una topología, hay que
definir como accederá cada nodo a la red. El objetivo es reducir las colisiones
(idealmente eliminarlas) entre los paquetes de datos y reducir el tiempo que
tarda un nodo en ganar el acceso al medio y comenzar a transmitir el paquete.
En otras palabras, maximizar la eficiencia de la red y reducir el retardo de
acceso al medio. Este último parámetro es el factor principal a la hora de
determinar si una red sirve para aplicaciones en tiempo real o no.
El direccionamiento de los nodos es otro de los aspectos claves. En una
red de control, la información puede ser originada y/o recibida por cualquier
nodo. La forma en que se direccionen los paquetes de información afectará de
7
forma importante a la eficiencia y la fiabilidad global de la red. Se pueden
distinguir tres tipos de direccionamiento:
•
Unicast: El paquete es enviado a un único nodo de destino.
•
Multicast: El paquete es enviado a un grupo de nodos simultáneamente.
•
Broadcast: El paquete es enviado a todos los nodos de la red
simultáneamente.
El direccionamiento broadcast presenta la ventaja de su sencillez y es
adecuado para redes basadas en información de estado, su funcionamiento se
basa en que cada nodo informa a todos los demás cuál es estado actual, pero
el principal inconveniente es que los nodos pueden tener que procesar
paquetes que no les afecten directamente. Los esquemas de direccionamiento
unicast y multicast son más eficientes, y facilitan operaciones como el acuse
de recibo y el reenvío, características que aumentan la fiabilidad del sistema.
En redes de control, es muy habitual encontrar esquemas de direccionamiento
del tipo maestro/esclavo, este tipo de esquemas permite plasmar ciertos
aspectos jerárquicos del control de forma sencilla, a la vez que simplifica el
funcionamiento de la red y por tanto abarata los costos de la interfaz física.
La elección del medio físico afecta a aspectos tales como la velocidad
de transmisión, distancia entre nodos y fiabilidad. En muchas redes de control
se recurre a una mezcla de distintos medios físicos para cumplir con los
requisitos de diferentes secciones al menor costo posible. Se incorporarán los
enrutadores, puentes o repetidores necesarios para asegurar el objetivo de una
comunicación extremo a extremo transparente al menor costo posible y sin
que la integración conlleve una disminución de las prestaciones.
El control en tiempo real es también otro aspecto importante a
considerar ya que demanda de las redes de control buenos tiempos de
8
respuesta. Por ejemplo, el retardo entre la detección de un objeto en una línea
de montaje de alta velocidad y el arranque de una máquina de pintado puede
ser del orden de decenas de milisegundos. En general, las redes de datos no
necesitan una respuesta en tiempo real cuando envían grandes conjuntos de
datos a través de la red. El control de acceso al medio y el número de capas
implementadas en la arquitectura de red resultan determinantes a la hora de
fijar la velocidad de respuesta de la red. La implementación de las siete capas
del modelo OSI (Open Systems Interconnection) implica una mayor potencia de
proceso por la sobrecarga que conlleva con respecto a un sistema más sencillo
que por ejemplo sólo implementase las dos primeras capas.
Otra forma de favorecer un tiempo de respuesta pequeño es la
capacidad para establecer mensajes con diferentes prioridades, de forma que
mensajes de alta prioridad (como por ejemplo una alarma) tengan más facilidad
para acceder al medio. Por último, hay que destacar el papel que juega la
seguridad de la red. Se puede destacar dos niveles diferentes de seguridad.
Por una parte la protección frente a accesos no autorizados a la red, y por otra
parte la protección frente a fallos del sistema y averías.
El primer problema es el menos grave, ya que la mayor parte de las
redes de control no están conectadas a redes externas a la fábrica. Además en
la práctica, la mayor parte de las veces, las redes pertenecientes a los
dispositivos de sensores y actuadores no están conectadas ni siquiera con las
redes de nivel superior dentro de la propia fábrica. En cualquier caso, los
mecanismos de protección son similares a los empleados en las redes de
datos: claves de usuario y autentificación de los nodos de la red.
La protección frente a fallos juega un papel mucho más importante,
debido a que se debe evitar, que este hecho afecte negativamente a la planta.
9
Por ejemplo, los sistemas de refrigeración de una central nuclear no pueden
bloquearse porque la interfaz de comunicaciones de un nodo de la red se
averíe. Para ello es fundamental que los nodos puedan detectar si la red está
funcionando correctamente o no, y en caso de avería puedan pasar a un
algoritmo de control que mantenga la planta en un punto seguro. Si el sistema
es crítico, se deben incluir equipos redundantes, que reemplacen al averiado
de forma automática en caso de avería. La monitorización de la red y la
capacidad de diagnóstico representan por tanto dos puntos básicos de
cualquier red de control.
La
necesidad
de
buenas
herramientas
de
mantenimiento
y
administración de la red son vitales. No sólo por lo dicho anteriormente sino
que también porque en las redes de control las operaciones de reconfiguración
y actualización de la red son frecuentes.
2.4.- VENTAJAS DE LOS BUSES DE CAMPO
La principal ventaja que ofrecen los buses de campo, y la que los hace
más atractivos a los usuarios finales, es la reducción de costos. El ahorro
proviene fundamentalmente de tres fuentes: ahorro en costo de instalación,
ahorro en el costo de mantenimiento y ahorros derivados de la mejora del
funcionamiento del sistema.
Una de las principales características de los buses de campo es una
significativa reducción en el cableado necesario para el control de una
instalación. Cada célula de proceso solo requiere un cable para la conexión de
los diversos nodos. Se estima que puede ofrecer una reducción de 5 a 1 en los
costos de cableado. En comparación con otros tipos de redes, dispone de
herramientas de administración del bus que permiten la reducción del número
de horas necesarias para la instalación y puesta en marcha.
10
El hecho de que los buses de campo sean más sencillos que otras redes
de uso industrial como por ejemplo MAP 1 hace que las necesidades de
mantenimiento de la red sean menores, de modo que la fiabilidad del sistema a
largo plazo aumenta. Además, los buses de campo permiten a los operadores
monitorizar todos los dispositivos que integran el sistema e interpretar
fácilmente las interacciones entre ellos. De esta forma, la detección de las
fuentes de problemas en la planta y su corrección resulta mucho más sencilla,
reduciendo los costos de mantenimiento y el tiempo de parada de la planta.
Los buses de campo ofrecen mayor flexibilidad al usuario en el diseño
del sistema. Algunos algoritmos y procedimientos de control que con sistemas
de comunicación tradicionales debían incluirse en los propios algoritmos de
control, radican ahora en los propios dispositivos de campo, simplificando el
sistema de control y sus posibles ampliaciones.
También hay que tener en cuenta que las prestaciones del sistema
mejoran con el uso de la tecnología de los buses de campo debido a la
simplificación en la forma de obtener información de la planta desde los
distintos sensores. Las mediciones de los distintos elementos de la red están
disponibles para todos los demás dispositivos. La simplificación en la
obtención de datos permitirá el diseño de sistemas de control más eficientes.
Con la tecnología de los buses de campo, se permite la comunicación
bidireccional entre los dispositivos de campo y los sistemas de control, pero
también entre los propios dispositivos de campo.
Otra ventaja de los buses de campo es que solo incluyen 4 capas
(Física, Enlace, Aplicación y Usuario), y un conjunto de servicios de
Una arquitectura de comunicaciones independiente del fabricante que permita interconectar
todos los elementos de la fábrica
1
11
administración. El usuario no tiene que preocuparse de las capas de enlace o
de aplicación, sólo necesita saber cuál es funcionalidad. Al usuario solo se le
exige tener un conocimiento mínimo de los servicios de administración de la
red, ya que parte de la información generada por dichos servicios puede ser
necesaria para la reparación de averías en el sistema. De hecho,
prácticamente, el usuario solo debe preocuparse de la capa física y la capa de
usuario.
2.5.- COMUNICACIONES EN ENTORNOS INDUSTRIALES
La estandarización de protocolos en la industria es un tema en
permanente discusión, donde intervienen problemas técnicos y comerciales.
Cada protocolo esta optimizado para diferentes niveles de automatización y en
consecuencia responden al interés de diferentes proveedores. Por ejemplo
Fieldbus
Foundation,
PROFIBUS
y
HART,
están
diseñados
para
instrumentación de control de procesos. En cambio DeviceNet y SDS están
optimizados para los mercados de los dispositivos discretos (on-off) de
detectores, actuadores e interruptores, donde el tiempo de respuesta y
repetibilidad son factores críticos.
Cada protocolo tiene un rango de aplicación, fuera del mismo disminuye
el rendimiento y aumenta la relación costo/prestación. En muchos casos no se
trata de protocolos que compitan entre sí, sino que se complementan, cuando
se trata de una arquitectura de un sistema de comunicación de varios niveles.
2.6.- CLASIFICACIÓN DE LAS REDES INDUSTRIALES
Existen muchas maneras de clasificar las redes: en función de su
funcionalidad, de los protocolos utilizados, de sus prestaciones, del tipo de
acceso, de su topología, etc. En nuestro caso se verán las siguientes:
12
•
Según su topología.
•
Según su acceso al medio.
•
Según su modelo de comunicación.
•
Según sus prestaciones.
•
Según el tipo de comunicación.
2.6.1.- SEGÚN SU TOPOLOGÍA
Se llaman topologías de red a las diferentes estructuras de
intercomunicación en que se pueden organizar las redes de transmisión de
datos entre dispositivos. Cuando componentes de automatización autónomos
tales como sensores, actuadores, autómatas programables, robots, etc.,
intercambian información, éstos deben interconectarse físicamente con una
estructura determinada. Cada topología de red lleva asociada una topología
física y una topología lógica. La primera (topología física), es la que define la
estructura física de la red, es decir, la manera en la que debe ser dispuesto el
cable de interconexión entre los elementos de la red (Figura 2.2). La topología
lógica es un conjunto de reglas normalmente asociado a una topología física,
que define el modo en el que se gestiona la transmisión de los datos en la red.
La utilización de una topología influye en el flujo de información (velocidad de
transmisión, tiempos de llegada, etc.), en el control de la red, y en la forma en
la que ésta se puede expandir y actualizar.
•
Topología en Malla: Este tipo de interconexión proporciona múltiples
enlaces físicos entre los nodos de la red, de tal modo que no existen
varios canales de comunicación compartidos y múltiples caminos de
interconexión entre dos nodos. La interconexión es total cuando todos
los nodos están conectados de forma directa entre ellos, existiendo
siempre un enlace punto a punto para su intercomunicación. La
13
interconexión es parcial cuando no todos los nodos pueden conectarse
mediante un enlace punto a punto con cualquier otro nodo de la red.
•
Topología en Estrella: Cada nodo se conecta a un nodo central
encargado del control de acceso a la red por el resto de nodos
(colisiones, errores, etc.). En esta topología adquiere una importancia
decisiva el nodo central que se encarga de controlar toda la
comunicación, pues cualquier perturbación en el mismo conduce,
generalmente, al fallo de la red completa. Su implementación puede ser
una decisión factible en el caso de que los nodos de la red no se
encuentren muy distanciados del nodo central debido al costo que
supone cablear cada nodo hasta el nodo central.
•
Topología en Bus: Todos los nodos se conectan a un único medio de
transmisión utilizando transceptores, encargados de controlar el acceso
al bus. Los mensajes se envían por el bus y todos los nodos escuchan,
aceptando los datos sólo en el caso de que vayan dirigidos a él
(reconocimiento de su propia dirección). Esta topología permite la
adición y sustracción de nodos sin interferir en el resto, aunque un fallo
en el medio de transmisión inutiliza por completo la red (rotura del cable,
por ejemplo). Suelen ser necesarios terminadores de red para poder
adaptar impedancias y evitar reflexiones de las ondas transmitidas y
recibidas. Los nodos se deben conectar a la línea de bus principal
mediante segmentos cortos pues ello influye directamente en la
velocidad de transmisión y recepción de datos para ese nodo. Esta es
una de las topologías más utilizadas habitualmente. Puede cubrir largas
distancias empleando amplificadores y repetidores. Poseen un costo
reducido, siendo las más sencillas de instalar. La respuesta es excelente
con poco tráfico, siendo empleadas en redes pequeñas.
•
Topología en Árbol: Esta topología puede interpretarse como el
14
encadenamiento de diferentes estructuras en bus de diferente longitud y
de características diferenciadas, constituyendo diferentes ramas de
interconexión. En este caso adquieren gran importancia los elementos
que permiten duplicar y enlazar las diferentes líneas, ya que actúan
como nodos principales de manera análoga a como lo hace el nodo
principal de la interconexión en estrella. Dado que existen varias
estructuras de bus, cada una debe incorporar sus terminadores y
elementos asociados, así como los elementos de enlace.
•
Topología en Anillo: Los nodos se conectan en serie alrededor del anillo.
Sería equivalente a unir los extremos de una red en bus. Los mensajes
se transmiten en una dirección (actualmente ya existen topologías en red
con envío en ambos sentidos), pasando por todos los nodos necesarios
hasta llegar a su destino. No existe un nodo principal y el control de la
red queda distribuido entre todos los nodos. Cuando la red es ampliada
o reducida, el funcionamiento queda interrumpido, y un fallo en la línea
provoca la caída de la red. Posee una relación costo/modularidad
buena, en general, la instalación es complicada, aunque es fácil variar el
número de estaciones. No influyen los fallos en las estaciones si no
condicionan la capacidad del interfaz del anillo. Es muy sensible a fallos
en los módulos de comunicaciones y en el medio de comunicación. El
retardo grande para número de estaciones elevado.
15
Figura 2.2.- Topologías de red
2.6.2.- SEGÚN SU ACCESO AL MEDIO
Como es lógico, un nodo no debería poder enviar mensajes siempre que
le pareciera. Esto provocaría un funcionamiento erróneo de la red. Para que la
comunicación tenga coherencia, se establecen políticas de arbitraje, para
determinar cuándo es posible acceder al bus, y quién puede hacerlo. Según la
forma de acceder al medio existen tres procedimientos básicos para compartir
un canal de comunicaciones: selección, reserva y contienda (Figura 2.3). Los
dos primeros pueden realizarse con control de acceso centralizado (hay una
estación encargada de que el acceso se realice de forma correcta), o
distribuido (el control se realiza de forma conjunta por todas las estaciones
conectadas al medio). Las técnicas de contienda, también denominadas de
acceso aleatorio, son específicas para redes con control de acceso distribuido.
•
Selección: El usuario es avisado al llegar su turno, y toma el control
hasta que finaliza la transmisión de los mensajes que tiene pendientes
en cola de espera. En el acceso descentralizado, existe un método de
paso de testigo el cual determina que usuario tiene acceso al medio,
16
mientras que en el acceso centralizado, existe un módulo que
selecciona por turno a los posibles usuarios cada vez que el canal de
comunicaciones queda libre. En cualquier caso, los usuarios son
seleccionados por turnos, y desconocen cuando van a serlo
nuevamente. Dentro de ésta categoría se encuentran: Token Passing,
Polling.
•
Reserva: En las técnicas de reserva, a diferencia de lo que ocurre con las
de selección, el usuario conoce con adelanto cuando va a poder utilizar
el recurso. O dispone de una reserva permanente, o antes de tomar el
recurso, solicita que se le haga y confirme una reserva determinada.
Dentro de ésta categoría se encuentra: Cyclic, Schedule Access.
•
Contienda: Cuando un usuario necesita el canal de comunicación intenta
tomarlo, estableciéndose una contienda con otros usuarios que deseen
utilizarlo. Pueden producirse colisiones porque un usuario intente
acceder al canal cuando estaba ocupado, o porque dos manden
mensajes al canal al mismo tiempo. Dentro de ésta categoría se
encuentran: CSMA/CD, CSMA/CA, CSMA/NBA.
Figura 2.3.- Clasificación de protocolos según su acceso al medio
17
2.6.3.- SEGÚN SU MODELO DE COMUNICACIÓN
Además de las diferentes técnicas de acceso de los sistemas de
comunicación, resulta importante conocer los dos modelos básicos en los que
se enmarca cualquier sistema de comunicación, estos modelos son:
•
Cliente/Servidor: La comunicación en este modelo consiste en que un
nodo emite un mensaje a cada nodo destino, debiendo repetir ese
mensaje para cada uno de los nodos si es que desea que el mensaje
llegue a varios nodos pues la trama del mensaje enviado contiene una
cabecera donde figura el nodo fuente y el nodo destino. De este modo,
no es posible la llegada simultánea del mismo mensaje a todos los
nodos, utilizando la red de comunicaciones durante un largo periodo de
tiempo. Además, el tiempo de emisión a todos los nodos cambia según
el número de nodos a los que se desea hacer llegar el mensaje, el tipo
de difusión utilizado es el envío de mensajes desde un único emisor a un
único receptor (unicast). Este modelo es empleado por protocolos como:
PROFIBUS, INTERBUS y AS-Interface.
•
Productor/Consumidor: La comunicación en este modelo emplea un
sistema por el que todos los nodos reciben los mensajes que se
transmiten, siendo la tarea de cada nodo decidir si ese mensaje debe
aceptarlo. De este modo, todos los nodos reciben el mensaje
simultáneamente y no es necesario repetirlo para cada uno de los nodos
a los que está dirigido, con el consiguiente ahorro en el tiempo de
utilización del bus. Así, el tiempo de transmisión resulta constante
independientemente del número de nodos a los que se desea hacer
llegar el mensaje. En este caso, la trama del mensaje incluye un
identificador de mensaje; este identificador permite que los nodos
receptores conozcan si deben aceptarlo o no, el tipo de difusión
18
utilizado es el envío de mensajes a un grupo de receptores (multicast) o
a toda la red (broadcast). Este modelo es empleado por protocolos
como: WorldFIP, Fieldbus Foundation, CAN, ControlNet y EtherNet/IP.
2.6.4.- SEGÚN SUS PRESTACIONES
Una clasificación de los sistemas de comunicación en red que se verá
será atendiendo a los aspectos relacionados con sus prestaciones.
•
Buses de Alta Velocidad y Baja Funcionalidad (SensorBus): Diseñados
para integrar dispositivos simples como finales de carrera, fotocélulas,
relés y actuadores simples, funcionando en aplicaciones de tiempo real,
y agrupados en una pequeña zona de la planta, típicamente una
máquina. Suelen especificar las capas física y de enlace del modelo OSI,
es decir, señales físicas y patrones de bits de las tramas. Algunos
ejemplos son: Seriplex, AS-Interface.
•
Buses de Alta Velocidad y Funcionalidad Media (DeviceBus): Se basan
en el diseño de una capa de enlace para el envío eficiente de bloques de
datos de tamaño medio. Estos mensajes permiten que el dispositivo
tenga mayor funcionalidad de modo que permite incluir aspectos como
la configuración, calibración o programación del dispositivo. Son buses
capaces de controlar dispositivos de campo complejos, de forma
eficiente y a bajo costo. Normalmente incluyen la especificación
completa de la capa de aplicación, lo que significa que se dispone de
funciones utilizables desde programas basados en PCs para acceder,
cambiar y controlar los diversos dispositivos que constituyen el sistema.
Algunos incluyen funciones estándar para distintos tipos de dispositivos
(perfiles) que facilitan la interoperabilidad de dispositivos de distintos
fabricantes. Algunos ejemplos son: PROFIBUS DP, DeviceNet, SDS,
19
INTERBUS.
•
Buses de Altas Prestaciones (FactoryBus): Son capaces de soportar
comunicaciones a nivel de toda la factoría, en muy diversos tipos de
aplicaciones. Aunque se basan en buses de alta velocidad, algunos
presentan problemas debido a la sobrecarga necesaria para alcanzar las
características funcionales y de seguridad que se les exigen. La capa de
aplicación oferta un gran número de servicios a la capa de usuario,
habitualmente
características
un
subconjunto
incluyen:
redes
del
estándar
multimaestro
MMS.
con
Entre
sus
redundancia,
comunicación maestro-esclavo según el esquema pregunta-respuesta,
recuperación de datos desde el esclavo con un límite máximo de
tiempo, capacidad de direccionamiento unicast, multicast y broadcast,
petición de servicios a los esclavos basada en eventos, comunicación
de variables y bloques de datos orientada a objetos, descarga y
ejecución remota de programas, altos niveles de seguridad de la red,
opcionalmente
con
procedimientos
de
autentificación,
conjunto
completo de funciones de administración de la red. Algunos ejemplos
son: PROFIBUS, WorldFIP, Fieldbus Foundation.
•
Buses para Áreas de Seguridad Intrínseca (Intrinsically Safety): Incluyen
modificaciones en la capa física para cumplir con los requisitos
específicos de seguridad intrínseca en ambientes con atmosferas
explosivas. La seguridad intrínseca es un tipo de protección por la que el
aparato en cuestión no tiene posibilidad de provocar una explosión en la
atmósfera circundante. Un circuito eléctrico o una parte de un circuito
tienen seguridad intrínseca, cuando alguna chispa o efecto térmico en
este circuito producidos en las condiciones de prueba establecidas por
un estándar (dentro del cual figuran las condiciones de operación normal
y de fallo específicas) no puede ocasionar una ignición. Algunos
20
ejemplos son: PROFIBUS PA, Fieldbus Foundation H1, WorldFIP y
HART.
Figura 2.4.- Clasificación de los diversos buses de campo según sus prestaciones
2.6.5.- SEGÚN EL TIPO DE COMUNICACIÓN
Según la forma de intercambiar la información existen dos tipos de
protocolos de comunicaciones de datos:
•
Protocolos orientados a nodos: El intercambio de información entre
nodos se basa en el direccionamiento de los mismos, generalmente las
tramas de datos que se transmiten contienen las direcciones de destino
y algunas veces la dirección fuente.
•
Protocolos orientados a mensajes: La información a intercambiar se
descompone en mensajes, a los cuales se les asigna un identificador y
se encapsulan en tramas para su transmisión. Cada mensaje tiene un
identificador único, con el cual los nodos deciden aceptar o no dicho
mensaje.
21
CAPÍTULO 3.- ESTADO DEL ARTE DEL PROTOCOLO DE
COMUNICACIONES CAN
El propósito de este capítulo es realizar un estudio de requisitos para
implementar un sistema de transmisión en redes industriales a través del
protocolo de comunicaciones CAN, tanto en el aspecto de módulos requeridos
como la disponibilidad de equipos que reúnan tales características
3.1.- PROTOCOLO DE COMUNICACIONES CAN
El protocolo de comunicación CAN es uno de los buses de campo más
populares, fue desarrollado por Bosch e Intel al final de los años 80 como bus
de comunicaciones de costos razonables para la industria automotriz, aunque
rápidamente se extendió a otros campos como la robótica, automática y la
manufactura.
El protocolo CAN, en su especificación ISO 11898, describe como la
información será transmitida entre los diferentes dispositivos de una red. En
conformidad con el modelo de referencia OSI, el protocolo CAN garantiza
transparencia en el diseño y flexibilidad en las implementaciones definiendo
únicamente las capas física y enlace de datos, además establece un
mecanismo de supervisión especial para la gestión y control del nodo
(Figura 3.1). Existen también ciertos protocolos en la capa de aplicación que
proporcionan especificaciones sobre la base de CAN, entre los que se
encuentran: CAL, CANopen, DeviceNet, SDS, OSEK/VDX y CAN Kingdom.
22
Figura 3.1.- Arquitectura de capas del protocolo CAN
3.2.- CONCEPTOS BÁSICOS DEL BUS CAN
CAN es un protocolo de comunicación serial que utiliza el modelo de
comunicación productor/consumidor el que proporciona los datos a través de
difusión de mensajes, además es un protocolo orientado a mensajes que
posee las siguientes características:
•
Prioridad de mensajes: Se define mediante el identificador del mensaje
durante el acceso al bus de comunicaciones. El identificador también
distingue el contenido del mensaje pero no indica el destino del mismo,
solo describe su significado. Cada nodo en la red es capaz de filtrar los
mensajes de acuerdo al identificador para decidir si deben actuar o no.
•
Garantía en tiempos de latencia: La longitud de un mensaje es corta,
23
tiene como máximo 8 bytes de datos por mensaje lo que garantiza una
baja latencia entre transmisión y recepción. El método de acceso al
medio utilizado es: acceso múltiple por detección de portadora con
arbitraje no destructivo bit a bit 2 (CSMA/NBA, Carrier Sense Multiple
Access with Non-destructive Bitwise Arbitration) esto significa que la
colisión de mensajes es evitada por medio de arbitraje tomando en
cuenta la prioridad de los mismos.
•
Flexibilidad en la configuración: En un sistema CAN un nodo no hace
ningún uso de la información del sistema de configuración como por
ejemplo la dirección física de cada estación, esto hace que el sistema
sea flexible, es decir, se puede añadir nodos a la red CAN sin necesidad
de ningún cambio de software, hardware o en la capa aplicación.
•
Recepción por multidifusión con sincronización de tiempos: Todos los
nodos de la red reciben el mismo mensaje y realizan el mismo
procedimiento de filtrado simultáneamente.
•
Sistema robusto en cuanto a consistencia de datos: Todos los
receptores verifican la consistencia de la información que es recibida y
reconocen un mensaje consistente mediante acuses de recibo.
•
Sistema multimaestro: Cuando el bus está libre, cualquier nodo puede
iniciar la comunicación. La unidad con el mensaje de mayor prioridad a
ser transmitido gana el acceso al bus.
•
Detección y señalización de errores: El sistema CAN proporciona alta
inmunidad
a
la
interferencia
electromagnética,
provee
además
mecanismos de detección de errores como los siguientes: monitoreo,
chequeo de redundancia cíclica, bits de relleno, chequeo de formato de
La literatura también conoce a este método como acceso múltiple por detección de portadora
con detección de colisiones y arbitraje por prioridad del mensaje (CSMA/CD+AMP, Carrier
Sense Multiple Access with Collision Detection and Arbitration Message Priority)
2
24
tramas del mensaje. El mecanismo de detección de errores permite a los
nodos detectar errores globales, errores distribuidos de manera
aleatoria, ráfagas de errores de longitud menor a 15 y errores de
cualquier número impar en un mensaje. La probabilidad de error en un
mensaje es de 4,7 x 10-11.
•
Retransmisión automática de tramas erróneas tan pronto como el bus
esté libre: Los mensajes erróneos son identificados por una bandera de
modo que cualquier nodo está en capacidad de detectar un error. Los
mensajes erróneos se descartan y se retransmiten automáticamente.
•
Aislamiento de fallos 3: Distinción entre errores temporales y fallas
permanentes de los nodos de la red, desconexión autónoma de nodos
defectuosos.
3.3.- CAPA FÍSICA (PHY)
La capa física de un sistema de comunicaciones define los aspectos del
medio físico para la transmisión de datos entre los nodos de una red, los más
importantes hacen referencia a los niveles de señal, representación,
sincronización y tiempos en los que los bits se transfieren al bus. El diseño de
una red CAN varía de acuerdo a las necesidades de desempeño y para ello se
deben considerar los requisitos de la capa física.
La especificación del protocolo CAN no define una capa física, sin
embargo,
los
estándares
ISO 11898-2
e
ISO 11898-3
establecen
las
características que deben cumplir las aplicaciones para la transferencia en alta
y baja velocidad respectivamente. Cabe mencionar que las características
definidas para la capa física deben implementarse en todos los nodos que se
El estándar ISO 11898 y la especificación CAN 2.0 denominan a este mecanismo como
aislamiento de fallos mientras que en la literatura se denomina limitación de errores. En este
trabajo de tesis se emplea el término aislamiento de fallos
3
25
encuentren conectados dentro de una red CAN. La capa física (PHY, Physical
Layer) se divide en tres secciones o subcapas (Figura 3.2), las cuales se
describen a continuación.
Figura 3.2.- Arquitectura de la capa física del protocolo CAN
3.3.1.- SUBCAPA DE SEÑALIZACIÓN FÍSICA (PLS)
La subcapa de señalización física (PLS, Physical Signalling) define las
funciones relacionadas con la representación, temporización y sincronización
de los bits, y está implementada en los controladores del protocolo CAN.
3.3.1.1.- REPRESENTACIÓN DE BITS
Una trama CAN está codificada de acuerdo con el método NRZ (Non
Return to Zero), el cual establece que durante todo el tiempo de bit se genera
un nivel de señal que puede ser dominante (d) o recesivo (r). Una ventaja de
dicho método, en comparación con la codificación Manchester, es que
produce una frecuencia menor de operación, ya que la codificación
Manchester requiere de flancos en la mitad del tiempo de bit (Figura 3.3).
26
Figura 3.3.- Comparación de la representación de bits del código NRZ y el código Manchester
Sin embargo, en el caso de transmitir una gran cantidad de bits con la
misma polaridad, la codificación NRZ no proporciona flancos que puedan
utilizarse en la sincronización y por ello se implementa el procedimiento de
inserción de bit (bit stuffing), el cual asegura que en la transmisión de una
trama sólo puede haber un máximo de cinco bits consecutivos con la misma
polaridad como se muestra en la Figura 3.4.
Figura 3.4.- Ejemplo del procedimiento de inserción de bit
27
3.3.1.2.- TEMPORIZACIÓN DE BITS
Una característica importante del protocolo CAN es la flexibilidad para
determinar los parámetros de velocidad de transferencia, punto de muestreo
de bit y número de muestras realizadas en un periodo de bit. Por lo tanto, el
diseño de una red CAN debe considerar los siguientes conceptos:
•
Tiempo de quantum �𝑡𝑞 �: Es una unidad básica de tiempo, es de valor
fijo y se deriva del período del oscilador, éste valor es programable y
puede tomar los valores de 1 a 32. La longitud de los segmentos de
tiempo en un intervalo de bit está definida por múltiplos enteros de la
unidad básica de tiempo (t q , time quantum) derivada del periodo del
oscilador t CLK (Figura 3.5). El parámetro t q es la unidad de tiempo
discreta más pequeña utilizada por un nodo CAN.
Figura 3.5.- Principio de derivación del periodo de bit
•
Tiempo de bit nominal (𝑡𝑏 ): Es la relación inversa entre el tiempo de
duración de un bit (t b ) y la velocidad de transferencia nominal (fb )
correspondiente al el número de bits por segundo que un transmisor
ideal emite sin resincronización. Se obtiene mediante la Ecuación 3.1 y
se divide en cuatro segmentos de tiempo no traslapados (Figura 3.6).
28
tb =
1
fb
[3. 1]
Figura 3.6.- Segmentos del tiempo de bit
Los cuatro segmentos que forman un tiempo de bit nominal son:

Segmento de sincronización (Sync_Seg): Es el primer segmento del
tiempo de bit nominal y el cual es utilizado para la sincronización de

los nodos en el bus. Su longitud es fija e igual a 1t q .
Segmento de tiempo de propagación (Prop_Seg): Es utilizado para
compensar el retardo de propagación de la señal en el bus y retardos
inherentes a los nodos como los son los retardos del controlador del

bus. Su longitud puede tomar los valores enteros de 1 a 8t q .
Segmento de memoria temporal de fase 1 (Phase_Seg1): Segmento
de longitud ajustable que se utiliza para compensar variaciones de
tiempo entre nodos, puede incrementarse durante la resincronización

Su longitud puede tomar los valores enteros de 1 a 8t q .
Segmento de memoria temporal de fase 2 (Phase_Seg2): Segmento
de longitud ajustable que se utiliza para compensar variaciones de
tiempo entre nodos y puede reducirse durante la resincronización. Su
longitud puede tomar los valores enteros desde el Tiempo de
procesamiento de la información hasta el máximo definido por
29
Phase_Seg1.
El número total de unidades básicas en un tiempo de bit debe ser
programable entre 8 a 25t q .
•
Punto de muestreo: Es el instante de tiempo en el cual se lee y se
interpreta el nivel del bus para determinar el valor del bit. Se localiza
después del segmento Phase_Seg1.
•
Tiempo de procesamiento de la información: Es el periodo de tiempo
que comienza con el Punto de muestreo reservado para calcular el nivel
de bit subsecuente. Su longitud es inferior o igual a 2t q .
Figura 3.7.- Ejemplo de definición de un tiempo de bit
3.3.1.3.- MECANISMOS DE SINCRONIZACIÓN DE BITS
El protocolo CAN utiliza transferencia de datos sincrónica, lo cual
incrementa la capacidad de transmisión pero requiere un método de
sincronización de bits debido a que sólo está disponible un bit de inicio al
comienzo de la trama. Lo anterior no es suficiente para mantener sincronizado
el muestreo de bit del receptor con el del transmisor, y para lograrlo se requiere
realizar una resincronización continua del receptor.
En una red CAN cada nodo se sincroniza con su propio oscilador,
debido a ello pueden ocurrir desplazamientos de fase en los diferentes nodos y
por lo tanto los controladores CAN proporcionan un mecanismo de
30
sincronización para compensar dichos desplazamientos mientras reciben una
trama CAN.
Antes de analizar las dos formas de sincronización descritas por el
protocolo CAN, es necesario definir:
•
Error de fase de un flanco: El error de fase de un flanco (e) está dado
por la posición del flanco respecto al segmento de sincronización
Sync_Seg y se mide en unidades (t q ). El signo del error de fase se define
de la siguiente manera:



e = 0, si el flanco se detecta dentro del Sync_Seg.
e > 0, si el flanco se detecta antes del Punto de muestreo.
e < 0, si el flanco se detecta después del Punto de muestreo del bit
previo.
•
Resincronización: Es el valor programado de unidades (t q ) que se suma
a la longitud del Phase_Seg1, o se reduce de la longitud del
Phase_Seg2. dado por un determinado valor que depende del error de
fase en la señal. Cuando la magnitud del Error de fase es mayor que el
valor de RJW,

y si el error de fase es positivo: El segmento Phase_Seg1 se prolonga

por una cantidad igual al valor de RJW (1 a 4t q ).
y si el error de fase es negativo: El segmento Phase_Seg2 se reduce
por una cantidad igual al valor de RJW (1 a 4t q ).
3.3.1.4.- TIPOS DE SINCRONIZACIÓN
El protocolo CAN define dos tipos de sincronización:
•
Sincronización al comienzo de la trama (Forzada): Ocurre en una
transición recesivo-dominante durante el tiempo en donde el bus se
31
encuentra inactivo (bus idle), se obliga al tiempo de bit interno reiniciar
con el segmento Sync_Seg al inicio del bit.
•
Resincronización dentro de la trama (RJW): Como resultado de una
Resincronización, uno de los segmentos de la fase se puede alargar
(Phase_Seg1) o se puede acortar (Phase_Seg2). La cantidad en que se
aumenta o disminuye alguno de los Phase_Seg tiene un límite superior
definido por el parámetro RJW (Resynchronization Jump Width) y deberá
ser programado entre 1 y 4t q .
Ambas formas de sincronización siguen las siguientes reglas:
1.- Dentro de un tiempo de bit sólo se permite una sincronización.
2.- Para efectos de sincronización se utiliza un flanco sólo si el valor
detectado en el punto de muestreo anterior difiere del valor del bus
inmediatamente después del flanco.
3.- Se realiza una sincronización siempre que haya un flanco recesivo a
dominante, y cuando el bus esté desocupado.
Todos los flancos recesivos a dominantes, opcionalmente los flancos
dominantes a recesivos en el caso de bajas velocidades de transferencia, que
satisfagan las reglas 1 y 2 se utilizan para una resincronización, a excepción de
que un nodo que se encuentre transmitiendo un bit dominante no puede
realizar resincronización como resultado de una flanco recesivo a dominante
con un error de fase positivo, si sólo son utilizados para la resincronización
flancos recesivos a dominantes.
32
3.3.1.5.- IMPACTO DE LA VELOCIDAD DE TRANSFERENCIA EN LA LONGITUD
DEL BUS
La longitud máxima del bus CAN depende básicamente de dos
aspectos:
•
Aspectos de corriente alterna: Que corresponden al tiempo de bit,
tolerancia del oscilador, retardo de propagación y capacitancia de la
red.
•
Aspectos de corriente directa: Correspondientes a las consecuencias de
la amplitud de la señal del bus, impedancia característica de los cables
del bus y la impedancia de entrada de los nodos.
Como se menciona anteriormente, la capa física se encarga de
representar los estados dominante y recesivo. Durante el proceso de arbitraje
para acceder al medio, el nodo compara los valores de bit que transmite con
los que recibe para decidir si continua con la transmisión, para ello los nodos
deben asegurar que la transmisión de un bit dominante se realice dentro del
periodo de bit correspondiente y por consiguiente puedan detectar una
condición de pérdida del arbitraje y detengan su transmisión.
El retardo de propagación entre los nodos es resultado del retardo de
línea del bus específica (menor a la velocidad de la luz) y del retardo de los
componentes electrónicos. Por esta razón, los requerimientos de tiempo de bit
implican que la velocidad de transferencia disminuya a medida que la longitud
del bus y/o la tolerancia del oscilador incrementan.
Existen dos criterios para optimizar la relación entre la velocidad de
transferencia y la longitud del bus:
•
El primero se enfoca en obtener una longitud de bus máxima dada una
33
velocidad de transferencia y para ello es necesario que la ubicación del
punto de muestreo esté lo más cercano posible del final del periodo de
bit, y la tolerancia del oscilador debe minimizarse utilizando un oscilador
de cristal.
•
El segundo hace hincapié en el uso de osciladores menos precisos y por
lo tanto, el tiempo de bit debe ajustarse a la tolerancia máxima del
oscilador, sin embargo, la optimización de la tolerancia del oscilador
implica una reducción considerable de la longitud de bus a una
velocidad de transferencia dada.
La relación entre la máxima velocidad de transferencia y la máxima
longitud de bus, pueden calcularse mediante la Ecuación 3.2.
[3. 2]
fB × long_bus < 50000m × Kbps
Utilizando transceptores de alta velocidad se pueden lograr distintas
longitudes de bus (Tabla 3.1 y Figura 3.8). A velocidades de transferencia de
datos menores a 1Mbps, la longitud del bus puede incrementarse
significativamente. El estándar ISO 11898 establece una longitud de bus
máxima de 1Km, pero permite el uso de puentes y/o repetidores para
incrementar la distancia entre los nodos.
Tabla 3.1.- Velocidad de transferencia de datos y longitud del bus
Velocidad de Transferencia
[Kbps]
1000
500
250
125
62,5
20
Longitud del Bus
[m]
40
100
250
500
1000
2500
Tiempo de Bits Nominal
[µs]
1
2
4
8
20
50
34
Figura 3.8.- Relación entre velocidad de transferencia y longitud del bus
3.3.1.6.- TOLERANCIA DE OSCILACIÓN
Como se mencionó en los anteriormente, cada nodo CAN deriva su
señal de tiempo de bit de su propio oscilador. En sistemas reales, la frecuencia
del oscilador fCLK se desvía de su valor nominal debido al desplazamiento de
tolerancia inicial, al envejecimiento de los componentes electrónicos y a las
variaciones de la temperatura ambiental.
La suma de desviaciones resulta en una tolerancia total del oscilador
(Δf), la cual es una tolerancia relativa que representa la desviación de la
frecuencia del oscilador normalizada a la frecuencia nominal (Ecuación 3.3).
Δf = �
fCLK máx/mín − fCLK nom
�
fCLK nom
[3. 3]
Así como la señal de reloj de un sistema CAN se deriva de la frecuencia
del oscilador, Δf representa la tolerancia relativa de la señal de reloj del
35
sistema; los valores mínimos y máximos para la duración del periodo del reloj
del sistema se aproximan como definen las Ecuaciones 3.4 y 3.5.
t SCL mín =
t SCL máx =
t SCL nom
≈ t SCL nom (1 − Δf)
1 + Δf
t SCL nom
≈ t SCL nom (1 + Δf)
1 − Δf
[3. 4]
[3. 5]
Las aproximaciones que se establecen las Ecuaciones 3.4 y 3.5 son
válidas asumiendo un valor de Δf << 1. Las referencias de reloj utilizadas en
sistemas reales, tales como osciladores de cristal (Δf < 0,1%), frecuencias
derivadas de PLL (Phase Locked Loop) (Δf < 0,5%) y resonadores cerámicos
(Δf < 1,2%), satisfacen tal consideración.
La especificación CAN, establece una tolerancia máxima para el
oscilador de 1,58%, y recomienda el uso de un resonador de cerámica en
aplicaciones que necesiten una velocidad de transferencia menor a 125Kbps.
Cuando se requiere de toda la gama de velocidades que establece el
protocolo CAN, es necesario utilizar un oscilador de cuarzo. En una red CAN, la
exactitud de oscilación requerida por los demás nodos está determinada por el
circuito integrado que demande mayor precisión en su oscilador.
Los resonadores de cerámica se utilizan únicamente cuando todos los
nodos de la red cumplen con la especificación del protocolo CAN posterior a la
versión 1.2. En controladores de protocolo que cumplan con la versión 2.0 A/B
y anteriores, se recomienda utilizar osciladores de cristal siempre y cuando
pertenezcan a la misma red.
36
3.3.2.- SUBCAPA DE UNIÓN AL MEDIO FÍSICO (PMA)
La conexión entre el controlador CAN y el medio físico se define en la
subcapa de unión al medio físico (PMA, Physical Medium Attachment). Esta
subcapa describe las características funcionales y eléctricas que debe cumplir
el transceptor para hacer posible la transmisión/recepción entre un nodo y la
red, además algunas de sus implementaciones en circuitos integrados o
discretos proporcionan los medios para detectar fallos en el bus.
La interfaz eléctrica con el bus consiste principalmente de un transmisor
y un receptor. La Figura 3.9 muestra el diagrama a bloques básico de un
transceptor en un nodo CAN, el controlador CAN provee funcionalidad básica
de transceptor, que consiste de un comparador en la recepción y un
amplificador en la salida.
Figura 3.9.- Arquitectura de un nodo CAN con transceptor
Además de la adaptación de señales entre el controlador CAN y el bus,
el transceptor tiene que cumplir con las siguientes funciones:
37
•
Suministrar la capacidad de rendimiento al controlador CAN.
•
Proteger al controlador CAN contra sobrecargas.
•
Reducir la radiación electromagnética.
Como receptor realiza las siguientes funciones:
•
Suministrar un nivel de señal recesivo.
•
Proteger el comparador de entrada del controlador CAN contra
sobre-voltajes de las líneas del bus.
•
Suministrar suficiente sensibilidad para un mejor reconocimiento de la
señal de entrada.
•
Detectar errores en el bus tales como: ruptura de la línea, corto-circuito
y conmutación a operación asimétrica de una sola línea.
Una función opcional del transceptor es proporcionar aislamiento
galvánico, al nodo CAN de las líneas de bus, mediante el empleo de
optoacopladores.
3.3.3.- SUBCAPA DE INTERFAZ DEPENDIENTE DEL MEDIO (MDI)
La interfaz dependiente del medio (MDI, Medium Dependent Interfaz)
define los aspectos eléctricos y mecánicos para la conexión entre el medio
físico y el nodo. Las especificaciones mecánicas de la capa física definen las
características de la interfaz respecto al medio de transmisión y al tipo de
conector.
3.3.3.1.- MEDIO FÍSICO
Un requisito indispensable para realizar el método de arbitraje en el bus,
es la capacidad de representar los niveles de señal recesivo y dominante.
38
Dicho principio se realiza con medios eléctricos u ópticos, los cuales se
describen a continuación.
3.3.3.1.1.- MEDIO DE TRANSMISIÓN ELÉCTRICO
La implementación de redes CAN generalmente utiliza como medio
físico un bus de dos hilos con retorno común controlados diferencialmente. En
aplicaciones específicas se utiliza un bus de un sólo hilo, por ejemplo en
dispositivos electrónicos internos de un vehículo. En la actualidad se
desarrollan soluciones en las que se transmiten las señales CAN junto con la
fuente de alimentación en el mismo bus.
Figura 3.10.- Medio de transmisión eléctrico
•
Bus de dos hilos: Permite una transmisión diferencial y es resistente a
los errores de modo común (Figura 3.10a). Las líneas del bus deben
contar con un terminador de bus en cada extremo, el cual consiste en
resistores de 120Ω para evitar la reflexión de la señal. Se garantiza la
transmisión de una señal a pesar de sus niveles bajos, además, la
interferencia de radio inducida de forma electromagnética se puede
compensar por cables del tipo par trenzado. Si se implementa un
manejo adecuado de los errores en el bus, es posible que la
comunicación continúe en condiciones de inmunidad de ruido reducida
39
aún si una línea se rompe o se encuentra en corto circuito.
•
Bus de un hilo: Esta solución da por hecho que está disponible una tierra
común para todos los nodos (Figura 3.10b) y sólo se implementa en
aplicaciones
automotrices
para
la
interconexión
de
dispositivos
electrónicos internos. El bus de un hilo está expuesto a la interferencia
inducida eléctricamente cuando no está blindado, por lo tanto es
necesario realizar un gran desplazamiento del nivel de la señal para
mejorar la relación señal/ruido, lo cual afecta el grado de emisiones
electromagnéticas y requiere la reducción de las caídas de la señal y por
lo tanto de la máxima velocidad de transferencia de datos.
•
Transmisión de la señal y fuente de alimentación integrada en la misma
línea:
Muchos
sistemas
de
Fieldbus,
como
AS-Interface
y
PROFIBUS PA, suministran la fuente de alimentación junto a la
transmisión de datos sobre la misma línea del bus. El suministro de
voltaje sobre el bus es conveniente en sistemas CAN, sin embargo, no
se recomienda la transmisión simultánea de alimentación y datos debido
al arbitraje no destructivo bit a bit que utiliza dicho protocolo.
Actualmente este tipo de transmisión se encuentra en fase de
investigación y una posible solución es utilizar modulación OOK (On-Off
Keying) para la transmisión de datos. Las investigaciones muestran que
la transmisión simultánea de datos y alimentación implica la utilización
de circuitos de alto costo, pérdida de inmunidad a la interferencia y
reducción en la longitud del bus, por lo que esta solución no es
competente frente a las ya existentes en el mercado.
3.3.3.1.2.- MEDIO DE TRANSMISIÓN ÓPTICO
Los avances relacionados con los medios de transmisión ópticos han
obtenido gran importancia en el desarrollo de redes CAN, especialmente en el
40
área de la fibra óptica. El comportamiento eléctricamente neutro de un medio
óptico es ideal para aplicaciones en ambientes potencialmente explosivos y
entornos electromagnéticos perturbados.
Las líneas de transmisión y recepción deben proporcionarse de forma
separada, debido al acoplamiento directo en el medio óptico. Además cada
línea de recepción debe acoplarse externamente con cada línea de transmisión
con el propósito de asegurar el monitoreo de bits que requiere el protocolo
CAN, esta función puede implementarse por un acoplador de tipo estrella. El
uso de acopladores pasivos tipo estrella es posible con una cantidad pequeña
de nodos, lo cual limita la expansión de este tipo de redes.
3.3.3.2.- TIPOS DE CONECTORES CAN
A nivel de capa física, existen diversos tipos de conectores
estandarizados que pueden ser utilizados, pueden ser tanto del tipo cerrado
como abierto. La definición del tipo a ser utilizado dependerá de la aplicación y
del ambiente de operación del equipamiento. A continuación se entregará una
lista de conectores más utilizados para el bus CAN en donde se mostrará la
forma y asignación de terminales de cada modelo.
3.3.3.2.1.- CONECTOR DB9
Conector DB9, recomendación DS-102 (Tabla 3.2 y Figura 3.11).
41
Tabla 3.2.- Asignación de terminales en el conector DB9
Pin
1
2
3
4
5
6
7
8
9
Señal
CAN_L
CAN_GND
CAN_SHLD
GND
CAN_H
CAN_V+
Descripción
Futuras aplicaciones
Señal de bus CAN (dominante bajo)
Señal de tierra (GND)
Futuras aplicaciones
Blindaje (opcional)
Tierra (opcional)
Señal de bus CAN (dominante alto)
Futuras aplicaciones
Fuente de alimentación externa (opcional)
Figura 3.11.- Conector tipo DB9
3.3.3.2.2.- CONECTOR TIPO MINI
Conector tipo mini (Tabla 3.3 y Figura 3.12).
Tabla 3.3.- Asignación de terminales del conector tipo mini
Pin
1
2
3
4
5
Señal
CAN_SHLD
CAN_V+
CAN_GND
CAN_H
CAN_L
Descripción
Blindaje (opcional)
Fuente de alimentación externa (opcional)
Señal de tierra (GND)
Señal de bus CAN (dominante alto)
Señal de bus CAN (dominante bajo)
Figura 3.12.- Conector tipo mini
42
3.3.3.2.3.- CONECTOR TIPO MICRO
Conector tipo micro de 5 terminales, o también llamado conector M12
(Tabla 3.4 y Figura 3.13).
Tabla 3.4.- Asignación de terminales del conector tipo micro
Pin
1
2
3
4
5
Señal
CAN_SHLD
CAN_V+
CAN_GND
CAN_H
CAN_L
Descripción
Blindaje (opcional)
Fuente de alimentación externa (opcional)
Señal de tierra (GND)
Señal de bus CAN (dominante alto)
Señal de bus CAN (dominante bajo)
Figura 3.13.- Conector tipo micro
3.3.3.2.4.- CONECTOR TIPO NANO
Conector tipo micro de 5 terminales, o también llamado conector M8
(Tabla 3.5 y Figura 3.14).
Tabla 3.5.- Asignación de terminales del conector tipo nano
Pin
1
2
3
4
5
Señal
CAN_V+
CAN_SHLD
CAN_H
CAN_L
CAN_GND
Descripción
Fuente de alimentación externa (opcional)
Blindaje (opcional)
Señal de bus CAN (dominante alto)
Señal de bus CAN (dominante bajo)
Señal de tierra (GND)
43
Figura 3.14.- Conector tipo nano
3.3.3.2.5.- CONECTOR TIPO ABIERTO
Conector tipo abierto (Tabla 3.6 y Figura 3.15).
Tabla 3.6.- Asignación de terminales del conector tipo abierto
Pin
1
2
3
4
5
Señal
CAN_GND
CAN_L
CAN_SHLD
CAN_H
CAN_V+
Descripción
Señal de tierra (GND)
Señal de bus CAN (dominante bajo)
Blindaje (opcional)
Señal de bus CAN (dominante alto)
Fuente de alimentación externa (opcional)
Figura 3.15.- Conector tipo abierto
3.3.3.3.- TOPOLOGÍA DE UNA RED CAN
Si no se consideran las medidas apropiadas, las señales eléctricas
transmitidas en las líneas del bus CAN se reflejan al final de la línea eléctrica
principal y en las líneas de extensión, por ello es necesario que las reflexiones
sobrepuestas de la señal estén debidamente atenuadas cuando se muestrea el
nivel de bit para interpretar los niveles de bus recibidos. Las reflexiones de la
44
señal se pueden evitar al colocar resistores de terminación con una impedancia
equivalente a la de la línea en ambos extremos del bus, y al evitar líneas de
extensión de grandes longitudes. De esta forma, mediante una topología de
bus se puede lograr el producto más alto de velocidad de transferencia y
longitud de línea (Figura 3.10).
En aplicaciones industriales no es común conectar un nodo al bus
mediante líneas de extensión muy cortas, sin embargo, con la configuración
apropiada de los parámetros de los tiempos de bit, el punto de muestro de bit
puede colocarse al final del tiempo de bit, y con ello se minimizan los efectos
de reflexión de la señal.
En muchas aplicaciones es inevitable utilizar topologías extendidas, por
ejemplo para conectar herramientas de diagnóstico o servicio. Para superar las
limitaciones de la topología de bus CAN se emplean repetidores, puentes y
pasarelas con la finalidad de adaptar la topología de red de acuerdo con las
necesidades geográficas de cada aplicación específica.
3.3.4.- ESTÁNDARES DE LA CAPA FÍSICA
Como se mencionó anteriormente, las redes CAN tienen diversas
aplicaciones, sin embargo la especificación CAN no define las características
del transceptor, y deja abierta la posibilidad de implementar el medio de
transmisión y los niveles de señales que más convengan al diseñador de la red.
Por ello se han definido diferentes estándares, los cuales especifican: niveles
de señales, topología de la red, máximo número de nodos, requisitos para el
bus y conectores.
45
Para medios eléctricos los voltajes diferenciales son definidos en:
ISO 11898-2 (alta velocidad), ISO 11898-3 (tolerante a fallos), SAE J2411 (un
sólo hilo), ISO 11992 (punto a punto).
3.3.4.1.- ESTÁNDAR ISO 11898-2
El estándar ISO 11898-2, destinado a la comunicación de alta velocidad
en vehículos, es la norma más importante y CiA lo recomienda para
aplicaciones industriales. Las capas de aplicación: CANopen, DeviceNet y SDS
especifican suplementos a éste estándar. Establece los fundamentos de una
serie de estándares y es la norma de capa física más importante en
aplicaciones industriales y automotrices. Dicha norma describe las funciones
de la subcapa PMA, y algunas características de la subcapa MDI. Sus
principales características son:
•
Velocidades de transferencia de datos de hasta 1Mbps.
•
Longitud máxima del bus de 40m a 1Mbps.
•
El número total de nodos está limitado por la carga eléctrica en el bus.
•
Bus diferencial de dos hilos.
•
Seguridad contra corto circuito en el rango de voltaje comprendido entre
-3V a +16V.
•
Impedancia característica de la línea de 120Ω.
•
Rango de voltaje en modo común desde -2V (CAN_L) a +7V (CAN_H).
El estándar ISO 11898-2 define un bus de dos hilos terminado en ambos
extremos con la impedancia de línea específica del medio físico y con las
siguientes características eléctricas:
•
Longitud máxima de línea de extensión: 30cm.
•
Resistencia de línea nominal por metro: 70mΩ/m.
46
•
Retardo de propagación nominal: 5ns/m.
El bus de dos hilos especificado en el estándar ISO 11898, contiene dos
señales, CAN_H y CAN_L, en donde todo nodo CAN debe proporcionar el
voltaje diferencial de salida en el bus (Ecuación 3.6):
Vdiff = VCAN_H − VCAN_L
•
Bit recesivo: -500mV a +500mV, sin carga.
•
Bit dominante: +1,5 V a +3,0 V, con una carga de 60Ω.
[3. 6]
En la Tabla 3.7 y Figura 3.16 se muestran los niveles de las señales en
el bus CAN en especificados en el estándar ISO 11898-2. Los nodos deben
detectar los dos estados posibles del bus: Dominante y Recesivo.
Tabla 3.7.- Niveles nominales de voltaje en el bus CAN de acuerdo al estándar ISO 11898-2
Señal CAN
Estado del Bus
Dominante
Recesivo
Niveles Nominales de Voltaje [V]
CAN_H
CAN_L
Vdiff
3,5
1,5
2
2,5
2,5
0
Figura 3.16.- Niveles nominales de señal en el bus CAN recomendados por el estándar
ISO 11898-2
47
Según el estándar ISO 11898-2, el acceso al medio se realiza mediante
un transceptor de alta velocidad, el cual además realiza otras tareas como
obtener las medidas de protección requeridas en vehículos de motor. Un
transceptor debe cumplir con las siguientes características:
•
Compatible con la norma ISO 11898-2.
•
Soportar velocidades de transferencia de datos de hasta 1Mbps.
•
Proteger contra sobrecarga térmica.
•
Proteger contra corto circuito, tanto de tierra como de fuente de voltaje.
•
Consumir poca corriente en modo de espera.
•
Protección contra perturbaciones de la línea del bus.
Para que un nodo cumpla con el estándar ISO 11898-2 debe contar con
un MCU y un controlador CAN, los cuales se conectan al bus mediante un
transceptor a través de dos líneas, una línea de salida de datos (TX ) y otra línea
de entrada de datos (R X ) (Figura 3.9).
Las líneas TX y R X manejan niveles TTL (Transistor-Transistor Logic) y
son unidireccionales; las líneas CAN_H y CAN_L se utilizan para enlazar el
transceptor al bus. La Figura 3.17 muestra los niveles nominales de las señales
CAN que se presentan en un transceptor CAN de alta velocidad.
48
Figura 3.17.- Niveles nominales de las señales presentes en un transceptor CAN
3.3.4.2.- ESTÁNDAR ISO 11898-3
El estándar ISO 11898-3 define una capa física CAN de baja velocidad
tolerante a fallos, destinada a aplicaciones con escasos requerimientos en
cuanto a velocidad de transferencia y longitud de bus. Fue desarrollado por las
firmas Philips y Bosch con la finalidad de reemplazar al estándar ISO 11519.
Este estándar está dirigido principalmente a la realización de redes de
unidades electrónicas que aumentan la comodidad en un automóvil.
Si se considera una red eléctricamente corta, no se considera el
problema de reflexión de la señal y puede utilizarse una línea de bus abierta. Lo
anterior significa que pueden utilizarse controladores de baja potencia, y con
ello realizarse redes de bajo consumo. Otra característica es la topología de
red, la cual no se restringe a una estructura lineal con longitudes de extensión
cortas para la conexión entre los nodos y el bus. Asimismo existe la posibilidad
de transmitir datos asimétricamente sobre un sólo hilo del bus en caso de
ocurrir una falla eléctrica en sus líneas. Los parámetros más importantes de
este estándar son los siguientes:
49
•
Velocidades de transferencia de datos de hasta 125Kbps.
•
Redes de hasta 32 nodos.
•
Transmisión de señal simétrica mediante par trenzado.
•
Prueba de corto circuito en un rango de voltaje de -6V a +16V.
•
Corriente de salida del transmisor mayor a 1mA.
•
Rango de voltaje en modo común entre -2V a +7V.
•
Fuente de alimentación de 5V.
En la Tabla 3.8 y Figura 3.18 se muestran los niveles de las señales en
el bus CAN en especificados en el estándar ISO 11898-3. Los niveles de la
señal en el bus son diferentes para el nivel recesivo y para el nivel dominante, y
de esta forma dichos niveles del bus pueden detectarse al compararse con un
voltaje de referencia de 2,5V.
Tabla 3.8.- Niveles de voltaje en el bus CAN de acuerdo al estándar ISO 11898-3
Señal CAN
Estado del Bus
Dominante
Recesivo
CAN_H
5 – 3,6
0 – 0,3
Niveles de Voltaje [V]
CAN_L
Vdiff
1,4 – 0
2,2 – 5
4,7 – 5
-4,4 – -5
Figura 3.18.- Niveles de señal en el bus CAN recomendados por el estándar ISO 11898-3
El estándar ISO 11898-3 considera la detección y el manejo de las
siguientes condiciones de error en el bus:
50
•
Interrupción de la señal CAN_H.
•
Interrupción de la señal CAN_L.
•
Corto circuito de la señal CAN_H con Vcc.
•
Corto circuito de la señal CAN_L con GND.
•
Corto circuito de la señal CAN_H con GND.
•
Corto circuito de la señal CAN_L con Vcc.
•
Corto circuito de la señal CAN_H con la señal CAN_L.
Las distintas condiciones de error pueden detectarse al comparar
ambas líneas del bus CAN, y detectando el nivel dominante a través de un
tiempo fuera al deshabilitar la línea defectuosa y conmutar a operación
asimétrica; la comunicación puede continuar sobre la línea sobrante, sin
embargo, se pierde la inmunidad a la interferencia eléctrica. Una solución de
interfaz de bus que cumpla con el estándar ISO 11898-3 puede realizarse
mediante un transceptor modelo TJA 1054 de la firma Philips (Figura 3.19).
Figura 3.19.- Interfaz para bus CAN utilizando un transceptor TJA 1054 de la firma Philips
Dicho transceptor da soporte total al manejo de errores, incluyendo la
detección de errores en el bus y la conmutación automática al modo de
51
transmisión asimétrico. Cuando la condición de error deja de existir,
automáticamente se regresa al modo de transmisión simétrico. Además el
transceptor contiene un filtro de interferencia integrado en el módulo de
recepción y un modo de ahorro de corriente, el cual habilita la conexión de
componentes adicionales que pueden agregarse cuando el bus está activo.
3.3.4.3.- ESTÁNDAR SAE J2411
El estándar de un sólo hilo SAE J2411 se aplica en redes CAN con
requisitos de velocidad de transferencia y longitud de bus menores a los
establecidos por el estándar ISO 11898-3. Los parámetros básicos de este
estándar son los siguientes:
•
Bus de comunicación de un sólo hilo.
•
Velocidad de transferencia nominal de 331/3Kbps en modo normal.
•
Alta velocidad de transferencia de datos para propósitos de diagnóstico
de 831/3Kbps.
•
Hasta 32 nodos por red.
•
Modo de temporizador selectivo.
La principal aplicación del estándar SAE J2411 está enfocada a la
realización de redes de ECUs que aumentan la comodidad en un automóvil. El
medio físico se define como un cable de un sólo hilo no blindado. Debido a la
baja velocidad de transferencia, la topología del bus no está limitada a una
estructura lineal con longitudes cortas de la línea de conexión del nodo con el
bus. La Figura 3.20 muestra los niveles nominales de la señal CAN en el bus,
en modo normal.
52
Figura 3.20.- Niveles nominales de la señal CAN en el bus de acuerdo al estándar SAE J2411
El estándar SAE J2411 puede realizarse utilizando un transceptor
modelo TLE 6255 de la firma Infineon Semiconductors.
3.3.4.4.- ESTÁNDAR ISO 11992
El estándar ISO 11992 es una alternativa de red CAN para baja
velocidad basado en conexiones punto a punto, utilizada en el control de
camiones de carga y vehículos remolcadores o grúas. Los parámetros básicos
de dicho estándar son:
•
Conexiones punto a punto para vehículos con un remolque.
•
Conexión lineal para vehículos con dos remolques.
•
Velocidad de transferencia nominal de 125Kbps.
•
Longitud de línea máxima de 40m.
•
Transmisión simétrica sobre un par de hilos con línea de tierra y fuente
de alimentación.
•
Manejo de errores de bus.
•
Voltaje de alimentación Vcc = 12V o 24V.
El medio físico está definido como un cable par trenzado y no se
especifican resistores de terminación en el bus debido a la corta longitud del
53
mismo y su baja velocidad de transferencia. El estándar ISO 11992 especifica
la capacitancia máxima por unidad de longitud, la impedancia de la línea, las
capacitancias de contacto máximas e impedancias de conexión para los
conectores, las condiciones extremas del ambiente para el cable, tipo de
conectores y los ciclos de conexión para intercambio de los remolques.
La Figura 3.21 muestra los niveles nominales de las señales CAN del
bus de acuerdo al estándar ISO 11992. Los niveles nominales en el bus
dependen de suministro de voltaje Vcc de los vehículos. Los niveles nominales
de las señales para 12V y 24V se muestran en la Tabla 3.9.
Tabla 3.9.- Niveles de las señales CAN en el bus recomendados por el estándar ISO 11992
Nivel
Dominante
Recesivo
Señal
CAN_H
CAN_L
CAN_H
CAN_L
Voltaje del vehículo [V]
12V
24V
6,0 a 10,6
10,6 a 21,3
3,0 a 5,3
5,3 a 10,6
3,0 a 5,3
5,3 a 10,6
6,0 a 10,6
10,6 a 21,3
Figura 3.21.- Niveles nominales de las señales CAN en el bus de acuerdo con el estándar
ISO 11992
El estándar ISO 11992 también especifica el manejo de errores del bus
al activar el cambio a transmisión de señal asimétrica cuando se detecta un
error de bus físico. La comunicación se puede mantener por operación
54
asimétrica en caso de ruptura, corto circuito con Vcc, con tierra o entre las
líneas. Durante la emisión de línea sencilla se verifica el modo de transmisión
de señal, para asegurar que en funcionamiento normal, o después de corregir
un error de bus, el modo de transmisión sea simétrico.
3.3.4.5.- RECOMENDACIÓN CIA DS-102
Respecto a la capa física, la recomendación CiA DS-102 brinda soporte
a la realización de redes CANopen para la comunicación entre diversos tipos
de módulos electrónicos en aplicaciones industriales. Dicha recomendación
está basada en los estándares ISO 11898-1 y 11898-2, y define lo siguiente:
Velocidades de transferencia estandarizadas desde 10Kbps a 1Mbps, con
recomendaciones para la configuración de los parámetros de tiempos de bit
(Tabla 3.10 y
•
Tabla 3.11).
•
Recomendaciones para la línea de bus.
•
Características mecánicas y eléctricas de los conectores, así como la
asignación de sus terminales (Tabla 3.7 y Figura 3.16).
Tabla 3.10.- Velocidades de transferencia y parámetros de tiempos de bit recomendados en
DS-102
Velocidad de Longitud de Tiempo de
Número de
Transferencia Línea Máxima Bit Nominal
tq
[Kbps]
[m]
[μs]
1000
25
1
8
800
50
1,25
10
500
100
2
16
250
250
4
16
125
500
8
16
50
1000
20
16
20
2500
50
16
10
5000
100
16
Duración
de tq [ns]
125
125
125
250
500
1250
3125
6250
Punto de
Muestreo
[tq]
6
8
14
14
14
14
14
14
55
Tabla 3.11.- Parámetros de tiempos de bit recomendados por DS-102
Parámetro
Frecuencia del oscilador
Método de muestreo
Modo de sincronización
Duración de SJW*
Duración de Phase_Seg2
Recomendación DS-102
16Mhz +/- 0,1%
Muestreo sencillo
Sólo flancos recesivos a dominantes
1 tq
2 tq
*Parámetro equivalente a RJW
De acuerdo a la recomendación DS-102, se implementa un par trenzado
blindado o no blindado terminado en ambos extremos con una impedancia
equivalente a la de la línea y tierra común, asimismo especifica el uso de
repetidores para incrementar el número de nodos en el bus. Es posible el
aislamiento galvánico de transceptores, sin convertidores DC/DC propios,
mediante una línea de fuente de alimentación común.
Existen dos conceptos básicos que indican cómo implementar la línea
de bus, línea de bus interconectada y línea de bus dividida, los cuales se
describen a continuación.
3.3.4.5.1.- LÍNEA DE BUS INTERCONECTADA
La línea de bus consiste de un número de secciones interconectadas
mediante dos opciones (Tabla 3.12):
•
Opción A: Se utiliza un conector tipo T 4 para interconectar las secciones
de línea de bus y el bus con el nodo.
•
Opción B: Los módulos electrónicos están equipados con dos
conectores para el bus, interconectando las secciones de línea de bus.
4
Un conector tipo T es un dispositivo pasivo que enlaza tres diferentes conectores
56
Tabla 3.12.- Línea de bus interconectada de acuerdo a la recomendación DS-102
Opción
A
Nodo
1 conector macho
Conector tipo T
Sección de línea de bus
1 conector macho y
2 conectores hembras
1 conector macho y 1
conector hembra
B
1 conector macho y
1 conector hembra
No requerido
1 conector macho y 1
conector hembra
3.3.4.5.2.- LÍNEA DE BUS NO DIVIDIDA
La línea de bus consiste de un sólo cable sin dispositivos
interconectados:
•
Nodo: Un conector macho.
•
Línea de bus: Un conector hembra por nodo, además un conector
hembra y un conector macho para terminación.
3.3.4.6.- RECOMENDACIONES DE CAPA FÍSICA POR LOS ESTÁNDARES HLP
La meta más importante que se intenta al estandarizar los protocolos de
capas altas (HLP, High Layer Protocol) y los perfiles de aplicación, tales como
CANopen, DeviceNet y SDS, es la interoperabilidad e intercambiabilidad de
dispositivos, lo cual asegura la compatibilidad total de las propiedades físicas
de los dispositivos y de la red. Por lo tanto, además de las características
básicas de la capa física definida en el estándar ISO 11898, se define:
topología de red, tipo de línea, tecnología de conexión, fuente de alimentación,
velocidad de transferencia de datos y transceptor.
3.3.4.6.1.- CANOPEN
CANopen permite la implementación de redes, hasta con 127 nodos,
cumpliendo con el estándar ISO 11898-2 y la recomendación DS-102. El
aislamiento galvánico de nodos es opcional y sólo se recomienda para buses
con longitudes mayores a 200m.
57
Todos los dispositivos CANopen deben dar soporte a la velocidad de
transferencia y a las longitudes de línea recomendadas en DS-102 (Tabla 3.10).
CANopen permite utilizar una fuente de alimentación común y recomienda el
uso de los siguientes conectores 5:
•
Conector DB9 (Tabla 3.2 y Figura 3.11).
•
Conector tipo mini (Tabla 3.3 y Figura 3.12).
•
Conector tipo micro (Tabla 3.4 y Figura 3.13).
•
Conector tipo nano (Tabla 3.5 y Figura 3.14).
•
Conector tipo abierto (Tabla 3.6 y Figura 3.15).
3.3.4.6.2.- DEVICENET
De la misma forma que CANopen, la especificación de capa física que
implementa DeviceNet es una extensión del estándar ISO 11898—2. DeviceNet
permite redes de hasta 64 nodos con topología de bus y sus líneas de bus
están terminadas en ambos extremos con una impedancia R t =121Ω +/- 1%.
DeviceNet define dos pares de cables, uno para la transmisión de la
señal y el otro para la fuente de alimentación. Se permiten tres tipos de cable
variantes en diámetro (grueso, delgado y plano), los cables grueso y plano se
utilizan en redes de longitud mayor a 100m y el cable delgado se utiliza en la
conexión del nodo al bus y en redes de longitudes menores a 100m
(Tabla 3.13). Es obligatorio el empleo del código de colores para hilos
individuales.
CANopen también define una serie de conectores adicionales los cuales son, en su mayoría,
de propósito general y de usos especiales; estos conectores se encuentran en el documento:
‘CANopen CiA Draft Recommendation 303’
5
58
Tabla 3.13.- Extensión de red y longitud de línea de extensión para DeviceNet
Velocidad de
transferencia
[Kbps]
500
250
125
Longitud de la línea principal [m]
Cable
grueso
100
250
500
Cable
delgado
100
100
100
Longitud máxima de la
línea de extensión [m]
Cable plano Acumulada
100
200
420
Individual
39
78
156
6
6
6
De acuerdo a la especificación de DeviceNet, el protocolo brinda
soporte a tres diferentes velocidades de transferencia de datos: 125, 250 y
500Kbps, además permite las conexiones del bus y los dispositivos
electrónicos pueden alimentarse de la fuente de voltaje común de 24V, se
recomienda el uso de cuatro tipos de conectores 6:
•
Conector tipo mini (Tabla 3.3 y Figura 3.12).
•
Conector tipo micro (Tabla 3.4 y Figura 3.13).
•
Conector tipo nano (Tabla 3.5 y Figura 3.14).
•
Conector tipo abierto (Tabla 3.6 y Figura 3.15).
La especificación de DeviceNet presenta ciertas recomendaciones en
cuanto a la protección de las conexiones. Opcionalmente la conexión al bus
puede aislarse galvánicamente y la corriente necesaria para alimentar a los
transceptores puede tomarse de la fuente de alimentación común.
3.3.4.6.3.- SDS
SDS describe una práctica recomendada para “autobauding”, en donde
la tasa de bit está establecido por el maestro, con la dirección más baja
posible, y todos los demás módulos comprobarán el tiempo de bits en el bus
para establecer su tasa de bits. Se recomiendan cuatro tasas de bits: 125, 250,
500 y 1000Kbps (Tabla 3.14).
DeviceNet adicionalmente recomienda el uso del conector tipo micro de 4 terminales
(conector M12 de 4-pines) para tomas auxiliares de energía
6
59
Tabla 3.14.- Velocidades de transferencia y longitudes de línea recomendadas para SDS
Velocidad de
transferencia [Kbps]
1000
500
250
125
Longitud de la línea
principal [m]
22,8
91,4
182,8
457,2
Longitud máxima de la
línea de extensión [m]
0,3
0,9
1,8
3,6
Dentro de las características de relacionadas con la capa física SDS se
encuentra que sólo soporta tramas CAN estándar y define el uso de tres tipos
de conectores 7:
•
Conector DB9 (Tabla 3.2 y Figura 3.11).
•
Conector tipo mini (Tabla 3.3 y Figura 3.12).
•
Conector tipo abierto (Tabla 3.6 y Figura 3.15).
3.4.- CAPA DE ENLACE DE DATOS (DLL)
En este apartado se describen los fundamentos y principios básicos de
la capa de enlace de datos (DLL, Data Link Layer), la cual se divide en dos
subcapas (Figura 3.22), las cuales se describen a continuación.
Figura 3.22.- Arquitectura de la capa de enlace de datos del protocolo CAN
SDS, a diferencia de DeviceNet, también recomienda el uso tipo micro de 4 terminales
(conector M12 de 4-pines) pero para extensiones de la línea del bus
7
60
3.4.1.- CONTROL DE ENLACE LÓGICO (LLC)
La subcapa de control de enlace lógico (LLC, Logic Link Control)
describe la parte alta de la capa DLL y define las tareas independientes del
método de acceso al medio, asimismo proporciona dos tipos de servicios de
transmisión sin conexión al usuario LLC:
•
Servicio de transmisión de datos sin reconocimiento: Proporciona al
usuario LLC los medios para intercambiar unidades de datos de servicio
de enlace (LSDU, Link Service Data Units) sin establecer una conexión
de enlace de datos. La transmisión de datos puede ser punto a punto,
multidifusión o difusión.
•
Servicio de petición de datos remota sin reconocimiento: Proporciona al
usuario LLC los medios para solicitar que un nodo remoto transmita sus
LDSUs sin establecer una conexión de enlace de datos.
De acuerdo con los tipos de servicios, se definen dos formatos de
tramas, de datos LLC y remota LLC. Ambos formatos definen identificadores
de 11 bits estándar (CAN 2.0A) y de 29 bits extendida (CAN 2.0B). La subcapa
LLC realiza las siguientes funciones:
•
Filtrar mensajes: El identificador de una trama no indica la dirección
destino pero define el contenido del mensaje, y mediante esta función
todo receptor activo en la red determina si el mensaje es relevante o no
para sus propósitos.
•
Notificar sobrecarga: Si las condiciones internas de un receptor
requieren un retraso en la transmisión de la siguiente trama de datos o
remota, la subcapa LLC transmite una trama de sobrecarga. Solamente
se pueden generar dos tramas de sobrecarga como máximo.
•
Gestión de recuperación: La subcapa LLC proporciona la capacidad de
61
retransmisión automática de tramas cuando una trama pierde el arbitraje
o presenta errores durante su transmisión, dicho servicio se confirma al
usuario hasta que la transmisión se completa con éxito.
3.4.2.- CONTROL DE ACCESO AL MEDIO (MAC)
El control de acceso al medio (MAC, Medium Access Control) de una red
CAN brinda soporte para procesamiento en tiempo real a todos los sistemas
que
la
integran.
El
intercambio
de
mensajes
que
demanda
dicho
procesamiento requiere de un sistema de transmisión a frecuencias altas y
retrasos mínimos. En redes multimaestro, la técnica de acceso al medio es muy
importante ya que todo nodo activo tiene los derechos para controlar la red y
acaparar sus recursos.
3.4.2.1.- ARBITRAJE DEL BUS
Para acceder al medio, los nodos CAN utilizan el mecanismo de arbitraje
que se describe a continuación:
•
Cuando un nodo necesita enviar información a través de una red CAN, la
capa de aplicación realiza una petición, de forma asíncrona, para
transmitir una trama. Puede ocurrir que varios nodos inicien el mismo
procedimiento simultáneamente generando una colisión en el bus, una
eventual colisión se resuelve asignando prioridades de cada mensaje
mediante un identificador; dicha asignación, que no puede modificarse
dinámicamente, se realiza durante el diseño del sistema en forma de
números binarios y se hace tomando en consideración que el
identificador con el menor número binario es el que tiene mayor
prioridad.
•
El método de acceso al medio utilizado es el CSMA/NBA, de acuerdo
62
con este método, los nodos en la red que necesiten transmitir
información deben esperar a que el bus esté libre (detección de
portadora); cuando se cumple esta condición, dichos nodos transmiten
un bit de inicio (acceso múltiple) y a continuación van comparando el
valor transmitido con el valor recibido bit a bit; mientras los valores sean
idénticos, los nodos continúan con la transmisión; si algún nodo detecta
una diferencia, deja de transmitir el nodo que tenga una menor prioridad
(arbitraje no destructivo bit a bit). Es decir que a pesar de que varios
nodos inicien la transmisión de sus tramas al mismo tiempo, el ganador
del arbitraje, el mensaje con la mayor prioridad, continúa con la
transmisión de su trama sin necesidad de retransmitirla desde el
principio.
•
Una vez finalizada la transmisión del mensaje más prioritario los demás
nodos volverán a intentar enviar el mensaje lo antes posible.
Para comenzar a explicar lo que sucede eléctricamente en el proceso de
arbitraje, se ha de tener en cuenta que la especificación CAN de Bosch no
establece cómo se ha de traducir cada nivel de bit (dominante o recesivo) a
variable física. Cuando se utiliza par trenzado según la norma ISO 11898 el
nivel dominante es una tensión diferencial positiva en el bus, mientras que el
nivel recesivo es ausencia de tensión o cierto valor negativo (los transceptores
no generan corriente sobre las resistencias de carga del bus). Definiendo el bit
dominante y bit recesivo en el bus de la siguiente manera:
•
El bit dominante representa un ‘0’ lógico.
•
El bit recesivo representa un ‘1’ lógico.
Se tiene que el arbitraje del bus CAN utiliza la función Wired-AND, la
cual tiene como consecuencia directa que: sólo en el caso que todos los nodos
63
de la red transmitan bits recesivos (1 lógico) el bus deberá pasar al estado
recesivo; mientras que si algún nodo transmite un bit dominante (0 lógico) el
bus pasa automáticamente a estado dominante. Es decir, que un bit recesivo
representa un estado de bus que puede ser sobrescrito por un bit dominante.
Considerando que más adelante se verá el significado de cada campo
detalladamente, podemos empezar a describir paso a paso el proceso de
arbitraje según la Tabla 3.15 y Figura 3.23. En el instante 1, se puede ver cómo
los tres nodos emiten un inicio de trama (SOF), que supone un aviso de que se
va a empezar a transmitir, a partir de aquí, los tres nodos empiezan a emitir sus
mensajes, es importante saber que durante la transferencia cada nodo va
comparando el nivel del bus con el nivel del bit que emitió, y mientras los bits
del campo de identificación del mensaje coincidan en los tres nodos, todos
siguen emitiendo; siguiendo la línea temporal, en el instante 2, el nodo 2
advierte que el nivel del bus es dominante, mientras que él había emitido un bit
recesivo, así pues, sabe que existe otro nodo que está transmitiendo un
mensaje más prioritario que él e inmediatamente deja de transmitir el mensaje
para conmutar a modo de recepción; finalmente, en el instante 3, el nodo 1
emite un bit recesivo y por lo tanto pierde el arbitraje, mientras que el nodo 3
es el que ha tomado el control sobre el bus, y por ende, el que transmitirá el
mensaje.
Tabla 3.15.- Representación bit a bit del arbitraje en el bus CAN
Nodo 1
Nodo 2
Nodo 3
Nivel del bus
S
O
F
0
0
0
0
Identificador
10
9
8
7
6
5
4
3
2
1
0
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
1
1
1
1
0
1
0
0
1
1
1
1
1
1
1
0
0
0
0
1
1
R
T
R
0
0
64
Figura 3.23.- Arbitraje del bus CAN
Otro aspecto a considerar, es que podría darse el caso de que se inicia
simultáneamente la transmisión, con un mismo identificador, de una trama de
datos (enviada por el nodo) y una trama remota (solicitada por un receptor) en
donde el proceso de arbitraje no puede resolverse únicamente con el
identificador de la trama, sino que tiene que utilizarse el bit de petición de
transmisión remota (RTR) el cual se transmite como recesivo en caso de
tratarse de una trama remota y como dominante en caso de tratarse de una
trama de datos; por ende, las tramas de datos tienen prioridad por sobre las
tramas remotas.
Este sistema de arbitraje tiene dos consecuencias directas: en primer
lugar, como ya se ha mencionado, limita la longitud máxima del bus en función
de la velocidad y del número de nodos presentes en la red, pues el tiempo de
transmisión de un bit debe ser lo suficientemente largo como para permitir su
decodificación por todas las estaciones de la red, ya que a mayor velocidad de
la red, menor longitud de bus (Tabla 3.1 y Figura 3.8); por otra parte, obliga a
65
que todos los mensajes posean un identificador único, que es el que establece
su prioridad.
3.4.2.2.- TRANSMISIÓN DE MENSAJES
CAN establece dos formatos de tramas que difieren en la longitud del
campo del identificador, las tramas estándares con un identificador de 11 bits
definidas en la especificación CAN 2.0A, y las tramas extendidas con un
identificador de 29 bits definidas en la especificación CAN 2.0B. Tanto las
tramas de datos como las remotas se separan de tramas precedentes
mediante espacios entre tramas. Para la transmisión y control de mensajes
CAN, se definen cuatro tipos de tramas:
•
Trama de datos: Lleva los datos de un transmisor a los receptores.
•
Trama remota: Es transmitida por un nodo para solicitar la transmisión
de la trama de datos con el mismo identificador.
•
Trama de error: Se transmite a través de cualquier unidad al detectar un
error del bus.
•
Trama de sobrecarga: Se utiliza para que un receptor solicite un retraso
en la transmisión de la trama siguiente.
3.4.2.2.1.- TRAMA DE DATOS
La trama de datos transporta información desde los transmisores hacia
los receptores, siendo el tipo de trama más utilizada. Una trama de datos se
compone de siete campos: inicio de trama, campo de arbitraje, campo de
control, campo de datos, campo CRC, campo de aceptación y fin de trama
(Figura 3.24). La longitud del campo de datos puede ser cero.
66
Figura 3.24.- Formato de una trama de datos
•
Inicio de trama: Este campo indica el inicio de una trama de datos o una
trama remota y sólo se puede enviar cuando el bus está libre. El bit de
inicio de trama (SOF, Start of Frame) consiste en un bit dominante que
sincroniza a todos los nodos activos en la red y es el mismo para la
trama estándar y extendida.
•
Campo de arbitraje: Este campo determina la prioridad de un mensaje
cuando dos o más nodos se encuentran en contienda para el acceso al
bus de comunicaciones y difiere según el formato de trama
(Figura 3.25).
Figura 3.25.- Campo de arbitraje, trama estándar y extendida

En el formato estándar está constituido por un identificador de 11
bits y el bit de petición de transmisión remota (RTR, Remote
Transmission Request). Si denotamos los bits del identificador como
ID-10 … ID-0, se tiene que el bit menos significativo del identificador
se transmite al último (ID-0) y que los siete bits más significativos no
67
pueden ser todos recesivos (ID-10 … ID-4).

En el formato extendido está formado por un identificador de 29 bits,
el bit de petición remota substituta (SRR, Substitute Remote
Request), el bit de extensión del identificador (IDE, Identifier
Extension) y el bit RTR. Si denotamos los bits del identificador como
ID-28 … ID-0, se tiene que el identificador se divide en dos
secciones: la primera sección consta de 11 bits (ID-28 … ID-18) y se
denomina identificador base, el cual es equivalente al identificador
del formato estándar; y la segunda sección consta de 18 bits
(ID-17 … ID-0) y es conocida como identificador extendido.
El bit RTR debe ser dominante para ambos formatos de trama de datos;
el bit SRR, que sustituye al bit RTR en el formato extendido ya que
ocupa la misma posición, debe transmitirse como recesivo aunque los
receptores deben ser capaces de aceptar bits tanto dominantes como
recesivos; y finalmente el bit IDE, el cual pertenece al campo de arbitraje
en el caso de un formato de trama extendida y se encuentra en el campo
de control para el caso de un formato de trama estándar, debe
transmitirse como dominante para el formato estándar y recesivo para el
extendido, por lo tanto, las posibles colisiones entre ambos tipos de
formatos de trama que tengan el mismo valor en el campo de
identificación base se resuelven de manera que el formato de trama
estándar predomina sobre el formato de trama extendida.
•
Campo de control: Este campo está compuesto de seis bits: IDE/r1, r0 y
cuatro bits que forman el código de longitud de datos (DLC, Data Length
Code). El formato del campo de control es diferente para el formato
estándar y extendido (Figura 3.26).
68
Figura 3.26.- Campo de control

En el formato estándar el primer bit del campo de control,
correspondiente al bit IDE, debe ser dominante.

En el formato extendido el primer bit del campo de control,
correspondiente al bit r1, debe transmitirse como dominante aunque
los receptores deben ser capaces de aceptar bits tanto dominantes
como recesivos.
El bit r0, reservado para futuras aplicaciones, debe transmitirse como
dominante para ambos formatos de trama de datos aunque los
receptores deben ser capaces de aceptar bits tanto dominantes como
recesivos; y finalmente los bits DLC, que indican el número de octetos
(de cero a ocho) que contendrá el campo de datos, toma las primeras
nueve combinaciones de las dieciséis posibles, por ende, las
combinaciones restantes no se consideran permitidas.
•
Campo de datos: Este campo contiene el mensaje a transmitir dentro de
una trama CAN, puede tener una longitud de cero a ocho octetos y se
envían primero los bits más significativos. Si denotamos los bits que
forman el código de longitud de datos como DLC-3 … DLC-0, se tiene
que los valores admisibles para el campo de datos están contenidos en
la Tabla 3.16. Los DLC’s en el rango de cero a siete indican la misma
69
longitud en bytes del campo de datos, mientras que todas las otras
combinaciones posibles indican que el campo de datos es de ocho
bytes.
Tabla 3.16.- Codificación de los bits DLC según la longitud de los datos
Código de longitud de datos
DLC-3 DLC-2 DLC-1 DLC-0
0
0
0
0
0
0
0
1
0
0
1
0
0
0
1
1
0
1
0
0
0
1
0
1
0
1
1
0
0
1
1
1
1
0o1
0o1
0o1
•
Número de
bytes de datos
0
1
2
3
4
5
6
7
8
Campo CRC: Este campo está constituido por una secuencia CRC de
15 bits seguido por un delimitador CRC de 1 bit, que se transmite en
estado recesivo (Figura 3.27). La secuencia de verificación de 15 bits
usada en el protocolo CAN se basa en el código BHC 8 cuyo generador
polinomial, dado por X15+X14+X10+X8+X7+X4+X3+1, se aplica una trama
que no tenga implementado el proceso de inserción de bits (destuffed
bits) e incluye los siguientes coeficientes para su cálculo: inicio de trama,
campo de arbitraje, campo de control y campo de datos (si existe). La
finalidad de este campo consiste en que los receptores sean capaces de
verificar si la secuencia de bits recibida fue alterada.
Figura 3.27.- Campo CRC
•
8
Campo de aceptación: Este campo está constituido por una ranura de
Un código cíclico bien especializado para las longitudes de trama menores a 127 bits
70
aceptación y delimitador de aceptación (Figura 3.28). Los bits de
aceptación (ACK, Acknowledge) en los nodos transmisores se emiten
ambos en estado recesivo; mientras que en los nodos receptores se
sobrescribe la ranura de aceptación con un bit en estado dominante
para confirmar que el mensaje se ha recibido sin errores, si no existe
dicha confirmación se asume que el mensaje llegó con errores.
Figura 3.28.- Campo de aceptación
•
Fin de trama: Este campo consiste de una secuencia de siete bits en
estado recesivo, esta bandera especial es utilizada para delimitar el fin
de las tramas de datos y remotas. Cuando los bits de fin de trama (EOF,
End of Frame) están activos se realiza una violación al procedimiento de
inserción de bit, por ello dicho procedimiento no se aplica a este campo.
3.4.2.2.2.- TRAMA REMOTA
La trama remota es utilizada por un nodo (receptor) para solicitar la
transmisión de una trama de datos a otro nodo (transmisor) que posea el
mismo identificador. Una trama remota se compone de seis campos: inicio de
trama, campo de arbitraje, campo de control, campo CRC, campo de
aceptación y fin de trama (Figura 3.29). Como se puede apreciar los campos
de una trama remota son los mismos que los de una trama de datos, con las
siguientes excepciones: el bit RTR es recesivo; y no contiene el campo de
datos, independientemente si el valor de los bits DLC esté dentro del rango
admisible (cero a ocho bytes). En las tramas remotas el valor de los bits DLC
cumple con la finalidad de contener la longitud del campo de datos que se
71
espera recibir y, por ende, debe coincidir con el valor que el transmisor enviará
posteriormente.
Figura 3.29.- Formato de una trama remota
3.4.2.2.3.- TRAMA DE ERROR
La trama de error señaliza la detección de cualquier error durante la
transmisión o recepción de una trama de datos o remota, la cual viola el
procedimiento de inserción de bit y ocasiona que el transmisor reenvíe la
trama. Asimismo la detección de un error, durante la transmisión o recepción
de una trama de sobrecarga o error, genera la transmisión de una nueva trama
de error. La trama de error está formada por dos campos (Figura 3.30):
Figura 3.30.- Formato de una trama de error
•
Bandera de error: Existen dos formas de representar una bandera de
error:

Bandera de error activo: Consiste en seis bits dominantes
72
consecutivos.

Bandera de error pasivo: Está formada por seis bits recesivos
consecutivos, a menos que sean sobrescritos por bits dominantes de
otros nodos.
•
Delimitador de error: Una trama de error termina con una secuencia de
ocho bits recesivos. Posterior a la transmisión de una bandera de error,
el nodo transmite bits recesivos y verifica el nivel del bus hasta que
reconozca un bit recesivo, entonces comienza la transmisión de otros
siete bits recesivos. Con este mecanismo, el nodo puede determinar si
fue el primero en transmitir una bandera de error y con ello detectar una
condición de error.
3.4.2.2.4.- TRAMA DE SOBRECARGA
La trama de sobrecarga se utiliza para que un receptor solicite un
retraso en la transmisión de la trama siguiente, ya sea de datos o remota, o
para señalizar condiciones de error relacionadas con el campo de intermisión.
El protocolo CAN permite la generación de dos tramas de sobrecarga como
máximo para retrasar la transmisión de la siguiente trama. Las tramas de
sobrecarga se transmiten después de detectar las siguientes condiciones de
error:
•
Detección de un bit dominante durante los primeros dos bits del campo
de intermisión. La detección de un bit dominante en el tercer bit del
campo de intermisión se interpreta como un SOF.
•
Cuando un receptor detecta un bit dominante en el último bit del campo
EOF; o cuando un nodo, receptor o transmisor, detecta un bit dominante
en el último bit del delimitador de una trama de error o de sobrecarga.
73
Una trama de sobrecarga se considera una forma especial de trama de
error y consta de los siguientes campos (Figura 3.31):
Figura 3.31.- Formato de una trama de sobrecarga
•
Bandera de sobrecarga: Se constituye por seis bits dominantes. La
forma completa corresponde a la bandera de error activa.
•
Delimitador de sobrecarga: Está formado por ocho bits recesivos.
3.4.2.2.5.- ESPACIO ENTRE TRAMAS
Las tramas de datos y remotas están separadas de tramas precedentes
por un espacio entre tramas, a diferencia de las tramas de error y de
sobrecarga que se transmiten en forma sucesiva, es decir sin un espacio entre
tramas. El espacio entre tramas está formado por tres campos:
•
Intermisión: Consiste en tres bits recesivos. Durante su transmisión la
única acción que puede realizarse es señalar una condición de
sobrecarga, y no se permite que ningún nodo inicie la transmisión de
una trama de datos o remota.
•
Bus libre: Este periodo es de longitud arbitraria y tiene un nivel recesivo
hasta que algún nodo inicie la transmisión de una nueva trama.
•
Suspender transmisión: Adicionalmente, el espacio entre tramas
contiene un tiempo de inhibición de transmisión de ocho bits para nodos
que se encuentren en estado de error pasivo.
74
3.4.2.3.- CODIFICACIÓN DE TRAMAS
En una trama CAN, de datos o remota, la codificación NRZ junto con el
procedimiento de inserción de bit se aplican al: inicio de trama, campo de
arbitraje, campo de control, campo de datos 9, secuencia CRC. Los segmentos
restantes: delimitador CRC, campo de aceptación y fin de trama, tienen un
formato fijo y son transmitidos sin emplear el procedimiento de inserción de bit,
de igual forma, las tramas de error y de sobrecarga tienen un formato fijo y no
se codifican por dicho procedimiento.
3.4.2.4.- VALIDACIÓN DE TRAMAS
El instante de tiempo en el que se valida una trama difiere según:
•
Transmisor: La trama es válida si no existen errores hasta el final del
campo EOF. Si existe un error, en la trama se activa el proceso de
recuperación.
•
Receptor: La trama es válida si no existen errores hasta el siguiente bit
después del campo EOF.
3.4.2.5.- DETECCIÓN Y MANEJO DE ERRORES
Un controlador CAN cuenta con la capacidad de detectar y manejar los
errores que surjan en una red. Todo error detectado por un nodo, se notifica
inmediatamente al resto de los nodos. Un nodo puede tener una alteración
local permanente, lo que provoca el envío continuo de tramas de error. Para
prevenir dicho comportamiento, el protocolo CAN describe un algoritmo,
basado en la actividad del bus, que obliga a los nodos con errores
permanentes a desconectarse de la red, y que los demás nodos no sean
perturbados por los nodos defectuosos.
9
El campo de datos no se incluye en una trama remota
75
3.4.2.5.1.- MECANISMOS DE DETECCIÓN DE ERRORES
Para cumplir con las demandas relativas a la seguridad en la transmisión
de datos, el protocolo CAN define los siguientes mecanismos para detección
de errores:
•
Monitoreo de bits: Todo nodo verifica que el nivel del bus transmitido
sea el mismo nivel en el bus, y cuando dichos valores difieren se detecta
un error de bit. El monitoreo de bits representa un mecanismo de
seguridad global para la detección de todos los errores efectivos.
•
Verificación del procedimiento de inserción de bit: Hace referencia al
hecho de detectar un error de inserción de bit cuando ocurren seis
niveles consecutivos de bits con el mismo valor en un campo de trama
codificado por el procedimiento de inserción de bit.
•
Verificación de redundancia cíclica de 15 bits: Se presenta un error de
CRC cuando la secuencia CRC recibida no corresponde con la
secuencia CRC calculada.
•
Verificación de trama: Detecta un error cuando un campo de bit de
formato fijo contiene uno o más bits no válidos.
•
Verificación de aceptación: Un transmisor detecta un error de
aceptación cuando la ranura ACK no cambia a estado dominante.
3.4.2.5.2.- MANEJO DE ERRORES
Cuando un nodo detecta algún tipo de error, de bit, de inserción de bit,
de forma o de aceptación, inicia la transmisión de una bandera de error en el
siguiente bit. Cuando se detecta un error de CRC, se inicia la transmisión de
una trama de error después del delimitador ACK, a excepción de que
previamente se haya transmitido otra trama de error. El manejo de errores se
lleva a cabo de acuerdo con el diagrama de flujo de la Figura 3.32.
76
Figura 3.32.- Diagrama de flujo para el manejo de errores
3.4.2.5.3.- CAPACIDAD DE DETECCIÓN DE ERRORES
Los protocolos de comunicaciones de bus seriales emplean diferentes
mecanismos de detección de error, los cuales proporcionan al receptor la
capacidad de detectar si la trama recibida es errónea o no. Por otro lado, la
capacidad de detectar errores de transmisión depende de los mecanismos de
error y del protocolo utilizado.
Para valorar la integridad de los datos en un sistema de transmisión se
deben considerar las interferencias electromagnéticas y la capacidad para
detectar errores de transmisión. En un sistema de transmisión de datos existe
una medida estadística que representa la integridad de datos transferidos
conocida como probabilidad de error residual, la cual especifica la probabilidad
de que existan tramas erróneas sin detectar y está dada por la Ecuación 3.7.
77
Probabilidad de error residual
< (4,7 × 10−11 ) × (velocidad de error de trama)
[3. 7]
La cual define el número de errores de transmisión sin detectar durante
el tiempo de operación de una red CAN, que puede ser estimado por la
velocidad de error de trama, el porcentaje de carga del bus, la velocidad de
transferencia de datos y la longitud de la trama.
La mayoría de errores de transmisión son debido a interferencias
electromagnéticas. La susceptibilidad de error de un sistema de transmisión de
datos se puede caracterizar mediante parámetros estadísticos tales como la
velocidad de error de trama y la probabilidad de error de bit. La velocidad de
error está dada por la relación entre el número de tramas erróneas y el número
total de tramas transmitidas durante un periodo de tiempo, con lo cual se
describe la probabilidad de que exista una trama errónea, por otro lado, la
probabilidad de error de bit especifica la probabilidad de que exista un bit
erróneo en una trama transmitida.
Los errores de transmisión no ocurren en todos los nodos de una red,
sino que aparecen en nodos individuales con diversos patrones de error. El
protocolo CAN tiene la capacidad de señalizar los errores detectados mediante
la transmisión de una bandera de error, sin embargo existe la posibilidad de no
detectar errores locales cuando se cumplen las siguientes condiciones en la
distribución del error de bit:
•
El nodo que transmite funciona adecuadamente, y puede detectar un
error al monitorear el bit y señalizarlo a todo el sistema.
•
Cuando todos los nodos receptores que reciben una trama errónea
detectan un patrón de error no definido (indetectable). Debido a que
78
estos patrones son muy raros, todos los nodos que recibieron la trama
errónea deben mostrar un patrón de error idéntico. Esta condición es
cada vez más improbable en un sistema distribuido con un gran número
de nodos.
La DLL del protocolo de comunicaciones CAN garantiza un alto grado
de detección de errores. Todos los errores se detectan mediante el proceso de
monitoreo de bit realizado por el transmisor de la trama, mediante dicho
proceso el transmisor puede detectar errores ocasionados a nivel global por
interferencia electromagnética, la cual aparece en todos los nodos, y además
tiene la capacidad de detectar errores locales.
Los errores que sólo ocurren localmente, en receptores individuales, se
detectan mediante la verificación de la secuencia CRC de 15 bits, realizada por
el mismo receptor.
3.5.- DESCRIPCIÓN DE LA SUPERVISIÓN
La sustitución del cableado convencional por un sistema de bus serie
presenta el problema de que un nodo defectuoso puede bloquear el
funcionamiento del sistema completo. Como se ha descrito con anterioridad,
cada nodo activo transmite una bandera de error cuando detecta algún tipo de
error (principio de señalización de errores) y puede ocasionar que un nodo
defectuoso pueda acaparar el medio físico, para eliminar este riesgo el
protocolo CAN define un mecanismo autónomo para detectar y desconectar un
nodo defectuoso del bus, dicho mecanismo se conoce como aislamiento de
fallos.
El objetivo del aislamiento de fallos es preservar la disponibilidad del
sistema de transmisión de datos, incluso en el caso de que existan nodos
79
defectuosos, para ello se definen estrategias que incrementan la seguridad en
los siguientes aspectos:
•
Distinguir entre errores temporales y fallas permanentes.
•
Localizar y desconectar nodos defectuosos.
Por ello, cada nodo tiene un contador de errores de transmisión (TEC,
Transmit Error Counter) y un contador de errores de recepción (REC, Receive
Error Counter) para registrar el número de errores respectivamente. Si las
tramas se transmiten y reciben correctamente, dichos contadores decrementan
sus valores, y en caso de ocurrir errores, los contadores se incrementan en
proporciones mayores a los que se decrementan.
Los contadores incrementan o decrementan sus valores dependiendo
de la relación existente entre las tramas enviadas y recibidas correctamente y
aquellas con errores. Los valores en los contadores indican la frecuencia
relativa de perturbaciones previas. El comportamiento de los nodos se modifica
en relación a los errores, dependiendo de los valores del contador
correspondiente un nodo puede estar en uno de los siguientes estados
(Figura 3.33):
•
Error activo: Un nodo toma parte en la comunicación de bus y cuando
detecta un error envía una bandera de error activo; destruye la trama
que transmitía, viola el procedimiento de inserción de bit y previene con
ello a los demás nodos de la presencia de una trama errónea.
•
Error pasivo: Un nodo no puede enviar una bandera de error activo pero
aún toma parte en la comunicación del bus; cuando detecta un error,
sólo puede enviar una bandera de error pasivo, la cual no interfiere en la
comunicación del bus.
•
Desconectado: En este estado, un nodo no tiene ninguna influencia en el
80
bus y por ello no puede transmitir tramas, aceptación ACK, tramas de
error o de sobrecarga.
Figura 3.33.- Diagrama de estados de error de un nodo CAN
3.6.- CAPA DE APLICACIÓN
CAN se utiliza en aplicaciones en las que no está determinada una
estructura de capas entre el nivel de enlace proporcionado por el controlador
de protocolo y la aplicación en el nodo. Actualmente, con la implementación de
sistemas distribuidos basados en CAN han surgido nuevos requerimientos que
no han sido considerados en el estándar ISO 11898-2, siendo los más
importantes:
•
Disponibilidad de servicios de transmisión para bloques de datos
mayores a 8 octetos.
•
Soporte al modelo cliente/servidor.
•
Funciones dedicadas a la gestión de red.
•
Métodos para asignar identificadores de mensaje y configuración de
parámetros específicos del nodo, de forma transparente al usuario.
•
Interoperabilidad e intercambio de dispositivos de diferentes fabricantes.
•
Estandarizar la funcionalidad y definir nuevos perfiles para dispositivos.
81
La necesidad de estandarizar las capas de aplicación ha surgido sobre
todo en el sector de los buses de campo industriales, donde la comunicación
entre dispositivos de diferentes fabricantes es una característica fundamental.
Respecto al protocolo CAN, existen diferentes estándares que definen
su capa de aplicación; algunos son muy específicos y están relacionados con
sus campos de aplicación. Entre las capas de aplicación más utilizadas cabe
mencionar las siguientes:
•
CAL: Define un amplio conjunto de funciones para la comunicación y
gestión de una red CAN.
•
CANopen: Protocolo de ámbito Europeo desarrollado Bosch y
respaldado por CiA. Utiliza parte de CAL y le agrega nuevos perfiles de
protocolo y dispositivos.
•
DeviceNet: Desarrollado por la firma Rockwell Automation con mayor
utilización en EE.UU. Es un enlace de bajo costo que conecta
dispositivos industriales a una red CAN.
•
SDS (Smart Distributed System): Sistema de bus desarrollado por la
firma Honeywell para la interconexión de sensores y actuadores
inteligentes.
•
OSEK/VDX (Offene Systeme und deren schnittstellen für die Elektronik im
Kraftfahrzeug 10/Vehicle Distributed eXecutive): Desarrollado por la firma
Siemens como resultado de la cooperación entre fabricantes de
automóviles alemanes para desarrollar una arquitectura abierta para
unidades de control distribuido.
•
CANKingdom: Desarrollado por la firma Kvaser y compatible con
DeviceNet, protocolo reconocido a nivel mundial en el control de
Su traducción del alemán al español vendría a ser: Sistemas abiertos y sus interfaces para la
electrónica en automóviles
10
82
maquinaria.
3.6.1.- CAL
La organización CiA estandarizó el protocolo de comunicaciones CAL
con la finalidad de facilitar las implementaciones de sistemas abiertos de redes
CAN en aplicaciones de control industrial. CAL se considera la única
implementación independiente dedicada exclusivamente a la capa de
aplicación en redes CAN. La funcionalidad de CAL consiste en cuatro
elementos de servicio:
•
Especificación de mensajes basada en CAN (CMS, CAN based Message
Specification):
Proporciona
los
medios
para
la
descripción
e
implementación de una comunicación orientada a objetos. Contiene
distintos tipos de datos estructurados y diferentes objetos de
comunicación con características de transmisión. Mediante reglas de
codificación, especifica un formato de datos común para todos los
mensajes de la red.
•
Gestión de la red (NMT, Network Management): Asegura un inicio
ordenado de toda la red y contiene las medidas de precaución
necesarias para la supervisión e intercambio/inserción de nodos en
tiempo de ejecución.
•
Distribuidor de identificadores (DBT, Identifier Distributor): Se encarga de
la asignación dinámica de identificadores y trabaja en conjunto con el
servicio NMT.
•
Gestión de capa (LMT, Layer Management): Se encarga de la
configuración y parametrización de CAL a través de la red.
83
Los elementos anteriores se pueden configurar para diseñar sistemas
con diferentes capacidades y requerimientos. En la Figura 3.34 se muestra la
arquitectura de un sistema basado en CAL.
Figura 3.34.- Arquitectura general de un sistema basado en CAL
3.6.2.- CANOPEN
CANopen es un estándar de comunicaciones y dispositivos basados en
CAL desarrollado por un consorcio liderado por Bosch y apoyado por la
organización CiA. Inicialmente se desarrolló como una red empotrada de
configuración flexible y con apoyo de CiA logró su estandarización para
utilizarse en sistemas distribuidos de automatización industrial. En Europa se
considera el estándar de facto para la implementación de sistemas industriales
basados en CAN, y sus campos de aplicación son: equipo médico, vehículos
para terreno especiales, electrónica marítima, transporte público, domótica,
etc.
CANopen está integrado por un perfil de comunicaciones que especifica
y define los mecanismos de comunicación. Los perfiles de dispositivos
describen a los dispositivos utilizados en la tecnología de automatización
84
industrial tales como módulos de E/S analógicos y digitales, controladores,
unidades de interfaz hombre, codificadores, etc. El perfil de dispositivo define
la funcionalidad de un dispositivo en particular.
La principal característica de CANopen es la descripción funcional de
parámetros, y datos de un dispositivo, la cual se encuentra en un diccionario
de objetos (OD, Object Dictionary). La funcionalidad y características de un
dispositivo CANopen se definen en una hoja de datos electrónica (EDS,
Electronic Data Sheet) estandarizada en formato ASCII.
De forma similar a otros buses de campo, CANopen define dos
mecanismos básicos de transmisión:
•
El intercambio crítico en tiempo real de datos de proceso mediante
objetos de proceso (PDO, Process Data Object).
•
El acceso en tiempo crítico a las entradas del diccionario de objetos
mediante objetos de servicio (SDO, Service Data Object).
La Tabla 3.17 muestra las ventajas y características, mientras que la
Figura 3.35 muestra la arquitectura general de un sistema CANopen.
Tabla 3.17.- Ventajas y características de CANopen
Ventajas
Permite la interoperabilidad entre
diferentes dispositivos
Capacidad de respuesta en tiempo real
Modular, cubre dispositivos desde
simples a complejos
Amigable con el usuario, disponibilidad
de herramientas
Protocolo abierto e independiente del
vendedor, estandarizado como
EN 50325-4
Características
Configuración automática de la red
Fácil acceso a todos los parámetros del
dispositivo
Sincronización de dispositivos
Transmisión de datos controlada por
eventos y cíclica
Lectura sincrónica de configuración de
entradas, salidas o parámetros
85
Figura 3.35.- Arquitectura general de un sistema basado en CANopen
3.6.3.- DEVICENET
DeviceNet es un protocolo desarrollado por la firma Rockwell
Automation 11 y publicado como un estándar de bus de campo abierto,
actualmente desempeña un papel importante en la industria de los EE.UU. y
Asia, y en Europa se extiende cada vez más. DeviceNet es un protocolo
basado en CAN: simple, de bajo costo y eficiente que fue diseñado para el
nivel más bajo de los buses de campo, por ejemplo sensores y actuadores, y
unidades de control asociadas.
DeviceNet es una de las tres redes abiertas (DeviceNet, ControlNet, y
Ethernet/IP) que utilizan el protocolo de control e información (CIP, Control and
Information Protocol). El CIP es un protocolo de comunicaciones común y sus
La firma Rockwell Automation escribió la especificación original DeviceNet. En Europa
DeviceNet forma parte de la norma EN 50325-2 y se incluye en el estándar internacional
IEC 62026-3
11
86
interfaces hardware/software permiten la conexión de dispositivos industriales
a Internet mediante dos tipos de mensajes:
•
Control: Se utiliza para control de las E/S en tiempo real o mensajes
implícitos.
•
Información: Está dedicado al intercambio de mensajes o mensajes
explícitos.
Ambos tipos de mensajes están destinados el área de control industrial y
proporcionan las siguientes características:
•
Servicios de control común.
•
Servicios de comunicación común.
•
Capacidades de encaminamiento común.
•
Base de conocimiento común.
La especificación de DeviceNet define parte de la capa física y el medio
de transmisión. La Figura 3.36 muestra la arquitectura de protocolos de
DeviceNet.
Figura 3.36.- Arquitectura de protocolos DeviceNet
3.6.4.- SDS
Impulsado por la firma Honeywell, SDS es un sistema de bus basado en
CAN para la conexión de sensores y actuadores inteligentes. SDS implementa
87
un protocolo de capa de aplicación diseñado para cumplir los requerimientos
establecidos en la automatización industrial, como son: velocidad de
transferencia de datos, confiabilidad, flexibilidad, etc. Algunas de sus
principales características son la utilización de métodos de detección y
corrección de errores, y confiabilidad en el reconocimiento de mensajes.
El protocolo de capa de aplicación SDS proporciona un conjunto de
mensajes que abarca desde mensajes de cambio de estado controlados por
eventos, hasta
operaciones
complejas
transportando valores
binarios,
analógicos y alfanuméricos.
La arquitectura del protocolo de capa de aplicación SDS se basa en el
modelo OSI, utiliza los servicios que proporciona la capa de enlace de datos
CAN y debe implementar una capa física compatible con CAN (Figura 3.37).
Figura 3.37.- Arquitectura de protocolos SDS
3.6.5.- OSEK/VDX
OSEK/VDX es un proyecto común de la industria automotriz alemana
liderado por Siemens, su objetivo es obtener una arquitectura abierta
estandarizada para las unidades de control distribuidas en vehículos.
88
OSEK/VDX introduce una arquitectura abierta que comprende tres áreas
(Figura 3.38):
•
Comunicación: Proporciona servicios para el intercambio de datos entre
tareas y/o rutinas de servicio de interrupción (ISR, Interrupt Service
Routine), comunicación interna de una ECU, y externa entre diferentes
ECUs; el acceso a los servicios de comunicación OSEK se realiza
mediante interfaces de programación de la aplicación específica (API,
Application Program Interface).
•
Gestión de red: Define un conjunto de servicios para determinar y
supervisar
la
configuración
del
nodo.
Debe
adaptarse
a
los
requerimientos específicos del sistema de bus utilizado (métodos
globales) o a los recursos de cada nodo (métodos locales).
•
Sistema operativo: Las aplicaciones automotrices se caracterizan por
tener requerimientos de tiempo real rigurosos. El OS de OSEK
proporciona la funcionalidad necesaria para dar soporte a sistemas de
control manejados por eventos. Los servicios especificados por el OS
constituyen una base para hacer posible la integración de módulos
software realizados por distintos fabricantes.
89
Figura 3.38.- Arquitectura OSEK/VDX
3.6.6.- CAN KINGDOM
CAN Kingdom fue desarrollado por la empresa sueca Kvaser
específicamente para aplicaciones de control de maquinaria que requieren un
desempeño en tiempo real, los demás protocolos están enfocados a la
automatización industrial.
CAN Kingdom es un conjunto de primitivas del protocolo basado en
CAN y es una herramienta que el diseñador de sistemas puede utilizar para
diseñar y optimizar HLPs. Propone una filosofía para el desarrollo de máquinas
basada en comprensibilidad, seguridad, simplicidad y efectividad.
El desarrollo de un sistema CAN Kingdom sigue el principio de que los
módulos deben servir a la red y como consecuencia todo nodo en la red tiene
la información necesaria para inicializar el sistema.
CAN Kingdom describe un sistema como si fuera un país, un reino, con
su respectiva capital y ciudades. El rey gobierna al reino desde la capital, y
cada ciudad tiene un alcalde responsable del gobierno local. El único medio
para comunicarse dentro de la ciudad es el correo. La red CAN se describe
90
como el sistema postal real, cada ciudad tiene una oficina de correos y un
director de correos el cual simboliza a un controlador CAN (Figura 3.39).
Figura 3.39.- Representación de una red CAN con CAN Kingdom
Cada ciudad produce algo y puede importar o exportar información por
correo. El alcalde de la ciudad organiza cualquier información de importación o
exportación dentro de listas, dichas listas forman parte de la documentación
del módulo. El diseñador de sistemas elige los módulos específicos que se
utilizarán en su máquina, y para ello debe conocer completamente las listas.
Asimismo el diseñador crea un protocolo optimizado para su máquina, al
asignar identificadores a las variables que estén en dicha lista.
91
CAPÍTULO 4.- REFERENCIAS PARA LA UTILIZACIÓN DEL KIT
DE DESARROLLO CAN
El propósito de este capítulo es describir los componentes de software y
de hardware necesarios para la utilización del kit de desarrollo. Para realizar lo
anteriormente expuesto, se detallan los procedimientos de programación y
creación de aplicaciones para el sistema.
4.1.- DESCRIPCIÓN DEL HARDWARE
Cada kit de desarrollo incluye dos placas: una tarjeta de demostración
C51 (C51 Demo Board) y una tarjeta de extensión CAN (CAN Extension Board)
dedicada a los dispositivos CAN las cuales se interconectan, como se aprecia
en la Figura 4.1.
Figura 4.1.- Tarjeta de demostración C51 conectada a la tarjeta de extensión CAN
Todas las características proporcionadas por la tarjeta de demostración
C51 que pueden utilizarse para fines didácticos son:
•
Pantalla LCD.
92
•
Barra de LED’s.
•
Puerto RS-232.
•
Interruptor de encendido/apagado.
•
Botón de reinicio.
•
Botón de interrupción.
•
Capacidad de hardware para programar los microcontroladores CAN en
el chip de memoria flash.
La tarjeta de extensión CAN para los microcontroladores Atmel
T89C51CC0x tiene las siguientes características:
•
Zócalo PLCC44
para instalar un microcontrolador Atmel del mismo
formato.
•
Transceptor CAN Atmel ATA6660.
•
Dos tomas diferentes para transceptor: DIL8 y SO8.
•
Conectores D-sub (DE-9) conformes a la CiA de la recomendación para
la alta velocidad de bus CAN.
•
Conector ADC para la tensión de referencia VAGND y VAREF del
conversor análogo a digital.
En la Tabla 4.1 muestra un listado de las características más
importantes del kit de desarrollo.
93
Tabla 4.1.- Características del kit de desarrollo para los microcontroladores Atmel
T89C51CC0x
Características del kit de desarrollo
Arquitectura del microcontrolador
Intel 8051
Memoria FLASH interna
32k Bytes
Memoria FLASH interna para el Bootloader 2k Bytes
Memoria EEPROM interna
2k Bytes
Memoria RAM interna
256 Bytes
Memoria XRAM interna
1k Byte
Controlador CAN
15 message objects
Programación del sistema
UART / CAN
Puertos
4 puertos (0/1/2/3)
Temporizadores
3 temporizadores de 16-bit (0/1/2)
Conversor análogo a digital
8 canales de 10 bit
Arreglo de contador programable
5 canales de 16 bit
Frecuencia de trabajo
12MHz
Pines de E/S
34
Suministro de energía
9 hasta 12V
Temperatura de trabajo
-40 hasta +85ºC
Zócalos superficiales de montaje
PLCC44, PLC68, DIL24
4.1.1.- MICROCONTROLADOR
El microcontrolador que se utilizará para el estudio del bus CAN
corresponde al modelo Atmel T89C51CC01 el cual posee compatibilidad con el
set de instrucciones de los microcontroladores Intel 8051 además del soporte
para el estándar de bus CAN 2.0A y 2.0B. En la Figura 4.2 y se muestra el
diagrama
de
bloques
y
distribución
de
pines
del
microcontrolador
respectivamente.
94
Figura 4.2.- Diagrama de bloques del microcontrolador Atmel T89C51CC01
Figura 4.3.- Distribución de pines del microcontrolador Atmel T89C51CC01 en formato
PLCC44
95
Otra característica del microcontrolador es que una gran parte de la
velocidad de procesamiento y de memoria queda disponible para la aplicación,
mientras que un completo protocolo de capa superior de pila (CANopen,
DeviceNet o J1939) se ejecuta en el chip. Debido a que se implementa un
motor de interrupciones que informa a la CPU cuando ha ocurrido un evento
asociado a la transmisión o recepción de mensajes en el bus CAN sin correr
una rutina de exploración por software, se minimiza el impacto en aplicaciones
de tiempo real.
Además este microcontrolador posee una gran flexibilidad para la
programación de aplicaciones, que puede ser a través de la interfaz UART o
CAN, permitiendo la programación a distancia y actualizaciones en terreno. El
fabricante ofrece una biblioteca de rutinas de programación de aplicaciones
dentro del sistema para los clientes que deseen construir sus propios gestores
de arranque, reduciendo el tiempo de desarrollo en general.
Finalmente en la lista de periféricos del microcontrolador se incluye 3
temporizadores de 16-bits con capacidad de modulación por ancho de pulso,
un conversor A/D de 10-bit/8-canales y varias interfaces seriales. Una amplia
gama de voltaje de funcionamiento que va desde 3 hasta 5,5V además de
cinco modos de baja potencia para optimizar el consumo de energía de la
aplicación.
96
Figura 4.4.- Esquema de la tarjeta de demostración C51
4.1.2.- CONECTORES DE ENERGÍA
En el kit de desarrollo de software existen básicamente 2 formas de
energizar la placa 12, la primera es por medio de la alimentación de 9 a 12V en el
conector J1 con un transformador AC/DC y la segunda es por medio de la
alimentación en el conector J2 con una batería de 9V.
Existen distintas combinaciones de alimentación para el kit de desarrollo las cuales están
detalladas en el documento “C51 Microcontrollers Demo Board User Guide” y que hacen uso
de configuraciones que incluyen la utilización del jumper J18, que para efectos prácticos no se
van a tomar en consideración, por lo tanto, se hablará sólo de alimentación en los conectores
J1 o J2
12
97
Figura 4.5.- Tarjeta de demostración C51 energizado en los conectores J1 y J2
4.1.3.- RELOJ DEL SISTEMA
El reloj del sistema depende de un cristal externo el que permite la
operación del oscilador interno del microcontrolador, se debe tener en
consideración que un ciclo de máquina se obtiene dividiendo la frecuencia del
cristal por 12, por lo tanto, con el cristal de 12MHz implementado en la tarjeta
de extensión CAN del kit de desarrollo, el ciclo de máquina es de 1µs. Otro
aspecto a mencionar es que la mayoría de las instrucciones se ejecutan en un
ciclo de máquina 13.
4.1.4.- INTERRUPTOR DE ENCENDIDO/APAGADO
Se conoce también como interruptor de encendido y sirve para
conmutar el estado de encendido y apagado (ON/OFF) de la fuente de
alimentación en el kit de desarrollo.
Es pertinente dejar en claro que las instrucciones de las que se hablan corresponden a
instrucciones escritas en lenguaje Assembly y no a las escritas en lenguaje C el cual se utilizará
posteriormente
13
98
4.1.5.- BOTÓN DE REINICIO
Se conoce también como pin de reinicio (RESET) y sirve para inicializar
el microcontrolador y empezar a ejecutar las instrucciones desde el espacio de
programa que reside en la memoria FLASH.
4.1.6.- BOTÓN DE INTERRUPCIÓN
Se conoce también como pin de interrupción externa 1 (P3.3/INT1) y en
el kit de desarrollo se implementó como un botón el cual, como su nombre lo
indica, puede generar una interrupción cada vez que se presiona de éste.
4.1.7.- PANTALLA LCD
Una pantalla LCD de 2x16 (2 líneas de 16 caracteres) de 5x8 puntos por
carácter (5 horizontales y 8 verticales) modelo Hitachi HD44780U.
4.1.8.- BARRA DE LED’S
Una barra de LED’s de 8 segmentos, cuya distribución de izquierda a
derecha consiste en: 2 rojos, 2 amarillos y 4 verdes.
4.1.9.- PUERTO RS-232
El puerto de comunicación RS-232 se implementa en el kit de desarrollo
en los pines de recepción (P3.0/RxD) y transmisión (P3.1/TxD) de señales de
datos seriales asíncronos (UART) del microcontrolador, éste puerto cumple un
doble propósito:
•
La utilización como puerto para visualizar o procesar mensajes de
entrada/salida.
•
El uso como interfaz de programación de la memoria FLASH del
99
microcontrolador 14.
4.1.10.- PUERTO CAN
El puerto de comunicación CAN se implementa en el kit de desarrollo en
los pines de transmisión (P4.0/TxDC) y recepción (P4.1/RxDC) de señales de
datos seriales del protocolo CAN del microcontrolador, éste puerto cumple con
la especificación CAN definida por BOSH GmbH en el estándar ISO 11898-2
(2.0A y 2.0B) para alta velocidad e ISO 11898-3 para baja velocidad.
Otro aspecto a destacar es que el jumper J10 de la tarjeta de extensión
CAN permite conectar o desconectar la resistencia de terminación de 120Ω del
bus, ya que se recomienda tener una resistencia de terminación conectada en
ambos extremos cuando el bus CAN esté funcionando a altas velocidades.
4.2.- DESCRIPCIÓN DEL SOFTWARE
Para poder utilizar el kit de desarrollo de precisan principalmente de 2
programas:
•
Entorno de Desarrollo Integrado.
•
Herramienta de Programación del Sistema.
4.2.1.- ENTORNO DE DESARROLLO INTEGRADO
Un entorno de desarrollo integrado o IDE (Integrated Development
Environment), es un programa informático compuesto por un conjunto de
herramientas de programación consistente en un editor de código, un
compilador y un depurador.
La programación del microcontrolador se hace mediante una combinación de una aplicación
de software residente en un espacio de la memoria FLASH del microcontrolador llamado
“bootloader” y una aplicación de software residente en un computador llamado “FLIP”
14
100
El entorno de desarrollo que se utilizará en los siguientes apartados
corresponde a las herramientas de desarrollo de la compañía Keil para los
microcontroladores Intel 8051 llamado “Keil C51 Development Tools”, el cual
permite la programación de aplicaciones escritas en lenguaje C y Assembly.
El lenguaje empleado para crear las aplicaciones que hagan uso del bus
CAN será el C, en un principio es necesario describir los motivos de escribir un
programa en C por sobre otros lenguajes de programación existentes para
microcontroladores:
•
Algoritmos de un alto nivel de complejidad pueden ser fácilmente
escritos en C mientras que no en Assembly.
•
La portabilidad de un programa escrito en lenguaje C es mucho mayor
que la de uno escrito en Assembly.
•
Crear aplicaciones CAN es mucho más fácil utilizando el lenguaje C que
crearlas en Assembly, ya que el fabricante provee el código escrito en C
para utilizar todos los periféricos del kit de desarrollo y en particular la
librería del bus CAN.
4.2.1.1.- TIPOS DE VARIABLES
El compilador C desarrollado por la compañía Keil es llamado C51 y
soporta la mayoría de los tipos de variables del ANSI C 15 además de agregar
unos cuantos propios.
Dentro de los tipos de variables estándar del compilador C51 los únicos
tipos de variables ANSI C que no están soportados son las variables de punto
flotante debido a que la arquitectura Intel 8051 no es capaz de manejar
ANSI C es un estándar publicado por el Instituto Nacional Estadounidense de Estándares
(American National Standards Institute) para el lenguaje de programación C
15
101
eficientemente este tipo de código, otro aspecto a considerar en la escritura de
un programa en C para sistemas empotrados es que el 8051 no tiene ningún
soporte directo para los tipos de datos con signo, por ende, operaciones con
signo requieren instrucciones adicionales mientras que los tipos de datos sin
signo no lo requieren, por este motivo debe evitarse el uso de variables con
signo siempre y cuando se pueda. Los tipos de variables soportados por el
compilador C51 se muestran en la Tabla 4.2.
Tabla 4.2.- Tipos de variables soportados por el compilador C51
Tipo
bit
signed char
unsigned char
enum
signed short
unsigned short
signed int
unsigned int
signed long
unsigned long
Bits
1
8
8
16
16
16
16
16
32
32
Bytes
Rango
0a1
1
-128 a +127
1
0 a 255
2
-32.768 a +32.767
2
-32.768 a +32.767
2
0 a 65.535
2
-32.768 a +32.767
2
0 a 65.535
4
-2.147.483.648 a +2.147.483.647
4
0 a 4.294.967.295
Compilador
Keil C51
Keil C51/ANSI C
Keil C51/ANSI C
Keil C51/ANSI C
Keil C51/ANSI C
Keil C51/ANSI C
Keil C51/ANSI C
Keil C51/ANSI C
Keil C51/ANSI C
Keil C51/ANSI C
El compilador C51 también añade el manejo de nuevos tipos de
variables las cuales son llamadas SFR (Special Function Registers) y son un
tipo de registro cuyo direccionamiento es asignado para el control y
configuración de: temporizadores, puertos seriales, puertos de E/S y periféricos
en general. Los SFR se encuentran en un área de memoria RAM al cual se
puede acceder más rápidamente que la memoria de propósito general y su
acceso puede ser mediante un tipo de datos bool (1bit), byte (8bits) o word
(16bits), los tipos de SFR que maneja el compilador C51 se muestran en la
Tabla 4.3.
102
Tabla 4.3.- Tipos de SFR que maneja el compilador C51
Tipo
Sbit
Sfr
Sf16
Bits
1
8
16
Bytes
1
2
Rango
0a1
0 a 255
0 a 65.535
4.2.1.2.- OPERACIONES Y ASIGNACIONES A NIVEL DE BITS
Las operaciones a nivel de bits que maneja el lenguaje C permiten una
serie de manipulaciones de datos que son muy útiles en aplicaciones
integradas, incluyendo los ejemplos que se verán en los futuros capítulos. Por
lo tanto, se mostrará las operaciones y asignaciones a nivel de bits que permite
el lenguaje C en la Tabla 4.4 y Tabla 4.5 respectivamente.
Tabla 4.4.- Operaciones a nivel de bits que permite el lenguaje C
Símbolo Forma
~
~x
&
x&y
|
x|y
^
x^y
<<
x << y
>>
x >> y
Descripción
operación de bit NOT
operación de bit AND
operación de bit OR
operación de bit XOR
desplazamiento a la
izquierda
desplazamiento a la
derecha
Operación
todos los bits se invierten
cada bit de ‘x’ AND cada bit de ‘y’
cada bit de ‘x’ OR cada bit de ‘y’
cada bit de ‘x’ XOR cada bit de ‘y’
todos los bits en ‘x’ se desplazan a la
izquierda en ‘y’ bits
todos los bits en ‘x’ se desplazan a la
derecha en ‘y’ bits
Tabla 4.5.- Asignaciones a nivel de bits que permite el lenguaje C
Símbolo Forma
&=
x &= y
|=
x |= y
^=
x ^= y
<<=
>>=
Descripción
asignación de bit AND
asignación de bit OR
asignación de bit XOR
asignación de desplazamiento
x <<= y
a la izquierda
asignación de desplazamiento
x >>= y
a la derecha
Operación
asigna ‘x & y’ a ‘x’
asigna ‘x | y’ a ‘x’
asigna ‘x ^ y’ a ‘x’
desplaza los bits en ‘x’ hacia la
izquierda en ‘y’ bits
desplaza los bits en ‘x’ hacia la
derecha en ‘y’ bits
4.2.1.3.- ESTRUCTURA DE UN PROGRAMA ESCRITO EN C
La estructura de un programa escrito en C para un microcontrolador es
básicamente la misma estructura de un programa estándar en C con algunos
cambios menores, la estructura típica se muestra en la Figura 4.6.
103
/******************************************************************************
* FILE_NAME: main.c
*
*-----------------------------------------------------------------------------*
* This is the program header. Describe your program here briefly
*
******************************************************************************/
/* include your headers here */
#include <t89c51cc01.h>
/* include your variable declarations here */
bit
var_1;
unsigned char var_2;
unsigned int var_3;
/* include your functions here */
void func_1(void)
{
/* body of function */
}
/* include your main code here */
void main(void) /* main code */
{
/* initialisation of variables */
}
while(1)
/* start of endless loop */
{
/* body of loop */
}
Figura 4.6.- Estructura general de un programa escrito en C para sistemas empotrados
Es necesario aclarar en este punto que la serie de laboratorios que se
implementarán los programas ya estarán escritos y se le pedirá al alumno
modificar algunos parámetros necesarios para la configuración y comunicación
de los kits.
4.2.1.4.- RUTINAS DE INTERRUPCIÓN
El microcontrolador Atmel T89C51CC01 tiene un total de 10 vectores de
interrupción: dos interrupciones externas (INT0 e INT1), tres interrupciones por
temporizador (Timer 0/1/2), una interrupción por puerto serie (UART), una
104
interrupción por el arreglo de contador programable (PCA/EWC 16), una
interrupción por conversión análoga/digital (ADC), una interrupción por
comunicación CAN y finalmente una interrupción por desbordamiento del
temporizador
CAN,
el
detalle
de
los
tipos
de
interrupciones
del
microcontrolador de muestran en la Tabla 4.6.
Tabla 4.6.- Detalle de los tipos de interrupciones del microcontrolador Atmel T89C51CC01
Interrupción
Número
Externa 0 (INT0)
Timer 0 (TF0)
Externa 1 (INT1)
Timer 1 (TF1)
UART (RI o TI)
Timer 2 (TF2)
PCA (CF o CCFn)
CAN (Tx, Rx, Err, OvrBuff)
ADC (ADCI)
CAN Timer (OvrTim)
0
1
2
3
4
5
6
7
8
9
Vector de
direccionamiento
0x0003
0x000B
0x0013
0x001B
0x0023
0x002B
0x0033
0x003B
0x0043
0x004B
El compilador C51 permite declarar rutinas de interrupción en el código
C para que el programa se dirija automáticamente a éste cuando se produzca
una interrupción, genera automáticamente los vectores de interrupción además
del código para entrar y salir de las rutinas de interrupción.
El esquema de las rutinas de interrupción es similar a la declaración de
funciones con la salvedad que el número de interrupción debe declararse como
parte de la función, tal como se muestra en la Figura 4.7.
void fct_timer1_it(void) interrupt 3
{
/* interrupt service goes here */
}
Figura 4.7.- Estructura general del código escrito en C de una rutina de interrupción
Se usa indistintamente el anglicismo PCA (Programmable Counter Array) o el EWC (Event
and Waveform Controller)
16
105
4.2.1.5.- CREAR UN PROGRAMA DE REFERENCIA
Una vez familiarizado con los aspectos de la programación para
microcontroladores se mostrará cómo empezar a crear un proyecto con el IDE
Keil μVision. La forma de crear un programa de referencia se mostrará a
continuación:
1.- En primer lugar ejecutar el programa Keil μVision3 (Figura 4.8).
Figura 4.8.- Interfaz gráfica de inicio del IDE Keil μVision3
2.- Diríjase al menú desplegable ‘Project → New μVision Project…’ y guarde
el proyecto con el nombre que desee, por ejemplo ‘my_project’.
3.- A continuación en la ventana de selección de dispositivo elija el
proveedor ‘Atmel’ y posteriormente el microcontrolador ‘T89C51CC01’
(Figura 4.9).
106
Figura 4.9.- Ventana de selección de dispositivo
4.- Cuando el programa consulte por copiar el código de inicio estándar
para un microcontrolador 8051 a la carpeta del proyecto, escoger ‘No’.
5.- Una vez configurado el dispositivo de destino marque y presione el click
derecho del mouse sobre la carpeta ‘Target 1’ y seleccione el menú
desplegable ‘Options for Target’ (Figura 4.10).
107
Figura 4.10.- Menú desplegable ‘Options for Target’
6.- Aparecerá una ventana con una serie de opciones de configuración para
el proyecto, de las cuales, en primera instancia, interesa cambiar la
configuración por defecto de las pestañas ‘Target’ y ‘Output’.
7.- En la pestaña ‘Target’ (Figura 4.11) modifique la opción de frecuencia
del cristal ‘Xtal (MHz)’ por 12, para ser coincidente con el cristal de
12MHz empleado en el kit de desarrollo 17.
Ésta modificación no causa ningún cambio en el código generado cuando se compile un
proyecto, pero es útil para simular la temporización, los retardos por software y configuración
de velocidad de los periféricos en las sesiones de depuración
17
108
Figura 4.11.- Pestaña ‘Target’ de la ventana ‘Options for Target’
8.- En la pestaña ‘Output’ (Figura 4.12) seleccione la casilla de verificación
‘Create HEX File’ para generar un archivo hexadecimal del proyecto, el
que posteriormente será programado en el microcontrolador.
109
Figura 4.12.- Pestaña ‘Output’ de la ventana ‘Options for Target’
9.- A continuación marque y presione el click derecho del mouse sobre la
carpeta ‘Source Group’ y seleccione el menú desplegable ‘Add Files to
Group’ (Figura 4.13) para añadir el código de fuente de todos los
archivos necesarios para el desarrollo del proyecto.
110
Figura 4.13.- Menú desplegable ‘Add Files to Group’
10.- Finalmente se puede compilar el proyecto marcando y presionando el
click derecho del mouse sobre la carpeta ‘Target 1’ y seleccionando el
menú desplegable ‘Build target’ (Figura 4.14).
111
Figura 4.14.- Menú desplegable ‘Build target’
4.2.1.6.- AGREGAR OPCIONES DE DEPURACIÓN
Una vez que el proyecto esté creado se pueden agregar opciones de
depuración las cuales son muy útiles a la hora de identificar y corregir errores
de programación. A su vez también es una herramienta muy importante para la
revisión sistemática del código de fuente y para dar seguimiento de la
ejecución del programa presentando, por ejemplo, los valores de variables y
direcciones de memoria. La forma de agregar secuencias de comandos y
cuadros de herramientas seleccionables en el menú de depuración se mostrará
a continuación:
1.- En primer lugar debe marcar y presionar el click derecho del mouse
sobre la carpeta ‘Target 1’ y seleccionar el menú desplegable ‘Options
for Target’ (Figura 4.10).
112
2.- Dentro de la ventana de opciones del proyecto, debe dirigirse, en esta
instancia, a la pestaña ‘Debug’ (Figura 4.15), presionar el botón de
selección de la opción ‘Initialization File’ y escoger el archivo necesario
para realizar la depuración del proyecto, que en este ejemplo es llamado
‘debug.ini’.
Figura 4.15.- Pestaña ‘Debug’ de la ventana ‘Options for Target’
3.- Para tener más fácil acceso al archivo de depuración dentro del IDE, se
pude incluir dentro del espacio de trabajo un nuevo grupo que contenga
dicho archivo.
4.- Para crear un nuevo grupo debe marcar y presionar el click derecho del
mouse sobre la carpeta ‘Target 1’ y seleccionar el menú desplegable
‘New Group’ (Figura 4.16).
113
Figura 4.16.- Menú desplegable ‘New Group’
5.- A continuación se creará una nueva carpeta de archivos dentro del
proyecto la cual es conveniente renombrar con un nombre que tenga
algún significado, en este ejemplo se llamará ‘Debug Session 1’.
6.- Posteriormente debe marcar y presionar el click derecho del mouse
sobre la carpeta creada y seleccionar el menú desplegable ‘Add Files to
Group’ (Figura 4.17).
114
Figura 4.17.- Menú desplegable ‘Add Files to Group’
7.- En la ventana desplegable cambie el tipo de filtro a ‘All files (*.*)’ y
agregue el archivo de depuración que desee, continuando con el
ejemplo se selecciona ‘debug.ini’, y cuando el programa consulte por el
tipo de archivo seleccionado escoja la opción ‘Text Document file’.
8.- Finalmente, si todos los pasos han sido ejecutados correctamente, se
tendrá un espacio de trabajo del proyecto similar al mostrado en la
Figura 4.18.
115
Figura 4.18.- Estructura del proyecto ‘my_project’
4.2.2.- HERRAMIENTA DE PROGRAMACIÓN DEL SISTEMA
La herramienta de programación del sistema es llamado por la compañía
Atmel como FLIP (FLexible In-system Programmer), es un software que se
ejecuta en el computador y sirve para la programación de microcontroladores
de dicha compañía. Esta herramienta puede programar dispositivos dentro del
sistema (ISP: In-System Programming) a través de UART, USB y CAN 18. El tipo
de programación que se utilizará para los proyectos será por medio del puerto
RS-232 (UART).
4.2.2.1.- CONDICIONES DE HARDWARE
En primer lugar se debe proceder a establecer las condiciones de
hardware que se requieren para programar el kit de desarrollo las cuales se
muestran en la Figura 4.19 y se describen a continuación:
1.- Interconectar la tarjeta de demostración C51 (C51 Demo Board) con la
tarjeta de extensión CAN (CAN Extension Board).
2.- Energizar la tarjeta de demostración C51 conectando el suministro de
energía de 9V.
3.- Conectar el puerto RS-232 de la tarjeta de demostración C51 al puerto
de
comunicaciones
COM
del
PC
mediante
un
cable
RS-232
La programación para el microcontrolador T89C51CC01 puede ser sólo a través de los
puertos RS-232 y CAN ya que no posee interfaz USB, además la programación por medio del
bus CAN requiere un sistema electrónico llamado “dongle”
18
116
Macho/Hembra 19.
4.- Asegurarse
que
el
microcontrolador
T89C51CC01UA-SLIM
esté
conectado al zócalo PLCC44 de la tarjeta de extensión CAN.
Figura 4.19.- Conexión entre el PC y el kit de desarrollo CAN mediante RS-232
Debemos tener en cuenta que el microcontrolador T89C51CC01 tiene un
área de memoria residente en la FLASH que viene pre-programada con una
aplicación de software llamada gestor de arranque (Bootloader). El gestor de
arranque que se utilizará para los proyectos será el UART 20 el cual se encarga
de realizar tareas para programar o reprogramar la memoria FLASH del
microcontrolador (EEPROM) utilizando el puerto serie. El kit de desarrollo se
19
En caso de que el computador a utilizar no tenga puerto de comunicaciones serial (COM) se
puede utilizar un conversor USB a RS-232
Los microcontroladores T89C51CC01 vienen disponibles con 2 gestores de arranque: UART
y CAN ambos, a grandes rasgos, se encargan de iniciar una secuencia de reconocimiento de la
velocidad de la interfaz serial (UART o CAN) para posteriormente realizar tareas relacionadas
con la lectura y/o escritura del chip en la memoria FLASH (EEPROM)
20
117
encarga de, según el posicionamiento de los interruptores: J9, J11 y J16, saltar
la ejecución del programa principal para ejecutar el gestor de arranque y
realizar tareas de programación en el microcontrolador (modo Gestor de
Arranque) o, en sentido contrario, saltar la ejecución del gestor de arranque
para ejecutar la aplicación principal (modo Aplicación de Usuario).
Para programar la memoria FLASH del microcontrolador es necesario,
en primera instancia, realizar los ajustes hardware del kit de desarrollo que
permitan iniciar el sistema en modo ‘Gestor de Arranque’. Para iniciar el
sistema en modo ‘Gestor de Arranque’ las posiciones de los interruptores J9,
J11 y J16 de la tarjeta de demostración C51 deben quedar como se muestra
en la Figura 4.20.
Figura 4.20.- Condición de hardware configurado para arrancar en modo ‘Gestor de Arranque’
Después de establecer las condiciones necesarias programar la
memoria FLASH del microcontrolador es necesario, en segunda instancia,
realizar los ajustes hardware del kit de desarrollo que permitan iniciar el sistema
en modo ‘Aplicación de Usuario’. Para iniciar el sistema en modo ‘Aplicación
118
de Usuario’ las posiciones de los interruptores J9, J11 y J16 de la tarjeta de
demostración C51 deben quedar como se muestra en la Figura 4.21.
Figura 4.21.- Condición de hardware configurado para arrancar en modo ‘Aplicación de
Usuario’
4.2.2.2.- USO DEL PROGRAMADOR DE SISTEMA
En segundo lugar veremos los pasos necesarios para utilizar el software
de programación FLIP y verificar que se han establecido correctamente los
parámetros necesarios para poder programar la tarjeta de demostración:
1.- En primer lugar ejecutar el programa FLIP (Figura 4.22).
119
Figura 4.22.- Interfaz gráfica de inicio del programador FLIP
2.- Diríjase al menú desplegable ‘Device → Select’ seleccione el dispositivo
‘T89C51CC01’, nótese que la ventana de la aplicación mostrará ahora la
configuración del microcontrolador (Figura 4.23).
120
Figura 4.23.- Ventana del programador FLIP con el dispositivo T89C51CC01 seleccionado
3.- Asegúrese de que el kit de desarrollo se encuentre debidamente
conectado al PC con la condición de hardware configurado para
arrancar en modo ‘Gestor de Arranque’ (Figura 4.20) y posteriormente
encienda el kit de desarrollo.
4.- A
continuación
seleccione
el
menú
desplegable
‘Settings
→
Communication → RS232’, en la ventana de configuración ‘RS232
Setup’ escoja de puerto COM al cual esté conectado el kit de desarrollo
y configure la velocidad de transmisión, tal como se muestra en la
Figura 4.24.
121
Figura 4.24.- Configuración del puerto RS-232
5.- Iniciar la comunicación presionando el botón ‘Connect’ de la ventana de
configuración ‘RS232 Setup’. Si la conexión es exitosa, la ventana del
FLIP debe ser similar a la mostrada en la Figura 4.25 21.
En algunos ordenadores portátiles es necesario realizar el siguiente procedimiento: Haga clic
en ‘Connect’, resetee el kit de desarrollo y a continuación haga clic en ‘Sync’
21
122
Figura 4.25.- Conexión exitosa del kit de desarrollo
6.- En el menú desplegable ‘File → Load HEX File…’ elija la aplicación que
desee programar en el microcontrolador, previamente compilada y en
formato binario hexadecimal. El mensaje ‘HEX file parsed’ mostrado en
la parte inferior de la ventana del programador FLIP confirma que la
carga del archivo fue exitosa (Figura 4.26).
123
Figura 4.26.- Archivo hexadecimal debidamente cargado
7.- Asegurarse
que
las
casillas
de
verificación
siguientes
están
seleccionadas en la sección ‘Operations Flow’ del FLIP:

Erase

Blank Check

Program

Verify
8.- Deje sin verificar el cuadro de ‘BLJB’ en la sección ‘T89C51CC01’ a fin
de ejecutar el programa de demostración después del siguiente reinicio.
9.- Presione el botón ‘Run’ para que la programación se ejecute. El mensaje
124
‘Verify PASS’ mostrado en la parte inferior de la ventana del
programador FLIP confirma que el microcontrolador se ha programado
correctamente (Figura 4.27).
Figura 4.27.- Programación exitosa del microcontrolador
10.- Una vez programado asegúrese de que el kit de desarrollo se
encuentre con la condición de hardware configurado para arrancar en
modo ‘Aplicación de Usuario’ (Figura 4.21).
11.- Finalmente, reinicie el kit de desarrollo para iniciar la aplicación
programada en el microcontrolador.
125
CAPÍTULO 5.- PUESTA EN FUNCIONAMIENTO DEL SISTEMA
CAN
El propósito de este capítulo es la de enseñar al alumno el protocolo de
comunicaciones CAN utilizando un kit de desarrollo, considerando para esto
los aspectos académicos relacionados con el estudio de dicho protocolo. Para
realizar lo anteriormente expuesto, se enseña la metodología para crear
aplicaciones para el kit de desarrollo por medio de una serie de experiencias de
laboratorio, cuyo detalle se encuentran en el anexo A: Guías de Laboratorio.
5.1.- INTRODUCCIÓN A LA PROGRAMACIÓN DE APLICACIONES
PARA EL KIT DE DESARROLLO
El propósito de este laboratorio es familiarizar al alumno con el kit de
desarrollo y las herramientas necesarias para la creación, compilación y
programación para éste, para ello es necesario abarcar los siguientes
aspectos:
•
Explicar la estructura general de un programa que haga uso de los
distintos componentes del kit de desarrollo.
•
La importancia del reloj del sistema para la comunicación asíncrona.
•
El funcionamiento del puerto RS-232 del microcontrolador.
Este laboratorio consta de utilizar las librerías creadas específicamente
para hacer uso de los componentes de hardware implementados en el kit de
desarrollo, cuyo propósito es ayudar al alumno a crear aplicaciones que hagan
uso de dichos componentes, se entregará al alumno 3 programas escritos en
C que mostrarán el uso de:
•
La barra de LED’s.
•
La pantalla LCD.
126
•
El puerto RS-232.
5.1.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE
Para la puesta en funcionamiento del kit de desarrollo es necesario
contar con herramientas de software y de hardware que se enumerarán a
continuación:
Tabla 5.1.- Requerimientos de software y de hardware para el laboratorio nº1
Requerimientos
Requerimientos de
Software
Requerimientos de
Hardware
Herramientas
Entorno de desarrollo integrado: Keil C51
Herramienta de programación del sistema: Atmel FLIP
Código de fuente de los programas ‘bargraph’, ‘display’ y
‘rs232’
Programas compilados en formato hexadecimal
‘bargraph.hex’, ‘display.hex’ y ‘rs232.hex’
Un kit de desarrollo CAN además de su respectivo
microcontrolador del tipo: T89C51CC01UA-SLSIM
Un Cable Serie RS-232 DB9/DB9 (Macho/Hembra) para la
comunicación entre el kit de desarrollo y el computador
5.1.2.- CONVENCIONES DE PROGRAMACIÓN
En todos los proyectos que se mostrarán desde ahora en adelante hará
uso de un archivo de configuración llamado ‘config.h’ (Figura 5.1) que estará
incluido en el código de fuente de todos los archivos con el fin de compartir las
configuraciones en todos los proyectos.
127
/******************************************************************************
* FILE_NAME: config.h
*
*-----------------------------------------------------------------------------*
* FILE_PURPOSE: This file is included by all source files in order to access *
*
to system wide configuration
*
******************************************************************************/
#ifndef _CONFIG_H_
#define _CONFIG_H_
#include <t89c51cc01.h>
#include "compiler.h"
#endif /* _CONFIG_H_ */
Figura 5.1.- Ejemplo de utilización del archivo ‘config.h’ incluido en las rutinas
El archivo de configuración incluido hace a su vez la inclusión de los
archivos ‘t89c51cc01.h’ y ‘compiler.h’. El archivo ‘t89c51cc01.h’ añade el
manejo los registros de funciones encargados del direccionamiento para el
microcontrolador T89C51CC01; mientras que el archivo ‘compiler.h’ redefine
las palabras clave con el fin de asegurarse de que cualquier archivo de origen
pueda ser procesado por distintos compiladores además de definir nombres
para tipos de datos que hagan más fácil el declarar variables y parámetros
(también llamados ‘alias’).
Dentro de los nombres definidos en el archivo ‘compiler.h’ se mostrarán
los más utilizados dentro de los proyectos, los que corresponden a las
definiciones de tipo asociadas a las variables (Tabla 5.2) y las definiciones de
constantes asociadas a las interrupciones (Tabla 5.3).
128
Tabla 5.2.- Definición de tipos entregados en el archivo ‘compiler.h’
Definición
Bool
Uchar
Uint8
Uint16
Uint32
Int8
Int16
Int32
Tipo
unsigned char
unsigned char
unsigned char
signed char
unsigned int
signed int
unsigned long
signed long
Bits
8
8
8
8
16
16
32
32
Bytes
1
1
1
1
2
2
4
4
Tabla 5.3.- Definición de constantes asociados a interrupciones entregados en el archivo
‘compiler.h’
Nombre
Número
Interrupción
IRQ_INT0
0
Externa 0 (INT0)
IRQ_TIMER0
1
Timer 0 (TF0)
IRQ_INT1
2
Externa 1 (INT1)
IRQ_TIMER1
3
Timer 1 (TF1)
IRQ_UART
4
UART (RI o TI)
IRQ_TIMER2
5
Timer 2 (TF2)
IRQ_EWC
6
PCA (CF o CCFn)
IRQ_CAN
7
CAN (Tx, Rx, Err, OvrBuff)
IRQ_ADC
8
ADC (ADCI)
IRQ_CAN_TIMOVF
9
CAN Timer (OvrTim)
5.1.3.- ESTÁNDAR RS-232
El estándar RS-232, definido en el ANSI como EIA-232, emplea un
esquema de transmisión serie con un circuito eléctrico single-ended y
especifica el conjunto de reglas para intercambiar datos entre 2 equipos de
computación, originalmente nombrados como DTE (Data Terminal Equipment)
y DCE (Data Communication Equipment) o MODEM.
Es adecuado para transferir datos a máxima velocidad a distancias de
hasta 15m según la norma 22, la interfaz puede trabajar en comunicación
La revisión ‘C’ especificaba una longitud máxima entre equipos de 15m, pero posteriores
revisiones, ‘D’ y ‘E’, han cambiado este requisito por uno más realista al especificar una
capacidad máxima del canal de transmisión. De esta manera, las longitudes máximas
aceptables dependen de las características de los cables empleados y las capacidades de
entrada de los circuitos de interface
22
129
asíncrona o síncrona y tipos de canal simplex, half dúplex o full dúplex. Para
generar un enlace entre 2 dispositivos, 5 parámetros deben especificarse,
estos parámetros son: velocidad de transmisión, bits de datos, paridad, bits de
parada y control de flujo, los cuales de describen a continuación:
•
Velocidad de transmisión: Determina cuanta información es transferida
sobre un determinado intervalo de tiempo la cual se mide en bits por
segundo,
usualmente
se
pueden
elegir velocidades
que
están
estandarizadas y van desde 75 hasta 19200bps 23. Por ejemplo, de la
famosa velocidad 9600bps obtenemos 1/9600 = 104µs.
•
Bits de datos: Puede ser desde 5 a 8 bits de datos 24, comúnmente sólo
se utilizan implementaciones de 7 u 8 bits de datos dependiendo de la
naturaleza de datos a ser transferidos, como ejemplo el estándar ASCII
original consta de 7 bits, mientras que 8 bits hacen 1 byte.
•
Paridad: Este bit es opcional y puede ser usado para marcar la paridad.
Esta puede ser entonces: par, impar, marca (siempre 1), espacio
(siempre 0) o sin paridad (no se utiliza). En caso de que no esté correcto
el valor se deberá desechar el dato recibido ya que ha sido corrompido
durante la transmisión. Los bits de inicio y término no se tienen en
cuenta para el cálculo de la paridad.
•
Bits de parada: Se utiliza para asegurar que no se transmita nada por la
línea hasta pasado un tiempo, es un valor que se puede configurar y
generalmente nos dan 3 opciones: 1 bit, 1,5 bits y 2 bits, puede sonar
extraño tener un bit y medio pero hay que tener en cuenta que hace
referencia al tiempo de bit por lo que, siguiendo con el ejemplo de
En realidad se dice que la RS-232 es la menos estándar de las normas por la infinidad de
variaciones que permite ya que comúnmente es utilizado a velocidades mayores que llegan
hasta los 115200bps (o superiores) pero éstas velocidades no son parte del estándar
23
5 y 6 bits de datos se utilizan para equipos de comunicación especializados, algunos
módems permiten también el uso de 4 bits de datos pero no es estándar
24
130
9600bps, 1,5×104µs = 156µs.
•
Control de flujo: El control de flujo o también llamado handshaking
(apretón de manos) hace referencia a la forma en la que el transmisor y
el receptor se notifican su estado para llevar a cabo la comunicación y
puede ser:

Ninguno: No es necesario emplear control de flujo.

Hardware: Utilizando líneas físicas específicas para esta tarea: RTS y
CTS.

Software: Por la propia UART se envían valores específicos para este
fin: XON y XOFF 25.
Debe tomarse en consideración que siempre el bit de inicio tiene 1 bit,
por lo que la transmisión y recepción de datos seriales consiste siempre en una
trama de:
•
1 bit de inicio.
•
5 a 8 bits de datos.
•
1 bit opcional de paridad.
•
1, 1,5 o 2 bits de término.
En muchas aplicaciones se utiliza una velocidad de transmisión de
9600bps en donde 10 bits son usados para especificar la trama RS-232
consistente en: 1 bit de inicio, 8 bits de datos, sin paridad, 1 bit de parada y sin
utilizar control de flujo, esta configuración es abreviada en la literatura como:
9600-8-N-1-N (9600bps, 8 bits de datos, sin paridad, 1 bit de parada y sin
control de flujo).
En XON/XOFF, cuando el receptor quiere que el transmisor pare el envío de datos envía
XOFF, mientras que cuando el receptor quiere que el transmisor envíe más datos envía XON
25
131
5.1.4.- LABORATORIO Nº1.1
En este laboratorio se describirá la utilización de la pantalla LCD para el
kit de desarrollo utilizando la librería de la pantalla LCD, esta librería contiene
los siguientes archivos:
•
lcd.c
•
lcd.h
La cual consta de 2 funciones que pueden ser llamadas únicamente si
se incluye la cabecera del programa que lo va a utilizar, las funciones que
entrega son las siguientes:
void lcd_init(void)
void set_lcd_line(Uchar line, Uchar *pt_string)
La primera función de encarga de ejecutar los procedimientos para
inicializar la pantalla LCD por software para que puedan interpretar
correctamente los datos enviados al controlador Hitachi HD44780U, mientras
que la segunda función se encarga de escribir en la pantalla una cadena de
caracteres determinada de la forma <número de línea, texto a mostrar>, la
utilización en un programa se ejemplifica en la Figura 5.2.
132
/******************************************************************************
* FILE_NAME: main.c
*
*-----------------------------------------------------------------------------*
* FILE_PURPOSE: Display LCD program example
*
******************************************************************************/
#include "config.h"
#include "lcd.h"
void main(void)
{
lcd_init(); /* lcd initialisation */
set_lcd_line(1, “ATMEL Wireless &”);
/* welcome */
set_lcd_line(2, “MicroControllers”);
/* message */
while(1);
/* start of endless loop */
}
Figura 5.2.- Ejemplo de utilización de la librería de la pantalla LCD
La utilización de esta librería se ejemplifica en el proyecto display.uv2 en
donde se verá la inclusión de ésta en el programa principal. Finalmente la
estructura del programa se muestra en la Figura 5.3.
Figura 5.3.- Estructura del proyecto ‘display’
Se dejará como labor para el alumno compilar el programa escrito y
programar el kit de desarrollo.
133
5.1.5.- LABORATORIO Nº1.2
En este laboratorio se describirá la utilización de la barra de LED’s para
el kit de desarrollo, ésta librería contiene los siguientes archivos:
•
bg.c
•
bg.h
La cual también consta de 2 funciones que pueden ser llamadas
únicamente si se incluye la cabecera del programa que lo va a utilizar, las
funciones que entrega son las siguientes:
void bg_init(void)
void set_bg_value(Uchar)
La primera función se encarga de ejecutar los procedimientos para
inicializar la barra de LED’s dejándolos todos apagados, mientras que la
segunda función se encarga de escribir en la barra de LED’s una secuencia de
caracteres que se entrega en formato hexadecimal, la utilización en un
programa se ejemplifica en la Figura 5.4.
134
/******************************************************************************
* FILE_NAME: main.c
*
*-----------------------------------------------------------------------------*
* FILE_PURPOSE: Bargraph LED program example
*
******************************************************************************/
#include "config.h"
#include "bg.h"
Uchar bar_led;
Uint16 i;
void delay(Uint16 tempo)
{
for(i=0; i<tempo; i++);
}
void main(void)
{
bar_led = 0xAA; /* bar_led initialisation, 0xAA = 1010 1010 */
bg_init();
/* bargraph initialisation */
while(1)
/* start of endless loop */
{
delay(0xC350);
/* delay for approx. 250ms */
set_bg_value(bar_led); /* send bargraph output */
bar_led = ~bar_led;
/* flip all bits */
}
}
Figura 5.4.- Ejemplo de utilización de la librería de la barra de LED’s
La utilización de esta librería se ejemplifica en el proyecto bargraph.uv2
en donde se verá la inclusión de ésta en el programa principal. Además es
necesario hacer notar que tanto el programa dado como ejemplo como el que
está en el proyecto hace uso de retardos por software mediante el uso de la
función ‘void delay(Uint16)’, otro punto a destacar es que el programa que se
da en el proyecto hace uso de interrupciones por hardware presionando el
botón de interrupción ‘INT1’, finalmente la estructura del programa se muestra
en la Figura 5.5.
135
Figura 5.5.- Estructura del proyecto ‘bargraph’
Se dejará como labor para el alumno compilar el programa escrito y
programar el kit de desarrollo.
5.1.6.- LABORATORIO Nº1.3
En éste laboratorio se describirá la utilización del puerto de
comunicación RS-232 para el kit de desarrollo, para esto es necesario utilizar
una biblioteca estándar para el lenguaje de programación C, la cual es llamada
‘stdio.h’ (cabecera estándar de entrada/salida), este archivo contiene las
definiciones de macros, las constantes, las declaraciones de funciones y la
definición de tipos usados por varias operaciones de entrada y salida, la
función que se utilizará desde ahora en adelante será la función ‘int printf(const
char *format, …)’ que puede ser utilizada para mandar datos hacia el puerto
RS-232.
En caso de querer transmitir o recibir datos por el puerto serie del
microcontrolador, es necesario reconocer los siguientes registros:
•
SMOD: Registro perteneciente a ‘PMOD’, el cual es un parámetro
opcional de configuración que si es configurado como el hexadecimal
136
‘0x80’ (SMOD = 1) duplica la velocidad de bits por segundo configurada
para el puerto serie.
•
SCON: Registro de control para el puerto serie, por ejemplo si es
configurado como el hexadecimal ‘0x40’ (SM0 = 0 y SM1 = 1) se habilita
el puerto serie en modo 1 (8-bit de datos con velocidad de bits variable)
sin recepción de datos; mientras que si es configurado como el
hexadecimal ‘0x50’ (SM0 = 0, SM1 = 1 y REN = 1) se habilita el puerto
serie en modo 1 con recepción de datos.
•
TI y RI: Registros pertenecientes a ‘SCON’ se activan (establecen como
1) para indicar que se está listo para transmitir o recibir datos y deben
limpiarse (establecerse como 0) por software para el reconocimiento de
una interrupción causada por la transmisión o recepción de datos por el
puerto serie 26.
En el caso de utilizar el Timer 0/1 para la comunicación serie los
registros a configurar son los siguientes:
•
TMOD: Registro de control del modo de trabajo para los Timer 0 y 1, por
ejemplo si es configurado como el hexadecimal ‘0x02’ (M10 = 1 y M00 =
0) habilita el funcionamiento del Timer 0 en modo 2 (temporizador de 8
bits con auto-recarga 27); mientras que si es configurado como el
hexadecimal ‘0x20’ (M11 = 1 y M01 = 0) habilita el funcionamiento del
Timer 1 en modo 2.
Es pertinente indicar que siempre antes de transmitir datos por el puerto RS-232 es
necesario asignar TI = 1, pues la función ‘printf’ que a su vez hace un llamado a la función
‘putchar’ se encarga de verificar si TI = 1 antes de enviar datos al puerto serie, una vez enviado
un carácter asigna TI = 0 para luego asignar nuevamente TI = 1 en caso de requerir transmitir
más caracteres, por ende la primera asignación TI = 1 debe ser escrito por uno mismo para
que este ciclo tenga efecto
26
El valor de recarga del Timer 0/1 se lee desde TH0/TH1 cuando se desborda el registro
TL0/TL1 según sea el caso
27
137
•
TH0 y TH1: Registro de byte alto del Timer 0/1 que en el funcionamiento
en modo 2 debe ser cargado con una constante para recargar el registro
TL0/TL1 una vez que este se haya desbordado, la Tabla 5.4 muestra los
valores de recarga para distintos cristales.
•
TR0 y TR1: Registro perteneciente a ‘TCON’ que se encarga de arrancar
o parar el Timer 0/1, se activa con un valor 1 y se desactiva con un valor
0.
Tabla 5.4.- Valores de recarga del registro TH0/TH1 para obtener distintas velocidades de
transmisión
Velocidad de
Cristal [MHz]
transmisión [bps]
9600
4800
2400
1200
9600
4800
2400
1200
Valor del bit
SMOD
12,000
12,000
12,000
12,000
11,059
11,059
11,059
11,059
1
1
0
0
0
0
0
0
Valor de
recarga para
TH0/TH1
0xF9
0xF3
0xF3
0xE6
0xFD
0xFA
0xF4
0xE8
Error [%]
6,99
0,16
0,16
0,16
0
0
0
0
Los valores para el cálculo de los valores de recarga del registro
TH0/TH1 se obtienen de las Ecuaciones 5.1 y 5.2.
TH0/TH1 = 256 −
2SMOD × FOSC
384 × Baud Rate
2SMOD × FOSC
Baud Rate =
2 × 32 × [256 − TH0/TH1]
[5. 1]
[5. 2]
En el caso de utilizar el Timer 2 para la comunicación serie los registros a
configurar son los siguientes:
•
T2CON: Registro de control del Timer 2, por ejemplo si es configurado
138
como el hexadecimal ‘0x30’ (RCLK = 1 y TCLK = 1) se establece el
Timer 2 como reloj para la transmisión de datos para el puerto serie en
modo temporizador de 16 bits con auto-recarga 28.
•
RCAP2H y RCAP2L: Registro de byte alto y bajo del Timer 2
respectivamente, que en el funcionamiento en modo temporizador de 16
bits con auto-recarga deben ser cargados con una constante para
recargar el registro TL2 y TH2 una vez que estos se hayan desbordado,
la Tabla 5.5 muestra los valores de recarga para distintos cristales.
•
TR2: Registro perteneciente a ‘T2CON’ que se encarga de arrancar o
parar el Timer 2, se activa con un valor 1 y se desactiva con un valor 0.
Tabla 5.5.- Valores de recarga de los registros RCAP2H y RCAP2L para obtener distintas
velocidades de transmisión
Velocidad de
transmisión
[bps]
115200
57600
38400
19200
14400
9600
115200
57600
38400
19200
14400
9600
Cristal
[MHz]
Valor del
bit SMOD
12,000
12,000
12,000
12,000
12,000
12,000
11,059
11,059
11,059
11,059
11,059
11,059
1
1
1
1
0
0
0
0
0
0
0
0
Valor de
Valor de
recarga para recarga para Error [%]
RCAP2H
RCAP2L
0xFF
0xF9
6,99
0xFF
0xF3
0,16
0xFF
0xEC
2,34
0xFF
0xD9
0,16
0xFF
0xE6
0,16
0xFF
0xD9
0,16
0xFF
0xFD
0
0xFF
0xFA
0
0xFF
0xF7
0
0xFF
0xEE
0
0xFF
0xE8
0
0xFF
0xDC
0
Los valores para el cálculo de los valores de recarga de los registros
RCAP2H y RCAP2L se obtienen de las Ecuaciones 5.3 y 5.4.
El valor de recarga del Timer 2 se lee desde RCAP2H y RCAP2L cuando se desbordan los
registros TL2 y TH2
28
139
(RCAP2H, RCAP2L) = 65536 −
Baud Rate =
2SMOD × FOSC
32 × Baud Rate
2SMOD × FOSC
32 × [65536 − (RCAP2H, RCAP2L)]
[5. 3]
[5. 4]
Como se puede ver en la Tabla 5.4 y Tabla 5.5 la mayor velocidad de
transmisión utilizando un cristal de 12MHz y manteniendo un error aceptable 29
es de 4800bps en caso de utilizar el Timer 0/1 y 57600bps en caso de utilizar el
Timer 2, la utilización en un programa utilizando el Timer 1 se ejemplifica en la
Figura 5.6.
/******************************************************************************
* FILE_NAME: main.c
*
*-----------------------------------------------------------------------------*
* FILE_PURPOSE: RS232 program example
*
******************************************************************************/
#include <stdio.h>
#include “config.h”
void serial_init(void)
{
PCON |= 0x80;
/*
SCON = 0x40;
/*
TMOD |= 0x20;
/*
TH1 = 0xF3;
/*
TR1 = 1;
/*
TI = 1;
/*
}
SMOD1 = 1, double baud rate */
serial port in mode 1, 8-bit UART data */
timer 1 in mode 2, 8-bit autoreload */
reload value for 2400 bauds @ 12MHz */
turn on timer 1 */
indicator ready to transmit */
void main(void)
{
serial_init(); /* serial initialisation */
printf(“ ATMEL T89C51CC01\n”);
/* welcome */
printf(“
RS232 Program Example\n\n”); /* message */
while(1);
/* start of endless loop */
}
Figura 5.6.- Ejemplo de utilización de la librería ‘stdio.h’
Se habla de un error aceptable para comunicaciones seriales un valor que no supere el 2,5%
de error en la velocidad de transferencia ya que la comunicación a través del puerto RS-232 es
extremadamente sensible a fluctuaciones
29
140
La utilización de esta librería se ejemplifica en el proyecto rs232.uv2 en
donde se verá la inclusión de ésta en el programa principal. Además es
necesario hacer notar que tanto el programa dado en el ejemplo como el que
está en el proyecto hace uso de retardos por software mediante el uso de la
función ‘void delay(Uint16)’ y de retardos por hardware haciendo uso del Timer
1 como temporizador para generar la velocidad de transferencia necesaria para
enviar mensajes por el puerto RS-232, otro punto a destacar es que el
programa que se da en el proyecto hace uso de interrupciones por hardware
presionando el botón de interrupción ‘INT1’, finalmente la estructura del
programa se muestra en la Figura 5.7.
Figura 5.7.- Estructura del proyecto ‘rs232’
Se dejará como labor para el alumno compilar el programa escrito y
programar el kit de desarrollo para generar distintas velocidades de transmisión
141
del puerto RS-232. Las velocidades requeridas van desde 2400 hasta
57600bps tal como se indica en la Tabla 5.6.
Tabla 5.6.- Velocidades de transmisión requeridas para la configuración del puerto RS-232
Velocidad de transmisión
[bps]
57600
38400
19200
14400
9600
4800
2400
1200
Temporizador
Timer 2
Timer 2
Timer 2
Timer 2
Timer 2
Timer 0/1
Timer 0/1
Timer 0/1
Para la visualización de mensajes entregados por el microcontrolador a
través del puerto de comunicaciones RS-232, el kit de desarrollo debe
conectarse al puerto de comunicaciones serie de un computador y utilizar un
terminal RS-232 estándar como Hyperterminal tal como se muestra en la
Figura 5.8.
142
Figura 5.8.- Conexión entre el PC y el kit de desarrollo CAN para visualizar mensajes mediante
RS-232
El puerto COM del PC conectado al kit de desarrollo debe configurarse
como X-8-N-1-N, en donde el valor de ‘X’ está dado por la velocidad que se
configuró el kit de desarrollo (Figura 5.9).
143
Figura 5.9.- Configuración del puerto RS-232
5.2.- ESTUDIO DE LA CAPA FÍSICA Y DE ENLACE DE DATOS DEL
PROTOCOLO CAN
El propósito de este laboratorio es familiarizar al alumno con el estudio
de la capa física y de enlace de datos del protocolo CAN haciendo uso del kit
de desarrollo, para ello es necesario abarcar los siguientes aspectos:
•
Enseñar los niveles de voltaje e impedancia que maneja el protocolo
CAN.
•
Explicar cómo crear un nodo para generar transmisión y recepción de
mensajes utilizando las librerías entregadas por el fabricante.
•
Mostrar la estructura general de una trama CAN, campos de:

SOF (inicio de trama)

Identificador (estándar o extendido)
144
•

Control (tipo de trama y número de bytes de datos)

Datos (mensaje de hasta 8 bytes)

CRC (detección de errores)

ACK (acuse de recibo)

EOF (fin de trama)
Detallar la configuración de los registros necesarios para obtener
comunicaciones a distintas velocidades.
Este laboratorio consta de utilizar las librerías CAN entregadas por el
fabricante para la programación del kit de desarrollo, se entregará al alumno
4 programas escritos en C que mostrarán el uso de:
•
Envío y recepción de distintos mensajes CAN (tramas de datos y
remotas) a distintas velocidades.
•
Rutinas de envío secuencial y recepción de mensajes CAN, mostrados
en la barra de LED’s, el panel LCD y el puerto RS-232.
5.2.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE
Para la puesta en funcionamiento del kit de desarrollo es necesario
contar con herramientas de software y de hardware que se enumerarán a
continuación:
145
Tabla 5.7.- Requerimientos de software y de hardware para el laboratorio nº2
Requerimientos
Requerimientos de
Software
Requerimientos de
Hardware
Herramientas
Entorno de desarrollo integrado: Keil C51
Herramienta de programación del sistema: Atmel FLIP
Utilidad para calcular la velocidad de bit para el bus CAN en el
kit de desarrollo: X-Calculator
Código de fuente de los programas ‘can_tx’, ‘can_rx’,
‘can_gen’ y ‘can_mon’
Programas compilados en formato hexadecimal ‘can_tx.hex’,
‘can_rx.hex’, ‘can_gen.hex’ y ‘can_mon.hex’
Dos kits de desarrollo CAN además de sus respectivos
microcontroladores del tipo T89C51CC01UA-SLSIM
Un Cable Serie RS-232 DB9/DB9 (Macho/Hembra) para la
comunicación entre el kit de desarrollo y el computador
Un Cable Serie RS-232 DB9/DB9 (Macho/Macho) para la
comunicación entre ambos kits de desarrollo
5.2.2.- LIBRERÍA DE COMUNICACIÓN CAN
En estos laboratorios se describirá la utilización del bus CAN para el kit
de desarrollo utilizando la librería CAN entregada por el fabricante, ésta librería
contiene los siguientes archivos:
•
can_lib.c
•
can_lib.h
La cual consta de 5 definiciones de tipos y 14 funciones que pueden
ser llamadas únicamente si se incluye la cabecera del programa que lo va a
utilizar, las definiciones de tipo que entrega son las siguientes:
can_data_t: Uchar

can_data: campo de datos del mensaje CAN
can_id_t: union

Uint32 ext: permite el acceso al identificador de 29 bits (modo extendido)

Uint16 std: permite el acceso al identificador de 11 bits (modo estándar)

Uchar tab[4]: permite el acceso por byte al identificador
146
can_msg_t: struct

can_id_t id: identificador del mensaje CAN, 11 bits en modo estándar y 29
bits en modo extendido

Uchar ctrl: define cierta información específica como RTR, IDE y los bits
DLC

bit 5: RTR ⇒ trama de datos = 0 o trama remota = 1 (se accede por
MSK_CTRL_RTR)

bit 4: IDE ⇒ identificador estándar = 0 o identificador extendido = 1 (se accede
por MSK_CTRL_IDE)

bits 3-0: DLC ⇒ número de bytes de datos a transmitir (se accede por
MSK_CTRL_DLC)

Uchar *pt_data: puntero a la tabla que contiene los datos para enviar o
recibir
channel_t: enum

channel: CHANNEL_0 … CHANNEL_14
dlc_t: enum

dlc: DLC_0 … DLC_8
Las funciones encargadas de inicializar los parámetros de configuración
son las siguientes:
void ClearAllMailbox(void): Función que se utiliza para borrar toda la
memoria RAM del controlador CAN
void CanSetBRP(Uchar prescaler): Función que se utiliza para inicializar el
parámetro BRP (Baud Rate Prescaler) del controlador CAN con el
parámetro ‘prescaler’
void CanSetSJW(Uchar sjw): Función que se utiliza para inicializar el
parámetro SJW (re-Synchronization Jump Width) del controlador CAN con
el parámetro ‘sjw’
void CanSetPRS(Uchar prs): Función que se utiliza para inicializar el
147
parámetro PRS (Propagation time Segment) del controlador CAN con el
parámetro ‘prs’
void CanSetPHS1(Uchar phs1): Función que se utiliza para inicializar el
parámetro PHS1 (Phase Segment 1) del controlador CAN con el parámetro
‘phs1’
void CanSetPHS2(Uchar phs2): Función que se utiliza para inicializar el
parámetro PHS2 (Phase Segment 2) del controlador CAN con el parámetro
‘phs2’
Las funciones encargadas de inicializar los parámetros encargados de la
transmisión y recepción de mensajes son las siguientes:
void ConfChannel_Rx(void): Función que se utiliza para configurar un canal
en el modo de recepción. Antes de llamar a esta función el canal
correspondiente debe estar seleccionado, asegurándose de que el canal
esté libre porque no se lleva a cabo ninguna verificación de esto por la
función. El identificador de filtrado y de enmascaramiento son inicializados
con los valores contenidos en las variables globales ‘can_rx_filt’ y
‘can_rx_msk’, la configuración se define en la variable global ‘conf_rx’, las
variables globales utilizadas se detallan a continuación:

can_id_t can_rx_filt: Valor de filtro del identificador

can_id_t can_rx_msk: Valor de enmascaramiento del identificador

Uchar conf_rx: Configuración utilizada para el canal de recepción

bit
7:
MSK_RTR
⇒
sin
enmascaramiento
del
campo
RTR
(CONF_NOMSK_RTR) o enmascaramiento del campo RTR (CONF_MSK_RTR)

bit 6: MSK_IDE ⇒ sin enmascaramiento del campo IDE (CONF_NOMSK_IDE) o
enmascaramiento del campo IDE (CONF_MSK_IDE)

bit 5: RTR ⇒ si es que existe enmascaramiento del campo RTR se aceptará
solamente tramas de datos (CONF_NORTR) o tramas remotas (CONF_RTR)

bit 4: IDE ⇒ si es que existe enmascaramiento del campo IDE se aceptará
148
solamente
identificadores
estándar
(CONF_NOIDE)
o
identificadores
extendidos (CONF_IDE)

bit
0:
BUFFER
⇒
configura
el
canal
en
recepción
sin
buffer
(CONF_NOBUFFER) o en recepción con buffer (CONF_BUFFER)
void SendCanMsg(void): Esta función se utiliza enviar un mensaje en el bus
CAN. Antes de llamar a esta función el canal correspondiente debe estar
seleccionado, asegurándose de que el canal esté libre porque no se lleva a
cabo ninguna verificación de esto por la función. El identificador a enviar se
declara en la variable global ‘can_id_tx’ y los datos a transmitir son
declarados en la variable global ‘pt_candata_tx’, la configuración se define
en la variable global ‘conf_tx’, las variables globales utilizadas se detallan a
continuación:

can_id_t can_tx_id: Valor del identificador a transmitir

Uchar *pt_candata_tx: Puntero a la tabla con los datos a transmitir

Uchar conf_tx: Configuración utilizada para la transmisión

bit 5: RTR ⇒ trama de datos (CONF_NORTR) o trama remota (CONF_RTR)

bit 4: IDE ⇒ identificador estándar (CONF_NOIDE) o identificador extendido
(CONF_IDE)

bits 3-0: DLC ⇒ número de bytes de datos a transmitir (se utiliza ‘dlc_t’,
CONF_DLC_0 … CONF_DLC_8)
void ReadCanMsg(Uchar next_conf): Esta función se utiliza recibir un
mensaje en el bus CAN. Esta función lee el mensaje recibido en el canal
‘num_channel’ y lo almacena en una estructura del tipo ‘pt_st_can_rx’ para
posteriormente configurar el canal en que se recibió el mensaje con una
nueva configuración entregada a través del parámetro ‘next_conf’, la
configuración puede ser:

CHANNEL_DISABLE: El canal quedará deshabilitado

CHANNEL_RX_ENABLE: El canal quedará habilitado en el modo recepción

CHANNEL_RXB_ENABLE: El canal quedará habilitado en el modo
recepción con búfer
149
finalmente la variable global utilizada se detallan a continuación:

can_msg_t *pt_st_can_rx: Puntero a la estructura que contendrá el
mensaje a recibir
Las funciones utilizadas para manejar las interrupciones son las
siguientes:
void fct_can_it(void): Función que se encarga de manejar las interrupciones
asociadas al bus CAN, esta a su vez puede llamar a 4 funciones:

void fct_can_it_txok(void): Esta función es llamada cuando un mensaje
es transmitido, para usar esta función debe:

Definir esta rutina en el archivo ‘config.h’:
#define USER_CAN_FCT_IT_TXOK


Crear esta función en el espacio de trabajo
void fct_can_it_rxok(void): Esta función es llamada cuando un mensaje
es recibido, para usar esta función debe:

Definir esta rutina en el archivo ‘config.h’:
#define USER_CAN_FCT_IT_RXOK


Crear esta función en el espacio de trabajo
void fct_can_it_error(void): Esta función es llamada cuando ocurre un
error en un canal específico, para usar esta función debe:

Definir esta rutina en el archivo ‘config.h’:
#define USER_CAN_FCT_IT_ERROR


Crear esta función en el espacio de trabajo
void fct_can_it_gen(void): Esta función es llamada cuando ocurre un
error en cualquier canal, para usar esta función debe:

Definir esta rutina en el archivo ‘config.h’:
#define USER_CAN_FCT_IT_GEN

Crear esta función en el espacio de trabajo
void fct_can_timovf_it(void): Función que se encarga de manejar la
150
interrupción producida por el desbordamiento del temporizador CAN, ésta,
a su vez, puede llamar a la siguiente función:

void fct_can_it_timovf(void): Esta función es llamada cuando el
temporizador CAN se desborda desde ‘0xFFFF’ a ‘0x0000’, para usar esta
función debe:

Definir esta rutina en el archivo ‘config.h’:
#define USER_CAN_FCT_IT_TIMOVF

Un
Crear esta función en el espacio de trabajo
ejemplo
de
la
utilización
del
archivo
‘config.h’
para
la
inclusión/exclusión de rutinas de interrupción (Figura 5.10) además del código
de las rutinas de interrupción (Figura 5.11) se muestran a continuación.
/******************************************************************************
* FILE_NAME: config.h
*
*-----------------------------------------------------------------------------*
* FILE_PURPOSE: This file is included by all source files in order to access *
*
to system wide configuration
*
******************************************************************************/
#ifndef _CONFIG_H_
#define _CONFIG_H_
#include <t89c51cc01.h>
#include "compiler.h"
/* prototypes declaration */
#define USER_CAN_FCT_IT_TXOK
#define USER_CAN_FCT_IT_RXOK
#undef USER_CAN_FCT_IT_ERROR
#undef USER_CAN_FCT_IT_GEN
#undef USER_CAN_FCT_IT_TIMOVF
#endif /* _CONFIG_H_ */
Figura 5.10.- Ejemplo de utilización del archivo ‘config.h’ para la definición de rutinas
151
void fct_can_it(void) interrupt 7
{
save_canpage = CANPAGE;
/* save the current CANPAGE */
channel = FindFirstChIt(); /* find first channel interrupt */
if(channel ¡= NO_CHANNEL)
{
CAN_SET_CHANNEL(channel);
bit_var = CANSTCH;
/* tx or rx interrupt */
if(IT_TXOK)
{
#ifdef USER_CAN_FCT_IT_TXOK
can_fct_it_txok();
#endif /* USER_CAN_FCT_IT_TXOK */
}
if(IT_RXOK)
{
#ifdef USER_CAN_FCT_IT_RXOK
can_fct_it_rxok();
#endif /* USER_CAN_FCT_IT_RXOK */
}
/* error analysis */
if(¡IT_RXOK && ¡IT_TXOK)
{
#ifdef USER_CAN_FCT_IT_ERROR
can_fct_it_error();
#endif /* USER_CAN_FCT_IT_ERROR */
}
CANSTCH = 0x00; /* clear all channel status registers */
}
else /* (channel == NO_CHANNEL) */
{
/* no channel match with the interrupt => general it */
#ifdef USER_CAN_FCT_IT_GEN
can_fct_it_gen();
#endif /* USER_CAN_FCT_IT_GEN */
CANGIT &= 0xF0; /* clear all general errors */
}
CANPAGE = save_canpage; /* restore the old config */
}
void fct_can_timovf_it(void) interrupt 9
{
#ifdef USER_CAN_FCT_IT_TIMOVF
can_fct_it_timovf();
#endif /* USER_CAN_FCT_IT_TIMOVF */
CANGIT &= ~MSK_CANGIT_OVRTIM; /* clear overrun timer */
}
Figura 5.11.- Código de las rutinas de interrupción de la librería CAN
152
5.2.3.- LABORATORIO Nº2.1
En este laboratorio se ejemplificará la creación de un nodo transmisor y
receptor de mensajes CAN utilizando las librerías del fabricante, se verá la
configuración de la velocidad del sistema, la habilitación de las interrupciones
que permiten la transmisión y recepción de mensajes, tipos de tramas y filtrado
de mensajes visualizándolos en el puerto RS-232 tanto en el programa de
transmisión como el de recepción de tramas.
En primer lugar se verá la utilización en un programa encargado de
transmitir mensajes, a modo de ejemplo se muestra un programa en la
Figura 5.12 que envía mensajes con un identificador estándar ‘0x123’ y 8 bytes
de datos ‘{0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88}’ a una velocidad de
500Kbps cada 250ms.
153
/******************************************************************************
* FILE_NAME: main.c
*
*-----------------------------------------------------------------------------*
* FILE_PURPOSE: This file is a simple CAN transmission sample software
*
******************************************************************************/
#include "config.h"
#include "can_lib.h"
Uint16 i;
can_data_t xdata data_tx = {0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88};
can_msg_t xdata msg_tx = {STD_ID(0x0123), CONF_NOIDE | CONF_NORTR | CONF_DLC_8,
data_tx};
void delay(Uint16 tempo)
{
for(i=0; i<tempo; i++);
}
void can_init(void)
{
CAN_CONTROLLER_RESET;
ClearAllMailbox();
CanSetBRP(BRP_500k);
CanSetSJW(SJW_500k);
CanSetPRS(PRS_500k);
CanSetPHS1(PHS1_500k);
CanSetPHS2(PHS2_500k);
CAN_CONTROLLER_ENABLE;
CAN_IT_ENABLE;
CAN_TX_IT_ENABLE;
}
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
reset can controller */
clear all ram of can controller */
configure can baud rate prescaler*/
configure can re-synchronization jump width */
configure can propagation time segment */
configure can phase segment 1 */
configure can phase segment 2 */
enable can controller */
enable can interrupts */
enable can transmission interrupt */
void can_fct_it_txok(void)
{
channel = CAN_GET_CHANNEL;
/* get interrupted channel */
CAN_CHANNEL_IT_DISABLE(channel); /* disable interrupt on channel */
}
void main(void)
{
can_init();
/* can initialisation */
EA = 1;
/* enable all interrupts
while(1)
/* start of endless loop */
{
delay(0xC350);
/*
can_tx_id
= msg_tx.id;
/*
conf_tx
= msg_tx.ctrl;
/*
pt_candata_tx = msg_tx.pt_data;
/*
CAN_SET_CHANNEL(CHANNEL_0);
/*
CAN_CHANNEL_IT_ENABLE(CHANNEL_0); /*
SendCanMsg();
/*
}
}
*/
delay for approx. 250ms */
message identifier */
message configuration */
message data pointer */
select message channel */
enable interrupt on channel */
send message */
Figura 5.12.- Ejemplo de utilización de la librería CAN para la transmisión de mensajes
154
En segundo lugar se verá la utilización en un programa encargado de
recibir mensajes, a modo de ejemplo se muestra un programa en la Figura 5.13
que sólo recibe mensajes con identificadores estándar que comienzan con
‘0x012X’ a una velocidad de 500kbps.
/******************************************************************************
* FILE_NAME: main.c
*
*-----------------------------------------------------------------------------*
* FILE_PURPOSE: This file is a simple CAN reception sample software
*
******************************************************************************/
#include "config.h"
#include "can_lib.h"
can_data_t xdata data_rx = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
can_msg_t xdata msg_rx = {0x00, 0x00, data_rx};
void can_init(void)
{
CAN_CONTROLLER_RESET;
/* reset can controller */
ClearAllMailbox();
/* clear all ram of can controller */
CanSetBRP(BRP_500k);
/* configure can baud rate prescaler*/
CanSetSJW(SJW_500k);
/* configure can re-synchronization jump width */
CanSetPRS(PRS_500k);
/* configure can propagation time segment */
CanSetPHS1(PHS1_500k); /* configure can phase segment 1 */
CanSetPHS2(PHS2_500k); /* configure can phase segment 2 */
can_rx_filt.std = 0x012F;
/* accept only identifier */
can_rx_msk.std = 0x0120;
/* start by 0x012X */
conf_rx = CONF_NOIDE|CONF_MSK_IDE; /* accept only standard identifier */
CAN_SET_CHANNEL(CHANNEL_0);
/* select message channel */
CAN_CHANNEL_IT_ENABLE(CHANNEL_0);
/* enable interrupt on channel */
ConfChannel_Rx();
/* configure channel for reception */
CAN_CONTROLLER_ENABLE; /* enable can controller */
CAN_IT_ENABLE;
/* enable can interrupts */
CAN_RX_IT_ENABLE;
/* enable can reception interrupt */
}
void can_fct_it_rxok(void)
{
pt_st_can_rx = &msg_rx;
ReadCanMsg(CHANNEL_RX_ENABLE);
}
/* message data struct pointer */
/* read message and configure channel */
void main(void)
{
can_init(); /* can initialisation */
EA = 1;
/* enable all interrupts */
while(1);
/* start of endless loop */
}
Figura 5.13.- Ejemplo de utilización de la librería CAN para la recepción de mensajes
155
Hay que tomar énfasis que el recibir mensajes es un poco más complejo
que enviarlos ya que a diferencia de la transmisión, que se sabe exactamente
cuándo y cómo será enviado, en la recepción se tiene la incertidumbre del
momento y forma serán recibidos, por lo que hay que tomar las
consideraciones necesarias para este propósito.
La utilización de esta librería se ejemplifica en los proyectos can_tx.uv2
y can_rx.uv2 en donde se verá la inclusión de ésta en el programa principal
Además es necesario hacer notar que el programa dado que está en el
proyecto hace uso de la librería ‘bg.h’ y la librería ‘lcd.h’ además de la
configuración del puerto serie para mostrar los mensajes enviados y recibidos
por los nodos a una velocidad de 9600bps, otro punto a destacar es que el
programa que se da en el proyecto hace uso de interrupciones por hardware
presionando el botón de interrupción ‘INT1’ para ambos programas, en el
programa de envío actúa como iniciador de envío de mensajes mientras que en
el programa de recepción se encarga de mostrar el último mensaje enviado
hacia el bus CAN por el puerto RS-232, finalmente se entrega la estructura de
ambos programas en la Figura 5.14.
156
Figura 5.14.- Estructura de los proyectos ‘can_tx’ y ‘can_rx’
Se dejará como labor para el alumno compilar el programa escrito y
programar el kit de desarrollo para generar distintas velocidades de transmisión
para el bus CAN utilizando el programa ‘X-Calculator’ disponible en la página
del fabricante, como se muestra en la Figura 5.15.
157
Figura 5.15.- Utilidad para calcular la velocidad de bit para el bus CAN en el kit de desarrollo
Las velocidades a configurar por el alumno serán las mostradas en la
Tabla 5.8.
Tabla 5.8.- Velocidades de transmisión requeridas para la configuración del bus CAN
Velocidad de
transmisión [kbps]
500
250
100
Sample Point [%]
80 a 90
80 a 90
80 a 90
Como tarea adicional, el alumno deberá generar las configuraciones
indicadas en la Tabla 5.9 y Tabla 5.10 para el nodo transmisor y receptor
respectivamente.
158
Tabla 5.9.- Configuraciones requeridas para el nodo transmisor
Canal
0
1
2
3
4
5
Identificador
STD: 0123
STD: 0011
STD: 0321
EXT: 01234567
EXT: 00110022
EXT: 07654321
Trama
Datos
Datos
Remota
Datos
Datos
Remota
Longitud
8 bytes
4 bytes
6 bytes
8 bytes
4 bytes
6 bytes
Datos
11, 22, 33, 44, 55, 66, 77, 88
12, 34, 56, 78
11, 22, 33, 44, 55, 66, 77, 88
12, 34, 56, 78
-
Tabla 5.10.- Configuraciones requeridas para el nodo receptor
Canal
0
1
2
3
4
5
Filtro de Identificador
STD: 012X
STD: 001X
STD: 032X
EXT: 012345XX
EXT: 001100XX
EXT: 076543XX
Filtro de Trama
Datos y Remota
Datos
Remota
Datos y Remota
Datos
Remota
Para la visualización de mensajes enviados/recibidos por el bus CAN, se
puede conectar el puerto RS-232 del kit de desarrollo al puerto de
comunicaciones serie de un computador y configurarse como 9600-8-N-1-N, el
montaje utilizado se muestra en la Figura 5.16.
159
Figura 5.16.- Conexión entre el PC y el kit de desarrollo CAN para visualizar los mensajes de
los nodos trasmisor y receptor mediante RS-232
5.2.4.- LABORATORIO Nº2.2
En este laboratorio se ejemplificará la creación de un nodo transmisor y
receptor de mensajes CAN utilizando las librerías ‘bg.h’ y ‘lcd.h’ para poder
visualizar mensajes enviados a través del bus CAN haciendo uso de la barra de
LED’s y visualizándolos en la pantalla LCD y el puerto RS-232 tanto en el
programa de transmisión como el de recepción de tramas.
160
En primer lugar se verá la utilización en un programa encargado de
transmitir mensajes que se mostrará en el panel LCD y el puerto RS-232 con
identificador estándar que parte con el valor hexadecimal ‘0x0001’ y se irá
incrementando cada vez que se envía un mensaje, el campo de datos enviado
será de 8 bytes el cual partirá inicialmente con el valor ‘{0x11, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00}’ y se irá rotando e incrementando el byte más
significativo con el valor hexadecimal ‘0x11’ cada vez que se presiona el botón
de interrupción ‘INT1’.
Mientras que en segundo lugar el receptor será capaz de mostrar
cualquier mensaje de datos con identificador estándar que se transmita por el
bus CAN, en el panel LCD y el puerto RS-232. Adicionalmente cada vez que se
presiona el botón de interrupción ‘INT1’ se mostrará el último mensaje recibido
por el bus CAN en el puerto RS-232, la secuencia de los primeros 8 mensajes
que mostrará el panel LCD tanto el transmisor como el receptor se muestra en
la Figura 5.17.
Figura 5.17.- Serie de datos mostrados en el panel LCD
161
Los programas de los que se habla anteriormente se encuentran en los
proyectos can_gen.uv2 y can_mon.uv2, finalmente la estructura (Figura 5.14)
y montaje (Figura 5.16) es el mismo que el del ‘Laboratorio nº2.1’.
5.3.- ESTUDIO DE APLICACIONES GATILLADAS EN EL TIEMPO
El propósito de este laboratorio es familiarizar al alumno con el estudio
de aplicaciones gatilladas en el tiempo para realizar tareas que requieran cierta
periodicidad, para ello es necesario abarcar los siguientes aspectos:
•
Explicar cómo construir una aplicación basada en el tiempo para
sistemas empotrados.
•
Mostrar la implementación de programas que hagan uso de tareas
gatilladas en el tiempo.
•
Mostrar un programa que haga uso de interrupciones y retardos por
hardware.
Este laboratorio consta en ver la estructura de programas gatillados en
el tiempo implementados en el kit de desarrollo, se entregará al alumno
7 programas escritos en C que mostrarán el uso de:
•
Los proyectos de la barra de LED’s, la pantalla LCD, el puerto RS-232, el
envío secuencial y recepción de distintos mensajes CAN programados
como aplicaciones gatilladas en el tiempo.
•
Explicar mediante un programa el funcionamiento de 2 nodos actuando
cada uno tanto como transmisor y receptor de mensajes, el primer nodo
se encargará de generar 8 tipos distintos de mensajes de prueba
mientras que el segundo nodo se encargará de realizar funciones de
registro y replicación de datos.
162
5.3.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE
Para la puesta en funcionamiento del kit de desarrollo es necesario
contar con herramientas de software y de hardware que se enumerarán a
continuación:
Tabla 5.11.- Requerimientos de software y de hardware para el laboratorio nº3
Requerimientos
Requerimientos de
Software
Requerimientos de
Hardware
Herramientas
Entorno de desarrollo integrado: Keil C51
Herramienta de programación del sistema: Atmel FLIP
Código de fuente de los programas ‘display’, ‘bargraph’,
‘rs232’, ‘can_gen’, ‘can_mon’, ‘can_tst’ y ‘can_log’
Programas compilados en formato hexadecimal ‘display.hex’,
‘bargraph.hex’, ‘rs232.hex’, ‘can_gen.hex’, ‘can_mon.hex’,
‘can_tst.hex’ y ‘can_log.hex’
Dos kits de desarrollo CAN además de sus respectivos
microcontroladores del tipo T89C51CC01UA-SLSIM
Un Cable Serie RS-232 DB9/DB9 (Macho/Hembra) para la
comunicación entre el kit de desarrollo y el computador
Un Cable Serie RS-232 DB9/DB9 (Macho/Macho) para la
comunicación entre ambos kits de desarrollo
5.3.2.- ESTRUCTURA DE APLICACIONES GATILLADAS EN EL TIEMPO
En estos laboratorios se describirá la creación de aplicaciones
gatilladas en el tiempo. La creación de una aplicación gatillada en el tiempo
se hace a través de un itinerario de tareas (schedule task), que puede ser visto
como un sencillo sistema operativo que permite la llamada a las tareas de
forma periódica o (de forma menos frecuente) la llamada a una sola tarea.
Desde el punto de vista de niveles más bajos, un itinerario de tareas puede ser
visto como una sencilla temporización usando interrupciones mediante un reloj
para generar rutinas que pueden ser compartidas entre diferentes tareas, como
resultado un solo reloj debe ser iniciado para ejecutar una, diez o cien tareas
diferentes, la estructura de un programa que hace uso de itinerarios se puede
ver en la Figura 5.18 y Figura 5.19.
163
/******************************************************************************
* FILE_NAME: main.c
*
*-----------------------------------------------------------------------------*
* FILE_PURPOSE: This file is a schedule program example.
*
******************************************************************************/
#include "config.h"
#include "schedule.h"
void timer1_init(void)
{
TMOD |= 0x10;
/*
TH1 = 0xF8;
/*
TL1 = 0x52;
/*
ET1 = 1;
/*
TR1 = 1;
/*
}
timer 1 in mode 1, 16 bit mode */
reload value for */
timer 1 at 2ms */
enable timer 1 interrupt */
turn on timer 1 */
void main(void) /* main code */
{
timer1_init();
/* timer 1 initialisation */
schedule_init();
/* schedule initialisation */
EA = 1;
/* enable all interrupts */
while(1)
/* start of endless loop */
{
schedule(); /* schedule task */
}
}
void fct_timer1_it(void) interrupt 3
{
TH1 = 0xF8;
/* reload value for */
TL1 = 0x52;
/* timer 1 at 2ms */
TF1 = 0;
/* clear interrupt flag */
activate_new_schedul(); /* create new schedule */
}
Figura 5.18.- Estructura general del programa principal escrito en C para aplicaciones
gatilladas en el tiempo
164
/******************************************************************************
* FILE_NAME: schedule.c
*
*-----------------------------------------------------------------------------*
* FILE_PURPOSE: This file is a schedule tasking example.
*
******************************************************************************/
#include
#include
#include
#include
#include
"config.h"
"schedule.h"
"task_1.h"
"task_2.h"
"task_3.h"
Uchar task_in_progress;
void call_next_task(void)
{
EA = 0;
/* disable all interrupts */
task_in_progress++; /* assign next task */
EA = 1;
/* enable all interrupts */
}
void schedule_init(void)
{
task_1_init();
task_2_init();
task_3_init();
task_in_progress = 1;
}
/*
/*
/*
/*
void schedule(void)
{
switch(task_in_progress)
{
case 1:
{
task_1();
call_next_task();
break;
}
case 2:
{
task_2();
call_next_task();
break;
}
case 3:
{
task_3();
call_next_task();
break;
}
default:
{
break;
}
}
}
task 1
task 2
task 3
assign
initialisation */
initialisation */
initialisation */
first task */
/* task 1 */
/* call next task */
/* break */
/* task 2 */
/* call next task */
/* break */
/* task 3 */
/* call next task */
/* break */
/* break */
165
void activate_new_schedul(void)
{
task_in_progress = 1;
/* assign first task */
}
Figura 5.19.- Estructura general del itinerario de tareas escrito en C para aplicaciones
gatilladas en el tiempo
5.3.3.- LABORATORIO Nº3.1
En esta primera serie de laboratorios se mostrará al alumno una
variación de los proyectos de la barra de LED’s, la pantalla LCD y el puerto
RS-232 programados como aplicaciones gatilladas en el tiempo, los proyectos
son bargraph.uv2, display.uv2 y rs232.uv2 y la estructura de los programas
de muestran en la Figura 5.20.
166
a) Proyecto ‘bargraph’
b) Proyecto ‘display’
c) Proyecto ‘rs232’
Figura 5.20.- Estructura de los proyectos ‘bargraph’, ‘display’ y ‘rs232’
167
5.3.4.- LABORATORIO Nº3.2
En la segunda serie de laboratorios se mostrará al alumno una variación
de los proyectos de transmisión y recepción de mensajes CAN programados
como aplicaciones gatilladas en el tiempo, los proyectos son can_tx.uv2 y
can_rx.uv2.
El primer programa consiste en transmitir mensajes con un identificador
estándar que se irá incrementando cada vez que se envía un mensaje, la trama
de datos consiste en 8 bytes los cuales se irán rotando e el byte más
significativo cada 2 segundos, además el cada vez que se presione el botón de
interrupción ‘INT1’ se enviará instantáneamente el mensaje almacenado sin la
necesidad de esperar los 2 segundos.
Mientras que en segundo lugar el receptor será capaz de mostrar
cualquier mensaje de datos con identificador estándar que se transmita por el
bus CAN en el panel LCD y el puerto RS-232, adicionalmente cada vez que se
presiona el botón de interrupción ‘INT1’ se mostrará el último mensaje recibido
por el bus CAN en el puerto RS-232.
168
Figura 5.21.- Estructura de los proyectos ‘can_tx’ y ‘can_rx’
5.3.5.- LABORATORIO Nº3.3
En la tercera serie de laboratorios se mostrará al alumno proyectos de
transmisión y recepción de mensajes CAN actuando como generador de
mensajes de prueba y de adquisición de datos programados como
aplicaciones gatilladas en el tiempo, los proyectos son can_tst.uv2 y
can_log.uv2.
En primer lugar, se verá la utilización en un programa encargado de
transmitir 8 tipos de mensajes secuenciales con identificadores estándar y
extendidos y se irá incrementando cada vez que se envía un mensaje, se
169
enviarán tramas remotas y de datos el que será variable además de ir rotando e
incrementando el byte más significativo cada 2 segundos, el cambio del tipo de
mensaje se hará cada vez que se presiona el botón de interrupción ‘INT1’; por
otro lado también será capaz de recibir mensajes e irá generando la misma
secuencia de mensajes anteriormente descrita según el último tipo de mensaje
recibido.
Mientras que en segundo lugar, el segundo programa será capaz de
mostrar cualquier mensaje ya sea con identificador estándar o extendido y
tramas remotas o de datos que se transmita por el bus CAN en el panel LCD y
el puerto RS-232, adicionalmente cada vez que se presiona el botón de
interrupción ‘INT1’ se mostrará el último mensaje recibido por el bus CAN en el
puerto RS-232.
Para la visualización de mensajes enviados/recibidos por el bus CAN, se
puede conectar el puerto RS-232 del kit de desarrollo al puerto de
comunicaciones serie de un computador y configurarse como 9600-8-N-1-N, el
montaje utilizado se muestra en la Figura 5.22.
170
Figura 5.22.- Conexión entre el PC y el kit de desarrollo CAN para visualizar los mensajes de
los nodos trasmisores/receptores mediante RS-232
5.4.- IMPLEMENTACIÓN DE APLICACIONES QUE HAGAN USO DEL
MODELO DE COMUNICACIÓN CAN
El propósito de este laboratorio es familiarizar al alumno con las
capacidades del bus CAN para implementar los distintos modelos de control
que permite el protocolo. Debido a que el sistema de comunicación está
basado en el modelo productor/consumidor, admite los modelos de control
multimaestro, maestro/esclavo, punto a punto, etc… el cual permite la
171
transmisión de mensajes mediantes diferentes métodos tales como sondeo,
muestreo, producción cíclica y cambio de estado.
En primera instancia se ejemplificará un control gatillado por eventos en
un esquema de comunicación multimaestro y en segundo lugar un control
cíclico en un esquema de comunicación maestro/esclavo tomando énfasis en
la programación orientada a la creación de aplicaciones de control en donde se
visualizarán las funciones de:
•
Sensor/Actuador (Esclavo).
•
Controlador (Maestro).
Se explicará la función que cumple los distintos tipos de mensajes en el
bus CAN para cada modelo de comunicación implementado emulando una red
de control.
5.4.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE
Para la puesta en funcionamiento del kit de desarrollo es necesario
contar con herramientas de software y de hardware que se enumerarán a
continuación:
172
Tabla 5.12.- Requerimientos de software y de hardware para el laboratorio nº4
Requerimientos
Requerimientos de
Software
Requerimientos de
Hardware
Herramientas
Entorno de desarrollo integrado: Keil C51
Herramienta de programación del sistema: Atmel FLIP
Código de fuente de los programas ‘can_trn_n1’, ‘can_trn_n2’,
‘can_air_mst’ y ‘can_air_slv’
Programas compilados en formato hexadecimal
‘can_trn_n1.hex’, ‘can_trn_n2.hex’, ‘can_air_mst.hex’ y
‘can_air_slv.hex’
Dos kits de desarrollo CAN además de sus respectivos
microcontroladores del tipo T89C51CC01UA-SLSIM
Un Cable Serie RS-232 DB9/DB9 (Macho/Hembra) para la
comunicación entre el kit de desarrollo y el computador
Un Cable Serie RS-232 DB9/DB9 (Macho/Macho) para la
comunicación entre ambos kits de desarrollo
5.4.2.- FLEXIBILIDAD DEL MODELO PRODUCTOR/CONSUMIDOR
El modelo productor/consumidor viene a cubrir las deficiencias del
antiguo modelo cliente/servidor, ya que los mensajes se identifican por su
contenido y ofrece las siguientes ventajas:
•
Múltiples nodos pueden consumir los mismos datos simultáneamente
desde un sólo productor.
•
Los nodos se pueden sincronizar fácilmente para obtener un
rendimiento más preciso del sistema.
•
Los dispositivos se pueden comunicar autónomamente, sin la necesidad
de un maestro de sistema.
La versatilidad que permite éste modelo de comunicación se puede
apreciar en la Figura 5.23, la cual muestra un resumen de su flexibilidad y
prestaciones.
173
Figura 5.23.- Resumen de la flexibilidad del modelo productor/consumidor
También éste modelo permite implementar el modelo cliente/servidor,
tomando en consideración que cada nodo debe identificar los campos de
origen y destino en el identificador, la Figura 5.24 muestra el formato de los
mensajes para cada uno de los modelos.
Figura 5.24.- Formato de mensajes en los modelos: a) cliente/servidor y b)
productor/consumidor
5.4.3.- MONTAJE DEL SISTEMA
El montaje de los laboratorios Nodo1/Nodo2 y Maestro/Esclavo,
mostrados a continuación, se muestra en la Figura 5.25.
174
Figura 5.25.- Montaje para los laboratorios Nodo1/Nodo2 y Maestro/Esclavo
5.4.4.- LABORATORIO Nº4.1
En este laboratorio se verá el funcionamiento de un sistema de control
por
cambio
de
estado,
utilizando
un
modelo
de
comunicación
productor/consumidor y una jerarquía multimaestro ejemplificado en un
sistema de control de poleas de una cinta transportadora.
Cada nodo será considerado como una estación de tambores motrices
de la cinta transportadora en donde cada nodo podrá gatillar la dirección y
estado (ON/OFF) de la cadena de correas transportadoras, las consideraciones
a tomar serán las siguientes:
175
•
Al iniciar la secuencia de encendido el estado de cada uno de los nodos
será de espera (standby).
•
Cada nodo será capaz de iniciar el arranque del sistema de correas
transportadoras.
•
Al desconectarse un nodo de la energía eléctrica y posteriormente volver
a conectarse, la secuencia de inicio deberá considerar preguntar al
sistema el estado de funcionamiento (dirección y estado) para ser capaz
de replicar su estado de funcionamiento.
•
El direccionamiento de los nodos debido a que la información puede ser
originada y/o recibida por cualquier nodo de la red, por lo que cada
nodo será capaz de identificar el tipo de direccionamiento entregado el
cual, por el tipo de control empleado, será broadcast.
El hecho de que cada nodo no transmita información hasta que se
modifica el estado de las variables se le conoce como control por cambio de
estado y el hecho de que sea capaz de generar tareas de control en el sistema
y por ende cada nodo puede actuar como: sensor, actuador y controlador se
conoce como un direccionamiento multimaestro.
5.4.5.- LABORATORIO Nº4.2
En este laboratorio se verá el funcionamiento de un sistema de control
cíclico, utilizando un modelo de comunicación cliente/servidor y una jerarquía
maestro/esclavo
ejemplificado
en
un
sistema
de
control
de
aire
acondicionado de una planta.
Existirá un nodo maestro que se encargará se ejercer el control en los
dispositivos esclavos, las consideraciones a tomar serán las siguientes:
•
La estación maestra podrá ejercer un control de temperatura para días
176
soleados y días nublados y ser capaz de identificar cada estación que
entrega el estado de la condición ambiental y temperatura de la planta.
•
Cada estación esclava deberá enviar en intervalos periódicos el estado
de la temperatura de la planta y de control ejercido sobre éste.
•
El direccionamiento de los nodos debido a que la información puede ser
originada y/o recibida por cualquier nodo de la red, por lo que cada
nodo será capaz de identificar el tipo de direccionamiento entregado el
cual, por el tipo de control empleado, será unicast.
•
Las estaciones deberán ser capaces de diferenciar entre lo que es
información de control y datos.
El hecho de que cada nodo no transmita información a la red en
intervalos de tiempo fijo se le conoce como control cíclico y el hecho de que
una estación funcione como controlador y sea capaz de generar tareas de
control en el sistema y las demás estaciones ejecuten acciones de sensor y
actuador en el sistema se conoce como un direccionamiento maestro/esclavo.
177
CAPÍTULO 6.- CONCLUSIONES
En base a la bibliografía consultada, se logró comprender los
fundamentos del protocolo CAN y sus características, como resultado de esto
se presentó un diseño de experiencias de laboratorio utilizando un kit de
desarrollo, permitiendo al alumno entender los aspectos más relevantes del
bus CAN y hacerse una idea de la implementación de los distintos modelos de
control en torno a este estándar.
La elección del set de experiencias de laboratorio no solamente ayuda al
aprendizaje del bus CAN, sino que además, contribuye a entender como
funcionan los buses de campo en general, ya que los aspectos a considerar
son similares en todos éstos, como por ejemplo, el que los nodos de un
sistema de control con reloj propio necesariamente deben ser configurados
para trabajar a la misma velocidad para que el sistema funcione
adecuadamente, además se debe considerar que en todo sistema de control
se debe asignar un direccionamiento para la comunicación entre los nodos,
entre otros aspectos relevantes.
Por otro lado, desde el punto de vista del diseño y programación de
sistemas
empotrados,
nos
permite
justificar
y
discutir
los
aspectos
relacionados con la creación de aplicaciones para microcontroladores, así
como, dejar en evidencia la importancia del diseño de software y el
conocimiento de la interfaz software/hardware.
Como aspectos transversales del estudio del bus CAN, se abarcan
aspectos relacionados con el estudio del lenguaje de programación C, el cual
corresponde al lenguaje más ampliamente difundido para crear aplicaciones en
microcontroladores, se añade además, el entendimiento de rutinas que hagan
178
uso de distintas filosofías de programación así como la importancia del uso de
interrupciones para facilitar la ejecución paralela de distintas tareas a la vez.
Finalmente, como trabajo futuro se pueden considerar el reforzar los
conocimientos de los distintos estándares existentes en torno a la capa de
aplicación que utilizan como base el protocolo CAN, así como también, buscar
potenciales aplicaciones para este kit de desarrollo, las cuales podrían incluir:
crear herramientas de diagnóstico del bus, crear interfaces para la
interpretación de datos de un sistema, generar rutinas de fiabilidad de un
sistema, o generar un sistema de control que cumpla con alguno de los
estándares de la capa aplicación basados en el protocolo CAN.
179
GLOSARIO
ACK
Acknowledge
ADC
Analog-to-Digital Converter
ANSI
American National Standards Institute
API
Application Program Interface
ASCII
American Standard Code for Information Interchange
AS-Interface
Actuator Sensor-Interface
CAL
CAN Application Layer
CAN
Controller Area Network
CiA
CAN in Automation
CIP
Control and Information Protocol
CMS
CAN based Message Specification
CPU
Central Processing Unit
CRC
Cyclic Redundancy Check
CSMA/CA
Carrier Sense Multiple Access with Collision Avoidance
CSMA/CD
Carrier Sense Multiple Access with Collision Detection
CSMA/NBA
Carrier Sense Multiple Access with Non-destructive Bitwise
Arbitration
CTRL
Control
DBT
Identifier Distributor
DCE
Data Communication Equipment
DLC
Data Length Code
DLL
Data Link Layer
DP
Decentralized Periphery
DS
Draft Standard
DTE
Data Terminal Equipment
ECU
Electronic Control Unit
180
EDS
Electronic Data Sheet
EEPROM
Electrically Erasable Programmable Read Only Memory
EIA
Electronic Industries Alliance
EN
Européenne Norme
EOF
End of Frame
EWC
Event and Waveform Controller
FLIP
Flexible In-System Programmer
GND
Ground
HART
Highway Addressable Remote Transducer
HLP
High Layer Protocol
ISP
In-System Programming
ISR
Interrupt Service Routine
I/O
Input/Output
ID
Identifier
IDE
Identifier Extension / Integrated Development Environment
IEC
International Electrotechnical Commission
LCD
Liquid Crystal Display
LED
Light-Emitting Diode
LLC
Logical Link Control
LME
Layer Management Entity
LMT
Layer Management
LSDU
Link Service Data Units
MAC
Medium Access Control
MAP
Manufacturing Automation Protocol
MCU
Microcontroller Unit
MDI
Medium Dependent Interfaz
MODEM
Modulator-Demodulator
NMT
Network Management
181
NRZ
Non-Return to Zero
OD
Object Dictionary
ODVA
Open DeviceNet Vendor Association
OOK
On-Off Keying
OS
Operating System
OSEK
Offene Systeme und deren schnittstellen für die Elektronik
im Kraftfahrzeug
OSI
Open System Interconnection
PC
Personal Computer
PCA
Programmable Counter Array
PDO
Process Data Object
PHY
Physical Layer
PLCC
Plastic Leaded Chip Carrier
PLL
Phase Locked Loop
PLS
Physical Signalling
PMA
Physical Medium Attachment
PROFIBUS
Process Field Bus
RAM
Random Access Memory
REC
Receive Error Counter
RJW
Re-synchronization Jump Width
RS
Recommended Standard
RTR
Remote Transmission Request
SAE
Society of Automotive Engineers
SDO
Service Data Object
SDS
Smart Distributed System
SFR
Special Function Registers
SJW
Synchronization Jump Width
SOF
Start of Frame
182
SRR
Substitute Remote Request
TEC
Transmit Error Counter
TTCAN
Time Triggered CAN
TTL
Transistor-Transistor Logic
UART
Universal Asynchronous Receiver/Transmitter
USB
Universal Serial Bus
VDX
Vehicle Distributed eXecutive
183
BIBLIOGRAFÍA
[1] Atmel Corporation, AT89C51CC01 Datasheet Enhanced 8-bit MCU with
CAN Controller and Flash Memory, San José, 2008.
[2] Atmel Corporation, Atmel C51 Hardware Manual, San José, 2004.
[3] Atmel Corporation, C51 Microcontrollers Demo Board, San José, 2002.
[4] Atmel Corporation, CAN Demoboard User Guide, San José, 2003.
[5] Atmel Corporation, Using Keil FlashMon Emulator with AT89C51CC01/03,
San José, 2006.
[6] K. Ayala, The 8051 Microcontroller, Jackson County: West Publishing,
1991.
[7] M. Beach y C. Hills, The C51 Primer, Staffordshire: Phaedrus Systems,
2006.
[8] D. Calcutt, F. Cowan y H. Parchizadeh, 8051 Microcontrollers, Oxford:
Newnes, 2004.
[9] J. Q. Castellano, Bus CAN: Estado de Buses Industriales y Aplicaciones,
Madrid, 2000.
[10] S. Cavalieri, A. Di Stefano y O. Mirabella, Centralized versus distributed
protocols for FieldBus applications, Cantania, 1995.
184
[11] C. A. Chamú Morales, Desarrollo de un Sistema Educativo para la
Enseñanza del Protocolo de Comunicaciones CAN, Huajuapan de León,
2005.
[12] M. Chapman, The Final Word on the 8051, San Diego, 1994.
[13] M. Distefano, Comunicaciones en Entornos Industriales, Mendoza, 2000.
[14] J. J. Fernández de Dios, Foundation Fieldbus y su adaptación a la alta
velocidad: HSE, Vigo, 2005.
[15] J. P. Ferrari, Sistemas de Control Distribuido, Rosario, 2005.
[16] I. M. Gómez González, Análisis y Diseño de Protocolos de Acceso al Medio
para el Control de Redes Eléctricas, Sevilla, 1995.
[17] R. C. Guevara Calume, Maestría en Automatización y Control Industrial,
Medellín, 2010.
[18] D. Ibrahim, Microcontroller Projects in C for the 8051, Oxford: Newnes,
2000.
[19] M. Ilyas y I. Mahgoub, Handbook of Sensor Networks Compact Wireless
and Wired Sensing Systems, Florida: CRC, 2005.
[20] H. Kaschel C. y E. Pinto L., Análisis de la Capa Física del Bus de Campo
CAN, Santiago, 2004.
[21] H. Kaschel C. y E. Pinto L., Análisis del Estado del Arte de los Buses de
Campo Aplicados al Control de Procesos Industriales, Santiago, 2002.
185
[22] H. Kaschel C. y E. Pinto L., Análisis Protocolar del Bus de Campo CAN,
Santiago, 2002.
[23] H. Kaschel C. y E. Pinto L., Implementación de la Capa Física del Bus de
Campo CAN, Santiago, 2004.
[24] H. Kaschel C. y E. Pinto L., Sistema de Diagnóstico y Sincronización de los
Buses de Campo CAN, Santiago, 2002.
[25] Keil Software, CAN Primer: Creating Your Own Network, Plano, 2009.
[26] Keil Software, Getting Started with µVision2 and C51 Microcontroller
Development Tools, Plano, 2001.
[27] B. W. Kernighan y D. M. Ritch, The C Programming Language, West
Lafayette: Prentice Hall, 1998.
[28] S. MacKenzie, The 8051 Microcontroller, West Lafayette: Prentice Hall,
1995.
[29] M. T. C. Medina, Análisis del Protocolo CAN (Controller Area Network) e
Implementación de un Prototipo de Control de Nodos Interconectados por
un Bus de Comunicaciones CAN, Quito, 2008.
[30] M. Molero Bastante, Bus CAN Diseño de Sistemas Críticos, Ciudad Real,
2005.
[31] M. Ortiz, F. Quiles, C. Moreno, M. Montuano, M. Brox y A. Gersnoviez,
CAN2PCI: Placa con Interfaz al Bus CAN y PCI con Finalidad Docente,
Córdoba, 2008.
186
[32] J. Parab, V. Shelake, R. Kamat y G. Naik, Exploring C For Microcontrollers
8051, Dordrecht: Springer, 2007.
[33] M. Pont, Embedded C, London: Addison-Wesley, 2002.
[34] M. Pont, Patterns for Time-Triggered Embedded Systems, London:
Addison-Wesley, 2011.
[35] M. Pont, Programming Embedded System I, Leicester: University of
Leicester, 2006.
[36] M. Pont, Programming Embedded System II, Leicester: University of
Leicester, 2007.
[37] A. Rosado, Sistemas Industriales Distribuidos: Tema 2, Valencia, 2003.
[38] Samson, Foundation Fieldbus: Part 4, Frankfurt, 2003.
[39] J. Sánchez Peñarroja, Controller Area Network, Valencia, 2007.
[40] T. Schultz, C and the 8051, West Lafayette: Prentice Hall, 1997.
[41] Silicon Graphics, C Language Reference Manual, Fremont: SGI Technical
Publications, 2003.
[42] G. Tejada Muñoz, Tutorial de Fieldbus, Lima, 1998.
187
ANEXOS
188
ANEXO A: GUÍAS DE LABORATORIO
189
EXPERIENCIA Nº1:
REFERENCIAS PARA LA UTILIZACIÓN DEL KIT DE DESARROLLO CAN
OBJETIVOS: El propósito de este laboratorio es describir los
componentes de software y de hardware
necesarios para la utilización del kit de desarrollo
CAN.
INTRODUCCIÓN: Para familiarizar al alumno con el kit de desarrollo y las
herramientas de trabajo, se analizarán los componentes de software y de
hardware con los que se trabajará posteriormente además de la configuración
del kit para la puesta en funcionamiento.
DESCRIPCIÓN DEL HARDWARE: Cada kit de desarrollo incluye dos placas:
una tarjeta de demostración C51 (C51 Demo Board) y una tarjeta de extensión
CAN (CAN Extension Board) dedicada a los dispositivos CAN las cuales se
interconectan.
Para programar el kit de desarrollo existen 2 condiciones de hardware que
afectan la forma en que se inicia el sistema. El kit de desarrollo se encarga de,
según el posicionamiento de los interruptores: J9, J11 y J16, saltar la ejecución
del programa principal para ejecutar el gestor de arranque y realizar tareas de
programación en el microcontrolador (modo Gestor de Arranque) o, en sentido
contrario, saltar la ejecución del gestor de arranque para ejecutar la aplicación
principal (modo Aplicación de Usuario).
190
a) Condición de hardware configurado para
arrancar en modo ‘Gestor de Arranque’
b) Condición de hardware configurado para
arrancar en modo ‘Aplicación de Usuario’
DESCRIPCIÓN DEL SOFTWARE: Para poder utilizar el kit de desarrollo de
precisan principalmente de 2 programas:
•
•
Entorno de desarrollo integrado.
Herramienta de programación del sistema.
Un entorno de desarrollo integrado o IDE (Integrated Development
Environment), es un programa informático compuesto por un conjunto de
herramientas de programación consistente en un editor de código, un
compilador y un depurador. El entorno de desarrollo que se utilizará en los
siguientes apartados corresponde a las herramientas de desarrollo de la
compañía Keil para los microcontroladores Intel 8051 llamado “Keil C51
Development Tools”, el cual permite la programación de aplicaciones escritas
en lenguaje C y Assembly.
La herramienta de programación del sistema es llamado por la compañía Atmel
como FLIP (FLexible In-system Programmer), es un software que se ejecuta en
el computador y sirve para la programación de microcontroladores de dicha
compañía. Ésta herramienta puede programar dispositivos dentro del sistema
(ISP: In-System Programming) a través de UART, USB y CAN. El tipo de
programación que se utilizará para los proyectos será por medio del puerto
RS-232 (UART) y la interconexión al PC será la siguiente:
191
CUESTIONARIO: Las preguntas siguientes deben ser respondidas por el
alumno; ya que, más de alguna será formulada antes de la experiencia.
1.- Explique las características y diferencias entre las arquitecturas von
Neumann y Harvard.
2.- Entregue la distribución de pines del microcontrolador Atmel
T89C51CC01 y los tipos de interrupciones que pueden gatillarse en el
microcontrolador Atmel T89C51CC01 junto con su numeración.
3.- Describa brevemente los siguientes componentes de hardware del kit de
desarrollo CAN: microcontrolador, conectores de energía, reloj del
sistema, interruptor de encendido/apagado, botón de reinicio, botón de
interrupción, pantalla LCD, barra de LED's, puerto RS-232 y puerto CAN.
PARTE EXPERIMENTAL: En primer lugar se debe proceder a establecer las
condiciones de hardware que se requieren para programar el kit de desarrollo
las cuales se describen a continuación:
1.- Interconectar la tarjeta de demostración C51 (C51 Demo Board) con la
tarjeta de extensión CAN (CAN Extension Board).
2.- Energizar la tarjeta de demostración C51 conectando el suministro de
energía de 9V.
3.- Conectar el puerto RS-232 de la tarjeta de demostración C51 al puerto
de comunicaciones COM del PC mediante un cable RS-232
Macho/Hembra.
4.- Asegurarse que el microcontrolador T89C51CC01UA-SLIM esté
192
conectado al zócalo PLCC44 de la tarjeta de extensión CAN.
En segundo lugar veremos los pasos necesarios para utilizar el software de
programación FLIP y verificar que se han establecido correctamente los
parámetros necesarios para poder programar la tarjeta de demostración:
1.- En primer lugar ejecutar el programa FLIP.
2.- Diríjase al menú desplegable ‘Device → Select’ seleccione el dispositivo
‘T89C51CC01’, nótese que la ventana de la aplicación mostrará ahora la
configuración del microcontrolador.
3.- Asegúrese de que el kit de desarrollo se encuentre debidamente
conectado al PC con la condición de hardware configurado para
arrancar en modo ‘Gestor de Arranque’ y posteriormente encienda el kit
de desarrollo.
4.- A continuación seleccione el menú desplegable ‘Settings →
Communication → RS232’, en la ventana de configuración ‘RS232
Setup’ escoja de puerto COM al cual esté conectado el kit de desarrollo
y configure la velocidad de transmisión con una velocidad de
transmisión de 9600bps.
5.- Iniciar la comunicación presionando el botón ‘Connect’ de la ventana de
configuración ‘RS232 Setup’.
6.- En el menú desplegable ‘File → Load HEX File…’ elija la aplicación que
desee programar en el microcontrolador, previamente compilada y en
formato binario hexadecimal. El mensaje ‘HEX file parsed’ mostrado en
la parte inferior de la ventana del programador FLIP confirma que la
carga del archivo fue exitosa.
7.- Asegurarse que las casillas de verificación siguientes están
seleccionadas en la sección ‘Operations Flow’ del FLIP: Erase, Blank
Check, Program y Verify.
8.- Deje sin verificar el cuadro de ‘BLJB’ en la sección ‘T89C51CC01’ a fin
de ejecutar el programa de demostración después del siguiente reinicio.
9.- Presione el botón ‘Run’ para que la programación se ejecute. El mensaje
‘Verify PASS’ mostrado en la parte inferior de la ventana del
programador FLIP confirma que el microcontrolador se ha programado
correctamente.
10.- Una vez programado asegúrese de que el kit de desarrollo se
encuentre con la condición de hardware configurado para arrancar en
modo ‘Aplicación de Usuario’.
11.- Finalmente reinicie el kit de desarrollo para iniciar la aplicación
programada en el microcontrolador.
193
BIBLIOGRAFÍA
[1] Atmel Corporation, AT89C51CC01 Datasheet Enhanced 8-bit MCU with
CAN Controller and Flash Memory, San José, 2008.
[2] Atmel Corporation, Atmel C51 Hardware Manual, San José, 2004.
[3] Atmel Corporation, C51 Microcontrollers Demo Board, San José, 2002.
[4] Atmel Corporation, CAN Demoboard User Guide, San José, 2003.
[5] Atmel Corporation, Using Keil FlashMon Emulator with AT89C51CC01/03,
San José, 2006.
[6] Keil Software, Getting Started with µVision2 and C51 Microcontroller
Development Tools, Plano, 2001.
[7] E. Ossandón, Diseño e Implementación de un Sistema Educativo del
Protocolo de Comunicaciones CAN, Santiago, 2011.
194
EXPERIENCIA Nº2:
INTRODUCCIÓN A LA PROGRAMACIÓN DE APLICACIONES PARA EL KIT DE
DESARROLLO
OBJETIVOS: El propósito de este laboratorio es familiarizar al
alumno con el kit de desarrollo y las
herramientas necesarias para la creación,
compilación y programación para éste.
INTRODUCCIÓN: Para familiarizar al alumno en la programación de
aplicaciones para el kit de desarrollo es necesario abarcar los siguientes
aspectos:
•
•
•
Explicar la estructura general de un programa escrito en lenguaje C y
mostrar ejemplos que haga uso de los distintos componentes del kit de
desarrollo.
Mostrar un programa que haga uso de interrupciones y retardos por
software y mostrar la importancia del reloj del sistema para la
comunicación asíncrona.
Configurar los parámetros necesarios para comunicarse a distintas
velocidades mediante puerto RS-232 del microcontrolador.
CONVENCIONES DE PROGRAMACIÓN: En todos los proyectos que se
mostrarán desde ahora en adelante hará uso de un archivo de configuración
llamado ‘config.h’ que estará incluido en el código de fuente de todos los
archivos con el fin de compartir las configuraciones en todos los proyectos, tal
como se muestra a continuación:
195
/******************************************************************************
* FILE_NAME: config.h
*
*-----------------------------------------------------------------------------*
* FILE_PURPOSE: This file is included by all source files in order to access *
*
to system wide configuration
*
******************************************************************************/
#ifndef _CONFIG_H_
#define _CONFIG_H_
#include <t89c51cc01.h>
#include "compiler.h"
#endif /* _CONFIG_H_ */
Éste archivo hace a su vez la inclusión de los archivos ‘t89c51cc01.h’ y
‘compiler.h’. El archivo ‘t89c51cc01.h’ añade el manejo los registros de
funciones encargados del direccionamiento para el microcontrolador
T89C51CC01; mientras que el archivo ‘compiler.h’ redefine las palabras clave
con el fin de asegurarse de que cualquier archivo de origen pueda ser
procesado por distintos compiladores además de definir nombres para tipos
de datos que hagan más fácil el declarar variables y parámetros (también
llamados ‘alias’).
ESTRUCTURA DE UN PROGRAMA: La estructura de un programa escrito en
C para un microcontrolador es básicamente la misma estructura de un
programa estándar en C con algunos cambios menores, cuya estructura típica
se muestra a continuación:
196
/******************************************************************************
* FILE_NAME: main.c
*
*-----------------------------------------------------------------------------*
* This is the program header. Describe your program here briefly
*
******************************************************************************/
/* include your headers here */
#include "config.h"
/* include your variable declarations here */
bit
Uchar
Uint16
var_1;
var_2;
var_3;
/* include your functions here */
void func_1(void)
{
/* body of function */
}
/* include your main code here */
void main(void) /* main code */
{
/* initialisation of variables */
}
while(1)
/* start of endless loop */
{
/* body of loop */
}
RUTINAS DE INTERRUPCIÓN: El compilador C51 permite declarar rutinas de
interrupción en el código C para que el programa se dirija automáticamente a
ese código cuando se produzca una interrupción, genera automáticamente los
vectores de interrupción además del código para entrar y salir de las rutinas de
interrupción. El esquema de las rutinas de interrupción es similar a la
declaración de funciones con la salvedad que el número de interrupción debe
declararse como parte de la función, tal como se muestra a continuación:
void fct_timer1_it(void) interrupt 3
{
/* interrupt service goes here */
}
197
CUESTIONARIO: Las preguntas siguientes deben ser respondidas por el
alumno; ya que, más de alguna será formulada antes de la experiencia.
1.- Explique la importancia de las comunicaciones asíncronas y los
principales beneficios de éste tipo de comunicación.
2.- Revise los archivos ‘t89c51cc01.h’ y ‘compiler.h’ de cada proyecto
entregado y explique en qué consisten los SFR (Special Function
Registers).
3.- Entregue una tabla resumen de las definiciones de tipo o ‘alias’ que
posee el archivo ‘compiler.h’.
4.- Explicar los niveles de voltaje e impedancia y campos que maneja el
protocolo RS-232, además de las características de: velocidad de
transmisión, bits de datos, paridad, bits de parada y control de flujo.
PARTE EXPERIMENTAL: Este laboratorio consta de utilizar las librerías
creadas específicamente para hacer uso de los componentes de hardware
implementados en el kit de desarrollo, se entregará al alumno 3 programas
escritos en C que mostrarán el uso de:
•
•
•
La barra de LED’s.
La pantalla LCD.
El puerto RS-232.
Se dejará como labor para el alumno compilar el programa escrito y programar
el kit de desarrollo. En el proyecto que utiliza el puerto RS-232 y según las
ecuaciones que se muestran a continuación:
198
Cálculo de recarga para el Timer 0/1
TH0/TH1 = 256 −
Baud Rate =
Cálculo de recarga para el Timer 2
2SMOD × FOSC
384 × Baud Rate
2SMOD × FOSC
2 × 32 × [256 − TH0/TH1]
(RCAP2H, RCAP2L) = 65536 −
Baud Rate =
2SMOD × FOSC
32 × Baud Rate
2SMOD × FOSC
32 × [65536 − (RCAP2H, RCAP2L)]
obtenga los valores de recarga de los registros TH0/TH1 o RCAP2H y RCAP2L
según sea el caso para obtener las distintas velocidades de transmisión
entregadas a continuación:
Velocidad de transmisión
[bps]
57600
38400
19200
14400
9600
4800
2400
1200
Temporizador
Timer 2
Timer 2
Timer 2
Timer 2
Timer 2
Timer 0/1
Timer 0/1
Timer 0/1
Para la visualización de mensajes entregados por el microcontrolador a través
del puerto de comunicaciones RS-232, el kit de desarrollo debe conectarse al
puerto de comunicaciones serie de un computador, utilizar un terminal RS-232
estándar como Hyperterminal y configurar el puerto serie del PC conectado al
kit de desarrollo como 8-N-1-N (8 bits de datos, sin paridad, 1 bit de parada y
sin control de flujo) en donde la velocidad de transmisión está dada por la
configuración especificada en el microcontrolador.
199
BIBLIOGRAFÍA
[1] K. Ayala, The 8051 Microcontroller, Jackson County: West Publishing,
1991.
[2] M. Beach y C. Hills, The C51 Primer, Staffordshire: Phaedrus Systems,
2006.
[3] D. Calcutt, F. Cowan y H. Parchizadeh, 8051 Microcontrollers, Oxford:
Newnes, 2004.
[4] M. Chapman, The Final Word on the 8051, California, 1994.
[5] D. Ibrahim, Microcontroller Projects in C for the 8051, Oxford: Newnes,
2000.
[6] B. W. Kernighan y D. M. Ritch, The C Programming Language, West
Lafayette: Prentice Hall, 1998.
[7] S. MacKenzie, The 8051 Microcontroller, West Lafayette: Prentice Hall,
1995.
[8] E. Ossandón, Diseño e Implementación de un Sistema Educativo del
Protocolo de Comunicaciones CAN, Santiago, 2011.
[9] J. Parab, V. Shelake, R. Kamat y G. Naik, Exploring C For Microcontrollers
8051, Dordrecht: Springer, 2007.
[10] M. Pont, Embedded C, London: Addison-Wesley, 2002.
[11] M. Pont, Programming Embedded System I, Leicester: University of
Leicester, 2006.
200
[12] T. Schultz, C and the 8051, West Lafayette: Prentice Hall, 1997.
[13] Silicon Graphics, C Language Reference Manual, Fremont: SGI Technical
Publications, 2003.
201
EXPERIENCIA Nº3:
ESTUDIO DE LA CAPA FÍSICA Y DE ENLACE DE DATOS DEL PROTOCOLO
CAN
OBJETIVOS: El propósito de este laboratorio es familiarizar al
alumno con el estudio de la capa física y de
enlace de datos del protocolo CAN haciendo uso
del kit de desarrollo.
INTRODUCCIÓN: Para familiarizar al alumno con el estudio de la capa física y
de enlace de datos del protocolo CAN es necesario abarcar los siguientes
aspectos:
• Explicar cómo crear un nodo para generar transmisión y recepción de
mensajes utilizando las librerías entregadas por el fabricante.
• Mostrar la estructura general de una trama CAN, campos de:







SOF (inicio de trama)
Identificador (estándar o extendido)
Control (tipo de trama y número de bytes de datos)
Datos (mensaje de hasta 8 bytes)
CRC (detección de errores)
ACK (acuse de recibo)
EOF (fin de trama)
• Detallar la configuración de los registros necesarios para obtener
comunicaciones a distintas velocidades.
TRANSMISIÓN DE MENSAJES CAN: En primer lugar se verá la utilización en
un programa encargado de transmitir mensajes, a modo de ejemplo se muestra
a continuación un programa que envía mensajes con un identificador estándar
‘0x123’ y 8 bytes de datos ‘{0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88}’ a
una velocidad de 500Kbps cada 250ms.
202
/******************************************************************************
* FILE_NAME: main.c
*
*-----------------------------------------------------------------------------*
* FILE_PURPOSE: This file is a simple CAN transmission sample software
*
******************************************************************************/
#include "config.h"
#include "can_lib.h"
Uint16 i;
can_data_t xdata data_tx = {0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88};
can_msg_t xdata msg_tx = {STD_ID(0x0123), CONF_NOIDE | CONF_NORTR | CONF_DLC_8,
data_tx};
void delay(Uint16 tempo)
{
for(i=0; i<tempo; i++);
}
void can_init(void)
{
CAN_CONTROLLER_RESET;
ClearAllMailbox();
CanSetBRP(BRP_500k);
CanSetSJW(SJW_500k);
CanSetPRS(PRS_500k);
CanSetPHS1(PHS1_500k);
CanSetPHS2(PHS2_500k);
CAN_CONTROLLER_ENABLE;
CAN_IT_ENABLE;
CAN_TX_IT_ENABLE;
}
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
reset can controller */
clear all ram of can controller */
configure can baud rate prescaler*/
configure can re-synchronization jump width */
configure can propagation time segment */
configure can phase segment 1 */
configure can phase segment 2 */
enable can controller */
enable can interrupts */
enable can transmission interrupt */
void can_fct_it_txok(void)
{
channel = CAN_GET_CHANNEL;
/* get interrupted channel */
CAN_CHANNEL_IT_DISABLE(channel); /* disable interrupt on channel */
}
void main(void)
{
can_init();
/* can initialisation */
EA = 1;
/* enable all interrupts
while(1)
/* start of endless loop */
{
delay(0xC350);
/*
can_tx_id
= msg_tx.id;
/*
conf_tx
= msg_tx.ctrl;
/*
pt_candata_tx = msg_tx.pt_data;
/*
CAN_SET_CHANNEL(CHANNEL_0);
/*
CAN_CHANNEL_IT_ENABLE(CHANNEL_0); /*
SendCanMsg();
/*
}
}
*/
delay for approx. 250ms */
message identifier */
message configuration */
message data pointer */
select message channel */
enable interrupt on channel */
send message */
203
RECEPCIÓN DE MENSAJES CAN: En segundo lugar se verá la utilización en
un programa encargado de recibir mensajes, a modo de ejemplo se muestra a
continuación un programa que sólo recibe mensajes con identificadores
estándar que comienzan con ‘0x012X’ a una velocidad de 500kbps.
/******************************************************************************
* FILE_NAME: main.c
*
*-----------------------------------------------------------------------------*
* FILE_PURPOSE: This file is a simple CAN reception sample software
*
******************************************************************************/
#include "config.h"
#include "can_lib.h"
can_data_t xdata data_rx = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
can_msg_t xdata msg_rx = {STD_ID(0x00, 0x00, data_rx};
void can_init(void)
{
CAN_CONTROLLER_RESET;
/* reset can controller */
ClearAllMailbox();
/* clear all ram of can controller */
CanSetBRP(BRP_500k);
/* configure can baud rate prescaler*/
CanSetSJW(SJW_500k);
/* configure can re-synchronization jump width */
CanSetPRS(PRS_500k);
/* configure can propagation time segment */
CanSetPHS1(PHS1_500k); /* configure can phase segment 1 */
CanSetPHS2(PHS2_500k); /* configure can phase segment 2 */
can_rx_filt.std = 0x012F;
/* accept only identifier */
can_rx_msk.std = 0x0120;
/* start by 0x012X */
conf_rx = CONF_NOIDE|CONF_MSK_IDE; /* accept only standard identifier */
CAN_SET_CHANNEL(CHANNEL_0);
/* select message channel */
CAN_CHANNEL_IT_ENABLE(CHANNEL_0);
/* enable interrupt on channel */
ConfChannel_Rx();
/* configure channel for reception */
CAN_CONTROLLER_ENABLE; /* enable can controller */
CAN_IT_ENABLE;
/* enable can interrupts */
CAN_RX_IT_ENABLE;
/* enable can reception interrupt */
}
void can_fct_it_rxok(void)
{
pt_st_can_rx = &msg_rx;
ReadCanMsg(CHANNEL_RX_ENABLE);
}
/* message data struct pointer */
/* read message and configure channel */
void main(void)
{
can_init(); /* can initialisation */
EA = 1;
/* enable all interrupts */
while(1);
/* start of endless loop */
}
204
CUESTIONARIO: Las preguntas siguientes deben ser respondidas por el
alumno; ya que, más de alguna será formulada antes de la experiencia.
1.- Investigue los niveles de voltaje e impedancia que maneja el protocolo
CAN, según los siguientes estándares: ISO 11898-2, ISO 11898-3,
SAE J2411 e ISO 11992.
2.- Estudie la forma de arbitraje del bus, los tipos de tramas y el tipo de
codificación de línea en el protocolo CAN e indique que tipo de
mensajes tienen prioridad por sobre otros: identificador estándar v/s
identificador extendido (que compartan el mismo identificador base),
trama de datos v/s trama remota y finalmente que identificado tiene
prioridad por sobre otro (mayor o menor identificador).
3.- En base a los ejemplos entregados, entregue una tabla resumen del uso
de las funciones contenidas en el archivo ‘can_lib.c’ y las definiciones de
tipo o ‘alias’ que posee el archivo ‘can_lib.h’.
PARTE EXPERIMENTAL: Este laboratorio consta de utilizar las librerías CAN
entregadas por el fabricante para la programación del kit de desarrollo, se
entregará al alumno 4 programas escritos en C que mostrarán el uso de:
•
•
Envío y recepción de distintos mensajes CAN (tramas de datos y
remotas) a distintas velocidades.
Rutinas de envío secuencial y recepción de mensajes CAN, mostrados
en la barra de LED’s, el panel LCD y el puerto RS-232.
Se dejará como labor para el alumno compilar el programa escrito y programar
el kit de desarrollo para generar distintas velocidades de transmisión para el
bus CAN utilizando el programa ‘X-Calculator’ disponible en la página del
fabricante, las velocidades a configurar por el alumno serán las mostradas en la
siguiente tabla:
Velocidad de
transmisión [kbps]
500
250
100
Sample Point [%]
80 a 90
80 a 90
80 a 90
Como tarea adicional el alumno deberá generar las configuraciones para el
nodo transmisor indicadas a continuación:
205
Canal
0
1
2
3
4
5
Identificador
STD: 0123
STD: 0011
STD: 0321
EXT: 01234567
EXT: 00110022
EXT: 07654321
Trama
Datos
Datos
Remota
Datos
Datos
Remota
DLC
8 bytes
4 bytes
6 bytes
8 bytes
4 bytes
6 bytes
Datos
11, 22, 33, 44, 55, 66, 77, 88
12, 34, 56, 78
11, 22, 33, 44, 55, 66, 77, 88
12, 34, 56, 78
-
y las siguientes configuraciones para el nodo receptor:
Canal
0
1
2
3
4
5
Filtro de Identificador
STD: 012X
STD: 001X
STD: 032X
EXT: 012345XX
EXT: 001100XX
EXT: 076543XX
Filtro de Trama
Datos y Remota
Datos
Remota
Datos y Remota
Datos
Remota
Para visualizar los mensajes los mensajes de los nodos trasmisor y receptor
mediante RS-232, el montaje de la conexión entre el PC y el kit de desarrollo
CAN es el siguiente:
206
BIBLIOGRAFÍA
[1] J. Q. Castellano, Bus CAN: Estado de Buses Industriales y Aplicaciones,
Madrid, 2000.
[2] C. A. Chamú Morales, Desarrollo de un Sistema Educativo para la
Enseñanza del Protocolo de Comunicaciones CAN, Huajuapan de León,
2005.
[3] H. Kaschel C. y E. Pinto L., Análisis de la Capa Física del Bus de Campo
CAN, Santiago, 2004.
[4] H. Kaschel C. y E. Pinto L., Análisis Protocolar del Bus de Campo CAN,
Santiago, 2002.
[5] H. Kaschel C. y E. Pinto L., Implementación de la Capa Física del Bus de
Campo CAN, Santiago, 2004.
[6] H. Kaschel C. y E. Pinto L., Sistema de Diagnóstico y Sincronización de los
Buses de Campo CAN, Santiago, 2002.
[7] M. T. C. Medina, Análisis del Protocolo CAN (Controller Area Network) e
Implementación de un Prototipo de Control de Nodos Interconectados por
un Bus de Comunicaciones CAN, Quito, 2008.
[8] M. Molero Bastante, Bus CAN Diseño de Sistemas Críticos, Ciudad Real,
2005.
[9] E. Ossandón, Diseño e Implementación de un Sistema Educativo del
Protocolo de Comunicaciones CAN, Santiago, 2011.
[10] J. Sánchez Peñarroja, Controller Area Network, Valencia, 2007.
207
EXPERIENCIA Nº4:
ESTUDIO DE APLICACIONES GATILLADAS EN EL TIEMPO
OBJETIVOS: El propósito de este laboratorio es familiarizar al
alumno con el estudio de aplicaciones gatilladas
en el tiempo para realizar tareas que requieran
cierta periodicidad.
INTRODUCCIÓN: Para familiarizar al alumno con el estudio de aplicaciones
gatilladas en el tiempo es necesario abarcar los siguientes aspectos:
•
•
•
Explicar cómo construir una aplicación basada en el tiempo para
sistemas empotrados.
Mostrar la implementación de programas que hagan uso de tareas
gatilladas en el tiempo.
Mostrar un programa que haga uso de interrupciones y retardos por
hardware.
APLICACIONES GATILLADAS EN EL TIEMPO: La creación de una aplicación
gatillada en el tiempo se hace a través de un itinerario de tareas (schedule
task), que puede ser visto como un sencillo sistema operativo que permite la
llamada a las tareas de forma periódica o (de forma menos frecuente) la
llamada a una sola tarea. Desde el punto de vista de niveles más bajos, un
itinerario de tareas puede ser visto como una sencilla temporización usando
interrupciones mediante un reloj para generar rutinas que pueden ser
compartidas entre diferentes tareas, como resultado un solo reloj debe ser
iniciado para ejecutar una, diez o cien tareas diferentes, la estructura de un
programa que hace uso de itinerarios se puede ver en los archivos ‘main.c’ y
‘schedule.c’ mostrados a continuación:
208
/******************************************************************************
* FILE_NAME: main.c
*
*-----------------------------------------------------------------------------*
* FILE_PURPOSE: This file is a schedule program example.
*
******************************************************************************/
#include "config.h"
#include "schedule.h"
void timer1_init(void)
{
TMOD |= 0x10;
/*
TH1 = 0xF8;
/*
TL1 = 0x52;
/*
ET1 = 1;
/*
TR1 = 1;
/*
}
timer 1 in mode 1, 16 bit mode */
reload value for */
timer 1 at 2ms */
enable timer 1 interrupt */
turn on timer 1 */
void main(void) /* main code */
{
timer1_init();
/* timer 1 initialisation */
schedule_init();
/* schedule initialisation */
EA = 1;
/* enable all interrupts */
while(1)
/* start of endless loop */
{
schedule(); /* schedule task */
}
}
void fct_timer1_it(void) interrupt 3
{
TH1 = 0xF8;
/* reload value for */
TL1 = 0x52;
/* timer 1 at 2ms */
TF1 = 0;
/* clear interrupt flag */
activate_new_schedul(); /* create new schedule */
}
209
/******************************************************************************
* FILE_NAME: schedule.c
*
*-----------------------------------------------------------------------------*
* FILE_PURPOSE: This file is a schedule tasking example.
*
******************************************************************************/
#include
#include
#include
#include
#include
"config.h"
"schedule.h"
"task_1.h"
"task_2.h"
"task_3.h"
Uchar task_in_progress;
void call_next_task(void)
{
EA = 0;
/* disable all interrupts */
task_in_progress++; /* assign next task */
EA = 1;
/* enable all interrupts */
}
void schedule_init(void)
{
task_1_init();
task_2_init();
task_3_init();
task_in_progress = 1;
}
/*
/*
/*
/*
void schedule(void)
{
switch(task_in_progress)
{
case 1:
{
task_1();
call_next_task();
break;
}
case 2:
{
task_2();
call_next_task();
break;
}
case 3:
{
task_3();
call_next_task();
break;
}
default:
{
break;
}
}
}
task 1
task 2
task 3
assign
initialisation */
initialisation */
initialisation */
first task */
/* task 1 */
/* call next task */
/* break */
/* task 2 */
/* call next task */
/* break */
/* task 3 */
/* call next task */
/* break */
/* break */
210
void activate_new_schedul(void)
{
task_in_progress = 1;
/* assign first task */
}
CUESTIONARIO: Las preguntas siguientes deben ser respondidas por el
alumno; ya que, más de alguna será formulada antes de la experiencia.
1.- Señale la importancia de la programación de aplicaciones gatilladas en
el tiempo para realizar tareas en tiempo real.
2.- ¿Cómo podría generar una mayor prioridad a algún tipo de tarea
específica en una aplicación que utilice la programación gatilladas en el
tiempo?
3.- Si es que necesito realizar una comunicación serie a través del puerto
RS-232 de éste kit de desarrollo a una velocidad de 9600bps ¿Es
posible utilizar el Timer 2 para realizar el itinerario de tareas? Explique.
PARTE EXPERIMENTAL: Este laboratorio consta en ver la estructura de
programas gatillados en el tiempo implementados en el kit de desarrollo, se
entregará al alumno 7 programas escritos en C que mostrarán el uso de:
•
•
Los proyectos de la barra de LED’s, la pantalla LCD, el puerto RS-232, el
envío secuencial y recepción de distintos mensajes CAN programados
como aplicaciones gatilladas en el tiempo.
Explicar mediante un programa el funcionamiento de 2 nodos actuando
cada uno tanto como transmisor y receptor de mensajes, el primer nodo
se encargará de generar 8 tipos de mensajes de prueba y de recibir
cualquier tipo de ellos; mientras que el segundo nodo se encargará de
realizar funciones de registro y replicación de datos.
En esta serie de laboratorios se mostrará al alumno proyectos de transmisión y
recepción de mensajes CAN actuando como generador de mensajes de prueba
y de adquisición de datos programados como aplicaciones gatilladas en el
tiempo.
Para visualizar los mensajes los mensajes de los nodos trasmisores/receptores
mediante RS-232, el montaje de la conexión entre el PC y el kit de desarrollo
CAN es el siguiente:
211
BIBLIOGRAFÍA
[1] E. Ossandón, Diseño e Implementación de un Sistema Educativo del
Protocolo de Comunicaciones CAN, Santiago, 2011.
[2] M. Pont, Patterns for Time-Triggered Embedded Systems, London:
Addison-Wesley, 2011.
[3] M. Pont, Programming Embedded System II, Leicester: University of
Leicester, 2007.
212
EXPERIENCIA Nº5:
IMPLEMENTACIÓN DE APLICACIONES QUE HAGAN USO DEL MODELO DE
COMUNICACIÓN CAN
OBJETIVOS: El propósito de este laboratorio es familiarizar al
alumno con las capacidades del bus CAN para
implementar los distintos modelos de control
que permite el protocolo.
INTRODUCCIÓN: Existen muchas maneras de clasificar las redes: en función
de su funcionalidad, de los protocolos utilizados, de sus prestaciones, del tipo
de acceso, de su topología, etc… En nuestro caso, y para no perdernos entre
las múltiples clasificaciones, veremos la clasificación según su modelo de
comunicación.
MODELOS DE COMUNICACIONES: Resulta importante conocer los dos
modelos básicos en los que se enmarca cualquier sistema de comunicación,
estos modelos son:
Cliente/Servidor: La comunicación en este modelo consiste en que un nodo
emite un mensaje a cada nodo destino, debiendo repetir ese mensaje para
cada uno de los nodos si es que desea que el mensaje llegue a varios nodos
pues la trama del mensaje enviado contiene una cabecera donde figura el nodo
fuente y el nodo destino. De este modo, no es posible la llegada simultánea del
mismo mensaje a todos los nodos, utilizando la red de comunicaciones durante
un largo periodo de tiempo. Además, el tiempo de emisión a todos los nodos
cambia según el número de nodos a los que se desea hacer llegar el mensaje,
el tipo de difusión utilizado es el envío de mensajes desde un único emisor a un
único receptor (unicast). Este modelo es empleado por protocolos como:
PROFIBUS, INTERBUS y AS-i.
Productor/Consumidor: La comunicación en este modelo emplea un sistema
por el que todos los nodos reciben los mensajes que se transmiten, siendo la
tarea de cada nodo decidir si ese mensaje debe aceptarlo. De este modo,
todos los nodos reciben el mensaje simultáneamente y no es necesario
repetirlo para cada uno de los nodos a los que está dirigido, con el
consiguiente ahorro en el tiempo de utilización del bus. Así, el tiempo de
transmisión resulta constante independientemente del número de nodos a los
que se desea hacer llegar el mensaje. En este caso, la trama del mensaje
incluye un identificador de mensaje; este identificador permite que los nodos
213
receptores conozcan si deben aceptarlo o no, el tipo de difusión utilizado es el
envío de mensajes a un grupo de receptores (multicast) o a toda la red
(broadcast). Este modelo es empleado por protocolos como: WorldFIP,
Fieldbus Foundation, CAN, ControlNet y EtherNet/IP.
FLEXIBILIDAD DEL MODELO PRODUCTOR/CONSUMIDOR: El modelo
productor/consumidor viene a cubrir las deficiencias del antiguo modelo
cliente/servidor, ya que los mensajes se identifican por su contenido y ofrece
las siguientes ventajas:
•
•
•
Múltiples nodos pueden consumir los mismos datos simultáneamente
desde un sólo productor.
Los nodos se pueden sincronizar fácilmente para obtener un
rendimiento más preciso del sistema.
Los dispositivos se pueden comunicar autónomamente, sin la necesidad
de un maestro de sistema.
El resumen de su flexibilidad y prestaciones que permite éste modelo de
comunicación se puede apreciar en la siguiente figura:
También éste modelo permite implementar el modelo cliente/servidor, tomando
en consideración que cada nodo debe identificar los campos de origen y
destino en el identificador, a continuación se muestra el formato de los
mensajes para cada uno de los modelos:
MONTAJE DEL SISTEMA: El montaje de los laboratorios Nodo1/Nodo2 y
Maestro/Esclavo se muestra a continuación:
214
CUESTIONARIO: Las preguntas siguientes deben ser respondidas por el
alumno; ya que, más de alguna será formulada antes de la experiencia.
1.- Explicar cuál es la función que cumple el filtrar los datos en el bus para
la recepción de mensajes en el modelo cliente/servidor y en el modelo
productor/consumidor.
2.- Explicar la función que cumplen los identificadores y los datos en ambos
modelos de comunicación: cliente/servidor y productor/consumidor.
3.- Explicar las funciones de controlador, sensor y actuador en los distintos
modelos de comunicación y como éstos se implementan en el sistema
PARTE EXPERIMENTAL: En el primer laboratorio de ésta experiencia se verá
el funcionamiento de un sistema de control por cambio de estado en un
esquema de comunicación multimaestro ejemplificado en un sistema de
control de poleas de una cinta transportadora. Cada nodo será considerado
como una estación de tambores motrices de la cinta transportadora en donde
cada nodo podrá gatillar la dirección y estado (ON/OFF) de la cadena de
correas transportadoras, las consideraciones a tomar serán las siguientes:
215
•
•
•
•
Al iniciar la secuencia de encendido el estado de cada uno de los nodos
será de espera (standby).
Cada nodo será capaz de iniciar el arranque del sistema de correas
transportadoras.
Al desconectarse un nodo de la energía eléctrica y posteriormente volver
a conectarse, la secuencia de inicio deberá considerar preguntar al
sistema el estado de funcionamiento (dirección y estado) para ser capaz
de replicar su estado de funcionamiento.
El direccionamiento de los nodos debido a que la información puede ser
originada y/o recibida por cualquier nodo de la red, por lo que cada
nodo será capaz de identificar el tipo de direccionamiento entregado el
cual, por el tipo de control empleado, será broadcast.
El hecho de que cada nodo no transmita información hasta que se modifica el
estado de las variables se le conoce como control por cambio de estado y el
hecho de que sea capaz de generar tareas de control en el sistema y por ende
cada nodo puede actuar como: sensor, actuador y controlador se conoce
como un direccionamiento multimaestro.
En el segundo laboratorio de ésta experiencia se verá el funcionamiento de un
sistema de control cíclico en un esquema de comunicación maestro/esclavo
ejemplificado en un sistema de control de aire acondicionado de una planta.
Existirá un nodo maestro que se encargará se ejercer el control en los
dispositivos esclavos, las consideraciones a tomar serán las siguientes:
•
•
•
•
La estación maestra podrá ejercer un control de temperatura para días
soleados y días nublados y ser capaz de identificar cada estación que
entrega el estado de la condición ambiental y temperatura de la planta.
Cada estación esclava deberá enviar en intervalos periódicos el estado
de la temperatura de la planta y de control ejercido sobre éste.
El direccionamiento de los nodos debido a que la información puede ser
originada y/o recibida por cualquier nodo de la red, por lo que cada
nodo será capaz de identificar el tipo de direccionamiento entregado el
cual, por el tipo de control empleado, será unicast.
Las estaciones deberán ser capaces de diferenciar entre lo que es
información de control y datos.
El hecho de que cada nodo no transmita información a la red en intervalos de
tiempo fijo se le conoce como control cíclico y el hecho de que una estación
funcione como controlador y sea capaz de generar tareas de control en el
sistema y las demás estaciones ejecuten acciones de sensor y actuador en el
sistema se conoce como un direccionamiento maestro/esclavo.
216
BIBLIOGRAFÍA
[1] Keil Software, CAN Primer: Creating Your Own Network, Plano, 2009.
[2] M. Ortiz, F. Quiles, C. Moreno, M. Montuano, M. Brox y A. Gersnoviez,
CAN2PCI: Placa con Interfaz al Bus CAN y PCI con Finalidad Docente,
Córdoba, 2008.
[3] E. Ossandón, Diseño e Implementación de un Sistema Educativo del
Protocolo de Comunicaciones CAN, Santiago, 2011.
217
ANEXO B: HOJA DE DATOS Y LISTA DE MATERIALES DEL KIT DE
DESARROLLO
218
HOJA DE DATOS DE LA TARJETA: C51 DEMO BOARD
219
220
221
222
223
224
LISTA DE MATERIALES DE LA TARJETA: C51 DEMO BOARD
Reference
Type
Specs
Qty
Comment
C1-C28
C2:C10-C19:C23
C11
C12
C13-C14-C24:C27
C15:C18
D1-D14
D2-D11:D13
D3:D6
D7:D8
D9:D10
J1
J2
J3
J4
J5-J10
J6:J7
J8
J9
J11
J12
J13
J14
J15
J16
J17
J18
J19
R1-R24-R28-R29
R2-R3-R20-R21-R25
R4:R11
R12-R19
R21
R23
R30
U1
U2
U3-U4-U7-U8
U5
U6
U9
U10
U12
U13
U14
U15
X1
X2
POL_CAPACITOR
CAPACITOR
POL_CAPACITOR
POL_CAPACITOR
CAPACITOR
POL_CAPACITOR
1N4001
LED
LED_GREEN
LED_YELLOW
LED_RED
CONNECTOR
CONNECTOR_BATTERY_9V
STRAP
DB9_MALE
DB9_FEMELLE
Push_Button
Switch ON-ON
Commut_DIP_2
Commut_DIP_8
CONNECTOR
Jumper_2,54mm
LCD_2X16
ALE_DIS
Commut_DIP_1
Switch ON-ON
jumper Battery
Switch ON-ON
RESISTOR
RESISTOR
RESISTOR
RESISTOR
POTENTIOMETER
RESISTOR
RESISTOR
LM7805C
LM2936Z5
74ACT573
TSC80C31
AT49HF010-45JC
ICL232CBE
HEF4555P
TSC80C51
TSC80C51
74ACT14
74ACT00
Quartz_11,0592
Quartz_22,1184
4,7uF
100nF
3,3uF
10uF
22pF
10uF
1N4001
LED
GREEN LED
YELLOW LED
RED LED
CONNECTOR
CONN_BATTERY_9V
STRAP
DB9_MALE
DB9_FEMELLE
Push_Button
Switch ON-ON
Commut_DIP_2
Commut_DIP_8
CONNECTOR
CONNECTOR
LCD_2X16
Strap
Commut_DIP_1
Switch ON-ON
Picot Pile
Switch ON-ON
1kOhm
10kOhm
10kOhm
1kOhm
10kOhm
100 Ohm
180 Ohm
LM7805C
LM2936Z5
74ACT573
Socket
Socket
ICL232CBE
HEF4555P
Socket
Socket
74ACT14
74ACT00
11,0592MHz
22,1184MHz
2
14
1
1
6
4
2
4
1
1
1
1
1
0
1
2
2
1
1
1
1
1
1
0
1
1
1
CMS_TAJ_Package_B
Package_0805
TAJ_CMS_Package_B
TAJ_CMS_Package_B
Serie_680
CMS_TAJ_Package_B
Package_DO204AL
CMS_STANDART
in_line_2.54mm step
in_line_2.54mm step
in_line_2.54mm step
4
6
2
2
1
1
1
1
1
4
1
1
1
1
1
1
1
1
1
1
Package_0603
Package_0603
Package_1206-CMS_ARC_241
Package_1206_CMS_ARC_241
SERIE_3362P
0.6W -1%
0,5W
TO220 + Heater
TO92
CMS
PLCC44
PLCC32
CMS
DIL
DIL24
PLCC68
CMS
CMS
HC49/4H
HC49/U
SUBD9Pins_Right_Angle
SUBD9Pins_Right_Angle
CMS
DIL
DIN41612_3*32_MALE_Right_Angle
2*11 contacts
NULL
Inter. ON/OFF
2 pins, step of 2,54mm
225
HOJA DE DATOS DE LA TARJETA: CAN EXTENSION BOARD
226
LISTA DE MATERIALES DE LA TARJETA: CAN EXTENSION BOARD
Reference
Value
Quantity
C1,C2
C3
J1
J2
R1
U1
U2
U3
X1
J12
J10
22pF
100 nF
2 pin connector
DB9 Female Connector
120Ω 1/4W
PLCC44 Socket
DIP8 socket
CAN Driver ATA6660 or compatible
12MHz Crystal
DIN3*32 Female Connector
Jumper Spacing 2.54 mm
2
1
1
1
1
1
1
1
1
1
1
227