sat – sistema automático de testeo · el sat permite el control y monitoreo remoto de duts ......

39
8. REVISTA DA SECÇÃO REGIONAL DO CENTRO DA ORDEM DOS MÉDICOS 2,00 · TRIMESTRAL · Nº 08 · AGOSTO 2018 MD Cultura · P. 61 Exposição ‘Transplantação’ MD Entrevista · P. 32 Grande entrevista com o Dr. Carlos Cortes, Presidente da Secção Regional do Centro da Ordem dos Médicos SNS · P. 42 Serviço Nacional de Saúde

Upload: buianh

Post on 11-Nov-2018

217 views

Category:

Documents


0 download

TRANSCRIPT

SAT – SISTEMA AUTOMÁTICO DE

TESTEO

Renzo Caballero - Gonzalo Carozo - Ma Cecilia Costa

Proyecto

sistemas

embebidos 2015

Instituto de Ing. Eléctrica

Facultad de Ingeniería

UdelaR

Tutor: Conrado Rossi

1

Resumen

Este documento especifica la primera implementación del SAT (Sistema Automático

de Testeo). El SAT permite el control y monitoreo remoto de DUTs (Dispositivos bajo

testeo) desde una PC. Se le atribuyen las siguientes características:

Controlable vía USB

16 salidas digitales de control

16 entradas digitales de monitoreo y muestreo

Preparado para comunicación UART y SPI (con el DUT)

Reloj en tiempo real con consulta de hora

Dos relojes configurables

Sistema de seguridad que impide el comienzo del monitoreo sin la previa

configuración del resto de las características

Se configuraron e implementaron funciones por módulos para cumplir con los

requerimientos y se hizo una abstracción de HW de los módulos para que sea más fácil

portarlos a otras familias de microcontroladores.

En el transcurso del proyecto se fueron testeando los módulos por separado y luego

se hizo una última prueba para testar todos los módulos trabajando en conjunto.

El resultado de las pruebas fue satisfactorio, cumpliéndose con todas las especificaciones

requeridas excepto la comunicación SPI. Se consiguió una frecuencia máxima de

muestreo de 10 Hz. Aunque en primera instancia no se consideraron requerimientos de

velocidad, es una de las mejoras a implementar para futuros usos.

2

Tabla de Contenido

Resumen ………………………………………………………………………………………………………………………………….1

Introducción ................................................................................................................................. 3

Objetivos ...................................................................................................................................... 3

Alcance ......................................................................................................................................... 3

Diseño ............................................................................................................................................ 4

Implementación ............................................................................................................................ 5

Pruebas ........................................................................................................................................ 12

Resultados ................................................................................................................................... 12

Conclusiones ............................................................................................................................... 14

Cosas a mejorar ........................................................................................................................... 14

Referencias .................................................................................................................................. 15

Anexo .......................................................................................................................................... 16

Pines usados …………………………………………………………………………………………………………..…16

Conceptos del curso aplicados…………………………………………………………………………………...16

Planificación del proyecto………………………………………………………………………………………….17

Especificación del proyecto………………………………………………………………………………………..18

Documentación en doxygen……………………………………………………………………………………….20

3

Introducción

El grupo de microelectrónica de la Facultad de Ingeniería diseña y manda a fabricar circuitos integrados que deben ser sometidos a testeos. Actualmente los tests son realizados manualmente, lo que lleva tiempo y puede generar más errores.

Esto impulsó el desarrollo del SAT, que permite el control y monitoreo remoto y

automático de los chips.

Objetivos

El objetivo de este proyecto es implementar un módulo auxiliar para testeo de

dispositivos de uso interno del Instituto de Ingeniería Eléctrica.

Se realizará un dispositivo que facilite la comunicación entre una PC y lo que se

desee testear (Device Under Test), comandando periféricos y pines para obtener un

sistema que se comunique y controle de forma remota el DUT.

Alcance

Se definirán un conjunto de comandos adecuados para la implementación de los

requerimientos. Se programará y se verificaran todas las funciones.

