test i2c documentación proyecto sisem 2012 iie - fing · ... se comunicara con el resto de los...
TRANSCRIPT
Test I2C
Documentación Proyecto SISEM 2012
IIE - FING
Tutores: Integrantes: Pablo Mazzara Martin Ardao Conrado Rossi Luis Briosso
Imanol Calvo
2
Resumen En el siguiente documento se describe el proceso de diseño y programación de un microcontrolador
(MSP4305438A) de manera de poder monitorear la comunicación I2C entre distintos módulos de un sistema compuesto por varios dispositivos. La idea principal es poder emular el comportamiento de los módulos que componen el nano satélite (Antelsat) actualmente en desarrollo por la Facultad de Ingeniería y Antel. Cada módulo podrá ser configurado con una determinada personalidad (maestro o esclavo) y de acuerdo a ella, se comunicara con el resto de los dispositivos presentes en el bus.
3
Contenido 1. Introducción ........................................................................................................................................ 4 2. Objetivos ............................................................................................................................................. 5 3. Alcance................................................................................................................................................ 5 4. Diseño ................................................................................................................................................. 6
4.1. Aspectos generales .......................................................................................................................... 6 4.2. Flujo del programa principal ............................................................................................................ 7 4.3. Cola de funciones ............................................................................................................................. 7
5. I2C ....................................................................................................................................................... 8 5.1. Ejemplos básicos .............................................................................................................................. 8
5.1.1. Maestro ..................................................................................................................................... 8 5.1.2. Esclavo ...................................................................................................................................... 9
5.2. Configuraciones ............................................................................................................................... 9 5.2.1. Modo I2C, reloj, velocidad de transmisión y M/S...................................................................... 9 5.2.2. Puertos de Salida..................................................................................................................... 10 5.2.3. Registro de interrupciones ...................................................................................................... 10 5.2.4. Condición de Stop ................................................................................................................... 10
5.3. Funciones ....................................................................................................................................... 10 5.4. ISR I2C ............................................................................................................................................ 11
6. UART ................................................................................................................................................. 12 6.1. Configuración ................................................................................................................................. 12 6.2. ISR UART ........................................................................................................................................ 13
6.2.1. Recepción ................................................................................................................................ 13 6.2.2. Transmisión ............................................................................................................................. 13
6.3. Funciones ....................................................................................................................................... 15 7. Almacenamiento de datos ................................................................................................................ 15 8. Queues .............................................................................................................................................. 16 9. Implementación ................................................................................................................................ 17
9.1. Hardware ....................................................................................................................................... 17 9.2. Software ......................................................................................................................................... 17
10. Pruebas ............................................................................................................................................. 18 11. Conclusiones ..................................................................................................................................... 19
11.1. Planificación ................................................................................................................................. 19 11.2. Conclusiones generales ................................................................................................................ 19 11.3. Tareas pendientes ........................................................................................................................ 19
12. Bibliografía ........................................................................................................................................ 20
4
1. Introducción La motivación inicial de este proyecto surgió de ciertas tareas requeridas para el proyecto Antelsat, el
cual involucra el diseño, implementación, puesta en órbita y control de un nano satélite (ver Anexo I). A modo de resumen, el nano satélite es un sistema que consta de varios módulos conectados entre sí a un mismo bus y que, para la comunicación entre estos se utiliza un protocolo llamado I2C.
Cada dispositivo conectado al bus cuenta con una dirección propia (Own Address). Cuando un
dispositivo maestro desea comunicarse con otro dispositivo conectado al bus, este genera una condición de arranque (START) y a continuación pone en el bus de datos (SDA) la dirección del esclavo con el que se quiere comunicar. El resto de los dispositivos, al recibir la condición de arranque comparan la dirección puesta en el bus con la propia y en caso de que corresponda envían una señal de reconocimiento (ACK). Luego de este diálogo, queda establecida la comunicación. Para el caso del satélite, se corresponde un sistema multi maestro, en el que a diferencia de los sistemas maestro-esclavo, cualquier dispositivo puede tomar el bus para establecer comunicación con otro.
Es de nuestro interés, poder emular los diferentes módulos de forma de poder comprobar el correcto
funcionamiento de cada uno con respecto al resto. Esto consistirá en conectar el módulo a evaluar con el dispositivo emulador, el cual será configurado para emular alguno de los módulos restantes, hasta poder verificar la comunicación con todos los demás. Esta configuración se realizará mediante la introducción de comandos usando la UART. Así mismo será posible observar la información recibida en pantalla. Se cuenta con la posibilidad de utilizar ambos protocolos de comunicación simultáneamente dado que el microcontrolador a utilizar cuenta con dos interfaces de comunicación serial, de aquí en más se le referenciará como USCI,(Universal Serial Communication Interface), módulo que es usado además, para la comunicación SPI.
Para lograr el objetivo será necesario estudiar el flujo de comunicación entre módulos, es decir
identificar los actores y las características de las diferentes transacciones. Es necesario evaluar la forma en que vamos a implementar las funcionalidades. Por tratarse de un sistema para comprobar el funcionamiento de la comunicación I2C las tareas consisten en transmisiones comandadas desde la consola y recepción de los datos enviados por el módulo que está siendo evaluado.
5
2. Objetivos Como se mencionó en la introducción, se buscó orientar el proyecto a proporcionar ciertas
funcionalidades al proyecto del nano satélite. Por lo tanto, el objetivo del proyecto es lograr la programación de un módulo que permita emular una comunicación I2C entre dos o más dispositivos permitiendo el monitoreo de la misma y testeo de cambio de parámetros como por ejemplo, la dirección propia del dispositivo.
Del objetivo principal del proyecto se desprenden los siguientes objetivos específicos: - Comprensión del funcionamiento del protocolo I2C. Este objetivo es fundamental para poder
desarrollar el proyecto. - Estudio e implementación de ejemplos simples de comunicación I2C. Utilización de los ejemplos
brindados por el fabricante, Texas Instruments. - Familiarización con los módulos de comunicación del microcontrolador a utilizar, MSP4305438A
de Texas Instruments. - Desarrollo del módulo permitiendo configuración de ciertos parámetros correspondientes al
protocolo de comunicación I2C, como por ejemplo, las direcciones propias, a modo de testeo del correcto flujo de comunicación.
- Integración de la UART como interfaz de configuración y monitoreo para el usuario. Es necesario añadir este objetivo dado que para los microcontroladores del satélite no sería posible utilizar la salida por pantalla de la PC.
3. Alcance Durante el proyecto se buscó poder emular el comportamiento de dispositivos conectados a un bus
I2C con distintas configuraciones de manera de incrementar las posibilidades de testeo. En cuanto al alcance se determinó que, en medida se cumpliera con el objetivo principal, se incrementaría las prestaciones del módulo a desarrollar. Inicialmente se planteó poder comunicar de forma serial dos microcontroladores, cada uno conectado a una PC a través de la interfaz RS232. Por tanto tendría una comunicación de consola a consola entre las 2 PC’s, utilizando los módulos de comunicación de los microcontroladores para una comunicación utilizando la UART.
El usuario, por medio de la consola, podría ser capaz de configurar cada dispositivo como maestro o
esclavo para testear el envío y recepción de datos. Además se definió la inclusión de una lista de funciones de manera de poder obtener ayuda, listar comandos disponibles, listar personalidades disponibles, configurar nuevas personalidades, etc. El programa estará estructurado de forma que sea sencillo agregar nuevas funciones, en caso de que se requieran.
6
4. Diseño
4.1. Aspectos generales
En un principio, el sistema diseñado se puede explicar con el diagrama de capas mostrado en la Figura 1. El usuario ingresa comandos pertenecientes a un Shell a través de la consola. Estos son transmitidos al microcontrolador vía UART y por último, los microcontroladores se comunican entre sí mediante el protocolo I2C. A su vez, la información de la comunicación I2C entre ambos controladores es transmitida vía UART.
Figura 1: Diagrama de capas de interacción.
Dentro de todas las arquitecturas disponibles, se optó por implementar encolado de funciones
mediante interrupciones para el desarrollo de este proyecto. La decisión se basó en que el diagrama de flujo del sistema parecía, en un principio, ser bastante lineal y no contener mayores bifurcaciones. Adicionalmente se podía identificar simplemente dos elementos generadores de eventos, comandos recibidos por UART y mensajes recibidos por I2C. Es por ello que se decidió que para un flujo tan simple era más conveniente tener los recursos necesarios para proveer al sistema con la capacidad de almacenar los datos recibidos por ambas interfaces de comunicación y encolar funciones correspondientes. En la sección 7. se profundizará sobre dicha necesidad de almacenamiento y las dificultades que generó este aspecto durante el desarrollo del proyecto.
Resumiendo, el diseño del sistema se basó en un encolado de funciones generado tanto en las
rutinas de atención a interrupciones de UART como en las de I2C. El otro segmento del programa que genera un encolado de funciones es donde se discrimina los comandos recibidos por UART para asociarlos a las funciones correspondientes dentro del Shell de comandos.
7
4.2. Flujo del programa principal
Dado la arquitectura de software que se decidió utilizar, el flujo del diagrama principal resultó verdaderamente sencillo. Como se ejemplifica gráficamente en la Figura 2, el programa ejecuta un loop infinito chequeando la existencia de funciones en la cola para ejecutar. Mientras la cola esté vacía chequea la condición. En el momento que no se cumpla dicha condición debido al encolado de una función por algún evento relacionado con la UART o I2C, se extrae la función de la cola y se ejecuta.
Figura 2: Diagrama de flujo del programa principal
4.3. Cola de funciones
Avanzado el proyecto, se arribó a un punto de bifurcación en cuanto a que rumbo tomar. Se observó que las funciones a encolar por el programa principal eran generadas en dos puntos distintos del programa, o dos extremos, y además existían múltiples posibilidades de configuración y ejecución que debía permitir el programa. Por lo tanto, existían dos posibilidades en cuanto al encolado de funciones. La primera era la del encolado de funciones sin parámetros y que utilizara variables globales. Por ejemplo, cada función podría tener un buffer donde guardar los sus parámetros. Dicha opción fue rápidamente descartada ya que se que carecía de versatilidad. Se eligió realizar una segunda opción que consistía en implementar una cola de estructuras como la que se detalla más adelante. Dicha estructura contendría el puntero a la función (puntero), la cantidad de argumentos de la misma (argc), y un puntero a los argumentos de la función (argv). Se consideró que dicha opción proporcionaba al programa mayor versatilidad y eliminaba la necesidad de discriminar donde guardar los argumentos dependiendo de la función.
typedef struct{
fptr puntero;
int argc;
char** argv;
}funcion;
Adicionalmente se implementaron todas las funciones necesarias para tratar una cola circular de
dicha estructura, permitiendo la extracción de funciones y sus respectivos argumentos, el encolado y chequeo del estado de la cola (cola llena o vacía).
8
5. I2C Como ya se mencionó en la sección 0, I2C es un bus para la transmisión de datos en forma serial. El
micro controlador MSP430F5438A cuenta con un módulo de I2C que resuelve varias de las tareas necesarias para el funcionamiento de forma automática. Una de ellas, a modo de ejemplo, es se realizar un desplazamiento (shift) a medida que van llegando los bits al puerto hasta que llega el último, momento en el cual es pasado al registro accesible por el usuario. Otra tareas ya resueltas son, el envío de condiciones de arranque (START) o de parada (STOP), la comparación de direcciones luego de una condición de arranque (puesta en el bus versus la dirección del dispositivo), el envío del reconocimientos (ACK) correspondientes, etc.
5.1. Ejemplos básicos
Como parte de los objetivos, sección 2. , se buscó una primera aproximación al protocolo I2C mediante el estudio teórico del funcionamiento, análisis de los registros involucrados además del estudio y testeo de ejemplos básicos brindados por el fabricante, Texas Instruments. En cuanto a este último punto se estudiaron varios ejemplos de códigos de dispositivos configurados como maestro y esclavo participando en escrituras y lecturas. Este punto fue muy positivo para poder comprender extensamente el funcionamiento del protocolo. En las siguientes secciones se pueden apreciar análisis básicos de flujos de las rutinas de atención a interrupciones en diferentes casos.
5.1.1. Maestro
El diagrama de la Figura 3 muestra el diagrama de flujo de las rutinas de atención a interrupciones de transmisión del dispositivo maestro de I2C brindada por Texas Instruments. En la función de trasmisión se debe cargar la dirección del esclavo con el que se desea comunicar y generar una condición de arranque (START). Con el reconocimiento (ACK) del esclavo, en caso de que se encuentre conectado al bus, se entra en la rutina de atención a interrupción del maestro, en donde se permanece hasta que se envía el número de bytes correspondiente y se genera una condición de parada (STOP). Es responsabilidad del programador poner los datos a ser enviados en el buffer de salida de I2C y llevar la cuenta de los bytes que se han enviado.
9
Figura 3: Diagrama de flujo de ISR de I2C en dispositivo maestro.
5.1.2. Esclavo
En la Figura 4 se aprecia el diagrama de flujo del programa utilizado en los ejemplos de Texas Instruments para el caso del esclavo. Se ingresa a la rutina de atención a interrupción con la llegada de una condición de arranque (START), permanece recibiendo datos mientras no llega una condición de parada (STOP). Es de destacar, que los ejemplo brindados por Texas Instruments, enviaban los microcontroladores a modos de bajo consumo mientras se realiza la transferencia, criterio que se decidió adoptar durante el proyecto.
Figura 4: Diagrama de flujo de ISR de I2C en dispositivo esclavo.
5.2. Configuraciones
5.2.1. Modo I2C, reloj, velocidad de transmisión y M/S.
Para configurar el módulo I2C es necesario modificar el contenido de ciertos registros de control de la USCI destinada a la comunicación I2C, UCB0CTL0 y UCB0CTL1. Además se utilizaron ciertos Macros definidos en la librería de la familia del dispositivo. Esta modalidad de configuración simplifica bastante la implementación así como las rutinas de envío o lectura. El contenido de estos registros configura el módulo en modo I2C, se selecciona la fuente de reloj y el bit ratio para determinar la velocidad de transmisión, la cual fue seleccionada a 100 kHz. Seguido de esto, se determina si el dispositivo va a
10
configurarse como maestro, esclavo, o maestro en un ambiente multi maestro modificando el registro de control 1. Por más información sobre los registros de control se puede consultar [1].
5.2.2. Puertos de Salida
Un punto importante al momento de la configuración es la selección del puerto de salida y la dirección de los pines del puerto seleccionado, según se trate de una configuración maestro o esclavo. Cuando se comenzó a experimentar con los ejemplos suministrados por Texas Instruments se encontró que los puertos no estaban seleccionados lo que provocaba que no se pudiera establecer la comunicación. Este punto provocó uno de los contratiempos sufridos durante el proyecto ya que resultó difícil encontrar el problema. Si bien en los ejemplos se indicaba si los puertos eran de entrada o salida, según si era esclavo o maestro, no se realizaba la selección. Los ejemplos de Texas se pueden consultar aquí [2].
5.2.3. Registro de interrupciones
Unas de las últimas configuraciones necesarias es la carga del registro de interrupciones, UCB0IE, donde se establece cuales interrupciones se habilitan y cuáles no, por ejemplo: RX, TX, STT, STP y NACK. En la sección 5.4 se analizará la rutina de atención a interrupción de I2C pero es importante mencionar que cada una de estas interrupciones genera un vector diferente de interrupción.
5.2.4. Condición de Stop
El envío de condiciones de arranque (START) y parada (STOP) se realiza seteando determinados bits del registro de control y estos vuelven a cero cuando la acción solicitada fue realizada. Por ejemplo seteando el bit de parada (STOP) se generará dicha condición luego de la cual el bit será reseteado.
5.3. Funciones
Dentro del módulo de I2C se consideró necesaria la implementación de las siguientes funciones: - Configuración de personalidades: Personalidades: para configurar las personalidades es
necesario ingresar el número de personalidad, la dirección propia y si es maestro o esclavo (1 si es maestro, 0 si es esclavo). Se pueden cargar una cantidad de personalidades establecida y se almacenan en un array. Para las personalidades se estableció una estructura para contener los parámetros mencionados anteriormente y también un campo adicional que indicara si la personalidad del array está cargada o no.
- Configuración de módulo I2C: Función para configurar el módulo, con los parámetros cargados en alguna de las personalidades del array. Recibe número de personalidad a configurar y configura los registros de control del módulo USCI.
- Función de lectura: Carga la dirección del esclavo en el registro correspondiente y el contador con el número de bytes a leer. Luego genera una condición de arranque (START) con el bit correspondiente a lectura seteado y la dirección del esclavo, para finalizar con una parada (STOP) una vez que se finalizo la trasmisión.
11
- Función de transmisión: Cagar la dirección del esclavo en el registro correspondiente, analiza el mensaje a enviar y carga el contador con el número de bytes a enviar, genera una condición de START y una de STOP al finalizar la transmisión. La función fuerza al microcontrolador a un modo de bajo consumo con interrupciones habilitadas hasta la condición de finalización antes mencionada.
- Envío de condición de START lectura: Modifica el registro de control 1 del módulo de I2C de
forma de generar una condición de START con el bit de lectura.
- Envío de condición de START escritura: Modifica el registro de control 1 del módulo de I2C de forma de generar una condición de START con el bit de escritura.
- Desplegar datos por UART: Función que pasa los datos recibidos al buffer de transmisión de
UART. El objetivo es liberar los buffers de recepción de I2C e desplegar lo recibido por consola al transmitirlo por UART.
Por más información se puede consultar el código.
5.4. ISR I2C
Para implementar la rutina de atención a interrupción se partió de las suministradas por Texas Instruments en los ejemplos de código y se modificaron para que se adaptaran a los requerimientos del proyecto. En los ejemplos, cada uno de ellos sólo trata uno de los cuatro casos posibles, esclavo receptor, esclavo transmisor maestro receptor o maestro transmisor y por lo tanto las rutinas sólo aplican para uno de los cuatro casos.
El punto medular en el proyecto en cuanto a lo que refiere a I2C fue implementar una rutina que abarcara todos los casos de transmisiones posibles. Para realizar esto se utilizó una variable a la que se le asigna valor dependiendo de si se trata de una configuración maestro o esclavo. La estructura de la ISR, como se puede apreciar en la Figura 5, es básicamente una sentencia switch-case que evalúa el valor del vector de interrupciones del módulo para determinar si se trata de un STOP, START, TX, RX o NACK.
Es en el caso de las interrupciones de TX y RX, escritura en esclavo y lectura del esclavo respectivamente, se utilizó la variable mencionada para separar el caso de la configuración esclavo o maestro.
La diferencia principal es el hecho de que tanto en recepción como en transmisión el maestro es el responsable de controlar el flujo de bytes y enviar la condición de Stop cuando corresponda.
Cuando el dispositivo recibe información, tanto porque realice una lectura, o porque reciba una transmisión de otro maestro, se encola la función que pasa la información del buffer de entrada al buffer de I2C de transmisión de la UART.
12
Figura 5: Diagrama de la ISR final para I2C.
6. UART En esta sección se desarrollarán los conceptos de programación aplicados durante el proyecto sobre
la comunicación vía UART entre la consola disponible por el usuario y el micro controlador. Durante el curso de Sistemas Embebidos para Tiempo Real se había realizado un laboratorio sobre este modo de comunicación serial que disponen los microcontroladores por lo que algunas configuraciones ya eran conocidas así como algunos modos de funcionamiento. Se creyó que esta parte del proyecto no demandaría dedicación dado que las funcionalidades de envío y recepción estaban testeadas, sin embargo se encontró que los conceptos en cuanto al manejo de la UART no estaban firmes lo que provocó contratiempos no planificados. Esto se desarrollará más adelante.
6.1. Configuración
Las configuraciones utilizadas para la UART surgieron de las utilizadas para el laboratorio, que a su vez, fueron basadas en las brindadas en las brindadas por Texas Instruments en sus ejemplos de códigos, ver [2]. Dentro de las configuraciones necesarias se incluyen:
- Selección de pines. - Selección de fuente de reloj. - Selección de tasa de transmisión.
13
- Habilitación de interrupciones.
Estas configuraciones se realizan utilizando los macros proporcionados por las librerías del dispositivo que se referencian, por ejemplo, a los registros de control del módulo USCIA0, el cual es la interfaz de comunicación serial que soporta UART. Por más detalles acerca de las configuraciones se puede consultar [1]
6.2. ISR UART
En esta sección se analizará el diagrama de flujo de la rutina de atención a interrupciones de la interfaz USCIA0, utilizado, como fue mencionado anteriormente, para la comunicación vía UART.
6.2.1. Recepción
En el caso de recepción vía UART, simplemente se extraen los datos del buffer de recepción del dispositivo y se chequea la llegada de un final de línea. Se utiliza un puntero a carácter que apunta a un lugar de un buffer utilizado para la recepción para guardar los datos y se incrementa el puntero.
En caso de la llegada de un final de línea, condición que impone el terminal utilizado, se incrementa un contador utilizado para saber cuántos comandos se han recibido y están guardados en el buffer sin categorizar. Luego se encola la función que trata los datos recibidos por UART y libera el buffer. El diagrama de flujo se puede ver en la Figura 6.
6.2.2. Transmisión
El caso de una transmisión se resolvió de forma diferente al de la recepción. Al comenzar el proyecto, como ya mencionado anteriormente se creían resueltas las funcionalidades de transmisión y recepción por UART. Sin embargo, la transmisión no se estaba realizando correctamente. No se realizaba utilizando las interrupciones del dispositivo sino que se realizaba dentro de una función que bloqueaba el flujo del programa principal hasta que no se terminara la transmisión. A continuación se proporciona un pseudo código para ejemplificar más claramente:
While(cond){ UCA0TXBUF=*ptr_char++; ___delay_cycles(50); }
La función de transmisión ponía los datos en el buffer de transmisión y esperaba un tiempo suficiente
para repetir esta operación hasta que ya no hubieran datos para transmitir. Como se mencionó antes, esta forma de transmitir los datos desperdiciaba totalmente las ventajas de utilizar interrupciones para enviar datos.
Lamentablemente se descubrió este error muy avanzado el proyecto y se probó una forma de transmisión similar a utilizada para recepción, con un buffer y punteros que se incrementan antes de cada transmisión. Debido a las limitaciones de tiempos para migrar un sistema planificado sobre una estructura ya armada, surgieron muchos bugs lo que preocupó a los tutores. Ellos proporcionaron un código para tratar las transmisiones pero nuevamente estábamos ante una la misma situación. Se tenían que implementar cambios importantes en una sección crítica del programa, dado que comprendían la
14
interfaz con el usuario, y con poco tiempo para asimilar los conceptos y lograr su implementación sin errores.
La decisión adoptada fue adoptar la idea principal del programa, su columna vertebral, que era una estructura llamada “cola” y aglomerar las funciones para tratar a esa estructura en un módulo externo. Los detalles de esta implementación se desarrollarán más profundamente en la sección 8. , pero para esta sección solo basta con saber que la transmisión se realiza utilizando la cola mencionada.
Cuando se requiere una transmisión se agregan los caracteres a la cola, se habilitan interrupciones y se setea una bandera que indica que hay datos para enviar. En la ISR, como ejemplifica la Figura 6, se procede de la siguiente forma, mientras la cola no esté vacía, sí tiene un carácter se lo extrae y se lo coloca en el buffer de transmisión del USCI. De lo contrario, se deshabilitan las interrupciones de transmisión y se limpia la bandera que indica que se está enviando caracteres.
No se pudo implementar la recepción utilizando la misma estructura ya que se encontraron ciertos inconvenientes a la hora de implementar estos segmentos y no se contaba con tiempo ni disponibilidad de tutores para solucionarlo.
Figura 6: Diagrama de flujo de ISR de UART.
15
6.3. Funciones
Para este módulo se consideraron necesarias funciones que nuclearan el envío de mensajes utilizados repetidamente, el carácter de salto de línea o mensajes de error. Estas funciones mencionadas son:
- msjInicial(); - comandoErroneo(); - saltoLinea(); - esEsclavo(); - personalidadNoCargada(); Además se implementó una función que iniciara la transmisión, enableUart(), que verificara la
ejecución de una transmisión. De haber transmisión en ejecución, dicha función no debe realizar ninguna acción porque la transmisión se realiza automáticamente y de la misma participan la ISR de la UART y las funciones y variables del módulo queue.c. Si se tiene que iniciar la transmisión, se setea la bandera correspondiente, se extrae de la cola el primer carácter a transmitir, se coloca en el buffer de transmisión y se habilitan las interrupciones de transmisión. Cabe señalar que dicha función se ejecuta al momento que se desea realizar una transmisión por UART y previamente se deben cargar los datos a transmitir en la cola de transmisión.
El punto central de este módulo es la caracterización de los comandos recibidos por UART y el encolado de las funciones correspondientes. Dichas funcionalidades se agrupan en la función atiendo_UART(), la cual es encolada en la cola de funciones cada vez que por la UART se recibe un carácter de fin de línea. Dentro de esta función se encuentran dos funciones ya que se deben realizar dos funcionalidades distintas bien marcadas, por un lado liberar el buffer de recepción y almacenar los caracteres recibidos, responsabilidad de la función libero(), y por el otro lado se debe caracterizar los comandos recibidos y encolar las funciones correspondientes, responsabilidad de la función separo().
Como fue mencionado, la función libero() se encarga de liberar el buffer de recepción. Originalmente los datos se pasaban a otro buffer pero se decidió que no era lo suficientemente flexible en el caso de que llegaran dos comandos consecutivos y se encolaran a continuación. Por lo tanto se creó un módulo adicional que consiste en una estructura de buffers circulares para poder almacenar datos de varios comandos que se reciben consecutivamente, ver sección 7. .
La función separo() realiza simplemente la caraterización de los comandos recibidos por UART. Si llegara a corresponder con alguno de los comandos del Shell se encola dicha función, de lo contrario se debe enviar por UART un mensaje de error.
7. Almacenamiento de datos El enfoque de desarrollo que se enfocó al desarrollo del proyecto fue incrementar, a medida que se
obtuvieran resultados positivos, la complejidad del sistema. Por lo tanto, avanzado el proyecto se descubrió que era necesario brindar capacidad de almacenamiento de datos para comandos ejecutados o eventos que se generaran en forma de “streaming”.
En un comienzo luego de llegado un comando se liberaba el buffer de recepción y el comando recibido con sus parámetros eran almacenados en otro buffer de datos. Si esos datos eran sobrescritos, por ejemplo por otro comando ingresado, antes que se ejecutara el primer comando, se generaría un error.
Se decidió priorizar el throughput del sistema ya que se buscaba la mejor optimización del mismo. Por lo tanto, esperar a que los comandos fueran ejecutados para poder tratar al siguiente no era una
16
opción. Entonces se buscó brindar al sistema con algún tipo de soporte de datos que permitiera encolar múltiples funciones y que no se generen problemas de sobre escrituras de datos y parámetros. Este camino coincide y se complementa con el haber desarrollado una cola de estructura que contuviera un puntero a función, su cantidad de argumentos y los punteros a argumentos, ver sección 4.3.
La solución consistió en generar un módulo independiente que manejara el soporte de datos. Contiene una cantidad fija de arreglos de caracteres, para guardar los datos, y arreglos de punteros a caracteres, para almacenar los punteros a los argumentos. A su vez se generó un arreglo de punteros a caracteres que contiene las direcciones de memoria de los arreglos de datos y otro arreglo de punteros a punteros que contiene las direcciones de memoria de los arreglos de punteros.
Conjuntamente con dichos arreglos se generaron funciones que pudieran manejarlos y proporcionaran punteros a buffers a utilizar y otras funciones necesarias. De esta manera, cuando llega un nuevo comando se solicita un nuevo buffer y no se obtienen problemas de sobre escritura. En principio no se consideró necesario chequear disponibilidad de buffers ya que para la aplicación que se le puede dar al día de hoy no se enfrentaría a un streaming tan exigente, pero debería ser una alternativa a considerar si se desea exigir a este sistema de dicha forma.
8. Queues Como se mencionó en la sección 6.2.2, durante el proyecto se encontró un mal manejo de las
transmisiones por UART y limitaciones de tiempos para programar y testear las soluciones. Ante esta problemática los tutores proporcionaron un código para intentar solucionar la situación. La solución no fue inmediata ya que dicho código no se integraba de forma inmediata al que se estaba desarrollando y se prefirió intentar prescindir de dicho código lo más posible e implementar alguna solución propia.
Se estudió los pilares de la solución brindada por los tutores y se encontró que su columna vertebral consistía en una estructura donde aglomeraba todas las funcionalidades de la cola a implementar y consistía una muy buena solución, práctica, elaborada y que atacaba muy eficazmente el problema. Se buscó desarrollar un módulo de manejo de colas, así como lo hacía el proporcionado, pero partiendo solo de la utilización de una estructura similar y desarrollando el resto.
Este fue un punto clave porque consistió en un aprendizaje de nuevos métodos para atacar problemas de manera sencilla pero elaborada a la vez. Se valoró la determinación de elaborar código propio lo que derivó en un mayor entendimiento de los conceptos y aplicabilidad de las estructuras así como también el manejo de referencias.
17
9. Implementación
9.1. Hardware
Se trabajó con el micro controlador MSP4305438A de Texas Instruments y se los dispuso en la
siguiente configuración (Figura 7).
Figura 7: Diagrama de conexión.
La asignación de Pines fue la siguiente: - 34 SDA (conectado a VCC a través de una resistencia de pull up de 10K). - 35 SCL (conectado a VCC a través de una resistencia de pull up de 10K). - 37 GND - 38 VCC - 39 UART TX - 40 UART RX De manera de poder conectar el micro controlador al puerto serie RS232, es necesario intercalar un
circuito integrado, Max232 de Maxim, con el fin de convertir las señales a niveles compatibles TTL.
9.2. Software
A continuación vemos un esquema de los módulos desarrollados, con sus respectivas funciones. Por más información se puede consultar el código documentado en Doxygen.
18
Figura 8: Diagrama de módulos del sistema.
El módulo no mencionado hasta el momento es Shell_commands.c. Dentro de este módulo se encuentran el array con los comandos que se deben introducir, sus respectivas descripciones y punteros a funciones. Las funciones que explícitamente están desarrolladas en este módulo son funciones realizadas para conseguir una interfaz amigable con el usuario. Una de ellas es help(), que imprime la lista de comandos disponibles o la descripción de alguno en especial si se indica. La otra es una función que despliega en pantalla la lista de personalidades que puede adoptar el dispositivo. El resto de las funciones correspondientes a los otros comandos no se desarrollan en este módulo porque pertenecen a otros, por ejemplo, i2c.c.
10. Pruebas Parte del proyecto fue efectuar pruebas a medida que el modulo se iba desarrollando, de forma de
probar todas sus funcionalidades por separado. Algunas de las pruebas que se realizaron:
Ingreso de comandos con parámetros vía UART.
Identificación de comandos ingresados y el encolado de la función correspondiente.
Comunicación básica I2C usando el código proporcionado por Texas Instruments.
Adaptación de rutina de atención a interrupción para esclavo trasmisor y receptor.
Adaptación de rutina de atención a interrupción para maestro trasmisor y receptor.
Adaptación de rutina de atención a interrupción que comprenda cuatro situaciones básicas.
19
11. Conclusiones
11.1. Planificación
En cuanto a la planificación se encontraron las siguientes conclusiones: - Las estimaciones iniciales deben ser más realistas. Se subestimaron ciertas tareas que insumieron
más tiempo del pronosticado. - La planificación del proyecto debe contener tareas más pequeñas y especificas en vez de pocas y
genéricas. Hecho esto, es necesario visualizar las tareas críticas para el desarrollo del proyecto. - Se debería contemplar más tiempo para imprevistos. - Es necesario evaluar constantemente el cronograma de manera de poder arrancar tareas futuras
cuando se está bloqueado con otras. Por más información consultar Anexo.
11.2. Conclusiones generales
Se encontraron varias dificultades a lo largo del proyecto, muchas de las cuales surgieron en tareas que se consideraban implementadas y solucionadas. Dichas problemáticas provocaron reestructuras importantes en puntos clave del proyecto y tampoco se contaba con tiempo suficiente para realizar la programación necesaria y el testo. Esto provocó que el producto final no tuviese la robustez deseada. Sin embargo se supo aprovechar los inconvenientes para reforzar conceptos y alcanzar una compresión superior de programación en C.
Desde un principio se buscó que la soluciones a los problemas planteados fuesen eficientes de forma de no tener que volver sobre estos puntos avanzado el proyecto. La intención fue lograr un producto robusto y pulir los detalles. Es así que se le brindó especial atención a lograr el mejor throughput para el sistema, entre otros detalles.
El producto desarrollado cumple con las especificaciones básicas iniciales y se intentó que fuera robusto. Lamentablemente, debido a los contratiempos sufridos no fue posible contemplar otros casos de uso.
11.3. Tareas pendientes
Dentro de las tareas pendientes se encuentran considerar el caso del envío de una condición de START con una dirección de un esclavo que no se encuentra conectado al SDA. Esto representa un problema ya que en esta situación el dispositivo queda esperando un ACK que recibirá. Una forma de solucionarlo es configurar un timer con un tiempo determinado e iniciarlo antes de enviar una condición de START y resetearlo apenas se entre en la rutina de interrupción, en cualquiera de los casos. En caso de no llegar el ACK se sale de la rutina y se atiende el caso de error.
Otra de las tareas pendientes consiste en la comunicación en modo multimaestro. Si bien no resulta una tarea difícil, no se contó con el tiempo como para probar esta configuración. Lo único que habría que tener en cuenta es la configuración de los puertos y el manejo de las rutinas de atención a interrupciones con funciones apropiadas. Cabe mencionar que el sistema ya configura a los maestros con dirección propia, punto importante en una configuración multimaestro. Para esta situación se deberían agregar otras funciones al Shell y modificar la atención a las rutinas de I2C.
20
12. Bibliografía
[1] Texas Instrument Incorporated, MSP430x5xx/MSP430x6xx Family, User´s Guide, 2008.
[2] Texas Instruments Incorporated, MSP430F543x, MSP430F541x Code Examples, Dallas, 2009, p. http://www.ti.com/lit/zip/slac166.
[3] K. D. ,. J. M. ,. H. ,. D. N. ,. G. D. I.Galysh, CubeSat: Developing a Standard Bus for Picosatellites, 9512 Rockport Rd, Vienna, VA 22180.
[4] Philips, I2C Overview, 2003.
21
Anexo
I. Antelsat
La Facultad de Ingeniería de la Universidad de la República junto con Antel, se encuentran desarrollando el proyecto “Antelsat” [3] el cual consiste en el diseño, implementación, puesta en órbita y control de un nano satélite para lo que se utilizará el estándar Cubesat (Figura 9).
Cubesat es el nombre que se le da a un tipo de micro satélites de investigación, con limitaciones de tamaño y peso (10x10x10 centímetros y no más de 1 kilogramo). Las especificaciones para los CubeSat fueron establecidas en 1999 por la Universidad Politécnica de California y la Universidad de Stanford de manera que las universidades del mundo puedan realizar investigaciones espaciales con costos reducidos.
Figura 9: Cubesat.
El satélite está compuesto por varios módulos entre los que se encuentran: 1. Módulo de Control Principal 2. Módulo de Detección y Control de Actitud 3. Módulo de Gestión de Energía 4. Módulo de Telemetría 5. Payload
Parte del funcionamiento consiste en el intercambio de datos entre diferentes módulos. Como por
ejemplo, la solicitud de “housekeeping” por parte del Módulo de Control Principal, la que consiste en recabar datos del resto de los módulos. Estos datos pueden ser: voltaje en baterías, temperatura en diferentes puntos del satélite, lectura de fotodiodos, etc. Luego de ser guardados, son enviados a tierra. La comunicación entre estos módulos se hará por medio de un bus serial I2C (ver Anexo II).
22
II. I2C
I2C [4] es un bus de comunicaciones serie síncrono diseñado por Philips en los 80’s y su nombre
deriva de “Interconnected Integrated Circuits”. El bus es ampliamente usado en la industria, principalmente para comunicar microcontroladores con sus periféricos en Sistemas Embebidos.
El bus soporta 4 modos de operación: 1. Standard mode 100 kb/s 2. Fast mode 400 kb/s 3. Fast mode plus 1 Mb/s 4. High speed mode 3.4 Mb/s
La característica más importante de I2C es que utiliza dos líneas para transmitir la información : SDA: señal de datos (entre maestro y esclavos) SCL: señal de reloj (sincroniza datos que viajan por SDA) Existe también una tercera línea, la cual es una referencia.
Figura 10: Bus I2C
Cada dispositivo conectado al bus posee una dirección única y puede ser tanto maestro como esclavo. El maestro inicia la transferencia de datos y además genera la señal de reloj, pero no tiene porque ser el mismo dispositivo siempre, se pueden alternar los dispositivos siempre y cuando tengan la capacidad de ser maestros. También es posible que haya varios esclavos conectados al bus, pero el maestro se comunicara con uno a la vez.
Los datos se transfieren en forma de paquetes, las cuales empiezan con un START y finalizan con un
STOP. Cada dato es de 8 bits (1 byte) y va seguido de un bit adicional de reconocimiento (ACK o NACK). La transferencia puede ser de varios bytes o de uno solo.
Figura 11: Datos en el bus I2C
23
Los datos se transfieren por SDA y son sincronizados por el reloj en SCL. Los datos pueden viajar ida y vuelta por SDA ya que es el maestro el que controla cuando se transmite o recibe. Por tanto, el maestro y esclavo pueden intercambiar los roles de emisor y receptor, pero el que maneja SCL es siempre el maestro.
La condición de START se da cuando estando SCL en nivel alto, se da una transición de alto a bajo en
SDA. Luego de START el bus se considera ocupado. La condición de STOP se da cuando estando SCL en nivel alto, se da una transición de bajo a alto en
SDA. Luego de STOP el bus se considera libre.
Figura 12: Secuencia de START y STOP.
El noveno bit presente en la transferencia, es un bit de reconocimiento devuelto por el receptor tras haber recibido cada byte. Si el bit de reconocimiento es 0, significa que el dato fue reconocido y aceptado (ACK). En cambio, si es 1, significa que el dato no es aceptado aun (NACK) ya que el receptor se encuentra resultando alguna otra tarea.
El maestro es el que establece con quien se va a comunicar y si va a transmitir o recibir, por tanto es
necesario enviar un primer byte de control. Los primero 7 bits de dicho byte contienen la dirección del esclavo con el que nos vamos a comunicar y el octavo bit (R/W) indica si será lectura o escritura.
R/W = 0 indica escritura R/W = 1 indica lectura Por ejemplo, si se pretende escribir en la dirección 10h se debe enviar 20h, que es 10 desplazado un
bit hacia arriba. Otra forma de ver las direcciones es como números de 8 bits, donde los pares son de solo escritura y los impares de solo lectura.
Figura 13: Byte de control.
Todos los esclavos reciben el byte de control, pero solo el que reconozca su dirección de control en el será el que continúe la comunicación. Los demás esclavos se mantienen al margen hasta que se de otra condición de START.
24
Luego de haber direccionado el dispositivo esclavo, el maestro debe ahora enviar la ubicación interna del registro que se desea escribir.
Después de enviar la dirección del dispositivo y el registro interno, puedo enviar ahora los bytes de
datos. Cuando el maestro finaliza el envío de datos, envía una secuencia de parada y se termina la transacción.
Si en vez de escribir en un esclavo, quiero leer del mismo, primero debo indicarle desde cuál de sus
direcciones internas se va a leer. De forma que una lectura desde un esclavo comienza con una escritura en el. Después, se envía una nueva secuencia de inicio con la dirección del dispositivo pero con el bit de R/W en alto. Luego de leer todos los bytes, se termina la transacción con una condición de STOP.
Como se puede apreciar, en una comunicación I2C, el maestro es el que determina la velocidad del
reloj. Sin embargo hay situaciones en las cuales el esclavo no puede cumplir con la velocidad dada por el maestro y por tanto debe demorar un poco más. Esto se realiza mediante un mecanismo llamado “clock stretching”. Al esclavo le es permitido mantener el reloj en nivel bajo si precisa disminuir la velocidad del bus. A su vez, el maestro requiere leer la señal de reloj una vez que esta sube a nivel alto y esperar hasta que efectivamente esté alta.
25
III. UART
UART (Universal Asynchronous Receiver Transmitter) es un modulo del MSP430 que sirve para comunicar al microprocesador con una PC.
La UART usa 2 líneas, TX (Trasmisión) y RX (Recepción), es asíncrona por tanto no precisa reloj. Si lo
conectamos otro módulo que usa UART, debemos cruzar las líneas. O sea el TX de un dispositivo se conecta al RX del otro y el RX del primero con el TX del segundo.
Figura 14: UART
La UART trabaja de manera serial y utiliza un buffer de 1 byte. El módulo envía un bit de START, siete u ocho bits de datos, uno o ningún bit de paridad, un bit de dirección y uno o dos bits de STOP. La cantidad de bits depende de la configuración de la UART, típicamente son 1 bit de START, 8 de datos, 1 de STOP y ninguno de paridad.
Figura 15: Datos UART.
Configuración de la UART Antes de poder utilizar la UART, es necesario configurar la PC y el módulo de la UART. Como la
comunicación es asíncrona, ambos deben estar configurados correctamente para evitar problemas en la transmisión.
Por ejemplo, es necesario: - Seleccionar los pines de E/S de la UART (P3SEL) - Parar el Watchdog (WDTCTL) - Seleccionar el reloj (UCA0CTL1) - Setear los baudios de acuerdo al reloj (UCA0BR0 y UCA0BR1). - Setear la modulación de manera de minimizar errores (UCA0MCTL) - Resetear e iniciar la máquina de estados (UCA0CTL1) - Habilitar interrupciones (UCA0IE)
26
Configuración del Host Una vez que la UART en el MSP430 está configurada, se debe configurar el software en el Host.
Algunos software disponibles son: Putty, Hyperterminal, RealTerm. Para configurarlo, es necesario ver el Puerto COM al que está conectado el MSP430. Luego
seleccionar la tasa de baudios que configuramos en la UART, setear los bits de datos a ocho, ningún bit de paridad y un stop bit (en caso de que se haya hecho así con la UART).
27
IV. Planificación
De manera de poder estimar con más exactitud los tiempos que iba a insumir el proyecto, lo subdividimos en varias tareas.
Tarea Descripción
1 Estudio Protocolo I2C.
2 Uso de I2C y UART en MSP430f5438A.
3 Diseño del sistema, funcionalidades y requerimientos.
4 Implementación y pruebas.
5 Documentación y preparación de presentación.
Luego asignamos tiempos estimados a cada una de ellas, considerando la fecha de finalización del
21/6/2012 y dejando una semana de buffer ante cualquier eventualidad. Este ejercicio nos dio el siguiente resultado:
Figura 16: Diagrama de Gantt de tareas (24 de abril).
El esquema de tiempos tuvo que ser modificado a medida que el tiempo fue corriendo debido a varios factores: el alcance del proyecto no había quedado del todo claro y demoras en el diseño e implementación de la solución. Llegamos al siguiente estado de situación 3 semanas después:
Figura 17: Diagrama de Gantt de tareas (18 de Mayo).
28
2 semanas más tarde hubo que hacer mas ajustes con lo que llegamos finalmente al siguiente esquema de tiempos, que se mantuvo hasta el final (con el agregado que hubo una prórroga para entregar la documentación y por tanto esta tarea se alargo).
Figura 18: Diagrama de Gantt de tareas (20 de Junio).
Por tanto, viendo la acumulación de tareas hacia el final del proyecto, podemos afirmar que la planificación inicial no fue del todo acertada. Dentro de las causas podemos encontrar:
La estimación inicial debió ser más realista.
El alcance del proyecto no estaba del todo claro desde el inicio
La decisión de intercambiar tareas o adelantar tareas de más adelante debe ser hecha antes.
Surgieron problemas no contemplados, como ser los referidos al manejo de la UART y problemas con el hardware.
En primera instancia estimamos que el proyecto iba a insumir alrededor de 150 horas. Las cuales se
dividen de la siguiente manera: 12 horas (Tarea 1), 24 horas (Tarea 2), 24 horas (Tarea 3), 48 horas (Tarea 4) y 24 horas (Tarea 5), 18 horas para imprevistos.
Luego de concluido el proyecto, podemos consignar que el proyecto insumió alrededor de 200 horas.
Subdivididas de la siguiente manera: 12 horas (Tarea 1), 24 horas (Tarea 2), 60 horas (Tarea 3), 60 horas (Tarea 4) y 44 horas (Tarea 5).