- El RP2040 destacaba por PIO, DMA y overclock, pero por limitaciones en rendimiento de CPU, RAM, GPIO, recursos de PIO y falta de QSPI PSRAM, en algunos proyectos había que pasarse al STM32H7, y el RP2350 cubre gran parte de ese hueco
- El RP2350 ofrece doble Cortex-M33F, soporte de coma flotante, instrucciones personalizadas para acelerar matemáticas de doble precisión, el doble de RAM y opción de núcleo RISC-V; en varios proyectos se usó de forma estable a 300MHz
- El PIO puede usar su FIFO como si fuera memoria para lecturas y escrituras arbitrarias, y gracias a 3 PIO, interrupciones entre PIO y un DMA mejorado, ahora es posible implementar incluso un Sony Memory Stick slave y un SDIO slave
- La QSPI PSRAM permite lectura, escritura y caché, y pruebas de memoria que en STM32H7 se colgaban o crasheaban siguieron ejecutándose en RP2350; además, se volvió sencillo añadir 16MB de RAM a una placa manual de 2 capas
- El primer proyecto público con RP2350, la DEFCON 32 badge, mostró un emulador de Game Boy y la ejecución de PalmOS; además, RP2354A/RP2354B ofrecen 2MB de flash en el encapsulado, el mismo pinout y una variante expandida de 80 pines GPIO
Lo que faltaba en el RP2040 y las mejoras deseadas
- El RP2040 fue un microcontrolador usado en varios proyectos, especialmente por sus fortalezas en PIO, un DMA bien diseñado y su gran capacidad de overclock
- La combinación de PIO y DMA se usó para implementar lo siguiente
- Drivers de pantalla avanzados
- Placas que funcionan como un bus completo de sistema con RAM y ROM
- Configuraciones conectadas al procesador MC68328
- Las carencias del RP2040 se concentraban en los recursos de periféricos y la escalabilidad de memoria
- Modo de transferencia infinita en DMA sin desperdiciar otros canales
- Más canales DMA
- Más registros para guardar variables temporales en las state machines de PIO
- Más unidades PIO
- Más de 32 slots de instrucciones por cada PIO
- Más GPIO
- La alta frecuencia ayudaba sobre todo a disimular las limitaciones del núcleo Cortex-M0+, y se considera que un mejor núcleo, como un Cortex-M4F, habría sido más favorable para cargas de trabajo con coma flotante o SIMD ligero
- El soporte para QSPI PSRAM y más RAM también eran deseos importantes
Experiencia con QSPI RAM en STM32H7 y comparación
- En algunos casos de uso fue necesario usar STM32H7 en lugar de RP2040, pero quedó una fuerte desconfianza por los bugs del STM32H7 y la forma en que STMicro manejó las errata
- En el soporte de QSPI RAM del STM32H7 aparecieron los siguientes problemas
- Si se escribía sin caché, se perdían escrituras
- Si se activaba la caché, se escribía basura aleatoria alrededor de algunas escrituras de 1 byte
- Si se ejecutaba código desde PSRAM, tras miles de millones de accesos se colgaba todo el chip y ni siquiera se podía conectar el depurador
- Aunque se reportó el problema y se entregó una demo, la respuesta de STMicro no fue suficiente
- Se encontraron soluciones alternativas, pero consumían entre 7% y 10% de rendimiento, reduciendo la utilidad del chip
Mejoras cumplidas en el RP2350
- Durante el último año, con ayuda de Raspberry Pi, se usaron muestras del RP2350 para reportar bugs y hacer sugerencias, comprobando cómo mejoraban los casos de uso del RP2040
- El núcleo y el rendimiento de cómputo mejoraron mucho
- Incluye 2 núcleos Cortex-M33F
- Soporte de coma flotante
- Instrucciones personalizadas que aceleran matemáticas de doble precisión más allá de la precisión simple típica del Cortex-M33F
- Las operaciones de doble precisión no son single-cycle, pero rondan entre 2 y 3 ciclos por operación
- También se puede usar el núcleo RISC-V, aunque en proyectos reales se usó Cortex-M33
- En varios proyectos, ejecutar el RP2350 a 300MHz no causó problemas
- La RAM pasó a ser el doble que en el RP2040
Cambios en PIO y DMA
- El PIO del RP2350 puede usar su FIFO como memoria para lecturas y escrituras arbitrarias, lo que facilita configuraciones de PIO que antes eran difíciles por falta de variables temporales
- La cantidad de PIO en el chip aumentó a 3
- Ahora es posible enviar interrupciones entre PIO, lo que permite sincronización cross-PIO y configuraciones más complejas
- La combinación mejorada de PIO y DMA se usó en proyectos reales para implementar lo siguiente
- Sony Memory Stick protocol slave: los dispositivos lo reconocen como si fuera un Memory Stick real
- SDIO slave device: los dispositivos probados lo reconocen como un dispositivo SDIO
- El DMA también fue mejorado en persistencia de transferencia y control de direcciones
- Permite transferencia infinita sin usar otro canal
- Aumentaron las formas de ajustar la dirección de memoria en cada acceso
- Además de "misma dirección" o "incrementar según el tamaño de acceso" del RP2040, se añadieron opciones de decremento y de incremento con otros tamaños
Soporte de QSPI PSRAM
- El RP2350 soporta QSPI PSRAM y permite lectura y escritura
- También ofrece caché y funciona correctamente
- Pruebas de memoria que en STM32H7 se colgaban o crasheaban siguieron ejecutándose en RP2350, sin pérdida de datos ni bloqueos del chip
- Las combinaciones posibles son las siguientes
- 1 flash + 1 PSRAM
- 2 flash
- 1 boot flash + 2 PSRAM en tiempo de ejecución
- También funcionó sin problemas una configuración con VTOR, SP y PC todos en PSRAM, recibiendo interrupciones mientras se ejecutaban muchas instrucciones LDM/STM dirigidas a PSRAM
- La configuración requiere apenas 3 líneas de código C, y también se volvió sencillo añadir 16MB de RAM a una placa ensamblada a mano de 2 capas
- La placa de muestra inicial del RP2350, la Pi Pico 2, no tenía footprint para PSRAM, así que la PSRAM se soldó en modo dead-bug, pero aun así funcionó a full speed
Ventajas conservadas y experiencia de desarrollo
- Al pasar de RP2040 a RP2350, se mantuvo la calidad del diseño y la documentación de los periféricos
- Se considera que los periféricos funcionan tal como prometen
- El SDK es claro y conciso, y no hace falta descargar herramientas pesadas tipo Cube/HAL
- El código no es macro hell y funciona bien
- La placa de desarrollo RP2350 de Raspberry Pi es compatible con rPiPico, y fue fácil portar varios proyectos al PiPico 2
Primer proyecto público con RP2350: DEFCON 32 badge
- Uno de los proyectos públicos con RP2350 es la DEFCON 32 badge
- El hardware fue desarrollado por Entropic Engineering y el firmware es un port del pequeño emulador de Game Boy uGB
- Los 2 núcleos se reparten funciones
- Un núcleo usa instrucciones SIMD del Cortex-M33 para escalar la pantalla de Game Boy a 1.5x
- El otro núcleo maneja la emulación, la UI y el resto del trabajo
- Los juegos válidos de Game Boy funcionan en tamaños de hasta 2MB, y si se instala un chip flash más grande, también se pueden usar juegos mayores
- Los juegos de Game Boy precargados fueron hechos por el equipo de DEFCON
- En esta badge, el chip se configuró de forma conservadora a 125MHz
- No hubo mucho tiempo de prueba, y la producción pasó de 10 unidades a 28,000 sin etapas intermedias, sin plan B
- El reloj máximo de la pantalla era 62.5MHz, y como lo alimenta una state machine de PIO, el reloj de pantalla debía ser un múltiplo entero del reloj del sistema
Ejecución de PalmOS y firmware
- El mismo hardware de la DEFCON 32 badge también puede ejecutar la versión completa de PalmOS mediante el rePalm project
- La badge base no llevaba PSRAM instalada, pero PalmOS funciona
- La memoria queda justa, pero funcionan infrared beaming, SD card, juegos simples, memo pad, audio y más
- Si se instala un chip PSRAM AP Memory de 64Mbit, se puede usar una segunda imagen y, con más memoria, cargar juegos o reproducir MP4 en tiempo real mediante TCPMP
- Las imágenes de firmware están en la documentación; se copian a la SD card con el nombre
FIRMWARE.BINy se cargan seleccionandofirmware updateen el menú del botónFN - La restauración del stock firmware es posible desde cualquier computadora mediante USB y el UF2 protocol, y la stock image también se puede descargar desde el mismo documento
RP2354 y más GPIO
- La conclusión fue que ya es posible replantear proyectos de STM32H7 usando RP2350
- Frente a la crítica de que el RP2350 requiere SPI flash externa, existen las variantes con flash integrada RP2354A y RP2354B
- RP2354A/RP2354B incluyen 2MB de flash dentro del encapsulado
- El pinout es igual al del RP2350A/B
- También hay una variante en encapsulado de 80 pines que ofrece más GPIO
Divulgación de intereses
- No se recibió compensación económica ni ningún pago por este texto
- Nadie pidió que se escribiera, ni hubo aprobación de ningún tipo
- El acceso anticipado al RP2350 no estuvo condicionado a hablar públicamente de forma positiva ni a hacer declaraciones específicas
1 comentarios
Comentarios de Hacker News
Durante los últimos años he estado desarrollando un driver de motor brushless basado en RP2040, y este anuncio realmente me entusiasma
El módulo del driver puede manejar hasta 53V, 30A continuos y 50A pico. Recientemente separé el driver en un módulo aparte, lo cual es útil para robots agrícolas y también es importante para probar el driver mientras mejoro el diseño. Esta revisión se ve bastante estable, así que quizá pronto pueda hacer un driver integrado de 1 motor en una sola placa y de bajo costo con RP2350. En el RP2040 la velocidad del loop era de 8 kHz y eso es suficiente para los motores de tracción de robots agrícolas grandes, pero entre los drivers de alto rendimiento que usan punto flotante hay algunos que alcanzan una velocidad de loop de 50 kHz
La placa está ejecutando SimpleFOC, y en el foro se había hablado de hacer un diseño insignia. Pero como se necesita control sensorless y soporte de punto flotante, usando la nueva variante de pinout grande del RP2350 con 8 pines ADC se podrían medir 3 señales de corriente y 3 voltajes del puente para hacer un driver sensorless decente. Tomará unos meses más antes de que el diseño esté listo, pero para novedades pueden ver el repositorio de Git o el perfil de Twitter
https://github.com/tlalexander/rp2040-motor-controller
https://twitter.com/TLAlexander
Me encanta que use piezas de bicicleta en las patas y ruedas
Ya existen MCU dedicados con periféricos específicos, notas de aplicación y ejemplos de código para control BLDC con sensor/sensorless, y no me parece que el RP2040 sea un chip especialmente bien preparado para este trabajo
Me recuerda cuando de niño desarmaba carritos de juguete y les sacaba el motor, sintiendo que había logrado algo
Me costaba imaginar usar el RP2040 en un producto real, pero el RP2350 corrige muchas de mis quejas, así que me entusiasma lo suficiente como para querer probarlo
El RP2040 también tenía muchas virtudes. TBMAN es un concepto genial y hace overclock increíblemente bien. PIO es realmente revolucionario, y tiene mucho valor para muchas empresas que quieren reemplazar cosas tipo 8051 con un núcleo Arm en formato daughterboard
Pero por cada cosa genial también había algo decepcionante. Tiene velocidad de reloj de nivel DSP, pero no tiene FPU ni división entera por hardware. Tampoco es deseable que una MCU sin protección de memoria incluya USB DFU en la ROM de arranque. En SDK de terceros como Zephyr, el soporte para PIO es extremadamente limitado, así que su utilidad baja en proyectos grandes
El RP2350 resuelve casi todas esas quejas, así que tengo muchísimas ganas de verlo. Aun así, si hay que implementar periféricos comunes como CAN o SDMMC con PIO, enseguida queda en desventaja. La flexibilidad es excelente, pero cuando necesitas sacar un producto rápido no quieres estar metiéndote con un lenguaje ensamblador de propósito especial. Al final, si ofrecieran bibliotecas de periféricos por software ya preparadas para funciones comunes como SD/MMC, MII o Bluetooth HCI, sería mucho más fácil integrarlo con Zephyr y similares, y eso ampliaría mucho el alcance de uso del chip
Puede mejorar todavía más, pero ya está bastante cerca de algo “listo para usar”
PIO es una gran ventaja, y me alegra ver que en la nueva versión reforzaron todavía más esa dirección. La gente ya ha desarrollado drivers PIO para varios periféricos como CAN y WS2812, así que se parece bastante a lo que esperabas
Lo mismo con operación autónoma de periféricos, amplificadores operacionales, comparadores y temporizadores de captura/comparación. Zephyr intenta ofrecer interfaces comunes como un sistema operativo de escritorio, pero eso no encaja bien en el mundo embebido. En escritorio muchas veces basta con el mínimo común denominador, pero en embebido a menudo eliges una plataforma justamente por esas funciones no comunes
Entre las razones para elegir RP2040 estaba la filosofía de diseño, pero después de la escasez de chips también pesó mucho que era fácil de conseguir
En la práctica hay “ejemplos”, y estaría mejor si ese tipo de cosas se ofrecieran como soporte de primera clase
Las especificaciones se pueden ver aquí: https://www.digikey.ca/en/product-highlight/r/raspberry-pi/r...
Basado en el RP2350 diseñado por Raspberry Pi en el Reino Unido: doble Arm M33 a 150MHz con FPU, 520KiB de SRAM, funciones de seguridad como arranque firmado, OTP, SHA-256, TRNG, detector de glitches y Arm TrustZone for Cortex-M, CPU dual RISC-V Hazard3 opcional a 150MHz, operación de bajo consumo, 3 PIO v2 y 12 máquinas de estado para soporte de periféricos personalizados, soporte para PSRAM, interfaz flash QSPI XIP externa más rápida, 4MB de flash QSPI integrada, GPIO tolerante a 5V, SDK open source de C/C++ y soporte para MicroPython, compatibilidad de software con Pico 1/RP2040, programación drag and drop mediante almacenamiento masivo USB, módulo con castellations para soldarlo directamente a una carrier board, mismo footprint y compatibilidad de pines que Pico 1, 26 GPIO multifunción incluyendo 3 entradas analógicas, temperatura de operación de -20°C a +85°C, voltaje de entrada de 1.8VDC a 5.5VDC
Después vi que en la sección 14.8.2.1 aparecen dos tipos de pines digitales, “Standard Digital” y “Fault Tolerant Digital”, y parece que los pines FT Digital son los tolerantes a 5V
Es un gran día para el equipo de Pigweed
Parte de su trabajo se mencionó en el anuncio principal del RP2350/Pico 2 [1], pero durante los últimos meses han estado trabajando en un nuevo SDK end-to-end [2] construido sobre Bazel [3], con soporte tanto para RP2040 como para RP2350. También incluye el trabajo para llevar soporte de Bazel upstream al Pico SDK. El nuevo “Tour of Pigweed” [4] muestra varias funciones de Pigweed trabajando juntas en una sola base de código, como builds herméticos, pruebas unitarias en dispositivo, comunicación centrada en RPC y pruebas de fábrica sobre el escritorio. Reciben preguntas en Discord [5]
[1] https://www.raspberrypi.com/news/raspberry-pi-pico-2-our-new...
[2] https://opensource.googleblog.com/2024/08/introducing-pigwee...
[3] https://blog.bazel.build/2024/08/08/bazel-for-embedded.html
[4] https://pigweed.dev/docs/showcases/sense/
[5] https://discord.gg/M9NSeTA
Se nota la diferencia cuando todo queda integrado de forma hermética y el workflow se resume a un solo comando de Bazel
Me sorprende que la presentación de Pigweed no mencione nada de eso
Ojalá en el ecosistema de microcontroladores dejaran Java fuera
Es la primera vez que veo un diseño donde puedes elegir entre núcleos Arm y núcleos RISC-V en el mismo die
Me pregunto si eso afectará el precio y el consumo de energía. El núcleo Hazard3 es opcional, y al arrancar se puede elegir correr a 150MHz con el par de núcleos Arm Cortex-M33 incluido o con el par de núcleos Hazard3. Más atrevido todavía, también se puede correr uno RV y uno Arm al mismo tiempo
Hazard3 es un diseño open source y su documentación está pública. Es una máquina RV32IMACZb* ligera de 3 etapas y ejecución en orden, con soporte para la ISA base RISC-V de 32 bits, multiplicación y división por hardware, instrucciones atómicas, manipulación de bits y más
Eben Upton lo explicó así: “se puede elegir al arrancar. Cada puerto que entra al bus fabric puede conectarse mediante un mux a un M33 o a un Hazard3. Si quieres ponerte geek, incluso puedes correr uno de cada uno”
Fuente: https://www.theregister.com/2024/08/08/pi_pico_2_risc_v/
En la práctica, el área que ocupan los núcleos de instrucciones suele ser bastante pequeña comparada con los periféricos o la memoria interna
Permite validar tanto la parte técnica como la aceptación del mercado a un costo mucho menor que hacer un tape-out nuevo para un chip separado
Está muy bien que puedas elegir un RISC-V completamente open source si quieres. Supongo que el núcleo RV será más lento por ciclo de reloj que el M33, y esperaría que el M33 saque mejores resultados en benchmarks. Eso sería por el pipeline de 3 etapas de Hazard3, aunque el M33 también es de 3 etapas. Quedo a la espera de los benchmarks
Publicación oficial de noticias: https://news.ycombinator.com/item?id=41192341
Página oficial del producto: https://news.ycombinator.com/item?id=41192269
Doom fue porteado al RP2040: https://kilograham.github.io/rp2040-doom/
El RP2350 parece capaz incluso de ejecutar Quake. Algunos cambios se sienten casi como si hubieran sido diseñados con ese propósito. Tiene FPU, doble núcleo a 150MHz, posibilidad de overclock por encima de 300MHz y soporte para hasta 16MB de PSRAM con paginación de lectura/escritura por hardware
No me gusta que la placa de desarrollo use micro-USB. Incluso en 2024
Fuera de eso, es excelente y es justo el tipo de producto necesario para competir con los grandes fabricantes ya establecidos
Está bien que los productos modernos sean todos USB-C, pero como todavía sobran muchos cables micro-USB, no molesta tanto que el Pico oficial y el Pico 2 usen micro-USB. Está bueno tener opciones para elegir el puerto que quieras según el proyecto
El chip de interfaz también tiene que ser más complejo, así que probablemente sea más caro. En AliExpress todavía hay muchos dispositivos baratos que usan micro-USB, así que seguramente sigue habiendo demanda. Dependiendo del público objetivo, incluso se podría convertir la placa de desarrollo tal cual en un producto de consumo
Es un poco inesperado que el segundo microcontrolador de una empresa joven, que parece orientada al consumidor, tenga tanta seguridad
Al principio sentí que era difícil confiar en la seguridad por falta de experiencia. Pero los microcontroladores seguros de fabricantes “experimentados” también tienen muchos fallos de seguridad conocidos, y más importante aún, a veces se ha visto que intentan tapar esos problemas. Haber hecho dos auditorías de arquitectura de seguridad, ofrecer una recompensa de 10 mil dólares por bugs y diseñar una placa para glitching como una credencial de DEF CON muestra un compromiso bastante grande con la seguridad. También me da curiosidad cómo funciona el Redundancy Coprocessor. Aun así, no me sorprendería que alguien lograra romper al menos una parte
Lo de orientada al consumidor va más por percepción; en términos de ventas y suministro, parece que han priorizado a los usuarios industriales
Todavía no encuentro un anuncio oficial ni la hoja de datos, pero según esta publicación, parece un gran salto frente al RP2040
2× Cortex-M33F, DMA mejorado, más PIO y mejores, soporte para PSRAM externa, 2MB de flash interna y una variante de 80 pines, RAM duplicada a 512KiB, y parece incluir algunos núcleos RISC-V. Puede que sean para bajo consumo