CAPÍTULO 4. PRUEBAS SOBRE EL...

4.1 PRUEBAS PRELIMINARES Las pruebas preliminares que se presentan a continuación se fueron efectuando a medida

que se iba desarrollando el hardware del sistema y sirvieron para familiarizarse con los dispositivos que integran el sistema y sentar las bases para la creación de los programas definitivos. La estrategia consistía en probar cada dispositivo por separado para luego ir uniéndolos todos.

4.1.1 PRUEBAS CON EL BUS CAN

Establecer una comunicación a través del bus CAN fue uno de los primeros objetivos. En

las primeras pruebas se utilizaron las placas PICMEO y PICMEO 2, dado que ambas poseen controladores CAN. Como sustituto del bus CAN se empleó un cable multihilo del que se aprovecharon sólo dos líneas y el cable fue terminado en sus extremos con resistencias de 120Ω. Debido a que las características del medio físico no eran óptimas, se decidió trabajar a una velocidad de transmisión media: 125 Kbit/s. Los programas utilizados en una y otra placa eran muy sencillos y se limitaban a reflejar los valores recibidos en los LEDs de las placas o simplemente a devolver lo que habían recibido. La placa PICMEO 2 funcionaba controlada por un PC a través del puerto serie utilizando el propio programa de demostración de la PICMEO 2 modificado para la ocasión. Las pruebas funcionaron correctamente.

Antes de haber implementado la placa PAEM se empezó a probar el módulo eCAN del

DSP TMS320F2812 en modo auto-test, es decir, sin estar físicamente conectado al bus CAN. En este caso, el resultado no fue el esperado ya que el módulo eCAN se comportaba de una manera muy extraña. En concreto no era capaz de utilizar las máscaras de los buzones y lo que era peor aún, si llegaba un mensaje que no debía ser recogido por ningún buzón, automáticamente lo almacenaba en el último buzón que había usado.

Una vez que se pudo disponer de la placa PAEM, que incluye un transceiver apropiado

para el DSP, se efectuaron pruebas sencillas como la que se hizo entre las dos placas PICMEO pero esta vez enfrentando al DSP con la PICMEO 2. En esta ocasión el DSP sí funcionó correctamente al no estar trabajando en modo auto-test, lo cual hace pensar que el modo auto-test no es del todo fiable, de hecho, en los ejemplos que propone Texas Instruments en su página web acerca del uso del módulo eCAN nunca se daban las situaciones que provocaban los comportamientos extraños. Aún así, es posible que el error que se detectó en la siguiente fase estuviera también detrás de esos comportamientos.

Cuando se creó el primer nodo de la red basado en el PIC18F248 se volvieron a hacer

pruebas sencillas enfrentando al nodo con el DSP pero esta vez utilizando identificadores extendidos de 29 bits. Se observó que en este caso el DSP era capaz de enviar y recibir mensajes, aunque no asentía las tramas que enviaba el nodo, por lo que éste entendía que la trama no había llegado correctamente y la retransmitía hasta entrar en el estado bus-off. Evidentemente no había ninguna perturbación en el bus que fuera responsable de que las tramas no llegaran correctamente, simplemente el fallo era del DSP por no asentir la trama. Hasta aquel momento los programas que se habían cargado en el DSP manipulaban los registros mediante punteros a las zonas de memoria donde residían, sin embargo, en los

CAPÍTULO 4. PRUEBAS SOBRE EL SISTEMA

Análisis y aplicación de los buses de campo a la domótica

131

ejemplos proporcionados por Texas Instruments, se utilizaba la estrategia descrita en el apartado 3.2.3, es decir, se declaran ciertas estructuras que tienen el mismo tamaño y disposición que los registros que pretenden manipular y después se mapean justamente en la zona de memoria donde se encuentran los registros mediante el uso de secciones en ficheros “.cmd”. Esta estrategia resulta en una programación más clara y fiable. Al reconstruir el programa de esta manera, los resultados fueron satisfactorios.

De las últimas pruebas con el bus CAN se extrajo un detalle significativo sobre el módulo

CAN de los PIC: Los registros de configuración del módulo, los filtros y las máscaras sólo pueden modificarse cuando el módulo se halla en modo configuración. Esto es muy importante cuando los elementos establecen dependencias, ya que hay que cambiar el identificador del filtro en plena ejecución.

4.1.2 PRUEBAS CON LA INTERFAZ SERIE ASÍNCRONA

Estas pruebas se efectuaron entre el DSP y el Rabbit una vez estaban construidas las

placas PAEM y “Madriguera”, que alojan al DSP y al Rabbit, respectivamente. Para las pruebas se estableció una comunicación a 9600 bit/s con 8 bits por carácter, 1 bit de parada y sin paridad. El programa en el lado del DSP no tuvo mayores complicaciones, pero en el lado del Rabbit si hubo algunas. Se detectó que al intentar configurar el puerto serie D, que es el que conecta ambos procesadores, se perdía la comunicación con el entorno de desarrollo del Rabbit. El motivo era que al configurar el puerto serie D hay que modificar registros comunes a otros puertos serie y si no se tienen en cuenta los valores previos se puede desconfigurar algún puerto. En este caso concreto, el que se desconfiguraba era el puerto serie A que es precisamente el que hace de puente entre el entorno de desarrollo y la pequeña BIOS que controla el flujo de ejecución del programa.

