Enunciado de la práctica estándar Sistemas Digitales (SDGII)

Transcripción

1 Departamento de Ingeniería Electrónica E.T.S.I. de Telecomunicación Universidad Politécnica de Madrid Sistemas Digitales II Enunciado de la práctica estándar Sistemas Digitales (SDGII) Sistema domótico de Monitorización y Generación de alarmas en el hogar basado en el MCF5272 Plan Bolonia. Curso Versión 1.0 Autores: Roberto Barra Chicote Rubén San-Segundo Hernández Luis Fernando D Haro Enríquez

2 ÍNDICE GENERAL 1 INTRODUCCIÓN AVISO INICIAL ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA ANTECEDENTES OBJETIVO GENERAL Generación de alarmas SUBSISTEMA HARDWARE MÓDULO BÁSICO DEL SISTEMA Emisor Reloj del emisor Generación de trama y emisión de información serie Línea de transmisión MÓDULOS ADICIONALES Incorporación de bit de paridad Ampliación del número de sensores Línea de transmisión: enlace de infrarrojos Utilización de sensores reales Mando a distancia por medio de infrarrojos para la configuración de las alarmas que genera el sistema Mando a distancia por radiofrecuencia para la configuración de las alarmas que genera el sistema Construcción de un prototipo del HW en PCB OBSERVACIONES ADICIONALES SOBRE EL HW DE ENTRADA/SALIDA ALIMENTACIÓN DE LOS SUBSISTEMAS SUBSISTEMA DIGITAL BASADO EN EL MCF SUBSISTEMA SOFTWARE MODELO DE REQUISITOS MÓDULO BÁSICO DEL SISTEMA Modelo de objetos o variables Trama actual Posibles valores o niveles de cada sensor Tiempo límite de alarma para cada valor de cada sensor Tiempo acumulado para cada valor de cada sensor Alarmas generadas para cada valor de cada sensor Relojes Rutinas o métodos generales de los objetos de un sistema Modelo de diseño Arquitectura del sistema SW Modelo dinámico Tiempo acumulado para cada valor de cada sensor Trama actual Modelo dinámico del objeto reloj Procesos Proceso principal Interrupción periódica... 17

3 Interrupción externa MÓDULOS ADICIONALES Configuración de alarmas mediante un teclado matricial Modelo dinámico del objeto tecla Ampliación de la funcionalidad por SW Alarmas dependientes de la franja horaria Generación de alarmas acústicas mediante el empleo de un DAC Generación de alarmas acústicas mediante temporización o PWM Ampliación del subsistema de visualización Comunicación con un sistema digital comercial para el envío de alarmas Comunicación serie utilizando la UART CODIFICACIÓN OPTIMIZACIÓN DESCRIPCIÓN DE LA SESIÓN -1 (ANTES DE IR AL LABORATORIO B-043) COMENTARIOS SOBRE LAS CONEXIONES DESCRIPCIÓN DETALLADA DE LA SESIÓN MÉTODO DE TRABAJO TUTORIAL INICIAL DISEÑO, IMPLEMENTACIÓN Y PRUEBA DE UN PRIMER PROGRAMA Estructura básica de los programas que desarrolle... Error! Marcador no definido Subrutina para configurar el HW (hwinit) Si tiene dudas o problemas NOCIONES SOBRE DEPURACIÓN DE PROGRAMAS PASO 1: Obtención de una prueba fallida y previsión de la salida PASO 2: Localización del error Comentarios adicionales PASO 3: Determinación de la causa del error PASO 4: Corregir el error Consejos para errores no sistemáticos y ocasionales Comentarios adicionales sobre depuración de programas Si tiene dudas o problemas DESARROLLO RECOMENDADO EVALUACIÓN EVALUACIÓN DEL MÓDULO BÁSICO EVALUACIÓN DE MÓDULOS ADICIONALES Valoración de la Complejidad Valoración de la Originalidad EVALUACIÓN CONTINUA CONSIDERACIONES GENERALES DE EVALUACIÓN BIBLIOGRAFÍA

4 1 Introducción El objetivo del Sistemas Digitales II es que el alumno aplique y consolide de una manera práctica los conocimientos adquiridos en las asignaturas de tercer curso Sistemas Digitales I y Circuitos Electrónicos, partiendo de la base sobre programación adquirida en Programación y Análisis y Diseño de Sofware. Para ello deberá seguir las instrucciones aquí incluidas, que implicarán diversas fases de diseño, análisis, implementación y medida de los circuitos y programas propuestos. Igualmente se hará especial énfasis en que los alumnos adquieran una visión práctica de los problemas con los que se encuentra el diseño del hardware (HW) y el software (SW) de sistemas electrónicos a la hora de implementar prototipos reales de Laboratorio. El resultado del trabajo realizado debe quedar reflejado en una memoria final que contenga los detalles del proceso, así como los resultados obtenidos y todas aquellas cuestiones específicas que se indiquen en el enunciado. Es obligatorio entregar electrónicamente el programa en desarrollo a través del portal de acuerdo con las normas generales del SDII publicadas previamente. Salvo que se indique lo contrario, la práctica propuesta contiene las especificaciones mínimas comunes y obligatorias (módulo básico) que deben cumplir los sistemas y serán valoradas con un máximo de 4,5 puntos (únicamente en el caso de evaluación continua). Adicionalmente al módulo básico, se presentarán sugerencias de módulos opcionales, dejando a los alumnos la libertad para decidir qué nuevos módulos o esquemas alternativos incorporan a su prototipo básico. Con estos módulos opcionales añadidos al prototipo básico, y dependiendo de su dificultad y realización, se podrá alcanzar la máxima nota, 10 puntos. Sobre otras modalidades de práctica distintas de la estándar, remitimos al alumno a la información general de la asignatura publicada con antelación a este documento. Aquellos alumnos que deseen realizar una práctica especial basada en un problema o un diseño propios (o propuesto por un profesor), deberán presentar a alguno de los profesores de la asignatura (y ser aprobada por el mismo) una propuesta de práctica donde describan en 2 o 3 páginas cuáles son los objetivos del sistema propuesto, qué recursos son necesarios para llevarlo a cabo, así como las arquitecturas HW y SW propuestas para la resolución del problema. No será admitida ninguna práctica (por muy compleja o perfecta que sea) que no se ajuste a estas normas. Sobre las consideraciones éticas del trabajo en el laboratorio, remitimos al alumno al documento publicado sobre la filosofía de los laboratorios CELT y SDII, disponible a través del portal de la asignatura. Para cualquier consulta, no duden en dirigirse al coordinador Roberto Barra Chicote (B-112, barra@die.upm.es), o a cualquiera de los profesores del SDII en sus respectivos horarios de clase. Podrá encontrar éste y otros documentos relacionados, así como información actualizada sobre la asignatura, en Aviso inicial Cuando aborde la lectura de este documento, hágalo con tranquilidad y detenimiento. Frases o comentarios que no se entiendan en una primera lectura pueden encerrar avisos y recomendaciones que le serán útiles a lo largo del desarrollo de la asignatura. 3

