Entradas de February, 2010

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?”.

Logotipo

Autor: Urriellu

En un post anterior ya hablé de qué significa Curuxa. Tras elegir el nombre para el proyecto vino el diseño del logotipo.

Ya que es bastante difícil representar gráficamente en qué consta el proyecto, me decanté por hacer referencia únicamente a su nombre, aunque la imagen resultase no tener nada que ver con los temas tratados, por lo que mi intención siempre fue que el logotipo de Curuxa fuese una lechuza.

Los logotipos pueden tener infinitas formas y colores. La solución que más me gustó fue un dibujo simple, vectorial, plano, a uno/dos colores y escalable. De esa manera no sólo podría utilizarse en el sitio web de Curuxa, sino también en lugares en los que dibujar es una tarea complicada, como por ejemplo placas de circuito impreso en las que tanto la serigrafía como los dibujos hechos con cobre están muy limitados. En este tipo de entornos normalmente no se puede utilizar más que un color y los dibujos deben tener una escala muy pequeña, pero el texto e imágenes deben poder distinguirse correctamente.

Las imágenes que se muestran a continuación están colocadas por orden cronológico, según se fueron haciendo modificaciones:

Logo v1 Logo v2
Logo v3 Logo v4
Logo v5 Logo v6

La primera versión nunca me gustó, principalmente porque más que una lechuza parecía una monja. Además si el fondo tiene un color parecido podría dar problemas, así que le añadí un recuadro alrededor.

Yo no soy un experto dibujante ni muchísimo menos, de hecho se puede ver que las dos primeras versiones son bastante mediocres. Así que le pedí ayuda a un amigo mío, Alfonso Zapico, al cual le agradezco mucho el trabajo que ha hecho tanto con este logo como sobre todo enseñándome a hacer fotos macro de calidad. Él es diseñador gráfico y dibujó la tercera, cuarta y quinta imagen basándose en mi diseño original y dándole un toque más profesional.

La última imagen es el logotipo definitivo, con algunos pequeños retoques que le hice y a un sólo color, lista para ser incrustada en el sitio web, en PCBs, o en cualquier parte.

Talleres de robótica

Autor: Urriellu

Talleres de RobóticaDesde 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 utilizaTalleres de Robóticando, 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 participantTalleres de Robóticaes 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:

Fabricando PCBs Fabricando PCBs
Fabricando PCBs Fabricando PCBs

Electrooculógrafo

Autor: Urriellu

Hace unas semanas en una asignatura de mi carrera me pidieron que diseñase cualquier dispositivo electrónico aplicado a la medicina. Después de muchas pruebas conseguí que funcionase una versión básica de electrooculógrafo construida sobre una placa de prototipos.

Para quien no lo sepa, un electrooculógrafo (EOG) es un dispositivo electrónico que mide la posición de los ojos mediante la diferencia de tensión producida por las contracciones de los músculos oculomotrices.

Una vez que supe que el circuito funcionaba era hora de construirlo. ¿Cómo lo hago? ¿Diseño un PCB desde cero? ¿Construyo todo el circuito sobre una placa perforada?

Pues no, evité tener que diseñar y construir todo el circuito desde cero para una sola aplicación utilizando una placa principal y varios módulos de Curuxa.

Para construir este electrooculógrafo utilicé MBP18 como “cerebro” del circuito para convertir las señales analógicas en digitales, filtrarlas digitalmente y generar la respuesta necesaria según la posición de los ojos. A esta placa iba conectado un pulsador (SISW-SPST) que, mientras el sujeto coloca los ojos en posición central, se mide la tensión en los electrodos colocados en su cara y utilizando un regulador de tipo P digital se calibra el EOG. También se utilizaron dos LEDs (LTIND-A) que se iluminan alternativamente según el sujeto esté mirando hacia la derecha o hacia la izquierda. Por último, a MBP18 también se conectó un altavoz (AO-SPK) que emite un sonido cuya frecuencia varía según la dirección en la que se esté mirando.

A parte de estos módulos, tuve que construir un pequeño módulo muy simple que incluye el amplificador de instrumentación AD620 para amplificar la señal de los electrodos colocados sobre la cara:

EOG_02 EOG_04

Aunque en principio este módulo no forma parte de Curuxa y lo diseñé exclusivamente para poder construir el EOG, sigue los mismos estándares que el resto del proyecto y puede resultar muy útil para multitud de aplicaciones, por lo que seguramente en el futuro se convierta en uno de los módulos oficiales de Curuxa.

Descargar su código fuente, listo para ser compilado con SDCC. El código hace referencia a las librerías de Curuxa.

Más fotos, esquemas, diagrama de flujo, y explicaciones de funcionamiento y construcción están disponibles en la página del electrooculógrafo.

El Precursor de Curuxa

Autor: Urriellu

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

picdub18Hace 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.