4

Diseño

La arquitectura de software elegida fue Round Robin con interrupciones, ya que

se trata de una arquitectura simple que cumple con todas las funciones que

pretendemos implementar. Se prioriza el muestreo del DUT, ya que es fundamental

almacenar información en tiempo real.

La interrupción de timer muestrea los puertos y luego el Round Robin maneja los

comandos de la Shell (módulo encargado de la comunicación entre PC y SAT) y despliega

las muestras en pantalla.

Se prioriza la comunicación USB-UART por sobre las demás comunicaciones.

El hardware que se utiliza consta de un LunchPad MSP430G2553 que hace de

interfaz USB-UART entre la PC y un MSP430F5438 como SAT. Esta placa cuenta con un

oscilador de cristal de 32768Hz el cual fue utilizado como reloj fuente para el timer del

microcontrolador.

Fig. 1 Set up

5

Implementación

Se utilizó el entorno IAR Embebbed Workbench para escribir el código del

programa, hacer el debug y correrlo. Utilizamos una estructura por módulos como se

detalla en la Fig. 2. El main como programa principal que maneja los comandos del Shell,

en jerarquía siguen los módulos reloj, que son los que manejan las interrupciones y los

tiempos y luego los módulos de comunicación, cadena, entrada y salida. Por último se

simboliza la abstracción de HW de cada módulo como un bloque separado.

A continuación se describen los módulos y su implementación.

MÓDULO SHELL: Se adaptó el Modulo Shell que ya estaba implementado del obligatorio Sisem

2011 para que corra en el main de nuestro proyecto y que maneje los mensajes que se

transmitan y reciban por la UART, evitando usar funciones de bibliotecas como stdio.h

que nos requerían espacio de código. Además implementamos el comando HELP que

despliega una breve descripción de la función y los parámetros a usar.

Este sistema funciona con una lista de comandos que pueden ser llamados desde

la PC y que llaman a su función de implementación correspondiente de la siguiente

manera:

{"COMANDO_PC", "Descripción de la función", FuncionAimplementar},

La función a implementar debe contar con un formato particular para que la Shell pueda

extraer sus parámetros:

donde argc es la cantidad de entradas del comando (el comando + parámetros) y argv

es un puntero a los parámetros. Una vez dentro de la función los parámetros se extraen

como char bit = *argv[x], con x>0 ya que el primer argumento es el comando en

Fig. 2 diagrama de bloques del SAT

6

sí. Dicha función devuelve un int OK o int ERROR si pudo ser implementada

correctamente o no.

La fig. 3 es un diagrama de cómo funciona la Shell. Toma el mensaje de la

comunicación UART y separa el comando, la cantidad de argumentos que contiene el

mensaje y los argumentos. Si existe devuelve OK y la función se ejecuta, si no lo

encuentra despliega “Función no encontrada” en pantalla y en el caso de que el comando

sea EXIT, despliega “No existe EXIT” (función a ser implementada).

MÓDULO MAIN: El módulo main es el modulo principal de nuestro programa que, utilizando Round

Robin, se encarga de manejar los comandos del Shell y de despegar las muestras en pantalla si

las hay.

Fig. 3 codigo ejemplo del main

Fig. 4 Codigo ejemplo del main

7

En primera instancia se inicializa el timer, la comunicación UART con la PC y la

cadena donde se guardaran los puertos a muestrear; se habilitan las interrupciones y se

entra al loop principal. Además de los bytes de comunicación, se chequean 2 banderas: si

hay elementos en la cola de muestras (esto implica que ya se comenzó el muestreo) y si

hay un comando desde la PC para implementarse.

MÓDULO ENTRADA: Este módulo agrupa las funciones de configuración de los puertos de entrada P1

y P2. Consta de 4 funciones1:

Las primeras 2 funciones configuran el puerto entero o solo un bit como puerto

de entrada. Además se puede configurar si se desea una entrada sea pull up (1) o pull

down (0).

Se utiliza la Tabla 1 del User’s Guide de la familia para la configuración tanto de

