- O RP2040 tinha como pontos fortes PIO, DMA e overclock, mas, por causa do desempenho do núcleo, da RAM, dos GPIOs, dos recursos de PIO e da falta de QSPI PSRAM, em alguns projetos era preciso migrar para o STM32H7; o RP2350 cobre boa parte dessas lacunas
- O RP2350 oferece dois Cortex-M33F, suporte a ponto flutuante, instruções customizadas para acelerar matemática de dupla precisão, o dobro de RAM e opção de núcleos RISC-V, tendo sido usado de forma estável a 300 MHz em vários projetos
- O PIO pode usar FIFOs como memória, com leituras e escritas arbitrárias; com 3 PIOs, interrupções entre PIOs e DMA aprimorado, tornou-se possível implementar até um slave de Sony Memory Stick e um slave SDIO
- A QSPI PSRAM funciona com leitura, escrita e cache; testes de memória que travavam ou davam crash no STM32H7 continuaram rodando no RP2350, e também ficou simples adicionar 16 MB de RAM a uma placa manual de 2 camadas
- O primeiro projeto público com RP2350, o badge da DEFCON 32, demonstrou um emulador de Game Boy e a execução do PalmOS; os RP2354A/RP2354B oferecem flash in-package de 2 MB, o mesmo pinout e uma variante com 80 pinos e mais GPIOs
O que faltava no RP2040 e as melhorias desejadas
- O RP2040 foi um microcontrolador usado em vários projetos, com destaque especialmente para PIO, DMA bem projetado e grande potencial de overclock
- A combinação de PIO e DMA foi usada nas seguintes implementações
- Drivers de display avançados
- Placas que se comportam como um barramento de sistema completo com RAM e ROM
- Configurações conectadas a um processador MC68328
- As limitações do RP2040 se concentravam em recursos de periféricos e expansibilidade de memória
- Um modo de transferência forever que não desperdice outro canal no DMA
- Mais canais de DMA
- Mais registradores para armazenar variáveis temporárias nas state machines de PIO
- Mais unidades de PIO
- Mais de 32 slots de instrução por PIO
- Mais GPIOs
- O clock alto servia em grande parte para mascarar as limitações do núcleo Cortex-M0+; a avaliação é que um núcleo melhor, como o Cortex-M4F, teria sido vantajoso para ponto flutuante ou cargas leves de SIMD
- Suporte a QSPI PSRAM e mais RAM também eram desejos importantes
Experiência com QSPI RAM no STM32H7 e comparação
- Em alguns casos de uso foi necessário usar o STM32H7 em vez do RP2040, mas permaneceu uma forte desconfiança em relação aos bugs do STM32H7 e à forma como a STMicro lida com errata
- No suporte a QSPI RAM do STM32H7, apareceram os seguintes problemas
- Sem cache, escritas eram perdidas
- Com cache ativado, lixo arbitrário era gravado ao redor de algumas escritas de 1 byte
- Ao executar código a partir da PSRAM, depois de bilhões de acessos o chip inteiro travava e nem o depurador conseguia se conectar
- O problema foi reportado e uma demonstração foi fornecida, mas a resposta da STMicro não foi suficiente
- Uma solução de contorno foi encontrada, mas ela consumia 7% a 10% de desempenho, reduzindo a utilidade do chip
Melhorias atendidas no RP2350
- Ao longo do último ano, com ajuda da Raspberry Pi, foram usados samples do RP2350, com relatos de bugs e sugestões, e foi possível verificar como os casos de uso do RP2040 melhoraram
- O desempenho dos núcleos e de computação melhorou muito
- Dois núcleos Cortex-M33F integrados
- Suporte a ponto flutuante
- Instruções customizadas que aceleram matemática de dupla precisão, além da single-precision normalmente oferecida pelo Cortex-M33F
- As operações de dupla precisão não são single-cycle, mas ficam na faixa de 2 a 3 ciclos por operação
- Também é possível usar núcleos RISC-V, mas nos projetos reais foram usados Cortex-M33
- Em vários projetos, executar o RP2350 a 300 MHz não causou problemas
- O tamanho da RAM ficou 2 vezes maior que no RP2040
Mudanças no PIO e no DMA
- O PIO do RP2350 consegue usar FIFOs como memória, permitindo leituras e escritas arbitrárias, o que facilita configurações de PIO que antes eram difíceis pela falta de variáveis temporárias
- O número de PIOs dentro do chip aumentou para 3
- Tornou-se possível transmitir interrupções entre PIOs, permitindo sincronização cross-PIO e configurações mais complexas
- A combinação de PIO e DMA aprimorados foi usada, em projetos reais, nas seguintes implementações
- Slave do protocolo Sony Memory Stick: os dispositivos o reconhecem como um Memory Stick real
- Dispositivo slave SDIO: os dispositivos testados o reconhecem como um dispositivo SDIO
- O DMA também foi reforçado em continuidade de transferência e controle de endereços
- Possibilidade de transferência infinita sem usar outro canal
- Mais formas de ajustar o endereço de memória a cada acesso
- Além de “mesmo endereço” ou “incrementar pelo tamanho do acesso” do RP2040, foram adicionadas opções de decremento e de incremento por outros tamanhos
Suporte a QSPI PSRAM
- O RP2350 oferece suporte a QSPI PSRAM, com leitura e escrita funcionais
- O cache também é fornecido e funciona corretamente
- Testes de memória que travavam ou davam crash no STM32H7 continuaram rodando no RP2350, sem perda de dados nem hang do chip
- As combinações possíveis são as seguintes
- 1 flash + 1 PSRAM
- 2 flashes
- 1 boot flash + 2 PSRAMs em runtime
- Configurações com VTOR, SP e PC todos na PSRAM, executando muitas instruções LDM/STM direcionadas à PSRAM enquanto recebem interrupções, também funcionam sem problemas
- A configuração exige apenas 3 linhas de código C, e adicionar 16 MB de RAM a uma placa de 2 camadas montada manualmente também ficou simples
- A placa sample inicial do RP2350, a Pi Pico 2, não tinha footprint para PSRAM, então a PSRAM foi instalada em estilo dead-bug; mesmo assim, funcionou em full speed
Vantagens mantidas e experiência de desenvolvimento
- Na transição do RP2040 para o RP2350, a qualidade do projeto e da documentação dos periféricos foi mantida
- A avaliação é que os periféricos funcionam conforme prometido
- O SDK é claro e conciso, sem necessidade de baixar ferramentas grandes no estilo Cube/HAL
- O código não é um macro hell e funciona bem
- A placa de desenvolvimento RP2350 da Raspberry Pi é compatível com rPiPico, e foi fácil portar vários projetos para a PiPico 2
Primeiro projeto público com RP2350: badge da DEFCON 32
- Um dos projetos públicos com RP2350 é o badge da DEFCON 32
- O hardware foi desenvolvido pela Entropic Engineering, e o firmware é um port do tiny emulador de Game Boy uGB
- Os dois núcleos são usados com papéis divididos
- Um núcleo usa instruções SIMD do Cortex-M33 para fazer upscale de 1,5x da tela do Game Boy
- O outro núcleo processa a emulação, a UI e o restante das tarefas
- Jogos válidos de Game Boy funcionam até 2 MB, e jogos maiores são possíveis se um chip flash maior for instalado
- O jogo de Game Boy pré-carregado foi escrito pela equipe da DEFCON
- Nesse badge, o chip usa um clock conservador de 125 MHz
- Não havia muito tempo de testes, a produção aumentou de 10 para 28.000 unidades sem uma etapa intermediária, e não havia plan B
- O clock máximo do display era 62,5 MHz e, como uma state machine de PIO o fornecia, o clock do display precisava ser um múltiplo inteiro do clock do sistema
Execução do PalmOS e firmware
- O mesmo hardware do badge da DEFCON 32 também consegue executar a versão completa do PalmOS por meio do projeto rePalm
- O badge básico não vinha com PSRAM instalada, mas o PalmOS funciona
- A memória é apertada, mas infrared beaming, cartão SD, jogos simples, memo pad, áudio etc. funcionam
- Ao instalar um chip AP Memory 64 Mbit PSRAM, é possível usar uma segunda imagem, e a memória adicional permite carregar jogos ou reproduzir MP4 em tempo real via TCPMP
- As imagens de firmware estão na documentação; coloque-as no cartão SD com o nome
FIRMWARE.BINe escolhafirmware updateno menu do botãoFNpara carregá-las - A restauração do stock firmware é possível a partir de qualquer computador via USB e protocolo UF2, e a stock image também pode ser baixada no mesmo documento
RP2354 e mais GPIOs
- A conclusão é que projetos STM32H7 podem voltar a ser planejados com o RP2350
- Para a observação de que o RP2350 precisa de flash SPI externa, existem variantes com flash integrada: RP2354A e RP2354B
- O RP2354A/RP2354B incluem 2 MB de flash in-package
- O pinout é o mesmo dos RP2350A/B
- Também há uma variante em encapsulamento de 80 pinos que oferece mais GPIOs
Declaração de interesses
- Não houve compensação financeira nem pagamento por este texto
- Não foi solicitado que o texto fosse escrito, nem houve qualquer aprovação
- O early access ao RP2350 não teve como condição fazer comentários positivos publicamente nem dizer algo específico
1 comentários
Comentários do Hacker News
Nos últimos anos, venho desenvolvendo um driver de motor brushless baseado no RP2040, então este anúncio me deixou muito empolgado
O módulo do driver consegue lidar com até 53 V, 30 A contínuos e 50 A de pico. Recentemente separei o driver em um módulo independente, o que é útil para robôs agrícolas e também importante para testar o driver durante melhorias no projeto. Esta revisão parece bastante estável, então talvez em breve eu possa fazer um driver integrado de baixo custo, em placa única, para 1 motor usando o RP2350. No RP2040, a velocidade do loop era de 8 kHz, suficiente para motores de tração de robôs agrícolas grandes, mas alguns drivers de alto desempenho que usam ponto flutuante chegam a uma velocidade de loop de 50 kHz
A placa roda SimpleFOC, e no fórum houve conversas sobre criar um projeto flagship. Porém, como é necessário suporte a controle sensorless e ponto flutuante, usar a nova variante de pinagem maior do RP2350, com 8 pinos ADC, permitiria medir 3 sinais de corrente e 3 tensões da ponte para criar um driver sensorless decente. Ainda levará alguns meses até o projeto ficar pronto, mas as novidades mais recentes podem ser vistas no repositório Git ou no perfil do Twitter
https://github.com/tlalexander/rp2040-motor-controller
https://twitter.com/TLAlexander
Gosto muito do fato de usar peças de bicicleta nos pés e nas rodas
Já existem MCUs dedicados com periféricos específicos, application notes e exemplos de código para controle BLDC com sensores/sem sensores, e não acho que o RP2040 seja um chip bem equipado para essa tarefa
Isso me lembra a infância, quando eu desmontava carrinhos de brinquedo e tirava o motor, sentindo que tinha conseguido fazer alguma coisa
Era difícil imaginar usar o RP2040 em um produto real, mas o RP2350 corrige muitas das reclamações e me deixa animado o bastante para querer testá-lo
O RP2040 também tinha muitos pontos fortes. TBMAN é um conceito bacana, e ele faz overclock extremamente bem. PIO é realmente inovador e tem muito valor para muitas empresas que querem substituir variantes do 8051 por um núcleo Arm em formato de daughterboard
Mas para cada coisa bacana havia também algo frustrante. Ele tem clock de nível DSP, mas não tem FPU nem divisão inteira por hardware. Também não é desejável ter funcionalidade USB DFU na boot ROM em um MCU sem proteção de memória. Em SDKs de terceiros como o Zephyr, o suporte a PIO é extremamente limitado, o que reduz sua utilidade em projetos grandes
O RP2350 resolve quase todas essas reclamações, então estou muito empolgado. Porém, se for preciso implementar periféricos comuns como CAN ou SDMMC via PIO, isso já vira uma desvantagem imediata. A flexibilidade é ótima, mas quando é preciso colocar um produto para funcionar rapidamente, não quero ficar mexendo em uma linguagem assembly de propósito especial. No fim, se eles fornecessem bibliotecas de soft peripherals prontas para funções comuns como SD/MMC, MII e Bluetooth HCI, a integração com Zephyr e afins ficaria mais fácil e o alcance de uso do chip aumentaria bastante
Eles poderiam ser mais completos, mas já estão bem próximos de algo “pronto”
PIO é uma grande vantagem, e fico feliz que a nova versão tenha reforçado ainda mais essa direção. As pessoas já estão desenvolvendo drivers PIO para vários periféricos, como CAN e WS2812, então está perto do que eu esperava
Operação autônoma de periféricos, amplificadores operacionais, comparadores e timers de captura/comparação são parecidos. O Zephyr tenta oferecer uma interface comum como um sistema operacional de desktop, mas isso não se encaixa bem em embarcados. No desktop, muitas vezes o mínimo denominador comum é suficiente; em embarcados, porém, a plataforma costuma ser escolhida justamente por esses recursos não comuns
A escolha pelo RP2040 teve a ver com a filosofia de design, mas depois da crise de escassez de chips, o fato de ele ter sido fácil de obter também pesou bastante
Na prática existem “exemplos”, e seria ainda melhor se essas coisas fossem oferecidas como suporte de primeira classe
As especificações podem ser vistas aqui: https://www.digikey.ca/en/product-highlight/r/raspberry-pi/r...
Baseado no RP2350, projetado pela Raspberry Pi no Reino Unido; Arm M33 dual-core a 150 MHz com FPU; 520 KiB de SRAM; recursos de segurança como boot assinado, OTP, SHA-256, TRNG, detector de glitch e Arm TrustZone for Cortex-M; CPU Hazard3 RISC-V dual-core opcional a 150 MHz; operação de baixo consumo; 3 PIO v2 e 12 máquinas de estado para suporte a periféricos customizados; suporte a PSRAM; interface de flash QSPI XIP externa mais rápida; flash QSPI onboard de 4 MB; GPIO tolerante a 5 V; SDK C/C++ open source e suporte a MicroPython; compatibilidade de software com Pico 1/RP2040; programação por arrastar e soltar via dispositivo de armazenamento em massa USB; módulo com castellações que pode ser soldado diretamente em placas carrier; mesmo footprint e compatibilidade de pinos com o Pico 1; 26 GPIOs multifuncionais, incluindo 3 entradas analógicas; temperatura de operação de -20 °C a +85 °C; tensão de entrada de 1,8 VDC a 5,5 VDC
Depois vi que a seção 14.8.2.1 menciona dois tipos de pinos digitais, “Standard Digital” e “Fault Tolerant Digital”, e os pinos FT Digital parecem ser tolerantes a 5 V
É um grande dia para a equipe do Pigweed
Embora alguns trabalhos tenham sido mencionados no próprio anúncio do RP2350/Pico 2 [1], nos últimos vários meses temos trabalhado em um novo SDK end-to-end [2] construído sobre Bazel [3], com suporte tanto ao RP2040 quanto ao RP2350. Isso também inclui upstream do suporte a Bazel no Pico SDK. O novo “Tour of Pigweed” [4] mostra vários recursos do Pigweed funcionando juntos em uma única base de código, como builds herméticos, testes unitários no dispositivo, comunicação centrada em RPC e testes de fábrica na bancada. Perguntas são recebidas no 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
Ver tudo integrado de forma hermética e o workflow reduzido a um único comando Bazel faz muita diferença
É surpreendente que o anúncio do Pigweed não mencione isso em nenhum momento
Gostaria que deixassem o Java fora do ecossistema de microcontroladores
É a primeira vez que vejo um design em que dá para escolher entre núcleos Arm e núcleos RISC-V no mesmo die
Fico curioso para saber se isso terá impacto no preço e no consumo de energia. Os núcleos Hazard3 são opcionais, e no boot é possível escolher executar a 150 MHz o par de núcleos Arm Cortex-M33 incluído ou o par de núcleos Hazard3. Indo mais longe, também é possível executar um RV e um Arm juntos
O Hazard3 é um design open source, com documentação publicada. É uma máquina RV32IMACZb* leve, sequencial, de 3 estágios, com a ISA RISC-V básica de 32 bits e suporte a multiplicação e divisão em hardware, instruções atômicas, manipulação de bits etc.
Eben Upton explicou: “Isso pode ser escolhido no boot. Cada porta que entra no bus fabric pode ser conectada, por meio de um mux, a um M33 ou a um Hazard3. Se quiser ser geek, você também pode executar um de cada”
Fonte: https://www.theregister.com/2024/08/08/pi_pico_2_risc_v/
A área ocupada pelos núcleos de instrução reais costuma ser bem pequena em comparação com periféricos ou memória interna
Dá para validar tanto a tecnologia quanto a aceitação do mercado a um custo muito menor do que fazer tape-out de um chip separado novo
É muito legal poder escolher RISC-V totalmente open source, se quiser. Acho que o núcleo RV deve ser mais lento que o M33 em desempenho por clock, e espero que o M33 tenha pontuações melhores nos benchmarks. Isso porque o Hazard3 tem pipeline de 3 estágios, embora o M33 também tenha 3 estágios. Estou ansioso pelos benchmarks
Post oficial de notícias: https://news.ycombinator.com/item?id=41192341
Página oficial do produto: https://news.ycombinator.com/item?id=41192269
Doom foi portado para o RP2040: https://kilograham.github.io/rp2040-doom/
O RP2350 parece capaz até de rodar Quake. Algumas mudanças dão a impressão de terem sido projetadas quase para esse objetivo. Ele tem FPU, dual core a 150 MHz, possibilidade de overclock para mais de 300 MHz e suporte a até 16 MB de PSRAM com paginação de leitura/gravação em hardware
Não é legal a placa de desenvolvimento usar micro-USB. Mesmo em 2024
Fora isso, é excelente e é exatamente o produto necessário para competir com os grandes players estabelecidos
É bom que produtos modernos sejam todos USB-C, mas ainda tenho muitos cabos micro-USB sobrando, então o fato de o Pico e o Pico 2 oficiais serem micro-USB não chega a incomodar muito. É bom haver opções para escolher a porta desejada conforme o projeto
O chip de interface também precisa ser mais complexo e, portanto, provavelmente mais caro. No AliExpress ainda há muitos dispositivos baratos usando micro-USB, e deve haver demanda por eles. Dependendo do público-alvo, pode-se criar um produto de consumo usando a placa de desenvolvimento como está
É um pouco surpreendente ver tanto foco em segurança no segundo microcontrolador de uma empresa jovem que parece voltada ao consumidor
No início, achei difícil confiar na segurança por falta de experiência. Mas microcontroladores seguros de fornecedores “experientes” também têm muitos bugs de segurança conhecidos e, mais importante, já houve casos em que ficou evidente a tentativa de encobrir esses problemas. Fazer duas auditorias da arquitetura de segurança, oferecer um bug bounty de US$ 10 mil e projetar uma placa para glitching, como um badge da DEF CON, mostra um compromisso bem grande com segurança. Também tenho curiosidade sobre como o Redundancy Coprocessor funciona. Ainda assim, não seria surpreendente se alguém conseguisse quebrar pelo menos parte disso
Isso significa que ela é percebida como voltada ao consumidor, e, do ponto de vista de receita e fornecimento, parece ter priorizado usuários industriais
Ainda não encontrei o anúncio oficial nem o datasheet, mas, segundo este texto, parece ser um grande salto em relação ao RP2040
Parece incluir 2× Cortex-M33F, DMA melhorado, mais PIOs e PIOs melhorados, suporte a PSRAM externa, flash interno de 2 MB e variante de 80 pinos, RAM dobrada para 512 KiB e alguns núcleos RISC-V. Talvez sejam para baixo consumo