diseño e implementació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.

i

HOJA DE CALIFICACIÓN

ii

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

iii

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!).

iv

TABLA DE CONTENIDOS

TABLA DE CONTENIDOS IV

ÍNDICE DE TABLAS IX

ÍNDICE DE ILUSTRACIONES XI

RESUMEN XVI

CAPÍTULO 1.- INTRODUCCIÓN 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

v

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

vi

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 92

4.1.- DESCRIPCIÓN DEL HARDWARE 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 100

4.2.1.- ENTORNO DE DESARROLLO INTEGRADO 100

4.2.1.1.- Tipos de Variables 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

vii

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.2.- ESTUDIO DE LA CAPA FÍSICA Y DE ENLACE DE DATOS DEL PROTOCOLO CAN 144


5.2.2.- LIBRERÍA DE COMUNICACIÓN CAN 146



5.3.- ESTUDIO DE APLICACIONES GATILLADAS EN EL TIEMPO 162


5.3.2.- ESTRUCTURA DE APLICACIONES GATILLADAS EN EL TIEMPO 163




5.4.- IMPLEMENTACIÓN DE APLICACIONES QUE HAGAN USO DEL MODELO DE

COMUNICACIÓN CAN 171


5.4.2.- FLEXIBILIDAD DEL MODELO PRODUCTOR/CONSUMIDOR 173

5.4.3.- MONTAJE DEL SISTEMA 174



CAPÍTULO 6.- CONCLUSIONES 178

viii

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

ix

Í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

x

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

xi

Í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

xii

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

xiii

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

xiv

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

xv

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

xvi

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.

1

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

2

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

3

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.

4

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

5

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.

6

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

7

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

8

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

9

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.

10

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.

11

El hecho de que los buses de campo sean más sencillos que otras redes

de uso industrial como por ejemplo MAP1 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

1 Una arquitectura de comunicaciones independiente del fabricante que permita interconectar todos los elementos de la fábrica

12

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:

13

• 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

14

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

15

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.

16

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,

17

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

18

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

19

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,

20

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 un subconjunto del estándar MMS. Entre sus

características incluyen: redes multimaestro con 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

21

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.

22

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.

23

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,

24

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 bit2 (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

2 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)

25

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 fallos3: 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

3 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

26

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).

27

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

28

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 (tq, time quantum) derivada del periodo del

oscilador tCLK (Figura 3.5). El parámetro tq 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 (tb) 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).

29

tb =1fb

[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 1tq.

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 8tq.

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 8tq.

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

30

Phase_Seg1.

El número total de unidades básicas en un tiempo de bit debe ser

programable entre 8 a 25tq.

• 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 2tq.

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

31

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 (tq). 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 (tq) 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 4tq).

y si el error de fase es negativo: El segmento Phase_Seg2 se reduce

por una cantidad igual al valor de RJW (1 a 4tq).

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

32

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 4tq.

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.

33

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

34

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.

fB × long_bus < 50000m × Kbps [3. 2]

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]

Longitud del Bus [m]

Tiempo de Bits Nominal [µs]

1000 40 1 500 100 2 250 250 4 125 500 8 62,5 1000 20 20 2500 50

35

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

36

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.

tSCL mín =tSCL nom

1 + Δf≈ tSCL nom(1− Δf) [3. 4]

tSCL máx =tSCL nom

1 − Δf≈ tSCL nom(1 + Δf) [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.

37

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:

38

• 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.

39

Dicho principio se realiza con medios eléctricos u ópticos, los cuales se


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

40

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

41

á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).

42

Tabla 3.2.- Asignación de terminales en el conector DB9

