Otimização extrema de boot no Pi

 (kittenlabs.de)
4 pontos por GN⁺ 2024-09-02 | 1 comentários | Compartilhar no WhatsApp
  • O SolarCamPi é uma câmera solar off-grid que liga e desliga o Raspberry Pi Zero 2 W apenas na hora de tirar fotos, então o tempo de boot afeta diretamente a duração da bateria
  • Tomando como base o Debian 12 arm64 Lite e medindo /init.sh como o primeiro código em espaço de usuário, o boot inicial consumia cerca de 12 segundos e 9,5 Ws
  • Ao reduzir HDMI, LED, HAT/PoE/LCD, autodetecção de câmera e display, e initramfs, foram eliminadas esperas e detecções desnecessárias, e a corrente caiu de 136,7 mA → 120,6 mA
  • Depois de migrar para o Buildroot 2024.02.1 com um kernel personalizado, removendo drivers, compressão, KASLR e algumas mitigações, o sistema passou a chegar a um programa Linux em espaço de usuário em menos de 3,5 segundos
  • Ao reduzir a tensão de entrada de 5,0 V para 3,6 V, a energia total caiu de 1,754 Ws → 1,438 Ws, mas isso ainda exige validação de estabilidade e confiabilidade por operar fora da especificação

Por que o SolarCamPi precisava reduzir o tempo de boot

  • O SolarCamPi é uma câmera Wi‑Fi movida a energia solar que inicializa periodicamente o Raspberry Pi Zero 2 W para tirar fotos, enviá-las via Wi‑Fi para um serviço em nuvem e depois desligar de novo
  • Em ambientes com pouca energia, como o inverno da Europa Ocidental, cada segundo em que o Pi fica ligado representa custo energético
  • O aplicativo em espaço de usuário já estava otimizado ao máximo para conexão com o servidor e upload de fotos, e o circuito eletrônico também já havia sido projetado para reduzir o consumo durante o sono
  • Restavam dois caminhos para economizar
    • Reduzir a corrente consumida
    • Reduzir o tempo de execução
  • Diminuir apenas a corrente nem sempre traz ganho
    • Se o turbo da CPU for desativado e a corrente cair, mas o tempo de execução aumentar, a energia total pode até subir
    • O objetivo é minimizar a área sob a curva de corrente ao longo do tempo

Equipamentos de medição e método de teste

  • Em otimização de boot embarcado, é importante confirmar rapidamente a execução real após cada mudança, então ferramentas que reduzem remoção de cartão SD e manipulação de energia são essenciais
  • Os equipamentos usados foram os seguintes
  • O Power Profiler Kit II fornece energia ao dispositivo em teste enquanto mede, ao longo do tempo, o consumo de energia e o estado de 8 entradas digitais
    • Os pinos GPIO do Raspberry Pi foram conectados às entradas digitais
    • A primeira ação do aplicativo foi alternar um GPIO, permitindo medir o tempo entre a energização e a execução do código em espaço de usuário
  • O USB-SD-Mux é um interposer entre o cartão microSD e o dispositivo, permitindo que o computador assuma o cartão, regrave seu conteúdo e o devolva ao dispositivo
    • Isso elimina o trabalho repetitivo de retirar o cartão, colocá-lo em um leitor e recolocá-lo no dispositivo
    • O GPIO onboard também pode automatizar reset ou controle de energia do alvo de teste
  • O console USB-UART é necessário para verificar o estado quando o sistema falha, como em problemas de boot ou Wi‑Fi

Medição de boot com Debian

  • Em uma imagem limpa do Debian 12 bookworm arm64 Lite, foi adicionado init=/init.sh em /boot/firmware/cmdline.txt
  • Essa configuração faz o kernel executar /init.sh antes do systemd como o primeiro processo em espaço de usuário
  • O init.sh de exemplo alterna o GPIO4 e depois continua o boot do systemd com exec /sbin/init
  • Na medição inicial, cerca de 12 segundos depois, a entrada digital 0 ia para low, confirmando a execução do init.sh
  • Esse processo de boot consumia ao todo 1,90 coulomb
    • 1.9As * 5.0V = 9.5Ws
    • Uma pilha alcalina AA pode fornecer aproximadamente 13500 Ws de energia

