Visão geral¶

Visão geral¶

Esta página explica como implementar IA embarcada no SF32: escolher o dispositivo, preparar o modelo para o caminho de execução previsto, planejar a memória e agendar inferências dentro do orçamento de energia do produto. Ela pressupõe que você conhece os fundamentos de hardware apresentados em Acelerador de IA. Se quiser conhecer primeiro o papel e os limites do acelerador, leia esse artigo antes.

O SDK expõe operações aceleradas pelo HAL NNACC (acelerador de redes neurais), com exemplos separados do HAL e do driver RT-Thread. Esses exemplos validam uma operação individual de convolução depthwise (por canal), não a implantação completa de um modelo treinado. Use-os para confirmar o funcionamento de uma operação isolada; escolha e verifique separadamente o runtime do modelo, as ferramentas de conversão e o mapeamento das camadas.

Os detalhes de implementação citados abaixo são específicos do SDK v2.5.1. Nem esses detalhes nem a disponibilidade de NNACC por família garantem suporte a um componente específico, a um runtime ou conversor de modelos completos, à compatibilidade de operadores, ao fallback automático para a CPU ou à entrada de câmera. Verifique esses pontos com a revisão e a configuração exatas do SDK, a revisão do chip, o runtime e a placa.

Use esta página quando você for responsável pelas decisões de produto e pelo caminho de implantação de um recurso de IA: o que o dispositivo deve decidir localmente, quanta memória e energia pode consumir e como deve se comportar diante de dados reais dos sensores. Ela complementa o artigo sobre o acelerador, que explica os limites do hardware.

Defina o que o produto precisa decidir localmente¶

Comece pela decisão que o produto precisa tomar, não pelo modelo:

• O que o dispositivo precisa classificar ou detectar por conta própria, sem depender de uma troca de dados com o celular ou a nuvem?
• Quais sensores fornecem os dados para essa decisão: movimento, áudio, sinais biométricos, câmera ou uma combinação deles?
• Com que frequência a decisão precisa ser calculada e em quanto tempo deve haver uma resposta?
• O que acontece se o modelo embarcado errar? O que custa mais: um falso positivo ou um falso negativo?
• O modelo precisará ser atualizado em campo? Se sim, como?

As respostas orientam todas as decisões seguintes: tamanho do modelo, orçamento de memória, seleção do dispositivo e por quanto tempo o sistema pode permanecer em repouso entre inferências.

Escolha o dispositivo SF32 adequado¶

Nem todos os dispositivos SF32 são voltados aos mesmos tipos de carga de trabalho de IA:

Use a tabela como ponto de partida para a avaliação, não como garantia de que o modelo caberá na memória ou executará com eficiência. Confira a memória, as interfaces dos sensores, a instância do acelerador e o suporte do SDK do componente escolhido para a carga completa. O guia NNACC do SDK v2.5.1 indica um acelerador na HCPU dos SF32LB55x/56x e aceleradores separados na HCPU e na LCPU do SF32LB58x. O guia não estabelece a disponibilidade de NNACC no SF32LB52x nem no SF32LB57x; trate essas famílias como não documentadas aqui, e não como prova de que não têm NNACC. A quantidade de instâncias não comprova compatibilidade do modelo nem eficiência energética. Consulte Posicionamento das famílias de dispositivos para o contexto de seleção.

Fluxo de desenvolvimento do modelo¶

Na prática, levar um modelo ao hardware SF32 segue etapas semelhantes, independentemente do caso de uso:

1. Treine ou selecione um modelo em uma estação de trabalho, usando dados que representem o que o sensor realmente encontrará em campo. Dados limpos de laboratório muitas vezes se comportam de forma bem diferente de sinais ruidosos coletados em situações reais.
2. Reduza o modelo para atender às restrições de sistemas embarcados, escolhendo a arquitetura, aplicando poda ou quantização, antes de se preocupar com a conversão específica do acelerador.
3. Exporte o modelo e mapeie as operações para o runtime de inferência escolhido e para os operadores, layouts e formatos numéricos realmente aceitos pelo SDK de destino. O HAL NNACC, por si só, não fornece um conversor de modelos completos nem um runtime de grafos.
4. Valide numericamente o modelo após a conversão e a quantização; não presuma que a precisão obtida no computador será mantida sem alterações.
5. Integre o pré-processamento, a inferência e o pós-processamento ao firmware. O modelo é apenas uma chamada de função dentro de uma pipeline maior.
6. Avalie latência, memória, consumo de energia e precisão em hardware real, não apenas em simulação.
7. Teste sob uma carga combinada realista: Bluetooth, display e sensores ativos ao mesmo tempo que a inferência, em vez de testar cada um isoladamente.

