Lenguajes de alto nivel para microcontroladores

Últimamente estoy bastante interesado en la búsqueda de algún lenguaje funcional que me pueda servir para programar microcontroladores. En concreto investigo acerca de lenguajes funcionales que se puedan usar para programar las dos familias más populares de microcontroladores: los PIC y los Atmel AVR.

Hay muchas opiniones en internet sobre cuál de las dos familias es mejor que la otra. Después de leer varios post sobre este tema, mi conclusión es que ambas están muy parejas y que la elección tal vez dependa de nuevo de los gustos de cada cual. Aunque si me tuviera que decantar por alguno de los dos yo tiraría por los Atmel quizás porque últimamente son más populares que los PIC (con el apoyo de la comunidad que tiene detrás) y porque tienen algunas versiones que pueden funcionar con 0.7V de alimentación (para poder alimentarlos con una celda solar barata).

Como resultado de mi investigación (no muy fructífera) he encontrado algunos proyectos interesantes. Enumero a continuación no sólo lenguajes funcionales sino toda la variedad de lenguajes de alto nivel que he encontrado para programar microcontroladores (a parte del ensamblador del propio microcontrolador que no lo considero de alto nivel, aunque en él hay que programar las partes que requieren mayor rendimiento):

• OCaPIC (OCaml)
• PicoBIT (Scheme) - PIC
• Forth: (la opción más viable, porque al menos a priori puede caber fácilmente en un micro)
• avrforth 
• amforth (8 a 12 KB de flash, 80 bytes de EEPROM, y 200 bytes de RAM). El amforth es muy prometedor.
• rforth1: Un compilador de Forth para la familia 18Fxxx de microcontroladores PIC. Este mismo autor tiene también un Forth para la familia 16Fxxx de PICs.
• .NET Micro - Aunque no investigado mucho este, parece que es sobre dispositivos más grandes.
• uJ (Java) - PIC
• NanoVM (Java) - Atmel.
• B#: la "huella" en memoria es un poco grande (<24KB de flash y <2KB de RAM). Pero es un lenguaje de programación orientado a objetos específicamente diseñado para MCUs.
• PyMite (Python): Huella de memoria grande (64KB de flash, 4KB de RAM).
• eLua. Para MCUs muy grandes, me da la impresión.
• ¿Alguna opción más? Seguro. Dejádmelo en los comentario y la pongo ;)

En uno de los enlaces que refiero abajo también sugieren programarse un intérprete personalizado de "pcode" que interprete un conjunto de instrucciones que tú definas.

Esto último parece una idea interesante así como también suena bien eso de poder crearse una especificación de máquina virtual que pudiera correr sobre dispositivos como MCUs. Hay algunas ya, pero visto que la JVM de Oracle/Sun son unas 200 microinstrucciones en la capa de VM parece factible poder generar un estándar o conjunto de instrucciones que pudiera servir para dispositivos de recursos más limitados.

¿Existe ya ese estándar? Porque estos dispositivos tienen una serie de características hardware que se podrían abstraer para luego poder programarlos más fácilmente.

Por último, hace poco terminé de leer y entender (que son dos cosas distintas) el paper de investigación que propició la creación del lenguaje Lisp y toda la belle époque de la inteligencia artificial de los años 80 y 90. Se trata de un artículo del gran John McCarthy titulado "Recursive Functions of Symbolic Expressions and Their Computation by Machine" (¡del año 1960! y todavía hoy en día relevante, que se lo apunten algunas mentes pensantes de nuestra época).

A partir de este paper se pueden extraer las operaciones fundamentales que dieron lugar a las primeras implementaciones del lenguaje Lisp. Con este germen tan prometedor: ¿se podría definir una VM basada en estas operaciones sobre MCUs?

En resumen:
Aunque parezca contradictorio, el poder programar un microcontrolador (MCU) con un lenguaje de alto nivel diferente a C (y al ensamblador, que de por sí no se puede calificar de alto nivel) aunque pueda resultar una idea peregrina a mí al menos me resulta altamente interesante. Máxime cuando la tendencia es que haya cada vez más dispositivos "embebidos" / empotrados / móviles como son los que constituyen la "Internet de las cosas" (IoT ó Intenet of Things en inglés).

