Arduino UNO con wifi ESP8266 por comandos AT simple

Los módulos ESP8266 vienen programados de fábrica para usarse como módems wifi. Para ello se debe usar una extensión del juego de comandos AT estándar: http://www.espressif.com/sites/default/files/documentation/4a-esp8266_at_instruction_set_en.pdf

Un problema que he encontrado es que los módulos ESP8266 antiguos (firmware 0.9.5) venían configurados por defecto con el puerto serie a 9600 baudios. Esto es muy lento pero muy adecuado para trabajar con los puertos série de software de Arduino UNO (librería softwareserial).
Los nuevos ESP8266 con el firmware (por ejemplo con firmware 1.5.2 ó 2.0.0) vienen configurados con el puerto serie a 115200 bauds. Esto no es problema para un Arduino MEGA que tiene varios puertos serie de hardware. Pero con un Arduino UNO, que solo tiene un puerto serie de hardware y esta conectado al convertidor USB <-> Serie, no podremos usarlos.
Si conectamos el ESP8266 al puerto serie nativo perdemos la comunicación con el PC y la capacidad de depurar el programa por el puerto serie. Además nos interferirá en la carga de sketchs desde el IDE e Arduino.
Si usamos un puerto serie de software (con la librería softwareserial) no podremos comunicar a más de 38400 bauds (teóricamente a 57600 pero yo no lo he conseguido, incluso a 38400 se producen muchos errores).

La solución que propongo es reconfigurar la velocidad por defecto de los ESP8266 a una velocidad mas baja compatible con la librería softwareserial. Una velocidad razonable para esta librería es 19200 baudios.

El procedimiento es el siguiente:
Cargar un sketch vacío en el IDE de arduino y enviarlo al Arduino UNO. A continuación conectar ESP8266 ESP01 para comunicar PC con ESP8266:
ESP8266 PIN 1 (RXD) -> ARDUINO UNO PIN 0 RX
ESP8266 PIN 8 (TXD) -> ARDUINO UNO PIN 1 TX
Según este esquema:

Es necesario que el Arduino UNO tenga un sketch vacío para que no interfiera en las comunicaciones con el ESP8266. Este esquema nos permite usar la placa Arduino UNO como convertidor USB <-> RS232 para comunicar el PC con la placa ESP8266.

A continuación abrir el monitor serie del IDE Arduino ( Herramientas -> Monitor Serie o pulsando Control + Mayúsculas + M) y configurar enviar “Ambos NL & CR” y la velocidad a 115200 baudios.
Enviar AT y enter y el módulo deberá responder OK si todo es correcto. Si la velocidad por defecto del módulo no es 115200 no responerá y posiblemente se vea “basura” en el monitor serie. Entonces habrá que probar distintas velocidades hasta conseguir que el módulo responda OK al comando AT.
Para configurar la velocidad por defecto a 19200 baudios, 8 bits de datos, uno de stop y sin control de flujo hay que enviar el comando:
AT+UART_DEF=19200,8,1,0,0
y el módulo responderá AT.
A continuación no responderá más a AT porque ya habrá conmutado a la nueva velocidad. Para probarlo seleccionar 19200 baudios en el monitor serie y enviar AT. La respuesta deberá ser OK si todo es correcto. Tras este procedimiento la velocidad por defecto queda fijada a 119200 baudios incluso tras un eset del módulo o tras quitarle alimentación.
En este fichero estan los esquemas e instrucciones para este proceso: Esp8266_Config

Ahora ya puede conectarse el ESP8266 en una par de pines generales y configurarlos para puerto serie de software.
Podemos usar los pines 2 y 3 para el puerto serie y conectar también un LED y un pulsador siguiendo este esquema:

A continuación cargamos en el IDE de arduino el sketch “Esp8266_Simple.ino”: Esp8266_Simple
Para monitorizar el trabajo de este sketch se puede usar el monitor serie configurado a 115200 baudios.
La salida será similar a esta:
Enviando: AT+RST
Respuesta: AT+RST
OK
(algo de basura…)
ready
Enviando: AT+CWSAP_CUR=”MyESP8266″,”Test1234″,5,3
Respuesta: AT+CWSAP_CUR=”MyESP8266″,”Test1234″,5,3
OK
Enviando: AT+CWMODE=2
Respuesta: AT+CWMODE=2
OK
Enviando: AT+CIPMUX=1
Respuesta: AT+CIPMUX=1
OK
Enviando: AT+CIPSERVER=1,80
Respuesta: AT+CIPSERVER=1,80
OK
Enviando: AT+CIFSR
Respuesta: AT+CIFSR
+CIFSR:APIP,”192.168.4.1″
+CIFSR:APMAC,”1a:fe:00:00:00:00″
OK
Trabajando
Trabajando
Trabajando
Trabajando

Este programa crea un punto de acceso WIFI (AP) llamado “MyESP8266” con contraseña WPA2 “Test1234” en el canal 5. Nos conectamos a ese punto de acceso, introducimos la contraseña y abrimos en un navegador la dirección 192.168.4.1.
Podremos ver una página web simple con dos botones rotulados ON y OFF. Pulsándolos podremos cambiar el estado del LED conectado el PIN 13 del Arduino. Más abajo podemos ver el estado del PULSADOR conectado en el pin 4.

El caso de los firmwares corruptos. SPI EEPROM 25Qxx

Un amigo me ha dejado un TV de marca ANSONIC (marca de Hipercor) para reparar. Aunque el televisor es una marca genérica la electrónica es Vestel, que es un gran fabricante de electrónica de consumo. La misma placa, modelo 17MB55, se usa en televisores Telefunken y otras marcas conocidas.

Los síntomas son que el TV se mantiene en standby, al encenderlo no hace nada de nada. La primera sospecha es de alimentaciones, pero todas son correctas. Comprobando los relojes y reset todo es correcto, pero sique sin arrancar. Si tiene alimentación, tiene reloj y no esta reseteado el procesador debería comenzar a ejecutar el programa y arrancar el TV, pero no… Por último sospecho del propio programa ¿y si es incorrecto?.
Esta placa usa dos memorias EEprom SPI de 8 patas para almacenar el programa, es facil encontrar los puntos de test para leerlas y progrmarlas por ICSP, pero yo prefiero desmontarlas y pincharlas directamente al lector/grabador porque me es mas rápido que preparar un cable ICSP específico para esta placa.

Añadiendo unos hilillos a las memorias SO8 puedo insertar las memorias en el lector/grabador para DIL. Leo las memorias y hago un backup, importante!, que nunca se sabe…

A continuación busco en distintos foros de internet dedicados al servicio técnico de Audio y Video, pero no encuentro el firmware exacto para esta Ansonic. Hay que buscar “Dump” no “firmware” porque lo que la gente sube a la web no es el firmware tal y como lo proporciona el fabricante sino un volcado binario de lo que se lee de las propias eeprom. Por suerte encuentro un firmware para esta placa Vestel, pero para un televisor Telefunken: http://remont-aud.net/dump/lcd_pdp_tv/telefunken/telefunken_d32h125n3_shassi_main_board_vestel_17mb55/378-1-0-31790 Flasheo las memorias y las sueldo provisionalmente en su sitio:

PERFECTO. El TV vuelve a funcionar, aunque ahora los menús son los de Telefunken.

Ya solo queda desoldarlas, quitar las patillas y soldarlas de forma definitiva.
Todavía me quedaba por averiguar la razón de la corrución de los datos… un amigo bromeó que había sido un rayo cósmico, pero yo pensaba que era un error del firmware que al grabar algún parámetro había sobreescrito el bloque equivocado.