Um erro comum de integração é otimizar o modelo sem medir o pré-processamento, os buffers e o pós-processamento. Essas etapas podem custar tanto quanto a inferência acelerada; por isso, avalie o caminho completo.

Defina o contrato de execução¶

Antes de converter o modelo, documente os requisitos exatos que o firmware precisa cumprir durante a execução:

Esse contrato deve ser revisado pelos responsáveis por machine learning e firmware. Se a forma dos tensores, o formato ou o conjunto de operadores do modelo mudar sem que o firmware seja atualizado, o problema pode aparecer como baixa precisão ou latência instável, em vez de um erro claro durante a compilação.

Revise os operadores e as alternativas de execução¶

Antes de escolher o modelo, revise cada operador, seus parâmetros e o caminho real de execução. Uma implementação pela CPU ou uma alternativa automática precisa ser explicitamente fornecida pelo runtime escolhido; uma operação incompatível também pode impedir a implantação. Mesmo um modelo pequeno pode ser lento se executar camadas frequentes na CPU ou exigir conversões repetidas de layout.

O critério de aprovação não é “o modelo executa”. É “a pipeline completa atende às metas de precisão, latência, memória e energia usando a mesma distribuição de dados que o produto encontrará em campo”.

Quantização e orçamento de memória¶

Modelos compactos e quantizados são comuns em IA para microcontroladores, muitas vezes com inteiros de 8 bits em vez de ponto flutuante. Escolha o formato numérico aceito pelo caminho real de execução. Antes de definir a arquitetura, planeje memória para todos os itens a seguir, não apenas para os pesos:

A quantização pode reduzir o custo de memória e processamento, mas confira novamente a precisão após a conversão com dados representativos dos sensores. O guia do SDK v2.5.1 documenta aceleração para arm_convolve_1x1_HWC_q7_fast_nonsquare, arm_convolve_HWC_q7_basic_nonsquare e arm_depthwise_separable_conv_HWC_q7_nonsquare. A configuração do HAL usa buffers de 8 bits e deslocamentos para bias e saída; isso não comprova compatibilidade direta com os zero-points e as escalas por canal de qualquer modelo int8 moderno. Verifique a equivalência numérica e defina, para cada camada incompatível, uma implementação pela CPU, uma conversão ou a rejeição da implantação.

Posicionamento de buffers e hierarquia de memória¶

A largura de banda da memória pode limitar o desempenho da IA mesmo quando há capacidade de processamento disponível. Em dispositivos SF32 com SRAM, Flash, PSRAM e caches de instruções/dados do STAR-MC1, verifique a acessibilidade da memória e o custo de posicionar os buffers:

• Coloque tensores e buffers intermediários usados com frequência em memória acessível à CPU e à instância escolhida do acelerador, respeitando alinhamento e layout.
• Mantenha pesos grandes ou recursos pouco usados em memória externa somente se o caminho de execução aceitar essa localização. Inclua eventuais cópias para memória acessível ao acelerador nos orçamentos de memória, latência e energia.
• Durante uma transferência, apenas a CPU ou o acelerador/DMA deve controlar o buffer compartilhado. Antes do acesso pelo hardware, prepare todo o intervalo alinhado às linhas de cache: limpe as linhas de cache que contêm dados de entrada gravados pela CPU e trate as linhas modificadas do buffer de saída conforme as regras do SDK para escritas de dispositivos. Aguarde a conclusão antes de invalidar a saída e devolver o controle à CPU. Não altere o buffer nem outros dados que compartilhem suas linhas de cache enquanto o hardware o utiliza.

