Memoria de proyecto de Sistemas Embebidos

Emulador AFE

Federico Nin, Santiago Radi, Federico Silva Tutor: Leonardo Steinfeld

Resumen Este proyecto consistió en programar un microcontrolador que emulase el comportamiento de la comunicación SPI del adquisidor de señales biológicas RHD2132 a nivel funcional. Éste chip filtra, amplifica y convierte de analógico a digital las señales recibidas en sus 32 canales en un número de 16 bits. En este proyecto se simularon las respuestas que debe dar el mismo a los comandos correspondientes. También se programó una interfaz, la cual se encarga del manejo del chip, proveyendo una API de alto nivel para funciones de conversión y configuración.

1

Índice

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

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

Descripción del problema…………………………………………………... 3

Antecedentes………………………………………………………………… 4

Objetivos…………………………………………………………………………….... 5

Alcance………………………………………………………………………………... 5

Diseño……………………………………………………………………………….... 5

Hardware……………………………………………………………………... 6

Emulador, esclavo SPI (MSP430)………………………………………….. 6

Microcontrolador maestro SPI (MSP430)...................................................

8

Implementación………………………………………………………………………. 13

Emulador, esclavo SPI (MSP430)………………………………………….. 13

Microcontrolador maestro SPI (MSP430)...................................................

17

Problemas encontrados……………………………………………………………... 21

Casos de prueba…………………………………………………………….............. 24

Emulador, esclavo SPI (MSP430)………………………………………….. 24

Microcontrolador maestro SPI (MSP430)...................................................

26

Conclusiones…………………………………………………………….................... 27

Referencias………………………………………………………….......................... 28

Anexo……………………………………………………………................................ 29

Conceptos del curso aplicados…………………………………………….. 29

Especificaciones del proyecto……………………………………………… 30

Planificación del proyecto…………………………………………………… 34

Lista de archivos fuente…………………………………………….……….. 35

2

3

Introducción Descripción del problema

La detección de señales biológicas requiere amplificadores muy especializados, los cuales son en general muy costosos debido a los requerimientos que se les exigen. En el marco del proyecto de fin de carrera wEEG, se diseñó una placa que integra dos de estos adquisidores de señales biológicas, junto con un microcontrolador que se encargará de recibir y procesar las señales. Sin embargo, debido al costo de los chips resulta deseable tener un emulador de los mismos, capaz de repetir su comportamiento a nivel funcional a los efectos de debuggear, testear el funcionamiento del microcontrolador maestro y evitar daños sobre los chips, principalmente el daño que se pueda causar en los chips RHD2132 que se pretende simular.

En ese contexto se desarrolla este proyecto, el cual implica la programación de dos MSP430G2553 para emular dos chips RHD2132 y de un MSP432P401 que hace de interfaz entre una computadora y el chip. En lo siguiente se explica la implementación de los mismos y los resultados de la pruebas realizadas. La Figura 1 resume lo mencionado anteriormente, incluye los nombres de los chips involucrados y su comunicación entre ellos.

Figura 1: Esquema de comunicación de los chips a utilizar en el proyecto y cómo se comunican entre ellos.

La comunicación será bidireccional puesto que el maestro enviará comandos para configurar a los esclavos, y los esclavos responderán en función de lo solicitado por el

4

maestro. En la siguiente figura se da un diagrama de tiempos provisto por el fabricante, con un ejemplo de un ciclo de comunicación SPI.

Figura 2: Diagrama de tiempos SPI del RHD2132

Finalmente, se incluye un diagrama de tiempos mostrando los comandos y cuándo son sus respuestas. Este diagrama es importante para entender el comportamiento del RHD2132, así como para emularlo correctamente.

Figura 3: Diagrama de tiempos de comandos para el RHD2132

Antecedentes

Actualmente existe un proyecto de investigación dentro del IIE con financiación del CSIC con el objetivo de desarrollar un sistema de medición de señales encefalográficas con fines de investigación. Dentro de este proyecto se encuentra el proyecto de fin de carrera wEEG (Santiago Radi, Franco La Paz y Martín Causa) que consiste, como se dijo anteriormente, en el diseño de una interfaz neuronal utilizando el chip RHD2132. Éste proyecto se incluye dentro del proyecto wEEG a los efectos de simulación y programación final de la interfaz que se usará en wEEG (MSP432P401).

5

Objetivos El primer objetivo es emular el comportamiento del chip RHD2132 de Intan Technologies con un MSP430G2553, para proveer una plataforma de testeo de software para el microcontrolador maestro. En segundo lugar, programar como maestro a un MSP432, capaz de recibir los datos enviados por estos chips y de transmitir comandos válidos a estos. Se desarrollan bibliotecas que permitan la configuración y adquisición de datos de forma transparente desde el microcontrolador

Alcance del proyecto De acuerdo con los requerimientos del RHD2132, la comunicación se implementa vía SPI de 16 bits, lo que en este proyecto implica resolver dicha comunicación en ambos microcontroladores. Desde los MSP430 (esclavo de la comunicación SPI), se emulan todas las funciones propias del RHD2132, respondiendo de manera acorde según cada caso. Desde el MSP432 (maestro de la comunicación SPI) se programan las funciones de adquisición de canales y configuración particular de cada RHD2132, con el objetivo de crear una API de alto nivel que facilite el funcionamiento. Queda por fuera del proyecto el procesamiento de datos recibidos y la comunicación UART, la cual es parte del proyecto de fin de carrera wEEG.

Diseño Hardware La Figura 4 muestra un esquema de la comunicación Hardware entre todos los dispositivos implicados en el proyecto

Figura 4: Diagrama de la comunicación Hardware entre los dispositivos implicados en el proyecto

6