Pin Señal Descripción 1 - Futuras aplicaciones 2 CAN_L Señal de bus CAN (dominante bajo) 3 CAN_GND Señal de tierra (GND) 4 - Futuras aplicaciones 5 CAN_SHLD Blindaje (opcional) 6 GND Tierra (opcional) 7 CAN_H Señal de bus CAN (dominante alto) 8 - Futuras aplicaciones 9 CAN_V+ 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 Señal Descripción 1 CAN_SHLD Blindaje (opcional) 2 CAN_V+ Fuente de alimentación externa (opcional) 3 CAN_GND Señal de tierra (GND) 4 CAN_H Señal de bus CAN (dominante alto) 5 CAN_L Señal de bus CAN (dominante bajo)

Figura 3.12.- Conector tipo mini

43

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 Señal Descripción 1 CAN_SHLD Blindaje (opcional) 2 CAN_V+ Fuente de alimentación externa (opcional) 3 CAN_GND Señal de tierra (GND) 4 CAN_H Señal de bus CAN (dominante alto) 5 CAN_L 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 Señal Descripción 1 CAN_V+ Fuente de alimentación externa (opcional) 2 CAN_SHLD Blindaje (opcional) 3 CAN_H Señal de bus CAN (dominante alto) 4 CAN_L Señal de bus CAN (dominante bajo) 5 CAN_GND Señal de tierra (GND)

44

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 Señal Descripción 1 CAN_GND Señal de tierra (GND) 2 CAN_L Señal de bus CAN (dominante bajo) 3 CAN_SHLD Blindaje (opcional) 4 CAN_H Señal de bus CAN (dominante alto) 5 CAN_V+ 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

45

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.

46

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.

47

• 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 [3. 6]

• Bit recesivo: -500mV a +500mV, sin carga.

• Bit dominante: +1,5 V a +3,0 V, con una carga de 60Ω.

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 Niveles Nominales de Voltaje [V]

CAN_H CAN_L Vdiff

Estado del Bus Dominante 3,5 1,5 2 Recesivo 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

48

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 (RX) (Figura 3.9).

Las líneas TX y RX 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.

49

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:

50

• 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 Niveles de Voltaje [V]

CAN_H CAN_L Vdiff

Estado del Bus Dominante 5 – 3,6 1,4 – 0 2,2 – 5 Recesivo 0 – 0,3 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:

51

• 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

52

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.

53

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

54

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 Señal Voltaje del vehículo [V] 12V 24V

Dominante CAN_H 6,0 a 10,6 10,6 a 21,3 CAN_L 3,0 a 5,3 5,3 a 10,6

Recesivo CAN_H 3,0 a 5,3 5,3 a 10,6 CAN_L 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

55

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 Transferencia

[Kbps]

Longitud de Línea Máxima

[m]

Tiempo de Bit Nominal

[μs]

Número de tq

Duración de tq [ns]

Punto de Muestreo

[tq] 1000 25 1 8 125 6 800 50 1,25 10 125 8 500 100 2 16 125 14 250 250 4 16 250 14 125 500 8 16 500 14 50 1000 20 16 1250 14 20 2500 50 16 3125 14 10 5000 100 16 6250 14

56

Tabla 3.11.- Parámetros de tiempos de bit recomendados por DS-102

Parámetro Recomendación DS-102 Frecuencia del oscilador 16Mhz +/- 0,1%

Método de muestreo Muestreo sencillo Modo de sincronización Sólo flancos recesivos a dominantes

Duración de SJW* 1 tq Duración de Phase_Seg2 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


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 T4 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

57

Tabla 3.12.- Línea de bus interconectada de acuerdo a la recomendación DS-102

Opción A B

Nodo 1 conector macho 1 conector macho y 1 conector hembra

Conector tipo T 1 conector macho y

2 conectores hembras No requerido

Sección de línea de bus 1 conector macho y 1

conector hembra 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.

58

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 conectores5:

• 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 Rt=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.

5 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’

59

Tabla 3.13.- Extensión de red y longitud de línea de extensión para DeviceNet

Velocidad de transferencia

[Kbps]

Longitud de la línea principal [m] Longitud máxima de la línea de extensión [m]

Cable grueso

Cable delgado Cable plano Acumulada Individual

