Disparador remoto para cámaras Canon

Este artículo es una versión en castellano de una entrada previa del blog R6500. 

El artículo fue reseñado, en su dia en hackaday.

El objetivo del artículo es explicar el desarrollo de un disparador IR para ser utilizado en las cámaras reflex digitales Canon EOS. Debe imitar el funcionamiento del disparador remoto Canon RC-1 y se construirá alrededor de un microcontrolador MSP430G2553.

El dispositivo Canon RC-1 presenta dos opciones para disparar una cámara a distancia. Instantánea, justo cuando se recibe la señal y diferido dos segundos después de recibir la señal. De esta forma, si estás en la foto, tienes tiempo para ocultar el control remoto.Es posible encontrar clones del mando RC-1 con precios alrededor de 20 € en tiendas de fotografía locales, por lo que el objetivo de este desarrollo no es económico, sino para jugar con la miniaturización y las restricciones de energía en un diseño basado en microcontrolador.También lo usaré para agregar algunas características nuevas en el futuro ya que el sistema será reprogramable.Empecemos con lo básico.

Precedentes y especificaciones de señal

Desarrollar un clon RC-1 no es nada nuevo. He utilizado como referencia el trabajo EOS IR REMOTE en doc-diy.net. Este trabajo es bastante interesante para cualquiera que intente desarrollar un clon RC-1 ya que incluye la ingeniería inversa del control remoto RC-1 original. No me gusta mucho la conexión directa propuesta de un LED IR a los pines de salida de una MCU, pero no es de lo peor que he visto.A partir de esta referencia, obtuve las especificaciones de señal necesarias.Para enviar la señal de disparo, el control remoto RC-1 de Canon envía dos ráfagas de 16 impulsos. Las ráfagas tienen una frecuencia de aproximadamente 32700 Hz y se obtienen de un cristal de reloj (probablemente deberían ser 32768 Hz).La separación de dos ráfagas determina el funcionamiento del disparador.Si el inicio de ambas ráfagas se separa alrededor de 8ms (7.82ms) la toma se toma justo cuando se recibe la señal.Si la separación de la ráfaga es de aproximadamente 6 ms (5,86 ms), la toma se retrasa dos segundos después de recibir la señal.El protocolo de señal es bastante fácil de reproducir y eso simplifica el desarrollo de un clon RC-1.La referencia también indica que el control remoto RC-1 usa una señal de infrarrojos con una longitud de onda de 950 nm.

Selección de LED IR

El elemento principal en el disparador remoto es el LED infrarrojo que debe enviar las ráfagas de impulsos a la cámara. Para seleccionar un componente óptimo, necesitaríamos las características del receptor IR en las cámaras Canon EOS. Lamentablemente, no tengo esa información, pero se puede hacer una conjetura razonable de otros receptores IR que podemos encontrar en el mercado. He considerado un TSOP11 como ejemplo de un receptor IR típico (normalmente utilizado en receptores remotos IR).

Receptor IR TSOP11

El silicio es sensible a las longitudes de onda desde el infrarrojo cercano hasta el final del espectro visible. Los receptores IR generalmente incorporan un filtro IR que reduce la sensibilidad a las longitudes de onda visibles. De esa manera, la luz visible que brilla sobre el receptor no interfiere con la señal de IR recibida. En la siguiente figura, muestro la sensibilidad típica a la longitud de onda del silicio (a partir de un fotodiodo de silicio BPW33) junto con la sensibilidad de un receptor TSOP11 y el rango de longitud de onda visible. Como se puede ver, el filtro IR en el receptor elimina toda la sensibilidad a la luz de onda corta, incluido todo el rango visible.

Rango de longitudes de onda TSOP11

No podemos estar seguros de que las cámaras EOS tengan la misma sensibilidad que el TSOP11, pero es una suposición bastante razonable. El hecho de que el RC-1 use una longitud de onda de 950nm, justo en el centro de la curva TSOP11, nos da algo de confianza adicional.Conocer la sensibilidad del receptor es importante para seleccionar el LED del emisor IR para el proyecto, ya que no todos los LED IR se crean iguales.Por ejemplo, podemos verificar un LED TSUS5400 cuyas características se muestran a continuación:

La longitud de onda máxima está a 950 nm, justo en el centro del receptor TSOP11. Por lo tanto, será ideal para el proyecto. Pero la longitud de onda pico no es todo lo que necesitamos. También necesitamos potencia. Los LED TSUS tienen potencias entre 14 y 20 mW / sr. Es decir, 20 mW para cada estereorradian de ángulo sólido.En cada emisor radiante hay un compromiso entre el ángulo y la densidad de potencia. El ángulo radiante de los diodos TSUS es de +/- 22 grados. Como se puede mostrar en la siguiente curva:

Ángulo de emisión de los LED TSUS