puertos de entrada como de salida.

El requerimiento de lectura de un puerto implica que una vez leído el puerto se

despliegue en pantalla dicha lectura; además para el muestreo se debe leer el puerto

pero no desplegar en pantalla. Por lo que la función lecturaPuertoEntero() llama a

leerPuerto() y envía vía UART la lectura para que sea desplegada. En cambio cuando

se muestrea simplemente se llama a la función leerPuerto().

1 El encabezado de las funciones son como se explica en el módulo main, de aquí en adelante en vez de argv y argc se explicitan los parámetros para la mejor comprensión del lector.

PXDIR PXREN PXOUT I/O CONFIGURATION

0 0 x Input

0 1 0 Input with pulldown resistor

0 1 1 Input with pullup resistor

1 x x Output

Tabla 1 Configuración I/O

8

MÓDULO SALIDA: Este módulo agrupa las funciones de configuración de los puertos de salida que

serán P6 y P7. Las funciones que implementa son:

Se implementa una función que escribe un byte en uno de los puertos de salida

(requerimiento) mientras que las otras 2 configuran el puerto de salida entero o por bit.

Se configura el pull up o pull down ya que no hay opción a configurar la salida como open

drain o tótem pole (como se plantea en los requerimientos –ver anexo-). Se utiliza la

tabla 1 para las configuraciones.

MÓDULO RELOJ CONFIGURABLE: Aquí se implementa una función que configura un reloj de frecuencia variable. El

MSP430f5438 cuenta con 3 timers de 16 bits (A0, A1 y B0). El timer A0 se utiliza como

fuente para el modulo RTC y es el que genera las interrupciones. Los otros 2 timers

fueron configurados para obtener señales de reloj externas.

La función

recibe que timer se desea configurar (0/1) y la frecuencia del mismo (1 a 8 kHz). Se utilizó

el modo Up para ambos timers y Toggle como modo de salida. Como se ve en la Fig. 5

dicho modo crea una onda cuadrada de la mitad de la frecuencia elegida, por lo que

optamos por duplicar la frecuencia recibida.

Fig. 5 Modo de configuración del timer

9

MÓDULO RELOJ Y RELOJ_HW: Este módulo es la adaptación del módulo RTC del laboratorio 6. Se hizo la

abstracción de HW correspondiente quitando la inicialización del timer A0 (se

modificaron los registros internos ya que el MSP usado es de una familia diferente) y se

modificó el período de interrupción del timer para poder muestrear a mayor velocidad.

Las funciones agregadas al módulo RTC fueron:

iniciarTimerA() y pararWatchDog() llaman a las funciones iniciarTimerA_HW() y

pararWatchDog_HW() en módulo Reloj_HW. WH() y WP() setean la hora (utilizando la

función inicializar() del lab3) y el período de las interrupciones respectivamente;

mientras que RH() y RP() leen el valor de la hora y el período y lo despliegan en pantalla.

En el módulo RTC_HW se encuentra el vector de interrupciones usado para

incrementar el reloj en tiempo real y hacer el muestreo de puertos. Vemos en la Fig. 6 como se

implementa, chequeando que ya este habilitado el muestreo.

MÓDULO UART SPI

Agrupa las funciones de comunicación con el DUT y de multiplexado de entradas.

Tiene las siguientes funcionalidades:

Fig. 6 Código ejemplo de la interrupción de A0

10

1. Permite configurar la comunicación UART con el DUT a frecuencias estándar

(1200, 2400, 4800, 9600 baudios), o con detección automática de frecuencia.

Permite setear las características: Paridad, MSBfirst, dataBits y stopBits.

2. Permite configurar la SPI para comunicación con el DUT o para el multiplexado de

entradas. Setea las características: divisorReloj, Fase, Polaridad, Master, cantBits

y MSBfirst.

3. En caso de que el DUT envíe un byte, este se reenvía al PC.

Para enviar un mensaje:

Los mensajes que se envían pueden ser variables (por ejemplo el muestreo), o