5 No se preocupe si no alcanza a comprender todos los términos, conceptos y detalles que se discuten. Todos ellos se irán aclarando a medida que avance en la lectura de este documento. Por supuesto, asuma que necesitará varias lecturas y una reflexión a fondo sobre todo esto. Preste especial atención a todas las referencias explícitas a aspectos que se indican como obligatorios para incluir en la memoria: no quiere decir que algo no referenciado explícitamente no tenga que ser tratado, sino que nuestra experiencia demuestra que algunos de ellos no son considerados por un cierto número de alumnos, lo que da lugar a desagradables sorpresas en los exámenes. A lo largo de este enunciado irá descubriendo que multitud de detalles imprescindibles de solventar en un sistema real se dejan de lado o se simplifican notablemente. Es fundamental que tenga en cuenta que esta práctica pretende ser un ejercicio de diseño, implementación y prueba de sistemas electrónicos digitales (con una pequeña componente analógica), con lo que es seguro que encontrará decisiones de diseño y recomendaciones que harían imposible que el prototipo final construido pudiera llegar a formar parte de un sistema real. Además de este documento, el alumno dispondrá de una clase introductoria teórica sobre este enunciado (donde recibirá explicaciones generales sobre la práctica y donde podrá realizar preguntas sobre la misma). No olvide tampoco que los profesores estarán disponibles para aclarar dudas a lo largo del desarrollo del laboratorio (según sus respectivos horarios en el B-043). 2 Especificación de requisitos del sistema 2.1 Antecedentes A medida que los sistemas de electrónicos se van incorporando a nuestros hogares, aparecen nuevos servicios que mejoran nuestra calidad de vida. Estos servicios pretenden mejorar tres aspectos importantes en nuestro hogar: el confort, el uso eficiente de recursos naturales, y la seguridad. En relación con el confort se plantean servicios que permiten llevar vídeo y/o audio a cualquier punto del hogar permitiendo disfrutar de ellos independientemente del lugar de la casa donde te encuentres o de la tarea concreta que estás haciendo. Por otro lado, se pueden centralizar servicios (llamadas telefónicas, Internet, vídeo bajo demanda) bajo los mismos interfaces mejorando sensiblemente la interacción entre los dispositivos y las personas que los utilizan. Otro aspecto importante es la utilización eficiente de recursos naturales. En este campo se puede disponer de sistemas que conecten las persianas de las ventanas con las luces, de forma que el uso de las luces dependa de la luminosidad que se pueda conseguir a través de las ventanas. De la misma forma, la utilización de la calefacción o del aire acondicionado en una habitación puede depender de si está abierta o no la ventana, por ejemplo. El tercer aspecto, y quizás el más importante, es el de la seguridad. En este aspecto podemos diferenciar dos tipos de sistemas. En primer lugar los que tienen como objetivo evitar que una persona no autorizada acceda a nuestro hogar: sistemas de alarma que detectan la entrada de intrusos, sistemas de aviso ante puertas o ventanas que se dejan abiertas, o sofisticados sistemas de acceso que pueden ser desde llaves electrónicas hasta sistemas de acceso biométrico. El segundo tipo de sistemas de seguridad está relacionado con la supervisión del comportamiento de las personas para evitar accidentes domésticos: que nos dejemos abierto el gas o el agua, por ejemplo. El sistema propuesto en esta práctica se engloba en este segundo tipo de aplicaciones domóticas orientadas a la seguridad. Se pretende la implementación de 4

6 un prototipo que reciba información de varios apartados domóticos y genere un conjunto de alarmas en función de la situación de los aparatos y el tiempo que transcurra en esa situación. Dado que nuestro propósito es docente y con especial énfasis en la interacción entre HW y SW y en los requisitos de tiempo real, no implementaremos un sistema real completo, y proporcionaremos a los alumnos una guía para su diseño e implementación. 2.2 Objetivo general El objetivo de la práctica es mostrar la viabilidad de la idea de diseño básica. El programa que ejecutará el micro se realizará en C o ensamblador (ambos incorporados en el entorno de desarrollo EDColdFire). El sistema digital basado en un microprocesador será la plataforma ENT2005CF disponible en el laboratorio B-043 (construida en torno a un MCF5272). Para más detalles relacionados con el sistema de desarrollo, consulte la nueva publicación [4][3]. En los apartados siguientes se detallarán las arquitecturas HW y SW, haciendo énfasis en la descomposición modular del sistema, tarea clave para abordar con éxito el diseño de cualquier sistema HW o SW medianamente complejo. El objetivo general lo podemos resumir de la siguiente manera: Desarrollar un sistema digital basado en un microprocesador que permita: Recibir una trama de información con el estado de 3 aparatos o sensores domóticos: sensor de agua (0/1, ausencia o existencia de agua), sensor de humo (hasta 4 niveles de densidad de humo) y sensor de gas (0/1, ausencia o existencia de gas). Medir el tiempo que trascurre desde un cambio a otro en el estado de los 3 aparatos. Generar una alarma visual en la pantalla del ordenador avisando de la situación detectada (aparato/sensor, nivel alcanzado y tiempo). El procesamiento se hará de una manera indefinida (el programa nunca dejará de monitorizar hasta que se apague el sistema) mediante el uso de interrupciones periódicas. El prototipo que vamos a diseñar se basará en la recepción de la información serie a través de una entrada digital sincronizada con un reloj externo (el reloj también se transmite de emisor a receptor). El reloj se conecta a la interrupción externa INT1 permitiendo la sincronización con los bits recibidos a través de la entrada digital serie. Será, igualmente, competencia del sistema SW, generar y procesar las señales necesarias para gobernar el HW externo: teclado matricial (opcional) y recepción serie Generación de alarmas El sistema debe generar alarmas como mínimo en las siguientes situaciones: Cuando el primer aparato (sensor de agua) tenga un valor de 1 (existencia de agua) durante un tiempo superior a 20 segundos. Cuando el segundo aparato (sensor de humo) tenga un valor igual o superior a 2 (10 en binario) durante un tiempo superior a 30 segundos o un valor de 3 (11 en binario) durante 10 segundos. 5