Para la comunicación SPI del lado de los esclavos se utilizaron los siguientes pines: 1.1 MISO (master input slave output) 1.2 MOSI (master output slave input) 1.4 CLK (reloj del sistema) Para la comunicación SPI del lado del maestro se usaron dos puertos SPI independientes (uno por cada esclavo). Para identificarlos, se rotuló cada puerto SPI con un número binario asociado al esclavo que por ese puerto se conecta: Esclavo 0 ­ Puerto SPI B3 del maestro: 10.1 CLK 10.2 MOSI 10.3 MISO Esclavo 1 ­ Puerto SPI A3 del maestro: 9.5 CLK 9.6 MISO 9.7 MOSI Los módulos SPI tanto del maestro como del esclavo se configuran en modo tres pines, 8 bits, reloj activo en nivel alto, leer en flanco de bajada y bit más significativo primero.

Emulador, esclavo SPI (MSP430)

Este microcontrolador debe recibir comandos vía SPI y actuar en concordancia, respondiendo mediante el mismo método. En esta configuración, el MSP430 es el esclavo del MSP432 como se mostró en la Figura 1. Si bien en un principio se planteó utilizar encolado de funciones, luego de comenzado el proyecto se cambió por Round­Robin con interrupciones, puesto que no había necesidad de prioridad de tareas y que las mismas no eran tantas como para complejizar en el funcionamiento del Main a un encolado de funciones. Se implementó una cola en recepción, la cual contendrá los comandos a ejecutar encolados, pues facilita la implementación y minimiza el tiempo que toma cada interrupción. Además, se utiliza una cola de transmisión, desde la cual se envían los datos cada vez que se recibe la señal de reloj desde el maestro. En la Figura 5 se puede observar los módulos a implementar en el esclavo.

7

Figura 5: Diagrama de módulos de software para el esclavo

En la Figura 5, las flechas representan el flujo de datos entre módulos. Por ejemplo, al llegar un comando por SPI, el módulo SPI lo guardará en la cola de RX del módulo Cola durante la ISR. Luego, en la ejecución principal, si la cola no está vacía se saca el comando de la cola de RX y se pasa al módulo Emulador_AFE. La función interpretar comando puede leer o escribir registros (dependiendo del comando recibido) y finalmente encola una respuesta en la cola de TX. En la próxima interrupción, la ISR del módulo SPI saca la respuesta de la cola de TX y la transmite por SPI.

Interpretar comando deberá discernir entre 6 posibles tipos de comandos: READ(R): esto le indica al RHD2132 que debe leer el valor del registro R y pasarlo por MISO WRITE(R,D): escribe el valor D en el registro R. Devuelve una palabra indicando que la escritura fue exitosa. Si el registro es de solo lectura, devuelve lo mismo que devolvería en caso de que la escritura sea exitosa, sin sobreescribir ese registro. CALIBRATE: al recibir este comando configura a los conversores A/D internos. Durante los nueve períodos de SPI que le lleva realizar la calibración, ignorará todos los comandos siguientes a un CALIBRATE. CLEAR: borra los parámetros de calibración de los conversores A/D internos.

8

CONVERT(C): al recibir este comando, muestrea y digitaliza la información del canal C y pasa por MISO el resultado de la conversión. INVALID COMMAND: Si la palabra enviada por MOSI no se corresponde con ningún comando de los anteriores, el RHD2132 responde con una palabra fija que indica al microcontrolador que lo enviado, no fue un comando válido para el chip RHD2132. Como se mencionó anteriormente, el RHD2132 funciona con SPI de 16 bits. Sin embargo, los microcontroladores elegidos soportan únicamente 8 bits. Luego de realizar diversos intentos fallidos para implementar nativamente los 16 bits, se decidió que la comunicación sea en parejas de 8 bits separados, pero que las colas y demás funciones trabajen con 16 bits de forma transparente. A partir de esa capa hacia arriba, todo el software funciona en 16 bits. Si se quisiera implementar la comunicación SPI de 16 bits seguidos (sin espera intermedia), solo sería necesario reescribir la rutina de interrupción, suponiendo que el hardware sea capaz de soportarlo.

Microcontrolador maestro SPI (MSP432)

El MSP432, que actúa de maestro, debe encargarse de enviar palabras de 16 bits a los esclavos, enviando a uno de ellos o a ambos según lo requerido. Los comandos que enviará serán los cinco comandos básicos que interpreta el RHD2132, que son las funciones READ, WRITE, CLEAR, CALIBRATE y CONVERT descritas anteriormente. La Figura 6 muestra un diagrama en bloques de transmisión y recepción de la comunicación SPI del lado del maestro.

9

Figura 6: Diagrama en bloques de la transmisión y recepción de la comunicación SPI del lado del maestro.

Como se observa, los comandos que se envían desde el maestro al esclavo se cargan en las colas de transmisión Buffer_Out_SPI[0] si el mensaje desea enviarse al esclavo rotulado como 0, o a Buffer_Out_SPI[1] si el mensaje desea enviarse al esclavo rotulado como 1. La respuesta del esclavo al maestro será guardada en las colas de recepción del maestro, que serán Buffer_In_SPI[0] para los mensajes recibidos por el esclavo rotulado como 0 y Buffer_In_SPI[1] para los mensajes recibidos por el esclavo rotulado como 1. DIAGRAMA EN MÓDULOS DEL MAESTRO La Figura 7 muestra el esquema de la dependencia de los módulos en el MSP432.

Figura 7: Diagrama de dependencia de los módulos del maestro.

10

Se detalla a continuación la función que realiza cada módulo: SPI432: este módulo se encarga de la transmisión y recepción de datos de 16 bits a intercambiar con los esclavos mediante los puertos SPI . Las funciones principales de este módulo son:

void send_word(uint16_t c, uint8_t destinatario): Envía por SPI la palabra c de 16 bits al chip indicado en destinatario.

uint16_t send_and_wait(uint16_t comando, uint8_t destinatario, uint8_t ciclos): Envía

por SPI la palabra comando de 16 bits al chip indicado en destinatario. Se espera los períodos de SPI indicados en la variable ciclos, y se retorna el resultado recibido por SPI, respuesta esperada al comando enviado al esclavo.