Tener un gran ángulo extendido es bueno porque de esa manera no necesitamos apuntar exactamente en la dirección de la cámara, pero también es malo porque la energía total se extiende en un ángulo mayor por lo que incide menos energía en el receptor. Como siempre, no hay una solución que valga para todo y debemos optimizar. Podemos tener un buen alcance y una necesidad de apuntar bien o un mal alcance y requisitos de poca puntería. En este proyecto, consideré que 20mW / sr era bastante poco, así que revisé otras opciones de emisor IR.Finalmente reduje la selección a dos LED: TSHF5210 y TSAL6100. Ambos LED tienen el mismo ángulo de raciación de +/- 10 grados. Como puede ver en la siguiente figura, eso significa que necesitaremos una buena orientación para esos dispositivos.

Ángulo para los LEDs seleccionados

El rango de distancia será es mucho mejor porque esos LED tienen una densidad de potencia radiante bastante mayor:

Ambos cuentan con potencias radiantes de más de 100 mW / sr (mucho mejores que los LED TSUS) pero son diferentes en las longitudes de onda pico y en el tiempo de respuesta.Hay LED IR en el mercado con una mejor potencia radiante. El SFH4550, por ejemplo, presenta 400mW / sr a 100mA. Pero su ángulo de radiante es de solo +/3 grados, por lo que requerirá de mucha puntería para usarlo.Respecto al tiempo de respuesta, nos gustaría enviar ráfagas de señal 32768Hz. Eso significa un período de aproximadamente 30us. Un tiempo de respuesta de aproximadamente 1us en el TSAL6100 parece estar bien, pero el TSHF5210 es mejor.Respecto a la longitud de onda, el TSAL6100, a 940 nm, está muy cerca del valor máximo de 950 nm del RC-1 y del valor esperado del receptor IR. El proyecto donde obtuve las especificaciones RC-1 usó un LED SFH484 que tiene una longitud de onda máxima de 880nm, así que creo que los 890nm del TSHF5210 no podrían ser tan malos.Para analizar más a fondo la cuestión de la longitud de onda, podemos poner las respuestas del LED, obtenidas de sus hojas de datos, en la curva de sensibilidad esperada del receptor.

Comparación de longitud de onda LED

Como se puede ver, el diodo TSAL6100 está mejor posicionado en el centro del rango del receptor. Pero el TSHF5210 tiene un rendimiento mayor (180 mW / sr frente a 130 mW / sr). La mayor potencia radiante compensa en cierta medida la compensación de la longitud de onda. Como el TSHF5210 también es más rápido, seleccioné al final este diodo. De hecho, puedo cambiarlo en el futuro, así que no es gran cosa.

Diseño de circuito

El circuito para controlar el LED IR está construido alrededor de un microcontrolador MSP430G2553 en encapsulado DIP20. Esta MCU, como se muestra en la siguiente figura, presenta 16KB Flash, 512B RAM, dos puertos de 8 bits (el tercero no está disponible en encapsulado DIP) y varios periféricos. Puede ser excesivo para este proyecto, pero, por el costo adicional respecto de las MCU menos complejos de la familia MSP430G, no es necesario optimizar el tamaño del programa y se pueden agregar varias características en el futuro sin necesidad de cambiar de MCU.

Características MSP430G2553

Alrededor del MCU hay varios componentes, como podemos ver en el esquema a continuación.

Esquema circuital

El LED IR es atacado por un transistor bipolar BC547 en la configuración del seguidor del emisor (colector común). Esta configuración no requiere una resistencia de base como la configuración  emisor común y es más rápida porque el transistor nunca entra en la región de saturación. Sin embargo, esto tiene un precio, ya que la tensión de salida se reduce aproximadamente 0,5 V con respecto a la configuración del emisor común. En esta aplicación, esto no es problema porque solo necesitamos un máximo de 1.6V para atacar el LED a 100mA como podemos ver en su hoja de datos:

Datos TSHF5210

Podemos ver que la corriente directa máxima es de 100 mA. En nuestra aplicación, enviamos una ráfaga de 16 pulsos a 32768Hz. Eso le da una duración total de 488us que es más que el pico permitido de la corriente de 100us en la hoja de datos. Así que mantendremos la corriente a aproximadamente a 100mA.La configuración del emisor seguidor necesita una resistencia en serie con el LED que se puede calcular:Rseries = (Vport - Vled - Vbe) / IledDónde:
  Vport: Es el voltaje de salida en un puerto de microcontrolador (3V)
  Vled: Es el máximo voltaje del LED en directa Vf (1,6V)
  Vbe: Es la tensión emisor-base del transistor (0,7V)
  Iled: Es la corriente deseada para el LED

Ello da un valor de 7 Ohm para la resistencia. Seleccionaremos un valor de 6,8 Ohmios ya que es un valor de resistencia normalizado similar.En la práctica, la resistencia de salida de la batería, especialmente cuando envejece, también puede limitar la corriente, por lo que es fácil que la corriente caiga por debajo de 100 mA en la práctica usando la resistencia elegida.En el circuito, el transistor se puede controlar con dos puertos de salida: P1.4 y P2.1. Hemos seleccionado ambas salidas porque de esa manera podemos seleccionar tres formas diferentes de atacar el LED:

•     Usando la operación GPIO normal con P1.4 o P2.1
•     Usar la salida SMCLK con P1.4
•     Usando la línea TA1.0 del temporizador 1 en P2.1

