SAT – Sistema Automático de Testeo · El SAT permite el control y monitoreo remoto de DUTs ......
Transcript of SAT – Sistema Automático de Testeo · El SAT permite el control y monitoreo remoto de DUTs ......
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.