La solución a este problema es sencilla y pasa por utilizar ciertas “copias locales” de los

registros de manera que el valor que se guarda realmente en los registros no altere los bits adyacentes a los que sí necesitan ser modificados. Estas “copias” suelen tener el mismo nombre que el registro pero seguido de la palabra “Shadow” y están definidos en el archivo RabbitBIOS.c que se proporciona con el entorno. Las funciones de librería que afectan a los registros del Rabbit contemplan el uso de estos registros.

4.1.3 PRUEBAS SOBRE ETHERNET

Las pruebas sobre Ethernet con el Rabbit se efectuaron sin demasiadas complicaciones.

El propio entorno de desarrollo ofrece bastantes ejemplos de aplicaciones típicas en red y las funciones de librería proporcionan un nivel de abstracción bastante alto de manera que el programador no tiene que preocuparse de las capas inferiores (desde la física a la de transporte). Las pruebas consistieron básicamente en montar un pequeño servidor de eco sobre TCP y acceder a él desde un PC mediante Telnet.

De las pruebas se extraen dos detalles importantes: - Aunque los datos de conexión (dirección IP, máscara de subred, etc.) se introducen

en el programa en forma de constantes, estos datos pueden ser redefinidos en tiempo de ejecución.

- La pequeña BIOS que Dynamic C añade al programa cuando lo carga en el Rabbit no puede desempeñar todas las funciones de un sistema operativo, y por tanto la


132

multitarea es responsabilidad del programador. Esto quiere decir que es el propio programa el que debe llamar periódicamente a un demonio que realiza las funciones de bajo nivel asociadas a las conexiones TCP/IP para que las comunicaciones funcionen correctamente.

4.1.4 PRUEBAS CON EL MÓDEM GSM

Las primeras pruebas con el módem GSM se efectuaron utilizando un PC dado que el

módem GSM dispone de una interfaz RS-232. En el PC se utilizó el programa “Hyperterminal” de Windows. Se probaron los comandos para acceder a la red y se hizo especial hincapié en los comandos relacionados con el envío de mensajes SMS. Los resultados fueron satisfactorios y se consiguió enviar mensajes SMS.

Las pruebas posteriores fueron similares pero esta vez utilizando el Rabbit para controlar

el módem. Tampoco hubo problemas para llevar a cabo las pruebas con éxito.

4.1.5 PRUEBAS CON EL TERMOPAR Para las primeras pruebas del circuito de adaptación del termopar se utilizó la PICMEO 2,

que ya incluye el circuito. Aunque sí se registraban aumentos de temperatura al acercar la llama de un mechero al termopar, la variación era no era demasiado grande, y la resolución por tanto era insuficiente. También se observó que la ganancia era bastante menor que la que indicaban las ecuaciones.

Se decidió probar con un circuito similar pero con una tensión Vref ajustable en lugar del

circuito de la PICMEO 2, que fijaba esta tensión en 2.5V. Aunque el término Vref no afecta en principio a la ganancia, según se extrae de la fórmula del apartado 3.4.4.1, los resultados experimentales determinaron que con una tensión Vref en torno a los 2.7 V se producía un máximo de ganancia. Habiendo ajustado la tensión Vref, se calentó agua y con ayuda de un termómetro de laboratorio se fueron realizando medidas de la temperatura del agua y del valor de tensión de salida del circuito del termopar. Los resultados se han representado junto con la recta de regresión en la figura 3.33.

Otro detalle que se observó durante las pruebas es que existe un periodo de unos 3 ó 4

minutos desde que se empieza a alimentar el circuito hasta que el valor de la tensión de salida se estabiliza, estando el termopar a temperatura constante durante ese intervalo. Se piensa que esto es debido al calentamiento que el paso de corriente provoca en los circuitos y que altera sus propiedades. Pasado ese tiempo, la temperatura interna de los componentes se estabiliza y las medidas también.

4.1.6 PRUEBAS CON OTROS ELEMENTOS

Aunque no todos los elementos que se han pretendido instalar en el sistema se han

probado, al menos la mayoría de ellos sí han sido probados. En el caso del circuito de control de las luces, se llegó a probar con bombillas de bajo

voltaje aunque la intensidad demanda por las bombillas era del orden de los 200 mA. Se probó con un circuito similar al que se ha diseñado para los leds, usando también un transistor 2N2222A, pero el problema era que el transistor se calentaba demasiado. Se pensó en utilizar un transistor de potencia en lugar del 2N2222A, pero finalmente se optó por sustituir las bombillas


133

por LEDs de alta luminosidad con luz blanca, que consumían mucho menos e iluminaban lo suficiente para poderse usar en la maqueta.

Con el circuito del motor del ventilador ocurrió algo parecido aunque en este caso se