Cuando devuelvo el TV a mi amigo y le explico la avería, muy contento, me dice que esta podía ser también la avería de otro TV que tenía. Es cierto, hacía unos meses habíamos estado intentando reparar un Blaupunkt BLA-236/173J con lector de DVD pero nos había sido imposible. Él lo solucionó comprando otro igual pero con el TFT roto y cambiando la placa base. Pero el cambio le funcionó unos meses y de nuevo muerto…
Recuperamos los restos de los TV del trastero y nos ponemos a ello. A ver que sacamos partiendo de dos Blaupunkt iguales averiados con el mismo problema en la placa base, modelo T.MSD309.B66B:

Esta placa base solo tiene una EEPROM, pero la técnica es la misma: desoldarla, leerla, buscar un firmware nuevo adecuado, grabarla, resoldarla para pruebas y soldarla definitivamente, si todo va bien.

Buscando por aqui: http://remont-aud.net/dump/lcd_pdp_tv/blaupunkt/blaupunkt_bla_23207i_gb_3b_hkdp_uk_b23u207thdd_shassi_main_board_t_msd309_b66b/380-1-0-37955
Encontré algunos que mediofuncionaban, aunque no manejaban adecuadamente el modelo de panel que este TV usaba:

Encontré otross que funcionaron bien, lo que confirmaba que el problema era el firmware corrupto, pero ninguno tenían soporte para DVD:

Pensando que el problema era un bloque de eeprom incorrecto, me pongo a comparar todas los firmwares .bin que había descargado con el backup que había leído, intentando buscar un bloque discrepante. Estos firmwares son modulares y dentro contienen secciones con el bootloader, el driver del panel, sintonizador, etc y los menús que cada fabricante personaliza.
Después de mucho comparar no pude ver diferencias en la estructura entre el backup corrupto y los firmwares operativos. Todo parecía estar en su sitio y no había bloques borrados.
Pero la casualidad, que a veces ayuda, me hace ver, en un bloque vacío, un dato discordante:

Un cuatro (04 hexadecimal, que es 00000100 en binario) en medio de un bloque de ceros… Un bit que debia estar a cero esta a uno!!! ¿Es este el problema? Pues SI! después de cambiar este 04 a 00 y grabar la memoria de nuevo el TV vuelve a funcionar como al principio, y con soporte para el lector de DVD! Es mucha casualidad haber encontrado un bit cambiado en 32 millones, pero estaba en una zona de buena visibilidad. Si el bit eeróneo hubiera estado en una zona con datos habría sido imposible identificarlo. Aunque el bit estaba en una zona vacía es común que el firmware realize un autochequeo con un checksum y si no es correcto no arranque, por seguridad.

Ahora ya no me parece tan raro lo del rayo cósmico, aunque es raro… También puede deberse a una mala calidad de la memoria EEPROM o un proceso de grabación incorrecto. La eeprom de este modelo era una GD25Q32 de GigaDevice: http://www.gigadevice.com/product/detail/5/365.html?locale=en_US.

Lo claro es que flasheando este firmware parcheado en las dos EEPROM se repararon las dos placas base del Blaupunkt y el TV funcionó de nuevo. Ya hora con una placa base de repuesto!

Si puede serle de ayuda a alguien, este es el firmware leido y reparado para esta placa T.MSD309.B66B del Blaupunkt BLA-236/173J-GB-4B-FHKDUP-EU: T.MSD309.B66B uf11 GD25Q32 Leida Reparada

Actualización 24/11/2017
Parece que la epidemia de datos corruptos en memorias SPI se extiende a otros aparatos, y a memorias I2C. Ayer reparé un (bastante caro) medidor de espesores por ultrasonidos Krautkramer Branson DM4E.
El aparato es muy parecido a este:

Mide espesores mediante una sonda de contacto por ultrasonidos de entre 1Mhz a 10Mhz. El aparato mostraba “FAIL” en la pantalla y un proveedor nos ofertó repararlo por casi 2000€. Por suerte teníamos otro igual para comprobar…
El problema estaba en una EEPROM I2C Microchip 24lc65.

