Frambuesa Pi RP2040: Manos

El lanzamiento de la placa Raspberry Pi Pico de la Fundación Raspberry Pi con microcontrolador RP2040 ha causado gran revuelo estos últimos meses en la comunidad de fabricantes. Muchos han demostrado cómo se pueden utilizar especialmente los dos periféricos de máquina de estado de E/S programables (PIO) para crear generadores de vídeo DVI y otros periféricos digitales.

Junto con este entusiasmo, surge la pregunta de si algo de esto causará algún trastorno importante para aquellos de nosotros que usamos STM32, SAM y otras MCU basadas en Cortex-M. ¿Sería quizás el RP2040 una opción válida para algunos de nuestros proyectos? Dado que el RP2040 es un MCU con procesador dual Cortex-M0+, parece justo compararlo cara a cara con las ofertas de uno de los pesos pesados ​​actuales en el espacio de MCU ARM de 32 bits: ST Microelectronics.

¿La Fundación Raspberry Pi logró mostrar a los ingenieros de ST cómo se hace, o deberían los primeros revisar algunas de sus suposiciones? ¿Y qué tan difícil será portar código de bajo nivel de STM32 a RP2040?

En pocas palabras, después de que el RP2040 me llamó la atención, pensé que podría ser interesante intentar portar mi marco STM32 basado en C++ a esta nueva MCU. Sin embargo, no tanto para los núcleos duales Cortex-M0+, ya que tengo MCU STM32H7 de doble núcleo (M4 y M7) por ahí que superarán fácilmente el relleno de un RP2040 con más E/S de sobra. Lo que más me intrigó fue este periférico de máquina de estado (PIO) en el RP2040 que parecía digno de una mirada más cercana.

Según mi experiencia con STM32, pensé que podría transferir rápidamente algunos archivos, crear una nueva rama de arquitectura 'RP' en el proyecto y comenzar a competir. Cortex-M es Cortex-M, ¿verdad? El procedimiento habitual con una nueva MCU basada en ARM es obtener las hojas de datos, el manual de referencia y los archivos del dispositivo CMSIS. Después de esto, se puede adaptar fácilmente el código de bajo nivel para usar el nuevo diseño de registro y nombres de periféricos, mientras que los dispositivos de nivel central (SysTick, NVIC, etc.) permanecen igual.

Quizás ingenuamente, hice un pedido de una placa Raspberry Pi Pico antes incluso de comprobar la compatibilidad con CMSIS o de echar un vistazo al manual de referencia. Para mi sorpresa, descubrí que el soporte CMSIS o incluso la interoperabilidad con el resto del ecosistema Cortex-M aún no estaba en el radar. Aún así, el archivo SVD para la MCU RP2040 se proporciona en el 'Pico SDK', que se puede utilizar para generar el encabezado del dispositivo. Gracias a los esfuerzos de Chris Hockuba para iniciar CMSIS con el RP2040, finalmente encontré una solución que funcionaba juntos.

Con un proyecto STM32, se requieren algunos elementos para que un proyecto básico funcione en una MCU de destino. Estos incluyen el código de inicio que realiza algunas configuraciones básicas del entorno, así como la tabla de vectores para los manejadores de interrupciones. También existe el script del vinculador para garantizar que todos los bits terminen en el desplazamiento de memoria correcto. Todo esto es bastante mínimo, ya que la MCU, al arrancar, carga la imagen del firmware desde Flash ROM en la dirección predeterminada.

El primer obstáculo con el RP2040 es comprender su proceso de cargador de arranque encadenado. Al igual que con los disquetes de arranque de antaño, o un HDD/SSD en una PC, la MCU trata la ROM flash QSPI externa esencialmente como un dispositivo de arranque potencial. El cargador de arranque de primera etapa está integrado en la MCU en la ROM de arranque, dirección 0x0000 0000, que al arrancar verifica la interfaz QSPI para intentar cargar 256 bytes desde ella. Se verificará si hay una coincidencia de hash CRC32 válida y se asumirá que es el gestor de arranque de segunda etapa si coincide.

Hay muchas cosas que este gestor de arranque de segunda etapa podría hacer y algunas son necesarias. Baste decir por ahora que, en comparación con algunos clones STM32 famosos, como los clones STM32 I-can't-believe-it-not-a-genuine-STM32 de GigaDevices, que también usan ROM SPI, todo este proceso con el RP2040 es no es tan intuitivo, bien documentado o transparente como podría ser, y tiene muchos obstáculos.