encontró un motor que consumía una corriente de unos 40 mA, fácilmente asumibles por el transistor 2N2222A.

Las cápsulas de ultrasonidos se han llegado a probar y se ha comprobado que la tensión

de alimentación influye mucho en la distancia máxima de detección. Si se alimentan a 5V, su rango de detección es del orden de las decenas de centímetros, distancia que aunque pequeña, es suficiente para las dimensiones de la maqueta.

4.2 DESARROLLO DEL PROGRAMA BÁSICO PARA NODOS

Como primer paso para la elaboración de los programas de cada nodo se ha creado un

programa base que incluye la funcionalidad de un nodo y la de un controlador de luz. El resto de programas pueden crearse fácilmente a partir de este programa modificando una serie de sentencias sobre la estructura principal y añadiendo los módulos propios de cada tipo de elemento que se quiera controlar con el nodo. Este primer programa ha sido implementado y probado con éxito sobre un nodo real.

4.2.1 ORGANIZACIÓN DEL PROGRAMA

Para permitir una rápida adaptación del programa base a cada tipo de elemento, se ha

intentado desarrollar el código de la forma más modular posible. El programa completo se articula entorno a un núcleo principal que contiene una serie de funciones que gestionan los recursos del microcontrolador y ofrecen un cierto nivel de abstracción, simplificando de esta manera el proceso de elaboración del software específico para manejar un elemento y evitando posibles conflictos entre elementos cuando éstos hacen uso de los recursos. El diagrama de flujo del núcleo del programa tiene la estructura mostrada en la figura 4.1. Los procesos marcados en color azul son específicos de cada elemento, y constituyen las partes del código varían de un nodo a otro. Para poder acceder por un camino que tenga asociada una condición marcada en color rojo se debe cumplir además que el elemento al que hace referencia se encuentre activo en ese momento, es decir, si llega una trama para un elemento que no está activo, ésta no se procesa.


134

Fig. 4. 1 Diagrama de flujo del núcleo del programa

4.2.1.1 CONTROL DE RECURSOS Los recursos más importantes que el nodo ofrece a los elementos que alberga son: - Contadores. - Recepción de tramas de protocolo interno. - Transmisión de tramas de protocolo interno. - Funciones de gestión de la memoria EEPROM.


135

Contadores El núcleo ofrece hasta 4 contadores de tiempo implementados por software. La función

servtimer se encarga de reservar un contador libre y configurarlo para que produzca un evento transcurrido el tiempo que se le haya pasado como parámetro. Para ello, la función servtimer suma el tiempo especificado con el contador de tiempo real y establece una marca que será comprobada periódicamente por la función contador. Una vez que el contador de tiempo real supera la marca, se desencadena un evento que acaba llamando a la función asociada al nº de suscriptor que se indicó cuando se invocó a la función servtimer. Con este mecanismo de suscriptores se pueden administrar de una manera eficiente los contadores asegurándose que se llama a la función correcta cuando sucede un evento de tiempo. Por supuesto el programador tiene la responsabilidad de asignar un nº de suscriptor a cada función de respuesta a eventos de tiempo en la etapa de diseño, y debe tener la precaución de no utilizar un mismo nº de suscriptor para diferentes funciones.

Cada uno de los contadores ocupa 3 bytes en memoria distribuidos de la siguiente forma:

CNTxH Marca de tiempo (byte alto) CNTxL Marca de tiempo (byte bajo)

CNTxCON B C m - S3 S2 S1 S0 Tabla 4. 1 Estructura de un contador

Los bytes CNTxH y CNTxL forman la marca de tiempo que al ser superada por el contador

de tiempo real, desencadenará un evento. En cuanto al registro CNTxCON, el bit B (Busy) indica si el contador está ocupado. El bit C es un bit de acarreo que se utiliza para las situaciones de desbordamiento en las que la marca de tiempo tiene que establecerse a un valor mayor que el máximo que se permite expresar con los registros CNTxH y CNTxL, (65535). Este bit de acarreo asegura que en estos casos la marca de tiempo se rebasa en el momento previsto y no justo después de colocarla, ya que de no ser por este bit, la función contadores la interpretaría como una marca ya caducada. El bit m cuando vale 1 indica que la marca de tiempo está expresada en milisegundos mientras que si vale 0 se entenderá que la marca está expresada en segundos. Por último, los bits del S3 al S0 expresan el número de suscriptor.

Recepción de tramas de protocolo interno La recepción de tramas por el bus CAN se basa en interrupciones. La rutina de

interrupción almacena la trama recibida junto con determinada información en uno de los dos buffers que ofrece el núcleo. Las funciones específicas que procesan las tramas las extraen de estos buffers. La selección de la función apropiada se hace en base al nº de filtro del módulo CAN del PIC que dejó pasar la trama, por tanto, cada función de procesamiento de tramas recibidas está asociada a un filtro concreto, y es responsabilidad del programador asignar dichos filtros de manera que no haya conflicto entre los elementos que alberga el nodo. Como ejemplo se muestra la distribución de filtros para el caso concreto de un nodo con un controlador de luz:

Filtro Función 0 Recepción de alarmas y canal de asignación 1 Recepción de mensajes del nodo 2 Recepción de mensajes para el controlador de luz 3 Recepción de mensajes que afectan a la luz (dependencia)


136

4 Recepción de mensajes que afectan a la luz (dependencia) 5 Recepción de mensajes que afectan a la luz (dependencia)

Tabla 4. 2 Distribución de filtros para el caso de un nodo + controlador de luz Los buffers mencionados anteriormente se utilizan para evitar pérdidas de tramas de

protocolo interno en los casos en los que el PIC tenga que realizar tareas que conlleven bastante tiempo. Cada uno de estos buffers, nombrados como BRAUX1 y BRAUX2, está formado por 14 bytes distribuidos de la siguiente forma:

SIDH Identificador de la trama (equivalente al registro RXBnSIDH del PIC) SIDL Identificador de la trama (equivalente al registro RXBnSIDL del PIC) EIDH Identificador de la trama (equivalente al registro RXBnEIDH del PIC) EIDL Identificador de la trama (equivalente al registro RXBnEIDH del PIC) DLC Número de bytes de datos D0 Datos D1 Datos D2 Datos D3 Datos D4 Datos D5 Datos D6 Datos D7 Datos

FILTRO B - F5 F4 F3 F2 F1 F0 Tabla 4. 3 Estructura de un buffer de recepción

Los registros SIDH, SIDL, EIDH y EIDL tienen el mismo formato que sus registros

homólogos del módulo CAN del PIC. El registro DLC indica el nº de bytes de datos que se han recibido y que han sido almacenados en los bytes Dx. El registro FILTRO es un campo de bits donde se indica qué filtro dejó pasar la trama activando el bit del filtro correspondiente. El bit B (Busy) indica si el buffer está ocupado o no. Es necesario que las funciones que procesan las tramas desactiven este bit cuando acaben el proceso de modo que el buffer quede libre para poder recibir más tramas, de no hacerlo así, la recepción de tramas quedaría bloqueada. Si llegase una nueva trama y ambos buffers estuvieran ocupados, la trama permanecería en el buzón CAN asociado al filtro hasta que alguno fuera liberado y mientras tanto, en el registro PENDIENTE, de estructura similar al registro FILTRO, se indicaría que hay tramas pendientes de almacenar, activando el bit B, y qué filtro las dejó pasar.

Transmisión de tramas de protocolo interno En el PIC existen 3 buzones de transmisión, de los cuales los dos primeros (TXB0 y

TXB1) se utilizan para la transmisión simple de tramas y el último (TXB2) se ha reservado para las transmisiones en bloque. Debido a la simplicidad de manejo de estos buzones, no hay funciones especiales para el envío de tramas simples. Es el propio código específico del elemento el que tiene que comprobar si hay alguno de los dos buzones libres para poder transmitir quedando en un bucle de espera en caso de que ambos estén ocupados. Una vez que hay un buzón libre, se coloca el identificador y los datos y se envía la trama.

En el caso de las transmisiones en bloque, la situación es cambia. No es conveniente que

la propia función específica se encargue de transmitir el bloque completo ya que tendría que esperar a que se transmitieran todas las tramas del bloque y durante ese tiempo no cedería el


137

control al resto del programa, lo cual podría dar lugar a la pérdida de datos recibidos por sobreescritura y otros tipos de fallos. Por este motivo, el núcleo dispone de un fragmento de código que se encarga precisamente de las transmisiones en bloque, cediendo el control del programa cuando no hay nada pendiente de transmitir o cuando el transmisor se encuentra ocupado. Las funciones especificas que necesiten transmitir bloques de datos solamente tienen que cargar el bloque en un buffer especial denominado BLOQTX, configurar el identificador del buzón TXB2 y marcar el buffer BLOQTX como ocupado, de la fragmentación y transmisión del bloque ya se encarga el código del núcleo. El buffer BLOQTX ocupa 104 bytes y consta de los siguientes campos:

PUNTERO Puntero al siguiente fragmento de datos a transmitir CONTROL P B PARAM D/F NUMPARAM NBYTES Número de bytes de datos a transmitir DATOS

Datos (hasta 100 bytes)

Tabla 4. 4 Estructura del buffer BLOQTX El campo PUNTERO debe valer 0 cuando se carga el buffer, y se va incrementando

automáticamente a medida que se van transmitiendo los fragmentos del bloque. El bit B del campo CONTROL indica si el buffer está ocupado o no. El bit P indica si se está transmitiendo un parámetro. Este detalle es importante, ya que la forma de transmitir un bloque de datos varía ligeramente si se trata de parámetros, ya que en el primer byte de datos de la trama de protocolo interno hay que incluir el nº de parámetro. El campo PARAM sólo se utiliza en estos casos y en él se indica el número de parámetro y el carácter del mismo mediante el bit D/F, de modo que si este bit está a 1, indica que se trata de un parámetro de dependencia, mientras que si vale 0, se trata de un parámetro de funcionamiento.