7 Cuando el tercer aparato (sensor de gas) tenga un valor de 1 (existencia de gas) durante un tiempo superior a 10 segundos. 3 Subsistema Hardware En la Figura 1 se muestra un diagrama de bloques con las partes más importantes que forman el subsistema hardware (HW) que se irán describiendo en los siguientes apartados. SUBSISTEMA HARDWARE Emisor de información serie Reloj del emisor EMISOR Línea de trasmisión Línea de trasmisión Hardware de acondicionamiento de señal serie Hardware de acondicionamiento de señal de reloj Hardware de Entrada- Salida 3.1 Módulo Básico del Sistema Figura 1. Diagrama de bloques del subsistema hardware. En la versión básica del subsistema hardware simplificaremos algunas de las características de varios módulos, teniendo la posibilidad de mejorar el sistema mediante características adicionales en una versión ampliada Emisor El emisor está formado por 2 componentes principales: el sistema de generación de trama (con la información de los sensores) y el circuito generador del reloj de transmisión serie Reloj del emisor Para generar un reloj de una frecuencia determinada se recomienda consultar el apartado 3.2 (Generación de relojes) de la referencia [5]. Además de los circuitos propuestos en esta referencia puede utilizar, si lo 6

8 desea, el circuito integrado 555, ajustando el valor de capacidad según la frecuencia de funcionamiento deseada. Para nuestra práctica la frecuencia de reloj considerada será de 10 Hz. Esta frecuencia será suficiente para transmitir toda la información de una trama en menos de un segundo. En el caso de que el alumno decidiera hacer algún de las mejoras a la práctica básica incorporando más información de supervisión, sería necesario incrementar esta frecuencia del reloj para poder mandar toda la información en un segundo Generación de trama y emisión de información serie En la Figura 2, se muestra la estructura de la trama que se debe generar en el emisor. Esta trama está formada por 8 bits: El primer lugar un bit de arranque para identificar el comienzo de la trama. A continuación 4 bits con la información del estado de los 3 sensores considerados: sensor de agua (0/1), sensor de humo (4 niveles) y sensor de gas (0/1). Finalmente 3 bits de parada puestos siempre a 0. Figura 2. Trama de emisión con la información del estado de los sensores. El emisor debe generar una trama cada 1 segundo y emitirla vía serie con un régimen binario de 10 bits/segundo (utilizando el reloj diseñado en el apartado anterior). A la hora de diseñar el emisor debe tener en cuenta los siguientes aspectos prácticos: Para simular el estado de los sensores puede utilizar unos microswitches que permitan modificar la situación de cada sensor fácilmente. Para la transmision serie puede utilizar registros de desplazamiento modelo 74HC165 o similar. Recuerde que puede utilizar contadores (modelo 74HC191 o similar) para gestionar el envío de los bits. 7

9 3.1.2 Línea de transmisión La línea de transmisión en la versión básica del emisor consistirá en dos cables que conecten el emisor con el puerto digital y una entrada de interrupción externa del MCF5272 para trasmitir la trama y el reloj respectivamente. De esta forma la trama generada por el emisor se presenta en la Figura Módulos Adicionales Incorporación de bit de paridad Esta mejora en el emisor consistirá en la incorporación de un bit de paridad (PAR) en la trama, que podrá realizarse mediante el uso de puertas lógicas, a fin de que posteriormente sea confirmada como correcta la trama detectada por parte del subsistema software. Figura 3. Trama de emisión con la información del estado de los sensores y bit de paridad Ampliación del número de sensores Una posibilidad de mejora del sistema es aumentar el tamaño de la trama para dar cabida a la información de más sensores. Es importante notar que al aumentar el tamaño de la trama hay que aumentar también la frecuencia del emisor con el fin de que de tiempo a transmitir una trama por segundo Línea de transmisión: enlace de infrarrojos La línea de transmisión (para la transmisión de la trama) podremos implementarla por medio de un enlace de infrarrojos de distancia fija que vamos a simular mediante un par optoacoplado: por ejemplo el H22A1/2/3 de FAIRCHILD o el OPB804. El fotoemisor es un diodo emisor de luz, cuya polarización será similar a la de un LED con el cátodo conectado a masa [5] (consulte la caída de tensión en directa, así como el consumo de corriente recomendados por el fabricante, a fin de calcular correctamente la resistencia de polarización). Por su parte, el fotorreceptor está constituido por un transistor cuya base realiza las funciones de célula fotoeléctrica, produciendo una corriente en colector proporcional a la cantidad de luz recibida (como en cualquier transistor la corriente inducida en la base provoca una corriente amplificada en colector). Una simple resistencia (R2) en colector nos permitirá traducir dicha corriente en voltaje. La sensibilidad del 8