Además, este módulo contendrá las rutinas de interrupción de recepción de los dos puertos SPI utilizados, en los cuales guardará los datos en los buffers mencionados anteriormente, buffer_in_SPI[0] y buffer_in_SPI[1] y enviará otras palabras de 16 bits, si es que existen en los buffers buffer_out_SPI[0] y buffer_out_SPI[1]. queue: Este módulo contiene las funciones para manejar a los buffer como colas circulares, para un tratamiento más eficiente de la memoria asignada para estos. Las funciones principales de este módulo son:

unsigned char is_Full(obj_t object, unsigned char prio): Función que devuelve 1 si la

cola pasada como parámetro está llena o 0 si no. char add_data(obj_t object, unsigned char prio): Agrega un dato a la cola pasada

como parámetro.

unsigned char is_emptysprio(obj_t object, unsigned char prio): Función que devuelve 1 si la cola está vacía y 0 si no.

char get_data_sprio(obj_t object, unsigned char prio): quita un dato de la cola en orden FIFO (first in, first out)

unsigned int number_elements(obj_t object,unsigned char prio): indica la cantidad de

elementos que tiene la cola pasada como parámetro. AFE: este módulo implementa funciones de alto nivel que envían comandos a los esclavos. Se separan las funciones en dos grupos en función de su nivel de abstracción al problema:

Funciones de bajo nivel:

11

uint8_t READ(uint8_t registro_RHD2132, uint8_t destinatario): función que envía un comando READ del registro pasado como parámetro al chip indicado en destinatario y devuelve el valor del registro leído.

uint8_t WRITE(uint8_t registro_RHD2132, uint8_t dato, uint8_t destinatario): función que envía un comando WRITE al chip indicado en destinatario, para escribir en el registro pasado como parámetro el dato pasado como parámetro. Retorna 1 si la escritura fue exitosa o 0 en caso contrario.

void CLEAR(uint8_t destinatario): Función que limpia los parámetros de calibración del ADC del chip indicado.

void CALIBRATE(uint8_t destinatario): Función que realiza la calibración del ADC

del chip indicado.

uint16_t CONVERT(uint8_t channel): Función que convierte el canal pasado como parámetro. Si el canal es menor a 32, enviará el comando al primer chip, si es mayor a 32 y menor a 64 lo enviará el segundo.

Funciones de alto nivel: void CONVERTburst(uint8_t *channels, int16_t *destino, uint8_t cant_ch_a_convertir): Envía ráfagas (secuencia

consecutiva de comandos) de convert al chip correspondiente. Envía convert de los canales indicados en el buffer channels (solamente los primeros “cant_ch_a_convertir”). Se encarga también de recibir las respuestas y almacenarlas en el buffer destino pasado como parámetro.

void set_sup_cutoff_freq(uint8_t freq): Setea la frecuencia de corte superior de los

dos chips RHD2132 al valor pasado como parámetro, modificando los registros adecuados.

void set_inf_cutoff_freq(float freq): Función que setea la frecuencia de corte inferior de los dos chips RHD2132 al valor pasado como parámetro, modificando los registros adecuados. En este módulo serán declarados los buffers de transmisión y recepción buffer_in_SPI y buffer_out_SPI para cada uno de los esclavos.

En la siguiente figura, para facilitar la comprensión del diseño del software, puede verse un ejemplo de diagrama de llamadas de las funciones. De cada función salen flechas que apuntan a las funciones de más bajo nivel que ésta usa.

12

Figura 8: Diagrama de funciones del módulo AFE

13

Implementación Esta sección se centra en la implementación del software tanto del maestro (MSP432) como del esclavo (MSP430). Se trabajó en el entorno de desarrollo de Texas Instruments, Code Composer Studio y su compilador TI v15.12.1.LTS.

Emulador, esclavo SPI (MSP430)

A continuación se describen los módulos de software del esclavo, desde el de más bajo nivel (interrupciones y SPI) hasta el de más alto nivel (emulación). Interrupciones, comunicación SPI El emulador utiliza una arquitectura de Round Robin por interrupciones. La única interrupción presente es la de la comunicación SPI, que al final de cada ciclo (de 8 bits) pasa la palabra recibida desde el shift­register al buffer e interrumpe. Para implementar una comunicación de 16 bits, utilizamos banderas TXisSet y RXisSet respectivamente, y buffers temporales que guardan los bytes altos, tx_msB y rx_msB, y bajos, tx_lsB y rx_lsB, de la transmisión y recepción. El diagrama de flujo de la interrupción puede verse en la siguiente figura.

Figura 9: Diagrama de flujo de la interrupción SPI para el MSP430

14

El módulo de colas es de palabras de 16 bits. Para transmitir una palabra se saca una en el primer ciclo de 8 bits de transmisión y se manda el byte alto, pues es MSB first. El byte bajo se guarda en una variable temporal y se manipula la bandera tx_isSet para indicar que en el próximo ciclo de 8 bits corresponde transmitir el byte bajo de la variable temporal y no sacar una nueva palabra de la cola. En recepción es análogo, en el primer ciclo se guarda el byte alto en una variable temporal, se manipula la bandera rx_isSet y en el próximo ciclo se completa la palabra de 16 bits y se guarda en la cola. Colas de datos Se implementan dos colas circulares de datos, una de transmisión y otra de recepción, para datos de 16 bits. Se proveen funciones para agregar y sacar datos, así como para preguntar si la cola está llena o si está vacía, para cada una de ellas por separado. Su funcionamiento es idéntico en ambos casos. Al ser circular se evitan problemas de datos compartidos, ya que son secciones de software distintas las que agregan y sacan datos. El módulo SPI agrega a RX y saca de TX, mientras que el módulo de emulación agrega a TX y saca de RX.

Módulo emulación AFE El módulo AFE es el que provee la funcionalidad de emulación, y es el de más alto nivel en la aplicación. En primer lugar, posee un arreglo correspondientes a los registros internos del chip a emular. Cada registro se representa con una estructura, y se guardan todas en un arreglo:

struct char reg; char read_only; registros[64];

El campo “reg” guarda la información del registro. El campo “read_only” tiene tres valores posibles: 1 significa que el registro es solo lectura, 0 significa que se puede tanto leer como escribir, 2 significa que el registro es inválido (es decir, no existe en el chip original; esto es necesario pues la numeración de los registros existentes es salteada).