Funciones de gestión de la memoria EEPROM Existen dos funciones básicas para el manejo de la memoria EEPROM, LeerEE y EscrEE,

que se encargan de leer y escribir en la EEPROM respectivamente. La memoria EEPROM del PIC es de tan sólo 256 bytes, por lo que no se recomienda guardar demasiada información en ella o guardar información que cambie a menudo. Para el funcionamiento básico del nodo sólo son necesarias las 9 primeras posiciones de memoria (0x00 a 0x08), la organización del resto de la memoria EEPROM es responsabilidad del programador. Las primeras posiciones de la memoria se organizan de la siguiente manera:

Dirección Registro Función 0x00 FLAG Flag de inicialización de memoria (0xAA) 0x01 REGISTRADOS E5 E4 E3 E2 E1 N 0x02 ACTIVOS E5 E4 E3 E2 E1 N 0x03 NODO Número del nodo 0x04 ELEMENTO 1 Número del elemento 1 0x05 ELEMENTO 2 Número del elemento 2 0x06 ELEMENTO 3 Número del elemento 3 0x07 ELEMENTO 4 Número del elemento 4 0x08 ELEMENTO 5 Número del elemento 5

Tabla 4. 5 Organización de la memoria EEPROM


138

Los nodos nuevos no tienen estructurada aún su memoria EEPROM y es precisamente el

registro FLAG el que indica esta situación. El programa espera encontrar el flag 0xAA en dicha posición, si encuentra otro valor, entiende que el nodo es nuevo y empieza a dar formato a la memoria EEPROM para después lanzar el mecanismo de plug & play y así poder normalizar su situación. Si el programa encuentra el flag, entiende que la memoria EEPROM ya tiene formato y puede leer sus registros sin temor a interpretar datos incoherentes.

Los registros ACTIVOS y REGISTRADOS indican qué elementos se encuentran activos y

registrados, respectivamente. Hay que tener en cuenta que estos registros señalan que un elemento está activo o registrado poniendo un 0 en el bit correspondiente. Cada elemento tiene un bit asociado (bits Ex), mientras que el estado del nodo como tal se refleja en el bit N.

Los siguientes registros almacenan los números del nodo y los elementos que alberga

éste. Estos números se obtienen como resultado del proceso de plug & play y son asignados por el elemento maestro. Una vez obtenido este número se dice que el elemento está registrado, y se pone a 0 su bit correspondiente del registro REGISTRADOS. Aunque normalmente los elementos registrados también están activos, pueden ser desactivados por el usuario. Cuando esto ocurre, el elemento mantiene su número y sigue registrado, pero no se le permite intervenir en el sistema hasta que vuelva a ser activado.

4.2.1.2 ADAPTACIÓN DE ELEMENTOS Como ya se mencionó anteriormente, para poder adaptar el programa base al elemento

que se desea controlar el programador debe modificar el código en determinados puntos del núcleo y añadir los módulos que contienen el código específico del elemento. Esos puntos están identificados en la figura 4.1 en color azul, y básicamente afectan a la inicialización del nodo, al mecanismo de plug & play, al mecanismo de selección de la rutina de atención a eventos de tiempo y al de selección de la rutina de procesamiento de tramas recibidas. En la fase de inicialización, cada elemento debe disponer de una función propia que sea invocada dentro de la función init. Dicha función deberá:

- Configurar las líneas de E/S tanto analógicas como digitales que sean necesarias para

el control del elemento. - Configurar los periféricos internos del PIC que sean necesarios para la manipulación

del elemento, incluido el filtro CAN que le haya sido asignado al elemento - Inicializar las variables de estado del elemento a un estado conocido. - Asignar valores por defecto a los parámetros de funcionamiento del elemento o

recurrir a valores guardados en la memoria EEPROM si fuera necesario. El programador debe poner especial cuidado a la hora de asignar líneas de E/S, filtros

CAN y periféricos internos a un elemento. Debe tener en cuenta que los recursos pueden ser utilizados por varios elementos y que una mala asignación puede dar lugar a conflictos entre elementos con resultados imprevisibles.

Se recomienda que los elementos sean gestionados usando variables de estado, aunque

es el programador el que decide finalmente cómo organiza el código que maneja el elemento. Como ejemplo se mostrará el esquema de estados propuesto para el controlador de luz:


139

Fig. 4. 2 Variables de estado del controlador de luz

En el caso del controlador de luz, hay dos variables de estado: TEMP, relacionada con la

temporización, y DEP, relacionada con las dependencias. El paso de un estado a otro depende del comando recibido, y dependiendo de la combinación de valores de las variables de estado, la luz se comportará de una forma u otra.

La disposición de las variables en memoria es otro de los procesos delicados ya que una

mala disposición puede desembocar en conflictos entre elementos difíciles de depurar. Según el esquema propuesto en el programa base, se reservan ciertas partes de la memoria RAM para el alojamiento de los diferentes tipos de variables:

