Blog de desarrollo de Curuxa

Probablemente la mayoría de los que leáis este blog estaréis acostumbrados a desarrollar software para ordenador. En ellos es bastante común que al comienzo del desarrollo de una nueva aplicación puedas escribir cientos o incluso más de mil líneas de código en un sólo día. Código bien estructurado, poco propenso a errores, documentado y fácil de entender.

Por el contrario, el desarrollo de software para MCUs (microcontroladores) es, por lo general, muy lento y tedioso. Es más que habitual dedicar varias horas para escribir un simple programa en cuya función principal sólo se terminan escribiendo un puñado de líneas de código y ni siquiera se hacen llamadas a otras funciones. El código, además, suele estar escrito a un nivel excesivamente bajo, lo que hace que el desarrollador deba tener en cuenta multitud de variables, combinaciones y detalles que en un ordenador no necesitan tenerse en cuenta, lo cual ocasiona que el programa resultante sea bastante propenso a errores, incluso en manos de programadores expertos.

Una de las tareas más tediosas suele ser la configuración de los periféricos internos del propio microcontrolador. Temporizadores y conversores analógico-digital son ejemplos muy habituales de periféricos integrados que la gran mayoría de MCUs tienen disponibles. Estos bloques funcionales son muy configurables y pueden utilizarse en infinidad de aplicaciones debido a la flexibilidad de funcionamiento que tienen. Esto hace que incluso para las tareas más simples el programador deba dedicar mucho tiempo a entender cómo funciona y cómo se configuran todos y cada uno de los bits individuales de los registros de la RAM asociados al periférico integrado que se esté utilizando.

Los compiladores normalmente incluyen funciones que pretenden simplificar la tarea de configuración de estas funcionalidades. No obstante, debido a la necesidad de ofrecer las mismas o casi tantas posibilidades y combinaciones que tendrías si lo configurases bit a bit (sin utilizar estas librerías), las funciones ofrecidas deben contarse por decenas o cientos, son tanto o más complicadas de usar que la configuración manual, requieren grandes cantidades de parámetros basados en defines y operaciones binarias, y muchas de ellas están vagamente documentadas y ejemplificadas.

Suelen existir muy pocos compiladores para cada arquitectura de microcontroladores y cada lenguaje de programación. Además, la calidad, estabilidad y fiabilidad de estos compiladores (tanto libres como comerciales) suelen ser muy inferiores a las de los compiladores para ordenador. Como ya he comentado, sus librerías suelen ser escasas, difíciles de usar y muy mal documentadas; el código máquina generado es, por lo general, bastante eficiente, pero muchas veces incluye errores que modifican la lógica del programa original. Sobre esto voy a comentar una anécdota que me ocurrió hace un tiempo:

A principios de 2009 me disponía a programar un microcontrolador en lenguaje C utilizando uno de los compiladores más conocidos que hay. Este compilador es comercial y, aunque tiene versiones tanto para Windows como para Linux, realmente nunca he conocido a nadie que lo utilizase en Linux. Mi código fuente era muy simple, ya que pretendía ser el código de ejemplo para un pequeño robot siguelíneas que más adelante utilizarían los participantes de unos talleres de introducción a la robótica. El código en C no necesitaba compilarse en más que unas pocas instrucciones en código máquina, y tras repasarlo una y otra vez todo parecía estar escrito correctamente. El compilador compilaba el código sin errores ni avisos, pero el microcontrolador actuaba erróneamente. Tras varias horas sin encontrar el error, decidí desensamblar el binario generado por el compilador y estudiar el código en lenguaje ensamblador que había sido generado. El programa estaba compuesto de unas 60 instrucciones en código máquina, y casi todas ellas se habían generado adecuadamente. No obstante, dos instrucciones no encajaban.

Mi código fuente llamaba a una función (sin parámetros ni valor de retorno) disponible en las librerías del compilador, la cual se compilaba en 5 instrucciones en código máquina. Estas instrucciones simplemente almacenaban un valor constante en dos registros de la RAM. No obstante, las direcciones de estos registros no eran las correctas. El compilador había generado código que almacenaba los valores en las posiciones 0×0F y 0×10, mientras que lo correcto eran 0×10 y 0×11 respectivamente. Es decir, las direcciones de las variables usadas estabandesplazadas una unidad hacia abajo.

Como estoy acostumbrado al funcionamiento del desarrollo de software libre, aunque este compilador fuese cerrado y comercial dediqué un buen rato a redactar un bug report en el que explicaba todo el problema y la solución. A los pocos días recibí la respuesta de la empresa, esperando al menos un agradecimiento por haber realizado su trabajo y una indicación de que estaría solucionado en la próxima versión. Para mi sorpresa, la única respuesta que obtuve fue una pregunta: “¿Cual es el número de serie de su producto?”.

Publicado en Otros | | No hay comentarios »

Desde principios de curso, en la Rama de Estudiantes del IEEE de la Universidad de Oviedo hemos estado organizando la segunda edición de nuestros conocidos talleres de robótica.

El año pasado, en su primera edición, diseñé un robot monolítico relativamente simple y durante 16 sesiones de 4-5 horas los 27 participantes fueron construyendo poco a poco su propio robot.

