Llevo una semana refatorizando el código de OSCAR y OSCARET para unificarlo todo en uno: TDSO, Tcl/Tk Digital Storage Oscilloscope.
La cosa, es que si revisas los proyectos que tengo en Sourceforge, hay varios osciloscopios:
- OSCAR: OSCiloscopio ARduino
- TDSO112A DSO112A de JYETech
- TDSO152 DSO152 de FNIRSI
- Techo CH32V00X
Hasta ahora, escogía el proyecto que tenía más a mano para realizar mejoras y después lo pasaba al resto… pero esta forma de actuar no escala y el tiempo no me llega.
La solución: one TDO to rule them all.
Tras varios prototipos hardware y software, ya tengo claro qué cosas tienen en común este tipo de hardware, así que podía atacar el problema de la heterogeneidad en mis proyectos.
Patrones de diseño
Creo que es un error empezar a abstraer problemas que no se entienden, y a lo largo de mi carrera profesional he sufrido en mis carnes este tipo de situaciones, donde alguien que no sabe nada del problema se pone a abstraer sin haber hablado con el cliente o sin tener unos mínimos requisitos claros (y sí; muchas veces el cliente tampoco tiene ni idea de qué necesita o cómo funcionan las cosas, así que el tema de los requisitos es una utopía…). Al final se crean soluciones software sobredimensionadas que no solo no satisfacen las necesidades del cliente, sino que son tan complicadas que ni el propio arquitecto es capaz de encontrar soluciones a nuevos requisitos (menos aún en un tiempo razonable). Pero que nadie me entienda mal, ese trabajo es MUY COMPLICADO, pero es que además, muchas veces nos complicamos nosotros mismos la existencia.
Por todo lo anterior, siempre tiendo a empezar con algo básico y sin ninguna pretensión de escalar o general. Además, esto permite mostrar al cliente un prototipo de forma rápida (y muchas veces, el primero se lleva el pez a casa). Por tanto, no considero que haya perdido el tiempo realizando todos estos prototipos, porque además, al ser tan simples, me han permitido tener algo funcional desde el principio.
En el caso de TDSO, estaba claro que si conseguía integrar OSCAR y OSCARET, ya tendría el camino libre para integrar otros osciloscopios. OSCAR y OSCARET son muy similares en la parte firmware, pero muy diferentes en la parte hardware, lo que los hace ideales para probar la integración.
Al final, usando factory y strategy (dos patrones de GoF), he podido integrarlo todo en un solo programa. Además, como prueba de fuego he podido integrar el control del DSO152 de FNIRSI en una sola tarde, así que: parece que la factorización ha funcionado.
Integración con Sigrok
La integración con Sigrok ya la había experimentado e implementado con éxito en TDSO112A. La verdad que es genial trabajar con este pequeño (aunque tiene errores de firmware que son molestos y tenemos que esquibarlos mediante software…). La documentación y el hardware me parecen geniales.
En una primera aproximación, tanto OSCAR como OSCARET no tienían implementado un trigger como tal, sino un disparo por nivel (que es mucho más sencillo y para visualizar señales es perfecto). En TDO, he implementado los trigger habituales:
- Auto Si hay condición de disparo, mostrar la señal. Sino… pues también
- Nomal Solo muestro la señal si hay condición de disparo
- Single Solo disparo una vez, si se da la condición
Aunque estos disparos son útiles (por ejemplo podemos ver un pre-trigger escogido de entre varios: 0%, 25%, 50%…), para la integración con Sigrok no valen para nada.
En el caso de OSCAR y OSCARET, solo tenemos 1024 puntos, así que tiene que darse la casualidad de que la señal que queremos estudiar se de en el preciso momento en que tenemos el espacio suficiente para capturarla entera. Para 1024 puntos como digo, se da de vez en cuando… pero con 4096 ya tenemos muchas más posibilidades, aunque evidentemente esto tampoco sirve, ya que no podemos estar pendientes de nuestra suerte. Todo esto lo pude comprobar con el DSO152, que dispone de 20kB de RAM, donde capturaba con bastante frecuencia la comunicación UART de un Arduino UNO R3 enviando “hola\r\n caracola”.
Evidentemente no quería de ninguna manera un trigger hardware, así que he implementado un trigger en el firmware, donde vamos capturando los datos de ADC pero solo los enviamos al buffer (que finalmente enviaremos al ordenador) si de da la condición del trigger (también envío el previo puesto que por ejemplo para la UART hace falta detectar el flanco de bajada. La verdad que solo un registro anterior es demasiado justo… lo tendría que cambiar, aunque de momento funciona).
Y con este trigger firmware (que evidentemente se puede modificar desde el software), y gracias al fantástico trabajo de Sigrok, se hace la magia. Aquí podemos ver como OSCAR está decodificando una señal UART 9600 bps de otro Arduino.
Decodificando UART con OSCAR
La verdad que me parece impresionante poder decodificar una señal UART mediante simplemente un Arduino UNO R3, dos hilos y OSCAR. Aquí tienes unas muestras.
Como puedes ver, la frecuencia de muestreo es demasiado grande y no cabe todo el paquete.
Disminuyendo la frecuencia de muestreo ya tenemos todos los caracteres.
Y esta es la frecuencia de muestreo máxima para que Sigrok pueda decodificar el mensaje. Como ves, podría ser muchísimo más largo, aunque siempre he pensado que 1024 puntos son muy pocos para que pueda ser útil, la realidad es que han sido suficientes.
Libro y software
Te animo a utilizar OSCAR con tu Arduino UNO. Verás que es una herramienta útil.
Si quieres aprender cómo he implementado el programa, a OSCAR y OSCARET, puedes leer mi libro disponible en Amazon, Arduino Tcl/Tk osciloscopio.
Eso sí, la parte de la integración con Sigrok, nuevos triggers y demás, es material para la próxima versión.