0x000 a 0x005 Números de elemento y registro de activos 0x006 a 0x00B Contadores de tiempo real 0x00C a 0x00F Reservado para control 0x010 a 0x01F Espacio para variables locales 0x020 a 0x02F Espacio para intercambio de parámetros entre funciones 0x030 a 0x04B Buffers de recepción (BRAUX) 0x04C a 0x0BF Buffer de transmisión en bloque (BLOQTX) 0x0C0 a 0x0CB Contadores ajustables 0x0CC a 0x0D2 Reservado para control 0x0D3 a 0x0F7 Reservado 0x0F8 a 0x0FF Reservado para variables de rutinas de interrupción 0x100 a 0x2FF Espacio para elementos

Tabla 4. 6 Organización de la memoria RAM del PIC El programador tiene la responsabilidad de distribuir la zona de memoria marcada en azul

entre los elementos que se albergan en el nodo. En esa zona deben estar ubicadas las variables de estado, los parámetros de funcionamiento, los parámetros de dependencia y otras variables de control del elemento. El programador puede utilizar los recursos que ofrece el programa base accediendo a las zonas de memoria correspondientes exceptuando las zonas reservadas.

Hay dos zonas pensadas para ser utilizadas por las funciones, la primera de ellas es el

espacio para variables locales, que debería ser utilizado por las funciones siempre que sea posible. La segunda zona sirve para el intercambio de parámetros entre funciones. La existencia


140

de esta zona se justifica por el pequeño tamaño de la pila de programa (32 posiciones). Si se utiliza la pila para pasar parámetros a las funciones, cabe la posibilidad de que ocurra un desbordamiento que tendría consecuencias catastróficas.

Para más información acerca de la distribución exacta de cada registro en memoria

consulte el archivo “globalVar.inc”. 4.2.1.3 DESARROLLO DEL PROGRAMA El programa se ha desarrollado en 4 fases: - Construcción - Simulación - Depuración - Pruebas El código del programa se ha dividido en varios archivos para hacerlo más modular y

comprensible. Por un lado están los ficheros con el código en ensamblador (.asm) y por otro los ficheros de declaraciones y cabeceras (.inc, .h). Las funciones básicas que integran el núcleo principal se encuentran desarrolladas en los ficheros “Eeprom.asm”, “Init.asm” y “Main.asm”. Como detalle hay que resaltar que para llevar a cabo esta fase hay que especificarle al entorno de desarrollo qué tipo de microcontrolador se está utilizando y el valor de los bits de configuración. Todo esto se puede encontrar en los menús “Configure Select device” y “Configure Configuration bits”. En el menú “Select device” se debe seleccionar el PIC18F248, mientras que en el menú “Configuration bits” se deben modificar las siguientes categorías:

Categoría Valor Oscillator HS Osc. Switch enable Disabled Watchdog timer Disabled – controlled by SWDTEN bit Low voltage program Disabled

Tabla 4. 7 Valores de los bits de configuración Una vez compilado el programa se procedió a su simulación y depuración con ayuda del

propio simulador que posee el entorno de desarrollo (MPLAB SIM). Mediante el uso del simulador se corrigieron algunos fallos y cuando el diseño era funcionalmente correcto se procedió a cargarlo en un nodo real para efectuar las pruebas. Para el proceso de carga del programa en el nodo se utilizó el programa IC-PROG. Con este programa se abre el archivo “.hex” que se generó en la compilación y a continuación se especifican manualmente los bits de configuración si éstos no aparecen en el apartado “Configuración”, situado en la parte derecha de la ventana. En ese caso los valores que habría que escribir para que resultara la configuración expuesta en la tabla 4.7 serían los que se exponen a continuación:

Config 1 FAFF Config 2 FEFF Config 3 FFFF Config 4 FF81

Tabla 4. 8 Valores de los bits de configuración para el programa IC-PROG


141

Fig. 4. 3 Vista del programa IC-PROG

En el menú “Ajustes Dispositivo” hay que seleccionar el PIC18F248. En el menú “Ajustes Tipo Hardware” hay que seleccionar la opción “JDM programmer”

en el campo programador, indicar el puerto serie que se está utilizando y en el campo Interfaz seleccionar “Direct I/O”. Con la opción “Direct I/O” se reduce el tiempo de programación, pero es posible que los usuarios de Windows XP tengan problemas al usarla. Si el sistema muestra un mensaje de error por uso de instrucción privilegiada al intentar programar, es recomendable cambiar a la opción “Windows API”, más lenta pero igualmente efectiva. Una vez que el programa IC-PROG está ajustado, se procede a cargar el programa usando el menú “Comando Programar todo”.

La última fase del desarrollo fueron las pruebas sobre el sistema real, para ello se utilizó

un programa sencillo para el DSP de modo que se pudiera enviar cualquier tipo de trama hacia el nodo bajo prueba. Se probó el mecanismo de plug & play y todos los comandos que influyen directamente sobre el controlador de luz. Además gracias al DSP se pudo emular la presencia de detectores de movimiento, interruptores y sensores de luz para probar el funcionamiento del controlador de luz en modo dependiente. Todas las pruebas fueron superadas con éxito.

De cara al usuario final, el nodo y sus elementos pueden ser manipulados a través de la