10 optoacoplador puede variar de manera importante de uno a otro puesto por lo que se recomienda que las resistencias R1 y R2 se implementen parcialmente mediante dos potenciómetros. En relación con la implementación de R1, para evitar que el fotodiodo emisor se queme, es IMPRESCINDIBLE poner una resistencia R min en serie con el potenciómetro. La misión de esta resistencia es garantizar un valor mínimo de resistencia para el caso en el que el potenciómetro se coloque, por error, en la posición de resistencia 0, evitando así que el diodo se estropee. 5 V R1 R2 74HC14 OPTOACOPLADOR Figura 4. Circuito de polarización del par optoacoplado: enlace de infrarrojos. Debe de implementarse un módulo de acondicionamiento de la señal recibida por la línea de transmisión. Con dicho módulo, la tensión a la salida del par optoacoplado debe ser convenientemente conformada por medio de un inversor o de un buffer digital (preferiblemente trigger-schmitt). Dependiendo de la resistencia R2 (resistencia de salida, Figura 4) puede ser necesario incorporar un circuito comparador para diferenciar claramente los dos niveles de tensión posibles. Al final de este módulo se debe obtener una señal digital cuyo valor bajo de tensión sea 0V y el nivel alto 5V Utilización de sensores reales En esta mejora se propone la utilización de sensores reales (en lugar de simulados con micro-switches) para la obtención de información sobre las presencia de agua, humo o gas, presión, vientos, temperatura, etc. En esta mejora es necesario la conversión Analógica-Digital de la información proporcionada por los sensores. Una propuesta sería la monitorización de temperatura mediante un sensor LM135 empleando el ADC disponible en la ENT2004CF Mando a distancia por medio de infrarrojos para la configuración de las alarmas que genera el sistema Remitimos al alumno al enunciado de la práctica del LSED para consultar los detalles sobre este tipo de enlace. Esto obliga a modificar el subsistema HW del teclado. A fin de poder alcanzar una 9

11 cierta distancia se le debe suministrar bastante corriente al LED (siempre dentro de las especificaciones dadas por el fabricante) y tener la adecuada amplificación y filtrado en el receptor Mando a distancia por radiofrecuencia para la configuración de las alarmas que genera el sistema Existen diversos fabricantes (Aurel, etc) que proporcionan circuitos híbridos de fácil manejo, capaces de transmitir, recibir y regenerar señal digital directamente, tanto en AM como en FM (mayor inmunidad frente al ruido, mayor precio), con un alcance de varias decenas de metros en campo abierto si se les dota de una antena (un simple conductor de cobre) de la longitud apropiada. Esto obliga a modificar el subsistema HW del teclado Construcción de un prototipo del HW en PCB En la realización de esta mejora es obligatorio utilizar un programa comercial para el diseño de la PCB. Remitimos al alumno interesado a lo que se comenta en el enunciado y la página web de la asignatura CELT, destacando que esta mejora es más asequible en SDGII porque el circuito a diseñar y construir es bastante más pequeño. 3.3 Observaciones adicionales sobre el HW de entrada/salida Para realizar la entrada y salida de datos al sistema se utilizará la placa TL04 disponible en el laboratorio B-043. Esta placa dispone de un teclado matricial con 16 teclas para introducir los valores de configuración de las alarmas y un LCD para la visualización de la información deseada si se aborda la mejora de uso del LCD. Se recomienda encarecidamente al alumno que consulte con detenimiento el tutorial del teclado disponible en la carpeta de tutoriales del PC del laboratorio, así como su descripción en [3]. En este tutorial encontrará una descripción detallada de la placa TL04 así como varios ejemplos para aprender a manejarla: lectura del teclado y muestra de un mensaje en el LCD. 3.4 Alimentación de los subsistemas Será suficiente con un único nivel de tensión de 5 V. Es muy importante desacoplar las alimentaciones; remitimos al alumno a la referencia bibliográfica [3]. Si algún elemento puede demandar picos fuertes de corriente, puede ser muy importante filtrar de manera extraordinaria su alimentación para que estos picos no afecten al resto de la circuitería. Incluso se puede llegar a emplear la salida de tensión fija de 5 voltios de que disponen las fuentes de alimentación del laboratorio. 4 Subsistema digital basado en el MCF5272 Este subsistema lo forma la plataforma ENT2005CF cuya descripción se puede consultar en (R. San- Segundo et al 2005). El manejo del entorno de desarrollo EDColdFire y las funciones de la TRAP #15 para comunicarse con el PC son descritas detalladamente en esta referencia. Existe igualmente un documento de dudas y preguntas frecuentes de gran utilidad en la etapa inicial de toma de contacto y elaboración de los primeros programas [8]. Es imprescindible realizar los principales tutoriales del EDColdFire para aprender el manejo de los principales recursos de la plataforma ENT2005CF ([3],[4], tutoriales en el PC y página Web de la asignatura). 10

12 El conjunto de programas que se ejecutan sobre el procesador se describirá a continuación, cuando hablemos del subsistema SW y su arquitectura. 5 Subsistema Software 5.1 Modelo de requisitos En esta asignatura, el análisis y el modelo de requisitos no son competencia exclusiva del alumno, sino que son, parcialmente, información que se le proporciona para la realización de la práctica. Supongamos que tenemos un cliente que desea que desarrollemos un sistema domótico de Monitorización y Generación de alarmas. Tras diversas entrevistas con este hipotético cliente, podríamos llegar a un ámbito del proyecto SW como el ya incluido previamente en la descripción del apartado 2.2 "Objetivo general. 5.2 Módulo Básico del Sistema Modelo de objetos o variables La labor de descubrir qué objetos o estructuras de datos son relevantes en nuestro proyecto es sistematizable sólo hasta cierto punto. Tras un análisis de requisitos del sistema y posibles características adicionales a implementar, los objetos principales los objetos principales deben ser los siguientes: Trama actual Contenido de la última trama recibida con la información de los valores de cada sensor Posibles valores o niveles de cada sensor Representa el buffer de todos los posibles valores o niveles que puede tener un sensor. Se dispondrán de tantos búferes como sensores diferentes se consideren en el sistema Tiempo límite de alarma para cada valor de cada sensor Representa el buffer con los límites de tiempo para todos los posibles valores de un sensor, transcurrido los cuales, se generarán alarma. Se dispondrán de tantos búferes como sensores diferentes se consideren en el problema. Para simular que un valor/nivel de un sensor no generará nunca alarma se puede poner un tiempo límite infinito Tiempo acumulado para cada valor de cada sensor Representa el buffer con los tiempos acumulados en los que el sensor ha tenido un valor IGUAL o SUPERIOR al valor considerado: en el caso de que un sensor tenga un valor de 3 durante 10 segundos, este tiempo debe contarse también para los valores inferiores 0, 1 y 2. Se dispondrán de tantos búferes como sensores diferentes se consideren en el problema. 11