definidos (como el “help” de una función). Para los mensajes variables el SAT usa los

string mensajeEnviar[] y mensajeEnviarDUT[] que almacenan los bytes mientras

están siendo enviados, mensajeEnviar[] corresponde a la comunicación USB-UART y

mensajeEnviarDUT[] a las comunicaciones SPI y UART. Antes de enviar un mensaje, el

SAT debe cargarlo en el string correspondiente.

La función enviarMensaje(string, x), es la encargada de comenzar la

transmisión, donde “x” determina el canal de comunicación (0=PC; 1=UART; 2=SPI).

Primero espera a que se terminen de enviar mensajes anteriores. Luego, comienza a

transmitir, enviando el primer byte y habilitando las interrupciones de transmisión (TX).

Cuando llega una interrupción de TX, se setea una bandera o se llama directamente

(según la prioridad de la comunicación), a la función manejarByteTX(x). Esta inicia la

transmisión del siguiente byte o termina la transmisión en caso de detectar el byte final

(“\r”).

Para recibir un mensaje:

Los mensajes pueden llegar desde la comunicación USB-UART, SPI o UART.

Para recibir mensajes el SAT dispone del string mensajeGuardado[], donde se

almacenan temporalmente los comandos que llegan de la PC. Para la comunicación SPI o

UART no se almacenan los mensajes, cuando llega un byte, directamente es enviado a la

PC.

Cuando se da una interrupción de recepción (RX), se setea una bandera o se llama

directamente (según la prioridad de la comunicación), a la función

manejarByteRX(x). Esta guarda el byte en mensajeGuardado[] y en caso de

detectar el byte final setea la bandera mensajeDisponible, que indica que hay un

mensaje disponible esperando ser procesado.

11

MÓDULO CADENA: El modulo Cadena reúne todas las funciones que se relacionan con la obtención,

guardado y despliegue de las muestras.

El módulo contiene el arreglo en el que se almacenan las muestras cuando el

timer interrumpe. Al muestrearse dos canales (cada uno de 8 bits) es necesaria una

estructura de por lo menos 16 bits. Cada vez que se guarda una muestra se guarda

también un “timestamp”, por lo que se le agrega a dicha estructura una cantidad de bits

correspondiente a 4 enteros (horas, minutos, segundos y milisegundos). El arreglo es

implementado como una cola circular de tamaño 10 muestras, sobrescribiendo valores al

llenarse y avisando cuando las sobre escrituras ocurren.

También está encargado de desplegar la información del arreglo, pudiéndolo

hacerlo como una estructura del tipo muestra (Extraer_Muestra()) o como un

arreglo de caracteres más comprensible (Mostrar_Muestra_en_PC_Binario()). Para

desplegar en pantalla lo hacemos como el arreglo de caracteres.

La función que guarda las muestras en el arreglo está implementada para que no

se guarden redundancias, compara el último dato guardado con la nueva muestra y

almacena solo si son diferentes.

La función ComienzaMuestreo es la llamada al recibir el comando MUESTREAR

desde la PC, y se encarga de confirmar que todos los parámetros necesarios fueron

configurados utilizando el bytecontrol para setear la flag que habilita el muestreo

durante la interrupción. El byte de control asegura que esté configurada la hora, el

período de muestreo y los puertos de entrada. En caso contrario se despliega un mensaje

de alerta en pantalla.

Fig. 7 Definición del tipo Muestra

12

Pruebas

Comunicación PC y shell: Se enviaron comandos usando el software Realterm y

se verificaron las respuestas esperadas.

Reloj de Tiempo Real: Se verificará que el reloj interrumpa en el intervalo

esperado comparando el reloj del SAT con el reloj de la PC.

Reloj configurable: Se utiliza un osciloscopio para ver los pines de salida de los

relojes y corroborar su frecuencia.

Para realizar las pruebas de entradas, salidas, muestreo y comunicación se utilizó

un SAT modificado, que emuló el comportamiento de un DUT.