aplicación de usuario, pero existe una señal visual que permite monitorizar el estado interno del nodo. Esta es la misión del LED que integra la placa. El significado de los estados del LED se describen a continuación:

Estado del LED Significado Apagado El nodo no está registrado en la red o no hay suministro eléctrico Encendido El nodo está registrado y operativo Parpadeando El nodo está desactivado temporalmente por perturbaciones en el bus CAN

Tabla 4. 9 Estados del LED y su significado


142

4.2.2 ALGORITMOS Función init: Inicializa el nodo

Fig. 4. 4 Diagrama de flujo de la función init


143

Función regNodo: registra el nodo en la red utilizando el mecanismo de plug & play Función regLuz: registra la luz en la red utilizando el mecanismo de plug & play

Fig. 4. 5 Diagramas de flujo de las funciones regNodo y regLuz


144

Función servtimer: asigna un contador a un suscriptor. Si numCNT=0 se asigna un temporizador libre. Si numCNT tiene otro valor se actúa sobre el contador indicado.

Parámetros:

NSUSCR 0x020 Número del suscriptor S/M 0x021 0 – segundos; 1 – milisegundos NumCNT 0x025 Número del contador (opcional) TiempoL 0x022 Tiempo de espera (byte bajo) TiempoH 0x023 Tiempo de espera (byte alto)

Devuelve: Ncont 0x024 Número del contador asignado

Función contadores: comprueba si ha caducado algún temporizador y llama a la función

de atención a eventos de tiempo correspondiente.

Fig. 4. 6 Diagramas de flujo de las funciones servtimer y contadores


145

Función rluz1: Procesa las tramas recibidas que van dirigidas al controlador de luz.

Fig. 4. 7 Diagrama de flujo de la función rluz1


146

Fig. 4. 8 Diagrama de flujo de la función rluz1 (continuación)


147

4.3 PROGRAMA PARA EL ELEMENTO MAESTRO

El programa del maestro se encuentra actualmente en fase de depuración y pruebas

aunque en un estado muy avanzado y funcionando parcialmente.

4.3.1 ORGANIZACIÓN DEL PROGRAMA 4.3.1.1 ESTRATEGIA DE DISEÑO A la hora de afrontar el diseño del programa para el elemento maestro, se decidió

construir el código en forma de dos bloques separados. El primero de estos bloques corresponde a lo que se ha denominado como “núcleo” o “kernel”. En este kernel residen las funciones de control del elemento y las que implementan el nivel de aplicación, por tanto son estas funciones las que controlan la comunicación siguiendo las reglas marcadas por los protocolos interno y externo.

El segundo bloque comprende las funciones de las capas inferiores y se encarga del

manejo a bajo nivel de los instrumentos de comunicación y otros dispositivos. Este bloque proporciona los servicios de comunicaciones que necesita el kernel.

El hecho de que el kernel sea relativamente independiente del hardware real sobre el que

se va a asentar hace que se pueda probar y depurar sobre un PC, lo cual simplifica esta tarea. El entorno de desarrollo del DSP utiliza el lenguaje C para la realización de los programas, y soporta las librerías más conocidas y utilizadas en otros compiladores de lenguaje C para PC, por tanto, la portabilidad del código entre el PC y el DSP está asegurada.

Inicialmente el kernel se desarrolló sobre un PC utilizando un compilador estándar como

es el “gcc”. Alrededor del kernel se crearon una serie de funciones que emulaban al hardware del DSP aunque realmente lo que hacían era interactuar con el usuario. Esta estrategia permite simular muchos situaciones y observar cómo se comporta el kernel. A través de unas funciones de consola se ha podido monitorizar las tramas generadas por el kernel para su transmisión por el bus CAN o a través del canal serie asíncrono así como los accesos a una memoria EEPROM ficticia. Estas mismas funciones también permiten al usuario simular la llegada de tramas por el bus CAN o por el canal serie asíncrono. Una vez creado y depurado el kernel, se eliminaron las funciones de consola y se transportó a la aplicación definitiva, añadiendo todas las funciones de manejo de periféricos que ya habían sido probadas por separado durante las pruebas preliminares.

Las pruebas del programa maestro se han llevado a cabo compilándolo y ejecutándolo

desde la memoria RAM por las ventajas que esto conlleva a la hora de depurar, aunque la versión definitiva del programa evidentemente no puede ir ubicada en memoria RAM sino en la memoria Flash del DSP de modo que el sistema pueda funcionar de forma autónoma sin tener que estar conectado a un PC a través del puerto paralelo. Para crear la versión definitiva es necesario modificar el archivo “.cmd”, que contiene información acerca de las secciones y su ubicación en memoria. Además hay que cambiar la configuración de ciertos jumpers de la tarjeta eZdsp para que el DSP arranque desde la memoria Flash. Estos jumpers están descritos en el manual de referencia de la tarjeta eZdsp F2812 de Spectrum Digital ®.


148

4.3.1.2 GESTIÓN DE RECURSOS El módulo eCAN del DSP dispone de 32 buzones independientes que han sido