13 Alarmas generadas para cada valor de cada sensor Representa el buffer con las alarmas generadas para cada uno de los niveles de cada sensor. Se dispondrán de tantos búferes como sensores diferentes se consideren en el problema. Una vez generadas las alarmas se debe resetear el tiempo acumulado que generó la alarma Relojes En los objetos anteriormente descritos es necesario contar tiempos para realizar correctamente algunas de las operaciones (recepción de los bits de la trama), por ejemplo. Para ello se necesitan uno o varios objetos que hagan las funciones de contadores de tiempo. La implementación de los distintos retardos y mediciones de tiempo del sistema puede dar lugar a la necesidad de emplear varios relojes-contador. En esta práctica se necesita al menos 1 reloj con el fin de establecer el tiempo en el que se deben realizar las diferentes medidas del bit que se está recibiendo. Una vez recibida una señal de sincronismo (interrupción INT1) se deben realizar 10 medidas del bit que se está recibiendo, espaciadas temporalmente 10 ms. El valor final del bit se decide por mayoría. Con esta consideración podríamos configurar un reloj cada 10 ms o configurar un reloj cada 1 ms y esperar 10 interrupciones del temporizador. Esta segunda opción es mejor porque permitiría un reloj interno con una mayor precisión a la hora de implementar retardos en otras partes del programa Rutinas o métodos generales de los objetos de un sistema Todos los objetos (o estructuras de datos) pueden tener asociadas al menos 2 o 3 funciones (o métodos) generales que los manejan: Inicializar (inic): da valores iniciales a las propiedades de un objeto o estructura de datos. En simulación en C, suele abrir un fichero de depuración donde se escribirán todas los eventos y valores del objeto a lo largo del tiempo, y que permite analizar detalladamente su funcionamiento a posteriori. Re-inicializar (reset): vuelve a darle valores a las propiedades (aunque, para la mayoría de los objetos, pueden coincidir con los valores de inicialización). Finalizar (fin): en el caso que nos ocupa, su existencia no tiene sentido, porque los objetos no desaparecen hasta que termina el propio sistema, y no son objetos persistentes cuyas propiedades haya que guardar para inicializar posteriores ejecuciones del sistema. En simulación en C, se suele cerrar el fichero de depuración abierto en Init Modelo de diseño En el modelo de diseño adaptamos nuestro modelo de objetos para tener en cuenta: los requisitos temporales capturados en el modelo de requisitos, el HW de que disponemos (su velocidad, su arquitectura...) 12

