Proyecto ADX-rp2040

En la entrada anterior compartí la historia inicial del proyecto ADX-rp2040, naciendo como una evolución de mejoras para el firmware ADX original, el darse cuenta que la arquitectura Arduino no permite grandes agregados, la búsqueda de un reemplazo utilizando el Raspberry Pi Pico (rp2040) con ese propósito y los esfuerzos para generar una versión común para ambos.

El esfuerzo resultó esteril en cuanto a resultados por lo que terminé con cierta frustración luego de varios meses de trabajo. 

Pero a poco de pensar sobre la cuestión me di cuenta que era solo una cuestión táctica sobre el camino elegido (que resultó incorrecto) y no estratégica (utilizar un procesador rp2040).

En efecto, la plataforma rp2040 que mueve la placa Raspberry Pi Pico es un orden de magnitud mas poderosa que la plataforma Atmel328p que mueve la Arduino; carece entonces de sentido hablar en términos de agregar funciones que no entran bien en una placa (o directamente no entran) y tener que restringirse en las dos placas con una implementación híbrida cuyoo único propósito es mantener compatibilidad.

La esencia del proyecto es contar con un transceiver "simple" para HF que sea capaz de operar en FT8 (u otros modos digitales de baja señal) siendo alimentado por el audio generado por el programa WSJT-X (u otro similar) corriendo en una PC convencional.

Como comenté en la entrada anterior la portabilidad del código se logra adoptando las librerías de Earle Philhower (ver entrada anterior) denominado tambien "Arduino pico core" por lo que el firmware de ADX compila con modificaciones muy menores para el procesador rp2040.

Hay solo dos modificaciones significativas, ambas devienen de diferencias en la arquitectura de hardware. Una, la ausencia de EEPROM en el rp2040, tiene una solución mas o menos a mano, las librerías del Arduino pico core preveen formas de emular memoria EEPROM en memoria Flash (con algunas limitaciones) de tal manera que las instrucciones relacionadas con EEPROM compilen y operen correctamente. La segunda diferencia, mucho mas significativa, es la ausencia de una interrupción que permita contar cruces por cero de una señal analógica en el rp2040.

Eso afortunadamente estaba resuelto desde el "fallido" proyecto PDX, y de cuatro formas diferentes, por lo que solo era cuestión de elegir.

Y en efecto, como parte de una filosofía diferente en el cual muchas opciones eran alternativamente incluidas o excluidas mediante configuración, esta implementación hace estrictamente lo que hace el firmware original del ADX (tomando como base el correspondiente a ADX_UnO_1.1) sin alternativas u opciones de ningún tipo, con la excepción de aquellas partes del código que debían cambiarse por diferencias de arquitectura. La razón para tomar la versión de firmware ADX_UnO_1.1 en lugar de la previamente adoptada ADX_QUAD_V1.1 es que el primero tiene menos dependencias de hardware al no tener que soportar la placa QUAD (multibanda) e implementandose en un diseño monobanda, el cual es mas simple. Eso lleva a un código extremadamente simple, tan conciso como el original de ADX. Se sigue requiriendo adaptar el método de conteo de frecuencia, central al funcionamiento del firmware, para lo cual se toma ventaja de una característica única de la arquitectura rp2040 que consiste en disponer además del procesador principal (de dos nucleos) de 16 procesadores RISC independientes (PIO) capaces de almacenar programas cortos (firmware) pero potentes especializados en operaciones de I/O. Ese firmware se "carga" automáticamente a poco de arrancar el procesador mediante una serie de instrucciones especiales. Esos procesadores a traves de ciertos recursos de comunicación entre procesos pueden interactuar con el código principal De esa forma un procesador PIO (Peripherical I/O) se encarga de medir el tiempo entre pulsos consecutivos en la entrada para que luego el programa principal con una cuenta simple pueda calcular la frecuencia y con ello operar las etapas de RF para lograr la síntesis directa de la señal PSK.

El código resultante lo denominé ADX-rp2040 (sitio Github) y mi compromiso es mantener al mismo con funcionalidades similares al ADX de base operando en la plataforma Arduino, pero sin funciones adicionales (bueno, no muchas mas al menos). 

