En entradas anteriores comenté distintas alternativas del proyecto ADX cuyo autor es Barb (WB2CBA), empezando por su estudio e implementación iniciales, luego modificaciones a su firmware para finalmente explorar los límites de la placa en frecuencias superiores a las originalmente concebidas por su autor. Es un proyecto muy interesante con el cual tuve la oportunidad de hacer varios experimentos, los que oportunamente fueron documentados en entradas previas de éste blog.
Al introducir nuevas funciones o modificaciones de las anteriores en el firmware fui también modificando el "estilo" base en el que está escrito, simplemente por una cuestión de experiencia sobre que constituye código robusto y que no lo es. Al mismo tiempo fui agregando funciones que objetivamente creía conveniente realizar. Aplicando prácticas mas o menos establecidas de evolución de productos e integración de funciones tuve la precaución de codificar las modificaciones con una técnica llamada "control de configuración" donde el código puede modificar su comportamiento en función de directivas externas en tiempo de compilación. De esa manera incluyendo una directiva del estilo de "#define CAT 1" puedo hacer que todos los segmentos de código relacionados con la implementación del CAT sean incluidos o excluidos. Haciendolo con todas las modificaciones es posible ir agregando las distintas funciones una por una y en cualquier orden sin que interaccionaran entre si, condición que técnicamente recibe el nombre de "alta cohesión y bajo acoplamiento" de funciones. El resultado es un código mas extenso y mas complejo, no solo porque hace mas cosas sino porque también existe una infraestructura de código para gestionar las alternativas de configuración. Habiendo puesto el código resultante en el dominio público (como ADX_QUAD_V1.5) encontré rápidamente que había un inconveniente fundamental. Hay demasiadas versiones de firmware independientes entre sí, sin la mas minima coordinación entre sí; situación que rápidamente hace que las funciones sean incompatibles entre si y que no se sepa cual hay que tomar de base para agregar alguna función. Al mismo tiempo, y casi completamente en dirección opuesta, los usuarios habituales de la plataforma ADX no apoyaban el incremento de complejidad y preferían claramente un código relativamente escaso en funciones pero pequeño tal como el original de ADX. Llegué entonces a la conclusión que no valía la pena el esfuerzo de trabajar en una versión mas grande y compleja, que agregaba funciones que no siempre eran entendidas para que (pues el firmware original no las tiene) y que además no era tenida en cuenta como base para agregar nuevas funciones, debido a ésto último no justifica el esfuerzo de trabajar en una cosa así.
En realidad esa versión se trataba de una función de referencia no ya para que fuera utilizada por toda la comunidad ADX existente sino que además era la plataforma para plantear la migración a un procesador mas potente. El procesador elegido es el ARM rp2040, corazón de la placa Raspberry Pi Pico.
Siendo que se trata de un procesador casi un orden de magnitud mas potente que el original del Arduino
En efecto, al agregar unas pocas funciones al firmware original ADX rápidamente se llega al límite de memoria que puede manejar un procesador Atmel328p, corazón del Arduino Nano, por lo que es dificultoso agregar mayor complejidad (mayor cantidad de código). Por lo que por mas que las funciones se agreguen incrementalmente deja de tener sentido una base común si lo fundamental solo funciona en una plataforma. Es una manera de limitar o restringir, artificialmente, ambas.
Se intentó hacer un esfuerzo mancomunado para "portar" el código de referencia ADX_QUAD_V1.5 a uno nuevo, denominado PDX (Pico Digital Transceiver) el cual esencialmente requiere una placa igual a la ADX pero con una placa Raspberry Pi Pico en lugar de una Arduino Nano, todo el resto idéntico.
El esfuerzo, significativo, implicaba no solo lograr que el firmware ADX pudiera funcionar en un procesador distinto, con una arquitectura distinta sino que en su esencia se mantuviera un solo código para ambas placas (ADX y PDX).
El firmware ADX está desarrollado utilizando el Arduino IDE (Integrated Development Environment) mientas que el ambiente de desarrollo para Raspberry Pi Pico está basado en el IDE Eclipse utilizando un conjunto de librería llamados el Pico-SDK (Software Development Kit), ambos incompatibles como habría de suponerse.
Eso se superó parcialmente gracias al enorme trabajo de Earle Philhower III, quien creo una serie de librerías (link) que una vez instaladas en un Arduino IDE (instrucciones) permite compilar indistintamente para un Arduino a para una multitud de placas basadas en el procesador rp2040.
El nivel de implementación es excelente, la mayor parte de la librerías que funcionan en Arduino también lo hacen bajo éste ambiente, aunque hay algunas variantes en aquellas caracteristicas que son diferentes entre un Atmel328p y un rp2040 a nivel de hardware.
Una diferencia en particular es que la forma de medir la frecuencia en el firmware ADX utiliza interrupciones y comparadores en hardware que el rp2040 no tiene, por lo que no es directamente portable.
La solución fue bastante trabajosa e implicó desarrollar en forma independiente cuatro diferentes formas de realizar la medición de forma de medir cual es la mejor; siguiendo con las caracteristicas de configuración mencionadas los cuatro métodos podían ser configurados independientemente.
Este enfoque de trabajo implica una coordinación muy precisa pues cualquier modificación para una arquitectura tiene que ser propagada para la otra, y teniendo en cuenta que un firmware está difundido y el otro está en desarrollo implica en ocasiones liberar en forma desbalanceada (incluir una modificación selectivamente en una plataforma y no en la otra). El esfuerzo para hacer eso es enorme.
Por su parte todas las nuevas funciones que se agreguen en la nueva plataforma (PDX) requiere un cierto grado de "retrocompatibilidad" a las correspondientes en el firmware "base" (ADX). Por ejemplo, rápidamente surgió para que ponerle LED o "push button" toda vez que la nueva placa probablemente tuviera un LCD TFT display, sin embargo sin ellos el ADX no funciona.
El proyecto entró en un circulo vicioso, por un lado la comunidad existente ADX no convergía a utilizar al versión 1.5 del firmware para ninguna actividad y la comunidad desarrollando el PDX no veía la
necesidad (y el esfuerzo adicional) de mantenerse compatible con ADX, generandose continuamente segmentos de código en violación a esa condición, completaba el escenario cierta disfuncionalidad en los acuerdos de metodología de trabajo entre el grupo de desarrolladores.
La situación se hizo insostenible, y luego de no pocas frustraciones anuncié entonces que retiraba del dominio público a la versión ADX_QUAD_V1.5, cosa que hice efectivamente y también discontinué todo el código desarrollado para PDX hasta ese momento (el cual mayormente tenía contribuciones mias).
Pero, el proyecto era demasiado lindo para terminar así, y había invertido una cantidad enorme de tiempo para llegar a ese punto. Juntando los pedazos nació el proyecto ADX-rp2040, pero eso es historia para la próxima entrada.
No hay comentarios:
Publicar un comentario