¿El futuro o el pasado? Dejo al lector elegir.

Enlaces:

• Embedded Systems - Atmel AVR: Un listado de lenguajes de programación para Atmel AVR.
• Alternative languages for embedded programming [Stack Overflow]
• What are the available interactive languages that run in tiny memory? [Stack Overflow]

EEVblog, blog sobre electrónica

En esta entrada simplemente os recomiendo un blog de electrónica que últimamente sigo mucho. Tiene una parte web con foros y un video-blog en Youtube, del que os pongo el enlace al canal más abajo.

Y como muestra un botón, la primera entrada al video-blog que hizo el hombre allá por el 2009 (no hace tanto tiempo):

EEVblog #1 – Rigol DS1052E Oscilloscope Reviewed

En este primer vídeo no tiene tantas energías como en los últimos vídeos. En estos 3 años al hombre le ha dado tiempo a "desmontar" decenas de aparatos delante de la cámara, revisar muchos productos, hacer diversos video-blogs sobre productos que está diseñando (con licencia Open Hardware), vídeos con tutoriales varios sobre electrónica, etc.

El canal del Youtube - http://youtube.com/user/EEVblog
El Blog en sí mismo - http://eevblog.com/, aquí hay enlaces a todos los vídeos.
Los foros del blog - http://eevblog.com/forum/

Reparación de pantallas LCD de cámaras digitales (y Parte 3)

El otro día terminamos de reparar la segunda cámara, marca Pentax. Fue un trabajo en equipo conjuntamente con mi padre. Al final encajaban todas las piezas y sólo nos sobró una chapa que causaba más problemas de los que solucionaba y decidimos no ponerla..

La parte más tricky fue usar partes del marco del antiguo LCD para que al colocarlo con la nueva pantalla encajase en el cuerpo de la cámara. También el hecho de conectar la pantalla mediante el bus y luego dejarla en su sitio no era algo trivial. Había que dejarla muy bien enganchada (mediante el clip del zócalo) y luego darle una serie de vueltas a la pantalla para conseguir que finalmente estuviese alineada. Lo conseguimos fijándonos en la pantalla antigua y haciendo un poco de ingeniería inversa.

No hay fotos en las que quede registro de la gesta. El único efecto colateral fue que la pantalla tiene una parte oscurecida, probablemente causada al hacer presión al intentar que se quedara en su posición mientras cerrábamos la carcasa.

"Hello World" en Arduino

Esta tarde soldé finalmente las patas a uno de mis Arduinos Nano v3.0 (o mejor habría que decir Chi-duinos). La operación ha sido delicada, pero con el estaño de 0.5 mm de grosor que me he adquirido ha sido satisfactoria. Al menos parece que todas las patas se han soldado bien.

Elementos para soldar las patas del Arduino Nano

En la foto podéis ver el estaño, un Arduino sin soldar, la fila de patas sin cortar, el soldador en medio, la protoboard con el montaje del ejemplo "Blink!" (que es el Hello World del Arduino) y el cable Mini-USB a USB.

Para soldar las patas más fácilmente conviene dejarlas pinchadas en la protoboard y soldarlas ahí.

Aquí tenéis el resultado final:

Blink Arduino Nano!!

Star Wars Uncut

Una película-remake realizada por aficionados. Cuenta con el beneplácito de George Lucas. La película "Star Wars: A new hope" (es decir, la primera de la saga clásica, el episodio 4) se dividió en trozos, de forma que cada aficionado eligió uno que luego filmó y envió para el montaje final, que es lo que se puede ver arriba.

Todavía no me lo he visto, me lo estoy bajando. Pero así a priori, aunque debe de ser un poco inconexo para aquellos que nos sabemos la peli de memoria tiene el atractivo de intentar reconocer todas las escenas de la peli. El cambio de personaje también debe de estar curioso. Además puede que sea una de las pocas películas que se ha filmado de forma distribuida, dando lugar a un nuevo género.