distribuidos de acuerdo con las necesidades de la aplicación:

Buzón Uso Función 31 RX Alarmas, Canal de Asignación, etc. 30 RX Sensores de temperatura (detección de incendios) 29 RX Sensores de movimiento (detección de intrusos) 28 TX Transmisiones en bloque 25, 26, 27 TX Transmisión de tramas simples Resto RX Recepción bajo reserva

Tabla 4. 10 Función de cada buzón del módulo eCAN La recepción de tramas por el bus CAN está controlada por una rutina de interrupción

cuya misión consiste básicamente en introducir la trama recibida en una cola denominada colarxcan. El algoritmo principal se encarga de extraer periódicamente las tramas de la cola y entregarlas a la funciones específicas que deban procesarlas. Cada elemento de la cola es una estructura de memoria que contiene los datos de la trama recibida y toda la información relativa a ella.

Las tramas que llegan a los buzones 31, 30 y 29 las procesa internamente el elemento

maestro de forma automática y sin intervención del usuario. Las tramas que llegan a esos buzones contienen información que afecta a la seguridad de la casa, concretamente el maestro escucha las tramas procedentes de los sensores de temperatura que contengan el comando STINCEN, para saber si se ha producido un conato de incendio, y las tramas procedentes de detectores de movimiento que lleven el comando MOV, para saber si hay intrusos en la casa.

El resto de buzones de recepción funcionan bajo reserva, esto es, se reservan para recibir

determinadas tramas especificadas previamente por la aplicación cliente y se liberan cuando han recopilado toda la información requerida. Muchas de las órdenes que el usuario puede dar al sistema involucran la reserva y liberación de buzones, tal y como se expuso en el apartado 3.7.4. Para la gestión de estos buzones existe una tabla con estructuras de tipo Reserva, que contiene información como el nº de petición asociado, el tipo de información esperada o un puntero a una estructura struct bloqueD_F donde se van ensamblando los datos recibidos para el caso de recepción de bloques.

Para la transmisión de tramas por el bus CAN se plantean dos formas distintas. Por un

lado, para la transmisión de tramas sueltas (simples) se utiliza la función envtramaCAN. Esta función busca entre los buzones 25, 26 y 27 uno libre, y si lo encuentra, transmite a través de ese buzón la trama que haya generado el kernel. Por otra parte, las transmisiones en bloque siguen un proceso totalmente diferente. En este caso la trama no se almacena en una estructura mensajeCAN, sino en una estructura especial del tipo bloq_a_dentro. El kernel tan sólo tiene que depositar dicha estructura con el bloque que quiere transmitir y el identificador CAN en la cola listaBAD. El propio algoritmo principal se encarga periódicamente de transmitir los fragmentos del bloque de uno en uno.

De cara al exterior, las transmisión y recepción de tramas de protocolo externo a través

del canal serie asíncrono SCI también tiene sus propios mecanismos. En primer lugar tenemos la cola colatxsci, donde se almacenan todas las tramas que se van a transmitir en forma de


149

estructuras Tramaexterna. El kernel sólo tiene que rellenar una de estas estructuras e introducirla en la cola, la transmisión de tramas se regula por medio de la interrupción correspondiente del módulo SCI-A. En el caso de la recepción, la situación es parecida ya que es otra rutina de interrupción la que se encarga de la sincronización y recepción de tramas. Esta rutina va recogiendo los bytes que le llegan desde el elemento de comunicación con el exterior y va componiendo la trama en una estructura Tramaexterna que posteriormente introduce en la cola colarxsci una vez que han llegado todos los bytes de la trama. El algoritmo principal extrae periódicamente las tramas de dicha cola y las envía a la función correspondiente seleccionada en virtud de la orden de protocolo externo que contenga la trama.

Otro de los recursos del elemento maestro es la memoria EEPROM, donde almacena

información sobre el sistema. Esta memoria está estructurada de la siguiente forma:

Fig. 4. 9 Formato de la memoria EEPROM del elemento maestro

Todos los campos de información tienen direcciones fijas excepto las listas de sectores y

elementos, que se rellenan de manera dinámica. Se han creado funciones específicas que localizan espacio libre y alojan los elementos y sectores nuevos manteniendo la estructura de la lista enlazada por medio de los punteros.


150

4.3.2 ALGORITMOS

A continuación se presentan algunos de los algoritmos más importantes que componen el

programa del elemento maestro. Función init: Inicializa el elemento maestro.

Fig. 4. 10 Diagrama de flujo de la función init (maestro)


151

Función main: algoritmo principal del programa.

Fig. 4. 11 Diagrama de flujo del algoritmo principal del programa maestro


152

Función reservadas: Procesa las tramas recibidas por un buzón reservado

Fig. 4. 12 Diagrama de flujo de la función reservadas


153

Función CArx: Implementación del mecanismo de plug & play en el lado del maestro

Fig. 4. 13 Diagrama de flujo de la función CArx

CAPÍTULO 4. PRUEBAS SOBRE EL...

Documents

Transcript of CAPÍTULO 4. PRUEBAS SOBRE EL...