UNIVERSIDAD DE SANTIAGO DE CHILE

FACULTAD DE INGENIERA DEPARTAMENTO DE INGENIERA ELCTRICA

DISEO E IMPLEMENTACIN DE UN SISTEMA EDUCATIVO DEL PROTOCOLO DE COMUNICACIONES CAN

ERTON ESTEBAN OSSANDN TAPIA

PROFESOR GUA: ERNESTO ALEJANDRO PINTO LINCOIR Trabajo de titulacin presentado en conformidad a los requisitos para obtener el ttulo de ingeniero civil en electricidad

SANTIAGO CHILE 2011

 Erton Esteban Ossandn Tapia Se autoriza la reproduccin parcial o total de esta obra, con fines acadmicos, por cualquier forma, medio o procedimiento, siempre y cuando se incluya la cita bibliogrfica del documento.

HOJA DE CALIFICACIN

DEDICATORIA

A mi hermano Rodrigo por todo el esfuerzo que haz hecho para que yo logre obtener mi ttulo

El hombre inteligente se repone fcilmente de sus fracasos; mientras que el tonto jams logra reponerse de sus xitos Sacha Guitry

ii

AGRADECIMIENTOS
Quisiera comenzar agradeciendo a los profesores de mi comisin evaluadora por el tiempo invertido en este trabajo de ttulo, en particular a mi profesor gua 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 ttulo como la culminacin de todo mi proceso universitario, no puedo dejar de agradecer a todas las personas que durante todos estos aos han estado conmigo y que de una u otra forma me han apoyado, en particular a: Mis compaeros 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 difciles) 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 ensearme a Debuggear!!!), Oscar (Oskiniak, gracias por la alegra brindada y por ayudar a superarme de forma competitiva), Felipe (Felipn, gracias por entregar tus certeras opiniones). A toda mi familia, en especial a mis hermanos: Rodrigo (Cokin, gracias por ayudarme en un momento difcil en mi vida, ser un gran apoyo y ofrecerme la tranquilidad necesaria para poder titularme) y Gustavo (Sapatn, gracias por ser una persona incondicional conmigo); y finalmente a Carolina (Carito, gracias por aguantarme en tu casa en las maanas de los das sbado!).

iii

TABLA DE CONTENIDOS
TABLA DE CONTENIDOS NDICE DE TABLAS NDICE DE ILUSTRACIONES RESUMEN CAPTULO 1.- INTRODUCCIN 1.1.- OBJETIVO GENERAL 1.2.- OBJETIVOS ESPECFICOS 1.3.- ORIGEN Y NECESIDAD 1.4.- DESARROLLO Y ALCANCES CAPTULO 2.- CARACTERSTICAS DE LAS REDES INDUSTRIALES 2.1.- BENEFICIOS DE LAS REDES 2.2.- REDES DE CONTROL Y REDES DE DATOS 2.3.- CARACTERSTICAS DE LAS REDES DE CONTROL 2.4.- VENTAJAS DE LOS BUSES DE CAMPO 2.5.- COMUNICACIONES EN ENTORNOS INDUSTRIALES 2.6.- CLASIFICACIN DE LAS REDES INDUSTRIALES
2.6.1.- SEGN SU TOPOLOGA 2.6.2.- SEGN SU ACCESO AL MEDIO 2.6.3.- SEGN SU MODELO DE COMUNICACIN 2.6.4.- SEGN SUS PRESTACIONES 2.6.5.- SEGN EL TIPO DE COMUNICACIN

IV IX XI XVI 1 1 1 1 2 4 4 5 7 10 12 12
13 16 18 19 21

iv

CAPTULO 3.- ESTADO DEL ARTE DEL PROTOCOLO DE COMUNICACIONES CAN 3.1.- PROTOCOLO DE COMUNICACIONES CAN 3.2.- CONCEPTOS BSICOS DEL BUS CAN 3.3.- CAPA FSICA (PHY)
3.3.1.- SUBCAPA DE SEALIZACIN FSICA (PLS) 3.3.1.1.- Representacin de Bits 3.3.1.2.- Temporizacin de Bits 3.3.1.3.- Mecanismos de Sincronizacin de Bits 3.3.1.4.- Tipos de Sincronizacin 3.3.1.5.- Impacto de la Velocidad de Transferencia en la Longitud del Bus 3.3.1.6.- Tolerancia de Oscilacin 3.3.2.- SUBCAPA DE UNIN AL MEDIO FSICO (PMA) 3.3.3.- SUBCAPA DE INTERFAZ DEPENDIENTE DEL MEDIO (MDI) 3.3.3.1.- Medio Fsico 3.3.3.2.- Tipos de Conectores CAN 3.3.3.3.- Topologa de Una Red CAN 3.3.4.- ESTNDARES DE LA CAPA FSICA 3.3.4.1.- Estndar ISO 11898-2 3.3.4.2.- Estndar ISO 11898-3 3.3.4.3.- Estndar SAE J2411 3.3.4.4.- Estndar ISO 11992 3.3.4.5.- Recomendacin CiA DS-102 3.3.4.6.- Recomendaciones de Capa Fsica por los Estndares HLP

22 22 23 25
26 26 28 30 31 33 35 37 38 38 41 44 45 46 49 52 53 55 57

3.4.- CAPA DE ENLACE DE DATOS (DLL)

3.4.1.- CONTROL DE ENLACE LGICO (LLC) 3.4.2.- CONTROL DE ACCESO AL MEDIO (MAC) 3.4.2.1.- Arbitraje del Bus 3.4.2.2.- Transmisin de Mensajes 3.4.2.3.- Codificacin de Tramas 3.4.2.4.- Validacin de Tramas 3.4.2.5.- Deteccin y Manejo de Errores

60
61 62 62 66 75 75 75

3.5.- DESCRIPCIN DE LA SUPERVISIN

79 v

3.6.- CAPA DE APLICACIN

3.6.1.- CAL 3.6.2.- CANOPEN 3.6.3.- DEVICENET 3.6.4.- SDS 3.6.5.- OSEK/VDX 3.6.6.- CAN KINGDOM

81
83 84 86 87 88 90

CAPTULO 4.- REFERENCIAS PARA LA UTILIZACIN DEL KIT DE DESARROLLO CAN 4.1.- DESCRIPCIN DEL HARDWARE
4.1.1.- MICROCONTROLADOR 4.1.2.- CONECTORES DE ENERGA 4.1.3.- RELOJ DEL SISTEMA 4.1.4.- INTERRUPTOR DE ENCENDIDO/APAGADO 4.1.5.- BOTN DE REINICIO 4.1.6.- BOTN DE INTERRUPCIN 4.1.7.- PANTALLA LCD 4.1.8.- BARRA DE LEDS 4.1.9.- PUERTO RS-232 4.1.10.- PUERTO CAN

92 92
94 97 98 98 99 99 99 99 99 100

4.2.- DESCRIPCIN DEL SOFTWARE

4.2.1.- ENTORNO DE DESARROLLO INTEGRADO 4.2.1.1.- Tipos de Variables 4.2.1.2.- Operaciones y Asignaciones a Nivel de Bits 4.2.1.3.- Estructura de un Programa Escrito en C 4.2.1.4.- Rutinas de Interrupcin 4.2.1.5.- Crear un Programa de Referencia 4.2.1.6.- Agregar Opciones de Depuracin 4.2.2.- HERRAMIENTA DE PROGRAMACIN DEL SISTEMA 4.2.2.1.- Condiciones de Hardware 4.2.2.2.- Uso del Programador de Sistema

100
100 101 103 103 104 106 112 116 116 119

vi

CAPTULO 5.- PUESTA EN FUNCIONAMIENTO DEL SISTEMA CAN

126

5.1.- INTRODUCCIN A LA PROGRAMACIN DE APLICACIONES PARA EL KIT DE DESARROLLO 126

5.1.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE 5.1.2.- CONVENCIONES DE PROGRAMACIN 5.1.3.- ESTNDAR RS-232 5.1.4.- LABORATORIO N1.1 5.1.5.- LABORATORIO N1.2 5.1.6.- LABORATORIO N1.3 127 127 129 132 134 136

5.2.- ESTUDIO DE LA CAPA FSICA Y DE ENLACE DE DATOS DEL PROTOCOLO CAN 144
5.2.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE 5.2.2.- LIBRERA DE COMUNICACIN CAN 5.2.3.- LABORATORIO N2.1 5.2.4.- LABORATORIO N2.2 145 146 153 160

5.3.- ESTUDIO DE APLICACIONES GATILLADAS EN EL TIEMPO

5.3.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE 5.3.2.- ESTRUCTURA DE APLICACIONES GATILLADAS EN EL TIEMPO 5.3.3.- LABORATORIO N3.1 5.3.4.- LABORATORIO N3.2 5.3.5.- LABORATORIO N3.3

162
163 163 166 168 169

5.4.- IMPLEMENTACIN DE APLICACIONES QUE HAGAN USO DEL MODELO DE COMUNICACIN CAN 171
5.4.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE 5.4.2.- FLEXIBILIDAD DEL MODELO PRODUCTOR/CONSUMIDOR 5.4.3.- MONTAJE DEL SISTEMA 5.4.4.- LABORATORIO N4.1 5.4.5.- LABORATORIO N4.2 172 173 174 175 176

CAPTULO 6.- CONCLUSIONES

178

vii

GLOSARIO BIBLIOGRAFA ANEXOS ANEXO A: GUAS DE LABORATORIO

EXPERIENCIA N1: REFERENCIAS PARA LA UTILIZACIN DEL KIT DE DESARROLLO CAN EXPERIENCIA N2: INTRODUCCIN A LA PROGRAMACIN DE APLICACIONES PARA EL KIT DE DESARROLLO EXPERIENCIA N3: ESTUDIO DE LA CAPA FSICA Y DE ENLACE DE DATOS DEL PROTOCOLO CAN EXPERIENCIA N4: ESTUDIO DE APLICACIONES GATILLADAS EN EL TIEMPO EXPERIENCIA N5: IMPLEMENTACIN DE APLICACIONES QUE HAGAN USO DEL MODELO DE COMUNICACIN CAN

180 184 188 189

190 195 202 208 213

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

HOJA DE DATOS DE LA TARJETA: C51 DEMO BOARD LISTA DE MATERIALES DE LA TARJETA: C51 DEMO BOARD HOJA DE DATOS DE LA TARJETA: CAN EXTENSION BOARD LISTA DE MATERIALES DE LA TARJETA: CAN EXTENSION BOARD 219 225 226 227

viii

NDICE DE TABLAS
Tabla 3.1.- Velocidad de transferencia de datos y longitud del bus ............................ 34 Tabla 3.2.- Asignacin de terminales en el conector DB9 ........................................... 42 Tabla 3.3.- Asignacin de terminales del conector tipo mini ....................................... 42 Tabla 3.4.- Asignacin de terminales del conector tipo micro .................................... 43 Tabla 3.5.- Asignacin de terminales del conector tipo nano...................................... 43 Tabla 3.6.- Asignacin de terminales del conector tipo abierto .................................. 44 Tabla 3.7.- Niveles nominales de voltaje en el bus CAN de acuerdo al estndar ISO 11898-2 ................................................................................................................ 47 Tabla 3.8.- Niveles de voltaje en el bus CAN de acuerdo al estndar ISO 11898-3 .... 50 Tabla 3.9.- Niveles de las seales CAN en el bus recomendados por el estndar ISO 11992.................................................................................................................... 54 Tabla 3.10.- Velocidades de transferencia y parmetros de tiempos de bit recomendados en DS-102 ........................................................................................... 55 Tabla 3.11.- Parmetros de tiempos de bit recomendados por DS-102 ..................... 56 Tabla 3.12.- Lnea de bus interconectada de acuerdo a la recomendacin DS-102 ... 57 Tabla 3.13.- Extensin de red y longitud de lnea de extensin para DeviceNet ......... 59 Tabla 3.14.- Velocidades de transferencia y longitudes de lnea recomendadas para SDS ............................................................................................................................. 60 Tabla 3.15.- Representacin bit a bit del arbitraje en el bus CAN ............................... 64 Tabla 3.16.- Codificacin de los bits DLC segn la longitud de los datos .................. 70 Tabla 3.17.- Ventajas y caractersticas de CANopen .................................................. 85 Tabla 4.1.- Caractersticas del kit de desarrollo para los microcontroladores Atmel T89C51CC0x ............................................................................................................... 94

ix

Tabla 4.2.- Tipos de variables soportados por el compilador C51 ............................ 102 Tabla 4.3.- Tipos de SFR que maneja el compilador C51 ......................................... 103 Tabla 4.4.- Operaciones a nivel de bits que permite el lenguaje C ............................ 103 Tabla 4.5.- Asignaciones a nivel de bits que permite el lenguaje C ........................... 103 Tabla 4.6.- Detalle de los tipos de interrupciones del microcontrolador Atmel T89C51CC01 ............................................................................................................. 105 Tabla 5.1.- Requerimientos de software y de hardware para el laboratorio n1 ........ 127 Tabla 5.2.- Definicin de tipos entregados en el archivo compiler.h ....................... 129 Tabla 5.3.- Definicin 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 transmisin ....................................................................................... 138 Tabla 5.5.- Valores de recarga de los registros RCAP2H y RCAP2L para obtener distintas velocidades de transmisin ......................................................................... 139 Tabla 5.6.- Velocidades de transmisin requeridas para la configuracin del puerto RS-232 ...................................................................................................................... 142 Tabla 5.7.- Requerimientos de software y de hardware para el laboratorio n2 ........ 146 Tabla 5.8.- Velocidades de transmisin requeridas para la configuracin 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 n3 ...... 163 Tabla 5.12.- Requerimientos de software y de hardware para el laboratorio n4 ...... 173

NDICE DE ILUSTRACIONES
Figura 2.1.- Comparacin de la red Ethernet ante variaciones del tamao de los paquetes ....................................................................................................................... 6 Figura 2.2.- Topologas de red .................................................................................... 16 Figura 2.3.- Clasificacin de protocolos segn su acceso al medio ........................... 17 Figura 2.4.- Clasificacin de los diversos buses de campo segn sus prestaciones .. 21 Figura 3.1.- Arquitectura de capas del protocolo CAN ............................................... 23 Figura 3.2.- Arquitectura de la capa fsica del protocolo CAN .................................... 26 Figura 3.3.- Comparacin de la representacin de bits del cdigo NRZ y el cdigo Manchester.................................................................................................................. 27 Figura 3.4.- Ejemplo del procedimiento de insercin de bit ........................................ 27 Figura 3.5.- Principio de derivacin del periodo de bit................................................ 28 Figura 3.6.- Segmentos del tiempo de bit ................................................................... 29 Figura 3.7.- Ejemplo de definicin de un tiempo de bit ............................................... 30 Figura 3.8.- Relacin 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 transmisin elctrico .............................................................. 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 seal en el bus CAN recomendados por el estndar ISO 11898-2 ................................................................................................. 47

xi

Figura 3.17.- Niveles nominales de las seales presentes en un transceptor CAN ..... 49 Figura 3.18.- Niveles de seal en el bus CAN recomendados por el estndar 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 seal CAN en el bus de acuerdo al estndar SAE J2411 ................................................................................................................... 53 Figura 3.21.- Niveles nominales de las seales CAN en el bus de acuerdo con el estndar 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 estndar y extendida ................................... 67 Figura 3.26.- Campo de control .................................................................................. 69 Figura 3.27.- Campo CRC .......................................................................................... 70 Figura 3.28.- Campo de aceptacin ........................................................................... 71 Figura 3.29.- Formato de una trama remota ............................................................... 72 Figura 3.30.- Formato de una trama de error .............................................................. 72 Figura 3.31.- Formato de una trama de sobrecarga ................................................... 74 Figura 3.32.- Diagrama de flujo para el manejo de errores ......................................... 77 Figura 3.33.- Diagrama de estados de error de un nodo CAN .................................... 81 Figura 3.34.- Arquitectura general de un sistema basado en CAL .............................. 84 Figura 3.35.- Arquitectura general de un sistema basado en CANopen ..................... 86 Figura 3.36.- Arquitectura de protocolos DeviceNet ................................................... 87

xii

Figura 3.37.- Arquitectura de protocolos SDS ............................................................ 88 Figura 3.38.- Arquitectura OSEK/VDX......................................................................... 90 Figura 3.39.- Representacin de una red CAN con CAN Kingdom ............................. 91 Figura 4.1.- Tarjeta de demostracin C51 conectada a la tarjeta de extensin CAN .. 92 Figura 4.2.- Diagrama de bloques del microcontrolador Atmel T89C51CC01 ............ 95 Figura 4.3.- Distribucin de pines del microcontrolador Atmel T89C51CC01 en formato PLCC44 .......................................................................................................... 95 Figura 4.4.- Esquema de la tarjeta de demostracin C51 ........................................... 97 Figura 4.5.- Tarjeta de demostracin 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 cdigo escrito en C de una rutina de interrupcin .................................................................................................................................. 105 Figura 4.8.- Interfaz grfica de inicio del IDE Keil Vision3 ....................................... 106 Figura 4.9.- Ventana de seleccin de dispositivo...................................................... 107 Figura 4.10.- Men desplegable Options for Target................................................ 108 Figura 4.11.- Pestaa Target de la ventana Options for Target ............................. 109 Figura 4.12.- Pestaa 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.- Pestaa Debug de la ventana Options for Target ............................ 113 Figura 4.16.- Men desplegable New Group .......................................................... 114 Figura 4.17.- Men desplegable Add Files to Group............................................... 115 Figura 4.18.- Estructura del proyecto my_project ................................................... 116

xiii

Figura 4.19.- Conexin entre el PC y el kit de desarrollo CAN mediante RS-232 ..... 117 Figura 4.20.- Condicin de hardware configurado para arrancar en modo Gestor de Arranque ................................................................................................................... 118 Figura 4.21.- Condicin de hardware configurado para arrancar en modo Aplicacin de Usuario ................................................................................................................ 119 Figura 4.22.- Interfaz grfica de inicio del programador FLIP ................................... 120 Figura 4.23.- Ventana del programador FLIP con el dispositivo T89C51CC01 seleccionado ............................................................................................................. 121 Figura 4.24.- Configuracin del puerto RS-232 ........................................................ 122 Figura 4.25.- Conexin exitosa del kit de desarrollo ................................................. 123 Figura 4.26.- Archivo hexadecimal debidamente cargado ........................................ 124 Figura 4.27.- Programacin exitosa del microcontrolador ........................................ 125 Figura 5.1.- Ejemplo de utilizacin del archivo config.h incluido en las rutinas ....... 128 Figura 5.2.- Ejemplo de utilizacin de la librera de la pantalla LCD .......................... 133 Figura 5.3.- Estructura del proyecto display ........................................................... 133 Figura 5.4.- Ejemplo de utilizacin de la librera de la barra de LEDs....................... 135 Figura 5.5.- Estructura del proyecto bargraph ........................................................ 136 Figura 5.6.- Ejemplo de utilizacin de la librera stdio.h .......................................... 140 Figura 5.7.- Estructura del proyecto rs232.............................................................. 141 Figura 5.8.- Conexin entre el PC y el kit de desarrollo CAN para visualizar mensajes mediante RS-232....................................................................................................... 143 Figura 5.9.- Configuracin del puerto RS-232 .......................................................... 144 Figura 5.10.- Ejemplo de utilizacin del archivo config.h para la definicin de rutinas .................................................................................................................................. 151 Figura 5.11.- Cdigo de las rutinas de interrupcin de la librera CAN...................... 152

xiv

Figura 5.12.- Ejemplo de utilizacin de la librera CAN para la transmisin de mensajes .................................................................................................................................. 154 Figura 5.13.- Ejemplo de utilizacin de la librera CAN para la recepcin 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.- Conexin 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.- Conexin entre el PC y el kit de desarrollo CAN para visualizar los mensajes de los nodos trasmisores/receptores mediante RS-232 ............................ 171 Figura 5.23.- Resumen de la flexibilidad del modelo productor/consumidor ............ 174 Figura 5.24.- Formato de mensajes en los modelos: a) cliente/servidor y b) productor/consumidor ............................................................................................... 174 Figura 5.25.- Montaje para los laboratorios Nodo1/Nodo2 y Maestro/Esclavo ......... 175

xv

TTULO: Diseo e implementacin de un sistema educativo del protocolo de comunicaciones CAN. CLASIFICACIN TEMTICA: Protocolos: redes industriales; Comunicaciones aplicadas al control; Control automtico; Microcontroladores; Software; Hardware. AUTOR: Ossandn Tapia, Erton Esteban CARRERA: Ingeniera Civil en Electricidad PROFESOR GUA: Pinto Lincoir, Ernesto Alejandro AO: 2011 CDIGO DE UBICACIN BIBLIOTECA:

2011 / E / 040

RESUMEN
El presente trabajo propone potenciar a los estudiantes en el conocimiento de los buses CAN (Controller Area Network) a travs 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 anlisis de las caractersticas y clasificacin de los buses de campo. Luego, se hace un estudio minucioso del protocolo CAN abarcando los aspectos ms relevantes: la capa fsica, la capa de enlace de datos y los estndares de la capa de aplicacin. A continuacin, 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 ayudarn al alumno a entender en profundidad el bus CAN.

xvi

CAPTULO 1.- INTRODUCCIN

1.1.- OBJETIVO GENERAL
El objetivo general de este proyecto es disear e implementar un sistema educativo del protocolo de comunicaciones CAN (Controller Area Network) para ser una herramienta de apoyo didctico en la enseanza de este protocolo.

1.2.- OBJETIVOS ESPECFICOS

Para cumplir el objetivo general, a continuacin se detallan objetivos ms especficos, que se derivan del general y lo complementan: 1.- Realizar un anlisis del estado del arte de la evolucin 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 caractersticas, as como tambin describir los mdulos necesarios que conforman las comunicaciones en redes industriales a travs del protocolo de comunicaciones CAN. 3.- Disear una serie de laboratorios utilizando un kit de desarrollo para ensear el protocolo CAN considerando aspectos acadmicos. 4.- Comprobar la validez de los laboratorios implementados. Realizar pruebas en cunto a funcionamiento y calidad.

1.3.- ORIGEN Y NECESIDAD

Debido a que los alumnos de la carrera de telecomunicaciones no tienen una clara visin del concepto de buses de campo, se origina la necesidad de potenciar a los estudiantes en el conocimiento de dicho concepto; en particular 1

del bus de campo CAN, donde no slo en la industria de control automotriz se est utilizando este protocolo, sino que tambin se est expandiendo a la automatizacin de edificios, aeronutica, control industrial, equipamiento mdico, entre otros.

1.4.- DESARROLLO Y ALCANCES

A continuacin se realiza una breve descripcin de los temas abordados en este trabajo de ttulo, adems del desarrollo de los contenidos y alcances de stos. En el captulo 2, Caractersticas de las Redes Industriales, se hace un anlisis de los buses de campo, mostrando aspectos de: beneficios, comparativas, caractersticas, ventajas, estandarizacin y clasificaciones que se pueden realizar en torno a ellos. En el captulo 3, Estado del Arte del Protocolo de Comunicaciones CAN, se realiza un estudio de requisitos para implementar un sistema de transmisin en redes industriales a travs del protocolo de comunicaciones CAN, tanto en el aspecto de mdulos requeridos como la disponibilidad de equipos que renan tales caractersticas. En el captulo 4, Referencias para la Utilizacin del Kit del Desarrollo CAN, describe los componentes de software y de hardware necesarios para la utilizacin del kit de desarrollo, detallndose los procedimientos de programacin y creacin de aplicaciones para el sistema. En el captulo 5, Puesta en Funcionamiento del Sistema CAN, se disea una serie de experiencias de laboratorio para ayudar al alumno a entender en profundidad el bus CAN, se propone una metodologa para crear aplicaciones

utilizando un kit de desarrollo, y paralelamente, se ensean los aspectos ms relevantes del protocolo CAN. Finalmente, en el captulo 6, Conclusiones, se comentan los resultados obtenidos y se establecen las conclusiones derivadas de la realizacin de este trabajo de ttulo.

CAPTULO 2.- CARACTERSTICAS DE LAS REDES INDUSTRIALES

El propsito de este captulo es hacer un anlisis de los buses de campo, mostrando aspectos de: beneficios, comparativas, caractersticas, ventajas, estandarizacin y clasificaciones que se pueden realizar en torno a ellos.

2.1.- BENEFICIOS DE LAS REDES

El concepto bsico de un sistema de red es que todos los dispositivos estn conectados y se comunican entre ellos usando un nico sistema estndar. El grado en el que esto afecto a cada dispositivo depende de la simplicidad del sistema en trminos de su implementacin y su uso. El permitir a los dispositivos sencillos comunicarse por medio de una red puede causar un incremento significativo en la complejidad y sofisticacin del dispositivo, lo que significa un costo extra, mientras que el beneficio extra para el propio dispositivo puede ser mnimo. Sin embargo, la capacidad de integracin con otros expandir la funcionalidad del sistema convirtindolo 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 mnimo entre dispositivos y reducir los costos de implementacin. Capacidad de los sistemas de control de expandirse sobre grandes reas geogrficas. Capacidad de aadir ms dispositivos al sistema sin necesidad de redisearlo. Un estndar de comunicaciones bsico nico, para que los ingenieros 4

puedan aprenderlo y mantenerlo. Independencia del vendedor, si el estndar est ampliamente aceptado en la industria, por ejemplo, protocolos abiertos. Otro beneficio asociado a las redes es que permiten transmitir datos a travs de un sistema estndar de cableado que es compartido por mltiples dispositivos, por lo que cualquier sistema estndar de cableado, como un cable de par trenzado entre dispositivos, tendr el beneficio inmediato del recorte de costos con respecto a la cantidad requerida, instalacin e implementacin. Adems se suma otro beneficio, que es la reduccin de costos de mantenimiento y prediccin de fallos. Los sistemas de redes pueden, en general, expandirse fcilmente. Adems, cuando se utilizan dispositivos estndar, la tarea de expansin 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 comunicacin 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 estn orientadas al transporte de grandes paquetes de datos, que aparecen de forma espordica (baja carga) y con un gran ancho de banda para permitir el envo rpido de una gran cantidad de datos. En contraste, las redes de control se enfrentan a un trfico formado por un gran nmero de pequeos paquetes, intercambiados con frecuencia (alta carga) entre un alto nmero de estaciones que forman la red y que muchas veces trabajan en tiempo real.

En principio, las redes de datos podran 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 informacin que una red Ethernet es capaz de transportar cae bruscamente cuando se utiliza por encima del 35% de la capacidad del canal, si el tamao de los mensajes es pequeo, como puede verse en la Figura 2.1. En las redes de control es habitual encontrar este tipo de carga, porque el trfico de la red depende directamente de eventos externos que estn siendo controlados (o monitorizados) por los diferentes nodos que la componen. A menudo, varios nodos necesitan enviar informacin simultneamente en funcin de uno o ms eventos externos. Este hecho, junto con el gran nmero de nodos que suelen estar presentes, implica la existencia de frecuentes periodos en los que muchas estaciones envan pequeos paquetes de informacin.

Figura 2.1.- Comparacin de la red Ethernet ante variaciones del tamao de los paquetes

2.3.- CARACTERSTICAS DE LAS REDES DE CONTROL

Por las razones expuestas anteriormente, es necesario disear una arquitectura de red adaptada a las caractersticas particulares de este tipo de trfico. En el diseo se debern tener en cuenta aspectos como los tipos de protocolos utilizados, la interoperabilidad, la topologa y la facilidad de administracin. Por lo que se refiere al tipo de topologa que deben adoptar las redes de control, cabe destacar que cualquiera de las topologas clsicas de las redes de datos es vlida. Cada una de ellas con sus propias ventajas y limitaciones. Cualquiera puede satisfacer las necesidades de cableado, prestaciones y costo de algn tipo de aplicacin. La eleccin 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 topologa, afecta prcticamente a cualquier otro aspecto de la red de control: costo, facilidad de instalacin, fiabilidad, prestaciones, facilidad de mantenimiento y expansin. El control de acceso al medio es vital. Elegida una topologa, 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 parmetro 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 informacin puede ser originada y/o recibida por cualquier nodo. La forma en que se direccionen los paquetes de informacin afectar de

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 simultneamente. Broadcast: El paquete es enviado a todos los nodos de la red simultneamente. El direccionamiento broadcast presenta la ventaja de su sencillez y es adecuado para redes basadas en informacin de estado, su funcionamiento se basa en que cada nodo informa a todos los dems cul 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 ms eficientes, y facilitan operaciones como el acuse de recibo y el reenvo, caractersticas 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 jerrquicos del control de forma sencilla, a la vez que simplifica el funcionamiento de la red y por tanto abarata los costos de la interfaz fsica. La eleccin del medio fsico afecta a aspectos tales como la velocidad de transmisin, distancia entre nodos y fiabilidad. En muchas redes de control se recurre a una mezcla de distintos medios fsicos para cumplir con los requisitos de diferentes secciones al menor costo posible. Se incorporarn los enrutadores, puentes o repetidores necesarios para asegurar el objetivo de una comunicacin extremo a extremo transparente al menor costo posible y sin que la integracin conlleve una disminucin de las prestaciones. El control en tiempo real es tambin otro aspecto importante a considerar ya que demanda de las redes de control buenos tiempos de 8