Debido al gran interés suscitado, este año hemos hecho dos grupos de 3 horas por semana cada grupo. Durante el primer cuatrimestre del curso (octubre-enero) los 46 participantes han asistido ya a 13 sesiones, pero esta vez en lugar de construir un robot monolítico han estado construyendo placas principales y módulos de Curuxa.

Durante estas 13 reuniones les hemos dado pequeñas explicaciones sobre electrónica, programación, y sobre cómo funcionan estos circuitos. En las primeras sesiones cada participante construyó y aprendió a programar la placa principal que estamos utilizando, MBP18. Una vez que tuvieron lista su placa principal dedicaron el resto del cuatrimestre a construir módulos simples para dar algunas funcionalidades a su robot. Por el momento ya han construido y programado varios pulsadores y bumpers, LEDs indicadores, un control de motores, un módulo con altavoz, y han tenido tiempo para aprender a controlar servomotores utilizando MBP18, además de material, herramientas e indicaciones sobre cómo construir los chasis de sus robots con aluminio.

En el sitio web de Curuxa la mayoría de módulos tienen disponibles versiones imprimibles en PDF. Estos archivos los preparé específicamente para poder imprimir múltiples copias y dar los esquemas en papel a los participantes de los talleres de robótica que no tuviesen ordenador portátil. Si algún otro grupo de estudiantes, profesor o quien sea se anima a organizar unos talleres de robótica o electrónica utilizando Curuxa, tiene a su disposición estas mismas versiones imprimibles para simplificar su trabajo. Ejemplos: [1], [2], [3], [4], [5], [6].

Además, los módulos que se pueden fabricar en placas de circuito impreso también tienen disponibles una versión imprimible del fotolito, lista para ser utilizada en la insoladora o en la plancha/plastificadora (según el método que se utilice para fabricar el PCB): ejemplo.

Algunos participantes de los talleres, en su tiempo libre, han diseñado y construido sus propios módulos siguiendo los estándares de Curuxa para añadir funcionalidades a sus circuitos. Algunos módulos que han hecho son, por ejemplo, un módulo que incluye 8 LEDs puestos en línea, una placa principal utilizando un PIC de 40 pines (MBP40 aún no la he publicado), un adaptador para conectar algunos módulos a las placas principales sin utilizar cables e incluso un módulo para conectar un LCD a la placa principal.

Estoy bastante contento con la acogida que los talleres han tenido, y los participantes (que la mayoría nunca habían construido ni programado nada por su cuenta) están construyendo un montón de circuitos, aprendiendo cómo funcionan, escribiendo sus propios programas, y a estas alturas ya están terminando el primer robot de su vida.

Además, junto a estos talleres, también estamos organizando pequeños concursos para que, utilizando los módulos de Curuxa que han construido durante los talleres, los conecten y programen de cierta forma para que realicen una tarea específica, de lo cual ya hablaré en otros post.

Fotos de los días que los participantes aprendieron a fabricar sus propios PCBs, para construir MC2A:

Publicado en Otros, Robótica | | No hay comentarios »

Desde hace años siempre me he interesado por el desarrollo orientado a aplicaciones educativas, de prototipado o para desarrolladores.

Hace dos años publiqué en mi sitio web personal picdub18, un circuito electrónico que incluye los componentes básicos y necesarios, comunes a casi todos los circuitos electrónicos basados en microcontroladores.

Picdub18 incluía un microcontrolador PIC16F716 (aunque podían utilizarse muchos otros modelos), un conector ICSP para programar el microcontrolador desde un ordenador fácilmente, un conector de alimentación, un botón de reset, un zócalo para poder sustituir el oscilador externo, y un conjunto de pines hembra útiles para conectar los pines de entrada y salida analógica y digital del PIC al resto de componentes electrónicos externos. La tarea se simplificaba en gran medida si el resto del circuito estaba montado en una placa de prototipos, ya que los mismos cables de hilo rígido de cobre que se utilizan para puentear los pines de la protoboard, también pueden utilizarse para conectar la protoboard con las hembras incluidas en picdub18.

Casi dos años después de haber desarrollado picdub18, la idea de una placa para desarrollo simple de prototipos electrónicos volvió a mi mente, y tras mucho darle vueltas y buscar la mejor forma de llevarlo a cabo, nació Curuxa.

En Curuxa, el equivalente a picdub18 serían las placas principales, y más específicamente MBP18. Las placas principales de Curuxa también incluyen solamente lo más básico necesario en cualquier circuito con microcontroladores, que es el propio microcontrolador, el conector de programación, y un conjunto de pines para poder conectar más fácilmente los circuitos externos. Estos conectores son un estándar propio de Curuxa, por lo que todas las placas principales contienen los mismos tipos.

Curuxa no sólo estandarizó y amplió el número de placas respecto a picdub18, sino que también ofrece módulos electrónicos diseñados para ser conectados a los pines mencionados.

Junto con esto, un conjunto de tutoriales, entorno de desarrollo, librerías y herramientas también se encuentran disponibles en el sitio web de Curuxa para que esta plataforma de hardware libre sea fácil de aprender a utilizar y al mismo tiempo se puedan construir multitud de aparatos distintos utilizando los módulos necesarios en casa una.

Publicado en Otros | | No hay comentarios »