OarMeter
Sistema digital para la asistencia al calibrado de los remos, en un bote de remo de competición.Carlos Falgueras Garcíanoreply@blogger.comBlogger7125
Actualizado: hace 5 horas 30 mins
¡Testíng!
Como comentábamos en una entrada anterior, se ha utilizado la placa de desarrollo STM32F4-Discovery provisionalmente para facilitar el desarrollo del firmware, debido a que ésta dispone de depurador.
Se ha desarrollado una pequeña aplicación de test que utiliza las dos bibliotecas que se han creado (para el LCD y para la IMU). En este test leemos los datos de la IMU y los mostramos en la pantalla de dos formas distintas: mediante una gráfica temporal y con texto. También se ha dibujado una especie de reloj con el fin de depurar el comportamiento del algoritmo de trazado de lineas.
Debido a que las librerías utilizadas para la gestión de los periféricos y la configuración del micro no son libres, no voy a subir este código al repositorio. Dejo un enlace aquí por si a alguien le es de ayuda: https://drive.google.com/file/d/0B2X0VWywUQgtZjRYQmN3QzFySFU/view?usp=sharing
A continuación se muestra un pequeño video del montaje en funcionamiento.
Biblioteca IMU
El sistema utilizará una IMU (MPU6050 de InvenSense) para obtener información sobre su verticalidad. Este dispositivo, que se comunica mediante I²C, tiene una configuración algo compleja. Para utilizarlo se ha buscado una biblioteca de software libre que facilitara el trabajo.
La biblioteca elegida está bastante completa y bien documentada, pero es específica para los micros de la familia STM32f103xx. Por esto se ha optado por crear un fork donde se ha trabajado en eliminar las dependencias de hardware de la biblioteca y crear una capa BSP.
La dependencia de la biblioteca respecto al periférico I²C aún puede gestionarse algo mejor, añadiendo parte del protocolo de comunicación a la biblioteca y delegando en el usuario la implementación de un BSP mínimo.
Enlace al repositorio: https://github.com/FarK/MPU6050-Generic-RTOS
Port de FreeRTOS para ATMega328 y estructura del proyecto
Ya he completado el "port" de FreeRTOS para el ATMega328 (repo). Además he creado la estructura básica para el código del firmware y he configurado la compilación usando CMake.
FreeRTOS haciendo parpadear un LED en un ATMega328p Port FreeRTOSFreeRTOS es un sistema operativo de tiempo real de open source ligero que puede caber en microcontroladores pequeños, como es el caso del ATMega328. Como es lógico, el código de FreeRTOS no es independiente del hardware dónde se vaya a usar, adaptarlo a uno específico es lo que se suele llamar "port".
Portar FreeRTOS se reduce a implementar/modificar dos archivos:
Estructura y CMakeSe ha optado por CMake como herramienta de compilación. Además de comprobar las si se disponen de las herramientas necesarias y generar el makefile para compilar, se ha creado un "target" para facilitar la programación de la placa. De forma que, al hacer make, se compila el firmware y se prepara el binario para programar el microcontrolador. Y al hacer make program grabamos este binario en el microcontrolador.
La programación del micro se puede hacer de distintas formas en función de la placa de desarrollo y el programador/depurador del que se disponga. Para establecer una configuración específica basta con modificar las variables en CMakeLists.txt dispuesta para ello.
FreeRTOS haciendo parpadear un LED en un ATMega328p Port FreeRTOSFreeRTOS es un sistema operativo de tiempo real de open source ligero que puede caber en microcontroladores pequeños, como es el caso del ATMega328. Como es lógico, el código de FreeRTOS no es independiente del hardware dónde se vaya a usar, adaptarlo a uno específico es lo que se suele llamar "port".
Portar FreeRTOS se reduce a implementar/modificar dos archivos:
- port.c: Donde se implementan las funciones de cambio de contexto, gestión del stack y configuración del timer del sistema, entre otras.
- portmacro.h: Aquí se defines algunas macros dependientes del hardware para la habilitación/desabilitación de las interrupciones y definición de tipos.
- heap_#.c: Los archivos heap_1.c, heap_2.c, etc implementan las funcionalidades de reserva dinámica de memoria. FreeRTOS tiene varios sistemas de gestión de memoria, en nuestro caso hemos elegido el más simple por ser el más eficiente (heap_1.c).
Estructura y CMakeSe ha optado por CMake como herramienta de compilación. Además de comprobar las si se disponen de las herramientas necesarias y generar el makefile para compilar, se ha creado un "target" para facilitar la programación de la placa. De forma que, al hacer make, se compila el firmware y se prepara el binario para programar el microcontrolador. Y al hacer make program grabamos este binario en el microcontrolador.
La programación del micro se puede hacer de distintas formas en función de la placa de desarrollo y el programador/depurador del que se disponga. Para establecer una configuración específica basta con modificar las variables en CMakeLists.txt dispuesta para ello.
Biblioteca LCD
Como se expuso en la entrada anterior, se ha implementado una biblioteca para el control de la LCD de Nokia (controlador PCD8544). En esta entrada voy a explicar las principales características de esta biblioteca, el trabajo realizado y el que queda por hacer.
Interfaz con el LCDComenzamos describiendo cómo nos comunicamos con el LCD. Los dos pines más importantes son los de MOSI (o data) y D/C (Datos/Comandos). El es por dónde el LCD recibe los datos mediante un protocolo SPI, el segundo pin indica cuando el dato enviado es un valor de un pixel o un comando de control del LCD. La pantalla tiene un pequeño conjunto de comandos sencillos para seleccionar la posición del pixel a escribir, variar el contraste, invertir o borrar la pantalla, etc.
IndependenciaEsta biblioteca no depende del Hardware donde se utilice. Esto se consigue delegando la implementación de todas las funcionalidades dependientes del Hardware al usuario. Así, el uso de la biblioteca no está limitado a una Hardware en particular. Para adaptarlo a una u otra placa de desarrollo hay que implementar las funciones de la cabecera "lsd_bsp.h". Internamente, la biblioteca utilizará esta funciones para controlar la pantalla.
Las funciones principales que se delegan son las tres siguientes:
También es necesario implementar las siguientes funciones para el manejo de pines e inicialización:
FuncionalidadesLa biblioteca no está completa y las funcionalidades que implementa ahora mismo son solamente de inicialización y control del LCD, y escritura y envío de un buffer a la pantalla. Ya se está trabajando en la implementación de una "biblioteca gráfica" con algoritmos para dibujar líneas, círculos, rectángulos y demás figuras geométricas.
¡Colabora!Esta biblioteca es libre con licencia GPL. Si estás interesado te animo a colaborar creando un fork del repositorio y haciendo un pull-request, o enviándome un parche a carlosfg <arroba> riseup <punto> net
Interfaz con el LCDComenzamos describiendo cómo nos comunicamos con el LCD. Los dos pines más importantes son los de MOSI (o data) y D/C (Datos/Comandos). El es por dónde el LCD recibe los datos mediante un protocolo SPI, el segundo pin indica cuando el dato enviado es un valor de un pixel o un comando de control del LCD. La pantalla tiene un pequeño conjunto de comandos sencillos para seleccionar la posición del pixel a escribir, variar el contraste, invertir o borrar la pantalla, etc.
IndependenciaEsta biblioteca no depende del Hardware donde se utilice. Esto se consigue delegando la implementación de todas las funcionalidades dependientes del Hardware al usuario. Así, el uso de la biblioteca no está limitado a una Hardware en particular. Para adaptarlo a una u otra placa de desarrollo hay que implementar las funciones de la cabecera "lsd_bsp.h". Internamente, la biblioteca utilizará esta funciones para controlar la pantalla.
Las funciones principales que se delegan son las tres siguientes:
- void LCD_BSP_send(uint8_t* data, uint16_t size): El envío de datos mediante protocolo SPI. Esta cabecera junto con las funciones de espera, permite al usuario una total libertad a al hora de elegir la forma de enviar los datos (SPI, SPI+DMA, bit banging...).
- void LCD_BSP_waitUntilTXA(): Esperar hasta que se permita una nueva transmisión. Delegar las funciones de espera son el fundamento del soporte para RTOS.
- void LCD_BSP_waitUntilTXC(): Esperar hasta que se haya completado la transmisión. Delegar las funciones de espera son el fundamento del soporte para RTOS.
También es necesario implementar las siguientes funciones para el manejo de pines e inicialización:
- void LCD_BSP_init(): Permite al usuario inicializar los periféricos que vaya a necesitar: SPI, DMA, timer, etc
- void LCD_BSP_RST(): Debido a que es necesario gernerar un pulso de una determinada duración, en un pin específico; se delega la implementación de esta acción.
- void LCD_BSP_setCE(uint8_t state): Establecer el estado (voltaje alto o bajo) del pin CE es una acción dependiente del Hardware.
- void LCD_BSP_setD_C(uint8_t state): Establecer el estado (voltaje alto o bajo) del pin D/C es una acción dependiente del Hardware.
- void LCD_BSP_setLIGHT(uint8_t state): Muchas pantallas vienen con unos LEDs para iluminarla. Si se desea, se debe implementar el control de los mismos.
FuncionalidadesLa biblioteca no está completa y las funcionalidades que implementa ahora mismo son solamente de inicialización y control del LCD, y escritura y envío de un buffer a la pantalla. Ya se está trabajando en la implementación de una "biblioteca gráfica" con algoritmos para dibujar líneas, círculos, rectángulos y demás figuras geométricas.
¡Colabora!Esta biblioteca es libre con licencia GPL. Si estás interesado te animo a colaborar creando un fork del repositorio y haciendo un pull-request, o enviándome un parche a carlosfg <arroba> riseup <punto> net
LCD NOKIA
Este proyecto usa la popular LCD de los antiguos Nokia 3310 y 5110. Estas pantallitas son muy baratas, fáciles de usar, con muy bajo consumo y una resolución bastante aceptable (84x48). Son precisamente estas características por las que se ha seleccionado para el proyecto.
BibliotecasAl ser tan populares existen varias bibliotecas para facilitar el uso de esta pantalla. Entonces, ¿por qué desarrollar otra nueva? La mayoría de las bibliotecas que encontramos están desarrolladas para una placa de desarrollo o microcontrolador específico (Arduino principalmente). Y las que no lo están, tienen ciertas carencias (desde mi punto de vista) que he querido solverntar.
La principal de estas carencias es una compatibilidad 100% con un sistema operativo en tiempo real (RTOS). Cuando usamos un RTOS vamos a querer evitar las esperas activas, ya que la tarea que las utilice va a consumir tiempo de CPU tóntamente, robándoselo potencialmente al resto de tareas.
Otra de las mejoras realizadas es proporcionar una mayor flexibilidad para la implementación de las funciones de envío de datos al LCD. Esto quiere decir que permite al usuario utilizar todo el potencial de su microcontrolador. Por ejemplo, en el caso de no disponer de un bus SPI podrá utilizar la técnica del bit banging, y si su µC dispone de un bus SPI con DMA podrá utilizarlo también, implementando las mismas funciones.
Esto no quiere decir que haya descartado todo el gran trabajo que podemos encontrar en las otras bibliotecas. De ellas he tomado muchas ideas, estructuras y algoritmos, adaptándolos a mi gusto en algunos casos y mejorándolos (a mi parecer) en otros. Esto es uno de los aspectos más bonitos del software libre. Por esto mismo, termino esta entrada agradeciendo el magnífico trabajo a los autores de las dos principales bibliotecas en las que he inspirado mi trabajo:
BibliotecasAl ser tan populares existen varias bibliotecas para facilitar el uso de esta pantalla. Entonces, ¿por qué desarrollar otra nueva? La mayoría de las bibliotecas que encontramos están desarrolladas para una placa de desarrollo o microcontrolador específico (Arduino principalmente). Y las que no lo están, tienen ciertas carencias (desde mi punto de vista) que he querido solverntar.
La principal de estas carencias es una compatibilidad 100% con un sistema operativo en tiempo real (RTOS). Cuando usamos un RTOS vamos a querer evitar las esperas activas, ya que la tarea que las utilice va a consumir tiempo de CPU tóntamente, robándoselo potencialmente al resto de tareas.
Otra de las mejoras realizadas es proporcionar una mayor flexibilidad para la implementación de las funciones de envío de datos al LCD. Esto quiere decir que permite al usuario utilizar todo el potencial de su microcontrolador. Por ejemplo, en el caso de no disponer de un bus SPI podrá utilizar la técnica del bit banging, y si su µC dispone de un bus SPI con DMA podrá utilizarlo también, implementando las mismas funciones.
Esto no quiere decir que haya descartado todo el gran trabajo que podemos encontrar en las otras bibliotecas. De ellas he tomado muchas ideas, estructuras y algoritmos, adaptándolos a mi gusto en algunos casos y mejorándolos (a mi parecer) en otros. Esto es uno de los aspectos más bonitos del software libre. Por esto mismo, termino esta entrada agradeciendo el magnífico trabajo a los autores de las dos principales bibliotecas en las que he inspirado mi trabajo:
- GLCD de http://agock.com. Repositorio: http://agock.com/software/glcd-graphic-lcd-library/
- Las dos bibliotecas de https://www.adafruit.com. Repos: https://github.com/adafruit/Adafruit-PCD8544-Nokia-5110-LCD-library y https://github.com/adafruit/Adafruit-GFX-Library
STM32F4-Discovery para depuración
Aunque el proyecto final se implementará en un ATMega328 para el desarrollo del firmware estoy utilizando una placa de desarrollo de ST, la STM32F4-Discovery. Esto se debe principalmente a que incluye el depurador, que va a facilitar enormemente el desarrollo.
Todo el código se va a modularizar mucho, separando sobre todo las partes dependientes del hardware. Así, cuando se termine de desarrollar y depurar el firmware en la Discovery, la migración al ATMega solo supondrá implementar unas pocas funciones relacionadas con la configuración y uso del SPI, GPIOs, Timers, etc
¿Por qué el ATMega328 y no la Discovery?Pues por tres factores:
Todo el código se va a modularizar mucho, separando sobre todo las partes dependientes del hardware. Así, cuando se termine de desarrollar y depurar el firmware en la Discovery, la migración al ATMega solo supondrá implementar unas pocas funciones relacionadas con la configuración y uso del SPI, GPIOs, Timers, etc
¿Por qué el ATMega328 y no la Discovery?Pues por tres factores:
- Consumo: El µC de la Discovery es un ARM Cortex-M4 de 32bits y el ATMega328 es un micro de 8 bits más sencillito, con menos periférico, menos frecuencia de reloj y menos consumo. Como no se necesita más de lo que nos proporciona el ATMega328, nos quedamos con él.
- Tamaño: La Discovery es una placa relativamente grande y crear la nuestra propia y soldar el ARM es bastante complejo. El ATMega328 tiene un encapsulado de pocos pines y la circuitería para echarlo a andar es muy simple (como vimos en el esquemático propuesto)
- Bibliotecas: Las bibliotecas para la configuración y el control de los periféricos del ARM son privativas y demasiado complejas para perder el tiempo replicándolas. Las del ATMega son libres, así que el firmware que desarrolle cumplirá con las normas del concurso.