Por otro lado, el módulo posee dos variables internas: static int contCalibrate = 0; static int lastChannel = 0;

La primera cuenta la cantidad de períodos desde que se empezó a ejecutar un comando CALIBRATE. Es requerida pues el emulador debe ignorar los 9 comandos siguientes a un CALIBRATE. La segunda guarda el último canal convertido con un comando CONVERT. Es requerida pues el comando CONVERT(63) implica convertir el canal siguiente al último convertido, por lo que el emulador debe recordarlo. Finalmente, están las funciones que ejecutan los comandos recibidos y hacen funcionar al emulador. La primera en llamarse debe ser emulacion_init(), que inicializa los registros y las variables globales. Luego está la función interpretar_comando, que acepta como parámetro

15

un comando recibido y ejecuta la función correspondiente. Estas funciones son una por cada comando posible (es decir, el comando WRITE tiene una función write() asociada, etc.). En la siguiente figura se puede ver el diagrama de flujo del programa principal, y cómo se llaman estas funciones entre ellas para proveer el comportamiento previsto.

Figura 10: Diagrama de flujo del programa principal MSP430

En general, la emulación se reduce a contestar al maestro la palabra adecuada (y guardar datos en el caso de un WRITE). Esto es, para los comandos WRITE, READ, CLEAR y CONVERT, cada función de emulación (es decir write(), read(), etc.) encola una respuesta de acuerdo con lo especificado por el fabricante. Un comando WRITE lleva una respuesta que es 0xFFXX, donde XX es la palabra escrita en el registro. Por lo tanto, la función write() encola esta respuesta en la cola de transmisión y, además, guarda XX en el arreglo de estructuras. Un comando READ, lleva una respuesta que es 0x00XX, donde XX es el contenido del registro leído, por lo que la función read() encola en la cola de transmisión el contenido del registro. Un comando CLEAR lleva una respueta 0x0000 y un comando CONVERT lleva una respuesta numérica de 16 bits que representa la conversión del canal, por lo que sus comandos correspondientes encolan esas respuestas. En el caso del CONVERT, como tomar muestras del ADC queda fuera del alcance del proyecto, se contesta el número de canal. Cualquier comando que no sea uno de los especificados en la hoja de datos, se considera inválido y la respuesta correspondiente es un 0x0000. Finalmente, el caso del comando CALIBRATE es un poco más complicado por lo que requiere una mención especial. El fabricante especifica que, dado un CALIBRATE, el chip ejecutará la rutina de autocalibración del ADC, lo que dura 9 ciclos de SPI (de 16 bits). Durante este tiempo, el chip ignora todos los comandos recibidos, y siempre responde 0x0000. Recién el décimo comando recibido luego de un CALIBRATE será atendido, los demás son desechados. Para resolver esto, la función calibrate() encola nueve palabras 0x0000 en la cola de TX, que serán las respuestas esperadas. Además, inicializa

16

contCalibrate=9. Luego, en la función interpretar_comando, si contCalibrate es distinto de cero, se decrementa, se saca el último comando de la cola de RX y se desecha. Cuando contCalibrate llega a 0, se vuelve al funcionamiento normal, donde el comando se saca de la cola pero se ejecuta. En la siguiente figura puede verse el diagrama de flujo.

Figura 11: Diagrama de flujo de Interpretar_Comando

Es importante notar que el decremento del contador se hace en interpretar_comando, y no en la rutina de interrupción. Esto es posible ya que en la comunicación SPI siempre ocurre una transferencia por ciclo, es decir, en cada ciclo se recibirá obligatoriamente un comando. Si el maestro no desea emitir comandos debe cesar la comunicación, o enviar comandos inválidos. Por ello, al inicio de cada ciclo de SPI, habrá en la cola de RX una sola palabra recibida, el comando del ciclo anterior. En el loop principal del programa, que se ejecuta asíncronamente con las interrupciones, se llamará a interpretar_comando tantas veces como haya comandos a procesar en la cola de RX, es decir, una sola vez. Por ello, pese a que interpretar_comando no se ejecuta sincronizada con las interrupciones, solo se ejecutará una vez por ciclo de SPI (de 16 bits), lo que hace que se puedan contar ciclos dentro y decrementar el contador. Esto posibilita modularizar el software y que no haya código de emulación dentro del módulo SPI.

17

Microcontrolador maestro SPI (MSP432)

En lo que sigue se describe la implementación de los módulos de comunicación SPI y módulo AFE del maestro.

Módulo comunicación SPI

Función send_and_wait(uint16_t cmd,uint8_t destinatario uint8_t ciclos)

Esta función es una función de comunicación SPI de 16 bits de alto nivel. Envía el comando y bloquea la ejecución del microprocesador durante la cantidad de ciclos SPI especificada. Retorna la última respuesta recibida. Su implementación puede verse en el diagrama de flujo de la figura 9. En primer lugar, se espera a que la cola de transmisión esté vacía para asegurarse que no haya otra parte del software intentando usar la comunicación SPI. Una vez que sucede esto, como send_and_wait es bloqueante, nadie más tendrá acceso a las colas SPI y el uso será exclusivo de esta función. Luego, se agrega el comando a la cola de TX (correspondiente al destinatario) y una cantidad de comandos dummies, o inválidos, igual a la cantidad de ciclos a esperar por la respuesta. En este caso y siempre que se use un comando dummy, usamos el comando 0x5555. Para comenzar la transmisión, se saca el primer dato de la cola de TX manualmente y se envía con send_word. Una vez iniciada la transmisión, la ISR se encargará, en cada interrupción, de mandar la siguiente palabra de 8 bits. La función luego se bloquea hasta que llegue la respuesta. Esto se logra chequeando sucesivamente la cantidad de respuestas recibidas en la cola hasta que se tengan todas las necesarias. Una vez recibidas todas, se sacan de la cola y se descartan excepto la última, que es retornada. La función send_and_wait garantiza que tanto la cola de transmisión como la de recepción estén vacías al final de su ejecución. Todos los comandos bloqueantes de alto nivel (READ, WRITE, CLEAR, CALIBRATE, CONVERT) usan send_and_wait y su implementación es idéntica: se llama send_and_wait con la palabra correspondiente al comando y n ciclos de espera (n = 2 en caso de READ, WRITE, CLEAR y CONVERT; n = 9 en caso de CALIBRATE). Se retorna lo mismo que