A implementação do HAL v2.5.1 verifica se os buffers atravessam limites de janelas de endereços de 1 MiB (1.048.576 bytes) e exige que entrada e bias estejam na mesma janela. Confira os endereços realmente alocados, não apenas o total de memória livre. O início bloqueante espera a conclusão por polling; o caminho por interrupção exige tratamento correto da IRQ e notificação de conclusão. Verifique os valores de retorno e defina recuperação de falhas e esperas limitadas na aplicação, sem presumir que o runtime do modelo forneça um timeout.

Consulte STAR-MC1 para ver considerações sobre cache e sistema de memória nesse tipo de padrão de acesso misto.

Planilha de dimensionamento da memória¶

Antes de integrar o firmware, preencha uma planilha de dimensionamento da memória com valores de pior caso, não com estimativas médias:

Reserve espaço também para stack, heap, objetos do RTOS, logs e OTA. Um modelo que só cabe quando todos os outros subsistemas estão desativados ainda não está pronto para um produto.

Monte a pipeline completa¶

O acelerador é uma etapa da pipeline que vai do sensor à decisão. A seguir são descritos três caminhos de entrada comuns.

Áudio e voz¶

Detecção de palavras-chave, gatilhos por palavra de ativação e classificação de eventos de áudio precisam de captura pelo microfone, organização em quadros e extração de características antes mesmo do início da inferência. Consulte a Visão geral de áudio para entender a captura e o uso de buffers nessa pipeline. O acelerador só ajuda se o áudio que recebe for capturado e armazenado em buffer com eficiência.

Movimento e fusão de sensores¶

Reconhecimento de gestos, classificação de atividades e análise biométrica normalmente usam dados do acelerômetro, giroscópio ou outros sensores. Meça separadamente o funcionamento dos sensores, a captura, o pré-processamento e a inferência antes de decidir o que domina o consumo. Agrupar amostras e capturar por interrupções pode reduzir despertares se a latência e a cobertura dos sinais permitirem; o benefício não supera necessariamente o custo do modelo. Consulte a Visão geral de baixo consumo.

Câmera e entrada de imagem¶

A entrada de câmera pode impor custos elevados de captura, buffers, largura de banda e inferência. A carga real depende da resolução, taxa de quadros, funcionamento do sensor e arquitetura do modelo. Se a precisão permitir, reduza a imagem ou processe uma região de interesse. Escolha um modelo para restrições embarcadas, sem presumir que um modelo de visão para computadores possa ser implantado sem alterações.

Agendamento de inferências com foco no consumo de energia¶

Escolha o agendamento para cumprir a cobertura de detecção e o tempo de resposta exigidos. A inferência periódica é válida quando o produto precisa de decisões regulares; condicionar a execução a eventos só é útil se isso não deixar passar sinais necessários.

• Quando adequado, inicie a inferência com dados novos e úteis, como um limiar de sensor ou um quadro completo de áudio. Mantenha o processamento periódico quando necessário e verifique falsos negativos e o pior tempo de resposta após mudar o gatilho.
• Agrupe amostras quando os requisitos de latência permitirem, em vez de executar muitas inferências pequenas.
• Se o dispositivo e o SDK oferecerem suporte, transfira a detecção leve e contínua para o processador de baixo consumo, evitando despertar a CPU principal da aplicação a cada amostra.
• Meça a energia por inferência integrando a potência de alimentação medida (tensão de alimentação × corrente) durante um intervalo definido. Inclua captura, pré/pós-processamento e transições entre atividade e repouso no orçamento do recurso. Processar mais rápido pode reduzir a energia ativa ou permitir repouso antecipado, mas o benefício depende da corrente, do tráfego de memória e do restante do sistema.

As orientações completas sobre consumo de energia do sistema estão na Visão geral de baixo consumo. Consulte esse artigo como complemento ao projetar um recurso de IA que precise funcionar continuamente ou quase continuamente.

Equilíbrio entre precisão, latência e consumo de energia¶

Os itens abaixo descrevem impactos comuns no projeto, não relações fixas. Meça a precisão real do modelo e a energia da pipeline completa ao fazer essas escolhas:

Antes de fazer ajustes, decida qual objetivo o produto realmente precisa priorizar. Um detector de gestos muitas vezes pode aceitar um pequeno aumento na latência para prolongar a autonomia da bateria; já um gatilho por voz costuma exigir resposta rápida e também precisa evitar falsos despertares que desperdiçam energia.

Atualização do modelo e validação em campo¶

Se o recurso de IA puder ser aprimorado após o lançamento, planeje desde cedo o suporte à atualização do modelo:

• Quando possível, versione o modelo separadamente do firmware e registre no pacote do modelo os requisitos esperados para os dados de entrada.
• Verifique autenticidade, integridade e compatibilidade do pacote com o runtime e a entrada antes da ativação. A ativação deve tolerar atualizações interrompidas e permitir voltar a uma versão comprovadamente funcional se a validação de inicialização falhar.
• Armazene dados de calibração, limiares e constantes de pós-processamento junto com a versão do modelo que depende deles.
• Registre estatísticas de campo suficientes para diagnosticar desvios, sem armazenar desnecessariamente dados brutos e privados dos sensores.
• Repita os testes de energia e coexistência após cada atualização do modelo. Um ganho de precisão ainda pode representar uma regressão do produto se fizer o sistema despertar com mais frequência.

Depuração do desempenho e da precisão de IA¶

Erros comuns¶

• Escolher a arquitetura do modelo antes de verificar quais operadores são realmente acelerados pelo runtime de destino.
• Portar um modelo dimensionado para desktop em vez de projetar desde o início para as restrições de sistemas embarcados.
• Ignorar o custo de memória das ativações intermediárias e planejar espaço apenas para os pesos do modelo.
• Executar inferências sem conferir se a frequência e o gatilho cumprem a cobertura de entrada e o tempo de resposta necessários.
• Validar a precisão apenas com dados limpos de laboratório, sem testar ruídos realistas de campo e dos sensores.
• Testar o recurso de IA isoladamente e só descobrir os problemas de coexistência depois da integração completa do produto.
• Otimizar a latência do modelo e ignorar as etapas de pré e pós-processamento ao redor da inferência.

Checklist de bring-up¶

• Defina a decisão local que o produto precisa tomar e o equilíbrio aceitável entre latência, precisão e consumo de energia.
• Selecione o dispositivo SF32 com base no tamanho do modelo e na memória necessária, não apenas na meta de custo.
• Construa e valide a pipeline completa (captura -> pré-processamento -> inferência -> pós-processamento), primeiro com um modelo mínimo de teste e depois com o modelo de produção.
• Converta e quantize o modelo real; em seguida, valide a precisão com dados realistas dos sensores.
• Planeje em conjunto a memória para pesos, tensores de entrada/saída e ativações intermediárias.
• Valide o tratamento da coerência de cache em todos os buffers compartilhados entre CPU e acelerador.
• Valide o agendamento periódico ou por eventos em relação à cobertura de detecção, à pior latência e ao orçamento de energia medido.
• Avalie a energia por inferência sob carga combinada do sistema, com Bluetooth, display e sensores ativos.
• Revalide a precisão e o consumo de energia após qualquer mudança na quantização, no modelo ou no agendamento.

Principais conclusões¶

• Comece pela decisão que o produto precisa tomar e pelos dados dos sensores, não pela arquitetura do modelo: ele é apenas uma etapa de uma pipeline maior.
• Use o posicionamento das famílias para a seleção inicial e depois verifique o componente, SDK, mapeamento dos operadores, alocação de memória e carga simultânea.
• Planeje a memória para a pipeline completa — pesos, tensores, ativações e buffers de pré/pós-processamento — e não apenas para o tamanho do arquivo do modelo.
• Escolha inferência periódica ou por eventos sem perder a cobertura necessária e meça a energia do recurso completo, sem tratar a velocidade do modelo como um resultado de consumo.
• Valide a precisão com dados realistas de campo e teste o recurso completo sob carga combinada do sistema, não isoladamente.

Última atualização: 2026-10-21