La única diferencia a ese criterio es que  el firmware ADX tiene una función de "calibración" del DDS (Si5351) que permite con la ayuda de instrumentos establecer cual es la corrección que debe realizarse en un chip en particular para que su frecuencia se exacta, la diferencia puede ser de unas pocas decenas de Hz. El ADX logra eso colocando una salida del Si5351 (CLK2) no utilizada con otro propósito en 1 MHz, y luego ir manualmente variando lentamente la frecuencia hasta que externamente se detecte que la frecuencia es realmente 1 MHz, a la corrección necesaria para lograr esa condición se la graba en EEPROM y se la aplica cada vez que arranca el código. En ADX-rp2040 es mucho mas facil directamente medir la frecuencia del CLK2 con el procesador rp2040 (dada su mayor potencia) por lo que no son necesarios instrumentos externos, simplemente en modo calibración el firmware puede hacer toda la operación e ir realizando las correcciones de manera que el error sea +/-2 Hz en forma automática.

Ahora bien, el firmware es todo lo parecido al original de ADX que es materialmente posible, pero el hardware tiene que ser modificado respecto a una placa ADX para funcionar correctamente.

La principal diferencia es obviamente que el Atmel328p y el rp2040 no son compatibles pin por pin, por lo que hay hacer un ruteo general de puertos. La segunda diferencia es que la placa Arduino se alimenta con +12Vcc y un regulador interno provee los +5Vcc para que opere el procesador, esa misma tensión es aprovechada para que el resto de la lógica de la placa funcione pues su consumo es suficientemente bajo para que eso sea posible. El rp2040 funciona con +3.3Vcc y debe ser alimentado por +5Vcc por lo que es necesario un regulador de tensión externo para bajar de +12Vcc a +5Vcc y de alli alimentar al procesador. Finalmente, los puertos de I/O requieren lógica de +3.3Vcc y no de +5Vcc, por lo que hay que tomar medidas para que no lleguen tensiones incorrectas, afortunadamente los tres botones push que tiene la placa ADX pueden ser alimentados con "pull-up" interno con lo que con solo no poblar las resistencia externas de pull-up. Finalmente, la forma de contar frecuencia se beneficia mucho con disponer de pulsos mas netos (mas "cuadrados") que la señal de audio senoidal, de esta forma pasado un umbral se hace innecesario la calibración de los niveles de medición y para ello por lo que se utiliza un comparador con ese propósito de forma que la señal sea encendido o apagado en forma neta. En realidad se usan dos, seleccionables, uno simple basado en MOSFET y otro mas sofisticado basado en comparador. Ambos funcionan muy bien.

Finalmente está la tarea de construir el transceiver. Obviamente que puede encararse como un proyecto de complejidad media simplemente cableando las conexiones de todo el circuito; pero uno de los grandes atractivos del proyecto ADX es su simplicidad, la que en buena medida se basa en disponer de una placa de circuito impreso relativamente económica que se puede mandar a fabricar para luego simplemente poblar unos cuantos componentes mas o menos simples y tener un circuito que salvo errores mayores sale andando siempre. Está también la cuestión de contemplar a quien ya tiene una placa ADX, realmente no tiene gran incentivo para construir una placa como la necesaria para operar el firmware ADX-rp2040 para hacer mas o menos lo mismo que puede hacer con el ADX. Obviamente que la solución de fondo es hacer una placa completamente nueva que evolucione desde la ADX original con los cambios necesarios. Pero al mismo tiempo al ADX-rp2040 es un primer paso en un proyecto mas ambicioso y por lo tanto es probable que vaya mutando con el tiempo. Resultó una idea interesante hacer una "placa-hija" (daughterboard) como la mostrada en la foto, donde toda la circuitería adicional se solucione en ella y que presente un pinout idéntico al del Arduino Nano. Por lo que es posible enchufar la misma en una placa ADX estandar y operar el firmware ADX-rp2040. Es decir una forma de acceder al nuevo procesador y eventualmente a su camino de evolución protegiendo el trabajo hecho hasta el momento con la placa ADX. El diseño de esa placa lo realizó Barb (WB2CBA) y los archivos de diseño para su construcción (Gerber) se encuentran disponibles en el sitio GitHub del proyecto ADX-rp2040.  Si luego, en el tiempo, el diseño prospera y se estabiliza quizás exista una masa crítica de interesados en una placa que sea nativa del rp2040, lo que implica sacar el diseño circuital del Arduino Nano y agregar lo que tiene la placa original del daughterboard (¿ADX+?).

El proyecto empieza a tomar forma, lo suficiente para poner manos a la obra y comenzar la siguiente fase, el RDX.