Reduzindo a corrente consumida

  • Ao desativar completamente o encoder HDMI, a corrente caiu de 136,7 mA para 122,6 mA
    • Como era necessário codificar os dados da câmera, não foi possível desligar a própria GPU
    • Em aplicações que não precisem de câmera nem GPU, também seria possível tentar desativar a GPU
  • Só desativar o LED de atividade economizou 2 mA, reduzindo a corrente de 122,6 mA para 120,6 mA
  • Se houver LED da câmera, ele também pode ser desativado
    • Isso ainda reduz a chance de reflexo da luz na imagem
  • No teste de mudança da configuração turbo, o Pi no estado atual da modificação consumiu 1,62 As
    • Sem turbo forçado, o consumo foi de 1,58 As
    • Por algum motivo desconhecido, ao desligar os modos turbo/boost, o estado padrão do GPIO4 foi invertido, então a polaridade foi alterada em init.sh

Reduzindo o tempo de boot

  • A corrente caiu cerca de 13%, mas ainda levava aproximadamente 8 segundos até o primeiro output do Linux aparecer no console, consumindo cerca de 1 As nesse intervalo
  • Na família Raspberry Pi, a GPU é inicializada primeiro
    • A GPU procura bootcode.bin no cartão SD
    • No Pi 4 e superiores, isso é feito via EEPROM
  • Ao ativar BOOT_UART em bootcode.bin, é possível ver logs UART detalhados
    • É necessário fazer backup do bootcode.bin original, e o processo de alteração é potencialmente destrutivo
  • O bootloader tenta autodetectar os parâmetros de vídeo do monitor HDMI conectado aguardando a resposta EDID
    • Como HDMI não era usado, a string EDID foi fixada para evitar essa detecção
  • Também foram desativadas as detecções de EEPROM I2C relacionadas a HAT, ventoinha PoE, LCD e touchscreen
    • Como essas opções aguardam resposta no barramento I2C, podem ser desligadas quando não são necessárias
  • A autodetecção de câmera e display MIPI também consome tempo
    • Como a câmera usada era fixamente a HQ Camera IMX477, foram usados camera_auto_detect=0 e display_auto_detect=0, carregando dtoverlay=imx477 diretamente
  • Com essas mudanças, o tempo de boot autorreportado caiu de 5,38 segundos para 4,75 segundos e, ao remover auto_initramfs=1 para desativar o initramfs, caiu para 4,47 segundos
  • A técnica sdtweak, que faz overclock dos periféricos SD para 100 MHz, não gerou diferença mensurável no desempenho de boot
    • Como há risco de corrupção de dados em acessos de escrita, ela não é desejável em dispositivos IoT remotos

Gargalo no carregamento do kernel e migração para Buildroot

  • Nesse ponto, o carregamento do kernel era uma das tarefas mais lentas
    • Levaram cerca de 1,54 segundos para carregar kernel8.img com 9.276.375 bytes
    • A taxa de transferência foi de cerca de 6 MiB/s
  • O carregamento do kernel é feito pela GPU, que usa o processador proprietário interno VideoCore IV
    • Pode ser que o código do loader seja ineficiente ou use configurações conservadoras, mas por ser uma caixa-preta não foi possível ajustar registradores ou parâmetros de forma útil
  • Overclock do núcleo do processador da GPU era teoricamente possível e reduziu o tempo de carga do kernel em 20%
    • Como os efeitos colaterais, como confiabilidade, são desconhecidos, isso não é recomendado
  • O sistema foi migrado de Raspbian/Debian para uma distribuição personalizada baseada em Buildroot 2024.02.1
    • Usando toolchain nativa aarch64
    • Mantendo glibc e as ferramentas userland do Raspberry Pi
  • No kernel personalizado, foram removidos ou reduzidos os seguintes itens
    • Suporte a som
    • A maioria dos drivers de dispositivos de bloco e sistemas de arquivos, mantendo apenas SD/MMC e ext4
    • RAID, USB, HID, DVB
    • Suporte a vídeo e framebuffer
    • Recursos avançados de rede, como túneis, bridging e firewall
    • Compressão Gzip do kernel e compressão de módulos
  • Deixar kernel e módulos sem compressão foi vantajoso do ponto de vista de energia total, mesmo com a GPU levando mais tempo para carregar
    • A descompressão Gzip consome muita energia e, na prática, inclui uma etapa extra de realocação
  • O KASLR também foi desativado
    • O KASLR randomiza o endereço de carregamento do kernel na memória, dificultando a criação de exploits, mas exige que o kernel seja realocado após o carregamento pela GPU
    • Nesse caso de uso, a superfície de ataque de rede é muito limitada e todo o software da aplicação roda como root
    • Mitigações para vulnerabilidades de execução especulativa, como Spectre, também foram desativadas
  • O kernel resultante tinha 8,5 MiB sem compressão, e para comparação o tamanho em Gzip era de 4,1 MiB
    • O kernel Raspbian original tinha 25 MiB sem compressão e 8,9 MiB com Gzip