14 el SW previo que deseamos reutilizar (la trap #15...) Arquitectura del sistema SW La arquitectura de un sistema es el esqueleto o el esquema sobre el que se asienta un sistema y que varía muy poco a lo largo del tiempo, aunque permite que el resto de los módulos no arquitecturales evolucionen. Establece la división del sistema en subsistemas 1 y regula sus relaciones, su ubicación y su sincronismo. Es el primer elemento de todo buen diseño, y debe estar presente desde el primer prototipo. Es frecuente comenzar un sistema diseñando e implementando un primer prototipo que recoge la arquitectura propuesta para el sistema completo, aunque los subsistemas incluidos carezcan de funcionalidad (o dispongan de una funcionalidad elemental muy alejada de la finalmente necesaria). Para establecer los subsistemas (y con ellos la arquitectura), podemos emplear: la intuición: que nos guía sobre qué elementos agrupar y cuáles no; la minimización de las interdependencias y relaciones: a fin de establecer subsistemas que sean bastante autónomos y cuya interfaz sea mínima; agrupamiento funcional: el conjunto de objetos que realizan una función común o un servicio deben pertenecer al mismo subsistema; tener en cuenta nuestro conocimiento del HW: si nuestro sistema se compone de diversas partes HW y SW, sería lógico no agrupar elementos SW que se ejecuten sobre HW diferente y que precisen de protocolos de comunicación; experiencia o bibliografía previa: establecen patrones o arquitecturas-modelo que han resuelto muchos problemas similares previamente y que pueden servirnos de referencia. Algunas arquitecturas son tan conocidas y clásicas como la cliente-servidor (frecuente en comunicaciones), la de capas (como en la torre OSI) y el procesamiento en cascada (típico en sistemas de procesamiento digital de señales). Continuando con el ejemplo que estamos comentando, nuestro análisis de los principales objetos nos da casi directamente la arquitectura, aunque en un sistema de unas ciertas dimensiones esto no ocurre, siendo necesario emplear los diversos criterios de agrupamiento antes mencionados. Sin embargo, no es extraño que, por cada una de las conexiones del sistema con los agentes exteriores, exista un subsistema interfaz para esa conexión, de tal manera que los procesadores queden independizados del modo de intercambiar datos con el exterior (lo cual facilita su simulación e incrementa su portabilidad, por ejemplo). La arquitectura debe ser capaz de soportar: Los requisitos de diseño impuestos por el cliente: como en nuestro caso es el procesamiento síncrono en tiempo real. 1 Un subsistema es un objeto o conjunto de objetos (superobjeto) con una interfaz definida y reducida, que pueden ser tratados como una unidad de cara al resto del sistema. 13

15 Los requisitos impuestos por el HW: por ejemplo, disponemos entradas sensibles a flanco y entradas digitales. El SW disponible previamente (middleware): en nuestro caso el manejo de la pantalla se debe hacer a través de la Trap #15, a fin de no tener que reprogramar la comunicación y perder un tiempo precioso, o los tutoriales sobre el teclado y la placa TL04. TIEMPOS ACUMULADOS TRAMA ACTUAL ALARMAS GENERADAS RELOJES TIEMPOS LÍMITE SEÑAL DE SINCRONISMO Modelo dinámico Figura 5. Diagrama de objetos: arquitectura software. Para describir la evolución de los objetos o los subsistemas a lo largo del tiempo y en función de los eventos producidos, se deben emplear diagramas de transición de estados. Un estado de un objeto se asocia a un valor o combinación de valores de sus propiedades variables, que resulta relevante a la hora de describir su comportamiento dinámico a lo largo del tiempo. Las transiciones entre estados son resultado de la aparición de eventos síncronos o asíncronos, que provocan además la ejecución de una o varias funciones del objeto. Obsérvese que el modelo dinámico forma parte del diseño, dado que se encarga de la temporización y el cómo de la solución del problema planteado. Los objetos Tiempos Acumulados y Trama Actual, tienen una dinámica especial regida por máquinas de estados que a continuación describiremos Tiempo acumulado para cada valor de cada sensor Este objeto va almacenando los tiempos acumulados para cada uno de los posibles valores de los diferentes sensores. Un aspecto muy importante que hay que considerar es que estos tiempos se incrementan cada vez que el sensor ha tenido un valor IGUAL o SUPERIOR al valor considerado y se ponen a cero si el valor actual es INFERIOR al valor considerado. También se deben resetear los tiempos acumulados cuando se haya generado una alarma. El tiempo acumulado se puede medir de dos maneras: Sabiendo que el emisor envía una trama por segundo, cada trama recibida se incrementa en una unidad el tiempo acumulado en segundo. Esta opción es la más sencilla. 14

16 La segunda opción es utilizar el reloj interno del MCF5272 para controlar los tiempos acumulados. En este caso, si consideramos un temporizador interno cada 1ms tendríamos una resolución temporal mayor Trama actual Este objeto contiene el valor de la última trama recibida. Como hemos comentado anteriormente, cada segundo el emisor transmite una trama que es recibida y almacenada en este objeto. Por esta razón, el valor de una trama permanece invariante durante el tiempo que transcurre entre la recepción completa de una trama y el comienzo de la trama siguiente (un tiempo inferior a 1 segundo) Modelo dinámico del objeto reloj La responsabilidad de incrementar o decrementar este objeto u objetos de tipo contador correrá de parte de la interrupción periódica como ahora veremos. El comportamiento del objeto es muy simple (se incrementa o decrementa en cada interrupción) y es consultado por los procesos asociados a los objetos tecla y trama actual, a fin de poder realizar retardos o esperar tiempos. Así por ejemplo, si se implementa una estrategia antirrebotes por SW, este reloj o relojes pueden servir para no leer el teclado durante el tiempo estimado de rebotes Procesos Frecuentemente, los sistemas electrónicos digitales precisan realizar diversas acciones de una manera paralela (concurrente en varios procesadores) o aparentemente paralela (ambas acciones se ejecutan entrelazadamente, produciéndose la apariencia de paralelismo si la frecuencia de conmutación entre ambas es elevada). Son lo que denominamos procesos. La creación, ejecución, sincronización y destrucción entre procesos suele ser facilitada por el sistema operativo a través de diversas primitivas. Pero incluso en ese caso, el diseñador debe definir qué tareas o rutinas serán concurrentes, elegir los mecanismos de comunicación entre ellas, los tiempos de vida, etc. En el SDGII no disponemos de sistema operativo en nuestra placa de desarrollo, pero podemos definir 3 procesos por medio de interrupciones periódicas, interrupciones externas y el programa principal, como se muestra en la Figura 6. Este esquema de procesos es obligatorio. Se puede observar que las funciones asociadas a un mismo objeto no necesariamente se ejecutan en un mismo proceso. Sobre los mecanismos de sincronización en el SDGII, recomendamos la lectura del apartado Desarrollo de software de tiempo real de [5], aunque en este caso el problema se simplifica porque la concurrencia entre procesos que nos vamos a encontrar en este diseño no es por el acceso a un mismo recurso en modo escritura. Por ejemplo la interrupción periódica puede acceder en modo escritura a la variable que contiene las alarmas generadas, mientras que el programa principal accede en modo lectura para presentar por pantalla el mensaje correspondiente. 15

17 Interrupción Periódica Interrupción Externa Programa principal Tiempo Figura 6. Representación temporal de los 3 procesos: programa o proceso principal, interrupción externa e interrupción periódica Proceso principal Siempre existe, y debe inicializar los objetos del sistema, inicializar el HW, habilitar la aparición de interrupciones externas e inicializar el proceso de la interrupción periódica (_init). Los sistemas empotrados de tiempo real suelen contener un bucle indefinido (buclemain) que puede llevar a cabo tareas sin requisitos temporales estrictos, como puede ser en nuestro caso la lectura del teclado y la presentación en pantalla de las diferentes alarmas que se hayan generado. En nuestro caso el bucle del programa principal debería ser simplemente: BucleMain: if (tecladoconsultar ()) { teclaprocesar() } if (HayAlarma) { AlarmaPresentar () } teclaprocesar() { TeclaImprimir() TiempoLimiteActualizar() } AlarmaPresentar () { /*Presenta la descripción de las alarmas ocurridas */ } donde al detectar cada tecla se imprime en la pantalla del ordenador y se presentan las alarmas ocurridas. La rutina general de inicialización sería similar a: Init: swinit() * inicializa el software 16

18 objetosinit() hwinit() * inicializa las variables * inicializa las interrupciones y los puertos Este proceso es el menos prioritario de los tres porque el barrido del teclado o la escritura en la pantalla no son acciones críticas en el tiempo Interrupción periódica Contendrá las funciones críticas en el tiempo; en nuestro caso son las de contar el tiempo, hacer las medidas del bit recibido (cada 10 ms) y decidir el valor del bit recibido por mayoría. Su ejecución es cíclica, discontinua y sucede a intervalos regulares de tiempo; es concurrente con el proceso principal al que puede interrumpir (pero por el cual no puede ser interrumpida). Es el proceso con mayor prioridad de los tres. Esta interrupción es la encargada de controlar la temporización del sistema de la cual depende directamente su correcto funcionamiento. Por esta razón, este proceso debe tener la mayor prioridad de los tres. En nuestro sistema la rutina de atención a la interrupción periódica será: InterrupcionPeriodica: GuardarRegistros() interrreset()... if (MedidasRestantes igual_a UNO){ BitMedir () BitDecidirMayoria () BitGuardar () MedidasRestantes -; NumBit++; } else if (MedidasRestantes mayor_que UNO){ BitMedir() MedidasRestantes-- } if (NumBit igual_a NumBitTrama){ TramaGuardar(); NumBit=0; }... relojesactualizar() RestaurarRegistros() RTE Interrupción externa Esta interrupción se debe producir cada ciclo de reloj del emisor. En nuestro sistema la rutina de atención a la interrupción simplemente debe iniciar las medidas del bit recibido. Para ello basta con poner a 10 la variable MedidasRestantes: InterrupcionExterna: GuardarRegistros() interrreset() MedidasRestantes=DIEZ;... RestaurarRegistros() RTE 17

19 Este proceso debe tener una mayor prioridad que el programa principal para activar la medida de un bit aunque se esté barriendo el teclado o presentando datos en la pantalla, pero debe tener menor prioridad que la interrupción periódica, encargada de controlar la temporización del sistema completo. 5.3 Módulos Adicionales Configuración de alarmas mediante un teclado matricial Este módulo tiene como objetivo detectar y decodificar las pulsaciones del usuario en un teclado matricial de 16 teclas, mostrarlas en la pantalla del ordenador e interpretar las pulsaciones como: secuencias de dígitos: configuración de alarmas (número de aparato/sensor, nivel y tiempo de activación de alarma para cada uno de los aparatos). letras para seleccionar el modo de configuración de alarmas y aceptar la nueva configuración de alarmas definida. Los retardos debidos, por ejemplo, al escribir por pantalla o configurar las situaciones de alarma no deben retardar el sistema de supervisión (requisito de concurrencia y tiempo real). Las teclas que debe aceptar el sistema serán al menos: los dígitos del 0 al 9, la tecla de selección de modo configuración de alarmas (C), la tecla de aceptación de la nueva configuración de alarmas (F), Los posibles casos de uso serían: Los posibles rebotes mecánicos debidos a pulsar el teclado o a soltar una tecla se suprimirán por SW (cada pulsación de una tecla no debe dar lugar a la detección de más de un símbolo). La duración de la pulsación de cada tecla (sea breve o sea larga) no debe modificar la expresión detectada. Si se está en modo configuración de alarmas, cada vez que se pulse una tecla de dígito se mostrará en pantalla el dígito asociado, y se guardará internamente hasta que se pulse la tecla especial: F (aceptación de la nueva configuración de alarmas). Si la configuración de algunos de los aparatos para generar alarma no se modifica se debe mantener el valor anterior. Asignación de teclas estándar: Tabla 1. Asignación de teclas del teclado TECLA 1 1 TECLA 9 9 TECLA 2 2 TECLA 0 0 TECLA 3 3 TECLA A LIBRE 18

20 TECLA 4 4 TECLA B LIBRE TECLA 5 5 TECLA C Configuración de Alarmas TECLA 6 6 TECLA D LIBRE TECLA 7 7 TECLA E LIBRE TECLA 8 8 TECLA F Aceptación de Alarmas Figura 7. Teclado matricial disponible en la placa TL04 de los puestos del laboratorio Para este módulo se recomienda el empleo de un objeto Tecla que represente cada símbolo tecleado por el usuario. Es un objeto activo que implica un barrido del teclado matricial Modelo dinámico del objeto tecla Barrido: inicialmente, debe barrer el teclado hasta detectar la pulsación de una tecla por parte del usuario. Se puede modelar mediante el siguiente sub-autómata: Enviar la excitación a una fila o columna Esperar que la excitación y la consiguiente respuesta se propaguen Analizando la respuesta, detectar si se ha pulsado alguna tecla en esa fila o columna, y en qué columna o fila ha sido la pulsación Si todavía no las hemos recorrido todas, hay que volver al punto 1 (pero cambiando de fila o columna; si se ha llegado a la última fila o columna se debe volver a la primera de una manera circular) Antirrebotes: si se ha detectado una tecla, hay que imprimirla y esperar un cierto tiempo por si hubiese rebotes mecánicos al pulsar Esperar que se suelte la tecla pulsada: una vez pasado este tiempo, hay que esperar que el usuario suelte la tecla (para evitar que una pulsación larga sea interpretada como varias pulsaciones). 19

21 Antirrebotes: una vez se ha soltado la tecla por primera vez, puede que haya que esperar un cierto tiempo por si hubiese rebotes mecánicos al soltar la tecla Ampliación de la funcionalidad por SW Es posible añadir nuevas posibilidades al sistema:... Ampliación del menú de configuración, Estadísticas de funcionamiento: alarmas generadas, causas, etc... Programar la activación o desativación del sistema de monitorización, Modificación de las condiciones de generación de alarmas dependiendo de la hora del día Alarmas dependientes de la franja horaria En este módulo se pretende que las alarmas se generen sólo durante una franja horaria determinada. Para la realización de esta mejora el sistema debe disponer de un reloj interno que se debe inicializar a la hora actual del día. Se proponen como franjas horarias las siguientes: Los sensores de gas y humo podrán generar alarma durante la noche: 22:00 hasta 8:00. El sensor de agua podrá generar alarma durante todo el día Generación de alarmas acústicas mediante el empleo de un DAC En este módulo se pretende que el sistema genere señales sinusoidales mediante un conversor Digital- Analógico (DAC) disponible en la plataforma ENT2004CF. El alumno dispone de un tutorial de manejo del conversor DAC en los puestos del laboratorio, así como su explicación en el capítulo 8 de [3]. La Figura 8 muestra el diagrama de bloques de este módulo. El sistema tendrá que poder emitir varias señales audibles y diferenciables (S out ) en caso de varias alarmas se activen simultáneamente. Las señales deberán generarse mediante el empleo de una interrupción adicional de frecuencia apropiada. Figura 8: Diagrama de bloques del módulo de generación de alarmas acústicas mediante DAC Para más información de cómo implementar los sub-módulos de reconstrucción de señal y de amplificación de potencia lea su descripción en 20

22 5.3.5 Generación de alarmas acústicas mediante temporización o PWM En este módulo se pretende que el sistema genere una señal acústica diferente para cada una de las alarmas generadas sin emplear el DAC. Las señales tendrán que ser audibles y diferenciables en caso de que varias alarmas se activen simultáneamente. La generación de la señal por parte del micro-controlador se puede hacer de algunas de las siguientes maneras: Generación de una señal cuadrada utilizando los temporizadores y un filtrado paso bajo posterior para quedarnos con una señal sinusoidal. Generación de una señal cuadrada utilizando los módulos PWM (Pulse Width Modulation) y un filtrado paso bajo posterior para quedarnos con una señal sinusoidal. El alumno dispone de un tutorial en los puestos del laboratorio, así como su explicación en el capítulo 6 de [3] Ampliación del subsistema de visualización Utilización del LCD (Liquid Cristal Display) de la placa TL04 en lugar de la pantalla del ordenador para mostrar mensajes. Un ejemplo de utilización se puede consultar en el ejemplo teclado_lcd.c o teclado_lcd.asm que se muestra en el tutorial de manejo de la placa TL04. Se valorarán detalles adicionales como: La inclusión de emoticonos o símbolos desarrollados por el alumno empleando las posibilidades que le ofrezca el LCD Implementando un scroll por medio de un buffer que guarde las últimas líneas impresas (el LCD sólo puede mostrar a la vez 2 líneas de texto) etc Comunicación con un sistema digital comercial para el envío de alarmas Dado que la plataforma incluye un puerto serie asíncrono RS-232, podemos enviarle órdenes desde un HW comercial y visualizarlos en el mismo (además de enviarlos a nuestra pantalla). Así podríamos emplear y programar una calculadora HP (48 o 49), una PDA (Palm) o un ordenador portátil. Para ello debemos programar adecuadamente el puerto serie del MCF5272 siguiendo los manuales del fabricante, y conectar los puertos serie de ambos sistemas digitales mediante un cable de módem nulo Comunicación serie utilizando la UART En este caso se propone utilizar alguna de las UARTs disponibles en el ColdFire para recibir la trama con la información del estado de los sensores a través del puerto serie asíncrono RS-232. Una consideración importante es que el emisor debe generar un régimen binario y una trama siguiendo algunas de las posibilidades ofrecidas por el periférico UART del ColdFire. 5.4 Codificación Una vez que, tras el diseño, disponemos de los modelos estáticos y dinámicos, llega el turno de convertir nuestras ideas y modelos en código ejecutable, y la dependencia del lenguaje de programación es completa. 21

23 Las normas de codificación en ensamblador de rutinas con paso de parámetros, se pueden encontrar en [5]. A la hora de codificar debe tener en cuenta los criterios de calidad establecidos en la asignatura: La estructura general del programa debe responder a lo comentado en la sección de [5]. Cada subrutina debería tener un único punto de comienzo y un único punto de terminación, y no debería entrelazarse con otras subrutinas (según se comenta en el documento [7]). Debería emplear un buen número de subrutinas (que le ayuden a dividir cada problema en subproblemas), y que no resulten muy extensas (y por lo tanto difíciles de entender y depurar). Algunas subrutinas recomendadas se han incluido a lo largo de este enunciado. Debe emplear constantes EQU que permitan reconfigurar fácilmente el sistema (las instrucciones deberían no usar números mágicos). Ejemplos típicos podrían ser: Una constante que permita fácilmente variar la frecuencia de las interrupciones temporizadas (FREQ_INT EQU...) Una constante para modificar el retardo entre las fases de excitación y respuestas del teclado (RET_TECL EQU...). Debe emplear modos de direccionamiento variados y apropiados (indexado, indirecto, post-incremento...) y usar estructuras de datos que agrupen datos interrelacionados y que faciliten la implementación (buferes, tablas de valores...). Emplear estas técnicas suele producir código más compacto y elegante, evitándose frecuentemente el abuso de la desaconsejable técnica de copiar, pegar y modificar. Debe incluir comentarios orientativos en el código (comentarios que aporten información al que los lea, no que se limiten a parafrasear el código). Un ejemplo paradigmático de un mal comentario es: 5.5 Optimización ADD.L #1,D0 * incrementa el contador Aunque la optimización del código (en cuanto a consumo de memoria o de tiempo de CPU) no se puede llevar a cabo hasta la fase de implementación, un mal diseño o una mala arquitectura pueden hacer imposible esta labor en la fase de implementación, obligando a una reconsideración del diseño. Así si nuestra arquitectura realizase la recepción de los bits en el programa principal, los requisitos de temporización de esta tarea serían muy difíciles de cumplir y se podría producir una recepción incorrecta de los bits: al tratarse de un defecto estructural, cualquier optimización puede estar condenada al fracaso si no revisamos la arquitectura. Aunque este no es nuestro caso (y la arquitectura propuesta puede satisfacer los requisitos del enunciado), dado que en el SDGII las prácticas son de tiempo real, no es extraño que el alumno se vea obligado a emplear una o varias de estas estrategias de optimización para conseguir solucionar el problema planteado por el enunciado. 22