En el primer firmware de prueba del sistema, he usado operaciones normales de GPIO, pero en el futuro planeo probar otras opciones y, conectar la base a P1.4 y P2.1, deja las opciones solo en el lado del software.

MSP430G2553 en encapsulado de 20 pines

El circuito incluye un diodo LED rojo normal de 3 mm conectado a P1.0. Ese LED se encenderá cuando se envíe la señal de disparo y también se usará para cualquier otra interacción del usuario.Hay dos botones conectados a P1.3 y P1.5. Un botón dará un disparador instantáneo de la cámara y el otro dará la operación retardada de dos segundos.Dos condensadores de 10uF y 100nF proporcionan el filtrado de suministro necesario.El circuito también incluye un cristal de reloj de 32768 Hz 12pF y dos resistencias de 22k conectadas a P1.6 y P1.7. Ambos elementos son opcionales ya que el sistema puede funcionar sin ellos. De hecho, el primer firmware desarrollado no los usa. El cristal del reloj está incluido para proporcionar una mejor estabilidad de frecuencia que el oscilador DCO interno, si es necesario, y las dos resistencias están incluidas para usar el ADC del MCU para medir el voltaje de alimentación y dar una indicación de una situación de batería baja.Finalmente hay un conector ISP de 6 pines. Esta conexión, junto con la resistencia de 47k y el condensador de 1nF, permite programar el sistema mediante un cable específico que utiliza las señales TDIO y TCK. El pin 1 se elimina del conector para indicar su orientación correcta. El pin 6 está conectado a la batería CR2032 que alimenta el sistema. De esa forma podemos alimentar el sistema cortocircuitando los pines 5 y 6 usando un puente. El circuito no incluye un interruptor de encendido porque puede apagarse eliminando el puente y porque planeo usar los modos de muy baja potencia de la MCU en el firmware final para que no sea necesario apagar el sistema.

Prototipo en breadboard

Para probar el sistema, los elementos del circuito principal se colocaron en una placa de prueba sin soldadura. Para programar el MCU, se utilizó un Launchpad MSP430. Podría usar mi Launchpad FET construido anteriormente, pero estaba en uso en otro proyecto más importante. Se utilizó un Analog Discovery para medir los tiempos.

El primer firmware para el proyecto fue desarrollado en Energia, un entorno de desarrollo similar a Arduino para la familia MSP430. Los tiempos para la señal IR se ajustaron manualmente usando el osciloscopio Analog Discovery. Puede encontrar el código en esta referencia de Google Drive. Energia proporciona una manera rápida y sucia de desarrollar el firmware. El futuro firmware del sistema se desarrollará bajo MSP GCC, pero con el fin de verificar el funcionamiento del sistema, Energia está bien.ACTUALIZACIÓN: hay un nuevo firmware desarrollado con GCC. Ver más información al final de este artículo.

Implementación de circuito

El circuito final se implementa en una placa de soldadura de 100 mil de paso. El primer paso fue reunir todos los componentes para verificar el espacio necesario.

Componentes del proyecto (falta C de 1nF)

La siguiente figura muestra la distribución de los componentes sobre la placa. De esa manera se verifica el espacio necesario para poder cortarla placa al tamaño necesario.

Distribución de componentes

Después de cortar la placa a la medida adecuada, los componentes se soldaron y todas las conexiones se hicieron una por una. El enrutamiento se realizó sobre la marcha sin planificación previa, por lo que anoté todas las conexiones según se hacían para verificar no dejar ninguna.

Dibujo de enrutamiento de la placa

La siguiente figura muestra el lado superior del circuito soldado final. El condensador de 100uF, el LED IR y el cristal del reloj se bloquearon en su lugar con cables de metal soldados.

Lado superior de la placa

Para minimizar el espacio utilizado, el soporte de la batería se soldó en el lado inferior de la placa después de que todos los demás componentes se enrutaron

Lado inferior de la placa

El LED IR necesitaba algo de espuma para garantizar que estuviese correctamente alineada con la placa. Como el ángulo radiante es de solo +/- 10 grados, es importante hacerlo bien.

Alineación LED IR

Como se explicó anteriormente, el conector del ISP funciona como el interruptor de encendido. Como el primer firmware, desarrollado en Energia, no fue lo suficientemente eficiente, el jumper debe colocarse en posición de apagado cuando no está en uso. El próximo firmware, que se desarrollará con MSP GCC utilizará los modos de baja potencia de la MCU para que el jumper no tenga que colocarse en la posición OFF después de cada uso.

Jumper en el conector ISP

Por ahora, el sistema funciona bien para distancias de hasta 5 m. Suficiente para mis necesidades de un disparador IR de cámara.

Próximos pasos

El sistema, tal como está ahora si es completamente funcional. Sin embargo, planeo hacer algunas mejoras en el futuro:

•     Desarrollar el firmware utilizando el Eclipse MSP GCC toolchain
•     Implementar  el modo de bajo consumo MSP430
•     Utilizar el cristal 32768Hz para proporcionar un timing más robusto
•     Implementar la indicación de batería baja usando las resistencias conectadas a P1.6 y P1.7
  

 