respuesta. Por ejemplo, el retardo entre la deteccin de un objeto en una lnea de montaje de alta velocidad y el arranque de una mquina de pintado puede ser del orden de decenas de milisegundos. En general, las redes de datos no necesitan una respuesta en tiempo real cuando envan grandes conjuntos de datos a travs de la red. El control de acceso al medio y el nmero de capas implementadas en la arquitectura de red resultan determinantes a la hora de fijar la velocidad de respuesta de la red. La implementacin 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 ms sencillo que por ejemplo slo implementase las dos primeras capas. Otra forma de favorecer un tiempo de respuesta pequeo es la capacidad para establecer mensajes con diferentes prioridades, de forma que mensajes de alta prioridad (como por ejemplo una alarma) tengan ms 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 proteccin frente a accesos no autorizados a la red, y por otra parte la proteccin frente a fallos del sistema y averas. El primer problema es el menos grave, ya que la mayor parte de las redes de control no estn conectadas a redes externas a la fbrica. Adems en la prctica, la mayor parte de las veces, las redes pertenecientes a los dispositivos de sensores y actuadores no estn conectadas ni siquiera con las redes de nivel superior dentro de la propia fbrica. En cualquier caso, los mecanismos de proteccin son similares a los empleados en las redes de datos: claves de usuario y autentificacin de los nodos de la red. La proteccin frente a fallos juega un papel mucho ms importante, debido a que se debe evitar, que este hecho afecte negativamente a la planta.

Por ejemplo, los sistemas de refrigeracin de una central nuclear no pueden bloquearse porque la interfaz de comunicaciones de un nodo de la red se avere. Para ello es fundamental que los nodos puedan detectar si la red est funcionando correctamente o no, y en caso de avera puedan pasar a un algoritmo de control que mantenga la planta en un punto seguro. Si el sistema es crtico, se deben incluir equipos redundantes, que reemplacen al averiado de forma automtica en caso de avera. La monitorizacin de la red y la capacidad de diagnstico representan por tanto dos puntos bsicos de cualquier red de control. La necesidad de buenas herramientas de mantenimiento y

administracin de la red son vitales. No slo por lo dicho anteriormente sino que tambin porque en las redes de control las operaciones de reconfiguracin y actualizacin 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 ms atractivos a los usuarios finales, es la reduccin de costos. El ahorro proviene fundamentalmente de tres fuentes: ahorro en costo de instalacin, ahorro en el costo de mantenimiento y ahorros derivados de la mejora del funcionamiento del sistema. Una de las principales caractersticas de los buses de campo es una significativa reduccin en el cableado necesario para el control de una instalacin. Cada clula de proceso solo requiere un cable para la conexin de los diversos nodos. Se estima que puede ofrecer una reduccin de 5 a 1 en los costos de cableado. En comparacin con otros tipos de redes, dispone de herramientas de administracin del bus que permiten la reduccin del nmero de horas necesarias para la instalacin y puesta en marcha. 10

El hecho de que los buses de campo sean ms sencillos que otras redes de uso industrial como por ejemplo MAP 1 hace que las necesidades de mantenimiento de la red sean menores, de modo que la fiabilidad del sistema a largo plazo aumenta. Adems, los buses de campo permiten a los operadores monitorizar todos los dispositivos que integran el sistema e interpretar fcilmente las interacciones entre ellos. De esta forma, la deteccin de las fuentes de problemas en la planta y su correccin resulta mucho ms 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 diseo del sistema. Algunos algoritmos y procedimientos de control que con sistemas de comunicacin tradicionales deban incluirse en los propios algoritmos de control, radican ahora en los propios dispositivos de campo, simplificando el sistema de control y sus posibles ampliaciones. Tambin hay que tener en cuenta que las prestaciones del sistema mejoran con el uso de la tecnologa de los buses de campo debido a la simplificacin en la forma de obtener informacin de la planta desde los distintos sensores. Las mediciones de los distintos elementos de la red estn disponibles para todos los dems dispositivos. La simplificacin en la obtencin de datos permitir el diseo de sistemas de control ms eficientes. Con la tecnologa de los buses de campo, se permite la comunicacin bidireccional entre los dispositivos de campo y los sistemas de control, pero tambin entre los propios dispositivos de campo. Otra ventaja de los buses de campo es que solo incluyen 4 capas (Fsica, Enlace, Aplicacin y Usuario), y un conjunto de servicios de
1

Una arquitectura de comunicaciones independiente del fabricante que permita interconectar todos los elementos de la fbrica

11

administracin. El usuario no tiene que preocuparse de las capas de enlace o de aplicacin, slo necesita saber cul es funcionalidad. Al usuario solo se le exige tener un conocimiento mnimo de los servicios de administracin de la red, ya que parte de la informacin generada por dichos servicios puede ser necesaria para la reparacin de averas en el sistema. De hecho, prcticamente, el usuario solo debe preocuparse de la capa fsica y la capa de usuario.

2.5.- COMUNICACIONES EN ENTORNOS INDUSTRIALES

La estandarizacin de protocolos en la industria es un tema en permanente discusin, donde intervienen problemas tcnicos y comerciales. Cada protocolo esta optimizado para diferentes niveles de automatizacin y en consecuencia responden al inters de diferentes proveedores. Por ejemplo Fieldbus Foundation, PROFIBUS y HART, estn diseados para instrumentacin de control de procesos. En cambio DeviceNet y SDS estn optimizados para los mercados de los dispositivos discretos (on-off) de detectores, actuadores e interruptores, donde el tiempo de respuesta y repetibilidad son factores crticos. Cada protocolo tiene un rango de aplicacin, fuera del mismo disminuye el rendimiento y aumenta la relacin costo/prestacin. 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 comunicacin de varios niveles.

2.6.- CLASIFICACIN DE LAS REDES INDUSTRIALES

Existen muchas maneras de clasificar las redes: en funcin de su funcionalidad, de los protocolos utilizados, de sus prestaciones, del tipo de acceso, de su topologa, etc. En nuestro caso se vern las siguientes:

12

Segn su topologa. Segn su acceso al medio. Segn su modelo de comunicacin. Segn sus prestaciones. Segn el tipo de comunicacin.

2.6.1.- SEGN SU TOPOLOGA

Se llaman topologas de red a las diferentes estructuras de intercomunicacin en que se pueden organizar las redes de transmisin de datos entre dispositivos. Cuando componentes de automatizacin autnomos tales como sensores, actuadores, autmatas programables, robots, etc., intercambian informacin, stos deben interconectarse fsicamente con una estructura determinada. Cada topologa de red lleva asociada una topologa fsica y una topologa lgica. La primera (topologa fsica), es la que define la estructura fsica de la red, es decir, la manera en la que debe ser dispuesto el cable de interconexin entre los elementos de la red (Figura 2.2). La topologa lgica es un conjunto de reglas normalmente asociado a una topologa fsica, que define el modo en el que se gestiona la transmisin de los datos en la red. La utilizacin de una topologa influye en el flujo de informacin (velocidad de transmisin, tiempos de llegada, etc.), en el control de la red, y en la forma en la que sta se puede expandir y actualizar. Topologa en Malla: Este tipo de interconexin proporciona mltiples enlaces fsicos entre los nodos de la red, de tal modo que no existen varios canales de comunicacin compartidos y mltiples caminos de interconexin entre dos nodos. La interconexin es total cuando todos los nodos estn conectados de forma directa entre ellos, existiendo siempre un enlace punto a punto para su intercomunicacin. La

13

interconexin es parcial cuando no todos los nodos pueden conectarse mediante un enlace punto a punto con cualquier otro nodo de la red. Topologa 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 topologa adquiere una importancia decisiva el nodo central que se encarga de controlar toda la comunicacin, pues cualquier perturbacin en el mismo conduce, generalmente, al fallo de la red completa. Su implementacin puede ser una decisin 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. Topologa en Bus: Todos los nodos se conectan a un nico medio de transmisin utilizando transceptores, encargados de controlar el acceso al bus. Los mensajes se envan por el bus y todos los nodos escuchan, aceptando los datos slo en el caso de que vayan dirigidos a l (reconocimiento de su propia direccin). Esta topologa permite la adicin y sustraccin de nodos sin interferir en el resto, aunque un fallo en el medio de transmisin 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 lnea de bus principal mediante segmentos cortos pues ello influye directamente en la velocidad de transmisin y recepcin de datos para ese nodo. Esta es una de las topologas ms utilizadas habitualmente. Puede cubrir largas distancias empleando amplificadores y repetidores. Poseen un costo reducido, siendo las ms sencillas de instalar. La respuesta es excelente con poco trfico, siendo empleadas en redes pequeas. Topologa en rbol: Esta topologa puede interpretarse como el

14