Reparación de pantallas LCD de cámaras digitales (Parte 2)

Me llegó la semana pasada la pantalla LCD de una de las cámaras digitales que estaban en proceso de reparación. En concreto la de la Nikon Coolpix S200. Esta tarde he procedido a la sustitución con éxito de la misma.

En el proceso de montaje, inverso al desmontaje, lo único que me ha costado más es fijar el bus del LCD a la placa mediante el conector. Es muy pequeño y difícil de manipular, pero con un poco de cuidado se puede conectar sin problemas.

Display LCD compatible con la Nikon Coolpix S200

Como vemos en la foto de la pantalla, el extremo marcado con un círculo rojo es el extremo del bus que hay que conectar a la circuitería de la cámara. En la parte de la cámara hay un pequeño zócalo con una pestaña que se abre, de forma que podemos colocar en su posición el extremo del bus antes de volver a cerrarlo (con unas pinzas o un pequeño destornillador). De esta forma la cámara se puede volver a cerrar y todo se queda (idealmente) como estaba, funcionando como si estuviera nueva.

Tengo que señalar sobre la pantalla que te llega desde China el hecho predecible de que no sea de la misma calidad que la original. Hay al menos 2 píxeles incorrectos que sobre cualquier fondo negro destacan en la nueva pantalla. En este tipo de pantallas es normal admitir algún pixel incorrecto, pero yo albergaba la esperanza que mi nueva pantalla fuera perfecta.

Como último paso, para que no nos vuelva a ocurrir, tenemos que comprar un estuche adecuado para trasportarla. Preferiblemente un estuche rígido y que nos frene un poco los golpes que pueda recibir la pantalla.

Me falta por montar la otra pantalla LCD de la Pentax. Pero eso será en otro post ;-)

To be continued...


Enlaces:

• Reparación de pantallas LCD de cámaras digitales (Parte 1)

¿Cuánto dura una batería de 300mAh conectada a un Arduino?

Se me plantea la pregunta de calcular cuánto duraría una batería de 300mAh conectada a un Arduino Nano v3.0.

La capacidad de una batería se mide en mAh. Esta cifra nos da la duración de la batería, mediante la siguiente fórmula:

Capacidad(mAh) = I(mA) x t(h)
t(h) = Capacidad(mAh) / I(mA)

En nuestro caso particularizamos para el dispositivo Arduino Nano. Sabemos que este dispositivo tiene un regulador de tensión cuya corriente máxima es de 500mA:

Capacidad = 300mAh = 300mA x 1h
I = 500 mA => t(h) = 300mAh/500mA = (3/5)h = (3x60)/5 = 36 min

Por completar la explicación, según las especificaciones, podemos alimentar al dispositivo mediante una fuente de tensión no regulada en el rango de 7—12V. En otro de los pines nos deja alimentarlo con una fuente regulada de 5V (por ejemplo esta tensión nos la podría dar una fuente de PC). El microprocesador irá más o menos rápido (varían los MHz) dependiendo de la tensión de alimentación, pero seguirá funcionando. En nuestro caso lo que se propone es conectar una batería de 9V al pin de alimentación no regulada.

Retomando la reflexión sobre la autonomía de la batería hemos visto que si conectamos una batería de 300mAh a un Arduino nos va proporcionar corriente como mínimo 36 minutos. Dependiendo de los componentes que conectemos al Arduino (sobre todo, de los componentes conectados a los puertos, que "chupan" 40mA como máximo cada uno) esta duración es mayor o menor.

Si conectamos otros componentes la corriente que tiene que soltar la fuente aumentaría y la autonomía disminuiría. Hay motores más eficientes y que consumen menos corriente que otros (por ejemplo, los que iban montados en los walkman). Tengo que hacer medidas, pero me da la impresión que un motor con su circuito driver puede llegar a consumir del orden de amperios. Con lo que la autonomía de todo el sistema cae sensiblemente. A parte de los motores, hay otros tipos de sensores que también consumen corriente (sensores de ultrasonidos, micrófonos, cámaras, sensores de temperatura, etc).