El DUT (SAT modificado) periódicamente escribe sus puertos de salida y manda

bytes por UART y SPI. El SAT deberá muestrear estos cambios en sus puertos de

entrada y recibir correctamente los bytes que envía el DUT. Se aumentará la

velocidad de muestreo para ver el funcionamiento del almacenamiento de

muestras y la velocidad máxima de muestreo.

Resultados

Comunicación PC: OK. Las respuestas fueron las esperadas.

Reloj: OK

Modulo Entrada: OK. El SAT muestreó las entradas esperadas.

Modulo Salida: OK. El SAT muestreó las salidas esperadas. Además se utilizó un

tester para corroborar que los pines activados estén a VDD y los desactivados a

GND.

Fig. 8 Diagrama de prueba general

13

Reloj configurable: OK. Se vieron los relojes funcionando a las frecuencias

deseadas.

Muestreo: OK. El SAT muestreó las salidas

esperadas. Se verificó el correcto

funcionamiento del almacenamiento de

muestras (que alertó de la sobre escritura de

muestras). La velocidad máxima de

muestreo fue de 100 ms. El limitante de la

velocidad de muestreo fue la comunicación

USB con la PC elegida (1200 bps), ya que la

cola no se vaciaba lo suficientemente rápido.

Para próximas implementaciones se sugiere

aumentar la frecuencia de comunicación

USB-UART. Fig. 9 Implementación del muestreo

Comunicación UART: OK. El SAT recibió y mandó vía USB-UART los bytes

esperados.

Comunicación SPI: FALLO. Los bytes SPI no fueron recibidos. Se debuggueó sin

encontrar el problema. Se realizarán posteriores testeos con osciloscopio.

14

Conclusiones

• Se generó una primera versión funcional del SAT. Esta versión cumple con el objetivo

del proyecto de controlar y monitorear de forma remota un DUT. Se definieron las

mejoras que se deberán hacer para futuras versiones.

• Se cumplieron los requerimientos iniciales con excepción de la comunicación SPI.

• Logramos aprender a usar e implementar funciones esenciales de un

microcontrolador, tales como el Reloj, la comunicación UART y SPI, periféricos y pines

de entrada y salida.

• La planificación del cronograma fue distinta a la esperada. Para próximos proyectos se

debería tener en cuenta la división de tareas por integrantes del grupo, trabajando en

paralelo (que disminuyó el tiempo de implementación), y asignarle más tiempo a la

realización de los test.

• Encontramos el proyecto muy interesante sobre todo por su utilidad, y por su relación

con nuestro proyecto de fin de carrera.

Cosas a mejorar

Muestreo y despliegue de datos

Nunca verificamos la velocidad máxima real de muestreo, nos conformamos con una

velocidad máxima de una muestra cada 100 ms. Además cuando intentábamos alcanzar

nuestra velocidad máxima, la cola comenzaba a sobrescribirse. Esto se debía al tiempo que le

llevaba al integrado desplegar en pantalla el arreglo de caracteres correspondiente a la

muestra más antigua.

Si quisiéramos verificar la velocidad máxima haríamos las siguientes adaptaciones:

- Aumentar al máximo la velocidad de comunicación USB-UART con la PC.

- El tiempo en que se toma cada muestra no lo guardaríamos en 4 enteros, sino

que podríamos usar 4 caracteres o un solo entero que almacene los ticks del timer

en lugar de una hora visible (esto además haría que el arreglo de muestras ocupe

menos espacio en la RAM, permitiéndonos ampliarlo).

- En lugar de desplegar un total de 30 caracteres en pantalla, podríamos reducir

ese valor a un carácter por cada canal, más la cantidad de caracteres necesaria para

la hora, pudiendo en primera instancia ser menor a 6 caracteres. De esta manera

pasamos de desplegar 30 caracteres a solo desplegar 8. Esto aceleraría la velocidad

con la cual la cola se vacía y a priori aumentaría la velocidad máxima de muestreo.

15

- Podríamos no querer desplegar en pantalla los valores de los canales y en su