Por alguna extraña razón el medidor interpretaba que los datos contenidos en la memoria, a penas 64 bytes de los 8K bytes disponibles, no eran correctos y se negaba a trabajar. Un “transplante” de datos desde la EEPROM del otro medidor que funcionaba correctamente y una nueva calibración y reparado!

Usando CIS (Contact Image Sensor) con Arduino y Processing

En construcción.
Esta semana estoy trabajando un poco la ingenieria inversa, a ver si soy capaz de sacar algo en claro de los CIS Contact Image Sensor).
Tengo un puñado de ellos, incluido uno enorme y antiguo para DIN A3 TCD120AC.

Desgraciadamente no hay mucha información técnica pública en internet. De lo poco que he podido encontrar esta hoja de datos de Dyna Image es muy interesante: https://www.tvsat.com.pl/pdf/D/dl100_dyna.pdf
Parece ser que son dispositivos muy personalizables y los fabricantes de escáners los encargan a medida. http://www.csensor.com/M118_CIS.htm
Los sensores CIS son mucho mas fáciles de usar que los CCD (que requieren varios clock y tiempos muy precisos y la salida necesita preamplificador etc). La salida de los CIS suele ser de entre 2,5V a 5V de fondo de escala. Podemos introducirla directamente en un A/D de cualquier micro.
Los elementos sensores son CMOS y eso les da unas características electro ópticas bastante buenas. No he podido encontrar las curvas de sensibilidad espectral de los elementos supongo que serán las típicas de los fotodiodos para luz visible.
Los fabricantes estan empleando CIS para sustituir los CCDs en los escáneres, faxes etc porque les simplifica y abarata los diseños: ya no neceesitan complejas ópticas con espejos y delicados ajustes.
Eso también ayuda a usarlos con facilidad a nivel de aficionado que sean grandes, 216mm (ancho del papel DIN A4), y que tengan bastantes elementos (mínimo unos 8 por mm, 1728 en total).

De todos los que tengo no he podido encontrar hoja de datos de ninguno, algunos se ve claramente que el código marcado es un código de cliente…
Por suerte tengo dos Dyna Image similares a los de la hoja de datos.
Uno es un DL100-10AFJK con conector de 12 pines y el otro un DL100-05EUJK con conector de 7 pines que parece coincidir con la hoja de datos.

Preparo un programa para Arduino UNO sencillo, para tratar de comunicar con él.
Parece ser que todos usan un sistema muy parecido, la salida es analógica y de un nivel compatible con un A/D de 5V fondo de escala. Solo hay que proporcionar dos señales para la lectura:
Pulso SP, (Start pulse) que señala el comienzo de línea y
Pulsos SP o CLK (Clock) que generan la salida del valor analógico de cada punto de imagen.

Para la visualización de las líneas capturadas uso un programa en Processing en un PC con Windows:

Fuentes para probar la lectura de datos de diversos CIS Contact Image Sensor), para Arduino UNO y para el PC, en java con Processing:

Descargar todas las fuentes del proyecto: CISReader.zip

Lectura de CIS DynaImage DL100-05EUJK a baja velocidad:

Lectura de CIS DynaImage DL100-05EUJK a alta velocidad:

Lectura de CIS SS30009B de color RGB:

Lector, copiador y borrador de tarjetas RFID MIFARE

Estoy liado con varios proyectos que involucran lectores de tarjetas RFID tipo MIFARE de NXP https://www.nxp.com/products/identification-and-security/mifare-ics/mifare-classic:MC_41863 con lectores MFRC522 https://www.prometec.net/producto/rfid-kit-arduino y Arduino UNO

MFRC522

Uno de los probemas que he encontrado es que, cuando trabajas con montones de tarjetas y varios proyectos a la vez, es muy facil confundir tarjetas o incluso programar keys incorrectas. En esas condiciones las tarjetas pueden quedar inútiles (es imprescindible conocer las keys internas para usarlas o borrarlas).