18

retorna send_and_wait. Las funciones de más alto nivel, como las de configurar frecuencias de filtrado, son combinaciones de READ y WRITE. Cada función de alto nivel que implementa un comando toma como parámetro el destinatario, es decir, el chip 0 o el 1. Dependiendo del destinatario, qué módulo de SPI se va a utilizar (A o B). La función convert es la excepción; no admite destinatario, simplemente se numeran los canales del 0 al 63 y la función infiere a qué chip corresponde (0­31 chip 0, 32­63 chip 1).

Módulo AFE

Función CONVERTburst(uint8_t *channels, int16_t *destino,... ...uint8_t cant_ch_a_convertir)

La función CONVERTburst es una función no bloqueante de alto nivel que envía una ráfaga de comandos CONVERT al esclavo, de los canales que especifica el usuario, y transfiere la respuesta a un buffer destino del usuario. Está pensada para ser lo más eficiente posible, maximizando la tasa de adquisición de datos y dejando al microcontrolador libre durante el tiempo que no sea necesaria su intervención en la comunicación SPI. Esto responde a la necesidad de la aplicación final de un sistema que utiliza un AFE, que en general requiere algún procesamiento de datos (como compresión o filtrado). De esta forma, se piden datos tan rápido como posibilita la interfaz SPI (limitado solo por el reloj) y el microprocesador tiene tiempo entre las interrupciones para dedicar al procesamiento de datos. Se esperan tres parámetros, un puntero a un arreglo con los índices de canales a convertir, un entero con la cantidad de canales a convertir (para poder recorrer el arreglo) y un puntero al buffer de destino donde se deben guardar los resultados. Este buffer debe tener 64 lugares, y el resultado del canal N se guarda en la posición N del arreglo. Las otras posiciones no son afectadas. La implementación dentro de la función es sencilla y se muestra en el siguiente diagrama de flujo:

Figura 13: Diagrama de flujo CONVERTburst

19

Esta función retorna al pasar el primer comando al módulo SPI y libera la ejecución. El resto de la transmisión se resuelve dentro de la ISR. En cada interrupción, la ISR guarda las respuestas en la cola de RX, transmite el próximo CONVERT, e incrementa un contador. Cuando el contador indica que se obtuvieron todas las respuestas esperadas, se guardan los resultados en el buffer del usuario y se resetean las banderas internas al módulo. Además, se provee una bandera pública (conversion_ready) para que el usuario pueda comprobar cuando la conversión ha finalizado. El diagrama de flujo puede verse a continuación.

Figura 14: Diagrama de flujo de la interrupción del SPI para el MSP432

Un ejemplo de un caso de uso podría ser un muestreo periódico, implementado con una interrupción de un Timer, compresión de los datos y transmisión. Se provee un fragmento de código de ejemplo:

int16_t datos[64]; main()

Inicializar(); while(1)

if(conversion_ready) comprimir(datos);

20

enviar(datos);

#pragma vector=TIMER void timerISR()

uint8_t canales[CANT_CANALES]; //Cargar el arreglo “canales” con los índices deseados CONVERTburst(canales, datos, CANT_CANALES);

21

Problemas encontrados

Figura 15: Glitch con CKPH=1 El chip emulado (RHD2132) funciona con una interfaz SPI de 16 bits, reloj activo en nivel alto, lee en flanco de subida y manda el bit más significativo primero. En este respecto, se tuvieron que hacer varias modificaciones para que el emulador funcionara correctamente. En primer lugar, se enfrentó un problema con el módulo de SPI del esclavo (MSP430). El problema observado era de shifteo de bits en el envío de datos, así como glitches en el estado inactivo de la línea MISO. En la figura 13 puede verse el glitch mencionado, donde la línea debería quedar en VDD cuando está inactiva y, sin embargo, luego de llegar a VDD baja nuevamente a GND. Luego de extensivas pruebas, se encontró que existe una errata reportada acerca de este microprocesador funcionando en este modo (esclavo, sin defasaje en el reloj de SPI). Si bien la misma errata sugiere una solución, la misma no se logró hacer efectiva, por lo que se optó por utilizar el esclavo con desfasaje. En la figura 14 se muestra la errata reportada.

Figura 16: Errata reportada del MSP430

22

Esto implica que el emulador implementa una comunicación SPI distinta a la del chip emulado. Sin embargo, no afecta al objetivo principal, que es proveer una plataforma para probar software del lado del maestro. Una vez probado dicho software, simplemente se debe cambiar el bit UCCKPH en el registro de configuración de SPI para utilizarlo con el chip real. Por otro lado, se experimentaron problemas con la recepción del maestro (MSP432) al intentar realizar la comunicación en 16 bits seguidos, sin tiempo de espera. Se observa que el maestro (MSP432) logra enviar 16 bits seguidos correctamente, como se muestra en la figura 15. Esto se logró siguiendo la siguiente lógica en la ISR:

Cargar byte alto en UCX3TXBUF Esperar UCTXIFG Cargar byte bajo en UCX3TXBUF

Esto funciona porque al principio del ciclo de SPI se carga el byte alto en el buffer y este se mueve rápidamente al shift register, lo que baja la bandera UCTXIFG mucho antes de que se termine la transmisión. En ese momento se carga el byte bajo y se retorna de la interrupción. En la siguiente interrupción habrá un dato nuevo (el byte alto) en UXTXBUF y este será transmitido sin esperas intermedias.