Nuevo Firware (actualización el 26/11/2014)

He escrito un nuevo firmware para el Disparador IR. Puedes encontrarlo en el siguiente enlace:

http://r6500.blogspot.com.es/2014/11/new-firmware-for-ir-trigger.html

Se desarrolla utilizando un entorno portátil MSP430GCC que describo en esta otra referencia:

http://aim65.blogspot.com.es/2012/03/desarrollo-portable-con-launchpad.html

El nuevo firmware usa el cristal de 32768 Hz por lo que brinda una sincronización más estable en la señal generada. También mejora en gran medida la corriente inactiva que pasa de 3.2mA a 0.1uA.

Codigo en Github (11/02/2018)

El código está ahora disponible en Github, tanto para la primera versión desarrollada en Energia como la segunda versión en MSP430-GCC:

https://github.com/R6500/Canon-IR-trigger
 
 

Recuperando el Blog

Han pasado unos cuantos años desde la última entrada en este blog.
El motivo ha sido que me he dedicado más al blog en ingles R6500.

Aún así llevo un cierto tiempo que tampoco escribo en ese blog. Ya se sabe el dicho: "Tantas cosas que hacer y tan poco tiempo!"

Hoy me he levantado con buen pie y he pensado en recuperar este blog e intentar mantener los dos blogs AIM65, en castellano, y R6500, en inglés, de manera paralela. Veremos si tengo el tiempo para mantenerlos a la vez.

Para recuperar el tiempo perdido, añadiré en este blog algunas de las entradas que considero más interesantes del blog hermano en inglés.

La Familia Crece

Ha pasado un poco de tiempo desde mi última entrada en el blog. Digamos que ha sido un año un tanto complicado. Pero el blog no ha muerto, seguimos con él.

Hace ya un tiempo escribí una entrada sobre la familia discovery. En esta entrada quiero hablar sobre los últimos miembros de la familia: STM32F3 Discovery y STM32F0 Discovery

STM32F3 Discovery

La placa STM32F3 Discovery es, dentro de la familia, una de las placas mejor especificadas en cuanto a periféricos incluidos. El corazón de esta placa es un procesador STM32F303VCT6 de tipo ARM Cortex M3 igual que en la placa STM32F4 Discovery. En este caso, sin embargo, aun siendo también M4, el procesador es más modesto, disponiendo de 256 KB de Flash y 48 KB de SRAM y trabajando a 72 MHz.

STM32 F3 Discovery

Lo que destaca de esta placa, como he comentado antes, son los periféricos incluidos:

• 8 Leds de usuario distribuidos en un círculo
• MEMS LSM303DLHC que incorpora un acelerómetro y un magnetómetro ambos 3D que se comunica con el MCU usando un puerto I2C
• MEMS L3GD20 que proporciona un giróscopo de 3 ejes que se comunica con el MCU con un puerto SPI

Por un precio aproximado de 14 € + IVA es una de las alternativas más baratas para crear un sistema de control completo debido a que mide un total de 9 grados de libertad (3 de aceleración, 3 de giro y 3 de dirección absoluta con la brújula 3D).

STM32F0 Discovery

La placa STM32F0 Discovery es el hermano pequeño de la familia STM32 Discovery. Incorpora un procesador STM32F051R8T6 que pertenece a la categoria ARM Cortex M0. El procesador incorpora 64 KB de memoria Flash y 8 KB de memoria SRAM.

STM32F0 Discovery

En cuanto a periféricos, se trata de una placa modesta. Incorpora sólo 2 leds de usuario y un pulsador. También se ha de de decir que es el miembro más barato de la familia discovery de 32 bits costando menos de 9 € (Sin incluir el IVA). Junto a la placa, como se aprecia en la figura, se proporciona una placa de topos para soldar componentes.

Puestos a elegir veo más interante la placa STM32 VL Discovery, que por un par de euros más posee un procesador ARM Cortex M3, la misma cantidad de memoria SRAM y el doble de memoria Flash. Además cuenta con un cristal de cuarzo de 32kHz muy útil para desarrollar sistemas en tiempo real.

Digamos que la placa STM32F0 es interesante pero no impresiona.

Energia: Un MiniArduino por 4 Euros

Como ya es bien sabido por toda la comunidad que trabaja con proyectos sencillos basados en microcontrolador, Arduino es una plataforma que permite acercarse de manera muy sencilla al mundo de los microcontroladores sin saber prácticamente nada de electrónica. El precio del Arduino más sencillo es de 20 Euros para el Arduino UNO. Bastante barato. Uno se puede comprar el procesador Atmega con el bootloader de Arduino por unos 6 Euros y montarse la placa si va justo de dinero. Parece que es el precio mínimo de desarrollo para no iniciados en microcontroladores, ¿no?

¡Pues NO!  La gente del proyecto Energía ha reventado el precio de los proyectos sencillos desarrollando un entorno tipo Arduino para el Launchpad de Texas Instruments. El software y las instrucciones de uso del proyecto Energía las teneis aquí:

https://github.com/energia/Energia/wiki/Getting-Started