Me tomó bastante investigar la hoja de datos del RP2040 y preguntar para descubrir cómo el administrador de reloj periférico en STM32 se asigna a la arquitectura del sistema RP2040. Resulta que la versión del RP2040 se llama RESETS y funciona básicamente a la inversa: hay que desarmar la condición de reinicio en un bloque para habilitar el reloj. Para habilitar el reloj GPIO, debe alternar el bit 8 en RESETS_RESET (PADS_BANK0).

Una vez resuelto, miré la sección de periféricos GPIO en la documentación (sección 2.19). Una cosa es evidente de inmediato: es completamente diferente del STM32, AVR, SAM y la mayoría de los demás periféricos GPIO que he visto.

Si bien la mayoría de los chips tienen uno o dos registros por función, y usted cambia bits en ellos para activar esa función para un pin en particular, el RP2040 tiene un registro por pin y usted cambia bits a un lugar que dicta la función. Es una elección única y tuve que escribir un código personalizado para buscar la dirección de memoria de los registros de control para cada pin.

Después de hacer todo este esfuerzo, seguramente funcionará, ¿verdad?

Como se mencionó anteriormente, el gestor de arranque de la segunda etapa debe ubicarse al principio de la imagen del firmware. Como pensé que tenía que ser un código genérico, simplemente tomé el código ASM listo para usar que escupió el PicoSDK oficial mientras construía el ejemplo de Blinky. Con esto agregado al puerto RP2040 Nodate, el ejemplo de Blinky se creó sin problemas.

Actualizar el binario ELF resultante al RP2040 fue el siguiente desafío, ya que no hay un adaptador SWD estilo ST-Link integrado en la placa Raspberry Pi Pico y, como MCU Cortex-M de doble núcleo, requiere un SWD multipunto. adaptador. Hasta ahora, los únicos adaptadores SWD multipunto que tengo están integrados en placas Nucleo STM32H7. Por lo tanto, decidí utilizar la bifurcación OpenOCD personalizada creada por la Fundación Raspberry Pi y ejecutarla en un SBC Raspberry Pi.

Con todo eso en su lugar, actualicé exitosamente el firmware al RP2040 y… no obtuve absolutamente nada. Tras una inspección superficial, pareció que el código nunca pasó del cargador de arranque inicial ni entró en el firmware real en la ROM SPI. Si esto se debe a un problema relacionado con el gestor de arranque ASM de la segunda etapa, algo en los archivos experimentales CMSIS RP2040 que tuve que tomar prestados de los esfuerzos de otra persona, o debido a algo completamente diferente, es difícil decirlo en este momento.

Después de pasar bastantes horas haciendo que el RP2040 básico funcione utilizando CMSIS improvisados ​​y archivos del gestor de arranque de segunda etapa, parecía el momento adecuado para dar unos pasos atrás y reevaluar. Desde mi evaluación inicial del RP2040, la solicitud de función CMSIS en el rastreador Pico SDK se ha actualizado felizmente con la sugerencia de que se puede agregar soporte CMSIS oficial con la versión 1.2.0 de Pico SDK.

Creo que tiene sentido que cualquiera que quiera familiarizarse con el RP2040 utilizando herramientas estándar de la industria espere este lanzamiento. Una vez que caiga, probablemente terminaré revisando primero el ejemplo de Nodate Blinky y luego, finalmente, revisaré el periférico PIO. Después de leer sobre su arquitectura de máquina de dos estados, parece bastante interesante. No es tan poderoso como CPLD o FPGA, pero sigue siendo extremadamente útil.

La 'hoja de datos' única del RP2040 (más un manual de referencia y una hoja de datos combinados) parece olvidar a veces que se supone que cubre la MCU y se desviará para convertirse en un tutorial de Pico SDK. Si bien es útil para quienes desean utilizar el SDK, decididamente es menos útil para quienes escriben su propia implementación.

Desde el complicado periférico GPIO, el complicado proceso de arranque de múltiples núcleos y el obstáculo adicional de tener que integrar un gestor de arranque de segunda etapa junto con una ROM externa no transparente, gran parte de esto es bastante irritante. Querrás utilizar el SDK oficial.

Es posible que una vez que uno se acostumbre a estas opciones de diseño, no se sienta tan discordante. O tal vez sea sólo una cuestión de incorporar el RP2040 a la cadena de herramientas estándar. Después de todo, cada nueva MCU es una experiencia de aprendizaje.