500 100 100 100 39 6 250 250 100 200 78 6 125 500 100 420 156 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 conectores6:


• Conector tipo micro (Tabla 3.4 y Figura 3.13).

• Conector tipo nano (Tabla 3.5 y Figura 3.14).


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).

6 DeviceNet adicionalmente recomienda el uso del conector tipo micro de 4 terminales (conector M12 de 4-pines) para tomas auxiliares de energía

60

Tabla 3.14.- Velocidades de transferencia y longitudes de línea recomendadas para SDS

Velocidad de transferencia [Kbps]

Longitud de la línea principal [m]

Longitud máxima de la línea de extensión [m]

1000 22,8 0,3 500 91,4 0,9 250 182,8 1,8 125 457,2 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 conectores7:

• Conector DB9 (Tabla 3.2 y Figura 3.11).



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

7 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

61

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

62

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

63

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

64

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

S O F

Identificador R T R 10 9 8 7 6 5 4 3 2 1 0

Nodo 1 0 1 1 0 0 1 0 1 1 1 - - - Nodo 2 0 1 1 0 0 1 1 - - - - - - Nodo 3 0 1 1 0 0 1 0 1 1 0 0 1 0

Nivel del bus 0 1 1 0 0 1 0 1 1 0 0 1 0

65

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

66

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.

67

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

68

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).

69

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

70

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 Número de bytes de datos DLC-3 DLC-2 DLC-1 DLC-0

0 0 0 0 0 0 0 0 1 1 0 0 1 0 2 0 0 1 1 3 0 1 0 0 4 0 1 0 1 5 0 1 1 0 6 0 1 1 1 7 1 0 o 1 0 o 1 0 o 1 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 BHC8 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

• Campo de aceptación: Este campo está constituido por una ranura de 8 Un código cíclico bien especializado para las longitudes de trama menores a 127 bits

71

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

72

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

73

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.

74

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.

75

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 datos9, 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

76

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.

77

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.

78

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

79

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

80

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

81

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.

82

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

Kraftfahrzeug10/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

10 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

83

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.

84

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

85

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 Características Permite la interoperabilidad entre

diferentes dispositivos Configuración automática de la red

Capacidad de respuesta en tiempo real Fácil acceso a todos los parámetros del

dispositivo Modular, cubre dispositivos desde

simples a complejos Sincronización de dispositivos

Amigable con el usuario, disponibilidad de herramientas

Transmisión de datos controlada por eventos y cíclica

Protocolo abierto e independiente del vendedor, estandarizado como

EN 50325-4

Lectura sincrónica de configuración de entradas, salidas o parámetros

86

Figura 3.35.- Arquitectura general de un sistema basado en CANopen

3.6.3.- DEVICENET

DeviceNet es un protocolo desarrollado por la firma Rockwell

Automation11 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

11 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

87

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

88

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.

89

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.

90

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

91

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.

92

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.

93

• 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.

94

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.

95

Figura 4.2.- Diagrama de bloques del microcontrolador Atmel T89C51CC01

Figura 4.3.- Distribución de pines del microcontrolador Atmel T89C51CC01 en formato

PLCC44

96

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.

97

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 placa12, 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.

12 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

98

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áquina13.

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.

13 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

99

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

100

microcontrolador14.

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.

14 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”

101

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 C15 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

15 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

102

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 Bits Bytes Rango Compilador bit 1 - 0 a 1 Keil C51 signed char 8 1 -128 a +127 Keil C51/ANSI C unsigned char 8 1 0 a 255 Keil C51/ANSI C enum 16 2 -32.768 a +32.767 Keil C51/ANSI C signed short 16 2 -32.768 a +32.767 Keil C51/ANSI C unsigned short 16 2 0 a 65.535 Keil C51/ANSI C signed int 16 2 -32.768 a +32.767 Keil C51/ANSI C unsigned int 16 2 0 a 65.535 Keil C51/ANSI C signed long 32 4 -2.147.483.648 a +2.147.483.647 Keil C51/ANSI C unsigned long 32 4 0 a 4.294.967.295 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.