Figura 17: Comunicación 16 bits, MOSI. Figura 18:Comunicación 16 bits MISO Sin embargo, no fue posible recibirlos correctamente en el esclavo (MSP430). Conjeturamos que el problema es que al producirse la primera interrupción (tras los primeros 8 bits), el microprocesador no tiene tiempo de sacar los datos recibidos del shift register y pasarlos al UCA0RXBUF antes de que llegue el próximo bit y comience el nuevo ciclo. En consecuencia, los datos recibidos se observan shifteados en el UCA0RXBUF y se prende la flag de OVERRUN, que indica que efectivamente está ocurriendo este problema, de no que se libera el buffer de recepción antes de que lleguen datos nuevos. También observamos que en estas circunstancias la transmisión funciona mal, como puede verse en la figura 16, donde la señal periódica (color celeste) es el CLK y la otra es el MISO. En la

23

mitad de la pantalla, hay un pulso demasiado corto, pues el tiempo de bit es igual al período de reloj (se cambia el dato en ciclo de subida y se lee en ciclo de bajada). Esto apunta a una posible limitación de hardware por parte del esclavo MSP430. Dada la duración acotada del proyecto, se optó por dar una espera entre los ciclos de 8 bits, para que el MSP430 pudiera funcionar correctamente. Sin embargo, es un punto en el que la emulación no es buena: en la capa más baja, la capa física, la comunicación implementada es diferente. Esto supone que no todo el software puede probarse con el emulador, ya que el driver SPI tiene que tener una espera apropiada entre ciclos. A futuro, para que la emulación sea correcta, debe hallarse la manera de que el MSP430 logre recibir 16 bits, o en su defecto, emular el funcionamiento con un chip distinto al que se utiliza en este proyecto, que sea capaz de manejar comunicación SPI de 16 bits

24

Casos de prueba Se dividen según la etapas de implementación. En primer lugar se programó el MSP430, por lo que fue el primero en ser probado. Luego se programó el SPI del MSP432; para probarlo, se implementó una rutina de prueba análoga a la primera, enviando los mismo comandos. Finalmente, una vez programadas las rutinas de alto nivel, se probaron las mismas.

Emulador, esclavo SPI (MSP430)

En este caso se utilizó otro MSP430 como maestro por su simpleza de programación y abundancia de ejemplos disponibles. Se idearon dos bancos de comandos de pruebas, los cuales se detallan en la Tabla 1, con el objetivo de probar el correcto funcionamiento del simulador en casos bordes, así como en funcionamiento normal.

Comando hexa Respuesta Comentario

convert(1) 0x0100 ? Convertir canales convert(2) 0x0200 ?

convert(63) 0x3F00 0x0001 Convertir siguiente canal (3)

read(40) 0xE800 0x0002 Leer registro prefijado

write(0,0xFA) 0x80FA 0x0003 Escribir registro

read(0) 0xC000 0x0049 Leer registro escribible

clear 0x6A00 0xFFFA Limpiar registros

write(40,0xFA) 0xA8FA 0x00FA Escribir registro solo lectura

read(40) 0xE800 0x0000 Leer registro solo lectura

read(41) 0xE900 0xFFFA

Leer registros varios

read(42) 0xEA00 0x0049

read(43) 0xEB00 0x004E

convert(31) 0x1F00 0x0054 Convertir canal 31

convert(63) 0x3F00 0x0041 Convertir siguiente canal (0)

convert(63) 0x3F00 0x001F Convertir siguiente canal (1)

write(20,0xFA) 0x94FA 0x0000 Escribir registro inválido

25

read(20) 0xD400 0x0001 Leer registro inválido

dummy 0x5555 0xFFFA

Comando inválido (dummy)

dummy 0x5555 0x0000

dummy 0x5555 0x0000

Tabla 1: Comandos de prueba para el MSP430 sin calibrate

En esta secuencia se envía comandos válidos e inválidos, así como se intenta escribir registros solo lectura o inválidos. Las dos primeras respuestas se marcan con un “?” porque en el sistema real son desconocidas; en el emulador, la respuesta es 0x0000. Las respuestas a los comandos tiene dos palabras de retraso y se corresponden con los que deberían responder según la hoja de datos. Se debe tener en cuenta que la respuesta a los comandos convert() es el número del canal, pues resultó lo más práctico a los efectos de debuggeo. La siguiente prueba es similar, salvo que incluye un comando calibrate. Para evitar repetir, se incluyen solamente los primeros catorce comandos.

Comando hexa Respuesta Comentario

calibrate 0x5500 ? Calibrate

convert(2) 0x0200 ? Convertir canal 2

convert(63) 0x3F00 0x0000 Convertir siguiente canal (3)

read(40) 0xE800 0x0000 Leer registro prefijado

write(0,0xFA) 0x80FA 0x0000 Escribir registro

read(0) 0xC000 0x0000 Leer registro escribible

clear 0x6A00 0x0000 Limpiar registros

write(40,0xFA) 0xA8FA 0x0000 Escribir registro solo lectura

read(40) 0xE800 0x0000 Leer registro solo lectura

read(41) 0xE900 0x0000 Leer registro solo lectura

read(42) 0xEA00 0x0000 Leer registro solo lectura

read(43) 0xEB00 0x0000 Leer registro solo lectura

convert(31) 0x1F00 0x0054 Convertir canal 31

Tabla 2: Comandos de prueba para el MSP430 con calibrate

26

En este caso, se prueba el correcto funcionamiento del comando calibrate. Según la hoja de datos, el chip necesita recibir 9 palabras luego de recibido el comando, pero las mismas serán ignoradas. En el simulador, las palabras ignoradas se representan con un color de fondo sobre la tabla. Como se observa, las respuestas en todo ese tiempo es nula como se esperaría; luego de finalizados los ciclos de espera, devuelve la respuesta del calibrate que es 0x0000. Finalmente, luego de la misma, se lee el comando READ(42) y un período luego devuelve la respuesta correcta.

Microcontrolador maestro SPI (MSP432)

Como se dijo, primero se repitió la prueba anterior solo que implementada para este microcontrolador, la cual resultó igual de exitosa, por lo que no se repiten los resultados. La siguiente prueba consistió en el uso de comandos de alto nivel implementados para probar su correcto funcionamiento. La secuencia de prueba fue la siguiente:

1. Escribir 0xAB en el registro 0. 2. Leer registro 0. 3. Conversión simple del canal 5. 4. Conversión en ráfaga de los canales 1,2,10,8,6,15,18,39,41,50,61,62,63. 5. Escribir 0xAC en el registro 0. 6. Leer registro 0. 7. Conversión simple del canal 5.

Las primeras 3 funciones se ejecutaron para probar el correcto funcionamiento de las funciones, tanto en su respuesta como en su capacidad de bloqueo. Luego se ejecutó la conversión en ráfagas las cuales guardaron los valores correctos en el buffer de destino. Se esperó que terminara la conversión y se ejecutaron los restantes comandos, los cuales fueron nuevamente exitosos.

27

Conclusiones En primer lugar, se puede concluir que se logró programar un MSP430 que simula correctamente el comportamiento del chip RHD2132. Todas las pruebas realizadas fueron extensivas y exitosas, lo que permitiría el eventual uso del mismo como sustituto del chip, a los efectos de debuggear la placa real sin necesidad de exponer al primero a riesgos innecesarios. Sin embargo, se debe tener en cuenta que debido a las restricciones de hardware ya descriptas, no se pudo lograr una comunicación real de 16 bits, teniendo que conformarse con pares de bytes. Se pueden considerar opciones a futuro para resolver este problema como: usar el reloj SPI a una frecuencia muy baja, de modo que el 430 pueda operar de a 16 bits; cambiar el 430 a un microcontrolador parecido pero más rápido; incorporar un periférico SPI de 16 bits nativo, exterior al microprocesador. Por el lado del MSP432, se cumplió con el objetivo de implementar una API de alto nivel para hacer transparente a un eventual usuario el uso del chip. Nuevamente, de utilizar el chip verdadero se deberían modificar las funciones de bajo nivel de SPI para enviar 16 bits seguidos (lo cual se corroboró fuera posible); las capas más altas de software funcionarían de igual manera. Debido a restricciones de tiempo y a problemas encontrados durante el desarrollo del proyecto, no se logró implementar un módulo UART con un shell de comandos.

28

Referencias Guía de usuario TI MSP430 ­ http://www.ti.com.cn/cn/lit/ug/slau144j/slau144j.pdf Hoja de datos TI MSP430G2253 ­ http://www.ti.com/lit/ds/slas735j/slas735j.pdf Errata TI MSP430G2553 ­ http://www.ti.com/lit/er/slaz440g/slaz440g.pdf Manuel de referencia TI MSP432P401 ­

http://www.ti.com/lit/ug/slau356c/slau356c.pdf Hoja de datos TI MSP432P401R ­ http://www.ti.com/lit/ds/slas826d/slas826d.pdf Hoja de datos Intan RHD2132 ­

http://www.intantech.com/files/Intan_RHD2000_series_datasheet.pdf

29

Anexo Conceptos del curso aplicados al proyecto

Para la rutina principal del esclavo, se utilizó Round­Robin con interrupciones de manera similar a la vista en clase. Esto se debió a que el esclavo debe siempre esperar un comando y actuar en base a éste; por lo tanto, solamente con una bandera que indicase la existencia de comandos pendientes en la cola de recepción bastaba, lo cual simplifica el diseño. A su vez, con el uso de colas de transmisión y recepción se evitó el problema de datos compartidos, pues únicamente un módulo es el que puede acceder a estas. Las rutinas de interrupción de ambos microcontroladores fueron lo más rápidas posibles, en concordancia con lo visto en el curso, pues éstas deben hacer el mínimo trabajo necesario para no bloquear al microprocesador. Se intentó modularizar lo máximo posible en la programación de ambos, maestro y esclavo, manteniendo como visibles únicamente las variables estrictamente necesarias por razones de modularidad y funcionalidad.

30

Especificación del proyecto

Descripción detallada del proyecto Nombre: Simulador de interfaz neuronal (AFE) Integrantes:

Federico Nin Santiago Radi Federico Silva

Tutor: Leonardo Steinfeld Descripción del problema: desarrollar un software embebido para interactuar con un Analog Front­End (AFE) integrado para EEG presenta muchos desafíos. En primer lugar, se trata de un chip o varios, muy especializados, de alto costo y de los que además no se cuenta con sustitutos, por lo que es deseable bajar los riesgos de dañarlo. En segundo lugar, dicho chip no está aún disponible por lo cual el test del software embebido que interactúa con dicho chip es difícil de realizar. Antecedentes: Actualmente existe un proyecto de investigación en el IIE con financiación de CSIC que pretende desarrollar un sistema de medición de señales de electroencefalografía, que sea utilizado para investigación, utilizando un algoritmo de compresión también desarrollado en la facultad. En el marco de esta investigación, y en paralelo con el proyecto descripto en este documento, se desarrolla el proyecto de fin de carrera wEEG (Santiago Radi, Martín Causa, Franco La Paz) que consiste en un microcontrolador interactuando con el AFE y transmitiendo las medidas por un módulo bluetooth. Objetivos: Los objetivos del proyecto son:

1. implementar un sistema embebido usando un microcontrolador que emule el comportamiento de un AFE de 64 canales, formado por dos chips RHD2132 de Intan Technologies (cada chip puede manejar 32 canales y en conjunto pueden manejar 64 canales simultáneamente).

2. desarrollar las bibliotecas (módulos de software embebido) para un microcontrolador que permitan la configuración y adquisición de datos (no reales) del AFE. Para el desarrollo y test de estos módulos se utilizará el emulador del punto i)

3. desarrollar una aplicación de prueba para 64 canales utilizando un microcontrolador, dos emuladores y un modem celular para que un usuario pueda interactuar con el sistema vía GPRS.

Alcance del proyecto: La comunicación del AFE con el microcontrolador es vía SPI. Se programarán dos MSP430 para que emulen el comportamiento del AFE, lo que implica resolver la comunicación SPI especificada para este chip y responder adecuadamente a los comandos externos, devolviendo medidas cuando son solicitadas y almacenando configuraciones (que modifiquen el comportamiento, si corresponde). Luego, se programará un MSP432 para que