Este programa para Arduino UNO (posiblemente funcione en otros) nos permite averiguar las keys programadas en las tarjetas para luego borrarlas o copiarlas sin preocuparnos de buscar las keys exactas que fueron programadas dentro.
Para ello es necesario compilar el programa con la lista de las keys comunmente usadas en nuestros proyectos. El programa intenta autentificarse en cada sector con cada una de las keys programadas y crea una lista de keys y secores. Esto nos permite luego borrar la tarjeta y dejarla en condiciones de fábrica o copiarla a otra vacía.
Es necesaria la librería de arduino MRFC522 que puede instalarse desde el gestor de librerías del arduino IDE o de aqui: https://github.com/miguelbalboa/rfid

El conexionado necesario es muy sencillo:

Fos ficheros del proyecto: HeliMifareClonner.zip

Para usar el programa se abre con el IDE de arduino y se carga en el arduino. Luego se abre el “monitor serie” y se configura a 115200 baudios y “sin ajuste de linea”. Aparecerá un menú con 5 opciones, que es autoexplicativo:
1: PROBAR las Keys conocidas. Intenta averiguar que key, de la lista incluida en el programa, corresponde con cada sector de la tarjeta.
2: LEER Tarjeta: Lee la tarjeta usando la lista de keys averiguada anteriormente.
3: VER DATOS de tarjeta: Muestra el bloque de datos (1024 bytes) que ha podido leer con la opción 2
4: ESCRIBIR nueva tarjeta: Escribe una tarjeta vacía, que este con las keys de fábrica a FFFFFFFFFFFF, con los datos leidos anteriormente y luego instala las keys averiguadas en cada sector. Esto crea una tarjeta clon de la leíada anteriormente. El bloque 0, que contiene el UID y otros datos del fabricante, no se copia. Aunque algunas tarjetas de fabricantes alternativos (No NXP) permiten escribir en el bloque 0 usando una secuencia de comandos especial, este programa no lo hace (la línea de código necearia esta comentada en el programa) porque no he podido probar que funcione correctamente.
5: COMPROBAR Tarjeta con datos Compara los datos leidos previamente con los datos de otra tarjeta. Si las keys no son las mismas en las dos tarjetas los bloques trailer no podrán coincidir y habrá otros sectores que no podrán leerse y quedarán sin comparar “SIN DATOS”.
6: BORRAR tarjeta: Borra una tarjeta usando las keys averiguadas para dejarla tal y como vienen de fábrica, con las keys a FFFFFFFFFFFF (“transport keys”).

Como optimizar el consumo de memoria en programas de Arduino

El compilador que usa el entorno Arduino es muy óptimo y es dificil escribir el programa de forma que genere menos código: el compilador optimiza automáticamente independientemente de como lo esribamos.
Pero hay algunos detalles que permiten ahorrar bytes de RAM o de FLASH, cambiando un poco el enfoque de los programas!

Uno es usar el macro F() para las variables de cadena que pasamos a algunas funciones, principalmente Serial.print().
Usando como ejemplo el programa http://heli.xbot.es/?p=501 podemos cambiar la línea 61 de:
        Serial.println (“Testing AnalogKeyPad”);
a
        Serial.println (F(“Testing AnalogKeyPad”));

Compilando con el IDE de Arduino 1.8.5 para Arduino UNO (Atmega328p),
la primera forma genera un programa de 1958 bytes que usa 269 bytes de RAM y
la segunda forma genera un programa de 1998 bytes que usa 249 bytes de RAM.
Hemos ahorrado 20 bytes de ram (de los 2048 disponibles) pero el programa ha crecido en 40 bytes!
Que no cunda el pánico, ahora optimizamos mas todavía:
cambiamos la línea 70 de:
        Serial.print (“Pulsado “); Serial.println (b);
a
        Serial.print (F(“Pulsado “)); Serial.println (b);
Ahora el programa ocupa 2004 bytes y usamos 239 de RAM, el programa solo ha crecido en 6 bytes y hemos ahorrado 10 bytes de RAM.