lugar, podríamos querer almacenarlos en otro sitio para luego (por ejemplo)

graficarlos, para eso el módulo Cadena tiene una función especial que vacía la cola y

devuelve la muestra en su forma real, esto nos ahorraría el tiempo en el que se

transforma la muestra en caracteres.

Si hacemos todo lo anterior, la información de los canales y el reloj es almacenada de

forma rápida y eficiente. Además la cola es vaciada de la forma más veloz posible. Con las

condiciones anteriores, podremos recién ahí verificar la velocidad máxima de muestreo

alcanzable por nuestro software con el hardware correspondiente.

Comunicación SPI

Queda pendiente hacer funcionar la comunicación SPI.

Módulos Entrada y Salida

Por más de haber alcanzado las especificaciones, el MSP430f5438 utilizado como SAT

tiene hasta 87 pines de entrada/salida. Por lo tanto, con ese hardware, es posible definir un

número aún mayor de entradas y salidas al de las especificaciones de nuestro proyecto.

Referencias

http://www.ti.com/lit/ds/symlink/msp430f5438.pdf http://www.ti.com/lit/ug/slau208o/slau208o.pdf (User´s Guide)

Anexo:

1. PUERTOS USADOS

PUERTO BIT DESCRIPCION

P1 0..7 PUERTO DE ENTRADA

P2 0..7 PUERTO DE ENTRADA

P3 4 TX UART -PC

5 RX UART -PC

6 RELOJ UART

P4 0 RELOJ CONFIG. TIMER B0

P5 6 TRANSMISIÓN UART - DUT

7 RECEPCIÓN UART -DUT

P6 0..7 PUERTO DE SALIDA

P7 0..7 PUERTO DE SALIDA

P8 5 RELOJ CONFIG. TIMER A1

P9 0 RELOJ SPI

4 UCA2TX

5 UCA2RX

16

2. CONCEPTOS DEL CURSO APLICADOS AL PROYECTO Round Robin con interrupciones: elegimos esta arquitectura ya que tenemos

eventos que atender pero con poca prioridad (comandos del shell) y los eventos

que deben ser realizados en tiempo crítico (muestreo de puertos e incremento de

la hora) son disparados por interrupciones y realizadas en ISR. Así priorizamos el

muestreo de los puertos y el resto de los comandos se pueden realizar sin

requerimiento de tiempos.

Masks: se utilizaron mascaras para hacer más compacto el código de configuración

de los puertos.

Inicialización de timer: Utilizamos el código de configuración del timer A0 que

implementamos en el laboratorio modificándolo para el nuevo micro.

UART: Se utilizó el protocolo UART para la comunicación con la PC para poder usar

como interfaz UART-USB el LunchPad MSP430g2553.

Cola circular: La cola circular es muy similar al a que vimos en los laboratorios, en

primera instancia se intentó algo más sofisticado que lograra una independencia

del hardware y un máximo aprovechamiento de la memoria RAM pero el mismo

hardware utilizado nos limitó (en particular por no poder utilizar la función

“malloc” de C).

Modularización: Se crearon módulos que agrupan funciones relacionadas entre sí.

A su vez, de ser requerido, a cada módulo se le creó su correspondiente módulo de

Hardware, en el que se escribió exclusivamente el código dependiente de

Hardware.

3. PLANIFICACIÓN DEL PROYECTO:

El cronograma fue hecho sin demasiada información a priori por lo que sabíamos

que el tiempo de trabajo de cada módulo podía ser diferente. Nos llevó menos tiempo

del estimado adaptar los módulos utilizados en los laboratorios y el Shell pero nos

tomó mucho tiempo diseñar e implementar las pruebas y luego debuggear para que

todo funcionara. En eso se equilibró el tiempo.

Cada uno le dedico 20hs aproximadamente al proyecto (no habíamos hecho

estimación de horas).

17

4. ESPECIFICACIÓN DEL PROYECTO Nombre del proyecto: SAT (Sistema Automático de Testeo)