Resultado final e otimização da tensão de entrada

  • No fim, foi possível chegar a um programa Linux em espaço de usuário em menos de 3,5 segundos
  • O tempo gasto dentro do kernel Linux foi de cerca de 400 ms
  • O consumo total de energia foi 0.364As * 5.0V = 1.82Ws
    • Em comparação com os 9,5 Ws para chegar ao espaço de usuário no Debian padrão, isso representa cerca de um quinto
  • Depois da publicação, Graham Sutherland / Polynomial apontou que o regulador do Pi Zero não é eficiente com entrada de 5,0 V
  • No cenário de teste e no produto final, foi possível reduzir a tensão de entrada para 4,0 V
    • 5.0V: 350.94mAs * 5.0V = 1.754Ws
    • 4.0V: 390.77mAs * 4.0V = 1.563Ws
    • 3.6V: 399.60mAs * 3.6V = 1.438Ws
  • Ao reduzir a tensão, os mC, isto é, mAs, aumentam por causa da corrente maior, mas a energia total cai bastante
  • A operação em 3,6 V reduziu a energia em mais cerca de 20% ao usar o regulador chaveado em um ponto de operação mais ideal, mas tecnicamente está fora da especificação, então ainda requer mais validação de estabilidade e confiabilidade

Configurações e código publicados

Leituras relacionadas