El programa sobre el que estamos trabajando es muy sencillo y no tiene mas cadenas constantes, no podemos seguir mejorándolo, pero cualquier cadena que convirtamos en constante en el futuro ahorraría aproximadamente su longitud en RAM incrementando solo 6 bytes de código en FLASH.

¿Y por que es así?
Porque el micro ATMEGA328P, y toda la familia aTMEGA, son micros con Arquitectura Harvard y eso significa que los DATOS y las instrucciones de PROGRAMA se almacenan en espacios separados y se acceden usando instrucciones de programa distintas.
Eso representa un problema para el compilador porque tiene que generar un código distinto para manejar datos variables (en RAM) y datos constantes (en memoria de programa FLASH).
El compilador que usa el entorno de Arduino es el AVR-GCC y soluciona este problema copiando en RAM las constantes y usando siempre funciones que trabajan sobre RAM.
Esto tiene el inconveniente de que cada constante que declaramos en nuestro programa ocupa una cantidad igual de memoria de programa y de RAM.
Y esto no tiene facil solución porque, para manejar datos que solo esten en memoria de programa, hacen falta funciones distintas que sepan manejar los datos residentes en ese espacio de memoria.
En arduino existe el macro F() que permite instruir al compilador para que almacene una cadena constante solo en FLASH.
Además la función Serial.print() esta sobrecargada de forma que se compila de forma distinta para cadenas variables que para cadenas constantes.
La primera vez que usamos la función Serial.print(F()) el compilador añade el código de la librería necesario para manejar cadenas constantes y por eso el programa crece un poco. Los siguientes usos de la función solo incrementen un poco el código debido a la diferente gestión de los datos.
Lo importante es que cada uso de F() ahorra una cantidad de RAM igual a la longitud de la cadena usada! Y en RAM es donde mas justo esta el Atmega328p.

Podemos usar esta técnica para otras constantes, pero si la función que las ha de usar no esta adecuadamente sobrecargada (es decir, no tienen definida función para trabajar con datos en espacio de programa) no será posible. Tenemos que escribir nuestro propio código para acceder a esos datos en memoria de programa… pero es sencillo.

Este es un array normal, cada dato (int) ocupa dos bytes de FLASH y dos de RAM.
        const int KeyVals[nKeys+1] = { 693, 665, 624, 573, 544, 491, 463, 432, 393, 353, 308, 249, 188, 157, 117, 79, 0};

La forma de decir al compilador que queremos que almacene un array en memoria de programa es esta:
        const int KeyVals[nKeys+1 ] PROGMEM = { 693, 665, 624, 573, 544, 491, 463, 432, 393, 353, 308, 249, 188, 157, 117, 79, 0};

Pero al usar la segunda forma ya no podemos hacer:
if (Val >= KeyVals[i]) break;

porque el manejo de variables array solo puede trabajar con datos en RAM. ATENCION el compilador no informará de un error!!! pero el programa no funcionará. Los datos estarán almacenados en un espacio de memoria pero el programa intentará usar punteros a ese espacio de memoria en otro espacio de memoria distinto, con lo que apuntará a datos distintos y no funcionará!! Debe usarse la función adecuada para leer los datos almacenados en la memoria de programa, usando los punteros a memoria de programa ha generado el uso de PROGMEM: pgm_read_word(), porque los datos son de tipo int (ocupan 16 bits):
        if (Val >= pgm_read_word(KeyVals+i)) break;

Para el otro array, que es tipo char (8 bits), se debe usar la función
        pgm_read_byte(Keys+i);

NO se puede usar el índice [i] en un array PROGMEM ya que su gestión esta definida para trabajar con variables RAM. Debe usarse +i que sirve para punteros a RAM o a FLASH.

Después de aplicar estas dos optimizaciones al programa (dos líneas con F() y dos arrays cambiados a PROGMEM) el programa que antes ocupaga 1958 bytes de FLASH y usaba 269 de RAM ahora ocupa 1992 bytes de FLASH pero solo usa 189 bytes de RAM.
Ha crecido en 34 bytes de 32768 disponibles (~ 0.1%) pero ha bajado el uso de ram en 80 bytes de 2048, casi un 4% de mejora.