Las instrucciones son muy fáciles de seguir y, una vez arrancado el programa, lo único que se ha de configurar es el puerto en el que se halla conectado el Launchpad y el modelo de microcontrolador que lleva.

Como ejemplo os muestro un programa que he desarrollado en unos minutos a partir del típico ejemplo Blink que hace parpadear un led. Mi modificación hace parpadear dos leds en lugar de uno. No es gran cosa pero demuestra lo fácil que es hacer un programa. Nada que extrañe a alguien que haya usado Arduino.

Sketch Blink2 que hace parpadear dos leds

Escribiendo el Sketch y pulsando el segundo botón desde la izquierda (Upload) el programa se compila y se carga en el launchpad si está conectado al cable USB. En un momento tenemos dos leds parpadeando a distinto ritmo.

Para poder desarrollar programas es necesario conocer la correspondencia entre los pines del microcontrolador identificados como P1.0 a P1.7 y P2.0 a P2.5 (en microcontroladores de 20 pines) y los números de pin que usa el entorno que van del 2 al 15. En realidad el Launchpad puede usar los pines P2.6 y P2.7 si no usa cristal de cuarzo, pero, por lo que veo, esta opción no está actualmente implementada en Energía. En todo caso, la correspondencia de pines está en el fichero pins_energia.h que se halla en el subdirectorio:

hardware\msp430\variants\launchpad

dentro del directorio de instalación de Energía. En todo caso, para simplificar, la correspondencia es esta:

P1_0 = 2;     // LED 1 Rojo (Activo alto)
P1_1 = 3;
P1_2 = 4;
P1_3 = 5;    // Pulsador S2 (Activo bajo)
P1_4 = 6;
P1_5 = 7;
P2_0 = 8;
P2_1 = 9;
P2_2 = 10;
P2_3 = 11;
P2_4 = 12;
P2_5 = 13;
P1_6 = 14;   // LED 2 Verde (Activo alto)
P1_7 = 15;

Con esto y, con un poco de dedicación, cualquiera puede desarrollar proyectos sencillos con microcontrolador por lo que vale un bocadillo.

La infame versión Z

En diseño de circuitos uno espera que los componentes se comporten siempre de la misma manera, que cuando compras un recambio de un componente por otro que tiene exactamente el mismo nombre, el funcionamiento sea el mismo. Lamentablemente eso no siempre es así, y en ocasiones, el fabricante no se toma muchas molestias en avisarlo.

Explicaré un caso concreto con la placa STM32F4 Discovery. La mejor y más potente placa de la familia Discovery.

Placa STM32F4 Discovery

El problema

Hace ya un tiempo compré una placa de éstas y empecé a trabajar en el software. El entorno de trabajo, algún dia hablaré del él, está basado en Eclipse y usa compiladores GCC. Hasta el momento he probado con Code Sourcery y Yagarto. Para depurar empleo el servidor GDB que veía con la versión gratuita de Atollic True Studio for STM32.

Como todo iba bién con la placa compré una placa nueva, igualita a a la otra que ya tenía. Mi sorpresa fué que el debugger se colgaba al intentar comunicarse con el microcontrolador.
Para descartar que fuera una placa defectuosa intenté programar en la placa usando el software STLink Utility que proporciona gratuitamente ST para programar sus microcontroladores.

Nada más arrancar ya se veía que algo iba mal.

Aplicación STLink Utility

El software era capaz de comunicar con el microcontrolador, pero no era capaz de averiguar de que micro se trata tal como se desprende de la frase "Unknown Device" arriba a la derecha de la pantalla. Fijémonos, luego diré porqué, en la identificación de la CPU que es 0x413

Al intentar programar el dispositivo las cosas se complican.

Es extraño, nunca habia visto este mensaje, le digo que adelante.

El programa es incapaz de programar el micro. Por lo visto está activada la protección que deshabitlita el bus JTAG para que no pueda extraerse el código del micro. Es extraño porque la placa es nueva.
La protección se configura con los llamados option bytes. Voy a la ventana pertinente y sale algo como ésto:

Parece que la protección de lectura está activada y la flash está protegida contra escritura. No se puede programar el micro y no se puede quitar la protección. No se puede usar el micro para nada que no sea usar el software de demostración que ya venía en la placa.

¡¡ Y la placa era nueva !!

La solución

Después de mucho buscar por internet a alguien que le hubiera pasado algo similar encontré esta referencia.

Por lo visto la gente tenía problemas con la versión "Z" de la CPU. Las placas STM32F4 Discovery, por lo visto, llevaban antes CPUs de versión "A". El último batch de placas usa CPUs de versión "Z".

La siguiente figura muestra una CPU de versión A.

STM32F407 Version A

A continuación se muestra una CPU de versión Z.

STM32F407 VersionZ

Parece ser que en el paso de la versión A  a la versión Z, la identificación de la CPU ha pasado de 0x411 a 0x413. A continuación se muestra el programa STLink Utility conectado a una CPU de versión "A" donde se vé como se identifica como 0x411 a diferencia de la identificación 0x413 de la versión "Z".