103

Tabla 4.3.- Tipos de SFR que maneja el compilador C51

Tipo Bits Bytes Rango Sbit 1 - 0 a 1 Sfr 8 1 0 a 255 Sf16 16 2 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 Descripción Operación ~ ~x operación de bit NOT todos los bits se invierten & x & y operación de bit AND cada bit de ‘x’ AND cada bit de ‘y’ | x | y operación de bit OR cada bit de ‘x’ OR cada bit de ‘y’ ^ x ^ y operación de bit XOR cada bit de ‘x’ XOR cada bit de ‘y’

<< x << y desplazamiento a la

izquierda todos los bits en ‘x’ se desplazan a la

izquierda en ‘y’ bits

>> x >> y desplazamiento a la

derecha 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 Descripción Operación &= x &= y asignación de bit AND asigna ‘x & y’ a ‘x’ |= x |= y asignación de bit OR asigna ‘x | y’ a ‘x’ ^= x ^= y asignación de bit XOR asigna ‘x ^ y’ a ‘x’

<<= x <<= y asignación de desplazamiento

a la izquierda desplaza los bits en ‘x’ hacia la

izquierda en ‘y’ bits

>>= x >>= y asignación de desplazamiento

a la derecha 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.

104

/****************************************************************************** * 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

105

interrupción por el arreglo de contador programable (PCA/EWC16), 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 Vector de direccionamiento

Externa 0 (INT0) 0 0x0003 Timer 0 (TF0) 1 0x000B Externa 1 (INT1) 2 0x0013 Timer 1 (TF1) 3 0x001B UART (RI o TI) 4 0x0023 Timer 2 (TF2) 5 0x002B PCA (CF o CCFn) 6 0x0033 CAN (Tx, Rx, Err, OvrBuff) 7 0x003B ADC (ADCI) 8 0x0043 CAN Timer (OvrTim) 9 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

16 Se usa indistintamente el anglicismo PCA (Programmable Counter Array) o el EWC (Event and Waveform Controller)

106

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).

107

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).

108

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 desarrollo17.

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

109

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.

110

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.

111

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).

112

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).

113

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).

114

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).

115

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.

116

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 CAN18. 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

18 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”

117

Macho/Hembra19.

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 UART20 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 20 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)

118

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

119

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).

120

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).

121

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.

122

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.2521.

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’

123

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).

124

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

125

‘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.

126

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.

127

• 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 Herramientas

Requerimientos de Software

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’

Requerimientos de Hardware

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.

128

/****************************************************************************** * 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).

129

Tabla 5.2.- Definición de tipos entregados en el archivo ‘compiler.h’

Definición Tipo Bits Bytes Bool unsigned char 8 1 Uchar unsigned char 8 1 Uint8 unsigned char 8 1 Uint16 signed char 8 1 Uint32 unsigned int 16 2 Int8 signed int 16 2 Int16 unsigned long 32 4 Int32 signed long 32 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 norma22, la interfaz puede trabajar en comunicación

22 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

130

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 19200bps23. Por ejemplo, de la

famosa velocidad 9600bps obtenemos 1/9600 = 104µs.

• Bits de datos: Puede ser desde 5 a 8 bits de datos24, 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

23 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 24 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

131

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 XOFF25.

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).

25 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

132

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.

133

/****************************************************************************** * 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.

134


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.

135

/****************************************************************************** * 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.

136

Figura 5.5.- Estructura del proyecto ‘bargraph’


programar el kit de desarrollo.


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

137

‘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 serie26.

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-recarga27); mientras que si es configurado como el

hexadecimal ‘0x20’ (M11 = 1 y M01 = 0) habilita el funcionamiento del

Timer 1 en modo 2.

26 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 27 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

138

• 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 transmisión [bps] Cristal [MHz] Valor del bit

SMOD

Valor de recarga para

TH0/TH1 Error [%]

9600 12,000 1 0xF9 6,99 4800 12,000 1 0xF3 0,16 2400 12,000 0 0xF3 0,16 1200 12,000 0 0xE6 0,16 9600 11,059 0 0xFD 0 4800 11,059 0 0xFA 0 2400 11,059 0 0xF4 0 1200 11,059 0 0xE8 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 [5. 1]

Baud Rate =2SMOD × FOSC

2 × 32 × [256 − TH0/TH1] [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

139

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-recarga28.

• 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]

Cristal [MHz]

Valor del bit SMOD


RCAP2H


RCAP2L Error [%]

115200 12,000 1 0xFF 0xF9 6,99 57600 12,000 1 0xFF 0xF3 0,16 38400 12,000 1 0xFF 0xEC 2,34 19200 12,000 1 0xFF 0xD9 0,16 14400 12,000 0 0xFF 0xE6 0,16 9600 12,000 0 0xFF 0xD9 0,16

115200 11,059 0 0xFF 0xFD 0 57600 11,059 0 0xFF 0xFA 0 38400 11,059 0 0xFF 0xF7 0 19200 11,059 0 0xFF 0xEE 0 14400 11,059 0 0xFF 0xE8 0 9600 11,059 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.

28 El valor de recarga del Timer 2 se lee desde RCAP2H y RCAP2L cuando se desbordan los registros TL2 y TH2

140

(RCAP2H, RCAP2L) = 65536 −2SMOD × FOSC

32 × Baud Rate [5. 3]


32 × [65536 − (RCAP2H, RCAP2L)] [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 aceptable29

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; /* SMOD1 = 1, double baud rate */ SCON = 0x40; /* serial port in mode 1, 8-bit UART data */ TMOD |= 0x20; /* timer 1 in mode 2, 8-bit autoreload */ TH1 = 0xF3; /* reload value for 2400 bauds @ 12MHz */ TR1 = 1; /* turn on timer 1 */ TI = 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’