encadenamiento de diferentes estructuras en bus de diferente longitud y de caractersticas diferenciadas, constituyendo diferentes ramas de interconexin. En este caso adquieren gran importancia los elementos que permiten duplicar y enlazar las diferentes lneas, ya que actan como nodos principales de manera anloga a como lo hace el nodo principal de la interconexin en estrella. Dado que existen varias estructuras de bus, cada una debe incorporar sus terminadores y elementos asociados, as como los elementos de enlace. Topologa en Anillo: Los nodos se conectan en serie alrededor del anillo. Sera equivalente a unir los extremos de una red en bus. Los mensajes se transmiten en una direccin (actualmente ya existen topologas en red con envo 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 lnea provoca la cada de la red. Posee una relacin costo/modularidad buena, en general, la instalacin es complicada, aunque es fcil variar el nmero 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 mdulos de comunicaciones y en el medio de comunicacin. El retardo grande para nmero de estaciones elevado.

15

Figura 2.2.- Topologas de red

2.6.2.- SEGN SU ACCESO AL MEDIO

Como es lgico, un nodo no debera poder enviar mensajes siempre que le pareciera. Esto provocara un funcionamiento errneo de la red. Para que la comunicacin tenga coherencia, se establecen polticas de arbitraje, para determinar cundo es posible acceder al bus, y quin puede hacerlo. Segn la forma de acceder al medio existen tres procedimientos bsicos para compartir un canal de comunicaciones: seleccin, reserva y contienda (Figura 2.3). Los dos primeros pueden realizarse con control de acceso centralizado (hay una estacin 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 tcnicas de contienda, tambin denominadas de acceso aleatorio, son especficas para redes con control de acceso distribuido. Seleccin: El usuario es avisado al llegar su turno, y toma el control hasta que finaliza la transmisin de los mensajes que tiene pendientes en cola de espera. En el acceso descentralizado, existe un mtodo de paso de testigo el cual determina que usuario tiene acceso al medio, 16

mientras que en el acceso centralizado, existe un mdulo 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 categora se encuentran: Token Passing, Polling. Reserva: En las tcnicas de reserva, a diferencia de lo que ocurre con las de seleccin, 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 categora se encuentra: Cyclic, Schedule Access. Contienda: Cuando un usuario necesita el canal de comunicacin intenta tomarlo, establecindose 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 categora se encuentran: CSMA/CD, CSMA/CA, CSMA/NBA.

Figura 2.3.- Clasificacin de protocolos segn su acceso al medio

17

2.6.3.- SEGN SU MODELO DE COMUNICACIN

Adems de las diferentes tcnicas de acceso de los sistemas de comunicacin, resulta importante conocer los dos modelos bsicos en los que se enmarca cualquier sistema de comunicacin, estos modelos son: Cliente/Servidor: La comunicacin 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 simultnea del mismo mensaje a todos los nodos, utilizando la red de comunicaciones durante un largo periodo de tiempo. Adems, el tiempo de emisin a todos los nodos cambia segn el nmero de nodos a los que se desea hacer llegar el mensaje, el tipo de difusin utilizado es el envo 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 comunicacin 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 simultneamente y no es necesario repetirlo para cada uno de los nodos a los que est dirigido, con el consiguiente ahorro en el tiempo de utilizacin del bus. As, el tiempo de transmisin resulta constante independientemente del nmero 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 difusin

18

utilizado es el envo 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.- SEGN SUS PRESTACIONES

Una clasificacin de los sistemas de comunicacin en red que se ver ser atendiendo a los aspectos relacionados con sus prestaciones. Buses de Alta Velocidad y Baja Funcionalidad (SensorBus): Diseados para integrar dispositivos simples como finales de carrera, fotoclulas, rels y actuadores simples, funcionando en aplicaciones de tiempo real, y agrupados en una pequea zona de la planta, tpicamente una mquina. Suelen especificar las capas fsica y de enlace del modelo OSI, es decir, seales fsicas 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 diseo de una capa de enlace para el envo eficiente de bloques de datos de tamao medio. Estos mensajes permiten que el dispositivo tenga mayor funcionalidad de modo que permite incluir aspectos como la configuracin, calibracin o programacin del dispositivo. Son buses capaces de controlar dispositivos de campo complejos, de forma eficiente y a bajo costo. Normalmente incluyen la especificacin completa de la capa de aplicacin, 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 estndar para distintos tipos de dispositivos (perfiles) que facilitan la interoperabilidad de dispositivos de distintos fabricantes. Algunos ejemplos son: PROFIBUS DP, DeviceNet, SDS,

19

INTERBUS. Buses de Altas Prestaciones (FactoryBus): Son capaces de soportar comunicaciones a nivel de toda la factora, 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 caractersticas funcionales y de seguridad que se les exigen. La capa de aplicacin oferta un gran nmero de servicios a la capa de usuario, habitualmente caractersticas un subconjunto redes del estndar MMS. con Entre sus incluyen: multimaestro redundancia,

comunicacin maestro-esclavo segn el esquema pregunta-respuesta, recuperacin de datos desde el esclavo con un lmite mximo de tiempo, capacidad de direccionamiento unicast, multicast y broadcast, peticin de servicios a los esclavos basada en eventos, comunicacin de variables y bloques de datos orientada a objetos, descarga y ejecucin remota de programas, altos niveles de seguridad de la red, opcionalmente con procedimientos de autentificacin, conjunto completo de funciones de administracin de la red. Algunos ejemplos son: PROFIBUS, WorldFIP, Fieldbus Foundation. Buses para reas de Seguridad Intrnseca (Intrinsically Safety): Incluyen modificaciones en la capa fsica para cumplir con los requisitos especficos de seguridad intrnseca en ambientes con atmosferas explosivas. La seguridad intrnseca es un tipo de proteccin por la que el aparato en cuestin no tiene posibilidad de provocar una explosin en la atmsfera circundante. Un circuito elctrico o una parte de un circuito tienen seguridad intrnseca, cuando alguna chispa o efecto trmico en este circuito producidos en las condiciones de prueba establecidas por un estndar (dentro del cual figuran las condiciones de operacin normal y de fallo especficas) no puede ocasionar una ignicin. Algunos

20

ejemplos son: PROFIBUS PA, Fieldbus Foundation H1, WorldFIP y HART.

Figura 2.4.- Clasificacin de los diversos buses de campo segn sus prestaciones

2.6.5.- SEGN EL TIPO DE COMUNICACIN

Segn la forma de intercambiar la informacin existen dos tipos de protocolos de comunicaciones de datos: Protocolos orientados a nodos: El intercambio de informacin 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 direccin fuente. Protocolos orientados a mensajes: La informacin a intercambiar se descompone en mensajes, a los cuales se les asigna un identificador y se encapsulan en tramas para su transmisin. Cada mensaje tiene un identificador nico, con el cual los nodos deciden aceptar o no dicho mensaje.

21

CAPTULO 3.- ESTADO DEL ARTE DEL PROTOCOLO DE COMUNICACIONES CAN

El propsito de este captulo es realizar un estudio de requisitos para implementar un sistema de transmisin en redes industriales a travs del protocolo de comunicaciones CAN, tanto en el aspecto de mdulos requeridos como la disponibilidad de equipos que renan tales caractersticas

3.1.- PROTOCOLO DE COMUNICACIONES CAN

El protocolo de comunicacin CAN es uno de los buses de campo ms populares, fue desarrollado por Bosch e Intel al final de los aos 80 como bus de comunicaciones de costos razonables para la industria automotriz, aunque rpidamente se extendi a otros campos como la robtica, automtica y la manufactura. El protocolo CAN, en su especificacin ISO 11898, describe como la informacin ser transmitida entre los diferentes dispositivos de una red. En conformidad con el modelo de referencia OSI, el protocolo CAN garantiza transparencia en el diseo y flexibilidad en las implementaciones definiendo nicamente las capas fsica y enlace de datos, adems establece un mecanismo de supervisin especial para la gestin y control del nodo (Figura 3.1). Existen tambin ciertos protocolos en la capa de aplicacin que proporcionan especificaciones sobre la base de CAN, entre los que se encuentran: CAL, CANopen, DeviceNet, SDS, OSEK/VDX y CAN Kingdom.

22

Figura 3.1.- Arquitectura de capas del protocolo CAN

3.2.- CONCEPTOS BSICOS DEL BUS CAN

CAN es un protocolo de comunicacin serial que utiliza el modelo de comunicacin productor/consumidor el que proporciona los datos a travs de difusin de mensajes, adems es un protocolo orientado a mensajes que posee las siguientes caractersticas: Prioridad de mensajes: Se define mediante el identificador del mensaje durante el acceso al bus de comunicaciones. El identificador tambin 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. Garanta en tiempos de latencia: La longitud de un mensaje es corta,

23

tiene como mximo 8 bytes de datos por mensaje lo que garantiza una baja latencia entre transmisin y recepcin. El mtodo de acceso al medio utilizado es: acceso mltiple por deteccin de portadora con arbitraje no destructivo bit a bit 2 (CSMA/NBA, Carrier Sense Multiple Access with Non-destructive Bitwise Arbitration) esto significa que la colisin de mensajes es evitada por medio de arbitraje tomando en cuenta la prioridad de los mismos. Flexibilidad en la configuracin: En un sistema CAN un nodo no hace ningn uso de la informacin del sistema de configuracin como por ejemplo la direccin fsica de cada estacin, esto hace que el sistema sea flexible, es decir, se puede aadir nodos a la red CAN sin necesidad de ningn cambio de software, hardware o en la capa aplicacin. Recepcin por multidifusin con sincronizacin de tiempos: Todos los nodos de la red reciben el mismo mensaje y realizan el mismo procedimiento de filtrado simultneamente. Sistema robusto en cuanto a consistencia de datos: Todos los receptores verifican la consistencia de la informacin que es recibida y reconocen un mensaje consistente mediante acuses de recibo. Sistema multimaestro: Cuando el bus est libre, cualquier nodo puede iniciar la comunicacin. La unidad con el mensaje de mayor prioridad a ser transmitido gana el acceso al bus. Deteccin y sealizacin de errores: El sistema CAN proporciona alta inmunidad a la interferencia electromagntica, provee adems mecanismos de deteccin de errores como los siguientes: monitoreo, chequeo de redundancia cclica, bits de relleno, chequeo de formato de

La literatura tambin conoce a este mtodo como acceso mltiple por deteccin de portadora con deteccin de colisiones y arbitraje por prioridad del mensaje (CSMA/CD+AMP, Carrier Sense Multiple Access with Collision Detection and Arbitration Message Priority)
2

24

tramas del mensaje. El mecanismo de deteccin de errores permite a los nodos detectar errores globales, errores distribuidos de manera aleatoria, rfagas de errores de longitud menor a 15 y errores de cualquier nmero impar en un mensaje. La probabilidad de error en un mensaje es de 4,7 x 10-11. Retransmisin automtica de tramas errneas tan pronto como el bus est libre: Los mensajes errneos son identificados por una bandera de modo que cualquier nodo est en capacidad de detectar un error. Los mensajes errneos se descartan y se retransmiten automticamente. Aislamiento de fallos 3: Distincin entre errores temporales y fallas permanentes de los nodos de la red, desconexin autnoma de nodos defectuosos.

3.3.- CAPA FSICA (PHY)

La capa fsica de un sistema de comunicaciones define los aspectos del medio fsico para la transmisin de datos entre los nodos de una red, los ms importantes hacen referencia a los niveles de seal, representacin, sincronizacin y tiempos en los que los bits se transfieren al bus. El diseo de una red CAN vara de acuerdo a las necesidades de desempeo y para ello se deben considerar los requisitos de la capa fsica. La especificacin del protocolo CAN no define una capa fsica, sin embargo, los estndares ISO 11898-2 e ISO 11898-3 establecen las caractersticas que deben cumplir las aplicaciones para la transferencia en alta y baja velocidad respectivamente. Cabe mencionar que las caractersticas definidas para la capa fsica deben implementarse en todos los nodos que se
El estndar ISO 11898 y la especificacin CAN 2.0 denominan a este mecanismo como aislamiento de fallos mientras que en la literatura se denomina limitacin de errores. En este trabajo de tesis se emplea el trmino aislamiento de fallos
3

25

encuentren conectados dentro de una red CAN. La capa fsica (PHY, Physical Layer) se divide en tres secciones o subcapas (Figura 3.2), las cuales se describen a continuacin.

Figura 3.2.- Arquitectura de la capa fsica del protocolo CAN

3.3.1.- SUBCAPA DE SEALIZACIN FSICA (PLS)

La subcapa de sealizacin fsica (PLS, Physical Signalling) define las funciones relacionadas con la representacin, temporizacin y sincronizacin de los bits, y est implementada en los controladores del protocolo CAN.

3.3.1.1.- REPRESENTACIN DE BITS

Una trama CAN est codificada de acuerdo con el mtodo NRZ (Non un nivel de seal que puede ser dominante (d) o recesivo (r). Una ventaja de Manchester requiere de flancos en la mitad del tiempo de bit (Figura 3.3). Return to Zero), el cual establece que durante todo el tiempo de bit se genera dicho mtodo, en comparacin con la codificacin Manchester, es que produce una frecuencia menor de operacin, ya que la codificacin

26

Figura 3.3.- Comparacin de la representacin de bits del cdigo NRZ y el cdigo Manchester

Sin embargo, en el caso de transmitir una gran cantidad de bits con la misma polaridad, la codificacin NRZ no proporciona flancos que puedan utilizarse en la sincronizacin y por ello se implementa el procedimiento de insercin de bit (bit stuffing), el cual asegura que en la transmisin de una trama slo puede haber un mximo de cinco bits consecutivos con la misma polaridad como se muestra en la Figura 3.4.

Figura 3.4.- Ejemplo del procedimiento de insercin de bit

27

3.3.1.2.- TEMPORIZACIN DE BITS

Una caracterstica importante del protocolo CAN es la flexibilidad para determinar los parmetros de velocidad de transferencia, punto de muestreo de bit y nmero de muestras realizadas en un periodo de bit. Por lo tanto, el diseo de una red CAN debe considerar los siguientes conceptos: Tiempo de quantum : Es una unidad bsica de tiempo, es de valor

fijo y se deriva del perodo 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 mltiplos enteros de la

unidad bsica de tiempo (t q , time quantum) derivada del periodo del discreta ms pequea utilizada por un nodo CAN.

oscilador t CLK (Figura 3.5). El parmetro t q es la unidad de tiempo

Tiempo de bit nominal ( ): Es la relacin inversa entre el tiempo de correspondiente al el nmero de bits por segundo que un transmisor se divide en cuatro segmentos de tiempo no traslapados (Figura 3.6).

Figura 3.5.- Principio de derivacin del periodo de bit

duracin de un bit (t b ) y la velocidad de transferencia nominal (fb )

ideal emite sin resincronizacin. Se obtiene mediante la Ecuacin 3.1 y

28

tb =

1 fb

[3. 1]

Figura 3.6.- Segmentos del tiempo de bit

Los cuatro segmentos que forman un tiempo de bit nominal son: Segmento de sincronizacin (Sync_Seg): Es el primer segmento del tiempo de bit nominal y el cual es utilizado para la sincronizacin de los nodos en el bus. Su longitud es fija e igual a 1t q .

Segmento de tiempo de propagacin (Prop_Seg): Es utilizado para compensar el retardo de propagacin de la seal en el bus y retardos inherentes a los nodos como los son los retardos del controlador del bus. Su longitud puede tomar los valores enteros de 1 a 8t q .

Segmento de memoria temporal de fase 1 (Phase_Seg1): Segmento de longitud ajustable que se utiliza para compensar variaciones de tiempo entre nodos, puede incrementarse durante la resincronizacin Su longitud puede tomar los valores enteros de 1 a 8t q .

Segmento de memoria temporal de fase 2 (Phase_Seg2): Segmento de longitud ajustable que se utiliza para compensar variaciones de tiempo entre nodos y puede reducirse durante la resincronizacin. Su longitud puede tomar los valores enteros desde el Tiempo de procesamiento de la informacin hasta el mximo definido por

29

Phase_Seg1. El nmero total de unidades bsicas en un tiempo de bit debe ser programable entre 8 a 25t q .

Punto de muestreo: Es el instante de tiempo en el cual se lee y se interpreta el nivel del bus para determinar el valor del bit. Se localiza despus del segmento Phase_Seg1.

Tiempo de procesamiento de la informacin: Es el periodo de tiempo que comienza con el Punto de muestreo reservado para calcular el nivel de bit subsecuente. Su longitud es inferior o igual a 2t q .

Figura 3.7.- Ejemplo de definicin de un tiempo de bit

3.3.1.3.- MECANISMOS DE SINCRONIZACIN DE BITS

El protocolo CAN utiliza transferencia de datos sincrnica, lo cual incrementa la capacidad de transmisin pero requiere un mtodo de sincronizacin de bits debido a que slo 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 resincronizacin continua del receptor. En una red CAN cada nodo se sincroniza con su propio oscilador, debido a ello pueden ocurrir desplazamientos de fase en los diferentes nodos y por lo tanto los controladores CAN proporcionan un mecanismo de

30

sincronizacin para compensar dichos desplazamientos mientras reciben una trama CAN. Antes de analizar las dos formas de sincronizacin descritas por el protocolo CAN, es necesario definir: Error de fase de un flanco: El error de fase de un flanco (e) est dado de la siguiente manera: e = 0, si el flanco se detecta dentro del Sync_Seg. previo.

Sync_Seg y se mide en unidades (t q ). El signo del error de fase se define e > 0, si el flanco se detecta antes del Punto de muestreo. e < 0, si el flanco se detecta despus del Punto de muestreo del bit

por la posicin del flanco respecto al segmento de sincronizacin

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 seal. Cuando la magnitud del Error de fase es mayor que el valor de RJW, y si el error de fase es positivo: El segmento Phase_Seg1 se prolonga por una cantidad igual al valor de RJW (1 a 4t q ).

Resincronizacin: Es el valor programado de unidades (t q ) que se suma

y si el error de fase es negativo: El segmento Phase_Seg2 se reduce por una cantidad igual al valor de RJW (1 a 4t q ).

3.3.1.4.- TIPOS DE SINCRONIZACIN

El protocolo CAN define dos tipos de sincronizacin: Sincronizacin al comienzo de la trama (Forzada): Ocurre en una transicin recesivo-dominante durante el tiempo en donde el bus se 31

encuentra inactivo (bus idle), se obliga al tiempo de bit interno reiniciar con el segmento Sync_Seg al inicio del bit. Resincronizacin dentro de la trama (RJW): Como resultado de una Resincronizacin, 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 lmite superior definido por el parmetro RJW (Resynchronization Jump Width) y deber ser programado entre 1 y 4t q .

Ambas formas de sincronizacin siguen las siguientes reglas: 1.- Dentro de un tiempo de bit slo se permite una sincronizacin. 2.- Para efectos de sincronizacin se utiliza un flanco slo si el valor detectado en el punto de muestreo anterior difiere del valor del bus inmediatamente despus del flanco. 3.- Se realiza una sincronizacin 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 resincronizacin, a excepcin de que un nodo que se encuentre transmitiendo un bit dominante no puede realizar resincronizacin como resultado de una flanco recesivo a dominante con un error de fase positivo, si slo son utilizados para la resincronizacin flancos recesivos a dominantes.

32

3.3.1.5.- IMPACTO DE LA VELOCIDAD DE TRANSFERENCIA EN LA LONGITUD DEL BUS

La longitud mxima del bus CAN depende bsicamente de dos aspectos: Aspectos de corriente alterna: Que corresponden al tiempo de bit, tolerancia del oscilador, retardo de propagacin y capacitancia de la red. Aspectos de corriente directa: Correspondientes a las consecuencias de la amplitud de la seal del bus, impedancia caracterstica de los cables del bus y la impedancia de entrada de los nodos. Como se menciona anteriormente, la capa fsica 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 transmisin, para ello los nodos deben asegurar que la transmisin de un bit dominante se realice dentro del periodo de bit correspondiente y por consiguiente puedan detectar una condicin de prdida del arbitraje y detengan su transmisin. El retardo de propagacin entre los nodos es resultado del retardo de lnea del bus especfica (menor a la velocidad de la luz) y del retardo de los componentes electrnicos. Por esta razn, 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 relacin entre la velocidad de transferencia y la longitud del bus: El primero se enfoca en obtener una longitud de bus mxima dada una

33

velocidad de transferencia y para ello es necesario que la ubicacin del punto de muestreo est lo ms 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 mxima del oscilador, sin embargo, la optimizacin de la tolerancia del oscilador implica una reduccin considerable de la longitud de bus a una velocidad de transferencia dada. La relacin entre la mxima velocidad de transferencia y la mxima longitud de bus, pueden calcularse mediante la Ecuacin 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 estndar ISO 11898 establece una longitud de bus mxima de 1Km, pero permite el uso de puentes y/o repetidores para incrementar la distancia entre los nodos.
Tabla 3.1.- Velocidad de transferencia de datos y longitud del bus Velocidad de Transferencia [Kbps] 1000 500 250 125 62,5 20 Longitud del Bus [m] 40 100 250 500 1000 2500 Tiempo de Bits Nominal [s] 1 2 4 8 20 50

34

Figura 3.8.- Relacin entre velocidad de transferencia y longitud del bus

3.3.1.6.- TOLERANCIA DE OSCILACIN

Como se mencion en los anteriormente, cada nodo CAN deriva su del oscilador fCLK se desva de su valor nominal debido al desplazamiento de seal de tiempo de bit de su propio oscilador. En sistemas reales, la frecuencia tolerancia inicial, al envejecimiento de los componentes electrnicos y a las variaciones de la temperatura ambiental. (f), la cual es una tolerancia relativa que representa la desviacin de la La suma de desviaciones resulta en una tolerancia total del oscilador f = fCLK mx/mn fCLK nom fCLK nom [3. 3]

frecuencia del oscilador normalizada a la frecuencia nominal (Ecuacin 3.3).

del oscilador, f representa la tolerancia relativa de la seal de reloj del

As como la seal de reloj de un sistema CAN se deriva de la frecuencia

35

sistema; los valores mnimos y mximos para la duracin del periodo del reloj del sistema se aproximan como definen las Ecuaciones 3.4 y 3.5. t SCL mn = t SCL nom t SCL nom (1 f) 1 + f [3. 4] [3. 5]

t SCL mx =

sistemas reales, tales como osciladores de cristal (f < 0,1%), frecuencias (f < 1,2%), satisfacen tal consideracin. derivadas de PLL (Phase Locked Loop) (f < 0,5%) y resonadores cermicos

vlidas asumiendo un valor de f << 1. Las referencias de reloj utilizadas en Las aproximaciones que se establecen las Ecuaciones 3.4 y 3.5 son

t SCL nom t SCL nom (1 + f) 1 f

La especificacin CAN, establece una tolerancia mxima para el

oscilador de 1,58%, y recomienda el uso de un resonador de cermica 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 oscilacin requerida por los dems nodos est determinada por el circuito integrado que demande mayor precisin en su oscilador. Los resonadores de cermica se utilizan nicamente cuando todos los nodos de la red cumplen con la especificacin del protocolo CAN posterior a la versin 1.2. En controladores de protocolo que cumplan con la versin 2.0 A/B y anteriores, se recomienda utilizar osciladores de cristal siempre y cuando pertenezcan a la misma red.

36

3.3.2.- SUBCAPA DE UNIN AL MEDIO FSICO (PMA)

La conexin entre el controlador CAN y el medio fsico se define en la subcapa de unin al medio fsico (PMA, Physical Medium Attachment). Esta subcapa describe las caractersticas funcionales y elctricas que debe cumplir el transceptor para hacer posible la transmisin/recepcin entre un nodo y la red, adems algunas de sus implementaciones en circuitos integrados o discretos proporcionan los medios para detectar fallos en el bus. La interfaz elctrica con el bus consiste principalmente de un transmisor y un receptor. La Figura 3.9 muestra el diagrama a bloques bsico de un transceptor en un nodo CAN, el controlador CAN provee funcionalidad bsica de transceptor, que consiste de un comparador en la recepcin y un amplificador en la salida.

Figura 3.9.- Arquitectura de un nodo CAN con transceptor

Adems de la adaptacin de seales entre el controlador CAN y el bus, el transceptor tiene que cumplir con las siguientes funciones: 37

Suministrar la capacidad de rendimiento al controlador CAN. Proteger al controlador CAN contra sobrecargas. Reducir la radiacin electromagntica. Como receptor realiza las siguientes funciones:

Suministrar un nivel de seal recesivo. Proteger el comparador de entrada del controlador CAN contra sobre-voltajes de las lneas del bus. Suministrar suficiente sensibilidad para un mejor reconocimiento de la seal de entrada. Detectar errores en el bus tales como: ruptura de la lnea, corto-circuito y conmutacin a operacin asimtrica de una sola lnea. Una funcin opcional del transceptor es proporcionar aislamiento

galvnico, al nodo CAN de las lneas 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 elctricos y mecnicos para la conexin entre el medio fsico y el nodo. Las especificaciones mecnicas de la capa fsica definen las caractersticas de la interfaz respecto al medio de transmisin y al tipo de conector.

3.3.3.1.- MEDIO FSICO

Un requisito indispensable para realizar el mtodo de arbitraje en el bus, es la capacidad de representar los niveles de seal recesivo y dominante.

38

Dicho principio se realiza con medios elctricos u pticos, los cuales se describen a continuacin. 3.3.3.1.1.- MEDIO DE TRANSMISIN ELCTRICO La implementacin de redes CAN generalmente utiliza como medio fsico un bus de dos hilos con retorno comn controlados diferencialmente. En aplicaciones especficas se utiliza un bus de un slo hilo, por ejemplo en dispositivos electrnicos internos de un vehculo. En la actualidad se desarrollan soluciones en las que se transmiten las seales CAN junto con la fuente de alimentacin en el mismo bus.

Figura 3.10.- Medio de transmisin elctrico

Bus de dos hilos: Permite una transmisin diferencial y es resistente a los errores de modo comn (Figura 3.10a). Las lneas del bus deben contar con un terminador de bus en cada extremo, el cual consiste en resistores de 120 para evitar la reflexin de la seal. Se garantiza la transmisin de una seal a pesar de sus niveles bajos, adems, la interferencia de radio inducida de forma electromagntica 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 comunicacin contine en condiciones de inmunidad de ruido reducida 39

an si una lnea se rompe o se encuentra en corto circuito. Bus de un hilo: Esta solucin da por hecho que est disponible una tierra comn para todos los nodos (Figura 3.10b) y slo se implementa en aplicaciones automotrices para la interconexin de dispositivos electrnicos internos. El bus de un hilo est expuesto a la interferencia inducida elctricamente cuando no est blindado, por lo tanto es necesario realizar un gran desplazamiento del nivel de la seal para mejorar la relacin seal/ruido, lo cual afecta el grado de emisiones electromagnticas y requiere la reduccin de las cadas de la seal y por lo tanto de la mxima velocidad de transferencia de datos. Transmisin de la seal y fuente de alimentacin integrada en la misma lnea: Muchos sistemas de Fieldbus, como AS-Interface y PROFIBUS PA, suministran la fuente de alimentacin junto a la transmisin de datos sobre la misma lnea del bus. El suministro de voltaje sobre el bus es conveniente en sistemas CAN, sin embargo, no se recomienda la transmisin simultnea de alimentacin y datos debido al arbitraje no destructivo bit a bit que utiliza dicho protocolo. Actualmente este tipo de transmisin se encuentra en fase de investigacin y una posible solucin es utilizar modulacin OOK (On-Off Keying) para la transmisin de datos. Las investigaciones muestran que la transmisin simultnea de datos y alimentacin implica la utilizacin de circuitos de alto costo, prdida de inmunidad a la interferencia y reduccin en la longitud del bus, por lo que esta solucin no es competente frente a las ya existentes en el mercado. 3.3.3.1.2.- MEDIO DE TRANSMISIN PTICO Los avances relacionados con los medios de transmisin pticos han obtenido gran importancia en el desarrollo de redes CAN, especialmente en el

40

rea de la fibra ptica. El comportamiento elctricamente neutro de un medio ptico es ideal para aplicaciones en ambientes potencialmente explosivos y entornos electromagnticos perturbados. Las lneas de transmisin y recepcin deben proporcionarse de forma separada, debido al acoplamiento directo en el medio ptico. Adems cada lnea de recepcin debe acoplarse externamente con cada lnea de transmisin con el propsito de asegurar el monitoreo de bits que requiere el protocolo CAN, esta funcin puede implementarse por un acoplador de tipo estrella. El uso de acopladores pasivos tipo estrella es posible con una cantidad pequea de nodos, lo cual limita la expansin de este tipo de redes.

3.3.3.2.- TIPOS DE CONECTORES CAN

A nivel de capa fsica, existen diversos tipos de conectores estandarizados que pueden ser utilizados, pueden ser tanto del tipo cerrado como abierto. La definicin del tipo a ser utilizado depender de la aplicacin y del ambiente de operacin del equipamiento. A continuacin se entregar una lista de conectores ms utilizados para el bus CAN en donde se mostrar la forma y asignacin de terminales de cada modelo. 3.3.3.2.1.- CONECTOR DB9 Conector DB9, recomendacin DS-102 (Tabla 3.2 y Figura 3.11).

41

Tabla 3.2.- Asignacin de terminales en el conector DB9 Pin 1 2 3 4 5 6 7 8 9 Seal CAN_L CAN_GND CAN_SHLD GND CAN_H CAN_V+ Descripcin Futuras aplicaciones Seal de bus CAN (dominante bajo) Seal de tierra (GND) Futuras aplicaciones Blindaje (opcional) Tierra (opcional) Seal de bus CAN (dominante alto) Futuras aplicaciones Fuente de alimentacin 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.- Asignacin de terminales del conector tipo mini Pin 1 2 3 4 5 Seal CAN_SHLD CAN_V+ CAN_GND CAN_H CAN_L Descripcin Blindaje (opcional) Fuente de alimentacin externa (opcional) Seal de tierra (GND) Seal de bus CAN (dominante alto) Seal de bus CAN (dominante bajo)

Figura 3.12.- Conector tipo mini

42

3.3.3.2.3.- CONECTOR TIPO MICRO Conector tipo micro de 5 terminales, o tambin llamado conector M12 (Tabla 3.4 y Figura 3.13).
Tabla 3.4.- Asignacin de terminales del conector tipo micro Pin 1 2 3 4 5 Seal CAN_SHLD CAN_V+ CAN_GND CAN_H CAN_L Descripcin Blindaje (opcional) Fuente de alimentacin externa (opcional) Seal de tierra (GND) Seal de bus CAN (dominante alto) Seal 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 tambin llamado conector M8 (Tabla 3.5 y Figura 3.14).
Tabla 3.5.- Asignacin de terminales del conector tipo nano Pin 1 2 3 4 5 Seal CAN_V+ CAN_SHLD CAN_H CAN_L CAN_GND Descripcin Fuente de alimentacin externa (opcional) Blindaje (opcional) Seal de bus CAN (dominante alto) Seal de bus CAN (dominante bajo) Seal de tierra (GND)

43

Figura 3.14.- Conector tipo nano

3.3.3.2.5.- CONECTOR TIPO ABIERTO Conector tipo abierto (Tabla 3.6 y Figura 3.15).
Tabla 3.6.- Asignacin de terminales del conector tipo abierto Pin 1 2 3 4 5 Seal CAN_GND CAN_L CAN_SHLD CAN_H CAN_V+ Descripcin Seal de tierra (GND) Seal de bus CAN (dominante bajo) Blindaje (opcional) Seal de bus CAN (dominante alto) Fuente de alimentacin externa (opcional)

Figura 3.15.- Conector tipo abierto

3.3.3.3.- TOPOLOGA DE UNA RED CAN

Si no se consideran las medidas apropiadas, las seales elctricas transmitidas en las lneas del bus CAN se reflejan al final de la lnea elctrica principal y en las lneas de extensin, por ello es necesario que las reflexiones sobrepuestas de la seal estn debidamente atenuadas cuando se muestrea el nivel de bit para interpretar los niveles de bus recibidos. Las reflexiones de la 44

seal se pueden evitar al colocar resistores de terminacin con una impedancia equivalente a la de la lnea en ambos extremos del bus, y al evitar lneas de extensin de grandes longitudes. De esta forma, mediante una topologa de bus se puede lograr el producto ms alto de velocidad de transferencia y longitud de lnea (Figura 3.10). En aplicaciones industriales no es comn conectar un nodo al bus mediante lneas de extensin muy cortas, sin embargo, con la configuracin apropiada de los parmetros 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 reflexin de la seal. En muchas aplicaciones es inevitable utilizar topologas extendidas, por ejemplo para conectar herramientas de diagnstico o servicio. Para superar las limitaciones de la topologa de bus CAN se emplean repetidores, puentes y pasarelas con la finalidad de adaptar la topologa de red de acuerdo con las necesidades geogrficas de cada aplicacin especfica.

3.3.4.- ESTNDARES DE LA CAPA FSICA

Como se mencion anteriormente, las redes CAN tienen diversas aplicaciones, sin embargo la especificacin CAN no define las caractersticas del transceptor, y deja abierta la posibilidad de implementar el medio de transmisin y los niveles de seales que ms convengan al diseador de la red. Por ello se han definido diferentes estndares, los cuales especifican: niveles de seales, topologa de la red, mximo nmero de nodos, requisitos para el bus y conectores.

45

Para medios elctricos los voltajes diferenciales son definidos en: ISO 11898-2 (alta velocidad), ISO 11898-3 (tolerante a fallos), SAE J2411 (un slo hilo), ISO 11992 (punto a punto).

3.3.4.1.- ESTNDAR ISO 11898-2

El estndar ISO 11898-2, destinado a la comunicacin de alta velocidad en vehculos, es la norma ms importante y CiA lo recomienda para aplicaciones industriales. Las capas de aplicacin: CANopen, DeviceNet y SDS especifican suplementos a ste estndar. Establece los fundamentos de una serie de estndares y es la norma de capa fsica ms importante en aplicaciones industriales y automotrices. Dicha norma describe las funciones de la subcapa PMA, y algunas caractersticas de la subcapa MDI. Sus principales caractersticas son: Velocidades de transferencia de datos de hasta 1Mbps. Longitud mxima del bus de 40m a 1Mbps. El nmero total de nodos est limitado por la carga elctrica en el bus. Bus diferencial de dos hilos. Seguridad contra corto circuito en el rango de voltaje comprendido entre -3V a +16V. Impedancia caracterstica de la lnea de 120. Rango de voltaje en modo comn desde -2V (CAN_L) a +7V (CAN_H). El estndar ISO 11898-2 define un bus de dos hilos terminado en ambos extremos con la impedancia de lnea especfica del medio fsico y con las siguientes caractersticas elctricas: Longitud mxima de lnea de extensin: 30cm. Resistencia de lnea nominal por metro: 70m/m.

46

Retardo de propagacin nominal: 5ns/m. El bus de dos hilos especificado en el estndar ISO 11898, contiene dos

seales, CAN_H y CAN_L, en donde todo nodo CAN debe proporcionar el voltaje diferencial de salida en el bus (Ecuacin 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 seales en

el bus CAN en especificados en el estndar 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 estndar ISO 11898-2 Seal CAN Estado del Bus Dominante Recesivo Niveles Nominales de Voltaje [V] CAN_H CAN_L Vdiff 3,5 1,5 2 2,5 2,5 0

Figura 3.16.- Niveles nominales de seal en el bus CAN recomendados por el estndar ISO 11898-2

47

Segn el estndar ISO 11898-2, el acceso al medio se realiza mediante un transceptor de alta velocidad, el cual adems realiza otras tareas como obtener las medidas de proteccin requeridas en vehculos de motor. Un transceptor debe cumplir con las siguientes caractersticas: Compatible con la norma ISO 11898-2. Soportar velocidades de transferencia de datos de hasta 1Mbps. Proteger contra sobrecarga trmica. Proteger contra corto circuito, tanto de tierra como de fuente de voltaje. Consumir poca corriente en modo de espera. Proteccin contra perturbaciones de la lnea del bus. Para que un nodo cumpla con el estndar ISO 11898-2 debe contar con un MCU y un controlador CAN, los cuales se conectan al bus mediante un de entrada de datos (R X ) (Figura 3.9). transceptor a travs de dos lneas, una lnea de salida de datos (TX ) y otra lnea Las lneas TX y R X manejan niveles TTL (Transistor-Transistor Logic) y

son unidireccionales; las lneas CAN_H y CAN_L se utilizan para enlazar el transceptor al bus. La Figura 3.17 muestra los niveles nominales de las seales CAN que se presentan en un transceptor CAN de alta velocidad.

48

Figura 3.17.- Niveles nominales de las seales presentes en un transceptor CAN

3.3.4.2.- ESTNDAR ISO 11898-3

El estndar ISO 11898-3 define una capa fsica 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 estndar ISO 11519. Este estndar est dirigido principalmente a la realizacin de redes de unidades electrnicas que aumentan la comodidad en un automvil. Si se considera una red elctricamente corta, no se considera el problema de reflexin de la seal y puede utilizarse una lnea de bus abierta. Lo anterior significa que pueden utilizarse controladores de baja potencia, y con ello realizarse redes de bajo consumo. Otra caracterstica es la topologa de red, la cual no se restringe a una estructura lineal con longitudes de extensin cortas para la conexin entre los nodos y el bus. Asimismo existe la posibilidad de transmitir datos asimtricamente sobre un slo hilo del bus en caso de ocurrir una falla elctrica en sus lneas. Los parmetros ms importantes de este estndar son los siguientes:

49

Velocidades de transferencia de datos de hasta 125Kbps. Redes de hasta 32 nodos. Transmisin de seal simtrica 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 comn entre -2V a +7V. Fuente de alimentacin de 5V. En la Tabla 3.8 y Figura 3.18 se muestran los niveles de las seales en

el bus CAN en especificados en el estndar ISO 11898-3. Los niveles de la seal 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 estndar ISO 11898-3 Seal CAN Estado del Bus Dominante Recesivo CAN_H 5 3,6 0 0,3 Niveles de Voltaje [V] CAN_L Vdiff 1,4 0 2,2 5 4,7 5 -4,4 -5

Figura 3.18.- Niveles de seal en el bus CAN recomendados por el estndar ISO 11898-3

El estndar ISO 11898-3 considera la deteccin y el manejo de las siguientes condiciones de error en el bus:

50

Interrupcin de la seal CAN_H. Interrupcin de la seal CAN_L. Corto circuito de la seal CAN_H con Vcc. Corto circuito de la seal CAN_L con GND. Corto circuito de la seal CAN_H con GND. Corto circuito de la seal CAN_L con Vcc. Corto circuito de la seal CAN_H con la seal CAN_L. Las distintas condiciones de error pueden detectarse al comparar

ambas lneas del bus CAN, y detectando el nivel dominante a travs de un tiempo fuera al deshabilitar la lnea defectuosa y conmutar a operacin asimtrica; la comunicacin puede continuar sobre la lnea sobrante, sin embargo, se pierde la inmunidad a la interferencia elctrica. Una solucin de interfaz de bus que cumpla con el estndar 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 deteccin de errores en el bus y la conmutacin automtica al modo de 51

transmisin asimtrico. Cuando la condicin de error deja de existir, automticamente se regresa al modo de transmisin simtrico. Adems el transceptor contiene un filtro de interferencia integrado en el mdulo de recepcin y un modo de ahorro de corriente, el cual habilita la conexin de componentes adicionales que pueden agregarse cuando el bus est activo.

3.3.4.3.- ESTNDAR SAE J2411

El estndar de un slo hilo SAE J2411 se aplica en redes CAN con requisitos de velocidad de transferencia y longitud de bus menores a los establecidos por el estndar ISO 11898-3. Los parmetros bsicos de este estndar son los siguientes: Bus de comunicacin de un slo hilo. Velocidad de transferencia nominal de 331/3Kbps en modo normal. Alta velocidad de transferencia de datos para propsitos de diagnstico de 831/3Kbps. Hasta 32 nodos por red. Modo de temporizador selectivo. La principal aplicacin del estndar SAE J2411 est enfocada a la realizacin de redes de ECUs que aumentan la comodidad en un automvil. El medio fsico se define como un cable de un slo hilo no blindado. Debido a la baja velocidad de transferencia, la topologa del bus no est limitada a una estructura lineal con longitudes cortas de la lnea de conexin del nodo con el bus. La Figura 3.20 muestra los niveles nominales de la seal CAN en el bus, en modo normal.

52

Figura 3.20.- Niveles nominales de la seal CAN en el bus de acuerdo al estndar SAE J2411

El estndar SAE J2411 puede realizarse utilizando un transceptor modelo TLE 6255 de la firma Infineon Semiconductors.

3.3.4.4.- ESTNDAR ISO 11992

El estndar 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 vehculos remolcadores o gras. Los parmetros bsicos de dicho estndar son: Conexiones punto a punto para vehculos con un remolque. Conexin lineal para vehculos con dos remolques. Velocidad de transferencia nominal de 125Kbps. Longitud de lnea mxima de 40m. Transmisin simtrica sobre un par de hilos con lnea de tierra y fuente de alimentacin. Manejo de errores de bus. Voltaje de alimentacin Vcc = 12V o 24V. El medio fsico est definido como un cable par trenzado y no se especifican resistores de terminacin en el bus debido a la corta longitud del 53

mismo y su baja velocidad de transferencia. El estndar ISO 11992 especifica la capacitancia mxima por unidad de longitud, la impedancia de la lnea, las capacitancias de contacto mximas e impedancias de conexin para los conectores, las condiciones extremas del ambiente para el cable, tipo de conectores y los ciclos de conexin para intercambio de los remolques. La Figura 3.21 muestra los niveles nominales de las seales CAN del bus de acuerdo al estndar ISO 11992. Los niveles nominales en el bus dependen de suministro de voltaje Vcc de los vehculos. Los niveles nominales de las seales para 12V y 24V se muestran en la Tabla 3.9.
Tabla 3.9.- Niveles de las seales CAN en el bus recomendados por el estndar ISO 11992 Nivel Dominante Recesivo Seal CAN_H CAN_L CAN_H CAN_L Voltaje del vehculo [V] 12V 24V 6,0 a 10,6 10,6 a 21,3 3,0 a 5,3 5,3 a 10,6 3,0 a 5,3 5,3 a 10,6 6,0 a 10,6 10,6 a 21,3

Figura 3.21.- Niveles nominales de las seales CAN en el bus de acuerdo con el estndar ISO 11992

El estndar ISO 11992 tambin especifica el manejo de errores del bus al activar el cambio a transmisin de seal asimtrica cuando se detecta un error de bus fsico. La comunicacin se puede mantener por operacin

54

asimtrica en caso de ruptura, corto circuito con Vcc, con tierra o entre las lneas. Durante la emisin de lnea sencilla se verifica el modo de transmisin de seal, para asegurar que en funcionamiento normal, o despus de corregir un error de bus, el modo de transmisin sea simtrico.

3.3.4.5.- RECOMENDACIN CIA DS-102

Respecto a la capa fsica, la recomendacin CiA DS-102 brinda soporte a la realizacin de redes CANopen para la comunicacin entre diversos tipos de mdulos electrnicos en aplicaciones industriales. Dicha recomendacin est basada en los estndares ISO 11898-1 y 11898-2, y define lo siguiente: Velocidades de transferencia estandarizadas desde 10Kbps a 1Mbps, con recomendaciones para la configuracin de los parmetros de tiempos de bit (Tabla 3.10 y Tabla 3.11). Recomendaciones para la lnea de bus. Caractersticas mecnicas y elctricas de los conectores, as como la asignacin de sus terminales (Tabla 3.7 y Figura 3.16).
Tabla 3.10.- Velocidades de transferencia y parmetros de tiempos de bit recomendados en DS-102 Velocidad de Longitud de Tiempo de Nmero de Transferencia Lnea Mxima Bit Nominal tq [Kbps] [m] [s] 1000 25 1 8 800 50 1,25 10 500 100 2 16 250 250 4 16 125 500 8 16 50 1000 20 16 20 2500 50 16 10 5000 100 16 Duracin de tq [ns] 125 125 125 250 500 1250 3125 6250 Punto de Muestreo [tq] 6 8 14 14 14 14 14 14

55

Tabla 3.11.- Parmetros de tiempos de bit recomendados por DS-102 Parmetro Frecuencia del oscilador Mtodo de muestreo Modo de sincronizacin Duracin de SJW* Duracin de Phase_Seg2 Recomendacin DS-102 16Mhz +/- 0,1% Muestreo sencillo Slo flancos recesivos a dominantes 1 tq 2 tq
*Parmetro equivalente a RJW

De acuerdo a la recomendacin DS-102, se implementa un par trenzado blindado o no blindado terminado en ambos extremos con una impedancia equivalente a la de la lnea y tierra comn, asimismo especifica el uso de repetidores para incrementar el nmero de nodos en el bus. Es posible el aislamiento galvnico de transceptores, sin convertidores DC/DC propios, mediante una lnea de fuente de alimentacin comn. Existen dos conceptos bsicos que indican cmo implementar la lnea de bus, lnea de bus interconectada y lnea de bus dividida, los cuales se describen a continuacin. 3.3.4.5.1.- LNEA DE BUS INTERCONECTADA La lnea de bus consiste de un nmero de secciones interconectadas mediante dos opciones (Tabla 3.12): Opcin A: Se utiliza un conector tipo T 4 para interconectar las secciones de lnea de bus y el bus con el nodo. Opcin B: Los mdulos electrnicos estn equipados con dos conectores para el bus, interconectando las secciones de lnea de bus.

Un conector tipo T es un dispositivo pasivo que enlaza tres diferentes conectores

56

Tabla 3.12.- Lnea de bus interconectada de acuerdo a la recomendacin DS-102 Opcin Nodo Conector tipo T Seccin de lnea de bus A 1 conector macho 1 conector macho y 2 conectores hembras 1 conector macho y 1 conector hembra B 1 conector macho y 1 conector hembra No requerido 1 conector macho y 1 conector hembra

3.3.4.5.2.- LNEA DE BUS NO DIVIDIDA La lnea de bus consiste de un slo cable sin dispositivos interconectados: Nodo: Un conector macho. Lnea de bus: Un conector hembra por nodo, adems un conector hembra y un conector macho para terminacin.

3.3.4.6.- RECOMENDACIONES DE CAPA FSICA POR LOS ESTNDARES HLP

La meta ms importante que se intenta al estandarizar los protocolos de capas altas (HLP, High Layer Protocol) y los perfiles de aplicacin, tales como CANopen, DeviceNet y SDS, es la interoperabilidad e intercambiabilidad de dispositivos, lo cual asegura la compatibilidad total de las propiedades fsicas de los dispositivos y de la red. Por lo tanto, adems de las caractersticas bsicas de la capa fsica definida en el estndar ISO 11898, se define: topologa de red, tipo de lnea, tecnologa de conexin, fuente de alimentacin, velocidad de transferencia de datos y transceptor. 3.3.4.6.1.- CANOPEN CANopen permite la implementacin de redes, hasta con 127 nodos, cumpliendo con el estndar ISO 11898-2 y la recomendacin DS-102. El aislamiento galvnico de nodos es opcional y slo se recomienda para buses con longitudes mayores a 200m.

57

Todos los dispositivos CANopen deben dar soporte a la velocidad de transferencia y a las longitudes de lnea recomendadas en DS-102 (Tabla 3.10). CANopen permite utilizar una fuente de alimentacin comn y recomienda el uso de los siguientes conectores 5: Conector DB9 (Tabla 3.2 y Figura 3.11). Conector tipo mini (Tabla 3.3 y Figura 3.12). Conector tipo micro (Tabla 3.4 y Figura 3.13). Conector tipo nano (Tabla 3.5 y Figura 3.14). Conector tipo abierto (Tabla 3.6 y Figura 3.15).

3.3.4.6.2.- DEVICENET De la misma forma que CANopen, la especificacin de capa fsica que implementa DeviceNet es una extensin del estndar ISO 118982. DeviceNet estn terminadas en ambos extremos con una impedancia R t =121 +/- 1%. permite redes de hasta 64 nodos con topologa de bus y sus lneas de bus

DeviceNet define dos pares de cables, uno para la transmisin de la

seal y el otro para la fuente de alimentacin. Se permiten tres tipos de cable variantes en dimetro (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 conexin del nodo al bus y en redes de longitudes menores a 100m (Tabla 3.13). Es obligatorio el empleo del cdigo de colores para hilos individuales.

CANopen tambin define una serie de conectores adicionales los cuales son, en su mayora, de propsito general y de usos especiales; estos conectores se encuentran en el documento: CANopen CiA Draft Recommendation 303
5

58

Tabla 3.13.- Extensin de red y longitud de lnea de extensin para DeviceNet Velocidad de transferencia [Kbps] 500 250 125 Longitud de la lnea principal [m] Cable grueso 100 250 500 Cable delgado 100 100 100 Longitud mxima de la lnea de extensin [m] Individual 6 6 6

Cable plano Acumulada 100 200 420 39 78 156

De acuerdo a la especificacin de DeviceNet, el protocolo brinda soporte a tres diferentes velocidades de transferencia de datos: 125, 250 y 500Kbps, adems permite las conexiones del bus y los dispositivos electrnicos pueden alimentarse de la fuente de voltaje comn de 24V, se recomienda el uso de cuatro tipos de conectores 6: Conector tipo mini (Tabla 3.3 y Figura 3.12). Conector tipo micro (Tabla 3.4 y Figura 3.13). Conector tipo nano (Tabla 3.5 y Figura 3.14). Conector tipo abierto (Tabla 3.6 y Figura 3.15). La especificacin de DeviceNet presenta ciertas recomendaciones en cuanto a la proteccin de las conexiones. Opcionalmente la conexin al bus puede aislarse galvnicamente y la corriente necesaria para alimentar a los transceptores puede tomarse de la fuente de alimentacin comn. 3.3.4.6.3.- SDS SDS describe una prctica recomendada para autobauding, en donde la tasa de bit est establecido por el maestro, con la direccin ms baja posible, y todos los dems mdulos comprobarn 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 energa

59

Tabla 3.14.- Velocidades de transferencia y longitudes de lnea recomendadas para SDS Velocidad de transferencia [Kbps] 1000 500 250 125 Longitud de la lnea principal [m] 22,8 91,4 182,8 457,2 Longitud mxima de la lnea de extensin [m] 0,3 0,9 1,8 3,6

Dentro de las caractersticas de relacionadas con la capa fsica SDS se encuentra que slo soporta tramas CAN estndar y define el uso de tres tipos de conectores 7: Conector DB9 (Tabla 3.2 y Figura 3.11). Conector tipo mini (Tabla 3.3 y Figura 3.12). Conector tipo abierto (Tabla 3.6 y Figura 3.15).

3.4.- CAPA DE ENLACE DE DATOS (DLL)

En este apartado se describen los fundamentos y principios bsicos 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 continuacin.

Figura 3.22.- Arquitectura de la capa de enlace de datos del protocolo CAN

SDS, a diferencia de DeviceNet, tambin recomienda el uso tipo micro de 4 terminales (conector M12 de 4-pines) pero para extensiones de la lnea del bus

60

3.4.1.- CONTROL DE ENLACE LGICO (LLC)

La subcapa de control de enlace lgico (LLC, Logic Link Control) describe la parte alta de la capa DLL y define las tareas independientes del mtodo de acceso al medio, asimismo proporciona dos tipos de servicios de transmisin sin conexin al usuario LLC: Servicio de transmisin 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 conexin de enlace de datos. La transmisin de datos puede ser punto a punto, multidifusin o difusin. Servicio de peticin de datos remota sin reconocimiento: Proporciona al usuario LLC los medios para solicitar que un nodo remoto transmita sus LDSUs sin establecer una conexin 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 estndar (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 direccin destino pero define el contenido del mensaje, y mediante esta funcin todo receptor activo en la red determina si el mensaje es relevante o no para sus propsitos. Notificar sobrecarga: Si las condiciones internas de un receptor requieren un retraso en la transmisin 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 mximo. Gestin de recuperacin: La subcapa LLC proporciona la capacidad de

61

retransmisin automtica de tramas cuando una trama pierde el arbitraje o presenta errores durante su transmisin, dicho servicio se confirma al usuario hasta que la transmisin 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 transmisin a frecuencias altas y retrasos mnimos. En redes multimaestro, la tcnica 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 continuacin: Cuando un nodo necesita enviar informacin a travs de una red CAN, la capa de aplicacin realiza una peticin, de forma asncrona, para transmitir una trama. Puede ocurrir que varios nodos inicien el mismo procedimiento simultneamente generando una colisin en el bus, una eventual colisin se resuelve asignando prioridades de cada mensaje mediante un identificador; dicha asignacin, que no puede modificarse dinmicamente, se realiza durante el diseo del sistema en forma de nmeros binarios y se hace tomando en consideracin que el identificador con el menor nmero binario es el que tiene mayor prioridad. El mtodo de acceso al medio utilizado es el CSMA/NBA, de acuerdo

62

con este mtodo, los nodos en la red que necesiten transmitir informacin deben esperar a que el bus est libre (deteccin de portadora); cuando se cumple esta condicin, dichos nodos transmiten un bit de inicio (acceso mltiple) y a continuacin van comparando el valor transmitido con el valor recibido bit a bit; mientras los valores sean idnticos, los nodos continan con la transmisin; si algn 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 transmisin de sus tramas al mismo tiempo, el ganador del arbitraje, el mensaje con la mayor prioridad, contina con la transmisin de su trama sin necesidad de retransmitirla desde el principio. Una vez finalizada la transmisin del mensaje ms prioritario los dems nodos volvern a intentar enviar el mensaje lo antes posible. Para comenzar a explicar lo que sucede elctricamente en el proceso de arbitraje, se ha de tener en cuenta que la especificacin CAN de Bosch no establece cmo se ha de traducir cada nivel de bit (dominante o recesivo) a variable fsica. Cuando se utiliza par trenzado segn la norma ISO 11898 el nivel dominante es una tensin diferencial positiva en el bus, mientras que el nivel recesivo es ausencia de tensin 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 lgico. El bit recesivo representa un 1 lgico. Se tiene que el arbitraje del bus CAN utiliza la funcin Wired-AND, la cual tiene como consecuencia directa que: slo en el caso que todos los nodos

63

de la red transmitan bits recesivos (1 lgico) el bus deber pasar al estado recesivo; mientras que si algn nodo transmite un bit dominante (0 lgico) el bus pasa automticamente a estado dominante. Es decir, que un bit recesivo representa un estado de bus que puede ser sobrescrito por un bit dominante. Considerando que ms adelante se ver el significado de cada campo detalladamente, podemos empezar a describir paso a paso el proceso de arbitraje segn la Tabla 3.15 y Figura 3.23. En el instante 1, se puede ver cmo 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 identificacin del mensaje coincidan en los tres nodos, todos siguen emitiendo; siguiendo la lnea temporal, en el instante 2, el nodo 2 advierte que el nivel del bus es dominante, mientras que l haba emitido un bit recesivo, as pues, sabe que existe otro nodo que est transmitiendo un mensaje ms prioritario que l e inmediatamente deja de transmitir el mensaje para conmutar a modo de recepcin; 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.- Representacin bit a bit del arbitraje en el bus CAN S O F 0 0 0 0 Identificador 10 1 1 1 1 9 1 1 1 1 8 0 0 0 0 7 0 0 0 0 6 1 1 1 1 5 0 1 0 0 4 1 1 1 3 1 1 1 2 1 0 0 1 0 0 0 1 1 R T R 0 0

Nodo 1 Nodo 2 Nodo 3 Nivel del bus

64

Figura 3.23.- Arbitraje del bus CAN

Otro aspecto a considerar, es que podra darse el caso de que se inicia simultneamente la transmisin, 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 peticin de transmisin 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 mxima del bus en funcin de la velocidad y del nmero de nodos presentes en la red, pues el tiempo de transmisin de un bit debe ser lo suficientemente largo como para permitir su decodificacin por todas las estaciones de la red, ya que a mayor velocidad de la red, menor longitud de bus (Tabla 3.1 y Figura 3.8); por otra parte, obliga a 65

que todos los mensajes posean un identificador nico, que es el que establece su prioridad.

3.4.2.2.- TRANSMISIN DE MENSAJES

CAN establece dos formatos de tramas que difieren en la longitud del campo del identificador, las tramas estndares con un identificador de 11 bits definidas en la especificacin CAN 2.0A, y las tramas extendidas con un identificador de 29 bits definidas en la especificacin CAN 2.0B. Tanto las tramas de datos como las remotas se separan de tramas precedentes mediante espacios entre tramas. Para la transmisin 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 transmisin de la trama de datos con el mismo identificador. Trama de error: Se transmite a travs de cualquier unidad al detectar un error del bus. Trama de sobrecarga: Se utiliza para que un receptor solicite un retraso en la transmisin de la trama siguiente. 3.4.2.2.1.- TRAMA DE DATOS La trama de datos transporta informacin desde los transmisores hacia los receptores, siendo el tipo de trama ms 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 aceptacin y fin de trama (Figura 3.24). La longitud del campo de datos puede ser cero.

66

Figura 3.24.- Formato de una trama de datos

Inicio de trama: Este campo indica el inicio de una trama de datos o una trama remota y slo 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 estndar y extendida.

Campo de arbitraje: Este campo determina la prioridad de un mensaje cuando dos o ms nodos se encuentran en contienda para el acceso al bus de comunicaciones y difiere segn el formato de trama (Figura 3.25).

Figura 3.25.- Campo de arbitraje, trama estndar y extendida

En el formato estndar est constituido por un identificador de 11 bits y el bit de peticin de transmisin 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 ms significativos no

67

pueden ser todos recesivos (ID-10 ID-4). En el formato extendido est formado por un identificador de 29 bits, el bit de peticin remota substituta (SRR, Substitute Remote Request), el bit de extensin 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 seccin consta de 11 bits (ID-28 ID-18) y se denomina identificador base, el cual es equivalente al identificador del formato estndar; y la segunda seccin 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 posicin, 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 estndar, debe transmitirse como dominante para el formato estndar 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 identificacin base se resuelven de manera que el formato de trama estndar 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 cdigo de longitud de datos (DLC, Data Length Code). El formato del campo de control es diferente para el formato estndar y extendido (Figura 3.26).

68

Figura 3.26.- Campo de control

En el formato estndar 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 nmero de octetos (de cero a ocho) que contendr el campo de datos, toma las primeras nueve combinaciones de las diecisis 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 envan primero los bits ms significativos. Si denotamos los bits que forman el cdigo de longitud de datos como DLC-3 DLC-0, se tiene que los valores admisibles para el campo de datos estn contenidos en la Tabla 3.16. Los DLCs en el rango de cero a siete indican la misma 69

longitud en bytes del campo de datos, mientras que todas las otras combinaciones posibles indican que el campo de datos es de ocho bytes.
Tabla 3.16.- Codificacin de los bits DLC segn la longitud de los datos Cdigo de longitud de datos DLC-3 DLC-2 DLC-1 DLC-0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 1 1 0 1 0 0 0 1 0 1 0 1 1 0 0 1 1 1 1 0o1 0o1 0o1 Nmero de bytes de datos 0 1 2 3 4 5 6 7 8

Campo CRC: Este campo est constituido por una secuencia CRC de 15 bits seguido por un delimitador CRC de 1 bit, que se transmite en estado recesivo (Figura 3.27). La secuencia de verificacin de 15 bits usada en el protocolo CAN se basa en el cdigo BHC 8 cuyo generador polinomial, dado por X15+X14+X10+X8+X7+X4+X3+1, se aplica una trama que no tenga implementado el proceso de insercin de bits (destuffed bits) e incluye los siguientes coeficientes para su clculo: 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 aceptacin: Este campo est constituido por una ranura de

Un cdigo cclico bien especializado para las longitudes de trama menores a 127 bits

70

aceptacin y delimitador de aceptacin (Figura 3.28). Los bits de aceptacin (ACK, Acknowledge) en los nodos transmisores se emiten ambos en estado recesivo; mientras que en los nodos receptores se sobrescribe la ranura de aceptacin con un bit en estado dominante para confirmar que el mensaje se ha recibido sin errores, si no existe dicha confirmacin se asume que el mensaje lleg con errores.

Figura 3.28.- Campo de aceptacin

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) estn activos se realiza una violacin al procedimiento de insercin 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 transmisin 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 aceptacin y fin de trama (Figura 3.29). Como se puede apreciar los campos de una trama remota son los mismos que los de una trama de datos, con las siguientes excepciones: el bit RTR es recesivo; y no contiene el campo de datos, independientemente si el valor de los bits DLC est dentro del rango admisible (cero a ocho bytes). En las tramas remotas el valor de los bits DLC cumple con la finalidad de contener la longitud del campo de datos que se

71

espera recibir y, por ende, debe coincidir con el valor que el transmisor enviar posteriormente.

Figura 3.29.- Formato de una trama remota

3.4.2.2.3.- TRAMA DE ERROR La trama de error sealiza la deteccin de cualquier error durante la transmisin o recepcin de una trama de datos o remota, la cual viola el procedimiento de insercin de bit y ocasiona que el transmisor reenve la trama. Asimismo la deteccin de un error, durante la transmisin o recepcin de una trama de sobrecarga o error, genera la transmisin de una nueva trama de error. La trama de error est formada por dos campos (Figura 3.30):

Figura 3.30.- Formato de una trama de error

Bandera de error: Existen dos formas de representar una bandera de error: Bandera de error activo: Consiste en seis bits dominantes

72

consecutivos. Bandera de error pasivo: Est formada por seis bits recesivos consecutivos, a menos que sean sobrescritos por bits dominantes de otros nodos. Delimitador de error: Una trama de error termina con una secuencia de ocho bits recesivos. Posterior a la transmisin 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 transmisin 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 condicin 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 transmisin de la trama siguiente, ya sea de datos o remota, o para sealizar condiciones de error relacionadas con el campo de intermisin. El protocolo CAN permite la generacin de dos tramas de sobrecarga como mximo para retrasar la transmisin de la siguiente trama. Las tramas de sobrecarga se transmiten despus de detectar las siguientes condiciones de error: Deteccin de un bit dominante durante los primeros dos bits del campo de intermisin. La deteccin de un bit dominante en el tercer bit del campo de intermisin se interpreta como un SOF. Cuando un receptor detecta un bit dominante en el ltimo bit del campo EOF; o cuando un nodo, receptor o transmisor, detecta un bit dominante en el ltimo bit del delimitador de una trama de error o de sobrecarga.

73

Una trama de sobrecarga se considera una forma especial de trama de error y consta de los siguientes campos (Figura 3.31):

Figura 3.31.- Formato de una trama de sobrecarga

Bandera de sobrecarga: Se constituye por seis bits dominantes. La forma completa corresponde a la bandera de error activa. Delimitador de sobrecarga: Est formado por ocho bits recesivos.

3.4.2.2.5.- ESPACIO ENTRE TRAMAS Las tramas de datos y remotas estn 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: Intermisin: Consiste en tres bits recesivos. Durante su transmisin la nica accin que puede realizarse es sealar una condicin de sobrecarga, y no se permite que ningn nodo inicie la transmisin de una trama de datos o remota. Bus libre: Este periodo es de longitud arbitraria y tiene un nivel recesivo hasta que algn nodo inicie la transmisin de una nueva trama. Suspender transmisin: Adicionalmente, el espacio entre tramas contiene un tiempo de inhibicin de transmisin de ocho bits para nodos que se encuentren en estado de error pasivo. 74

3.4.2.3.- CODIFICACIN DE TRAMAS

En una trama CAN, de datos o remota, la codificacin NRZ junto con el procedimiento de insercin de bit se aplican al: inicio de trama, campo de arbitraje, campo de control, campo de datos 9, secuencia CRC. Los segmentos restantes: delimitador CRC, campo de aceptacin y fin de trama, tienen un formato fijo y son transmitidos sin emplear el procedimiento de insercin 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.- VALIDACIN DE TRAMAS

El instante de tiempo en el que se valida una trama difiere segn: Transmisor: La trama es vlida si no existen errores hasta el final del campo EOF. Si existe un error, en la trama se activa el proceso de recuperacin. Receptor: La trama es vlida si no existen errores hasta el siguiente bit despus del campo EOF.

3.4.2.5.- DETECCIN 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 alteracin local permanente, lo que provoca el envo 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 dems nodos no sean perturbados por los nodos defectuosos.
9

El campo de datos no se incluye en una trama remota

75

3.4.2.5.1.- MECANISMOS DE DETECCIN DE ERRORES Para cumplir con las demandas relativas a la seguridad en la transmisin de datos, el protocolo CAN define los siguientes mecanismos para deteccin 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 deteccin de todos los errores efectivos. Verificacin del procedimiento de insercin de bit: Hace referencia al hecho de detectar un error de insercin de bit cuando ocurren seis niveles consecutivos de bits con el mismo valor en un campo de trama codificado por el procedimiento de insercin de bit. Verificacin de redundancia cclica de 15 bits: Se presenta un error de CRC cuando la secuencia CRC recibida no corresponde con la secuencia CRC calculada. Verificacin de trama: Detecta un error cuando un campo de bit de formato fijo contiene uno o ms bits no vlidos. Verificacin de aceptacin: Un transmisor detecta un error de aceptacin cuando la ranura ACK no cambia a estado dominante. 3.4.2.5.2.- MANEJO DE ERRORES Cuando un nodo detecta algn tipo de error, de bit, de insercin de bit, de forma o de aceptacin, inicia la transmisin de una bandera de error en el siguiente bit. Cuando se detecta un error de CRC, se inicia la transmisin de una trama de error despus del delimitador ACK, a excepcin de que previamente se haya transmitido otra trama de error. El manejo de errores se lleva a cabo de acuerdo con el diagrama de flujo de la Figura 3.32.

76

Figura 3.32.- Diagrama de flujo para el manejo de errores

3.4.2.5.3.- CAPACIDAD DE DETECCIN DE ERRORES Los protocolos de comunicaciones de bus seriales emplean diferentes mecanismos de deteccin de error, los cuales proporcionan al receptor la capacidad de detectar si la trama recibida es errnea o no. Por otro lado, la capacidad de detectar errores de transmisin depende de los mecanismos de error y del protocolo utilizado. Para valorar la integridad de los datos en un sistema de transmisin se deben considerar las interferencias electromagnticas y la capacidad para detectar errores de transmisin. En un sistema de transmisin de datos existe una medida estadstica que representa la integridad de datos transferidos conocida como probabilidad de error residual, la cual especifica la probabilidad de que existan tramas errneas sin detectar y est dada por la Ecuacin 3.7.

77

Probabilidad de error residual

< (4,7 1011 ) (velocidad de error de trama)

[3. 7]

La cual define el nmero de errores de transmisin sin detectar durante el tiempo de operacin 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 mayora de errores de transmisin son debido a interferencias electromagnticas. La susceptibilidad de error de un sistema de transmisin de datos se puede caracterizar mediante parmetros estadsticos tales como la velocidad de error de trama y la probabilidad de error de bit. La velocidad de error est dada por la relacin entre el nmero de tramas errneas y el nmero total de tramas transmitidas durante un periodo de tiempo, con lo cual se describe la probabilidad de que exista una trama errnea, por otro lado, la probabilidad de error de bit especifica la probabilidad de que exista un bit errneo en una trama transmitida. Los errores de transmisin 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 sealizar los errores detectados mediante la transmisin de una bandera de error, sin embargo existe la posibilidad de no detectar errores locales cuando se cumplen las siguientes condiciones en la distribucin del error de bit: El nodo que transmite funciona adecuadamente, y puede detectar un error al monitorear el bit y sealizarlo a todo el sistema. Cuando todos los nodos receptores que reciben una trama errnea detectan un patrn de error no definido (indetectable). Debido a que 78

estos patrones son muy raros, todos los nodos que recibieron la trama errnea deben mostrar un patrn de error idntico. Esta condicin es cada vez ms improbable en un sistema distribuido con un gran nmero de nodos. La DLL del protocolo de comunicaciones CAN garantiza un alto grado de deteccin 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 electromagntica, la cual aparece en todos los nodos, y adems tiene la capacidad de detectar errores locales. Los errores que slo ocurren localmente, en receptores individuales, se detectan mediante la verificacin de la secuencia CRC de 15 bits, realizada por el mismo receptor.

3.5.- DESCRIPCIN DE LA SUPERVISIN

La sustitucin 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 algn tipo de error (principio de sealizacin de errores) y puede ocasionar que un nodo defectuoso pueda acaparar el medio fsico, para eliminar este riesgo el protocolo CAN define un mecanismo autnomo 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 transmisin de datos, incluso en el caso de que existan nodos

79

defectuosos, para ello se definen estrategias que incrementan la seguridad en los siguientes aspectos: Distinguir entre errores temporales y fallas permanentes. Localizar y desconectar nodos defectuosos. Por ello, cada nodo tiene un contador de errores de transmisin (TEC, Transmit Error Counter) y un contador de errores de recepcin (REC, Receive Error Counter) para registrar el nmero 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 relacin 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 relacin 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 comunicacin de bus y cuando detecta un error enva una bandera de error activo; destruye la trama que transmita, viola el procedimiento de insercin de bit y previene con ello a los dems nodos de la presencia de una trama errnea. Error pasivo: Un nodo no puede enviar una bandera de error activo pero an toma parte en la comunicacin del bus; cuando detecta un error, slo puede enviar una bandera de error pasivo, la cual no interfiere en la comunicacin del bus. Desconectado: En este estado, un nodo no tiene ninguna influencia en el 80

bus y por ello no puede transmitir tramas, aceptacin ACK, tramas de error o de sobrecarga.

Figura 3.33.- Diagrama de estados de error de un nodo CAN

3.6.- CAPA DE APLICACIN

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 aplicacin en el nodo. Actualmente, con la implementacin de sistemas distribuidos basados en CAN han surgido nuevos requerimientos que no han sido considerados en el estndar ISO 11898-2, siendo los ms importantes: Disponibilidad de servicios de transmisin para bloques de datos mayores a 8 octetos. Soporte al modelo cliente/servidor. Funciones dedicadas a la gestin de red. Mtodos para asignar identificadores de mensaje y configuracin de parmetros especficos del nodo, de forma transparente al usuario. Interoperabilidad e intercambio de dispositivos de diferentes fabricantes. Estandarizar la funcionalidad y definir nuevos perfiles para dispositivos.

81

La necesidad de estandarizar las capas de aplicacin ha surgido sobre todo en el sector de los buses de campo industriales, donde la comunicacin entre dispositivos de diferentes fabricantes es una caracterstica fundamental. Respecto al protocolo CAN, existen diferentes estndares que definen su capa de aplicacin; algunos son muy especficos y estn relacionados con sus campos de aplicacin. Entre las capas de aplicacin ms utilizadas cabe mencionar las siguientes: CAL: Define un amplio conjunto de funciones para la comunicacin y gestin 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 utilizacin 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 interconexin de sensores y actuadores inteligentes. OSEK/VDX (Offene Systeme und deren schnittstellen fr die Elektronik im Kraftfahrzeug 10/Vehicle Distributed eXecutive): Desarrollado por la firma Siemens como resultado de la cooperacin entre fabricantes de automviles alemanes para desarrollar una arquitectura abierta para unidades de control distribuido. CANKingdom: Desarrollado por la firma Kvaser y compatible con DeviceNet, protocolo reconocido a nivel mundial en el control de
Su traduccin del alemn al espaol vendra a ser: Sistemas abiertos y sus interfaces para la electrnica en automviles
10

82

maquinaria.

3.6.1.- CAL
La organizacin 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 implementacin independiente dedicada exclusivamente a la capa de aplicacin en redes CAN. La funcionalidad de CAL consiste en cuatro elementos de servicio: Especificacin de mensajes basada en CAN (CMS, CAN based Message Specification): Proporciona los medios para la descripcin e implementacin de una comunicacin orientada a objetos. Contiene distintos tipos de datos estructurados y diferentes objetos de comunicacin con caractersticas de transmisin. Mediante reglas de codificacin, especifica un formato de datos comn para todos los mensajes de la red. Gestin de la red (NMT, Network Management): Asegura un inicio ordenado de toda la red y contiene las medidas de precaucin necesarias para la supervisin e intercambio/insercin de nodos en tiempo de ejecucin. Distribuidor de identificadores (DBT, Identifier Distributor): Se encarga de la asignacin dinmica de identificadores y trabaja en conjunto con el servicio NMT. Gestin de capa (LMT, Layer Management): Se encarga de la configuracin y parametrizacin de CAL a travs de la red.

83

Los elementos anteriores se pueden configurar para disear 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 estndar de comunicaciones y dispositivos basados en CAL desarrollado por un consorcio liderado por Bosch y apoyado por la organizacin CiA. Inicialmente se desarroll como una red empotrada de configuracin flexible y con apoyo de CiA logr su estandarizacin para utilizarse en sistemas distribuidos de automatizacin industrial. En Europa se considera el estndar de facto para la implementacin de sistemas industriales basados en CAN, y sus campos de aplicacin son: equipo mdico, vehculos para terreno especiales, electrnica martima, transporte pblico, domtica, etc. CANopen est integrado por un perfil de comunicaciones que especifica y define los mecanismos de comunicacin. Los perfiles de dispositivos describen a los dispositivos utilizados en la tecnologa de automatizacin 84

industrial tales como mdulos de E/S analgicos y digitales, controladores, unidades de interfaz hombre, codificadores, etc. El perfil de dispositivo define la funcionalidad de un dispositivo en particular. La principal caracterstica de CANopen es la descripcin funcional de parmetros, y datos de un dispositivo, la cual se encuentra en un diccionario de objetos (OD, Object Dictionary). La funcionalidad y caractersticas de un dispositivo CANopen se definen en una hoja de datos electrnica (EDS, Electronic Data Sheet) estandarizada en formato ASCII. De forma similar a otros buses de campo, CANopen define dos mecanismos bsicos de transmisin: El intercambio crtico en tiempo real de datos de proceso mediante objetos de proceso (PDO, Process Data Object). El acceso en tiempo crtico a las entradas del diccionario de objetos mediante objetos de servicio (SDO, Service Data Object). La Tabla 3.17 muestra las ventajas y caractersticas, mientras que la Figura 3.35 muestra la arquitectura general de un sistema CANopen.
Tabla 3.17.- Ventajas y caractersticas de CANopen Ventajas Permite la interoperabilidad entre diferentes dispositivos Capacidad de respuesta en tiempo real Modular, cubre dispositivos desde simples a complejos Amigable con el usuario, disponibilidad de herramientas Protocolo abierto e independiente del vendedor, estandarizado como EN 50325-4 Caractersticas Configuracin automtica de la red Fcil acceso a todos los parmetros del dispositivo Sincronizacin de dispositivos Transmisin de datos controlada por eventos y cclica Lectura sincrnica de configuracin de entradas, salidas o parmetros

85

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

3.6.3.- DEVICENET
DeviceNet es un protocolo desarrollado por la firma Rockwell Automation 11 y publicado como un estndar de bus de campo abierto, actualmente desempea un papel importante en la industria de los EE.UU. y Asia, y en Europa se extiende cada vez ms. DeviceNet es un protocolo basado en CAN: simple, de bajo costo y eficiente que fue diseado para el nivel ms 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 informacin (CIP, Control and Information Protocol). El CIP es un protocolo de comunicaciones comn y sus
La firma Rockwell Automation escribi la especificacin original DeviceNet. En Europa DeviceNet forma parte de la norma EN 50325-2 y se incluye en el estndar internacional IEC 62026-3
11

86

interfaces hardware/software permiten la conexin de dispositivos industriales a Internet mediante dos tipos de mensajes: Control: Se utiliza para control de las E/S en tiempo real o mensajes implcitos. Informacin: Est dedicado al intercambio de mensajes o mensajes explcitos. Ambos tipos de mensajes estn destinados el rea de control industrial y proporcionan las siguientes caractersticas: Servicios de control comn. Servicios de comunicacin comn. Capacidades de encaminamiento comn. Base de conocimiento comn. La especificacin de DeviceNet define parte de la capa fsica y el medio de transmisin. 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 conexin de sensores y actuadores inteligentes. SDS implementa 87

un protocolo de capa de aplicacin diseado para cumplir los requerimientos establecidos en la automatizacin industrial, como son: velocidad de transferencia de datos, confiabilidad, flexibilidad, etc. Algunas de sus principales caractersticas son la utilizacin de mtodos de deteccin y correccin de errores, y confiabilidad en el reconocimiento de mensajes. El protocolo de capa de aplicacin SDS proporciona un conjunto de mensajes que abarca desde mensajes de cambio de estado controlados por eventos, hasta operaciones complejas transportando valores binarios, analgicos y alfanumricos. La arquitectura del protocolo de capa de aplicacin SDS se basa en el modelo OSI, utiliza los servicios que proporciona la capa de enlace de datos CAN y debe implementar una capa fsica compatible con CAN (Figura 3.37).

Figura 3.37.- Arquitectura de protocolos SDS

3.6.5.- OSEK/VDX
OSEK/VDX es un proyecto comn de la industria automotriz alemana liderado por Siemens, su objetivo es obtener una arquitectura abierta estandarizada para las unidades de control distribuidas en vehculos.

88

OSEK/VDX introduce una arquitectura abierta que comprende tres reas (Figura 3.38): Comunicacin: Proporciona servicios para el intercambio de datos entre tareas y/o rutinas de servicio de interrupcin (ISR, Interrupt Service Routine), comunicacin interna de una ECU, y externa entre diferentes ECUs; el acceso a los servicios de comunicacin OSEK se realiza mediante interfaces de programacin de la aplicacin especfica (API, Application Program Interface). Gestin de red: Define un conjunto de servicios para determinar y supervisar la configuracin del nodo. Debe adaptarse a los requerimientos especficos del sistema de bus utilizado (mtodos globales) o a los recursos de cada nodo (mtodos 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 integracin de mdulos software realizados por distintos fabricantes.

89

Figura 3.38.- Arquitectura OSEK/VDX

3.6.6.- CAN KINGDOM

CAN Kingdom fue desarrollado por la empresa sueca Kvaser especficamente para aplicaciones de control de maquinaria que requieren un desempeo en tiempo real, los dems protocolos estn enfocados a la automatizacin industrial. CAN Kingdom es un conjunto de primitivas del protocolo basado en CAN y es una herramienta que el diseador de sistemas puede utilizar para disear y optimizar HLPs. Propone una filosofa para el desarrollo de mquinas basada en comprensibilidad, seguridad, simplicidad y efectividad. El desarrollo de un sistema CAN Kingdom sigue el principio de que los mdulos deben servir a la red y como consecuencia todo nodo en la red tiene la informacin necesaria para inicializar el sistema. CAN Kingdom describe un sistema como si fuera un pas, un reino, con su respectiva capital y ciudades. El rey gobierna al reino desde la capital, y cada ciudad tiene un alcalde responsable del gobierno local. El nico medio para comunicarse dentro de la ciudad es el correo. La red CAN se describe 90

como el sistema postal real, cada ciudad tiene una oficina de correos y un director de correos el cual simboliza a un controlador CAN (Figura 3.39).

Figura 3.39.- Representacin de una red CAN con CAN Kingdom

Cada ciudad produce algo y puede importar o exportar informacin por correo. El alcalde de la ciudad organiza cualquier informacin de importacin o exportacin dentro de listas, dichas listas forman parte de la documentacin del mdulo. El diseador de sistemas elige los mdulos especficos que se utilizarn en su mquina, y para ello debe conocer completamente las listas. Asimismo el diseador crea un protocolo optimizado para su mquina, al asignar identificadores a las variables que estn en dicha lista.

91

CAPTULO 4.- REFERENCIAS PARA LA UTILIZACIN DEL KIT DE DESARROLLO CAN

El propsito de este captulo es describir los componentes de software y de hardware necesarios para la utilizacin del kit de desarrollo. Para realizar lo anteriormente expuesto, se detallan los procedimientos de programacin y creacin de aplicaciones para el sistema.

4.1.- DESCRIPCIN DEL HARDWARE

Cada kit de desarrollo incluye dos placas: una tarjeta de demostracin C51 (C51 Demo Board) y una tarjeta de extensin 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 demostracin C51 conectada a la tarjeta de extensin CAN

Todas las caractersticas proporcionadas por la tarjeta de demostracin C51 que pueden utilizarse para fines didcticos son: Pantalla LCD. 92

Barra de LEDs. Puerto RS-232. Interruptor de encendido/apagado. Botn de reinicio. Botn de interrupcin. Capacidad de hardware para programar los microcontroladores CAN en el chip de memoria flash. La tarjeta de extensin CAN para los microcontroladores Atmel

T89C51CC0x tiene las siguientes caractersticas: Zcalo PLCC44 formato. Transceptor CAN Atmel ATA6660. Dos tomas diferentes para transceptor: DIL8 y SO8. Conectores D-sub (DE-9) conformes a la CiA de la recomendacin para la alta velocidad de bus CAN. Conector ADC para la tensin de referencia VAGND y VAREF del conversor anlogo a digital. En la Tabla 4.1 muestra un listado de las caractersticas ms importantes del kit de desarrollo. para instalar un microcontrolador Atmel del mismo

93

Tabla 4.1.- Caractersticas del kit de desarrollo para los microcontroladores Atmel T89C51CC0x Caractersticas 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 Programacin del sistema UART / CAN Puertos 4 puertos (0/1/2/3) Temporizadores 3 temporizadores de 16-bit (0/1/2) Conversor anlogo 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 energa 9 hasta 12V Temperatura de trabajo -40 hasta +85C Zcalos 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 adems del soporte para el estndar de bus CAN 2.0A y 2.0B. En la Figura 4.2 y se muestra el diagrama de bloques y distribucin de pines del microcontrolador respectivamente.

94

Figura 4.2.- Diagrama de bloques del microcontrolador Atmel T89C51CC01

Figura 4.3.- Distribucin de pines del microcontrolador Atmel T89C51CC01 en formato PLCC44

95

Otra caracterstica del microcontrolador es que una gran parte de la velocidad de procesamiento y de memoria queda disponible para la aplicacin, 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 transmisin o recepcin de mensajes en el bus CAN sin correr una rutina de exploracin por software, se minimiza el impacto en aplicaciones de tiempo real. Adems este microcontrolador posee una gran flexibilidad para la programacin de aplicaciones, que puede ser a travs de la interfaz UART o CAN, permitiendo la programacin a distancia y actualizaciones en terreno. El fabricante ofrece una biblioteca de rutinas de programacin 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 perifricos del microcontrolador se incluye 3 temporizadores de 16-bits con capacidad de modulacin 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 adems de cinco modos de baja potencia para optimizar el consumo de energa de la aplicacin.

96

Figura 4.4.- Esquema de la tarjeta de demostracin C51

4.1.2.- CONECTORES DE ENERGA

En el kit de desarrollo de software existen bsicamente 2 formas de energizar la placa 12, la primera es por medio de la alimentacin de 9 a 12V en el conector J1 con un transformador AC/DC y la segunda es por medio de la alimentacin en el conector J2 con una batera de 9V.

Existen distintas combinaciones de alimentacin para el kit de desarrollo las cuales estn detalladas en el documento C51 Microcontrollers Demo Board User Guide y que hacen uso de configuraciones que incluyen la utilizacin del jumper J18, que para efectos prcticos no se van a tomar en consideracin, por lo tanto, se hablar slo de alimentacin en los conectores J1 o J2
12

97

Figura 4.5.- Tarjeta de demostracin 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 operacin del oscilador interno del microcontrolador, se debe tener en consideracin que un ciclo de mquina se obtiene dividiendo la frecuencia del cristal por 12, por lo tanto, con el cristal de 12MHz implementado en la tarjeta de extensin CAN del kit de desarrollo, el ciclo de mquina es de 1s. Otro aspecto a mencionar es que la mayora de las instrucciones se ejecutan en un ciclo de mquina 13.

4.1.4.- INTERRUPTOR DE ENCENDIDO/APAGADO

Se conoce tambin como interruptor de encendido y sirve para conmutar el estado de encendido y apagado (ON/OFF) de la fuente de alimentacin en el kit de desarrollo.

Es pertinente dejar en claro que las instrucciones de las que se hablan corresponden a instrucciones escritas en lenguaje Assembly y no a las escritas en lenguaje C el cual se utilizar posteriormente
13

98

4.1.5.- BOTN DE REINICIO

Se conoce tambin 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.- BOTN DE INTERRUPCIN

Se conoce tambin como pin de interrupcin externa 1 (P3.3/INT1) y en el kit de desarrollo se implement como un botn el cual, como su nombre lo indica, puede generar una interrupcin cada vez que se presiona de ste.

4.1.7.- PANTALLA LCD

Una pantalla LCD de 2x16 (2 lneas de 16 caracteres) de 5x8 puntos por carcter (5 horizontales y 8 verticales) modelo Hitachi HD44780U.

4.1.8.- BARRA DE LEDS

Una barra de LEDs de 8 segmentos, cuya distribucin de izquierda a derecha consiste en: 2 rojos, 2 amarillos y 4 verdes.

4.1.9.- PUERTO RS-232

El puerto de comunicacin RS-232 se implementa en el kit de desarrollo en los pines de recepcin (P3.0/RxD) y transmisin (P3.1/TxD) de seales de datos seriales asncronos (UART) del microcontrolador, ste puerto cumple un doble propsito: La utilizacin como puerto para visualizar o procesar mensajes de entrada/salida. El uso como interfaz de programacin de la memoria FLASH del

99

microcontrolador 14.

4.1.10.- PUERTO CAN

El puerto de comunicacin CAN se implementa en el kit de desarrollo en los pines de transmisin (P4.0/TxDC) y recepcin (P4.1/RxDC) de seales de datos seriales del protocolo CAN del microcontrolador, ste puerto cumple con la especificacin CAN definida por BOSH GmbH en el estndar 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 extensin CAN permite conectar o desconectar la resistencia de terminacin de 120 del bus, ya que se recomienda tener una resistencia de terminacin conectada en ambos extremos cuando el bus CAN est funcionando a altas velocidades.

4.2.- DESCRIPCIN DEL SOFTWARE

Para poder utilizar el kit de desarrollo de precisan principalmente de 2 programas: Entorno de Desarrollo Integrado. Herramienta de Programacin del Sistema.

4.2.1.- ENTORNO DE DESARROLLO INTEGRADO

Un entorno de desarrollo integrado o IDE (Integrated Development Environment), es un programa informtico compuesto por un conjunto de herramientas de programacin consistente en un editor de cdigo, un compilador y un depurador.
La programacin del microcontrolador se hace mediante una combinacin de una aplicacin de software residente en un espacio de la memoria FLASH del microcontrolador llamado bootloader y una aplicacin de software residente en un computador llamado FLIP
14

100

El entorno de desarrollo que se utilizar en los siguientes apartados corresponde a las herramientas de desarrollo de la compaa Keil para los microcontroladores Intel 8051 llamado Keil C51 Development Tools, el cual permite la programacin 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 programacin existentes para microcontroladores: Algoritmos de un alto nivel de complejidad pueden ser fcilmente 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 ms fcil utilizando el lenguaje C que crearlas en Assembly, ya que el fabricante provee el cdigo escrito en C para utilizar todos los perifricos del kit de desarrollo y en particular la librera del bus CAN.

4.2.1.1.- TIPOS DE VARIABLES

El compilador C desarrollado por la compaa Keil es llamado C51 y soporta la mayora de los tipos de variables del ANSI C 15 adems de agregar unos cuantos propios. Dentro de los tipos de variables estndar del compilador C51 los nicos tipos de variables ANSI C que no estn soportados son las variables de punto flotante debido a que la arquitectura Intel 8051 no es capaz de manejar

ANSI C es un estndar publicado por el Instituto Nacional Estadounidense de Estndares (American National Standards Institute) para el lenguaje de programacin C
15

101

eficientemente este tipo de cdigo, otro aspecto a considerar en la escritura de un programa en C para sistemas empotrados es que el 8051 no tiene ningn soporte directo para los tipos de datos con signo, por ende, operaciones con signo requieren instrucciones adicionales mientras que los tipos de datos sin signo no lo requieren, por este motivo debe evitarse el uso de variables con signo siempre y cuando se pueda. Los tipos de variables soportados por el compilador C51 se muestran en la Tabla 4.2.
Tabla 4.2.- Tipos de variables soportados por el compilador C51 Tipo bit signed char unsigned char enum signed short unsigned short signed int unsigned int signed long unsigned long Bits 1 8 8 16 16 16 16 16 32 32 Bytes Rango 0a1 1 -128 a +127 1 0 a 255 2 -32.768 a +32.767 2 -32.768 a +32.767 2 0 a 65.535 2 -32.768 a +32.767 2 0 a 65.535 4 -2.147.483.648 a +2.147.483.647 4 0 a 4.294.967.295 Compilador Keil C51 Keil C51/ANSI C Keil C51/ANSI C Keil C51/ANSI C Keil C51/ANSI C Keil C51/ANSI C Keil C51/ANSI C Keil C51/ANSI C Keil C51/ANSI C Keil C51/ANSI C

El compilador C51 tambin aade 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 configuracin de: temporizadores, puertos seriales, puertos de E/S y perifricos en general. Los SFR se encuentran en un rea de memoria RAM al cual se puede acceder ms rpidamente que la memoria de propsito general y su acceso puede ser mediante un tipo de datos bool (1bit), byte (8bits) o word (16bits), los tipos de SFR que maneja el compilador C51 se muestran en la Tabla 4.3.

102

Tabla 4.3.- Tipos de SFR que maneja el compilador C51 Tipo Sbit Sfr Sf16 Bits 1 8 16 Bytes 1 2 Rango 0a1 0 a 255 0 a 65.535

4.2.1.2.- OPERACIONES Y ASIGNACIONES A NIVEL DE BITS

Las operaciones a nivel de bits que maneja el lenguaje C permiten una serie de manipulaciones de datos que son muy tiles en aplicaciones integradas, incluyendo los ejemplos que se vern en los futuros captulos. 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 Smbolo Forma ~ ~x & x&y | x|y ^ x^y << >> x << y x >> y Descripcin operacin de bit NOT operacin de bit AND operacin de bit OR operacin de bit XOR desplazamiento a la izquierda desplazamiento a la derecha Operacin todos los bits se invierten cada bit de x AND cada bit de y cada bit de x OR cada bit de y cada bit de x XOR cada bit de y todos los bits en x se desplazan a la izquierda en y bits todos los bits en x se desplazan a la derecha en y bits

Tabla 4.5.- Asignaciones a nivel de bits que permite el lenguaje C Smbolo Forma &= x &= y |= x |= y ^= x ^= y <<= >>= Descripcin asignacin de bit AND asignacin de bit OR asignacin de bit XOR asignacin de desplazamiento x <<= y a la izquierda asignacin de desplazamiento x >>= y a la derecha Operacin asigna x & y a x asigna x | y a x asigna x ^ y a x desplaza los bits en x hacia la izquierda en y bits desplaza los bits en x hacia la derecha en y bits

4.2.1.3.- ESTRUCTURA DE UN PROGRAMA ESCRITO EN C

La estructura de un programa escrito en C para un microcontrolador es bsicamente la misma estructura de un programa estndar en C con algunos cambios menores, la estructura tpica se muestra en la Figura 4.6. 103

/****************************************************************************** * FILE_NAME: main.c * *-----------------------------------------------------------------------------* * This is the program header. Describe your program here briefly * ******************************************************************************/ /* include your headers here */ #include <t89c51cc01.h> /* include your variable declarations here */ bit var_1; unsigned char var_2; unsigned int var_3; /* include your functions here */ void func_1(void) { /* body of function */ } /* include your main code here */ void main(void) /* main code */ { /* initialisation of variables */ while(1) /* start of endless loop */ { /* body of loop */ }

Figura 4.6.- Estructura general de un programa escrito en C para sistemas empotrados

Es necesario aclarar en este punto que la serie de laboratorios que se implementarn los programas ya estarn escritos y se le pedir al alumno modificar algunos parmetros necesarios para la configuracin y comunicacin de los kits.

4.2.1.4.- RUTINAS DE INTERRUPCIN

El microcontrolador Atmel T89C51CC01 tiene un total de 10 vectores de interrupcin: dos interrupciones externas (INT0 e INT1), tres interrupciones por temporizador (Timer 0/1/2), una interrupcin por puerto serie (UART), una

104

interrupcin por el arreglo de contador programable (PCA/EWC 16), una interrupcin por conversin anloga/digital (ADC), una interrupcin por comunicacin CAN y finalmente una interrupcin 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 Interrupcin Externa 0 (INT0) Timer 0 (TF0) Externa 1 (INT1) Timer 1 (TF1) UART (RI o TI) Timer 2 (TF2) PCA (CF o CCFn) CAN (Tx, Rx, Err, OvrBuff) ADC (ADCI) CAN Timer (OvrTim) Nmero 0 1 2 3 4 5 6 7 8 9 Vector de direccionamiento 0x0003 0x000B 0x0013 0x001B 0x0023 0x002B 0x0033 0x003B 0x0043 0x004B

El compilador C51 permite declarar rutinas de interrupcin en el cdigo C para que el programa se dirija automticamente a ste cuando se produzca una interrupcin, genera automticamente los vectores de interrupcin adems del cdigo para entrar y salir de las rutinas de interrupcin. El esquema de las rutinas de interrupcin es similar a la declaracin de funciones con la salvedad que el nmero de interrupcin debe declararse como parte de la funcin, 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 cdigo escrito en C de una rutina de interrupcin

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

105

4.2.1.5.- CREAR UN PROGRAMA DE REFERENCIA

Una vez familiarizado con los aspectos de la programacin para microcontroladores se mostrar cmo empezar a crear un proyecto con el IDE Keil Vision. La forma de crear un programa de referencia se mostrar a continuacin: 1.- En primer lugar ejecutar el programa Keil Vision3 (Figura 4.8).

Figura 4.8.- Interfaz grfica de inicio del IDE Keil Vision3

2.- Dirjase al men desplegable Project New Vision Project y guarde el proyecto con el nombre que desee, por ejemplo my_project. 3.- A continuacin en la ventana de seleccin de dispositivo elija el proveedor Atmel y posteriormente el microcontrolador T89C51CC01 (Figura 4.9). 106

Figura 4.9.- Ventana de seleccin de dispositivo

4.- Cuando el programa consulte por copiar el cdigo de inicio estndar para un microcontrolador 8051 a la carpeta del proyecto, escoger No. 5.- Una vez configurado el dispositivo de destino marque y presione el click derecho del mouse sobre la carpeta Target 1 y seleccione el men desplegable Options for Target (Figura 4.10).

107

Figura 4.10.- Men desplegable Options for Target

6.- Aparecer una ventana con una serie de opciones de configuracin para el proyecto, de las cuales, en primera instancia, interesa cambiar la configuracin por defecto de las pestaas Target y Output. 7.- En la pestaa Target (Figura 4.11) modifique la opcin de frecuencia del cristal Xtal (MHz) por 12, para ser coincidente con el cristal de 12MHz empleado en el kit de desarrollo 17.

17

sta modificacin no causa ningn cambio en el cdigo generado cuando se compile un proyecto, pero es til para simular la temporizacin, los retardos por software y configuracin de velocidad de los perifricos en las sesiones de depuracin

108

Figura 4.11.- Pestaa Target de la ventana Options for Target

8.- En la pestaa Output (Figura 4.12) seleccione la casilla de verificacin Create HEX File para generar un archivo hexadecimal del proyecto, el que posteriormente ser programado en el microcontrolador.

109

Figura 4.12.- Pestaa Output de la ventana Options for Target

9.- A continuacin 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 aadir el cdigo de fuente de todos los archivos necesarios para el desarrollo del proyecto.

110

Figura 4.13.- Men desplegable Add Files to Group

10.- Finalmente se puede compilar el proyecto marcando y presionando el click derecho del mouse sobre la carpeta Target 1 y seleccionando el men desplegable Build target (Figura 4.14).

111

Figura 4.14.- Men desplegable Build target

4.2.1.6.- AGREGAR OPCIONES DE DEPURACIN

Una vez que el proyecto est creado se pueden agregar opciones de depuracin las cuales son muy tiles a la hora de identificar y corregir errores de programacin. A su vez tambin es una herramienta muy importante para la revisin sistemtica del cdigo de fuente y para dar seguimiento de la ejecucin 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 depuracin se mostrar a continuacin: 1.- En primer lugar debe marcar y presionar el click derecho del mouse sobre la carpeta Target 1 y seleccionar el men desplegable Options for Target (Figura 4.10). 112

2.- Dentro de la ventana de opciones del proyecto, debe dirigirse, en esta instancia, a la pestaa Debug (Figura 4.15), presionar el botn de seleccin de la opcin Initialization File y escoger el archivo necesario para realizar la depuracin del proyecto, que en este ejemplo es llamado debug.ini.

Figura 4.15.- Pestaa Debug de la ventana Options for Target

3.- Para tener ms fcil acceso al archivo de depuracin dentro del IDE, se pude incluir dentro del espacio de trabajo un nuevo grupo que contenga dicho archivo. 4.- Para crear un nuevo grupo debe marcar y presionar el click derecho del mouse sobre la carpeta Target 1 y seleccionar el men desplegable New Group (Figura 4.16).

113

Figura 4.16.- Men desplegable New Group

5.- A continuacin se crear una nueva carpeta de archivos dentro del proyecto la cual es conveniente renombrar con un nombre que tenga algn significado, en este ejemplo se llamar Debug Session 1. 6.- Posteriormente debe marcar y presionar el click derecho del mouse sobre la carpeta creada y seleccionar el men desplegable Add Files to Group (Figura 4.17).

114

Figura 4.17.- Men desplegable Add Files to Group

7.- En la ventana desplegable cambie el tipo de filtro a All files (*.*) y agregue el archivo de depuracin que desee, continuando con el ejemplo se selecciona debug.ini, y cuando el programa consulte por el tipo de archivo seleccionado escoja la opcin Text Document file. 8.- Finalmente, si todos los pasos han sido ejecutados correctamente, se tendr un espacio de trabajo del proyecto similar al mostrado en la Figura 4.18.

115

Figura 4.18.- Estructura del proyecto my_project

4.2.2.- HERRAMIENTA DE PROGRAMACIN DEL SISTEMA

La herramienta de programacin del sistema es llamado por la compaa Atmel como FLIP (FLexible In-system Programmer), es un software que se ejecuta en el computador y sirve para la programacin de microcontroladores de dicha compaa. Esta herramienta puede programar dispositivos dentro del sistema (ISP: In-System Programming) a travs de UART, USB y CAN 18. El tipo de programacin 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 continuacin: 1.- Interconectar la tarjeta de demostracin C51 (C51 Demo Board) con la tarjeta de extensin CAN (CAN Extension Board). 2.- Energizar la tarjeta de demostracin C51 conectando el suministro de energa de 9V. 3.- Conectar el puerto RS-232 de la tarjeta de demostracin C51 al puerto de comunicaciones COM del PC mediante un cable RS-232

18

La programacin para el microcontrolador T89C51CC01 puede ser slo a travs de los puertos RS-232 y CAN ya que no posee interfaz USB, adems la programacin por medio del bus CAN requiere un sistema electrnico llamado dongle

116

Macho/Hembra 19. 4.- Asegurarse que el microcontrolador T89C51CC01UA-SLIM est conectado al zcalo PLCC44 de la tarjeta de extensin CAN.

Figura 4.19.- Conexin 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 aplicacin de software llamada gestor de arranque (Bootloader). El gestor de arranque que se utilizar para los proyectos ser el UART 20 el cual se encarga de realizar tareas para programar o reprogramar la memoria FLASH del microcontrolador (EEPROM) utilizando el puerto serie. El kit de desarrollo se

19 En caso de que el computador a utilizar no tenga puerto de comunicaciones serial (COM) se puede utilizar un conversor USB a RS-232

Los microcontroladores T89C51CC01 vienen disponibles con 2 gestores de arranque: UART y CAN ambos, a grandes rasgos, se encargan de iniciar una secuencia de reconocimiento de la velocidad de la interfaz serial (UART o CAN) para posteriormente realizar tareas relacionadas con la lectura y/o escritura del chip en la memoria FLASH (EEPROM)
20

117

encarga de, segn el posicionamiento de los interruptores: J9, J11 y J16, saltar la ejecucin del programa principal para ejecutar el gestor de arranque y realizar tareas de programacin en el microcontrolador (modo Gestor de Arranque) o, en sentido contrario, saltar la ejecucin del gestor de arranque para ejecutar la aplicacin principal (modo Aplicacin 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 demostracin C51 deben quedar como se muestra en la Figura 4.20.

Figura 4.20.- Condicin de hardware configurado para arrancar en modo Gestor de Arranque

Despus 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 Aplicacin de Usuario. Para iniciar el sistema en modo Aplicacin

118

de Usuario las posiciones de los interruptores J9, J11 y J16 de la tarjeta de demostracin C51 deben quedar como se muestra en la Figura 4.21.

Figura 4.21.- Condicin de hardware configurado para arrancar en modo Aplicacin de Usuario

4.2.2.2.- USO DEL PROGRAMADOR DE SISTEMA

En segundo lugar veremos los pasos necesarios para utilizar el software de programacin FLIP y verificar que se han establecido correctamente los parmetros necesarios para poder programar la tarjeta de demostracin: 1.- En primer lugar ejecutar el programa FLIP (Figura 4.22).

119

Figura 4.22.- Interfaz grfica de inicio del programador FLIP

2.- Dirjase al men desplegable Device Select seleccione el dispositivo T89C51CC01, ntese que la ventana de la aplicacin mostrar ahora la configuracin del microcontrolador (Figura 4.23).

120

Figura 4.23.- Ventana del programador FLIP con el dispositivo T89C51CC01 seleccionado

3.- Asegrese de que el kit de desarrollo se encuentre debidamente conectado al PC con la condicin de hardware configurado para arrancar en modo Gestor de Arranque (Figura 4.20) y posteriormente encienda el kit de desarrollo. 4.- A continuacin seleccione el men desplegable Settings Communication RS232, en la ventana de configuracin RS232 Setup escoja de puerto COM al cual est conectado el kit de desarrollo y configure la velocidad de transmisin, tal como se muestra en la Figura 4.24.

121

Figura 4.24.- Configuracin del puerto RS-232

5.- Iniciar la comunicacin presionando el botn Connect de la ventana de configuracin RS232 Setup. Si la conexin es exitosa, la ventana del FLIP debe ser similar a la mostrada en la Figura 4.25 21.

En algunos ordenadores porttiles es necesario realizar el siguiente procedimiento: Haga clic en Connect, resetee el kit de desarrollo y a continuacin haga clic en Sync
21

122

Figura 4.25.- Conexin exitosa del kit de desarrollo

6.- En el men desplegable File Load HEX File elija la aplicacin que desee programar en el microcontrolador, previamente compilada y en formato binario hexadecimal. El mensaje HEX file parsed mostrado en la parte inferior de la ventana del programador FLIP confirma que la carga del archivo fue exitosa (Figura 4.26).

123

Figura 4.26.- Archivo hexadecimal debidamente cargado

7.- Asegurarse

que

las

casillas

de

verificacin

siguientes

estn

seleccionadas en la seccin Operations Flow del FLIP: Erase Blank Check Program Verify

8.- Deje sin verificar el cuadro de BLJB en la seccin T89C51CC01 a fin de ejecutar el programa de demostracin despus del siguiente reinicio. 9.- Presione el botn Run para que la programacin se ejecute. El mensaje 124

Verify PASS mostrado en la parte inferior de la ventana del programador FLIP confirma que el microcontrolador se ha programado correctamente (Figura 4.27).

Figura 4.27.- Programacin exitosa del microcontrolador

10.- Una vez programado asegrese de que el kit de desarrollo se encuentre con la condicin de hardware configurado para arrancar en modo Aplicacin de Usuario (Figura 4.21). 11.- Finalmente, reinicie el kit de desarrollo para iniciar la aplicacin programada en el microcontrolador.

125

CAPTULO 5.- PUESTA EN FUNCIONAMIENTO DEL SISTEMA CAN

El propsito de este captulo es la de ensear al alumno el protocolo de comunicaciones CAN utilizando un kit de desarrollo, considerando para esto los aspectos acadmicos relacionados con el estudio de dicho protocolo. Para realizar lo anteriormente expuesto, se ensea la metodologa 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: Guas de Laboratorio.

5.1.- INTRODUCCIN A LA PROGRAMACIN DE APLICACIONES PARA EL KIT DE DESARROLLO

El propsito de este laboratorio es familiarizar al alumno con el kit de desarrollo y las herramientas necesarias para la creacin, compilacin y programacin 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 comunicacin asncrona. El funcionamiento del puerto RS-232 del microcontrolador. Este laboratorio consta de utilizar las libreras creadas especficamente para hacer uso de los componentes de hardware implementados en el kit de desarrollo, cuyo propsito es ayudar al alumno a crear aplicaciones que hagan uso de dichos componentes, se entregar al alumno 3 programas escritos en C que mostrarn el uso de: La barra de LEDs. La pantalla LCD. 126

El puerto RS-232.

5.1.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE

Para la puesta en funcionamiento del kit de desarrollo es necesario contar con herramientas de software y de hardware que se enumerarn a continuacin:
Tabla 5.1.- Requerimientos de software y de hardware para el laboratorio n1 Requerimientos Herramientas Entorno de desarrollo integrado: Keil C51 Herramienta de programacin del sistema: Atmel FLIP Cdigo de fuente de los programas bargraph, display y rs232 Programas compilados en formato hexadecimal bargraph.hex, display.hex y rs232.hex Un kit de desarrollo CAN adems de su respectivo microcontrolador del tipo: T89C51CC01UA-SLSIM Un Cable Serie RS-232 DB9/DB9 (Macho/Hembra) para la comunicacin entre el kit de desarrollo y el computador

Requerimientos de Software

Requerimientos de Hardware

5.1.2.- CONVENCIONES DE PROGRAMACIN

En todos los proyectos que se mostrarn desde ahora en adelante har uso de un archivo de configuracin llamado config.h (Figura 5.1) que estar incluido en el cdigo de fuente de todos los archivos con el fin de compartir las configuraciones en todos los proyectos.

127

/****************************************************************************** * FILE_NAME: config.h * *-----------------------------------------------------------------------------* * FILE_PURPOSE: This file is included by all source files in order to access * * to system wide configuration * ******************************************************************************/ #ifndef _CONFIG_H_ #define _CONFIG_H_ #include <t89c51cc01.h> #include "compiler.h" #endif /* _CONFIG_H_ */

Figura 5.1.- Ejemplo de utilizacin del archivo config.h incluido en las rutinas

El archivo de configuracin incluido hace a su vez la inclusin de los archivos t89c51cc01.h y compiler.h. El archivo t89c51cc01.h aade 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 adems de definir nombres para tipos de datos que hagan ms fcil el declarar variables y parmetros (tambin llamados alias). Dentro de los nombres definidos en el archivo compiler.h se mostrarn los ms utilizados dentro de los proyectos, los que corresponden a las definiciones de tipo asociadas a las variables (Tabla 5.2) y las definiciones de constantes asociadas a las interrupciones (Tabla 5.3).

128

Tabla 5.2.- Definicin de tipos entregados en el archivo compiler.h Definicin Bool Uchar Uint8 Uint16 Uint32 Int8 Int16 Int32 Tipo unsigned char unsigned char unsigned char signed char unsigned int signed int unsigned long signed long Bits 8 8 8 8 16 16 32 32 Bytes 1 1 1 1 2 2 4 4

Tabla 5.3.- Definicin de constantes asociados a interrupciones entregados en el archivo compiler.h Nombre Nmero Interrupcin 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.- ESTNDAR RS-232

El estndar RS-232, definido en el ANSI como EIA-232, emplea un esquema de transmisin serie con un circuito elctrico single-ended y especifica el conjunto de reglas para intercambiar datos entre 2 equipos de computacin, originalmente nombrados como DTE (Data Terminal Equipment) y DCE (Data Communication Equipment) o MODEM. Es adecuado para transferir datos a mxima velocidad a distancias de hasta 15m segn la norma 22, la interfaz puede trabajar en comunicacin

22

La revisin C especificaba una longitud mxima entre equipos de 15m, pero posteriores revisiones, D y E, han cambiado este requisito por uno ms realista al especificar una capacidad mxima del canal de transmisin. De esta manera, las longitudes mximas aceptables dependen de las caractersticas de los cables empleados y las capacidades de entrada de los circuitos de interface

129

asncrona o sncrona y tipos de canal simplex, half dplex o full dplex. Para generar un enlace entre 2 dispositivos, 5 parmetros deben especificarse, estos parmetros son: velocidad de transmisin, bits de datos, paridad, bits de parada y control de flujo, los cuales de describen a continuacin: Velocidad de transmisin: Determina cuanta informacin es transferida sobre un determinado intervalo de tiempo la cual se mide en bits por segundo, usualmente se pueden elegir velocidades que estn estandarizadas y van desde 75 hasta 19200bps 23. Por ejemplo, de la famosa velocidad 9600bps obtenemos 1/9600 = 104s. Bits de datos: Puede ser desde 5 a 8 bits de datos 24, comnmente slo se utilizan implementaciones de 7 u 8 bits de datos dependiendo de la naturaleza de datos a ser transferidos, como ejemplo el estndar 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 transmisin. Los bits de inicio y trmino no se tienen en cuenta para el clculo de la paridad. Bits de parada: Se utiliza para asegurar que no se transmita nada por la lnea 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 extrao 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 estndar de las normas por la infinidad de variaciones que permite ya que comnmente es utilizado a velocidades mayores que llegan hasta los 115200bps (o superiores) pero stas velocidades no son parte del estndar

5 y 6 bits de datos se utilizan para equipos de comunicacin especializados, algunos mdems permiten tambin el uso de 4 bits de datos pero no es estndar
24

130

9600bps, 1,5104s = 156s. Control de flujo: El control de flujo o tambin llamado handshaking (apretn de manos) hace referencia a la forma en la que el transmisor y el receptor se notifican su estado para llevar a cabo la comunicacin y puede ser: Ninguno: No es necesario emplear control de flujo. Hardware: Utilizando lneas fsicas especficas para esta tarea: RTS y CTS. Software: Por la propia UART se envan valores especficos para este fin: XON y XOFF 25. Debe tomarse en consideracin que siempre el bit de inicio tiene 1 bit, por lo que la transmisin y recepcin 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 trmino. En muchas aplicaciones se utiliza una velocidad de transmisin 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 configuracin 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 envo de datos enva XOFF, mientras que cuando el receptor quiere que el transmisor enve ms datos enva XON

131

5.1.4.- LABORATORIO N1.1

En este laboratorio se describir la utilizacin de la pantalla LCD para el kit de desarrollo utilizando la librera de la pantalla LCD, esta librera 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 funcin 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 funcin se encarga de escribir en la pantalla una cadena de caracteres determinada de la forma <nmero de lnea, texto a mostrar>, la utilizacin en un programa se ejemplifica en la Figura 5.2.

132

/****************************************************************************** * FILE_NAME: main.c * *-----------------------------------------------------------------------------* * FILE_PURPOSE: Display LCD program example * ******************************************************************************/ #include "config.h" #include "lcd.h" void main(void) { lcd_init(); /* lcd initialisation */ set_lcd_line(1, ATMEL Wireless &); /* welcome */ set_lcd_line(2, MicroControllers); /* message */ while(1); /* start of endless loop */ }

Figura 5.2.- Ejemplo de utilizacin de la librera de la pantalla LCD

La utilizacin de esta librera se ejemplifica en el proyecto display.uv2 en donde se ver la inclusin de sta en el programa principal. Finalmente la estructura del programa se muestra en la Figura 5.3.

Figura 5.3.- Estructura del proyecto display

Se dejar como labor para el alumno compilar el programa escrito y programar el kit de desarrollo.

133

5.1.5.- LABORATORIO N1.2

En este laboratorio se describir la utilizacin de la barra de LEDs para el kit de desarrollo, sta librera contiene los siguientes archivos: bg.c bg.h La cual tambin 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 funcin se encarga de ejecutar los procedimientos para inicializar la barra de LEDs dejndolos todos apagados, mientras que la segunda funcin se encarga de escribir en la barra de LEDs una secuencia de caracteres que se entrega en formato hexadecimal, la utilizacin en un programa se ejemplifica en la Figura 5.4.

134

/****************************************************************************** * FILE_NAME: main.c * *-----------------------------------------------------------------------------* * FILE_PURPOSE: Bargraph LED program example * ******************************************************************************/ #include "config.h" #include "bg.h" Uchar bar_led; Uint16 i; void delay(Uint16 tempo) { for(i=0; i<tempo; i++); } void main(void) { bar_led = 0xAA; /* bar_led initialisation, 0xAA = 1010 1010 */ bg_init(); /* bargraph initialisation */ while(1) /* start of endless loop */ { delay(0xC350); /* delay for approx. 250ms */ set_bg_value(bar_led); /* send bargraph output */ bar_led = ~bar_led; /* flip all bits */ } }

Figura 5.4.- Ejemplo de utilizacin de la librera de la barra de LEDs

La utilizacin de esta librera se ejemplifica en el proyecto bargraph.uv2 en donde se ver la inclusin de sta en el programa principal. Adems 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 funcin 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 botn de interrupcin INT1, finalmente la estructura del programa se muestra en la Figura 5.5.

135

Figura 5.5.- Estructura del proyecto bargraph

Se dejar como labor para el alumno compilar el programa escrito y programar el kit de desarrollo.

5.1.6.- LABORATORIO N1.3

En ste laboratorio se describir la utilizacin del puerto de comunicacin RS-232 para el kit de desarrollo, para esto es necesario utilizar una biblioteca estndar para el lenguaje de programacin C, la cual es llamada stdio.h (cabecera estndar de entrada/salida), este archivo contiene las definiciones de macros, las constantes, las declaraciones de funciones y la definicin de tipos usados por varias operaciones de entrada y salida, la funcin que se utilizar desde ahora en adelante ser la funcin 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 parmetro opcional de configuracin que si es configurado como el hexadecimal

136

0x80 (SMOD = 1) duplica la velocidad de bits por segundo configurada para el puerto serie. SCON: Registro de control para el puerto serie, por ejemplo si es configurado como el hexadecimal 0x40 (SM0 = 0 y SM1 = 1) se habilita el puerto serie en modo 1 (8-bit de datos con velocidad de bits variable) sin recepcin 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 recepcin 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 interrupcin causada por la transmisin o recepcin de datos por el puerto serie 26. En el caso de utilizar el Timer 0/1 para la comunicacin serie los registros a configurar son los siguientes: TMOD: Registro de control del modo de trabajo para los Timer 0 y 1, por ejemplo si es configurado como el hexadecimal 0x02 (M10 = 1 y M00 = 0) habilita el funcionamiento del Timer 0 en modo 2 (temporizador de 8 bits con auto-recarga 27); mientras que si es configurado como el hexadecimal 0x20 (M11 = 1 y M01 = 0) habilita el funcionamiento del Timer 1 en modo 2.

26

Es pertinente indicar que siempre antes de transmitir datos por el puerto RS-232 es necesario asignar TI = 1, pues la funcin printf que a su vez hace un llamado a la funcin putchar se encarga de verificar si TI = 1 antes de enviar datos al puerto serie, una vez enviado un carcter asigna TI = 0 para luego asignar nuevamente TI = 1 en caso de requerir transmitir ms caracteres, por ende la primera asignacin TI = 1 debe ser escrito por uno mismo para que este ciclo tenga efecto El valor de recarga del Timer 0/1 se lee desde TH0/TH1 cuando se desborda el registro TL0/TL1 segn sea el caso

27

137

TH0 y TH1: Registro de byte alto del Timer 0/1 que en el funcionamiento en modo 2 debe ser cargado con una constante para recargar el registro TL0/TL1 una vez que este se haya desbordado, la Tabla 5.4 muestra los valores de recarga para distintos cristales.

TR0 y TR1: Registro perteneciente a TCON que se encarga de arrancar o parar el Timer 0/1, se activa con un valor 1 y se desactiva con un valor 0.

Tabla 5.4.- Valores de recarga del registro TH0/TH1 para obtener distintas velocidades de transmisin Velocidad de Cristal [MHz] transmisin [bps] 9600 4800 2400 1200 9600 4800 2400 1200 12,000 12,000 12,000 12,000 11,059 11,059 11,059 11,059 Valor del bit SMOD 1 1 0 0 0 0 0 0 Valor de recarga para TH0/TH1 0xF9 0xF3 0xF3 0xE6 0xFD 0xFA 0xF4 0xE8 Error [%] 6,99 0,16 0,16 0,16 0 0 0 0

Los valores para el clculo 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] [5. 2]

2SMOD FOSC Baud Rate = 2 32 [256 TH0/TH1] configurar son los siguientes:

En el caso de utilizar el Timer 2 para la comunicacin serie los registros a

T2CON: Registro de control del Timer 2, por ejemplo si es configurado

138

como el hexadecimal 0x30 (RCLK = 1 y TCLK = 1) se establece el Timer 2 como reloj para la transmisin de datos para el puerto serie en modo temporizador de 16 bits con auto-recarga 28. RCAP2H y RCAP2L: Registro de byte alto y bajo del Timer 2 respectivamente, que en el funcionamiento en modo temporizador de 16 bits con auto-recarga deben ser cargados con una constante para recargar el registro TL2 y TH2 una vez que estos se hayan desbordado, la Tabla 5.5 muestra los valores de recarga para distintos cristales. TR2: Registro perteneciente a T2CON que se encarga de arrancar o parar el Timer 2, se activa con un valor 1 y se desactiva con un valor 0.
Tabla 5.5.- Valores de recarga de los registros RCAP2H y RCAP2L para obtener distintas velocidades de transmisin Velocidad de transmisin [bps] 115200 57600 38400 19200 14400 9600 115200 57600 38400 19200 14400 9600 Cristal [MHz] 12,000 12,000 12,000 12,000 12,000 12,000 11,059 11,059 11,059 11,059 11,059 11,059 Valor del bit SMOD 1 1 1 1 0 0 0 0 0 0 0 0 Valor de Valor de recarga para recarga para Error [%] RCAP2H RCAP2L 0xFF 0xF9 6,99 0xFF 0xF3 0,16 0xFF 0xEC 2,34 0xFF 0xD9 0,16 0xFF 0xE6 0,16 0xFF 0xD9 0,16 0xFF 0xFD 0 0xFF 0xFA 0 0xFF 0xF7 0 0xFF 0xEE 0 0xFF 0xE8 0 0xFF 0xDC 0

Los valores para el clculo de los valores de recarga de los registros RCAP2H y RCAP2L se obtienen de las Ecuaciones 5.3 y 5.4.

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

139

Baud Rate =

(RCAP2H, RCAP2L) = 65536

2SMOD FOSC 32 [65536 (RCAP2H, RCAP2L)]

2SMOD FOSC 32 Baud Rate

[5. 3] [5. 4]

Como se puede ver en la Tabla 5.4 y Tabla 5.5 la mayor velocidad de transmisin utilizando un cristal de 12MHz y manteniendo un error aceptable 29 es de 4800bps en caso de utilizar el Timer 0/1 y 57600bps en caso de utilizar el Timer 2, la utilizacin en un programa utilizando el Timer 1 se ejemplifica en la Figura 5.6.
/****************************************************************************** * FILE_NAME: main.c * *-----------------------------------------------------------------------------* * FILE_PURPOSE: RS232 program example * ******************************************************************************/ #include <stdio.h> #include config.h void serial_init(void) { PCON |= 0x80; /* SCON = 0x40; /* TMOD |= 0x20; /* TH1 = 0xF3; /* TR1 = 1; /* TI = 1; /* }

SMOD1 = 1, double baud rate */ serial port in mode 1, 8-bit UART data */ timer 1 in mode 2, 8-bit autoreload */ reload value for 2400 bauds @ 12MHz */ turn on timer 1 */ indicator ready to transmit */

void main(void) { serial_init(); /* serial initialisation */ printf( ATMEL T89C51CC01\n); /* welcome */ printf( RS232 Program Example\n\n); /* message */ while(1); /* start of endless loop */ }

Figura 5.6.- Ejemplo de utilizacin de la librera stdio.h

Se habla de un error aceptable para comunicaciones seriales un valor que no supere el 2,5% de error en la velocidad de transferencia ya que la comunicacin a travs del puerto RS-232 es extremadamente sensible a fluctuaciones
29

140

La utilizacin de esta librera se ejemplifica en el proyecto rs232.uv2 en donde se ver la inclusin de sta en el programa principal. Adems 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 funcin 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 botn de interrupcin INT1, finalmente la estructura del programa se muestra en la Figura 5.7.

Figura 5.7.- Estructura del proyecto rs232

Se dejar como labor para el alumno compilar el programa escrito y programar el kit de desarrollo para generar distintas velocidades de transmisin

141

del puerto RS-232. Las velocidades requeridas van desde 2400 hasta 57600bps tal como se indica en la Tabla 5.6.
Tabla 5.6.- Velocidades de transmisin requeridas para la configuracin del puerto RS-232 Velocidad de transmisin [bps] 57600 38400 19200 14400 9600 4800 2400 1200 Temporizador Timer 2 Timer 2 Timer 2 Timer 2 Timer 2 Timer 0/1 Timer 0/1 Timer 0/1

Para la visualizacin de mensajes entregados por el microcontrolador a travs 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 estndar como Hyperterminal tal como se muestra en la Figura 5.8.

142

Figura 5.8.- Conexin entre el PC y el kit de desarrollo CAN para visualizar mensajes mediante RS-232

El puerto COM del PC conectado al kit de desarrollo debe configurarse como X-8-N-1-N, en donde el valor de X est dado por la velocidad que se configur el kit de desarrollo (Figura 5.9).

143

Figura 5.9.- Configuracin del puerto RS-232

5.2.- ESTUDIO DE LA CAPA FSICA Y DE ENLACE DE DATOS DEL PROTOCOLO CAN

El propsito de este laboratorio es familiarizar al alumno con el estudio de la capa fsica y de enlace de datos del protocolo CAN haciendo uso del kit de desarrollo, para ello es necesario abarcar los siguientes aspectos: Ensear los niveles de voltaje e impedancia que maneja el protocolo CAN. Explicar cmo crear un nodo para generar transmisin y recepcin de mensajes utilizando las libreras entregadas por el fabricante. Mostrar la estructura general de una trama CAN, campos de:
SOF (inicio de trama) Identificador (estndar o extendido)

144

Control (tipo de trama y nmero de bytes de datos) Datos (mensaje de hasta 8 bytes) CRC (deteccin de errores) ACK (acuse de recibo) EOF (fin de trama)

Detallar la configuracin de los registros necesarios para obtener comunicaciones a distintas velocidades. Este laboratorio consta de utilizar las libreras CAN entregadas por el

fabricante para la programacin del kit de desarrollo, se entregar al alumno 4 programas escritos en C que mostrarn el uso de: Envo y recepcin de distintos mensajes CAN (tramas de datos y remotas) a distintas velocidades. Rutinas de envo secuencial y recepcin de mensajes CAN, mostrados en la barra de LEDs, el panel LCD y el puerto RS-232.

5.2.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE

Para la puesta en funcionamiento del kit de desarrollo es necesario contar con herramientas de software y de hardware que se enumerarn a continuacin:

145

Tabla 5.7.- Requerimientos de software y de hardware para el laboratorio n2 Requerimientos Herramientas Entorno de desarrollo integrado: Keil C51 Herramienta de programacin del sistema: Atmel FLIP Utilidad para calcular la velocidad de bit para el bus CAN en el kit de desarrollo: X-Calculator Cdigo 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 adems de sus respectivos microcontroladores del tipo T89C51CC01UA-SLSIM Un Cable Serie RS-232 DB9/DB9 (Macho/Hembra) para la comunicacin entre el kit de desarrollo y el computador Un Cable Serie RS-232 DB9/DB9 (Macho/Macho) para la comunicacin entre ambos kits de desarrollo

Requerimientos de Software

Requerimientos de Hardware

5.2.2.- LIBRERA DE COMUNICACIN CAN

En estos laboratorios se describir la utilizacin del bus CAN para el kit de desarrollo utilizando la librera CAN entregada por el fabricante, sta librera 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 estndar) Uchar tab[4]: permite el acceso por byte al identificador

146

can_msg_t: struct
can_id_t id: identificador del mensaje CAN, 11 bits en modo estndar y 29 bits en modo extendido Uchar ctrl: define cierta informacin especfica 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 estndar = 0 o identificador extendido = 1 (se accede por MSK_CTRL_IDE) bits 3-0: DLC nmero 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 parmetros de configuracin son las siguientes: void ClearAllMailbox(void): Funcin que se utiliza para borrar toda la memoria RAM del controlador CAN void CanSetBRP(Uchar prescaler): Funcin que se utiliza para inicializar el parmetro BRP (Baud Rate Prescaler) del controlador CAN con el parmetro prescaler void CanSetSJW(Uchar sjw): Funcin que se utiliza para inicializar el parmetro SJW (re-Synchronization Jump Width) del controlador CAN con el parmetro sjw void CanSetPRS(Uchar prs): Funcin que se utiliza para inicializar el

147

parmetro PRS (Propagation time Segment) del controlador CAN con el parmetro prs void CanSetPHS1(Uchar phs1): Funcin que se utiliza para inicializar el parmetro PHS1 (Phase Segment 1) del controlador CAN con el parmetro phs1 void CanSetPHS2(Uchar phs2): Funcin que se utiliza para inicializar el parmetro PHS2 (Phase Segment 2) del controlador CAN con el parmetro phs2 Las funciones encargadas de inicializar los parmetros encargados de la transmisin y recepcin de mensajes son las siguientes: void ConfChannel_Rx(void): Funcin que se utiliza para configurar un canal en el modo de recepcin. Antes de llamar a esta funcin el canal correspondiente debe estar seleccionado, asegurndose de que el canal est libre porque no se lleva a cabo ninguna verificacin de esto por la funcin. 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 configuracin se define en la variable global conf_rx, las variables globales utilizadas se detallan a continuacin:
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: Configuracin utilizada para el canal de recepcin
bit 7: MSK_RTR sin enmascaramiento del campo RTR (CONF_NOMSK_RTR) o enmascaramiento del campo RTR (CONF_MSK_RTR) bit 6: MSK_IDE sin enmascaramiento del campo IDE (CONF_NOMSK_IDE) o enmascaramiento del campo IDE (CONF_MSK_IDE) bit 5: RTR si es que existe enmascaramiento del campo RTR se aceptar solamente tramas de datos (CONF_NORTR) o tramas remotas (CONF_RTR) bit 4: IDE si es que existe enmascaramiento del campo IDE se aceptar

148

solamente bit 0:

identificadores

estndar el

(CONF_NOIDE) canal en

identificadores sin buffer

extendidos (CONF_IDE) BUFFER configura recepcin (CONF_NOBUFFER) o en recepcin con buffer (CONF_BUFFER)

void SendCanMsg(void): Esta funcin se utiliza enviar un mensaje en el bus CAN. Antes de llamar a esta funcin el canal correspondiente debe estar seleccionado, asegurndose de que el canal est libre porque no se lleva a cabo ninguna verificacin de esto por la funcin. 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 configuracin se define en la variable global conf_tx, las variables globales utilizadas se detallan a continuacin:
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: Configuracin utilizada para la transmisin
bit 5: RTR trama de datos (CONF_NORTR) o trama remota (CONF_RTR) bit 4: IDE identificador estndar (CONF_NOIDE) o identificador extendido (CONF_IDE) bits 3-0: DLC nmero de bytes de datos a transmitir (se utiliza dlc_t, CONF_DLC_0 CONF_DLC_8)

void ReadCanMsg(Uchar next_conf): Esta funcin se utiliza recibir un mensaje en el bus CAN. Esta funcin 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 configuracin entregada a travs del parmetro next_conf, la configuracin puede ser:
CHANNEL_DISABLE: El canal quedar deshabilitado CHANNEL_RX_ENABLE: El canal quedar habilitado en el modo recepcin CHANNEL_RXB_ENABLE: El canal quedar habilitado en el modo recepcin con bfer

149

finalmente la variable global utilizada se detallan a continuacin:

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): Funcin 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 funcin es llamada cuando un mensaje

es transmitido, para usar esta funcin debe: Definir esta rutina en el archivo config.h: #define USER_CAN_FCT_IT_TXOK Crear esta funcin en el espacio de trabajo

void fct_can_it_rxok(void): Esta funcin es llamada cuando un mensaje

es recibido, para usar esta funcin debe: Definir esta rutina en el archivo config.h: #define USER_CAN_FCT_IT_RXOK Crear esta funcin en el espacio de trabajo

void fct_can_it_error(void): Esta funcin es llamada cuando ocurre un

error en un canal especfico, para usar esta funcin debe: Definir esta rutina en el archivo config.h: #define USER_CAN_FCT_IT_ERROR Crear esta funcin en el espacio de trabajo

void fct_can_it_gen(void): Esta funcin es llamada cuando ocurre un

error en cualquier canal, para usar esta funcin debe: Definir esta rutina en el archivo config.h: #define USER_CAN_FCT_IT_GEN Crear esta funcin en el espacio de trabajo

void fct_can_timovf_it(void): Funcin que se encarga de manejar la

150

interrupcin producida por el desbordamiento del temporizador CAN, sta, a su vez, puede llamar a la siguiente funcin:

void fct_can_it_timovf(void): Esta funcin es llamada cuando el

temporizador CAN se desborda desde 0xFFFF a 0x0000, para usar esta funcin debe: Definir esta rutina en el archivo config.h: #define USER_CAN_FCT_IT_TIMOVF Crear esta funcin en el espacio de trabajo

Un

ejemplo

de

la

utilizacin

del

archivo

config.h

para

la

inclusin/exclusin de rutinas de interrupcin (Figura 5.10) adems del cdigo de las rutinas de interrupcin (Figura 5.11) se muestran a continuacin.
/****************************************************************************** * 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 utilizacin del archivo config.h para la definicin de rutinas

151

void fct_can_it(void) interrupt 7 { save_canpage = CANPAGE; /* save the current CANPAGE */ channel = FindFirstChIt(); /* find first channel interrupt */ if(channel = NO_CHANNEL) { CAN_SET_CHANNEL(channel); bit_var = CANSTCH; /* tx or rx interrupt */ if(IT_TXOK) { #ifdef USER_CAN_FCT_IT_TXOK can_fct_it_txok(); #endif /* USER_CAN_FCT_IT_TXOK */ } if(IT_RXOK) { #ifdef USER_CAN_FCT_IT_RXOK can_fct_it_rxok(); #endif /* USER_CAN_FCT_IT_RXOK */ } /* error analysis */ if(IT_RXOK && IT_TXOK) { #ifdef USER_CAN_FCT_IT_ERROR can_fct_it_error(); #endif /* USER_CAN_FCT_IT_ERROR */ } CANSTCH = 0x00; /* clear all channel status registers */ } else /* (channel == NO_CHANNEL) */ { /* no channel match with the interrupt => general it */ #ifdef USER_CAN_FCT_IT_GEN can_fct_it_gen(); #endif /* USER_CAN_FCT_IT_GEN */ CANGIT &= 0xF0; /* clear all general errors */ } CANPAGE = save_canpage; /* restore the old config */ } void fct_can_timovf_it(void) interrupt 9 { #ifdef USER_CAN_FCT_IT_TIMOVF can_fct_it_timovf(); #endif /* USER_CAN_FCT_IT_TIMOVF */ CANGIT &= ~MSK_CANGIT_OVRTIM; /* clear overrun timer */ }

Figura 5.11.- Cdigo de las rutinas de interrupcin de la librera CAN

152

5.2.3.- LABORATORIO N2.1

En este laboratorio se ejemplificar la creacin de un nodo transmisor y receptor de mensajes CAN utilizando las libreras del fabricante, se ver la configuracin de la velocidad del sistema, la habilitacin de las interrupciones que permiten la transmisin y recepcin de mensajes, tipos de tramas y filtrado de mensajes visualizndolos en el puerto RS-232 tanto en el programa de transmisin como el de recepcin de tramas. En primer lugar se ver la utilizacin en un programa encargado de transmitir mensajes, a modo de ejemplo se muestra un programa en la Figura 5.12 que enva mensajes con un identificador estndar 0x123 y 8 bytes de datos {0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88} a una velocidad de 500Kbps cada 250ms.

153

/****************************************************************************** * FILE_NAME: main.c * *-----------------------------------------------------------------------------* * FILE_PURPOSE: This file is a simple CAN transmission sample software * ******************************************************************************/ #include "config.h" #include "can_lib.h" Uint16 i; can_data_t xdata data_tx = {0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88}; can_msg_t xdata msg_tx = {STD_ID(0x0123), CONF_NOIDE | CONF_NORTR | CONF_DLC_8, data_tx}; void delay(Uint16 tempo) { for(i=0; i<tempo; i++); } void can_init(void) { CAN_CONTROLLER_RESET; ClearAllMailbox(); CanSetBRP(BRP_500k); CanSetSJW(SJW_500k); CanSetPRS(PRS_500k); CanSetPHS1(PHS1_500k); CanSetPHS2(PHS2_500k); CAN_CONTROLLER_ENABLE; CAN_IT_ENABLE; CAN_TX_IT_ENABLE; }

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

reset can controller */ clear all ram of can controller */ configure can baud rate prescaler*/ configure can re-synchronization jump width */ configure can propagation time segment */ configure can phase segment 1 */ configure can phase segment 2 */ enable can controller */ enable can interrupts */ enable can transmission interrupt */

void can_fct_it_txok(void) { channel = CAN_GET_CHANNEL; /* get interrupted channel */ CAN_CHANNEL_IT_DISABLE(channel); /* disable interrupt on channel */ } void main(void) { can_init(); /* can initialisation */ EA = 1; /* enable all interrupts while(1) /* start of endless loop */ { delay(0xC350); /* can_tx_id = msg_tx.id; /* conf_tx = msg_tx.ctrl; /* pt_candata_tx = msg_tx.pt_data; /* CAN_SET_CHANNEL(CHANNEL_0); /* CAN_CHANNEL_IT_ENABLE(CHANNEL_0); /* SendCanMsg(); /* } }

*/ delay for approx. 250ms */ message identifier */ message configuration */ message data pointer */ select message channel */ enable interrupt on channel */ send message */

Figura 5.12.- Ejemplo de utilizacin de la librera CAN para la transmisin de mensajes

154

En segundo lugar se ver la utilizacin en un programa encargado de recibir mensajes, a modo de ejemplo se muestra un programa en la Figura 5.13 que slo recibe mensajes con identificadores estndar que comienzan con 0x012X a una velocidad de 500kbps.
/****************************************************************************** * FILE_NAME: main.c * *-----------------------------------------------------------------------------* * FILE_PURPOSE: This file is a simple CAN reception sample software * ******************************************************************************/ #include "config.h" #include "can_lib.h" can_data_t xdata data_rx = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; can_msg_t xdata msg_rx = {0x00, 0x00, data_rx}; void can_init(void) { CAN_CONTROLLER_RESET; /* reset can controller */ ClearAllMailbox(); /* clear all ram of can controller */ CanSetBRP(BRP_500k); /* configure can baud rate prescaler*/ CanSetSJW(SJW_500k); /* configure can re-synchronization jump width */ CanSetPRS(PRS_500k); /* configure can propagation time segment */ CanSetPHS1(PHS1_500k); /* configure can phase segment 1 */ CanSetPHS2(PHS2_500k); /* configure can phase segment 2 */ can_rx_filt.std = 0x012F; /* accept only identifier */ can_rx_msk.std = 0x0120; /* start by 0x012X */ conf_rx = CONF_NOIDE|CONF_MSK_IDE; /* accept only standard identifier */ CAN_SET_CHANNEL(CHANNEL_0); /* select message channel */ CAN_CHANNEL_IT_ENABLE(CHANNEL_0); /* enable interrupt on channel */ ConfChannel_Rx(); /* configure channel for reception */ CAN_CONTROLLER_ENABLE; /* enable can controller */ CAN_IT_ENABLE; /* enable can interrupts */ CAN_RX_IT_ENABLE; /* enable can reception interrupt */ } void can_fct_it_rxok(void) { pt_st_can_rx = &msg_rx; ReadCanMsg(CHANNEL_RX_ENABLE); }

/* message data struct pointer */ /* read message and configure channel */

void main(void) { can_init(); /* can initialisation */ EA = 1; /* enable all interrupts */ while(1); /* start of endless loop */ }

Figura 5.13.- Ejemplo de utilizacin de la librera CAN para la recepcin de mensajes

155

Hay que tomar nfasis que el recibir mensajes es un poco ms complejo que enviarlos ya que a diferencia de la transmisin, que se sabe exactamente cundo y cmo ser enviado, en la recepcin se tiene la incertidumbre del momento y forma sern recibidos, por lo que hay que tomar las consideraciones necesarias para este propsito. La utilizacin de esta librera se ejemplifica en los proyectos can_tx.uv2 y can_rx.uv2 en donde se ver la inclusin de sta en el programa principal Adems es necesario hacer notar que el programa dado que est en el proyecto hace uso de la librera bg.h y la librera lcd.h adems de la configuracin 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 botn de interrupcin INT1 para ambos programas, en el programa de envo acta como iniciador de envo de mensajes mientras que en el programa de recepcin se encarga de mostrar el ltimo mensaje enviado hacia el bus CAN por el puerto RS-232, finalmente se entrega la estructura de ambos programas en la Figura 5.14.

156

Figura 5.14.- Estructura de los proyectos can_tx y can_rx

Se dejar como labor para el alumno compilar el programa escrito y programar el kit de desarrollo para generar distintas velocidades de transmisin para el bus CAN utilizando el programa X-Calculator disponible en la pgina del fabricante, como se muestra en la Figura 5.15.

157

Figura 5.15.- Utilidad para calcular la velocidad de bit para el bus CAN en el kit de desarrollo

Las velocidades a configurar por el alumno sern las mostradas en la Tabla 5.8.
Tabla 5.8.- Velocidades de transmisin requeridas para la configuracin del bus CAN Velocidad de transmisin [kbps] 500 250 100 Sample Point [%] 80 a 90 80 a 90 80 a 90

Como tarea adicional, el alumno deber generar las configuraciones indicadas en la Tabla 5.9 y Tabla 5.10 para el nodo transmisor y receptor respectivamente.

158

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

Tabla 5.10.- Configuraciones requeridas para el nodo receptor Canal 0 1 2 3 4 5 Filtro de Identificador STD: 012X STD: 001X STD: 032X EXT: 012345XX EXT: 001100XX EXT: 076543XX Filtro de Trama Datos y Remota Datos Remota Datos y Remota Datos Remota

Para la visualizacin de mensajes enviados/recibidos por el bus CAN, se puede conectar el puerto RS-232 del kit de desarrollo al puerto de comunicaciones serie de un computador y configurarse como 9600-8-N-1-N, el montaje utilizado se muestra en la Figura 5.16.

159

Figura 5.16.- Conexin entre el PC y el kit de desarrollo CAN para visualizar los mensajes de los nodos trasmisor y receptor mediante RS-232

5.2.4.- LABORATORIO N2.2

En este laboratorio se ejemplificar la creacin de un nodo transmisor y receptor de mensajes CAN utilizando las libreras bg.h y lcd.h para poder visualizar mensajes enviados a travs del bus CAN haciendo uso de la barra de LEDs y visualizndolos en la pantalla LCD y el puerto RS-232 tanto en el programa de transmisin como el de recepcin de tramas.

160

En primer lugar se ver la utilizacin en un programa encargado de transmitir mensajes que se mostrar en el panel LCD y el puerto RS-232 con identificador estndar que parte con el valor hexadecimal 0x0001 y se ir incrementando cada vez que se enva 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 ms significativo con el valor hexadecimal 0x11 cada vez que se presiona el botn de interrupcin INT1. Mientras que en segundo lugar el receptor ser capaz de mostrar cualquier mensaje de datos con identificador estndar que se transmita por el bus CAN, en el panel LCD y el puerto RS-232. Adicionalmente cada vez que se presiona el botn de interrupcin INT1 se mostrar el ltimo mensaje recibido por el bus CAN en el puerto RS-232, la secuencia de los primeros 8 mensajes que mostrar el panel LCD tanto el transmisor como el receptor se muestra en la Figura 5.17.

Figura 5.17.- Serie de datos mostrados en el panel LCD

161

Los programas de los que se habla anteriormente se encuentran en los proyectos can_gen.uv2 y can_mon.uv2, finalmente la estructura (Figura 5.14) y montaje (Figura 5.16) es el mismo que el del Laboratorio n2.1.

5.3.- ESTUDIO DE APLICACIONES GATILLADAS EN EL TIEMPO

El propsito 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 cmo construir una aplicacin basada en el tiempo para sistemas empotrados. Mostrar la implementacin 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 mostrarn el uso de: Los proyectos de la barra de LEDs, la pantalla LCD, el puerto RS-232, el envo secuencial y recepcin 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 replicacin de datos.

162

5.3.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE

Para la puesta en funcionamiento del kit de desarrollo es necesario contar con herramientas de software y de hardware que se enumerarn a continuacin:
Tabla 5.11.- Requerimientos de software y de hardware para el laboratorio n3 Requerimientos Herramientas Entorno de desarrollo integrado: Keil C51 Herramienta de programacin del sistema: Atmel FLIP Cdigo de fuente de los programas display, bargraph, rs232, can_gen, can_mon, can_tst y can_log Programas compilados en formato hexadecimal display.hex, bargraph.hex, rs232.hex, can_gen.hex, can_mon.hex, can_tst.hex y can_log.hex Dos kits de desarrollo CAN adems de sus respectivos microcontroladores del tipo T89C51CC01UA-SLSIM Un Cable Serie RS-232 DB9/DB9 (Macho/Hembra) para la comunicacin entre el kit de desarrollo y el computador Un Cable Serie RS-232 DB9/DB9 (Macho/Macho) para la comunicacin entre ambos kits de desarrollo

Requerimientos de Software

Requerimientos de Hardware

5.3.2.- ESTRUCTURA DE APLICACIONES GATILLADAS EN EL TIEMPO

En estos laboratorios se describir la creacin de aplicaciones gatilladas en el tiempo. La creacin de una aplicacin gatillada en el tiempo se hace a travs 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 peridica o (de forma menos frecuente) la llamada a una sola tarea. Desde el punto de vista de niveles ms bajos, un itinerario de tareas puede ser visto como una sencilla temporizacin usando interrupciones mediante un reloj para generar rutinas que pueden ser compartidas entre diferentes tareas, como resultado un solo reloj debe ser iniciado para ejecutar una, diez o cien tareas diferentes, la estructura de un programa que hace uso de itinerarios se puede ver en la Figura 5.18 y Figura 5.19.

163

/****************************************************************************** * FILE_NAME: main.c * *-----------------------------------------------------------------------------* * FILE_PURPOSE: This file is a schedule program example. * ******************************************************************************/ #include "config.h" #include "schedule.h" void timer1_init(void) { TMOD |= 0x10; /* TH1 = 0xF8; /* TL1 = 0x52; /* ET1 = 1; /* TR1 = 1; /* }

timer 1 in mode 1, 16 bit mode */ reload value for */ timer 1 at 2ms */ enable timer 1 interrupt */ turn on timer 1 */

void main(void) /* main code */ { timer1_init(); /* timer 1 initialisation */ schedule_init(); /* schedule initialisation */ EA = 1; /* enable all interrupts */ while(1) /* start of endless loop */ { schedule(); /* schedule task */ } } void fct_timer1_it(void) interrupt 3 { TH1 = 0xF8; /* reload value for */ TL1 = 0x52; /* timer 1 at 2ms */ TF1 = 0; /* clear interrupt flag */ activate_new_schedul(); /* create new schedule */ }

Figura 5.18.- Estructura general del programa principal escrito en C para aplicaciones gatilladas en el tiempo

164

/****************************************************************************** * FILE_NAME: schedule.c * *-----------------------------------------------------------------------------* * FILE_PURPOSE: This file is a schedule tasking example. * ******************************************************************************/ #include #include #include #include #include "config.h" "schedule.h" "task_1.h" "task_2.h" "task_3.h"

Uchar task_in_progress; void call_next_task(void) { EA = 0; /* disable all interrupts */ task_in_progress++; /* assign next task */ EA = 1; /* enable all interrupts */ } void schedule_init(void) { task_1_init(); task_2_init(); task_3_init(); task_in_progress = 1; }

/* /* /* /*

task 1 task 2 task 3 assign

initialisation */ initialisation */ initialisation */ first task */

void schedule(void) { switch(task_in_progress) { case 1: { task_1(); call_next_task(); break; } case 2: { task_2(); call_next_task(); break; } case 3: { task_3(); call_next_task(); break; } default: { break; } } }

/* task 1 */ /* call next task */ /* break */

/* task 2 */ /* call next task */ /* break */

/* task 3 */ /* call next task */ /* break */

/* break */

165

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

Figura 5.19.- Estructura general del itinerario de tareas escrito en C para aplicaciones gatilladas en el tiempo

5.3.3.- LABORATORIO N3.1

En esta primera serie de laboratorios se mostrar al alumno una variacin de los proyectos de la barra de LEDs, la pantalla LCD y el puerto RS-232 programados como aplicaciones gatilladas en el tiempo, los proyectos son bargraph.uv2, display.uv2 y rs232.uv2 y la estructura de los programas de muestran en la Figura 5.20.

166

a) Proyecto bargraph

b) Proyecto display

c) Proyecto rs232 Figura 5.20.- Estructura de los proyectos bargraph, display y rs232

167

5.3.4.- LABORATORIO N3.2

En la segunda serie de laboratorios se mostrar al alumno una variacin de los proyectos de transmisin y recepcin 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 estndar que se ir incrementando cada vez que se enva un mensaje, la trama de datos consiste en 8 bytes los cuales se irn rotando e el byte ms significativo cada 2 segundos, adems el cada vez que se presione el botn de interrupcin INT1 se enviar instantneamente 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 estndar que se transmita por el bus CAN en el panel LCD y el puerto RS-232, adicionalmente cada vez que se presiona el botn de interrupcin INT1 se mostrar el ltimo mensaje recibido por el bus CAN en el puerto RS-232.

168

Figura 5.21.- Estructura de los proyectos can_tx y can_rx

5.3.5.- LABORATORIO N3.3

En la tercera serie de laboratorios se mostrar al alumno proyectos de transmisin y recepcin de mensajes CAN actuando como generador de mensajes de prueba y de adquisicin 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 utilizacin en un programa encargado de transmitir 8 tipos de mensajes secuenciales con identificadores estndar y extendidos y se ir incrementando cada vez que se enva un mensaje, se

169

enviarn tramas remotas y de datos el que ser variable adems de ir rotando e incrementando el byte ms significativo cada 2 segundos, el cambio del tipo de mensaje se har cada vez que se presiona el botn de interrupcin INT1; por otro lado tambin ser capaz de recibir mensajes e ir generando la misma secuencia de mensajes anteriormente descrita segn el ltimo tipo de mensaje recibido. Mientras que en segundo lugar, el segundo programa ser capaz de mostrar cualquier mensaje ya sea con identificador estndar 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 botn de interrupcin INT1 se mostrar el ltimo mensaje recibido por el bus CAN en el puerto RS-232. Para la visualizacin de mensajes enviados/recibidos por el bus CAN, se puede conectar el puerto RS-232 del kit de desarrollo al puerto de comunicaciones serie de un computador y configurarse como 9600-8-N-1-N, el montaje utilizado se muestra en la Figura 5.22.

170

Figura 5.22.- Conexin entre el PC y el kit de desarrollo CAN para visualizar los mensajes de los nodos trasmisores/receptores mediante RS-232

5.4.- IMPLEMENTACIN DE APLICACIONES QUE HAGAN USO DEL MODELO DE COMUNICACIN CAN
El propsito 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 comunicacin est basado en el modelo productor/consumidor, admite los modelos de control multimaestro, maestro/esclavo, punto a punto, etc el cual permite la

171

transmisin de mensajes mediantes diferentes mtodos tales como sondeo, muestreo, produccin cclica y cambio de estado. En primera instancia se ejemplificar un control gatillado por eventos en un esquema de comunicacin multimaestro y en segundo lugar un control cclico en un esquema de comunicacin maestro/esclavo tomando nfasis en la programacin orientada a la creacin de aplicaciones de control en donde se visualizarn las funciones de: Sensor/Actuador (Esclavo). Controlador (Maestro). Se explicar la funcin que cumple los distintos tipos de mensajes en el bus CAN para cada modelo de comunicacin implementado emulando una red de control.

5.4.1.- REQUERIMIENTOS DE SOFTWARE Y DE HARDWARE

Para la puesta en funcionamiento del kit de desarrollo es necesario contar con herramientas de software y de hardware que se enumerarn a continuacin:

172

Tabla 5.12.- Requerimientos de software y de hardware para el laboratorio n4 Requerimientos Herramientas Entorno de desarrollo integrado: Keil C51 Herramienta de programacin del sistema: Atmel FLIP Cdigo de fuente de los programas can_trn_n1, can_trn_n2, can_air_mst y can_air_slv Programas compilados en formato hexadecimal can_trn_n1.hex, can_trn_n2.hex, can_air_mst.hex y can_air_slv.hex Dos kits de desarrollo CAN adems de sus respectivos microcontroladores del tipo T89C51CC01UA-SLSIM Un Cable Serie RS-232 DB9/DB9 (Macho/Hembra) para la comunicacin entre el kit de desarrollo y el computador Un Cable Serie RS-232 DB9/DB9 (Macho/Macho) para la comunicacin entre ambos kits de desarrollo

Requerimientos de Software

Requerimientos de Hardware

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: Mltiples nodos pueden consumir los mismos datos simultneamente desde un slo productor. Los nodos se pueden sincronizar fcilmente para obtener un rendimiento ms preciso del sistema. Los dispositivos se pueden comunicar autnomamente, sin la necesidad de un maestro de sistema. La versatilidad que permite ste modelo de comunicacin se puede apreciar en la Figura 5.23, la cual muestra un resumen de su flexibilidad y prestaciones.

173

Figura 5.23.- Resumen de la flexibilidad del modelo productor/consumidor

Tambin ste modelo permite implementar el modelo cliente/servidor, tomando en consideracin 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 continuacin, se muestra en la Figura 5.25.

174

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

5.4.4.- LABORATORIO N4.1

En este laboratorio se ver el funcionamiento de un sistema de control por cambio de estado, utilizando un modelo de comunicacin productor/consumidor y una jerarqua multimaestro ejemplificado en un sistema de control de poleas de una cinta transportadora. Cada nodo ser considerado como una estacin de tambores motrices de la cinta transportadora en donde cada nodo podr gatillar la direccin y estado (ON/OFF) de la cadena de correas transportadoras, las consideraciones a tomar sern las siguientes:

175

Al iniciar la secuencia de encendido el estado de cada uno de los nodos ser de espera (standby). Cada nodo ser capaz de iniciar el arranque del sistema de correas transportadoras. Al desconectarse un nodo de la energa elctrica y posteriormente volver a conectarse, la secuencia de inicio deber considerar preguntar al sistema el estado de funcionamiento (direccin y estado) para ser capaz de replicar su estado de funcionamiento.

El direccionamiento de los nodos debido a que la informacin 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 informacin hasta que se

modifica el estado de las variables se le conoce como control por cambio de estado y el hecho de que sea capaz de generar tareas de control en el sistema y por ende cada nodo puede actuar como: sensor, actuador y controlador se conoce como un direccionamiento multimaestro.

5.4.5.- LABORATORIO N4.2

En este laboratorio se ver el funcionamiento de un sistema de control cclico, utilizando un modelo de comunicacin cliente/servidor y una jerarqua 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 sern las siguientes: La estacin maestra podr ejercer un control de temperatura para das

176

soleados y das nublados y ser capaz de identificar cada estacin que entrega el estado de la condicin ambiental y temperatura de la planta. Cada estacin esclava deber enviar en intervalos peridicos el estado de la temperatura de la planta y de control ejercido sobre ste. El direccionamiento de los nodos debido a que la informacin 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 debern ser capaces de diferenciar entre lo que es informacin de control y datos. El hecho de que cada nodo no transmita informacin a la red en intervalos de tiempo fijo se le conoce como control cclico y el hecho de que una estacin funcione como controlador y sea capaz de generar tareas de control en el sistema y las dems estaciones ejecuten acciones de sensor y actuador en el sistema se conoce como un direccionamiento maestro/esclavo.

177

CAPTULO 6.- CONCLUSIONES

En base a la bibliografa consultada, se logr comprender los fundamentos del protocolo CAN y sus caractersticas, como resultado de esto se present un diseo de experiencias de laboratorio utilizando un kit de desarrollo, permitiendo al alumno entender los aspectos ms relevantes del bus CAN y hacerse una idea de la implementacin de los distintos modelos de control en torno a este estndar. La eleccin del set de experiencias de laboratorio no solamente ayuda al aprendizaje del bus CAN, sino que adems, 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, adems se debe considerar que en todo sistema de control se debe asignar un direccionamiento para la comunicacin entre los nodos, entre otros aspectos relevantes. Por otro lado, desde el punto de vista del diseo y programacin de sistemas empotrados, nos permite justificar y discutir los aspectos relacionados con la creacin de aplicaciones para microcontroladores, as como, dejar en evidencia la importancia del diseo 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 programacin C, el cual corresponde al lenguaje ms ampliamente difundido para crear aplicaciones en microcontroladores, se aade adems, el entendimiento de rutinas que hagan

178

uso de distintas filosofas de programacin as como la importancia del uso de interrupciones para facilitar la ejecucin paralela de distintas tareas a la vez. Finalmente, como trabajo futuro se pueden considerar el reforzar los conocimientos de los distintos estndares existentes en torno a la capa de aplicacin que utilizan como base el protocolo CAN, as como tambin, buscar potenciales aplicaciones para este kit de desarrollo, las cuales podran incluir: crear herramientas de diagnstico del bus, crear interfaces para la interpretacin de datos de un sistema, generar rutinas de fiabilidad de un sistema, o generar un sistema de control que cumpla con alguno de los estndares de la capa aplicacin basados en el protocolo CAN.

179

GLOSARIO
ACK ADC ANSI API ASCII AS-Interface CAL CAN CiA CIP CMS CPU CRC CSMA/CA CSMA/CD CSMA/NBA CTRL DBT DCE DLC DLL DP DS DTE ECU Acknowledge Analog-to-Digital Converter American National Standards Institute Application Program Interface American Standard Code for Information Interchange Actuator Sensor-Interface CAN Application Layer Controller Area Network CAN in Automation Control and Information Protocol CAN based Message Specification Central Processing Unit Cyclic Redundancy Check Carrier Sense Multiple Access with Collision Avoidance Carrier Sense Multiple Access with Collision Detection Carrier Sense Multiple Access with Non-destructive Bitwise Arbitration Control Identifier Distributor Data Communication Equipment Data Length Code Data Link Layer Decentralized Periphery Draft Standard Data Terminal Equipment Electronic Control Unit

180

EDS EEPROM EIA EN EOF EWC FLIP GND HART HLP ISP ISR I/O ID IDE IEC LCD LED LLC LME LMT LSDU MAC MAP MCU MDI MODEM NMT

Electronic Data Sheet Electrically Erasable Programmable Read Only Memory Electronic Industries Alliance Europenne Norme End of Frame Event and Waveform Controller Flexible In-System Programmer Ground Highway Addressable Remote Transducer High Layer Protocol In-System Programming Interrupt Service Routine Input/Output Identifier Identifier Extension / Integrated Development Environment International Electrotechnical Commission Liquid Crystal Display Light-Emitting Diode Logical Link Control Layer Management Entity Layer Management Link Service Data Units Medium Access Control Manufacturing Automation Protocol Microcontroller Unit Medium Dependent Interfaz Modulator-Demodulator Network Management

181

NRZ OD ODVA OOK OS OSEK OSI PC PCA PDO PHY PLCC PLL PLS PMA PROFIBUS RAM REC RJW RS RTR SAE SDO SDS SFR SJW SOF

Non-Return to Zero Object Dictionary Open DeviceNet Vendor Association On-Off Keying Operating System Offene Systeme und deren schnittstellen fr die Elektronik im Kraftfahrzeug Open System Interconnection Personal Computer Programmable Counter Array Process Data Object Physical Layer Plastic Leaded Chip Carrier Phase Locked Loop Physical Signalling Physical Medium Attachment Process Field Bus Random Access Memory Receive Error Counter Re-synchronization Jump Width Recommended Standard Remote Transmission Request Society of Automotive Engineers Service Data Object Smart Distributed System Special Function Registers Synchronization Jump Width Start of Frame

182

SRR TEC TTCAN TTL UART USB VDX

Substitute Remote Request Transmit Error Counter Time Triggered CAN Transistor-Transistor Logic Universal Asynchronous Receiver/Transmitter Universal Serial Bus Vehicle Distributed eXecutive

183

BIBLIOGRAFA

[1] Atmel Corporation, AT89C51CC01 Datasheet Enhanced 8-bit MCU with CAN Controller and Flash Memory, San Jos, 2008. [2] Atmel Corporation, Atmel C51 Hardware Manual, San Jos, 2004. [3] Atmel Corporation, C51 Microcontrollers Demo Board, San Jos, 2002. [4] Atmel Corporation, CAN Demoboard User Guide, San Jos, 2003. [5] Atmel Corporation, Using Keil FlashMon Emulator with AT89C51CC01/03, San Jos, 2006. [6] K. Ayala, The 8051 Microcontroller, Jackson County: West Publishing, 1991. [7] M. Beach y C. Hills, The C51 Primer, Staffordshire: Phaedrus Systems, 2006. [8] D. Calcutt, F. Cowan y H. Parchizadeh, 8051 Microcontrollers, Oxford: Newnes, 2004. [9] J. Q. Castellano, Bus CAN: Estado de Buses Industriales y Aplicaciones, Madrid, 2000. [10] S. Cavalieri, A. Di Stefano y O. Mirabella, Centralized versus distributed protocols for FieldBus applications, Cantania, 1995.

184

[11] C. A. Cham Morales, Desarrollo de un Sistema Educativo para la Enseanza del Protocolo de Comunicaciones CAN, Huajuapan de Len, 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. Fernndez de Dios, Foundation Fieldbus y su adaptacin a la alta velocidad: HSE, Vigo, 2005. [15] J. P. Ferrari, Sistemas de Control Distribuido, Rosario, 2005. [16] I. M. Gmez Gonzlez, Anlisis y Diseo de Protocolos de Acceso al Medio para el Control de Redes Elctricas, Sevilla, 1995. [17] R. C. Guevara Calume, Maestra en Automatizacin y Control Industrial, Medelln, 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., Anlisis de la Capa Fsica del Bus de Campo CAN, Santiago, 2004. [21] H. Kaschel C. y E. Pinto L., Anlisis del Estado del Arte de los Buses de Campo Aplicados al Control de Procesos Industriales, Santiago, 2002.

185

[22] H. Kaschel C. y E. Pinto L., Anlisis Protocolar del Bus de Campo CAN, Santiago, 2002. [23] H. Kaschel C. y E. Pinto L., Implementacin de la Capa Fsica del Bus de Campo CAN, Santiago, 2004. [24] H. Kaschel C. y E. Pinto L., Sistema de Diagnstico y Sincronizacin 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, Anlisis del Protocolo CAN (Controller Area Network) e Implementacin de un Prototipo de Control de Nodos Interconectados por un Bus de Comunicaciones CAN, Quito, 2008. [30] M. Molero Bastante, Bus CAN Diseo de Sistemas Crticos, 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, Crdoba, 2008.

186

[32] J. Parab, V. Shelake, R. Kamat y G. Naik, Exploring C For Microcontrollers 8051, Dordrecht: Springer, 2007. [33] M. Pont, Embedded C, London: Addison-Wesley, 2002. [34] M. Pont, Patterns for Time-Triggered Embedded Systems, London: Addison-Wesley, 2011. [35] M. Pont, Programming Embedded System I, Leicester: University of Leicester, 2006. [36] M. Pont, Programming Embedded System II, Leicester: University of Leicester, 2007. [37] A. Rosado, Sistemas Industriales Distribuidos: Tema 2, Valencia, 2003. [38] Samson, Foundation Fieldbus: Part 4, Frankfurt, 2003. [39] J. Snchez Pearroja, 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 Muoz, Tutorial de Fieldbus, Lima, 1998.

187

ANEXOS

188

ANEXO A: GUAS DE LABORATORIO

189

EXPERIENCIA N1:
REFERENCIAS PARA LA UTILIZACIN DEL KIT DE DESARROLLO CAN
OBJETIVOS: El propsito de este laboratorio es describir los componentes de software y de hardware necesarios para la utilizacin del kit de desarrollo CAN. INTRODUCCIN: Para familiarizar al alumno con el kit de desarrollo y las herramientas de trabajo, se analizarn los componentes de software y de hardware con los que se trabajar posteriormente adems de la configuracin del kit para la puesta en funcionamiento. DESCRIPCIN DEL HARDWARE: Cada kit de desarrollo incluye dos placas: una tarjeta de demostracin C51 (C51 Demo Board) y una tarjeta de extensin 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, segn el posicionamiento de los interruptores: J9, J11 y J16, saltar la ejecucin del programa principal para ejecutar el gestor de arranque y realizar tareas de programacin en el microcontrolador (modo Gestor de Arranque) o, en sentido contrario, saltar la ejecucin del gestor de arranque para ejecutar la aplicacin principal (modo Aplicacin de Usuario). 190

a) Condicin de hardware configurado para arrancar en modo Gestor de Arranque

b) Condicin de hardware configurado para arrancar en modo Aplicacin de Usuario

DESCRIPCIN DEL SOFTWARE: Para poder utilizar el kit de desarrollo de precisan principalmente de 2 programas: Entorno de desarrollo integrado. Herramienta de programacin del sistema.

Un entorno de desarrollo integrado o IDE (Integrated Development Environment), es un programa informtico compuesto por un conjunto de herramientas de programacin consistente en un editor de cdigo, un compilador y un depurador. El entorno de desarrollo que se utilizar en los siguientes apartados corresponde a las herramientas de desarrollo de la compaa Keil para los microcontroladores Intel 8051 llamado Keil C51 Development Tools, el cual permite la programacin de aplicaciones escritas en lenguaje C y Assembly. La herramienta de programacin del sistema es llamado por la compaa Atmel como FLIP (FLexible In-system Programmer), es un software que se ejecuta en el computador y sirve para la programacin de microcontroladores de dicha compaa. sta herramienta puede programar dispositivos dentro del sistema (ISP: In-System Programming) a travs de UART, USB y CAN. El tipo de programacin que se utilizar para los proyectos ser por medio del puerto RS-232 (UART) y la interconexin al PC ser la siguiente:

191

CUESTIONARIO: Las preguntas siguientes deben ser respondidas por el alumno; ya que, ms de alguna ser formulada antes de la experiencia. 1.- Explique las caractersticas y diferencias entre las arquitecturas von Neumann y Harvard. 2.- Entregue la distribucin de pines del microcontrolador Atmel T89C51CC01 y los tipos de interrupciones que pueden gatillarse en el microcontrolador Atmel T89C51CC01 junto con su numeracin. 3.- Describa brevemente los siguientes componentes de hardware del kit de desarrollo CAN: microcontrolador, conectores de energa, reloj del sistema, interruptor de encendido/apagado, botn de reinicio, botn de interrupcin, 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 continuacin: 1.- Interconectar la tarjeta de demostracin C51 (C51 Demo Board) con la tarjeta de extensin CAN (CAN Extension Board). 2.- Energizar la tarjeta de demostracin C51 conectando el suministro de energa de 9V. 3.- Conectar el puerto RS-232 de la tarjeta de demostracin C51 al puerto de comunicaciones COM del PC mediante un cable RS-232 Macho/Hembra. 4.- Asegurarse que el microcontrolador T89C51CC01UA-SLIM est 192

conectado al zcalo PLCC44 de la tarjeta de extensin CAN. En segundo lugar veremos los pasos necesarios para utilizar el software de programacin FLIP y verificar que se han establecido correctamente los parmetros necesarios para poder programar la tarjeta de demostracin: 1.- En primer lugar ejecutar el programa FLIP. 2.- Dirjase al men desplegable Device Select seleccione el dispositivo T89C51CC01, ntese que la ventana de la aplicacin mostrar ahora la configuracin del microcontrolador. 3.- Asegrese de que el kit de desarrollo se encuentre debidamente conectado al PC con la condicin de hardware configurado para arrancar en modo Gestor de Arranque y posteriormente encienda el kit de desarrollo. 4.- A continuacin seleccione el men desplegable Settings Communication RS232, en la ventana de configuracin RS232 Setup escoja de puerto COM al cual est conectado el kit de desarrollo y configure la velocidad de transmisin con una velocidad de transmisin de 9600bps. 5.- Iniciar la comunicacin presionando el botn Connect de la ventana de configuracin RS232 Setup. 6.- En el men desplegable File Load HEX File elija la aplicacin 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 verificacin siguientes estn seleccionadas en la seccin Operations Flow del FLIP: Erase, Blank Check, Program y Verify. 8.- Deje sin verificar el cuadro de BLJB en la seccin T89C51CC01 a fin de ejecutar el programa de demostracin despus del siguiente reinicio. 9.- Presione el botn Run para que la programacin 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 asegrese de que el kit de desarrollo se encuentre con la condicin de hardware configurado para arrancar en modo Aplicacin de Usuario. 11.- Finalmente reinicie el kit de desarrollo para iniciar la aplicacin programada en el microcontrolador.

193

BIBLIOGRAFA [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. Ossandn, Diseo e Implementacin de un Sistema Educativo del Protocolo de Comunicaciones CAN, Santiago, 2011.

194

EXPERIENCIA N2:
INTRODUCCIN A LA PROGRAMACIN DE APLICACIONES PARA EL KIT DE DESARROLLO
OBJETIVOS: El propsito de este laboratorio es familiarizar al alumno con el kit de desarrollo y las herramientas necesarias para la creacin, compilacin y programacin para ste. INTRODUCCIN: Para familiarizar al alumno en la programacin 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 comunicacin asncrona. Configurar los parmetros necesarios para comunicarse a distintas velocidades mediante puerto RS-232 del microcontrolador.

CONVENCIONES DE PROGRAMACIN: En todos los proyectos que se mostrarn desde ahora en adelante har uso de un archivo de configuracin llamado config.h que estar incluido en el cdigo de fuente de todos los archivos con el fin de compartir las configuraciones en todos los proyectos, tal como se muestra a continuacin:

195

/****************************************************************************** * FILE_NAME: config.h * *-----------------------------------------------------------------------------* * FILE_PURPOSE: This file is included by all source files in order to access * * to system wide configuration * ******************************************************************************/ #ifndef _CONFIG_H_ #define _CONFIG_H_ #include <t89c51cc01.h> #include "compiler.h" #endif /* _CONFIG_H_ */

ste archivo hace a su vez la inclusin de los archivos t89c51cc01.h y compiler.h. El archivo t89c51cc01.h aade 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 adems de definir nombres para tipos de datos que hagan ms fcil el declarar variables y parmetros (tambin llamados alias). ESTRUCTURA DE UN PROGRAMA: La estructura de un programa escrito en C para un microcontrolador es bsicamente la misma estructura de un programa estndar en C con algunos cambios menores, cuya estructura tpica se muestra a continuacin:

196

/****************************************************************************** * FILE_NAME: main.c * *-----------------------------------------------------------------------------* * This is the program header. Describe your program here briefly * ******************************************************************************/ /* include your headers here */ #include "config.h" /* include your variable declarations here */ bit Uchar Uint16 var_1; var_2; var_3;

/* include your functions here */ void func_1(void) { /* body of function */ } /* include your main code here */ void main(void) /* main code */ { /* initialisation of variables */ while(1) /* start of endless loop */ { /* body of loop */ }

RUTINAS DE INTERRUPCIN: El compilador C51 permite declarar rutinas de interrupcin en el cdigo C para que el programa se dirija automticamente a ese cdigo cuando se produzca una interrupcin, genera automticamente los vectores de interrupcin adems del cdigo para entrar y salir de las rutinas de interrupcin. El esquema de las rutinas de interrupcin es similar a la declaracin de funciones con la salvedad que el nmero de interrupcin debe declararse como parte de la funcin, tal como se muestra a continuacin:
void fct_timer1_it(void) interrupt 3 { /* interrupt service goes here */ }

197

CUESTIONARIO: Las preguntas siguientes deben ser respondidas por el alumno; ya que, ms de alguna ser formulada antes de la experiencia. 1.- Explique la importancia de las comunicaciones asncronas y los principales beneficios de ste tipo de comunicacin. 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, adems de las caractersticas de: velocidad de transmisin, bits de datos, paridad, bits de parada y control de flujo.

PARTE EXPERIMENTAL: Este laboratorio consta de utilizar las libreras creadas especficamente para hacer uso de los componentes de hardware implementados en el kit de desarrollo, se entregar al alumno 3 programas escritos en C que mostrarn el uso de: La barra de LEDs. 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 segn las ecuaciones que se muestran a continuacin:

198

Clculo de recarga para el Timer 0/1 TH0/TH1 = 256 2SMOD FOSC 384 Baud Rate

Baud Rate =

2SMOD FOSC 2 32 [256 TH0/TH1]

Baud Rate =

(RCAP2H, RCAP2L) = 65536

Clculo de recarga para el Timer 2

2SMOD FOSC 32 [65536 (RCAP2H, RCAP2L)]

2SMOD FOSC 32 Baud Rate

obtenga los valores de recarga de los registros TH0/TH1 o RCAP2H y RCAP2L segn sea el caso para obtener las distintas velocidades de transmisin entregadas a continuacin:
Velocidad de transmisin [bps] 57600 38400 19200 14400 9600 4800 2400 1200 Temporizador Timer 2 Timer 2 Timer 2 Timer 2 Timer 2 Timer 0/1 Timer 0/1 Timer 0/1

Para la visualizacin de mensajes entregados por el microcontrolador a travs 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 estndar 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 transmisin est dada por la configuracin especificada en el microcontrolador.

199

BIBLIOGRAFA [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. Ossandn, Diseo e Implementacin de un Sistema Educativo del Protocolo de Comunicaciones CAN, Santiago, 2011. [9] J. Parab, V. Shelake, R. Kamat y G. Naik, Exploring C For Microcontrollers 8051, Dordrecht: Springer, 2007. [10] M. Pont, Embedded C, London: Addison-Wesley, 2002. [11] M. Pont, Programming Embedded System I, Leicester: University of Leicester, 2006.

200

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

201

EXPERIENCIA N3:
ESTUDIO DE LA CAPA FSICA Y DE ENLACE DE DATOS DEL PROTOCOLO CAN
OBJETIVOS: El propsito de este laboratorio es familiarizar al alumno con el estudio de la capa fsica y de enlace de datos del protocolo CAN haciendo uso del kit de desarrollo. INTRODUCCIN: Para familiarizar al alumno con el estudio de la capa fsica y de enlace de datos del protocolo CAN es necesario abarcar los siguientes aspectos: Explicar cmo crear un nodo para generar transmisin y recepcin de mensajes utilizando las libreras entregadas por el fabricante. Mostrar la estructura general de una trama CAN, campos de:
SOF (inicio de trama) Identificador (estndar o extendido) Control (tipo de trama y nmero de bytes de datos) Datos (mensaje de hasta 8 bytes) CRC (deteccin de errores) ACK (acuse de recibo) EOF (fin de trama)

Detallar la configuracin de los registros necesarios para obtener comunicaciones a distintas velocidades. TRANSMISIN DE MENSAJES CAN: En primer lugar se ver la utilizacin en un programa encargado de transmitir mensajes, a modo de ejemplo se muestra a continuacin un programa que enva mensajes con un identificador estndar 0x123 y 8 bytes de datos {0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88} a una velocidad de 500Kbps cada 250ms.

202

/****************************************************************************** * FILE_NAME: main.c * *-----------------------------------------------------------------------------* * FILE_PURPOSE: This file is a simple CAN transmission sample software * ******************************************************************************/ #include "config.h" #include "can_lib.h" Uint16 i; can_data_t xdata data_tx = {0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88}; can_msg_t xdata msg_tx = {STD_ID(0x0123), CONF_NOIDE | CONF_NORTR | CONF_DLC_8, data_tx}; void delay(Uint16 tempo) { for(i=0; i<tempo; i++); } void can_init(void) { CAN_CONTROLLER_RESET; ClearAllMailbox(); CanSetBRP(BRP_500k); CanSetSJW(SJW_500k); CanSetPRS(PRS_500k); CanSetPHS1(PHS1_500k); CanSetPHS2(PHS2_500k); CAN_CONTROLLER_ENABLE; CAN_IT_ENABLE; CAN_TX_IT_ENABLE; }

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

reset can controller */ clear all ram of can controller */ configure can baud rate prescaler*/ configure can re-synchronization jump width */ configure can propagation time segment */ configure can phase segment 1 */ configure can phase segment 2 */ enable can controller */ enable can interrupts */ enable can transmission interrupt */

void can_fct_it_txok(void) { channel = CAN_GET_CHANNEL; /* get interrupted channel */ CAN_CHANNEL_IT_DISABLE(channel); /* disable interrupt on channel */ } void main(void) { can_init(); /* can initialisation */ EA = 1; /* enable all interrupts while(1) /* start of endless loop */ { delay(0xC350); /* can_tx_id = msg_tx.id; /* conf_tx = msg_tx.ctrl; /* pt_candata_tx = msg_tx.pt_data; /* CAN_SET_CHANNEL(CHANNEL_0); /* CAN_CHANNEL_IT_ENABLE(CHANNEL_0); /* SendCanMsg(); /* } }

*/ delay for approx. 250ms */ message identifier */ message configuration */ message data pointer */ select message channel */ enable interrupt on channel */ send message */

203

RECEPCIN DE MENSAJES CAN: En segundo lugar se ver la utilizacin en un programa encargado de recibir mensajes, a modo de ejemplo se muestra a continuacin un programa que slo recibe mensajes con identificadores estndar que comienzan con 0x012X a una velocidad de 500kbps.
/****************************************************************************** * FILE_NAME: main.c * *-----------------------------------------------------------------------------* * FILE_PURPOSE: This file is a simple CAN reception sample software * ******************************************************************************/ #include "config.h" #include "can_lib.h" can_data_t xdata data_rx = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; can_msg_t xdata msg_rx = {STD_ID(0x00, 0x00, data_rx}; void can_init(void) { CAN_CONTROLLER_RESET; /* reset can controller */ ClearAllMailbox(); /* clear all ram of can controller */ CanSetBRP(BRP_500k); /* configure can baud rate prescaler*/ CanSetSJW(SJW_500k); /* configure can re-synchronization jump width */ CanSetPRS(PRS_500k); /* configure can propagation time segment */ CanSetPHS1(PHS1_500k); /* configure can phase segment 1 */ CanSetPHS2(PHS2_500k); /* configure can phase segment 2 */ can_rx_filt.std = 0x012F; /* accept only identifier */ can_rx_msk.std = 0x0120; /* start by 0x012X */ conf_rx = CONF_NOIDE|CONF_MSK_IDE; /* accept only standard identifier */ CAN_SET_CHANNEL(CHANNEL_0); /* select message channel */ CAN_CHANNEL_IT_ENABLE(CHANNEL_0); /* enable interrupt on channel */ ConfChannel_Rx(); /* configure channel for reception */ CAN_CONTROLLER_ENABLE; /* enable can controller */ CAN_IT_ENABLE; /* enable can interrupts */ CAN_RX_IT_ENABLE; /* enable can reception interrupt */ } void can_fct_it_rxok(void) { pt_st_can_rx = &msg_rx; ReadCanMsg(CHANNEL_RX_ENABLE); }

/* message data struct pointer */ /* read message and configure channel */

void main(void) { can_init(); /* can initialisation */ EA = 1; /* enable all interrupts */ while(1); /* start of endless loop */ }

204

CUESTIONARIO: Las preguntas siguientes deben ser respondidas por el alumno; ya que, ms de alguna ser formulada antes de la experiencia. 1.- Investigue los niveles de voltaje e impedancia que maneja el protocolo CAN, segn los siguientes estndares: 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 codificacin de lnea en el protocolo CAN e indique que tipo de mensajes tienen prioridad por sobre otros: identificador estndar 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 libreras CAN entregadas por el fabricante para la programacin del kit de desarrollo, se entregar al alumno 4 programas escritos en C que mostrarn el uso de: Envo y recepcin de distintos mensajes CAN (tramas de datos y remotas) a distintas velocidades. Rutinas de envo secuencial y recepcin de mensajes CAN, mostrados en la barra de LEDs, 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 transmisin para el bus CAN utilizando el programa X-Calculator disponible en la pgina del fabricante, las velocidades a configurar por el alumno sern las mostradas en la siguiente tabla:
Velocidad de transmisin [kbps] 500 250 100 Sample Point [%] 80 a 90 80 a 90 80 a 90

Como tarea adicional el alumno deber generar las configuraciones para el nodo transmisor indicadas a continuacin:

205

Canal 0 1 2 3 4 5

Identificador STD: 0123 STD: 0011 STD: 0321 EXT: 01234567 EXT: 00110022 EXT: 07654321

Trama Datos Datos Remota Datos Datos Remota

DLC 8 bytes 4 bytes 6 bytes 8 bytes 4 bytes 6 bytes

Datos 11, 22, 33, 44, 55, 66, 77, 88 12, 34, 56, 78 11, 22, 33, 44, 55, 66, 77, 88 12, 34, 56, 78 -

y las siguientes configuraciones para el nodo receptor:

Canal 0 1 2 3 4 5 Filtro de Identificador STD: 012X STD: 001X STD: 032X EXT: 012345XX EXT: 001100XX EXT: 076543XX Filtro de Trama Datos y Remota Datos Remota Datos y Remota Datos Remota

Para visualizar los mensajes los mensajes de los nodos trasmisor y receptor mediante RS-232, el montaje de la conexin entre el PC y el kit de desarrollo CAN es el siguiente:

206

BIBLIOGRAFA [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 Enseanza del Protocolo de Comunicaciones CAN, Huajuapan de Len, 2005. [3] H. Kaschel C. y E. Pinto L., Anlisis de la Capa Fsica del Bus de Campo CAN, Santiago, 2004. [4] H. Kaschel C. y E. Pinto L., Anlisis Protocolar del Bus de Campo CAN, Santiago, 2002. [5] H. Kaschel C. y E. Pinto L., Implementacin de la Capa Fsica del Bus de Campo CAN, Santiago, 2004. [6] H. Kaschel C. y E. Pinto L., Sistema de Diagnstico y Sincronizacin de los Buses de Campo CAN, Santiago, 2002. [7] M. T. C. Medina, Anlisis del Protocolo CAN (Controller Area Network) e Implementacin de un Prototipo de Control de Nodos Interconectados por un Bus de Comunicaciones CAN, Quito, 2008. [8] M. Molero Bastante, Bus CAN Diseo de Sistemas Crticos, Ciudad Real, 2005. [9] E. Ossandn, Diseo e Implementacin de un Sistema Educativo del Protocolo de Comunicaciones CAN, Santiago, 2011. [10] J. Snchez Pearroja, Controller Area Network, Valencia, 2007.

207

EXPERIENCIA N4:
ESTUDIO DE APLICACIONES GATILLADAS EN EL TIEMPO
OBJETIVOS: El propsito de este laboratorio es familiarizar al alumno con el estudio de aplicaciones gatilladas en el tiempo para realizar tareas que requieran cierta periodicidad. INTRODUCCIN: Para familiarizar al alumno con el estudio de aplicaciones gatilladas en el tiempo es necesario abarcar los siguientes aspectos: Explicar cmo construir una aplicacin basada en el tiempo para sistemas empotrados. Mostrar la implementacin 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 creacin de una aplicacin gatillada en el tiempo se hace a travs 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 peridica o (de forma menos frecuente) la llamada a una sola tarea. Desde el punto de vista de niveles ms bajos, un itinerario de tareas puede ser visto como una sencilla temporizacin 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 continuacin:

208

/****************************************************************************** * FILE_NAME: main.c * *-----------------------------------------------------------------------------* * FILE_PURPOSE: This file is a schedule program example. * ******************************************************************************/ #include "config.h" #include "schedule.h" void timer1_init(void) { TMOD |= 0x10; /* TH1 = 0xF8; /* TL1 = 0x52; /* ET1 = 1; /* TR1 = 1; /* }

timer 1 in mode 1, 16 bit mode */ reload value for */ timer 1 at 2ms */ enable timer 1 interrupt */ turn on timer 1 */

void main(void) /* main code */ { timer1_init(); /* timer 1 initialisation */ schedule_init(); /* schedule initialisation */ EA = 1; /* enable all interrupts */ while(1) /* start of endless loop */ { schedule(); /* schedule task */ } } void fct_timer1_it(void) interrupt 3 { TH1 = 0xF8; /* reload value for */ TL1 = 0x52; /* timer 1 at 2ms */ TF1 = 0; /* clear interrupt flag */ activate_new_schedul(); /* create new schedule */ }

209

/****************************************************************************** * FILE_NAME: schedule.c * *-----------------------------------------------------------------------------* * FILE_PURPOSE: This file is a schedule tasking example. * ******************************************************************************/ #include #include #include #include #include "config.h" "schedule.h" "task_1.h" "task_2.h" "task_3.h"

Uchar task_in_progress; void call_next_task(void) { EA = 0; /* disable all interrupts */ task_in_progress++; /* assign next task */ EA = 1; /* enable all interrupts */ } void schedule_init(void) { task_1_init(); task_2_init(); task_3_init(); task_in_progress = 1; }

/* /* /* /*

task 1 task 2 task 3 assign

initialisation */ initialisation */ initialisation */ first task */

void schedule(void) { switch(task_in_progress) { case 1: { task_1(); call_next_task(); break; } case 2: { task_2(); call_next_task(); break; } case 3: { task_3(); call_next_task(); break; } default: { break; } } }

/* task 1 */ /* call next task */ /* break */

/* task 2 */ /* call next task */ /* break */

/* task 3 */ /* call next task */ /* break */

/* break */

210

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

CUESTIONARIO: Las preguntas siguientes deben ser respondidas por el alumno; ya que, ms de alguna ser formulada antes de la experiencia. 1.- Seale la importancia de la programacin de aplicaciones gatilladas en el tiempo para realizar tareas en tiempo real. 2.- Cmo podra generar una mayor prioridad a algn tipo de tarea especfica en una aplicacin que utilice la programacin gatilladas en el tiempo? 3.- Si es que necesito realizar una comunicacin serie a travs 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 mostrarn el uso de: Los proyectos de la barra de LEDs, la pantalla LCD, el puerto RS-232, el envo secuencial y recepcin 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 replicacin de datos.

En esta serie de laboratorios se mostrar al alumno proyectos de transmisin y recepcin de mensajes CAN actuando como generador de mensajes de prueba y de adquisicin 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 conexin entre el PC y el kit de desarrollo CAN es el siguiente:

211

BIBLIOGRAFA [1] E. Ossandn, Diseo e Implementacin de un Sistema Educativo del Protocolo de Comunicaciones CAN, Santiago, 2011. [2] M. Pont, Patterns for Time-Triggered Embedded Systems, London: Addison-Wesley, 2011. [3] M. Pont, Programming Embedded System II, Leicester: University of Leicester, 2007.

212

EXPERIENCIA N5:
IMPLEMENTACIN DE APLICACIONES QUE HAGAN USO DEL MODELO DE COMUNICACIN CAN
OBJETIVOS: El propsito de este laboratorio es familiarizar al alumno con las capacidades del bus CAN para implementar los distintos modelos de control que permite el protocolo. INTRODUCCIN: Existen muchas maneras de clasificar las redes: en funcin de su funcionalidad, de los protocolos utilizados, de sus prestaciones, del tipo de acceso, de su topologa, etc En nuestro caso, y para no perdernos entre las mltiples clasificaciones, veremos la clasificacin segn su modelo de comunicacin. MODELOS DE COMUNICACIONES: Resulta importante conocer los dos modelos bsicos en los que se enmarca cualquier sistema de comunicacin, estos modelos son: Cliente/Servidor: La comunicacin 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 simultnea del mismo mensaje a todos los nodos, utilizando la red de comunicaciones durante un largo periodo de tiempo. Adems, el tiempo de emisin a todos los nodos cambia segn el nmero de nodos a los que se desea hacer llegar el mensaje, el tipo de difusin utilizado es el envo 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 comunicacin 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 simultneamente y no es necesario repetirlo para cada uno de los nodos a los que est dirigido, con el consiguiente ahorro en el tiempo de utilizacin del bus. As, el tiempo de transmisin resulta constante independientemente del nmero de nodos a los que se desea hacer llegar el mensaje. En este caso, la trama del mensaje incluye un identificador de mensaje; este identificador permite que los nodos 213

receptores conozcan si deben aceptarlo o no, el tipo de difusin utilizado es el envo 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: Mltiples nodos pueden consumir los mismos datos simultneamente desde un slo productor. Los nodos se pueden sincronizar fcilmente para obtener un rendimiento ms preciso del sistema. Los dispositivos se pueden comunicar autnomamente, sin la necesidad de un maestro de sistema.

El resumen de su flexibilidad y prestaciones que permite ste modelo de comunicacin se puede apreciar en la siguiente figura:

Tambin ste modelo permite implementar el modelo cliente/servidor, tomando en consideracin que cada nodo debe identificar los campos de origen y destino en el identificador, a continuacin 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 continuacin: 214

CUESTIONARIO: Las preguntas siguientes deben ser respondidas por el alumno; ya que, ms de alguna ser formulada antes de la experiencia. 1.- Explicar cul es la funcin que cumple el filtrar los datos en el bus para la recepcin de mensajes en el modelo cliente/servidor y en el modelo productor/consumidor. 2.- Explicar la funcin que cumplen los identificadores y los datos en ambos modelos de comunicacin: cliente/servidor y productor/consumidor. 3.- Explicar las funciones de controlador, sensor y actuador en los distintos modelos de comunicacin 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 comunicacin multimaestro ejemplificado en un sistema de control de poleas de una cinta transportadora. Cada nodo ser considerado como una estacin de tambores motrices de la cinta transportadora en donde cada nodo podr gatillar la direccin y estado (ON/OFF) de la cadena de correas transportadoras, las consideraciones a tomar sern las siguientes: 215

Al iniciar la secuencia de encendido el estado de cada uno de los nodos ser de espera (standby). Cada nodo ser capaz de iniciar el arranque del sistema de correas transportadoras. Al desconectarse un nodo de la energa elctrica y posteriormente volver a conectarse, la secuencia de inicio deber considerar preguntar al sistema el estado de funcionamiento (direccin y estado) para ser capaz de replicar su estado de funcionamiento. El direccionamiento de los nodos debido a que la informacin 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 informacin 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 cclico en un esquema de comunicacin 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 sern las siguientes: La estacin maestra podr ejercer un control de temperatura para das soleados y das nublados y ser capaz de identificar cada estacin que entrega el estado de la condicin ambiental y temperatura de la planta. Cada estacin esclava deber enviar en intervalos peridicos el estado de la temperatura de la planta y de control ejercido sobre ste. El direccionamiento de los nodos debido a que la informacin 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 debern ser capaces de diferenciar entre lo que es informacin de control y datos.

El hecho de que cada nodo no transmita informacin a la red en intervalos de tiempo fijo se le conoce como control cclico y el hecho de que una estacin funcione como controlador y sea capaz de generar tareas de control en el sistema y las dems estaciones ejecuten acciones de sensor y actuador en el sistema se conoce como un direccionamiento maestro/esclavo.

216

BIBLIOGRAFA [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, Crdoba, 2008. [3] E. Ossandn, Diseo e Implementacin de un Sistema Educativo del Protocolo de Comunicaciones CAN, Santiago, 2011.

217

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

218

HOJA DE DATOS DE LA TARJETA: C51 DEMO BOARD

219

220

221

222

223

224

LISTA DE MATERIALES DE LA TARJETA: C51 DEMO BOARD

Reference
C1-C28 C2:C10-C19:C23 C11 C12 C13-C14-C24:C27 C15:C18 D1-D14 D2-D11:D13 D3:D6 D7:D8 D9:D10 J1 J2 J3 J4 J5-J10 J6:J7 J8 J9 J11 J12 J13 J14 J15 J16 J17 J18 J19 R1-R24-R28-R29 R2-R3-R20-R21-R25 R4:R11 R12-R19 R21 R23 R30 U1 U2 U3-U4-U7-U8 U5 U6 U9 U10 U12 U13 U14 U15 X1 X2

Type
POL_CAPACITOR CAPACITOR POL_CAPACITOR POL_CAPACITOR CAPACITOR POL_CAPACITOR 1N4001 LED LED_GREEN LED_YELLOW LED_RED CONNECTOR CONNECTOR_BATTERY_9V STRAP DB9_MALE DB9_FEMELLE Push_Button Switch ON-ON Commut_DIP_2 Commut_DIP_8 CONNECTOR Jumper_2,54mm LCD_2X16 ALE_DIS Commut_DIP_1 Switch ON-ON jumper Battery Switch ON-ON RESISTOR RESISTOR RESISTOR RESISTOR POTENTIOMETER RESISTOR RESISTOR LM7805C LM2936Z5 74ACT573 TSC80C31 AT49HF010-45JC ICL232CBE HEF4555P TSC80C51 TSC80C51 74ACT14 74ACT00 Quartz_11,0592 Quartz_22,1184

Specs
4,7uF 100nF 3,3uF 10uF 22pF 10uF 1N4001 LED GREEN LED YELLOW LED RED LED CONNECTOR CONN_BATTERY_9V STRAP DB9_MALE DB9_FEMELLE Push_Button Switch ON-ON Commut_DIP_2 Commut_DIP_8 CONNECTOR CONNECTOR LCD_2X16 Strap Commut_DIP_1 Switch ON-ON Picot Pile Switch ON-ON 1kOhm 10kOhm 10kOhm 1kOhm 10kOhm 100 Ohm 180 Ohm LM7805C LM2936Z5 74ACT573 Socket Socket ICL232CBE HEF4555P Socket Socket 74ACT14 74ACT00 11,0592MHz 22,1184MHz

Qty
2 14 1 1 6 4 2 4 1 1 1 1 1 0 1 2 2 1 1 1 1 1 1 0 1 1 1 4 6 2 2 1 1 1 1 1 4 1 1 1 1 1 1 1 1 1 1

Comment
CMS_TAJ_Package_B Package_0805 TAJ_CMS_Package_B TAJ_CMS_Package_B Serie_680 CMS_TAJ_Package_B Package_DO204AL CMS_STANDART in_line_2.54mm step in_line_2.54mm step in_line_2.54mm step

SUBD9Pins_Right_Angle SUBD9Pins_Right_Angle CMS

DIL DIN41612_3*32_MALE_Right_Angle 2*11 contacts NULL

Inter. ON/OFF 2 pins, step of 2,54mm Package_0603 Package_0603 Package_1206-CMS_ARC_241 Package_1206_CMS_ARC_241 SERIE_3362P 0.6W -1% 0,5W TO220 + Heater TO92 CMS PLCC44 PLCC32 CMS DIL DIL24 PLCC68 CMS CMS HC49/4H HC49/U

225

HOJA DE DATOS DE LA TARJETA: CAN EXTENSION BOARD

226

LISTA DE MATERIALES DE LA TARJETA: CAN EXTENSION BOARD

Reference
C1,C2 C3 J1 J2 R1 U1 U2 U3 X1 J12 J10

Value
22pF 100 nF 2 pin connector DB9 Female Connector 120 1/4W PLCC44 Socket DIP8 socket CAN Driver ATA6660 or compatible 12MHz Crystal DIN3*32 Female Connector Jumper Spacing 2.54 mm

Quantity
2 1 1 1 1 1 1 1 1 1 1

227