STLink Utility con STM32F4 versión "A"

 

Misterio solucionado. Pero en esta historia hay algunos puntos muy molestos:

• Que ST envie placas STM32F4 Discovery incompatibles con versiones anteriores del software sin avisar de los posibles problemas de compatibilidad.

• Que ST no actualice la aplicación STLink cuando cambia los MCUs que soporta.

• Que la aplicación STLink no sea capaz de decir que no sabe como trabajar con el micro en lugar de hacernos creer que se ha habilitado la protección contra escritura.

Suerte que en la misma referencia que cité anteriormente se proporcionaba el link a una versión parcheada de STLink Utility para poder programar la placa.

Como información adicional de los cambios de la versión "A" a la versión "Z", parece que no hay más versiones intermedias. Éstos están documentados en el la Errata Sheet del microcontrolador. Lo que no se dice en este documento es la incompatibilidad que produce con las propias aplicaciones de ST.

Finalmente me alegra decir que la versión actual del servidor GDB de ATollic True Studio es capaz también de comunicarse con la CPU "Z" maldita.

Calibrando el DCO

En este artículo explicaré por encima el funcionamiento del oscilador controlado digitalmente DCO de la familia MSP430 y explicaré un procedimiento, software incluido, para calibrar este oscilador para un conjunto de frecuencias elegido.

Para empezar, hablaremos del DCO...

Descripción del DCO

Los microcontroladores MSP430 de Texas Instruments, por ejemplo los compatibles con la placa Launchpad, disponen de un oscilador RC interno controlado digitalmente (DCO). El DCO se controla con 3 valores digitales:

• RSELx  (0..15) Selecciona un rango de frecuencia de funcionamiento
• DCOx   (0..7)   Selección fina de frecuencia dentro del rango elegido
• MODx  (0..31) Modulación de frecuencia entre DCO elegido y el siguiente DCO+1

Los valores RSELx y DCOx, por tanto seleccionan la frecuencia del oscilador interno tal y como se muestra en la siguiente figura de la familia MSP430x2xx (slau144i).

Frecuencia vs RSEL,DCO

Se ha de tener en cuenta que los rangos que cubren los distintos valores de RSEL se pueden solapar entre si, por tanto, es posible que RSEL=7 DCO=7 de una frecuencia mayor que RSEL=8 DCO=0.

El valor de MODx permite un ajuste más fino de la frecuencia media del oscilador. Básicamente, cada 32 ciclos, (32-MOD) ciclos se harán con la frecuencia DCO y MOD ciclos se harán con la frecuencia DCO+1. Para que esto funcione el valor de DCO elegido ha de ser inferior a 7 ya que no existe DCO+1 cuando DCO=7. Ls siguiente figura muestra el patrón de modulación para distintos valores de MOD.

Modulación del oscilador DCO

Es importante notar que el uso de la modulación introduce Jitter en la señal de reloj. Eso puede ser o no importante para una aplicación concreta pero es importante tenerlo en cuenta si necesitamos instantes de captura completamente periódicos.

  

Calibración del DCO en producción

El problema general es que las relaciones entre RSEL y DCO y la frecuencia generada tienen una tolerancia muy elevada por lo que para tener frecuencias de operación mínimamente exactas es necesario calibrar el oscilador. A modo de ejemplo, para la familia MSP430G2x21 (slas694i) con RSELx = 7, DCOx = 3 y MODx = 0 que es el valor con el que arranca el microcontrolador, pueden dar valores de frecuencia entre 0,8 y 1,5 MHz. Esto es, el error puede ser de 0,35MHz (un 23%) respecto de un valor central de 1,15MHz.

Calibrar el oscilador es determinar que valores de RSEL, DCO y MOD se han de programar para generar una determinada frecuencia. Aún usando valores calibrados el oscilador tiene una cierta tolerancia que puede ser de hasta +/- 6% para todo el rango de temperaturas y tensiones de alimentación, pero, aun así, es mucha menos tolerancia que un DCO no calibrado. Sin embargo, si calibramos el oscilador cuando el circuito opera a la tensión y temperatura de operación, la deriva será mucho menor.

Todos los microcontroladores de la familia MSP430 se calibran en el momento de producirlos, al menos a la frecuencia de 1MHz. Los valores de RSEL, DCO, y MOD que han de programarse en los registros  DCOCTL (DCO y MOD) y BCSCTL1 (RSEL) se guardan en la memoria flash del microcontrolador.

Usar los valores calibrados en factoría está bien, pero tiene algunos inconvenientes:

• Sólo podemos usar las frecuencias elegidas por Texas Instruments para nuestro microcontrolador. El MSPG2211 sólo tiene la de 1MHz, el MSPG2553 tiene lass de 1, 8, 12 y 16MHz. Si nos interesa una calibración a 4MHz, mala suerte.

• Texas Instruments realiza sus calibraciones a 30ºC y 3V. Si nuestro sistema ha de operar lejos de estos valores la calibración no será buena.

Para solventar estos problemas podemos hacer la calibración nosotros mismos.

Calibración de usuario del DCO