29 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

141

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’


programar el kit de desarrollo para generar distintas velocidades de transmisión

142

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] Temporizador

57600 Timer 2 38400 Timer 2 19200 Timer 2 14400 Timer 2 9600 Timer 2 4800 Timer 0/1 2400 Timer 0/1 1200 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.

143

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).

144

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)

145

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.




continuación:

146




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

147

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

148

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á

149

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

150

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:


#define USER_CAN_FCT_IT_RXOK


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:


#define USER_CAN_FCT_IT_ERROR


void fct_can_it_gen(void): Esta función es llamada cuando ocurre un

error en cualquier canal, para usar esta función debe:


#define USER_CAN_FCT_IT_GEN


void fct_can_timovf_it(void): Función que se encarga de manejar la

151

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:


#define USER_CAN_FCT_IT_TIMOVF


Un 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

152

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

153


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.

154

/****************************************************************************** * 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; /* 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_CONTROLLER_ENABLE; /* enable can controller */ CAN_IT_ENABLE; /* enable can interrupts */ CAN_TX_IT_ENABLE; /* 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); /* delay for approx. 250ms */ can_tx_id = msg_tx.id; /* message identifier */ conf_tx = msg_tx.ctrl; /* message configuration */ pt_candata_tx = msg_tx.pt_data; /* message data pointer */ CAN_SET_CHANNEL(CHANNEL_0); /* select message channel */ CAN_CHANNEL_IT_ENABLE(CHANNEL_0); /* enable interrupt on channel */ SendCanMsg(); /* send message */

Figura 5.12.- Ejemplo de utilización de la librería CAN para la transmisión de mensajes