Nota 12/1/2012: Leo en algún foro de por ahí que también hay que tener en cuenta otros factores, como son el tipo de batería (Ni-Cd, Li-Ion, etc), las curvas de descarga en voltaje, las veces que se puede cargar y descargar la batería, etc. Es decir, que el tema de las baterías es un asunto peliagudo. También dicen que los mAh son aproximados pero no exactos.

Reparación de pantallas LCD de cámaras digitales (Parte 1)

Maldición, mi cámara no funciona

Una de las causas más comunes de que una cámara digital deje de funcionar es que su pantalla LCD se estropee. Normalmente es debido a un golpe o a alguna experiencia traumática (cambio de temperatura) que sufra durante su vida útil.

En la mayoría de los casos algo así puede acabar con la cámara en la basura ya que si vamos a las tiendas de fotografía los dependientes siempre nos dicen que comprar una pantalla nueva nos va a costar igual que la cámara.

En este post os voy a contar la otra alternativa que con algo de trabajo por nuestra parte podemos adoptar: intentar arreglar la cámara nosotros mismos. Os contaré mi experiencia en dos partes que esperemos que sea exitosa y logre sus objetivos.

Las protagonistas de la gesta

Esta experiencia se inicia hace unos 5 días, cuando leo en una web de descuentos que ofrecen una cámara digital a precio reducido. Se trata de una Agfa, que hace tiempo era más famosa por sus carretes que por otra cosa.

En el fondo de un cajón de mi casa tenía dos cámaras averiadas que por dejadez más que otra cosa no había intentado todavía reparar.

Las cámaras en cuestión son:

• Nikon Coolpix S200
• Pentax Optio S6

De estas dos cámaras la Pentax yo creo que es superior, aunque a la Nikon la tengo cariño porque lleva más tiempo conmigo.

Desmontaje

Armado con mi juego de destornilladores de relojero procedo a desarmar ambas dos cámaras con el pensamiento inicial de comprobar si es viable el cambio de pantalla. Por supuesto las memorias están extraídas y las baterías también, no vaya a ser que de produzca alguna derivación y metamos la pata.

He tenido suerte. Al menos en mis dos modelos es posible el reemplazo, ya que están conectados a la electrónica de la cámara con un bus que no está soldado. La Pentax además tiene conectado otro cable pequeño que sospecho es la alimentación de la pantalla. La Nikon tiene todo en el mismo bus.

Los tornillos hay que guardarlos a buen recaudo. Son minúsculos y si te despistas se te perderán y no volverás a poder cerrar la cámara tan bien como antes. Normalmente están estandarizados y no hay que quedarse con cuál va en dónde. Aunque no es mala idea apuntarlo en algún sitio.

Compra de repuestos

Con los dos únicos datos de las marcas y modelos de las cámaras busco en eBay un posible proveedor de repuestos. Mis búsqueda consiste en las palabras "nikon coolpix s200 lcd display". De forma análoga busco los repuestos de la Pentax.

Veo que un par de vendedores en China me proporcionan recambios. No soy muy optimista de que sean partes originales aunque según ellos sí. Nunca te fíes de un chino cuando te dice que algo es original. Sin embargo creo que pueden servirme para recuperar las cámaras. Además cuesta el repuesto de la Nikon $13.99 sin gastos de envío (unos 10,83€) y el de la Pentax $12.99 más $5 de gastos de envío (en total 13,93€). No se aproxima al precio de las cámaras, que es muy superior.

Con mi cuenta de PayPal (que recomiendan siempre usar cuando compras algo por eBay) realizo las compras. Dicen que tardarán unos 15-20 días (dependiento del proveedor, si lo paran en la aduana, etc) en llegar.

De momento estoy a la espera de que me lleguen los repuestos para seguir. Cuando lo hagan escribiré la "Parte 2" ;-)

To be continued...


Enlaces:

• Reparación de pantallas LCD de cámaras digitales (Parte 2)