Para realizar la calibración debemos de contrastar la frecuencia que genera el DCO con una referencia más exacta. Podemos entonces variar los valores de RSEL, DCO y MOD para lograr la frecuencia deseada.
Un buen patrón para realizar la calibración es el oscilador de cristal externo de 32768 Hz. Hay varios motivos para ello:

• Un cristal de este tipo puede tener una precisión de 10 a 20ppm
• Todos los microcontroladores de la serie MSP430 pueden usar un oscilador externo de 32768Hz
• El Launchpad viene con un un cristal de este tipo, aunque sin soldar. En otro artículo hablo de como instalar un cristal de 32768Hz de manera temporal o permanente en el launchpad.

Buscando en internet se ve que hay varias personas que ya han llegado a esta conclusión como se demuestra aqui y aqui. Incluso existe una libreria de Texas Instruments al respecto.

En general, la mayor parte de soluciones reescriben la Sección A de Information Area de la flash del micrcontrolador que es donde Texas Instruments guarda la información de calibración del oscilador y otros elementos durante la producción. Es por eso que este área está especialmente protegida por un flag de seguridad (LOCKA).

Reescribir este área es potencialmente peligroso porque podemos perder información de calibración importante de otros elementos como el ADC y porque este área está protegida por un checksum que algunas aplicación podrían revisar. Es cierto que se puede recalcular el checksum, pero, igualmente corremos riesgos de borrar información importante.

 Los microcontroladores MSP430 tienen 3 áreas más de información (B,C,D) en la flash, todas ellas de 64 bytes igual que el área A, pero, a diferencia del área A, están vacían en los microcontoladores que salen de la factoría de Texas Instruments. En mi caso he pensado que sería mejor guardar la nueva información de calibración en la Sección B y no tocar la sección A para nada.

Dentro de esta área guardaré 9 valores de calibración para las frecuencias de 500Hz, 1MHz, 2MHz, 4MHz, 6MHz, 8MHz, 10MHz, 12MHz y 16MHz. La posición donde guardaré los valores de calibración las he incluido en un fichero NewDCOCal.h para tener una mejor referencia de sus posiciones. Si hace falta, se pueden cambiar o añadir nuevos valores de calibración si hace falta.


Programa de Calibración

Para realizar la calibración he realizado un programa DCO Calibration. Este program depende, a parte de NewDCOCal.h, del fichero io430masks.h. El programa se ha compilado con el compilador MSPGCC bajo Eclipse y, optimizado en tamaño, cabe en cualquier microcontrolador con al menos 2kB de flash.

El programa está pensado para hacerse correr en la placa Launchpad, por ello se emplean los siguientes pines:

         Xin/Xout : Cristal de 32768Hz

         P1.0 : Led Verde

         P1.3 : Pulsador a tierra

         P1.6 : Led Rojo

Adicionalmente se emplean dos pines para verificar los osciladores:

         P1.4 : Salida de cuadrada a la frecuencia del DCO

         P1.5 : Salida de 256Hz generada por el oscilador de 32768Hz

  

 Cuando el programa arranca, verifica si hay información en la sección de información B. Si hay información, pasa al modo de generación de frecuencia descrito más delante. Si no hay datos, se realiza la calibración, se guarda en la sección de información B de la flash y se pasa al modo de generación de frecuencia.

Durante la calibración el pin P1.4 muestra la frecuencia actualmente generada. Cada vez que se pasa a calibrar una nueva frecuencia, el led verde parpadea una vez. Si la calibración de una frecuencia se ha de repetir por no cumplir con la tolerancia deseada, parpadean los dos leds rojo y verde. 

En modo de generación de frecuencia el sistema programa la primera frecuencia de la lista de frecuencias calibradas (500kHz). Cada vez que se pulsa el pulsador que se halla en P1.3 se salta a la siguiente frecuencia de la lista para pasarse otra vez a la primera (500kHz) después de la última (16MHz). En este modo P1.4 tiene la frecuencia generada y el led verde parpadea a la frecuencia generada dividida por 20*65536 (20 desbordamientos del Timer A0).

En caso de error, el programa se bloquea mostrando un código de error mediante un número de parpadeos:

       (1)  Fallo del oscilador de 32768 Hz

       (2)  Problemas al calibrar una frecuencia

       (4)  No existe calibración de fábrica para 1MHz (necesaria para programar la flash)

       (5)  No puede lograrse la cota de error deseada (por defecto menos del 5%) 

       (Led Continuo) Problemas al arrancar el oscilador de 32768 Hz

Funcionamiento del programa

Para calibrar el oscilador el Watchdog se programa en modo temporizador con un período de unos 1,9ms (64/32768Hz) usando el oscilador de cuarzo. El timer A0 se configura en modo contínuo con el DCO como entrada. Se genera una captura del timer A0 cada vez que se da la interrupción del Watchdog. Calculando el número de ciclos del DCO entre dos capturas podemos inferir la frecuencia del DCO.

                    Frecuencia DCO = 512 * Ciclos entre capturas

Para aumentar la precisión, se promedia el intervalo de 50 capturas.