155

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; /* message data struct pointer */ ReadCanMsg(CHANNEL_RX_ENABLE); /* 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

156

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.

157

Figura 5.14.- Estructura de los proyectos ‘can_tx’ y ‘can_rx’


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.

158

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] Sample Point [%]

500 80 a 90 250 80 a 90 100 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.

159

Tabla 5.9.- Configuraciones requeridas para el nodo transmisor

Canal Identificador Trama Longitud Datos 0 STD: 0123 Datos 8 bytes 11, 22, 33, 44, 55, 66, 77, 88 1 STD: 0011 Datos 4 bytes 12, 34, 56, 78 2 STD: 0321 Remota 6 bytes - 3 EXT: 01234567 Datos 8 bytes 11, 22, 33, 44, 55, 66, 77, 88 4 EXT: 00110022 Datos 4 bytes 12, 34, 56, 78 5 EXT: 07654321 Remota 6 bytes -

Tabla 5.10.- Configuraciones requeridas para el nodo receptor

Canal Filtro de Identificador Filtro de Trama 0 STD: 012X Datos y Remota 1 STD: 001X Datos 2 STD: 032X Remota 3 EXT: 012345XX Datos y Remota 4 EXT: 001100XX Datos 5 EXT: 076543XX 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.

160

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


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.

161

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

162

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.

163




continuación:




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’



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.

164

/****************************************************************************** * 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; /* timer 1 in mode 1, 16 bit mode */ TH1 = 0xF8; /* reload value for */ TL1 = 0x52; /* timer 1 at 2ms */ ET1 = 1; /* enable timer 1 interrupt */ TR1 = 1; /* 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

165

/****************************************************************************** * FILE_NAME: schedule.c * *-----------------------------------------------------------------------------* * FILE_PURPOSE: This file is a schedule tasking example. * ******************************************************************************/ #include "config.h" #include "schedule.h" #include "task_1.h" #include "task_2.h" #include "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 1 initialisation */ task_2_init(); /* task 2 initialisation */ task_3_init(); /* task 3 initialisation */ task_in_progress = 1; /* assign first task */ void schedule(void) switch(task_in_progress) case 1: task_1(); /* task 1 */ call_next_task(); /* call next task */ break; /* break */ case 2: task_2(); /* task 2 */ call_next_task(); /* call next task */ break; /* break */ case 3: task_3(); /* task 3 */ call_next_task(); /* call next task */ break; /* break */ default: break; /* break */

166

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


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.

167

a) Proyecto ‘bargraph’

b) Proyecto ‘display’

c) Proyecto ‘rs232’

Figura 5.20.- Estructura de los proyectos ‘bargraph’, ‘display’ y ‘rs232’

168


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.

169

Figura 5.21.- Estructura de los proyectos ‘can_tx’ y ‘can_rx’


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

170

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.

171

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

172

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.




continuación:

173




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’



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.

174

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.

175

Figura 5.25.- Montaje para los laboratorios Nodo1/Nodo2 y Maestro/Esclavo


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:

176

• 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 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

177

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.

178

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

179

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.

180

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

181

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

182

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

183

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

184

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.

185