31

adquiera datos del emulador AFE y los guarde adecuadamente para su posterior envío. El microcontrolador interactuará con una PC mediante UART, con la cual se probarán los comandos de la API. Descripción del sistema: Descripción funcional: Dos MSP430 emularan un RHD2132 cada uno. Deben responder como lo haría el chip emulado a los comandos externos. Se desarrollará una API de alto nivel para el microcontrolador, la cual ejecutará los comandos recibidos por UART desde el PC. Diagrama de bloques:

PC

32

Diagrama del MSP430

Requerimientos y restricciones del sistema: En primera instancia, se utilizará un MSP430 para la simulación de RHD2132. Se estima que la capacidad de cómputo del mismo será suficientes, pues el sistema deberá enviar datos aleatorios (32 canales por chips, de forma secuencial) con una frecuencia máxima de 500 Hz, mientras que la velocidad de éste microcontrolador es de 8MHz. Por otro lado, el microcontrolador a utilizar como módulo de control y adquisidor de datos es el MSP432, el cual es significativamente más potente que el anterior. Se estima que la capacidad será suficiente, en la medida que no se van a comprimir los datos como el proyecto macro. De cualquier manera, el uso de éste microcontrolador es impuesto por el proyecto macro. En cuanto al tiempo de respuesta, como se dijo anteriormente, los MSP430 deberán ser capaces de enviar 32 valores aleatorios mediante SPI, cada 2ms como máximo. Diseño preliminar: Hardware: Se utilizará un MSP432 como MCU y dos MSP430 para emular los RHD2132. Cada MSP430 emula un RHD2132 y, en conjunto, emulan el AFE de 64 canales. No será necesario hardware adicional, ya que todos los microcontroladores cuentan con módulos de comunicación (SPI y UART). Software: La arquitectura para el MSP432 será de encolado de funciones con interrupciones. Se elige esta arquitectura por su facilidad de uso y ajuste a las necesidades del proyecto puesto que será necesario dar prioridad no solo a las interrupciones sino también a tareas dentro del miscrocontrolador.

33

Se implementarán distintos módulos: UART, SPI, AFE, UART, ControlComandos, Buffer y colas. Para la recepción de datos desde SPI, se utilizará una cola circular en la cual la interrupción correspondiente guardará los datos recibidos. Cualquiera de los chips de Intan Technologies, en este caso el RHD2132, puede recibir del microcontrolador únicamente cinco funciones. El módulo de software AFE contará con funciones que manden estos comandos al AFE y, por sobre ellos, funciones de más alto nivel que los utilicen, facilitando la operación al usuario. Los comandos básicos que acepta el AFE son: CONVERT(C): indica el número de canal que el chip RHD2132 debe convertir de analógico a digital. CALIBRATE: Inicia la rutina de autocalibración del ADC. CLEAR: limpia los parámetros de calibración del ADC. WRITE(R,D): escribe un dato de 8 bits D en el registro R del RHD2132. READ(R): Lee el registro R del RHD2132. Se proveerán funciones de alto nivel para ofrecer la funcionalidad de: setear en los chips parámetros como las frecuencias de corte inferior y superior de los filtros previos a la etapa de amplificación interna de los chips RHD2132, los canales que debe amplificar y luego, cuando sea indicado, realizar la conversión A/D, activar/desactivar el test de impedancia de electrodos, sensar el voltaje de alimentación, activar/desactivar electrodos y recibir entradas analógicas para realizar respuesta a estímulos. Finalmente, en los MSP430 que emularán el AFE también se utilizará encolado de funciones y se implementará un módulo de comunicación SPI muy similar. En respuesta a los comandos recibidos se implementarán acciones similares a la del chip original. Planificación: Actividades y tareas: Se dividirá el problema en bloques. En primera instancia, se programará el sistema de emulación del AFE, con las funciones correspondientes al chip. Esto supone la interfaz SPI tanto de los MSP430 como del MSP432, los módulos de software de AFE y las colas. Pruebas a realizar: Correcto comportamiento del sistema emulado (probar cada comando por separado). Verificación del loop principal del 432, es decir, verificar que pida medidas y las almacene correctamente en el buffer. Verificación de la recepción y envío de comandos mediante UART. Prueba final de todo el sistema integrado. Hitos intermedios: Para el hito 1, se pretende completar la emulación del AFE y desarrollar el módulo de interfaz de software con el AFE al punto de poder pedirle datos y programarlo. Cronograma: Semana 1: Especificación de módulos. Interfaz SPI. Semana 2: Interfaz SPI y emulación del AFE. Semana 3: Módulo de interfaz de software con el AFE y emulación del AFE. Semana 4: Módulo de interfaz de software con el AFE y emulación del AFE. Hito 1. Semana 5: Módulo de interfaz de software con el AFE. Documentación. Semana 6: Documentación y defensa.

34

Planificación del proyecto En primer lugar, consideramos que no realizamos una buena evaluación de las restricciones de hardware del 430. En una primera instancia nos pareció suficiente, pues la aplicación no demanda mucho procesamiento. Sin embargo, implementar un comunicación SPI de 16 bits en un sistema de 8 resultó ser difícil y además, probablemente fue agravado por la velocidad del microprocesador. Una investigación más en profundidad quizás hubiera sugerido optar por otra plataforma de hardware. Además, consideramos que para proyectos posteriores, es conveniente leer la errata antes de usar alguna funcionalidad concreta del microprocesador. Tanto las diferencias entre la planificación y la ejecución, como entre horas estimadas y horas dedicadas se explican por las dificultades con la comunicación SPI. En este aspecto, consideramos que la planificación fue adecuada, pero fue afectada por las razones ya discutidas.

35

Lista de archivos fuentes

Maestro main.c startup_msp432p401r_ccs.c system_msp432p401r.c AFE.c AFE.h queue.c queue.h SPI432.c SPI432.h

Esclavo mainSLAVE430.c cola.c cola.h emulacion_AFE.c emulacion_AFE.h fun.c fun.h SPISLAVE.c SPISLAVE.h

36