El programa comienza eligiendo el valor de RSEL, a continuación se elige el valor de DCO que se halla justo por debajo de la frecuencia deseada. Finalmente se ajusta la modulación MOD entre esta frecuencia de DCO y la siguiente.

Compilación condicional

El programa contiene 3 defines que permiten compilación condicional.

Si se activa el define DEBUG, el programa guarda los valores de RSEL, DCO y MOD junto con el error de calibración en cada frecuencia. De esta manera se puede verificar con el debugger.

Si se activa el define FLASH_OVERRIDE el programa reescribirá la información de la Sección B aunque no se halle vacía.

Si se activa el define TEST_MODE, toda la calibración se realizará en RAM para verificar el funcionamientod e la calibración sin tocar la memoria flash.

Video del funcionamiento

A continuación se muestra un video del funcionamiento del sistema de calibración en un Launchpad version 1.5 con el procesador MSP430G2553 que lleva por defecto. Junto al Launchpad tenemos un osciloscopio que muestra la frecuencia generada y un multimetro que trabaja como frecuencímetro.

Codigo en Github (11/02/2018)

El código está ahora disponible en Github:

https://github.com/R6500/MSP430-DCO-Calibration

Instalación del Cristal en el Launchpad

 En este artículo hablaré de la instalación del cristal de cuarzo de 32768Hz en el Launchpad.  Un cristal de 32768Hz es fundamental para disponer de un reloj de tiempo real. En efecto 2^15 ciclos de este oscilador corresponden a un segundo. En el caso de la familia MSP430, en concreto, podemos usar el Watchdog en modo timer para generar una interrupción exactamente cada segundo usando como base este cristal de cuarzo.

Launchpad y bolsa con el cristal

 Este cristal de cuarzo viene incluido en la caja del Launchpad, pero no se halla soldado en la placa. El motivo por el que no viene soldado es porque el cuarzo ocupa 2 pines del microcontrolador que podrían ser usado como líneas de I/O. Dependiendo de la aplicación, por tanto, nos puede interesar no soldar este cristal para poder disponer de estas líneas. 

 En la siguiente figura se muestra la localización del cristal de cuarzo.

Localización del cristal

 El problema a la hora de poner el cristal es que el que se proporciona con el Launchpad es muy pequeño y cuesta de soldar. Para hacer las cosas más fáciles lo mejor es sujetar el cristal en su sitio con cinta adhesiva. Se ha de andar con ojo porque el cristal tiene delante y detrás. En la posición correcta los dos pines deben quedan apoyados sobre los pads de soldadura.

Cristal sujeto con cinta adhesiva

Para soldar el cristal conviene tener una lupa y un soldador de punta fina, pero con paciencia al final queda bien soldado. Si se cortocircuitan los pads, se retira el estaño con cinta de desoldar y vuelta a empezar.

Cristal soldado

Una vez soldados los dos terminales del cristal, podemos retirar la cinta adhesiva con cuidado de no arrancar el cristal y, a continuación, soldamos el cuerpo del cristal en el pad que tiene debajo.

Soldadura del cuerpo del cristal

Una vez soldado el cristal, se debe probar que funciona correctamente. Para ello he realizado un programa de test bajo Eclipse basado en dos ficheros main.c y io430masks.h.

El programa intenta poner en marcha el reloj basado en el cristal externo de 32768Hz. Si funciona correctamente, el led verde parpadea cambiando cada segundo. Si el oscilador falla, se enciende el led rojo.

Solución a problemas

Si el oscilador no funciona, lo primero es revisar las soldaduras.

El oscilador es muy sensible a cualquier interferencia. Los pines del oscilador, dado que pueden ser usados como I/O, están conectados a los pines de salida de la placa Launchpad. Para minimizar las interferencias se puede desconectar el oscilador de estos pines retirando las dos resistencais de cero ohmios que unen el oscilador con los pines. En la siguiente figura se muestra la localización de estas resistencias. Esta figura se puede comparar con la anterior que aún tenía las resistencias soldadas.

Resistencias eliminadas

Alternativa al la soldadura

Finalmente, para la gente a la que esta soldadura le resulte muy complicada o, para quienes no quieran sacrificar de manera permanente los dos pines de I/O, existe la posibilidad de poner el cristal de cuarzo conectado a los pines externos de la placa.

El procedimiento se puede hacer con el cristal que viene con el launchpad, pero, debido a su tamaño,no es la solución más cómoda.  Los osciladores de 32768Hz son fáciles de conseguir y baratos. Es importante, no obstante, comprarlos con una capacidad soportada por la familia MSP430 como 12,5pF o 6pF para no tener que añadir capacidades externas. A modo de ejemplo está este de Farnell que es el que he empleado.

En la siguiente figura se muestra un cristal de 32768Hz soldado a dos pines hembra.

Cristal soldado a pines hembra

Para emplear el cristal basta con conectarlo en la placa en los pines correspondientes.

Cristal sobre los pines de la placa

Con ello acaba este artículo sobre el cristal externo del Launchpad. Con un cristal como éste es fácil desarrollar aplicaciones que requieran una temporización precisa como sistemas basados en reloj de tiempo real, frecuencímetros, etc...