[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.

186

[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.

187

[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.

188

ANEXOS

189

ANEXO A: GUÍAS DE LABORATORIO

190

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).

191

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:

192

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é

193

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.

194

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.

195

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:

196

/****************************************************************************** * 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:

197

/****************************************************************************** * 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 var_1; Uchar var_2; Uint16 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 */

198


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:

199

Cálculo de recarga para el Timer 0/1 Cálculo de recarga para el Timer 2

TH0/TH1 = 256 −2SMOD × FOSC

384 × Baud Rate (RCAP2H, RCAP2L) = 65536 −

2SMOD × FOSC32 × Baud Rate


2 × 32 × [256 − TH0/TH1] 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] Temporizador

57600 Timer 2 38400 Timer 2 19200 Timer 2 14400 Timer 2 9600 Timer 2 4800 Timer 0/1 2400 Timer 0/1 1200 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.

200

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.

201

[12] T. Schultz, C and the 8051, West Lafayette: Prentice Hall, 1997. [13] Silicon Graphics, C Language Reference Manual, Fremont: SGI Technical

Publications, 2003.

202

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.

203

/****************************************************************************** * 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; /* 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_CONTROLLER_ENABLE; /* enable can controller */ CAN_IT_ENABLE; /* enable can interrupts */ CAN_TX_IT_ENABLE; /* 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); /* delay for approx. 250ms */ can_tx_id = msg_tx.id; /* message identifier */ conf_tx = msg_tx.ctrl; /* message configuration */ pt_candata_tx = msg_tx.pt_data; /* message data pointer */ CAN_SET_CHANNEL(CHANNEL_0); /* select message channel */ CAN_CHANNEL_IT_ENABLE(CHANNEL_0); /* enable interrupt on channel */ SendCanMsg(); /* send message */

204

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; /* message data struct pointer */ ReadCanMsg(CHANNEL_RX_ENABLE); /* read message and configure channel */ void main(void) can_init(); /* can initialisation */ EA = 1; /* enable all interrupts */ while(1); /* start of endless loop */

205


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] Sample Point [%]

500 80 a 90 250 80 a 90 100 80 a 90

Como tarea adicional el alumno deberá generar las configuraciones para el nodo transmisor indicadas a continuación:

206

Canal Identificador Trama DLC Datos 0 STD: 0123 Datos 8 bytes 11, 22, 33, 44, 55, 66, 77, 88 1 STD: 0011 Datos 4 bytes 12, 34, 56, 78 2 STD: 0321 Remota 6 bytes - 3 EXT: 01234567 Datos 8 bytes 11, 22, 33, 44, 55, 66, 77, 88 4 EXT: 00110022 Datos 4 bytes 12, 34, 56, 78 5 EXT: 07654321 Remota 6 bytes -

y las siguientes configuraciones para el nodo receptor:

Canal Filtro de Identificador Filtro de Trama 0 STD: 012X Datos y Remota 1 STD: 001X Datos 2 STD: 032X Remota 3 EXT: 012345XX Datos y Remota 4 EXT: 001100XX Datos 5 EXT: 076543XX 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:

207

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.

208

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:

209

/****************************************************************************** * 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; /* timer 1 in mode 1, 16 bit mode */ TH1 = 0xF8; /* reload value for */ TL1 = 0x52; /* timer 1 at 2ms */ ET1 = 1; /* enable timer 1 interrupt */ TR1 = 1; /* 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 */

210

/****************************************************************************** * FILE_NAME: schedule.c * *-----------------------------------------------------------------------------* * FILE_PURPOSE: This file is a schedule tasking example. * ******************************************************************************/ #include "config.h" #include "schedule.h" #include "task_1.h" #include "task_2.h" #include "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 1 initialisation */ task_2_init(); /* task 2 initialisation */ task_3_init(); /* task 3 initialisation */ task_in_progress = 1; /* assign first task */ void schedule(void) switch(task_in_progress) case 1: task_1(); /* task 1 */ call_next_task(); /* call next task */ break; /* break */ case 2: task_2(); /* task 2 */ call_next_task(); /* call next task */ break; /* break */ case 3: task_3(); /* task 3 */ call_next_task(); /* call next task */ break; /* break */ default: break; /* break */

211

void activate_new_schedul(void) task_in_progress = 1; /* assign first task */


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:

212

BIBLIOGRAFÍA