Integrantes: Renzo Caballero, Gonzalo Carozo, Ma Cecilia Costa

Tutor: Conrado Rossi

• Descripción del problema a ser resuelto:

La verificación de un dispositivo requiere controlar y manejar señales, en particular digitales,

sobre todo para automatizar el proceso de medida. A veces la cantidad de señales es mayor a la

cantidad de pines disponibles por lo que se requiere multiplexar las señales tanto de entrada

como de salida.

• Antecedentes:

Las pruebas que se le hacen a los integrados diseñados por el grupo de microelectrónica de

la facultad a veces tienen un gran número de pines que comandar. En particular nos ayudará a

probar nuestro proyecto de fin de carrera.

• Objetivos del proyecto:

El proyecto generará un dispositivo auxiliar para testeo de dispositivos para uso interno del

Instituto de Ingeniería Eléctrica. Se realizará un dispositivo que facilite la comunicación entre una

PC y un dispositivo que se desea testear (Device Under Test), comandando periféricos y pines.

Servirá como intermediario entre la PC y el dispositivo bajo prueba. A través de un puerto USB se

van a dar y recibir datos tanto de configuración como de uso.

• Alcance del proyecto:

Se definirán un conjunto de comandos adecuados para la implementación de los requerimientos.

Se programará y se verificaran todas las sus funciones.

• Descripción del sistema:

Se usará una interfaz UART como canal de entrada y salida para comunicar un

terminal con el dispositivo a través un conversor UART-USB.

Tendrá un módulo de reloj de tiempo real (RTC) con consulta del valor del

contador para ver fracciones de segundo

Módulos (posiblemente 3) de reloj con frecuencia y duty cycle configurable.

Salidas: se controlarán pines por separado (se pueden ver como puerto paralelo)

con configuración individual, si se usa o no y como (tótem pole u open drain); se podrá

setear puerto entero o de a 1 bit por vez

Entradas: serán de 8 bits configurables, especificando si tienen pull up o pull

down bit a bit. Se implementarán comandos de lectura y escritura bajo demanda (puerto

o bit); muestreo de canales habilitados (se almacena la información y mientras no haya

cambios permanece igual, si cambia algo se guarda y deja un timestamp-se

implementara una cola circular-)

Se podrá configurar vía PC los puertos de entrada/salida y el tiempo de muestreo

de las señales que se quiera adquirir del DUT.

Permite comunicación SPI y UART con el DUT.

No se podrá usar el dispositivo sin que estén todos los puntos anteriores

configurados totalmente

18

• Diagrama de bloques:

• Requerimientos y restricciones del sistema:

• Procesamiento y memoria: Buffer de almacenamiento de datos

• Tiempos de respuesta: no hay requerimientos de velocidad.

• Diseño preliminar:

• Plataforma de hardware: MSP4305438 y un Launchpad para la adaptación USB-

UART

• Arquitectura de software: Round Robin con interrupciones. Evaluando las

funcionalidades de nuestro sistema vemos que dicha arquitectura es la más simple

que cumple con todos los requerimientos del sistema, por ejemplo, hay tareas que

requieren más prioridad que otras.

• Planificación:

• Cronograma con actividades/tareas

Semana 1:

Definir comandos a implementar

Integrar el Shell a nuestra interfaz ya empezada a partir de los laboratorios

Estudio del MSP4305438

Semana 2:

Inicialización de HW (configurar los 2 tipos de comunicaciones UART y SPI) y prueba

Adaptar Modulo RTC del laboratorio y prueba

Módulo reloj configurable y prueba

HITO INTERMEDIO

Semana 3:

Módulo de configuración de pines E/S y prueba

19

Interrupciones de almacenamiento de datos muestrados y timestamp y prueba

Semana 4:

Abstracción de HW

Tests finales

• Pruebas a realizar:

Funcionalidades de cada módulo

Testeo final implementando 2 estaciones de testeo comunicándose entre si

5. DOCUMENTACIÓN GENERADA EN DOXYGEN

Se anexa documentación en html.