1 comentários

 
GN⁺ 2024-09-02
Comentários do Hacker News

  • O gerenciamento de energia da linha Raspberry Pi é, sem dúvida, um de seus pontos fracos. Por isso estou animado com o novo Pico 2, porque parece que ficou mais fácil entrar em estados de economia de energia relativamente profundos sem hardware externo
    Já fiz uma câmera para uso parecido com um Google Coral mini; a câmera não era tão boa quanto a HQ cam, mas o RTC integrado dava suporte a standby/despertar com muita facilidade, então era perfeito para um app que tirava fotos periodicamente. Ele também tinha desempenho e 2 GB de memória suficientes para processar imagens de alta resolução
    Dá para conectar fisicamente a HQ camera, mas, até onde sei, não existe no Coral um pipeline de software para gerenciá-la
    O ecossistema do Raspberry Pi é muito mais maduro, e confio mais na disponibilidade futura do Raspberry Pi do que na continuidade do fornecimento da linha Coral pelo Google. Ainda assim, deu para sentir claramente como um bom suporte de energia no hardware é útil
    Ironicamente, a próxima versão da câmera foi feita por um fornecedor terceirizado usando Raspberry Pi, e o problema de energia foi compensado colocando uma bateria muito maior. Com isso, fiquei com 100 Coral dev mini e câmeras nem desembalados acumulados, e agora preciso encontrar uma boa ideia para eles ou vendê-los

    • A linha Coral me parece já morta ou descontinuada. O site coral.ai também não parece ter sido atualizado desde 2021, e o aviso de copyright é de 2020
      Fui procurar a conta oficial no Twitter pesquisando por "google coral twitter" e fiquei surpreso que o segundo resultado era um tweet seu tentando vender as 100 placas sobrando
    • Interessante, porque sempre usei Pi só ligado na tomada. Fico me perguntando se o hardware do Pi é que não consegue fazer otimização de energia como o Coral, ou se falta suporte de software para gerenciamento de energia no Pi
      Pelo que foi dito sobre gerenciar energia com hardware externo, parece não ser apenas um simples problema de software
    • Fico curioso se você chegou a olhar o hardware BeagleBone, que tem uma unidade PRU para operação de baixo consumo. A PRU pode continuar acordada enquanto o sistema está dormindo
    • Fico curioso sobre que tipo de tarefa vocês fazem que não dá para fazer com câmeras prontas atuais

  • Se você empacotar a aplicação como um initramfs vinculado ao kernel, em casos simples dá para eliminar a necessidade de montar um sistema de arquivos e reduzir bastante o tempo
    Em alguns casos, até algo como o init do BusyBox pode ser substituído por um script bash simples que faça apenas o mínimo da inicialização. Vale considerar montar devtmpfs, proc, sysfs etc., e, se possível, abandonar a glibc
    Antes de embutir o initramfs no kernel, é bom testar com chroot se todas as dependências necessárias da aplicação estão presentes. Se ela roda no chroot, o kernel também conseguirá executá-la durante a inicialização, e o ciclo de desenvolvimento fica muito mais rápido
    Desativar módulos do kernel e vincular ao kernel apenas os recursos necessários pode reduzir ainda mais espaço e tempo de boot. Também vale testar compressão zstd em vez de gzip

    • Por outro lado, se o carregamento do kernel e do initramfs for lento, pode ser mais rápido, na prática, inicializar com a menor imagem possível e carregar o restante do software depois que o espaço de usuário tiver começado
      Isso se aplica quando as etapas anteriores do boot não usam bem o desempenho do hardware, ou quando a imagem é grande e é melhor fazer outras coisas em paralelo ao carregamento
    • Não é obrigatório ter um script de shell só para montar vários pseudosistemas de arquivos. Você pode fazer isso diretamente dentro da aplicação
      Aí o que sobra é apenas um initramfs contendo um único binário linkado estaticamente

  • Há mais dois bons textos sobre como reduzir o tempo de boot do Pi
    https://www.furkantokac.com/rpi3-fast-boot-less-than-2-secon...
    http://himeshp.blogspot.com/2018/08/fast-boot-with-raspberry...
    Usei esses dois textos como referência para fazer um porta-retratos digital com Pi, e consegui fazê-lo iniciar muito rápido, inclusive com um navegador em modo quiosque. Quando os requisitos são bem pequenos, dá para alcançar tempos de boot bastante impressionantes

    • Lendo o primeiro texto, parece que o post original também poderia se beneficiar de usar start_cd.elf. É o bootloader de terceiro estágio com o subsistema gráfico removido, e dizem que melhora o tempo de carregamento em 0,5 s
    • Obrigado pelos links. Por acaso o código desse porta-retratos em modo quiosque está público?

  • A verdadeira tragédia é que o código de GPU bootcode.bin é uma caixa-preta proprietária, sem código-fonte
    É terrível que projetos de hacking e hobby tenham de carregar uma caixa-preta secreta e oculta que não pode ser modificada

    • O firmware do Pi é ThreadX, que depois foi adquirido pela Microsoft e renomeado para Azure RTOS
      Hoje ele é software livre e de código aberto
      https://www.theregister.com/2023/11/28/microsoft_opens_sourc...
      Isso não torna automaticamente todo o firmware do Pi livre e de código aberto, pois não se trata dos drivers. Mas, se quisessem, poderiam fazer isso
    • Fico pensando se, caso o código-fonte do bootcode fosse aberto, isso permitiria modificações tão extremas que a RPI não conseguiria garantir o funcionamento correto. Ou talvez tenha relação com o carregamento de drivers proprietários
      Fico curioso sobre o que há lá dentro que exige mantê-lo fechado

  • Gostei do texto como um todo, mas não tenho certeza sobre esta parte
    É a parte que diz que desligar o turbo da CPU para economizar um pouco de consumo de corrente é uma má escolha, e que, por causa do tempo maior, você acaba gastando mais energia do que se terminasse rápido e desligasse
    Nas aulas de ciência da computação aprendi que o consumo de energia é proporcional ao quadrado da frequência do clock. Ou seja, se você dobra o clock, a potência quadruplica
    Então acho que seria preciso medir a diferença real de potência para verificar se o aumento quadrático causado pela elevação do clock é maior do que o produto do consumo fixo de energia pelo aumento do tempo de execução
    Nesse sentido, seria bom se a CPU do Pi fornecesse informações detalhadas de consumo de energia, deriváveis do datasheet ou expostas em tempo real por registradores

    • Essa explicação não está totalmente correta. A potência de chaveamento do chip, excluindo vazamento estático, é proporcional ao quadrado da tensão multiplicado pela frequência
      A maioria dos chips precisa de uma tensão mais alta para atingir frequências de clock maiores, e é daí que vem a relação quadrática
      Mas, até onde sei, o Raspberry Pi não tem controle dinâmico de tensão, então, se você apenas reduz o clock sem reduzir a tensão, isso provavelmente não afeta o consumo total de energia de chaveamento
    • Isso é uma estratégia bem conhecida de otimização de energia chamada race to idle. Ela funciona porque, além da CPU, há muitos periféricos consumindo energia, e eles não podem ser desligados até que o trabalho da CPU termine
      Claro, também existe um ponto ótimo. Se você fizer overclock demais na CPU, o desempenho por watt cai tanto que o race to idle deixa de compensar
    • Para cargas de trabalho contínuas, é uma boa regra prática, mas não é a história toda. Há sempre um certo consumo estático de energia só pelo fato de os componentes estarem ligados
      Por isso, sistemas embarcados modernos muitas vezes usam estratégias de "race-to-sleep" ou "race-to-halt": executam o trabalho muito rapidamente e depois desligam a maioria dos componentes até o próximo evento
    • Há uma sobrecarga de energia básica que o dispositivo consome mesmo sem fazer nada. O benchmark também mostra que, com o turbo ligado, o consumo de corrente aumenta 10%, mas o tempo de boot cai 11%, gerando uma diferença pequena, porém mensurável, no uso total de energia
    • Conteúdo interessante. Obrigado por compartilhar
      Se fazer certo cálculo em 1 segundo consome 1 J, por exemplo 1 W a 1 GHz, então em um modelo esférico perfeito da vaca isso parece significar que fazer o mesmo cálculo em 0,5 segundo consumiria 2 J. Afinal, seriam 4 W a 2 GHz
      Só que isso considera apenas o consumo da CPU; se o sistema inteiro tiver um consumo fixo de 4 W, então a 1 GHz seriam 1 J da CPU mais 4 J do sistema, totalizando 5 J, e a 2 GHz seriam 2 J da CPU mais 2 J do sistema, totalizando 4 J
      Se entendi corretamente, isso quer dizer que faz sentido usar turbo quando o consumo de energia do sistema inteiro é parecido com o consumo da CPU em turbo, e caso contrário não?

  • Impressionante. Mas, toda vez que leio algo assim, lembro de quando gravei o boot do Plan 9 em um Pi Zero: https://taoofmac.com/space/blog/2020/09/02/1900#resurrecting
    O GIF é a saída em tempo real

    • Isso, por si só, é legal
      Mas conseguir carregar os drivers de câmera e Wi‑Fi necessários para o projeto original já é outra questão

  • Pessoalmente, acho os tempos de boot das distribuições Linux, no geral, bem decepcionantes, e esse problema fica muito maior nesse tipo de hardware fraco
    Fiz otimizações parecidas em uma SBC MQ-Pro. Também sinto bastante isso em notebooks. MacBooks talvez sejam uma exceção, mas, de todo modo, é algo irritante

    • Depende muito de como você define tempo de boot. Por exemplo, o Windows otimiza para o tempo até a primeira UI aparecer, mas o restante continua carregando depois disso, e o PC fica praticamente inutilizável por alguns segundos
    • Um MacBook M1 leva várias vezes mais, na casa de um dígito, para iniciar do que meu desktop Windows
      Depois de ligado, apenas fazer login novamente é instantâneo, mas reiniciar leva um bom tempo
    • Linux também pode inicializar bem rápido com a configuração certa. Já escrevi sobre isso em [0]
      O problema é que as distribuições, por motivos razoáveis, criam kernels e initramfs muito genéricos, e essa combinação não é particularmente rápida no boot
      [0]: https://blog.davidv.dev/posts/minimizing-linux-boot-times/
    • Não sei ao certo quanto uma distribuição pode fazer aqui. Muitas vezes, o tempo de boot no espaço de usuário é desprezível
      A menos que haja alguma configuração terrível, como o NetworkManager esperando 90 segundos por um Wi‑Fi inexistente. Minha máquina Linux leva cerca de 4 segundos até o graphical.target, e a maior parte disso é por causa da conexão Wi‑Fi e do ntpd, ambos em princípio opcionais
      Se você quer um boot realmente rápido, basta jogar fora toda a configurabilidade dinâmica, como camada de compatibilidade do bootloader, abstrações e initramfs. Mas aí você fica à mercê do fornecedor do hardware, então não vale a pena
    • Acho essa afirmação um pouco estranha. No meu caso, o boot do Linux é muito rápido mesmo em máquinas antigas e com armazenamento lento
      Por exemplo, meu MacBook Air 11 com Linux chega à tela de login tão rápido que quase não dá para ver os logs de boot. Pelo systemd-analyze, leva menos de 4 segundos até o graphical target
      A chave parece estar em duas coisas. Não uso ambiente de desktop; inicializo em modo texto e, quando necessário, rodo startx ou entro no X com um gerenciador de login leve (lightdm). Sem ambiente de desktop, o número de serviços cai para algo na casa de um dígito, reduzindo bastante a pressão de I/O durante o boot em hardware antigo. Mesmo rodando X, o sistema inicializado fica abaixo de 200 MB
      A outra é que o EFI stub pode acelerar: https://wiki.archlinux.org/title/EFISTUB

  • Minha primeira intuição foi: será que não daria para usar outro core? Será que é realmente necessário Linux para tirar uma foto e enviá-la para a nuvem?
    Não sou da área de hardware, então fiquei curioso sobre como seria possível concluir essa tarefa com o menor orçamento possível. Foi um texto interessante

    • Também foi a primeira coisa que pensei
      Talvez seja só porque tenho dois ESP32-CAM agora na mesa de jantar, mas fiquei curioso para saber como uma configuração com ESP32-CAM se compararia. Provavelmente só seria boa até imagens de 2 megapixels, mas acho que tanto o tempo de inicialização quanto o consumo de energia seriam quase uma ordem de grandeza menores
      Se tiver curiosidade, há detalhes aqui: https://components101.com/modules/esp32-cam-camera-module
    • O problema é que este projeto usa uma câmera e rede sem fio, e ambos exigem drivers bastante complexos
      Em princípio, seria possível fazer em bare-metal, mas fazer os periféricos necessários funcionarem não é fácil

  • Fiquei me perguntando por que o kernel customizado apareceu tão tarde. Para otimizar, não se começaria por LFS ou por uma distribuição baseada em código-fonte? Também não parece que atualizações autônomas de software sejam realmente necessárias em um dispositivo desses
    Também fico curioso se dá para otimizar EFI/BIOS em um dispositivo assim. Pelo menos no meu desktop comum com Arch Linux, isso responde por uma parte considerável do tempo de boot
    $ systemd-analyze
    Startup finished in 10.076s (firmware) + 1.339s (loader) + 1.569s (kernel) + 2.974s (initrd) + 3.894s (userspace) = 19.854s

    • O Buildroot que eles usaram é exatamente uma ferramenta para esse propósito. No Buildroot, você configura sua própria "distribuição" e, a partir dela, gera uma única imagem de boot
      Não conheço exatamente o hardware do Raspberry Pi, mas muitos outros SoCs embarcados têm um bootloader bem minimalista que roda com u-boot e costuma ser muito rápido. Especialmente se você definir como 0 o atraso que espera entrada do usuário
    • Em um ambiente real, você provavelmente não vai querer usar LFS seguindo o manual do projeto LFS. Há GNU demais para compilar
      Um kernel mínimo com um sistema busybox é muito menos doloroso, e Gentoo também não é uma má escolha
    • Graças a isso, percebi que preciso otimizar meu bootloader (systemd-boot) e que meu firmware é surpreendentemente excelente
      > systemd-analyze
      Startup finished in 3.259s (firmware) + 35.127s (loader) + 1.823s (kernel) + 2.927s (userspace) = 43.138s

  • 3,5 segundos é legal, mas, se o cenário completo é mesmo conectar ao Wi-Fi a cada poucos minutos para enviar uma imagem, ESP32 teria sido uma escolha muito melhor em termos de consumo de energia
    A menos que seja absolutamente necessário algum recurso específico do módulo de câmera para Pi que não exista nas câmeras compatíveis com ESP32-CAM

    • O ESP32 só oferece suporte a até 4 MB de PSRAM, enquanto uma única imagem estática da RPi HQ Camera já tem 18 MB
    • Eu até poderia recomendar um microcontrolador um pouco mais sofisticado com interface MIPI CSI, mas, fora isso, concordo
      Parece trabalho demais para fazer algo que um microcontrolador conseguiria fazer quase sem esforço