[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.

213

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

214

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:

215


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:

216

• 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.

217

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.


218

ANEXO B: HOJA DE DATOS Y LISTA DE MATERIALES DEL KIT DE DESARROLLO

219

HOJA DE DATOS DE LA TARJETA: C51 DEMO BOARD

225

LISTA DE MATERIALES DE LA TARJETA: C51 DEMO BOARD

Reference Type Specs Qty Comment C1-C28 POL_CAPACITOR 4,7uF 2 CMS_TAJ_Package_B C2:C10-C19:C23 CAPACITOR 100nF 14 Package_0805 C11 POL_CAPACITOR 3,3uF 1 TAJ_CMS_Package_B C12 POL_CAPACITOR 10uF 1 TAJ_CMS_Package_B C13-C14-C24:C27 CAPACITOR 22pF 6 Serie_680 C15:C18 POL_CAPACITOR 10uF 4 CMS_TAJ_Package_B D1-D14 1N4001 1N4001 2 Package_DO204AL D2-D11:D13 LED LED 4 CMS_STANDART D3:D6 LED_GREEN GREEN LED 1 in_line_2.54mm step D7:D8 LED_YELLOW YELLOW LED 1 in_line_2.54mm step D9:D10 LED_RED RED LED 1 in_line_2.54mm step J1 CONNECTOR CONNECTOR 1 J2 CONNECTOR_BATTERY_9V CONN_BATTERY_9V 1 J3 STRAP STRAP 0 J4 DB9_MALE DB9_MALE 1 SUBD9Pins_Right_Angle J5-J10 DB9_FEMELLE DB9_FEMELLE 2 SUBD9Pins_Right_Angle J6:J7 Push_Button Push_Button 2 CMS J8 Switch ON-ON Switch ON-ON 1 J9 Commut_DIP_2 Commut_DIP_2 1 J11 Commut_DIP_8 Commut_DIP_8 1 DIL J12 CONNECTOR CONNECTOR 1 DIN41612_3*32_MALE_Right_Angle J13 Jumper_2,54mm CONNECTOR 1 2*11 contacts J14 LCD_2X16 LCD_2X16 1 NULL J15 ALE_DIS Strap 0 J16 Commut_DIP_1 Commut_DIP_1 1 J17 Switch ON-ON Switch ON-ON 1 Inter. ON/OFF J18 jumper Battery Picot Pile 1 2 pins, step of 2,54mm J19 Switch ON-ON Switch ON-ON R1-R24-R28-R29 RESISTOR 1kOhm 4 Package_0603 R2-R3-R20-R21-R25 RESISTOR 10kOhm 6 Package_0603 R4:R11 RESISTOR 10kOhm 2 Package_1206-CMS_ARC_241 R12-R19 RESISTOR 1kOhm 2 Package_1206_CMS_ARC_241 R21 POTENTIOMETER 10kOhm 1 SERIE_3362P R23 RESISTOR 100 Ohm 1 0.6W -1% R30 RESISTOR 180 Ohm 1 0,5W U1 LM7805C LM7805C 1 TO220 + Heater U2 LM2936Z5 LM2936Z5 1 TO92 U3-U4-U7-U8 74ACT573 74ACT573 4 CMS U5 TSC80C31 Socket 1 PLCC44 U6 AT49HF010-45JC Socket 1 PLCC32 U9 ICL232CBE ICL232CBE 1 CMS U10 HEF4555P HEF4555P 1 DIL U12 TSC80C51 Socket 1 DIL24 U13 TSC80C51 Socket 1 PLCC68 U14 74ACT14 74ACT14 1 CMS U15 74ACT00 74ACT00 1 CMS X1 Quartz_11,0592 11,0592MHz 1 HC49/4H X2 Quartz_22,1184 22,1184MHz 1 HC49/U

226

HOJA DE DATOS DE LA TARJETA: CAN EXTENSION BOARD

227

LISTA DE MATERIALES DE LA TARJETA: CAN EXTENSION BOARD

Reference Value Quantity C1,C2 22pF 2 C3 100 nF 1 J1 2 pin connector 1 J2 DB9 Female Connector 1 R1 120Ω 1/4W 1 U1 PLCC44 Socket 1 U2 DIP8 socket 1 U3 CAN Driver ATA6660 or compatible 1 X1 12MHz Crystal 1 J12 DIN3*32 Female Connector 1 J10 Jumper Spacing 2.54 mm 1

diseño e implementación de un sistema educativo del protocolo de comunicaciones can

Documents