https://www.arduino.cc/en/Reference/PROGMEM

El programa optimizado: AnalogKeyPad1

Usando un display de matriz LED indocumentado CDM102

Haciendo limpieza he desmontado y tirado una docena de viejos switches ethernet 10baseT de Nortel Networks “Baystack 102”. Specs Baystack 102

A parte de mucho hierro tienen unas fuentes de alimentación fabricadas por Delta SMP43ep-5 muy interesantes.
https://www.usbid.com/assets/datasheets/C5/smp43ep.pdf
Proporcionan 5V hasta 11A, 12V 3A y -12V 0,5A aunque la potencia total es de 43W.

También son muy interesantes los displays de matriz de 12 * 5 LED bicolores. La pega es que no hay mucha información acerca de su funcionamiento. Llevan impreso el código “CDM102”, pero parecen ser diseñados a medida y no existe información pública sobre ellos.

En google he encontrado algo de información, que coincide con mis primeros análisis: http://home.earthlink.net/~drbarrall/CDM102.html

El interface es série síncrono al estilo del SPI. El uso de cada uno de los 6 pines es el siguiente:

1: LOAD Load data (Active low)
2: V+ 5V
3: SDCLK Data Clock (Active high)
4: Ground
5: SDDATA Data
6: Reset (Active low)

Despues de probar los comandos publicados por DrBarral he llegado a la conclusión de que este display es un diseño a medida para Nortel, fabricado por Siemens – Infineon – OSRAM y derivado de los displays estándar SCDQ554x http://www.osram-os.com/Graphics/XPic1/00052446_0.pdf o SCD551x http://www.osram-os.com/Graphics/XPic4/00045726_0.pdf.
CDM102 podría ser Custom Display Module 102.
La principal diferencia es que se trata de una matriz doble de 6 x 5 mientras que los displays citados son de matriz de 5 x 5.

El juego de comandos es bastante sencillo, basado en una única palabra de 8 bits:
00 – 7F: 5 bits de datos para las columnas, bit 0 es el LED de mas arriba. Se incrementa el puntero automaticamente.
Hay 6 columnas
80 – 9F: Nop
A0 – A5: Selecciona bloque de columnas. Hay 2 bloques de 6 columnas. Bloque par color ROJO, impar color VERDE.
El bit 4 no importa. El primer bloque es el de la izquierda.
A6 – AF: Select none
B0 – B5: Selecciona bloque de columnas. Hay 2 bloques de 6 columnas. Bloque par color ROJO, impar color VERDE.
El bit 4 no importa. El primer bloque es el de la izquierda.
B6 – BF: Seleccionar NADA
C0 – DF: Test: rellena filas con rojo+verde: bit 0 = primera columna, bit 1 = segunda etc
E0 – EF: Ajustar brillo en 8 steps, el bit 3 no importa
F0 – FF: Ajustar brillo en 8 steps, el bit 3 no importa

He escrito un software de prueba que permite escribir caracteres en un número arbitrario de displays puestos lado con lado, bien de forma vertical como horizontal. Tembién contiene un ejemplo para usarlo como barra gráfica de 12 barras berticales x 5 LED o 5 barras horizontales de 12 LED.
He aprovechado los bitmap que ya tenía escritos hace años para los SCDQ554x, sirven igual pero solo son de 5 x 5 pixel, dejo sin uso una línea de LED en este display de 6 x 5.
Prueba para CDM102 con Arduino/Teensy

El montaje de pruebas ha quedado así:

Las funciones que he incluido dentro del programa de pruebas son las mismas que ya usé en el display YL-3: http://heli.xbot.es/wp-admin/post.php?post=151
Aunque he añadido un par de comandos para cambiar la orientación del texto y el color “ºh , ºv, “ºr y ºg.