• Filtragem Digital, Cepstrum e Detecção Acústica em MCU
• Detecção de Assobio Humano com o Algoritmo de Goertzel no RP2040

1. Introdução — Por que combinar Goertzel com aprendizado estatístico?

Nos dois artigos anteriores desta série, exploramos duas estratégias clássicas e complementares de processamento digital de sinais em microcontroladores:

1. Séries de Taylor + Cepstrum → análise estrutural e harmônica do sinal
2. Algoritmo de Goertzel → detecção espectral dirigida e altamente eficiente

Ambas funcionam muito bem, mas compartilham uma característica importante:
a decisão final é baseada em limiares fixos.

Neste terceiro artigo, damos um passo conceitual além, mantendo o Goertzel como extrator de características espectrais, mas substituindo o decisor rígido por um modelo de aprendizado estatístico leve, adequado a MCUs como o RP2040.

O objetivo não é “colocar inteligência artificial por marketing”, mas sim responder a um problema real:

Como tornar a detecção mais robusta quando o ambiente muda, o usuário muda ou o ruído não é previsível?

1.1 O papel do Goertzel nesta nova arquitetura

É importante deixar claro desde o início:

• Goertzel não será substituído
• Não vamos rodar FFT gigante
• Não vamos usar redes neurais profundas
• Goertzel continua sendo o sensor espectral

Nesta arquitetura, o Goertzel atua como um extrator determinístico de características (features):

• Energia na frequência fundamental
• Relação entre harmônicos
• Estabilidade espectral ao longo do tempo

Esses valores passam a ser dados de entrada para um bloco estatístico que decide se o padrão observado se parece ou não com um assobio humano real.

1.2 O que entendemos aqui por “aprendizado estatístico”

Neste artigo, aprendizado estatístico não significa deep learning.

Vamos trabalhar com modelos:

• Interpretáveis
• Leves
• Computacionalmente previsíveis
• Treináveis com poucos dados

Exemplos que abordaremos ao longo do artigo:

• Média e variância adaptativas
• Distância estatística (z-score, Mahalanobis simplificada)
• Classificador linear simples
• Modelo incremental (online learning)

Tudo isso é:

• Executável em ponto flutuante simples
• Compatível com firmware bare-metal
• Determinístico em tempo real

1.3 Por que limiares fixos falham em campo

Nos artigos anteriores, usamos decisões do tipo:

• score > S_ON
• score < S_OFF

Isso funciona bem quando:

• O ambiente é estável
• O microfone é sempre o mesmo
• O usuário assobia sempre da mesma forma

Mas em campo real:

• Pessoas assobiam diferente
• Distância ao microfone muda
• Ruído de fundo varia
• Ganho analógico muda com temperatura e alimentação

Resultado:
limiar bom hoje, ruim amanhã.

O aprendizado estatístico resolve exatamente isso:

• Ele aprende o padrão típico
• Ele tolera variações naturais
• Ele se adapta lentamente ao ambiente

1.4 Visão geral da nova arquitetura

A nova cadeia de processamento será:

ADC
 └── DC-block
     └── Frame (256 amostras)
         └── Goertzel (fundamental + harmônicos)
             └── Vetor de características
                 └── Modelo estatístico adaptativo
                     └── Decisão (assobio / não assobio)
                         └── LED / evento

Comparando com o artigo anterior:

1.5 O que você terá ao final deste artigo

Ao final deste terceiro artigo da série, você terá:

• Um detector de assobio adaptativo
• Baseado em Goertzel + estatística
• Código 100% em C
• Executando em tempo real no RP2040
• Sem dependência de bibliotecas externas
• Com arquitetura reutilizável para:
  • Detecção de padrões acústicos
  • Sensores inteligentes
  • Interfaces por som
  • Pré-processamento para tinyML

Mais importante:
você entenderá como transformar DSP em dados e dados em decisão, de forma técnica.

The post Detecção de Assobio com Goertzel e Aprendizado Estatístico no RP2040 first appeared on MCU & FPGA.

1. Introdução — Por que Goertzel?

No artigo anterior desta série, exploramos uma abordagem baseada em filtragem digital construída com Séries de Taylor, seguida pelo cálculo do cepstrum, para identificar a periodicidade característica de um assobio humano. Aquela estratégia privilegiou uma análise global do espectro, permitindo identificar a estrutura harmônica do sinal de forma robusta, mesmo em ambientes com ruído.

Neste novo artigo, damos continuidade direta a essa série, adotando uma estratégia complementar e mais enxuta: o algoritmo de Goertzel. Em vez de calcular todo o espectro via FFT, o Goertzel permite extrair seletivamente a energia de frequências específicas, tornando-o ideal para microcontroladores com recursos limitados — como o RP2040 — quando o interesse está restrito a faixas bem definidas.

O assobio humano típico apresenta uma frequência fundamental relativamente estável, geralmente entre 800 Hz e 3000 Hz, com harmônicos previsíveis. O algoritmo de Goertzel explora exatamente esse cenário:

“Eu sei qual frequência quero detectar — e só ela importa.”

1.1 Estratégia geral adotada neste artigo

A arquitetura de processamento deste artigo será:

1. Aquisição do sinal acústico (ADC do RP2040)
2. Pré-processamento simples (remoção de DC e normalização)
3. Aplicação do algoritmo de Goertzel para:
   • Frequência fundamental
   • Harmônicos selecionados
4. Construção de um critério de decisão espectral
5. Confirmação temporal (evitar falsos positivos)
6. Acionamento de um LED quando o assobio é detectado

Diferentemente do artigo anterior:

• Não calcularemos FFT
• Não calcularemos cepstrum
• Usaremos análise espectral pontual
• Menor uso de RAM e CPU
• Menor latência

Isso permite uma comparação clara entre duas filosofias de DSP embarcado:

• FFT + Cepstrum → análise estrutural
• Goertzel → análise dirigida por frequência

1.2 Quando Goertzel é a escolha correta (e quando não é)

Goertzel é uma excelente escolha quando:

• Você conhece as frequências de interesse
• O número de frequências é pequeno
• O MCU possui RAM limitada
• A latência precisa ser baixa
• O sistema é reativo (event-driven)

Goertzel NÃO é a melhor escolha quando:

• A frequência fundamental varia muito
• Você precisa analisar o espectro completo
• O sinal tem múltiplas fontes concorrentes
• A estrutura harmônica é desconhecida

Este artigo assume explicitamente o caso ideal para Goertzel:
detectar um fenômeno acústico específico e conhecido.

1.3 Relação direta com o artigo anterior

Este artigo não substitui o anterior — ele o complementa.

A ideia da série é exatamente essa: mostrar estratégias diferentes para o mesmo problema, permitindo ao engenheiro escolher conscientemente.

1.4 O que você terá ao final deste artigo

Ao final deste artigo, você terá:

• Um detector de assobio funcional
• Código 100% em C, portátil
• Execução em tempo real no RP2040
• Arquitetura reutilizável para:
  • DTMF
  • Tons de controle
  • Alarmes acústicos
  • Interfaces sonoras simples

The post Detecção de Assobio Humano com o Algoritmo de Goertzel no RP2040 first appeared on MCU & FPGA.

1 — Motivação, Visão Geral do Problema e Arquitetura da Solução

1.1 Motivação técnica

Assobios humanos possuem uma característica muito interessante do ponto de vista de processamento digital de sinais (DSP): eles apresentam uma frequência fundamental bem definida, normalmente entre 800 Hz e 3 kHz, acompanhada por harmônicas que decrescem em amplitude. Isso os torna excelentes candidatos para estudo de extração de pitch, separação espectral e detecção robusta de eventos acústicos em sistemas embarcados.

No contexto de microcontroladores como o RP2040, o desafio é duplo:

1. Executar algoritmos matematicamente consistentes com baixo custo computacional.
2. Evitar bibliotecas pesadas de DSP, favorecendo implementações determinísticas, explicáveis e portáveis.

Este artigo foi desenhado exatamente com esse espírito: mostrar que é possível construir um pipeline de detecção de assobio usando apenas matemática clássica, séries de Taylor e algoritmos fundamentais de DSP, sem FFTs complexas ou frameworks externos.

1.2 Problema a ser resolvido

O problema central pode ser descrito em três níveis:

1. Separação espectral
   O sinal do microfone contém:
   • Ruído ambiente
   • Voz humana
   • Sons impulsivos
   • O assobio propriamente dito
   Precisamos isolar a frequência fundamental do assobio e suas harmônicas.
2. Identificação confiável do assobio
   Apenas detectar energia em uma faixa de frequência não é suficiente, pois outros sons podem cair nessa banda.
   Precisamos identificar periodicidade — aqui entra o cepstrum, que trabalha no domínio da quefrência.
3. Ação física
   Após a detecção confiável:
   • Acender um LED quando um assobio é detectado
   • Apagar o LED quando o assobio desaparece

Tudo isso deve funcionar em tempo real, em um RP2040, usando a BitDogLab como plataforma de referência.

1.3 Arquitetura geral do sistema

O pipeline completo que iremos construir ao longo do artigo é o seguinte:

Microfone (ADC)
       ↓
Pré-processamento (remoção de DC)
       ↓
Filtro Digital por Séries de Taylor
(separação da fundamental e harmônicas)
       ↓
Cálculo do Cepstrum
(log + autocorrelação simplificada)
       ↓
Detecção de Pitch (assobio)
       ↓
Controle do LED (GPIO)

Microfone (ADC)
       ↓
Pré-processamento (remoção de DC)
       ↓
Filtro Digital por Séries de Taylor
(separação da fundamental e harmônicas)
       ↓
Cálculo do Cepstrum
(log + autocorrelação simplificada)
       ↓
Detecção de Pitch (assobio)
       ↓
Controle do LED (GPIO)

Cada bloco será implementado incrementalmente, de forma que:

• O código compile e funcione a cada etapa
• Possamos validar o comportamento do sistema progressivamente
• Ao final, teremos um firmware completo, funcional e didático

1.4 Por que Séries de Taylor em filtros digitais?

Normalmente, filtros digitais são apresentados como:

• IIR (Butterworth, Chebyshev, etc.)
• FIR por convolução
• FFT + máscara espectral

Aqui escolhemos Séries de Taylor por três razões estratégicas:

1. Controle matemático total
   Um filtro baseado em Taylor é, na prática, uma aproximação explícita de operadores diferenciais, o que permite entender exatamente o que está sendo implementado.
2. Eficiência em microcontroladores
   Séries truncadas resultam em:
   • Poucas multiplicações
   • Nenhuma função transcendental cara em tempo real
3. Valor didático elevado
   Esse método conecta:
   • Cálculo diferencial
   • Sistemas lineares
   • DSP clássico
     Em um único algoritmo executável em hardware real.

Mais adiante, mostraremos como aproximar respostas passa-faixa usando expansões de Taylor aplicadas a operadores discretos.

1.5 O papel do Cepstrum na detecção do assobio

Mesmo após filtrar o sinal, ainda temos um problema:
harmônicas também são periódicas, e ruídos podem enganar um detector simples.

O cepstrum resolve isso explorando uma ideia elegante:

A periodicidade no domínio do tempo vira um pico no domínio da quefrência.

Em termos práticos:

• Um assobio gera um pico claro no cepstrum
• Voz humana tende a gerar padrões mais espalhados
• Ruído branco praticamente não gera picos estáveis

Isso torna o cepstrum extremamente robusto para identificar assobios reais, mesmo em ambientes ruidosos.

The post Filtro Digital com Séries de Taylor e Cepstrum para Detecção de Assobio em RP2040 first appeared on MCU & FPGA.

A STMicroelectronics anunciou recentemente a família STM32V8, marcando um avanço significativo na evolução dos microcontroladores de uso geral e industrial. Diferentemente das gerações anteriores da linha STM32, o STM32V8 foi concebido desde a origem para atender aplicações que exigem altíssimo desempenho computacional, baixa latência, eficiência energética e capacidade de executar algoritmos avançados, incluindo inteligência artificial embarcada, controle em tempo real e processamento digital de sinais.

O grande diferencial tecnológico do STM32V8 está no uso de um processo de fabricação em 18 nm FD-SOI (Fully Depleted Silicon On Insulator), aliado à integração de memória não volátil do tipo PCM (Phase-Change Memory) diretamente no chip. Essa combinação permite à ST superar limitações clássicas dos microcontroladores baseados em Flash tradicional, como latência de acesso à memória, consumo energético elevado durante escrita e restrições de escalabilidade em nós tecnológicos mais avançados.

No núcleo computacional, o STM32V8 é baseado no Arm Cortex-M85, atualmente o núcleo mais poderoso da família Cortex-M. Esse núcleo oferece suporte nativo a extensões Helium (M-Profile Vector Extension) para aceleração de DSP (Processamento Digital de Sinais) e workloads de machine learning, além de um pipeline mais profundo e recursos avançados de predição e paralelismo interno. Com frequências de operação significativamente mais altas que gerações anteriores, o STM32V8 se posiciona como um microcontrolador que começa a ocupar o espaço tradicionalmente reservado a microprocessadores de entrada, porém mantendo as vantagens de um MCU: determinismo, baixo consumo e integração periférica.

Do ponto de vista prático, a ST posiciona o STM32V8 para aplicações como controle industrial avançado, robótica, automação predial e fabril, dispositivos médicos, edge AI, sensoriamento inteligente e sistemas ciberfísicos. O objetivo é permitir que arquiteturas antes dependentes de SoCs com Linux ou coprocessadores externos possam ser implementadas em um único microcontrolador, reduzindo custo, consumo, complexidade de software e requisitos de certificação.

Essa nova família não substitui as linhas STM32 já consolidadas (como STM32F, G, H ou U), mas inaugura uma nova classe de MCU dentro do portfólio da ST, voltada explicitamente para aplicações que exigem o máximo desempenho possível dentro do ecossistema Cortex-M. Nas próximas seções, serão detalhados os pilares tecnológicos do STM32V8, começando pela sua arquitetura de fabricação e sistema de memória, e posteriormente avançando para núcleo, periféricos, segurança e uma comparação técnica objetiva com o Renesas RA8M1.

Seção 2 – Tecnologia de Fabricação do STM32V8: 18 nm FD-SOI e Memória PCM

Um dos aspectos mais disruptivos do STM32V8 não está apenas no núcleo Cortex-M85, mas principalmente na tecnologia de fabricação adotada pela STMicroelectronics. Pela primeira vez em microcontroladores de uso geral, a ST emprega um processo 18 nm FD-SOI (Fully Depleted Silicon On Insulator) combinado com memória não volátil do tipo PCM (Phase-Change Memory) integrada no próprio chip. Essa escolha tem implicações diretas em desempenho, consumo, confiabilidade e escalabilidade tecnológica.

A tecnologia FD-SOI difere significativamente do CMOS convencional utilizado em processos mais antigos (40 nm, 65 nm, 90 nm). No FD-SOI, o transistor é construído sobre uma camada isolante extremamente fina, o que reduz drasticamente correntes parasitas, melhora o controle eletrostático do canal e diminui a variabilidade dos transistores. Na prática, isso se traduz em menor consumo dinâmico e estático, maior frequência de operação e melhor comportamento térmico, fatores críticos para sistemas embarcados que operam 24/7 ou em ambientes industriais severos.

Outro benefício importante do FD-SOI é a possibilidade de body biasing dinâmico, técnica que permite ajustar o limiar de tensão dos transistores por software ou hardware. Isso dá ao projetista a capacidade de priorizar desempenho ou eficiência energética em tempo real, algo particularmente relevante em aplicações que alternam entre modos de processamento intenso e estados de baixo consumo. Em um microcontrolador de alto desempenho como o STM32V8, esse recurso amplia significativamente a flexibilidade arquitetural do sistema.

Complementando o processo de 18 nm, a ST substituiu a Flash tradicional por memória PCM (Phase-Change Memory). Diferente da Flash, a PCM não depende de tunelamento de elétrons através de óxidos finos, o que elimina vários gargalos clássicos: latência elevada de leitura, alto consumo durante escrita e desgaste acelerado com ciclos de programação/apagamento. A PCM permite leituras praticamente tão rápidas quanto SRAM, com maior densidade e excelente retenção de dados, mesmo em temperaturas elevadas.

Do ponto de vista prático de firmware, a presença da PCM impacta diretamente a forma como o código é executado. O STM32V8 consegue operar em execução direta da memória não volátil (XIP – Execute In Place) sem as penalidades comuns da Flash, reduzindo ou até eliminando a necessidade de copiar rotinas críticas para RAM. Isso simplifica o linker script, reduz o uso de SRAM e melhora o determinismo temporal — um ponto fundamental para RTOS, controle em tempo real e aplicações safety-critical.

Além disso, a PCM é naturalmente mais adequada a nós tecnológicos avançados, o que garante longevidade à família STM32V8. Enquanto a Flash enfrenta sérias dificuldades de escalabilidade abaixo de 28 nm, a PCM se mantém viável em processos ainda menores, preparando o caminho para futuras evoluções da linha sem rupturas arquiteturais. Para desenvolvedores e fabricantes de equipamentos, isso significa maior segurança de investimento e continuidade de plataforma.

Na próxima seção, entraremos no coração computacional do STM32V8, analisando em detalhes o núcleo Arm Cortex-M85, suas extensões vetoriais, impacto prático em DSP e inteligência artificial embarcada, e como isso redefine o limite do que se espera de um microcontrolador.

Núcleo Arm Cortex-M85 no STM32V8: Desempenho, DSP e Inteligência Artificial Embarcada

No centro do STM32V8 está o Arm Cortex-M85, atualmente o núcleo mais avançado da família Cortex-M. Sua adoção não representa apenas um incremento incremental de desempenho, mas sim uma mudança de patamar naquilo que é possível executar em um microcontrolador sem recorrer a microprocessadores ou aceleradores externos. A ST posiciona o STM32V8 como uma plataforma capaz de consolidar controle em tempo real, processamento de sinais e inferência de modelos de inteligência artificial em um único dispositivo.

O Cortex-M85 introduz um pipeline mais profundo e otimizado em relação a núcleos anteriores como o Cortex-M7 ou M33, permitindo frequências de operação significativamente mais altas. No contexto do STM32V8, isso se traduz em um MCU capaz de executar centenas de milhões de instruções por segundo, mantendo características fundamentais de sistemas embarcados, como determinismo temporal, interrupções de baixa latência e execução previsível, essenciais para aplicações industriais, automotivas e médicas.

Um dos principais diferenciais técnicos do Cortex-M85 é o suporte nativo às extensões Helium, também conhecidas como M-Profile Vector Extension (MVE). Essas extensões introduzem um conjunto de instruções vetoriais SIMD (Single Instruction, Multiple Data), permitindo que operações matemáticas sejam executadas em paralelo sobre múltiplos dados. Na prática, isso acelera de forma expressiva algoritmos de DSP, como filtros FIR e IIR, FFTs, convoluções, correlação e operações matriciais, amplamente utilizadas em controle, áudio, vibração, sensores e comunicações industriais.

No campo da inteligência artificial embarcada, o impacto é ainda mais relevante. O Cortex-M85 foi projetado para executar inferência de redes neurais leves diretamente no MCU, especialmente modelos de machine learning para edge computing, como classificadores, detectores de padrões e modelos de regressão. Quando combinado com bibliotecas otimizadas como CMSIS-DSP e CMSIS-NN, o STM32V8 passa a executar modelos treinados em frameworks como TensorFlow Lite Micro com desempenho antes restrito a SoCs mais complexos.

Do ponto de vista prático de desenvolvimento, isso significa que tarefas como detecção de anomalias, classificação de sinais, reconhecimento de padrões em sensores, monitoramento preditivo e processamento inteligente de dados podem ser implementadas diretamente no microcontrolador, sem dependência de sistemas operacionais complexos ou unidades externas de processamento. Além de reduzir consumo e custo, essa abordagem melhora a confiabilidade do sistema e reduz latências críticas.

Outro aspecto importante do Cortex-M85 é o avanço nos mecanismos de segurança e isolamento, especialmente quando combinado com arquiteturas compatíveis com TrustZone para Cortex-M. Embora o foco principal do STM32V8 seja desempenho, a presença de recursos modernos de proteção de memória, execução segura e separação de contextos torna o dispositivo adequado a aplicações conectadas, onde segurança cibernética é um requisito básico e não opcional.

Em síntese, o núcleo Cortex-M85 transforma o STM32V8 em um microcontrolador que atua como uma plataforma computacional completa, capaz de unificar controle, processamento de sinais e inteligência artificial. Na próxima seção, será analisada a arquitetura de memória e subsistema de interconexão do STM32V8, explorando como a combinação de PCM, SRAM e barramentos internos sustenta esse nível de desempenho de forma determinística e eficiente.

Arquitetura de Memória e Execução no STM32V8

O desempenho elevado do STM32V8 não é resultado apenas do núcleo Cortex-M85 ou do processo de fabricação em 18 nm, mas da forma como a arquitetura de memória foi projetada para sustentar cargas computacionais intensas com previsibilidade temporal. A ST adotou uma abordagem que combina memória PCM de alta velocidade, SRAM interna otimizada e um subsistema de barramentos de alta largura de banda, criando uma base sólida para aplicações em tempo real, DSP e inteligência artificial embarcada.

A memória PCM (Phase-Change Memory) atua como principal memória não volátil do sistema, substituindo completamente a Flash tradicional. Diferente da Flash, cujo acesso pode introduzir estados de espera (wait states) em altas frequências, a PCM oferece latência significativamente menor e mais previsível, permitindo que o núcleo execute código diretamente da memória não volátil com impacto mínimo no desempenho. Isso reduz a necessidade de técnicas clássicas, como cópia de código crítico para RAM, simplificando o projeto de firmware e melhorando o determinismo.

A SRAM interna complementa a PCM, sendo utilizada para dados, pilhas, heaps, buffers de comunicação e estruturas temporárias exigidas por algoritmos de DSP e IA. No STM32V8, essa SRAM é distribuída de forma estratégica no mapa de memória, permitindo acessos paralelos e reduzindo contenções no barramento. Essa organização é particularmente importante quando múltiplos mestres — como o núcleo, DMA e aceleradores internos — competem por acesso à memória.

O subsistema de interconexão interna do STM32V8 foi projetado para acompanhar o aumento de desempenho do núcleo. Barramentos de alta velocidade interligam o Cortex-M85 às memórias e periféricos, garantindo baixa latência em acessos críticos e previsibilidade temporal. Para aplicações em tempo real, essa previsibilidade é tão importante quanto a velocidade bruta, pois garante que interrupções, tarefas de RTOS e rotinas de controle cumpram seus prazos de execução.

Do ponto de vista prático, essa arquitetura favorece fortemente o uso de RTOS como FreeRTOS ou Zephyr, permitindo que múltiplas tarefas executem algoritmos complexos sem interferências imprevisíveis. Em sistemas de controle avançado, por exemplo, é possível isolar tarefas de aquisição de sensores, processamento vetorial e comunicação, mantendo comportamento determinístico mesmo sob carga elevada.

Outro ponto relevante é o impacto dessa arquitetura na eficiência energética. A menor latência da PCM reduz o tempo total de execução das instruções, permitindo que o microcontrolador entre mais rapidamente em estados de baixo consumo. Aliado aos recursos do FD-SOI, como body biasing dinâmico, o STM32V8 consegue equilibrar alto desempenho com consumo otimizado, algo essencial em aplicações industriais e embarcadas que operam continuamente.

Em resumo, a arquitetura de memória do STM32V8 foi concebida para remover gargalos históricos dos microcontroladores de alto desempenho, oferecendo uma plataforma onde execução direta da memória, acesso previsível e alto paralelismo são características intrínsecas. Na próxima seção, o foco será a integração de periféricos, interfaces e capacidades de sistema, analisando como o STM32V8 se posiciona em aplicações reais de automação, controle e edge computing.

Periféricos, Interfaces e Aplicações Práticas do STM32V8

Além do avanço significativo em núcleo, processo de fabricação e arquitetura de memória, o STM32V8 foi concebido como um microcontrolador altamente integrado, capaz de atender sistemas complexos sem a necessidade de circuitos externos adicionais. A ST mantém a filosofia histórica da família STM32: oferecer um ecossistema robusto de periféricos, com forte integração a ferramentas de software e suporte de longo prazo, agora elevado a um novo patamar de desempenho.

Embora a publicação oficial foque principalmente nos avanços tecnológicos de processo e memória, o posicionamento do STM32V8 indica claramente a presença de um conjunto completo de periféricos de alto desempenho, incluindo temporizadores avançados, interfaces de comunicação industriais e subsistemas de conversão analógica. Esses recursos são essenciais para aplicações que combinam controle em tempo real, aquisição de sinais e processamento intensivo em um único dispositivo.

No contexto de controle e automação, temporizadores de alta resolução e baixo jitter permitem a implementação de controle de motores, conversores de potência, robótica e sistemas mecatrônicos com precisão elevada. A capacidade de executar algoritmos complexos diretamente no MCU possibilita a adoção de técnicas mais sofisticadas, como controle preditivo, observadores de estado e filtragem adaptativa, sem comprometer os requisitos temporais do sistema.

As interfaces de comunicação desempenham um papel central no posicionamento do STM32V8 em aplicações modernas. Protocolos seriais de alta velocidade, combinados com suporte a comunicação determinística, tornam o dispositivo adequado para redes industriais, sistemas distribuídos e edge computing. Em aplicações conectadas, o alto desempenho do núcleo Cortex-M85 permite que pilhas de comunicação, criptografia e segurança sejam executadas em paralelo com tarefas de controle e processamento de sinais.

Um aspecto particularmente relevante é a viabilidade prática de consolidar múltiplas funções em um único microcontrolador. Em projetos tradicionais, seria comum dividir responsabilidades entre um MCU de controle e um processador dedicado a processamento de sinais ou inferência de IA. Com o STM32V8, essa separação se torna desnecessária em muitos casos, reduzindo custo de hardware, consumo energético, complexidade de software e pontos potenciais de falha.

Do ponto de vista de desenvolvimento, o STM32V8 se beneficia diretamente do ecossistema já consolidado da ST, incluindo STM32Cube, bibliotecas HAL e LL, suporte a RTOS, além de integração com ferramentas de depuração e profiling. Isso reduz significativamente a curva de aprendizado, permitindo que equipes que já dominam a família STM32 migrem para o STM32V8 sem ruptura conceitual, mesmo diante de uma arquitetura significativamente mais avançada.

Em aplicações práticas, o STM32V8 se posiciona como uma plataforma ideal para manutenção preditiva, monitoramento inteligente, processamento de sinais vibroacústicos, edge AI industrial, instrumentação avançada e sistemas ciberfísicos. A capacidade de executar algoritmos complexos localmente, com baixa latência e alto grau de determinismo, atende diretamente às demandas atuais da Indústria 4.0 e de sistemas embarcados inteligentes.

Na próxima seção, será apresentada uma comparação técnica objetiva entre o STM32V8 e o Renesas RA8M1, destacando semelhanças, diferenças arquiteturais e cenários em que cada plataforma se mostra mais adequada.

Seção 6 – Comparação Técnica: STM32V8 versus Renesas RA8M1

A comparação entre o STM32V8, da STMicroelectronics, e o Renesas RA8M1 é particularmente relevante porque ambos são baseados no núcleo Arm Cortex-M85 e se posicionam no segmento de microcontroladores de altíssimo desempenho. Apesar dessa similaridade fundamental, as duas plataformas adotam estratégias arquiteturais distintas, refletindo visões diferentes sobre escalabilidade, memória, eficiência energética e foco de aplicação.

Do ponto de vista de núcleo e capacidade computacional, ambos utilizam o Cortex-M85 com suporte às extensões Helium (MVE), o que garante excelente desempenho em DSP e workloads de machine learning. No entanto, o STM32V8 se beneficia diretamente do processo de fabricação em 18 nm FD-SOI, permitindo frequências mais elevadas e melhor controle de consumo dinâmico em comparação ao RA8M1, que é fabricado em um processo CMOS mais convencional. Na prática, isso favorece o STM32V8 em aplicações que exigem desempenho sustentado com controle térmico rigoroso.

A diferença mais marcante entre as duas plataformas está no sistema de memória não volátil. O Renesas RA8M1 utiliza Flash embutida tradicional, complementada por uma quantidade significativa de SRAM. Essa abordagem é madura, amplamente conhecida e bem suportada por ferramentas, mas impõe limitações de latência e escalabilidade em altas frequências. O STM32V8, por outro lado, elimina a Flash e adota memória PCM, oferecendo menor latência de acesso, maior previsibilidade temporal e melhor adequação a nós tecnológicos avançados. Para aplicações em tempo real estrito, essa diferença é particularmente relevante.

Em termos de arquitetura de execução, o STM32V8 apresenta vantagens claras na execução direta da memória não volátil (XIP) sem penalidades significativas, enquanto o RA8M1 pode exigir estratégias adicionais, como cache ou cópia seletiva de código para RAM, em aplicações mais exigentes. Isso impacta diretamente a complexidade do firmware e o esforço de otimização por parte do desenvolvedor.

No campo da eficiência energética, ambos os dispositivos são projetados para aplicações embarcadas modernas, mas o uso de FD-SOI no STM32V8 introduz recursos adicionais, como body biasing dinâmico, que permitem ajustes finos entre desempenho e consumo em tempo de execução. O RA8M1 mantém uma abordagem mais tradicional, eficiente e confiável, porém com menor flexibilidade nesse aspecto específico.

Do ponto de vista de ecossistema e maturidade, o RA8M1 se beneficia da forte integração com o Renesas Flexible Software Package (FSP), oferecendo uma pilha de software bem estruturada e voltada para aplicações industriais e comerciais. O STM32V8, por sua vez, herda o vasto ecossistema STM32Cube, amplamente difundido, com suporte consolidado a RTOS, middleware e ferramentas de desenvolvimento, o que pode representar uma vantagem estratégica para equipes já familiarizadas com o universo STM32.

Em síntese, o Renesas RA8M1 se apresenta como uma plataforma robusta, madura e altamente capaz para aplicações industriais de alto desempenho, enquanto o STM32V8 avança além, explorando novas tecnologias de fabricação e memória para atingir um nível superior de desempenho, previsibilidade e escalabilidade futura. A escolha entre as duas soluções dependerá diretamente dos requisitos do projeto, especialmente no que se refere a latência, consumo, longevidade tecnológica e complexidade de software aceitável.

Na próxima e última seção, será apresentada a conclusão do artigo, seguida da lista de fontes utilizadas, conforme solicitado.

Seção 7 – Conclusão e Fontes

Conclusão

O STM32V8 representa um marco importante na evolução dos microcontroladores, não apenas dentro do portfólio da STMicroelectronics, mas no mercado de sistemas embarcados como um todo. Ao combinar o núcleo Arm Cortex-M85 com um processo de fabricação avançado em 18 nm FD-SOI e a adoção inédita de memória PCM, a ST redefine os limites tradicionais entre microcontroladores e microprocessadores de entrada. Essa abordagem permite alcançar níveis de desempenho, eficiência energética e previsibilidade temporal que antes exigiam arquiteturas mais complexas.

Do ponto de vista técnico, o STM32V8 se destaca pela execução eficiente de DSP e inteligência artificial embarcada, suportada por extensões vetoriais Helium e por uma arquitetura de memória capaz de sustentar altas taxas de processamento sem os gargalos clássicos da Flash. Para o desenvolvedor, isso se traduz em projetos mais simples, com menor necessidade de otimizações manuais, cópias de código para RAM ou uso de dispositivos auxiliares.

Na comparação com o Renesas RA8M1, fica evidente que ambas as plataformas ocupam o topo do segmento Cortex-M. Entretanto, o STM32V8 adota uma postura mais agressiva em termos de inovação tecnológica, priorizando escalabilidade futura, menor latência e maior flexibilidade energética. Já o RA8M1 se posiciona como uma solução madura, robusta e alinhada a arquiteturas tradicionais, o que pode ser uma vantagem em projetos que valorizam estabilidade e continuidade de design.

Em aplicações práticas, o STM32V8 surge como uma plataforma especialmente atraente para automação industrial avançada, edge AI, manutenção preditiva, instrumentação inteligente, robótica e sistemas ciberfísicos, onde alto desempenho, determinismo e integração são requisitos fundamentais. Seu lançamento sinaliza uma tendência clara: o futuro dos microcontroladores passa pela convergência entre computação intensiva, eficiência energética e inteligência embarcada.

Fontes Utilizadas

1. STMicroelectronics – Press Release
   ST unveils STM32V8 microcontroller with embedded phase-change memory on 18nm FD-SOI technology
   Disponível em:
   https://newsroom.st.com/media-center/press-item.html/p4733.html
2. Renesas Electronics – RA8M1 Product Page
   RA8M1 – 480 MHz Arm Cortex-M85 MCU
   Disponível em:
   https://www.renesas.com/en/products/ra8m1

The post STM32V8: o novo microcontrolador da ST com Cortex-M85, PCM e tecnologia 18 nm FD-SOI first appeared on MCU & FPGA.

Quando trabalhamos com áudio em sistemas embarcados (como um ESP32-P4), é muito comum pensar apenas em tempo e frequência: sinal no tempo, depois FFT para ver o espectro, aplicar filtros, etc. Porém, há situações em que olhar somente o espectro de magnitude não é suficiente para separar os “componentes” de interesse do sinal:

• Separar o conteúdo de excitação (por exemplo, cordas vocais ou fonte sonora) do “formante” ou ressonâncias do sistema (trato vocal, sala, caixa acústica).
• Identificar ecos ou reverberações (reflexões) embutidos no sinal.
• Estimar pitch (frequência fundamental da voz) mesmo em ambientes ruidosos ou com filtragem forte.
• Detectar características de envoltória espectral (timbre) independentemente da excitação instantânea.

A análise cepstral foi criada justamente para isso: ela “desfaz” a convolução no domínio da frequência ao transformar multiplicações em somas usando o logaritmo, e depois aplica novamente uma transformada inversa. Isso gera um novo domínio de análise – não mais tempo, nem frequência – mas o domínio da quefrequência.

Conceito intuitivo de Quefrequência

O termo “quefrequência” é um trocadilho proposital com “frequency” (frequência). A ideia é:

• No domínio da frequência, o eixo horizontal é a frequência ( f ) (Hz).
• Na análise cepstral, depois de aplicar log do espectro e uma transformada inversa, o eixo horizontal passa a ter unidade de tempo, mas não é o tempo original do sinal; é um “tempo de periodicidade” derivado da estrutura de frequência.
• Como essa variável não é exatamente o tempo do domínio original, nem a frequência, foi dado o nome de quefrequência e a unidade de queferência (em segundos ou amostras, mas interpretada como “período da estrutura espectral”).

Intuitivamente:

• Picos de periodicidade de pitch aparecem como picos em quefrequência correspondendo ao período fundamental do sinal.
• A envoltória lenta do espectro (por exemplo, os formantes da voz ou a resposta de uma sala) aparece concentrada em baixas quefrequências.
• Componentes mais “rápidos” do espectro (finas linhas espectrais, harmônicos) aparecem em quefrequências mais altas.

Isso permite “separar no eixo da quefrequência” aquilo que queremos analisar:

• Baixa quefrequência → envoltória espectral (formantes, timbre, resposta de sistema).
• Alta quefrequência → detalhes finos da excitação (harmônicos, rugosidade, etc.).

Em processamento de voz, isso tem aplicações clássicas:

• Modelagem fonte–filtro: a fala é modelada como excitação (cordas vocais ou ruído glótico) passando por um filtro (trato vocal). A análise cepstral permite separar esses dois componentes.
• Reconhecimento de fala: coeficientes cepstrais (por exemplo, MFCC – Mel Frequency Cepstral Coefficients) são onipresentes em sistemas de ASR.
• Equalização e cancelamento de eco: a estrutura de eco pode ser observada no domínio cepstral e tratada de forma mais clara em alguns cenários.

No contexto do ESP32-P4 e de sistemas embarcados em geral, a análise cepstral é interessante porque:

• Pode ser implementada em cima de FFTs já disponíveis (bibliotecas de DSP, ESP-DSP, etc.).
• É computacionalmente viável para janelas de áudio de tamanho moderado.
• Fornece uma representação compacta do sinal (poucos coeficientes cepstrais podem ser suficientes para muitos algoritmos de decisão, classificação ou detecção).

Visão global do fluxo de análise cepstral

Sem entrar ainda nos detalhes matemáticos (que virão na próxima seção), o fluxo básico é:

1. Janelação do sinal no tempo
   Pegamos um bloco de amostras \( x[n] \) (por exemplo, 256, 512 ou 1024 amostras) e aplicamos uma janela \( w[n] \) (Hann, Hamming, etc.) para reduzir descontinuidades.
2. Transformada de Fourier (FFT)
   Calculamos o espectro complexo:
   \[
   X[k] = \text{FFT}{ x[n] \cdot w[n] }
   \]
   Obtemos magnitude (|X[k]|) e fase \(\angle X[k]\).
3. Logaritmo da magnitude
   Calculamos o logaritmo \(natural ou base 10\) da magnitude:
   \[
   Y[k] = \log(|X[k]|)
   \]
   Isso transforma produtos (decorrentes da convolução no tempo) em somas no domínio espectral.
4. Transformada de Fourier inversa (IFFT)
   Fazemos a IFFT de ( Y[k] ):
   \[
   c[n] = \text{IFFT}{ Y[k] }
   \]
   O sinal \( c[n] \) é o cepstro do quadro de áudio, e o índice ( n ) agora é interpretado como quefrequência.
5. Análise dos coeficientes cepstrais
   • Coeficientes próximos de ( n = 0 ) (baixa quefrequência) descrevem a envoltória lenta do espectro.
   • Coeficientes em quefrequências maiores podem indicar periodicidade (pitch) e detalhes finos.

Na prática, em um ESP32-P4, esse fluxo pode ser implementado em tempo quase real, usando:

• DMA + I2S para adquirir áudio.
• FFT otimizada em ponto fixo ou flutuante (conforme os recursos).
• Um pipeline de janelas de áudio para extrair cepstro quadro a quadro (por exemplo, a cada 10–20 ms).

Nas próximas seções, vamos:

1. Escrever as fórmulas matemáticas formais da análise cepstral (domínio contínuo e discreto, convolução, FFT, log-espectro, IFFT, quefrequência).
2. Discutir a interpretação física e prática do cepstro e da quefrequência, com exemplos típicos em áudio.
3. Apresentar códigos em C para ESP32-P4, com:
   • Aquisição de áudio (mock ou usando I2S).
   • Cálculo da FFT, log-espectro e IFFT para obter o cepstro.
   • Extração de coeficientes de baixa quefrequência para uso em algoritmos de decisão (por exemplo, detecção de voz, pitch simplificado, ou caracterização de timbre).

2 – Fundamentos Matemáticos da Análise Cepstral e da Quefrequência

A análise cepstral nasce da necessidade de separar efeitos de convolução entre um sinal de excitação e a resposta de um sistema. Em áudio, isso aparece no modelo clássico fonte–filtro, mas o conceito é geral: sempre que um sinal ( x(t) ) resulta da convolução entre dois sinais ( s(t) ) e ( h(t) ), o cepstro ajuda a separar essas contribuições.

2.1 O ponto de partida: convolução no tempo → multiplicação na frequência

Seja um sinal:

\[
x(t) = s(t) * h(t)
\]

onde:

• \( s(t) \): excitação (por exemplo, vibrato das cordas vocais).
• \( h(t) \): filtro (por exemplo, trato vocal ou resposta de uma sala).

Pela transformada de Fourier:

\[
X(\omega) = S(\omega) \cdot H(\omega)
\]

A multiplicação complica a interpretação do espectro quando queremos isolar \( S(\omega) \) e \( H(\omega) \).
A solução clássica é aplicar logaritmo:

\[
\log |X(\omega)| = \log |S(\omega)| + \log |H(\omega)|
\]

Isto é fundamental: o log converte produtos em somas, tornando possível uma “separação” térmica entre efeitos rápidos e lentos no domínio espectral.

2.2 Cepstro como IFFT do log-espectro

A definição formal do cepstro real é:

\[
c(t) = \mathcal{F}^{-1}\left{ \log |X(\omega)| \right}
\]

O sinal \( c(t) \) não está mais no domínio do tempo original. O eixo ( t ) passa a ser interpretado como quefrequência, e sua unidade não é frequência, mas sim algo dimensionalmente equivalente ao tempo — porém não o tempo físico.

Por isso, usa-se notação humorística criada pelo grupo de Bogert (inventores do cepstro):

• tempo → quetime
• frequência → quefrequência
• espectro → espectro
• cepstro → cepstrum
• convolução → convolução
• filtro → lifter (filtro no domínio do cepstro)

No domínio discreto, para uma janela ( x[n] ), temos:

\[
X[k] = \text{FFT}{x[n]}
\]

\[
C[n] = \text{IFFT}\left{\log(|X[k]|)\right}
\]

onde:

• \( k = 0, 1, …, N-1 \) é o índice de frequência,
• \( n = 0, 1, …, N-1 \) é o índice de quefrequência.

2.3 Separação entre excitação e envoltória espectral

A interpretação prática decorre da análise de periodicidades:

• A excitação ( s(t) ), quando periódica (como voz sonora), gera um espectro composto por harmônicos espaçados.
  Esses harmônicos introduzem padrões rápidos no espectro → aparecem em quefrequências altas.
• O filtro ( h(t) ) representa a forma da garganta, microfone, sala, etc., produzindo variações lentas na magnitude espectral (formantes, equalização).
  Essas variações lentas → aparecem em quefrequências baixas.

Portanto:

\[
C[n] = C_s[n] + C_h[n]
\]

e como:

• \( C_h[n] \) está concentrado em pequenos valores de ( n ),
• \( C_s[n] \) está concentrado em valores mais altos,

fica simples isolá-los truncando ou filtrando o cepstro.

2.4 Pitch a partir da quefrequência

Se o sinal contém um período dominante \( T_0 \), sua frequência fundamental é:

\[
f_0 = \frac{1}{T_0}
\]

No domínio cepstral, surge um pico aproximadamente em:

\[
n_0 \approx \frac{T_0}{\Delta t}
\]

onde \( \Delta t = \frac{1}{f_s} \) é o período de amostragem.

Por exemplo, em voz humana, com pitch entre 80 e 300 Hz:

• \( T_0 \approx 3,3 \text{ ms a } 12,5 \text{ ms} \)
• Em um sistema com 16 kHz de amostragem: \[
  n_0 \approx [53\text{ a }200] \text{ amostras}
  \]

Assim, basta procurar o máximo do cepstro em uma faixa adequada.

2.5 Cepstro em sistemas embarcados: por que é eficiente?

A análise cepstral é muito eficiente computacionalmente porque:

• Reutiliza FFT/IFFT já comuns em DSP.
• Usa apenas operações elementares (log, magnitude, FFT inversa).
• Pode ser reduzida a poucos coeficientes (por exemplo, primeiros 12 CEPSTRAIS).

Isso torna o método adequado para o ESP32-P4, que conta com:

• Núcleos de processamento de 32 bits com boa capacidade de DSP.
• Instruções aceleradas para MACs e operações vetoriais.
• Suporte a bibliotecas otimizadas, como ESP-DSP.

3 – Interpretação Prática da Quefrequência em Áudio

A análise cepstral não é apenas uma manobra matemática elegante; ela é extremamente prática quando lidamos com sinais acústicos reais. Nesta seção, vamos interpretar o que significa observar um sinal no domínio da quefrequência e como isso permite separar componentes que, no domínio da frequência tradicional, aparecem misturados.

3.1 Separação Fonte–Filtro: o coração da análise cepstral

Em áudio — especialmente em voz e instrumentos — um modelo universal é:

\[
x(t) = s(t) * h(t)
\]

onde:

• \( s(t) \) é a excitação (cordas vocais, palheta, ruído, golpe mecânico),
• \( h(t) \) é o filtro acústico (trato vocal, corpo do instrumento, caixa acústica, reverberação).

Esse modelo implica:

\[
X(\omega) = S(\omega)\cdot H(\omega)
\]

Quando analisamos o espectro convencional, os efeitos de excitação e filtro aparecem multiplicados. O buraco que a análise cepstral preenche é justamente desmultiplicar esses efeitos — o que não é possível diretamente através da FFT, mas se torna possível usando o log-espectro + IFFT.

O que acontece no cepstro?

Após o processo:

\[
C[n] = \text{IFFT}{\log(|X[k]|)},
\]

a estrutura se reorganiza de forma surpreendente:

• Variações lentas do espectro (formantes, equalização, formato do corpo do instrumento) aparecem próximas de n = 0.
• Variações rápidas, como harmônicos resultantes de excitações periódicas, aparecem em quefrequências maiores.

É como se a análise cepstral “esticava” o espectro em um domínio onde cada tipo de efeito possui uma assinatura clara e separável.

3.2 Estimativa de Pitch (Fundamental) no Cepstro

Uma das aplicações mais conhecidas do cepstro é a detecção de pitch.

Considere um sinal periódico com período fundamental \( T_0 \). Um espectro composto por harmônicos cria uma estrutura repetitiva. O log-espectro evidencia essas repetições e a IFFT devolve um pico em:

\[
n_0 \approx \frac{T_0}{\Delta t},
\quad \Delta t = \frac{1}{f_s}.
\]

Interpretando:

• O pico ocorre aproximadamente na quefrequência que representa o período do sinal.
• Assim, basta localizar o máximo em uma janela adequada para extrair pitch.

Exemplo prático:

Para amostragem a 16 kHz e pitch de 200 Hz:

\[
T_0 = 5 \text{ ms} \quad \Rightarrow \quad n_0 \approx 80.
\]

Logo, buscar picos entre 50 e 250 amostras é suficiente para detectar a maior parte da voz humana.

Essa abordagem funciona bem mesmo quando:

• O espectro está suavizado,
• Há ruído moderado,
• O sinal sofreu filtragens/acústicas conhecidas ou não lineares.

3.3 Detecção de Envoltória Espectral (Timbre)

Os primeiros coeficientes do cepstro representam a envelopa espectral, que define o timbre de instrumentos e da voz.

Em reconhecimento de fala, isso inspira técnicas clássicas como:

• LPC (Linear Predictive Coding),
• MFCC (Mel-Frequency Cepstral Coefficients).

A ideia é simples:

• Os coeficientes de baixa quefrequência capturam a forma geral do espectro.
• Pequenos conjuntos (12 a 20 coeficientes) representam bem o timbre.

Isso se torna extremamente útil em sistemas embarcados para:

• Classificação de sons (porta batendo, voz, motor, música).
• Detecção de eventos acústicos (EDA).
• Reconhecimento de comandos por voz com baixa complexidade.

3.4 Detecção de Eco e Reverberação

Uma propriedade menos conhecida — mas muito poderosa — é a capacidade de observar ecos no domínio cepstral.

Quando um eco ocorre com atraso \( \tau \), a convolução com uma versão atrasada do sinal adiciona um componente periódico no espectro. No cepstro, isso aparece como um pico em:

\[
n_\tau \approx \frac{\tau}{\Delta t}.
\]

Exemplo:

• Um eco com 10 ms de atraso → pico na quefrequência correspondente a 10 ms.
• Uma reverberação mais longa produz uma faixa de quefrequências com energia distribuída.

Isso é útil para:

• Cancelamento de eco,
• Algoritmos de de-reverberação,
• Diagnóstico acústico (testes de salas, tubulações, painéis mecânicos).

3.5 Resumo interpretativo da quefrequência

Este mapeamento orienta como “ler” um cepstro e como projetar algoritmos que exploram o método.

4 – Implementação Prática da Análise Cepstral no ESP32-P4

Nesta seção entramos no nível operacional: como implementar, no ESP32-P4, o pipeline completo da análise cepstral — desde a captura de áudio até a obtenção do vetor de coeficientes no domínio da quefrequência.

O ESP32-P4 possui um núcleo de desempenho superior às gerações anteriores, com instruções otimizadas para DSP, permitindo executar FFT/IFFT e operações vetoriais com boa eficiência mesmo em janelas de 512 ou 1024 amostras. A biblioteca ESP-DSP facilita bastante esse processo, pois contém FFTs altamente otimizadas.

A seguir, apresento o pipeline completo e exemplos de código baseados no ESP-IDF + ESP-DSP.

4.1 Pipeline de processamento do cepstro

O processo no microcontrolador segue:

1. Capturar um quadro de áudio via I2S (1024 amostras, por exemplo).
2. Aplicar janela Hann ou Hamming.
3. Fazer FFT real → espectro complexo.
4. Obter magnitude.
5. Aplicar logaritmo.
6. Fazer IFFT para obter o cepstro.
7. Analisar quefrequências de interesse.

Representando matematicamente para ( N ) amostras:

\[
X[k] = \text{FFT}{ x[n] \cdot w[n] }
\]

\[
Y[k] = \log(|X[k]| + \epsilon)
\]

\[
C[n] = \text{IFFT}{ Y[k] }
\]

O termo \( \epsilon \) evita log(0), tipicamente \( \epsilon = 10^{-12} \).

4.2 Estrutura básica do código no ESP32-P4

A seguir um esqueleto funcional em C, com comentários detalhados e adequado ao ESP-IDF.

Inclui:

• Janela Hann
• FFT real
• Cálculo de magnitude + log
• IFFT
• Extração de pitch via busca de máximo na faixa de quefrequência

Código: Inicialização do módulo DSP

/**
 * @brief Inicializa a biblioteca ESP-DSP para FFTs
 */
static void init_dsp()
{
    // Inicializa tabelas de FFT internas.
    dsps_fft2r_init_fc32(NULL, CONFIG_DSP_MAX_FFT_SIZE);
}

/**
 * @brief Inicializa a biblioteca ESP-DSP para FFTs
 */
static void init_dsp()
{
    // Inicializa tabelas de FFT internas.
    dsps_fft2r_init_fc32(NULL, CONFIG_DSP_MAX_FFT_SIZE);
}

4.3 Aplicação da janela Hann

/**
 * @brief Aplica janela Hann ao buffer de entrada
 */
static void apply_hann(float *data, int N)
{
    for (int n = 0; n < N; n++) {
        float w = 0.5f * (1 - cosf((2 * M_PI * n) / (N - 1)));
        data[n] *= w;
    }
}

/**
 * @brief Aplica janela Hann ao buffer de entrada
 */
static void apply_hann(float *data, int N)
{
    for (int n = 0; n < N; n++) {
        float w = 0.5f * (1 - cosf((2 * M_PI * n) / (N - 1)));
        data[n] *= w;
    }
}

4.4 FFT + cálculo da magnitude + log

void compute_log_spectrum(const float *input, float *log_spec, int N)
{
    // Buffer complexo para FFT (intercalado real/imag)
    static float fft_buf[2048];

    // Copia entrada para buffer da FFT
    for (int i = 0; i < N; i++) {
        fft_buf[2*i]   = input[i]; // parte real
        fft_buf[2*i+1] = 0.0f;     // parte imaginária
    }

    // FFT real
    dsps_fft2r_fc32(fft_buf, N);
    dsps_bit_rev_fc32(fft_buf, N);

    // Calcula magnitude e log
    for (int k = 0; k < N; k++) {
        float real = fft_buf[2*k];
        float imag = fft_buf[2*k+1];
        float mag  = sqrtf(real*real + imag*imag);
        log_spec[k] = logf(mag + 1e-12f);
    }
}

void compute_log_spectrum(const float *input, float *log_spec, int N)
{
    // Buffer complexo para FFT (intercalado real/imag)
    static float fft_buf[2048];

    // Copia entrada para buffer da FFT
    for (int i = 0; i < N; i++) {
        fft_buf[2*i]   = input[i]; // parte real
        fft_buf[2*i+1] = 0.0f;     // parte imaginária
    }

    // FFT real
    dsps_fft2r_fc32(fft_buf, N);
    dsps_bit_rev_fc32(fft_buf, N);

    // Calcula magnitude e log
    for (int k = 0; k < N; k++) {
        float real = fft_buf[2*k];
        float imag = fft_buf[2*k+1];
        float mag  = sqrtf(real*real + imag*imag);
        log_spec[k] = logf(mag + 1e-12f);
    }
}

4.5 IFFT para obter o Cepstro

void compute_cepstrum(const float *log_spec, float *cep, int N)
{
    static float buf[2048];

    // Copia log-espectro para o buffer complexo
    for (int k = 0; k < N; k++) {
        buf[2*k]   = log_spec[k];
        buf[2*k+1] = 0.0f;
    }

    // IFFT
    dsps_fft2r_fc32(buf, N);
    dsps_bit_rev_fc32(buf, N);

    // Saída real do cepstro
    for (int n = 0; n < N; n++) {
        cep[n] = buf[2*n] / N; // normalização
    }
}

void compute_cepstrum(const float *log_spec, float *cep, int N)
{
    static float buf[2048];

    // Copia log-espectro para o buffer complexo
    for (int k = 0; k < N; k++) {
        buf[2*k]   = log_spec[k];
        buf[2*k+1] = 0.0f;
    }

    // IFFT
    dsps_fft2r_fc32(buf, N);
    dsps_bit_rev_fc32(buf, N);

    // Saída real do cepstro
    for (int n = 0; n < N; n++) {
        cep[n] = buf[2*n] / N; // normalização
    }
}

4.6 Extração de pitch a partir da quefrequência

O pitch aparece como o pico dominante em uma faixa de quefrequências que representa períodos possíveis da excitação.

Por exemplo, para voz humana em 16 kHz:

• pitch de 80–300 Hz → períodos entre 3,3 ms e 12,5 ms → 53–200 amostras.

/**
 * @brief Estima pitch a partir do cepstro
 *
 * @param cep      Vetor de cepstro
 * @param fs       Taxa de amostragem
 * @param N        Tamanho do cepstro
 *
 * @return Frequência fundamental estimada
 */
float estimate_pitch_from_cepstrum(const float *cep, int fs, int N)
{
    int min_q = fs / 300; // ~53
    int max_q = fs / 80;  // ~200

    int max_index = min_q;
    float max_val = cep[min_q];

    for (int n = min_q; n < max_q; n++) {
        if (cep[n] > max_val) {
            max_val   = cep[n];
            max_index = n;
        }
    }

    // período estimado
    float T0 = (float)max_index / fs;

    return 1.0f / T0;
}

/**
 * @brief Estima pitch a partir do cepstro
 *
 * @param cep      Vetor de cepstro
 * @param fs       Taxa de amostragem
 * @param N        Tamanho do cepstro
 *
 * @return Frequência fundamental estimada
 */
float estimate_pitch_from_cepstrum(const float *cep, int fs, int N)
{
    int min_q = fs / 300; // ~53
    int max_q = fs / 80;  // ~200

    int max_index = min_q;
    float max_val = cep[min_q];

    for (int n = min_q; n < max_q; n++) {
        if (cep[n] > max_val) {
            max_val   = cep[n];
            max_index = n;
        }
    }

    // período estimado
    float T0 = (float)max_index / fs;

    return 1.0f / T0;
}

4.7 Extração dos primeiros coeficientes cepstrais (para classificação)

Em muita aplicações (classificação acústica, detecção de eventos), apenas os primeiros coeficientes cepstrais são necessários.

/**
 * @brief Copia os primeiros M coeficientes do cepstro
 */
void extract_cepstral_coeffs(const float *cep, float *out, int M)
{
    for (int i = 0; i < M; i++) {
        out[i] = cep[i];
    }
}

/**
 * @brief Copia os primeiros M coeficientes do cepstro
 */
void extract_cepstral_coeffs(const float *cep, float *out, int M)
{
    for (int i = 0; i < M; i++) {
        out[i] = cep[i];
    }
}

4.8 Pipeline completo (função principal)

void process_audio_frame(float *frame, int N, int fs)
{
    static float log_spec[1024];
    static float cep[1024];

    apply_hann(frame, N);
    compute_log_spectrum(frame, log_spec, N);
    compute_cepstrum(log_spec, cep, N);

    float pitch = estimate_pitch_from_cepstrum(cep, fs, N);

    printf("Pitch estimado: %.2f Hz\n", pitch);
}

void process_audio_frame(float *frame, int N, int fs)
{
    static float log_spec[1024];
    static float cep[1024];

    apply_hann(frame, N);
    compute_log_spectrum(frame, log_spec, N);
    compute_cepstrum(log_spec, cep, N);

    float pitch = estimate_pitch_from_cepstrum(cep, fs, N);

    printf("Pitch estimado: %.2f Hz\n", pitch);
}

4.9 Observações de implementação no ESP32-P4

1. Memória
   FFT de 1024 pontos requer buffers complexos de 2048 floats → 8 KB.
   O ESP32-P4 suporta isso confortavelmente.
2. Desempenho
   Com clock adequado, é possível analisar um quadro de 1024 amostras em menos de 5 ms.
3. Precisão
   Sugere-se usar float (32 bits). Em sistemas críticos, é possível migrar para ponto fixo.
4. Aquisição de áudio real
   Basta integrar esta pipeline à captura I2S + DMA, substituindo o frame[] preenchido por dados do ADC/I2S.

5 – Conclusão e Aplicações Práticas em Sistemas Embarcados

A análise cepstral — e, em particular, a interpretação do sinal no domínio da quefrequência — é uma das ferramentas mais poderosas e versáteis no processamento moderno de áudio. Seu ponto forte é justamente possibilitar a separação matemática e prática entre efeitos que, no domínio da frequência convencional, aparecem misturados de forma inseparável.

Ao longo deste artigo, vimos que:

• O cepstro transforma convoluções em somas através da operação log-espectral + IFFT.
• Esse processo reorganiza o conteúdo espectral, permitindo distinguir excitação, resposta acústica, pitch, ecos e timbre.
• A quefrequência interpreta periodicidades espectrais (não temporais), revelando padrões profundos do sinal.
• Em voz, permite separar fonte–filtro e detectar frequência fundamental mesmo sob ruído ou filtragem.
• Em instrumentação, auxilia na detecção de defeitos, ecos estruturais, vibrações periódicas e assinaturas mecânicas.
• Em classificação de eventos acústicos, os primeiros coeficientes cepstrais são extremamente eficientes — compactos, robustos e amigáveis para algoritmos embarcados.

Do ponto de vista de implementação embarcada:

• A análise cepstral é inteiramente viável no ESP32-P4, graças às instruções DSP nativas e ao suporte da biblioteca ESP-DSP.
• Um pipeline típico com janelas de 1024 amostras pode ser processado em tempo real com folga, mesmo associado a I2S + DMA.
• O código apresentado pode servir como base para:
  • Detecção de voz (VAD);
  • Estimativa de pitch;
  • Extração de coeficientes cepstrais para classificadores;
  • Estudo de reverberações e ecos;
  • Detecção de falhas mecânicas via áudio/vibração.

A análise cepstral é especialmente adequada para sistemas embarcados modernos que precisam extrair significado de sinais sonoros complexos, mantendo consumo moderado de memória e CPU. Ela combina rigor matemático, elegância teórica e elevada eficiência prática — por isso permanece um dos pilares do processamento de áudio desde os anos 1960 até hoje.

The post Quefrequência e Análise Cepstral: Uma Introdução Prática para Sistemas Embarcados (ESP32-P4) first appeared on MCU & FPGA.

A proposta da Arm com a introdução do Cortex-M55 foi clara: fornecer um núcleo que atendesse às demandas cada vez maiores de aplicações em borda (edge computing) — especialmente em setores como automação industrial, wearables, áudio embarcado, sensores inteligentes e assistentes de voz —, mantendo a compatibilidade com as ferramentas já bem estabelecidas na cadeia Cortex-M.

Com isso, os desenvolvedores que já trabalham com Cortex-M encontram no M55 um ambiente evolutivo, com ganhos de desempenho e eficiência energética, mas sem abrir mão da familiaridade da arquitetura Armv8.1-M. E, principalmente, passam a contar com um conjunto de instruções vetoriais que reduz drasticamente o tempo de execução de operações típicas de sinais e redes neurais.

A seguir, mergulharemos nos principais diferenciais da extensão Helium, seus impactos no desempenho, seus benefícios adicionais e exemplos práticos de uso em aplicações reais com CMSIS-DSP e TensorFlow Lite Micro.

Suporte Helium com o Processador Cortex-M55

A tecnologia Helium foi projetada como uma extensão vetorial da arquitetura Armv8.1-M, e o Cortex-M55 é o primeiro núcleo da família Cortex-M a implementá-la completamente. Diferente de instruções SIMD tradicionais (como as encontradas em processadores DSP dedicados), Helium oferece uma abordagem mais granular e integrada ao pipeline do núcleo, permitindo processamento paralelo de dados vetorizados em um único ciclo de instrução, com maior eficiência.

O conjunto de instruções Helium é capaz de operar com dados de 8, 16 ou 32 bits de forma vetorial, armazenados em registradores de 128 bits (denominados Q0–Q7). Isso habilita o processamento de quatro dados de 32 bits, oito de 16 bits ou dezesseis de 8 bits de maneira simultânea, aumentando exponencialmente o throughput em operações vetoriais típicas de DSP e ML.

Arquitetura do suporte vetorial

A unidade de execução vetorial no M55 é independente do pipeline escalar. Isso significa que instruções vetoriais podem ser processadas com alto grau de paralelismo, com suporte a:

• Saturação aritmética (essencial para processamento de áudio e sensores),
• Operações MAC vetoriais (Multiply-Accumulate),
• Conversões de tipos (por exemplo, de q7_t para q15_t ou float32_t),
• Manipulação vetorial com predicação (uso de máscaras para controle de elementos).

Além disso, o Helium se integra totalmente com o CMSIS-DSP e o CMSIS-NN, que são bibliotecas otimizadas mantidas pela própria Arm para acelerar operações matemáticas, filtragem, FFT, convoluções e inferência de redes neurais — sem a necessidade de codificar diretamente em assembly.

Ferramentas de desenvolvimento

O ecossistema de desenvolvimento já oferece ferramentas com suporte ao Helium:

• Compiladores Armclang e GCC (com flags específicas para ativar Helium: -march=armv8.1-m.main+mve.fp),
• Depuradores e simuladores no Arm Keil MDK e CMSIS-Pack,
• Modelos de referência no TensorFlow Lite Micro otimizados para Helium,
• Perfis detalhados no Arm Development Studio com suporte a instruções MVE.

O suporte Helium é opcional e detectável via __ARM_FEATURE_MVE nos projetos em C, permitindo condicionalmente escrever código que utilize instruções vetoriais apenas quando disponível.

Como o Helium Acelera o Processamento Digital de Sinais e o Aprendizado de Máquina

O grande diferencial da extensão Helium reside em sua capacidade de processar dados vetorizados de maneira eficiente, reduzindo significativamente a quantidade de instruções necessárias para tarefas intensivas de cálculo, como as comumente encontradas em filtros digitais, FFTs, convoluções e operações de redes neurais.

Impacto no DSP (Digital Signal Processing)

Em aplicações DSP, como filtros FIR, IIR ou transformadas rápidas de Fourier (FFT), as operações repetitivas de multiplicação, acumulação e saturação são intensivas em tempo de CPU. Com Helium, essas operações são vetorizadas e otimizadas diretamente no hardware, gerando ganhos reais:

• Filtros FIR com múltiplas amostras por chamada são implementados com poucas instruções vetoriais, que processam blocos inteiros por vez.
• Operações FFT, como arm_cfft_q15(), ganham aceleração através de instruções especializadas de carregamento vetorial, rotação e multiplicação complexa.
• A operação MAC vetorial (VMLA, VMLAL) permite multiplicações acumulativas com saturação, reduzindo o risco de overflows e melhorando a fidelidade numérica.

Impacto no Machine Learning (ML)

Para inferência de modelos de aprendizado de máquina na borda (edge), como classificadores, detectores ou segmentadores de sinais/sensores, o Helium oferece aceleração real com eficiência energética. As bibliotecas CMSIS-NN e TensorFlow Lite Micro já possuem kernels otimizados para MVE, permitindo ganhos como:

• Redução de até 5x no tempo de inferência em redes convolucionais pequenas (CNNs).
• Suporte nativo a operações como depthwise separable convolution, pooling e quantização com aritmética inteira (Q7/Q15).
• Aproveitamento da predicação vetorial para aplicar máscaras sobre tensores (útil em atenção e normalizações).

Exemplo de código com Helium (CMSIS-DSP)

cCopiarEditar#include "arm_math.h"

#define SAMPLES 128
q15_t input[SAMPLES], output[SAMPLES];
arm_fir_instance_q15 filter;
q15_t coeffs[16];
q15_t state[16 + SAMPLES - 1];

void setup_filter() {
    arm_fir_init_q15(&filter, 16, coeffs, state, SAMPLES);
    arm_fir_q15(&filter, input, output, SAMPLES); // usa Helium se compilado com suporte MVE
}

Com suporte Helium ativo, a função arm_fir_q15() utiliza instruções MVE para realizar a filtragem de múltiplas amostras simultaneamente, acelerando o desempenho geral.

Desempenho da Extensão Helium em Benchmarks Reais

Os ganhos proporcionados pela extensão Helium não são apenas teóricos — diversos benchmarks mostram melhorias expressivas de desempenho em aplicações práticas de DSP e inferência de ML, especialmente em comparação com processadores Cortex-M tradicionais, como M4 e M7.

Comparações de Desempenho

De acordo com medições publicadas pela própria Arm e estudos com o CMSIS-DSP e CMSIS-NN, temos os seguintes ganhos médios com o Cortex-M55 equipado com Helium:

• 2x a 5x mais desempenho em filtros FIR e convoluções DSP comparado ao Cortex-M7.
• 6x mais rápido em transformadas FFT complexas de 256 pontos (em q15_t).
• 4x menos ciclos de CPU para funções como arm_max_q15() e arm_abs_q15(), graças ao paralelismo vetorial.
• Inferência de modelos quantizados com CMSIS-NN com redução de até 5x no tempo de execução, mesmo sem aceleração por NPU.

Em sistemas com suporte ao acelerador Ethos-U55 (quando acoplado ao Cortex-M55), o ganho em ML pode chegar a 50x para modelos convolucionais densos e redes com múltiplas camadas ocultas.

Eficiência Energética

Além da melhoria de tempo, o uso de instruções Helium resulta em menor uso de barramento e cache, o que se traduz diretamente em:

• Redução no consumo energético total da aplicação,
• Menor aquecimento e prolongamento da vida útil da bateria, especialmente em aplicações wearable ou IoT.

Isso torna o Cortex-M55 com Helium ideal para aplicações de borda que precisam operar por longos períodos em modo autônomo, como sensores industriais inteligentes, assistentes de voz, analisadores portáteis e monitores biomédicos.

Casos Reais

Exemplos de benchmarks baseados em código real, compilado com suporte -O3 -march=armv8.1-m.main+mve:

Estes testes foram realizados com clock fixo e sem NPU, apenas com Helium ativado e bibliotecas CMSIS otimizadas.

Benefícios Adicionais da Extensão Helium

Além do impacto direto no desempenho de aplicações DSP e de aprendizado de máquina, a extensão Helium oferece uma série de benefícios estruturais e estratégicos para quem desenvolve firmware embarcado em sistemas de alto desempenho e baixo consumo.

1. Compatibilidade com o ecossistema Cortex-M

O Helium foi desenvolvido para manter compatibilidade com o ecossistema existente da arquitetura Arm Cortex-M, o que significa que:

• Ferramentas como CMSIS-DSP, CMSIS-NN e TensorFlow Lite Micro já oferecem suporte direto.
• Código legado pode ser reaproveitado e gradualmente otimizado para instruções vetoriais.
• Não há necessidade de mudar drasticamente o estilo de desenvolvimento — o uso de Helium é incremental.

Essa abordagem reduz a curva de aprendizado e facilita a adoção em sistemas existentes, além de proteger o investimento em código já testado.

2. Modularidade e escalabilidade

O Helium permite que você escreva funções genéricas otimizadas para diferentes tamanhos de vetores, utilizando predicação e máscaras de operação. Isso torna o código:

• Mais compacto,
• Mais reutilizável,
• Mais fácil de ajustar conforme o consumo de recursos (por exemplo, reduzindo tamanho de vetor para economizar RAM).

Essa modularidade é essencial em sistemas embarcados que variam de 64 KB a 1 MB de RAM, especialmente em wearables e dispositivos IoT.

3. Otimização por predicação e controle fine-grain

Um recurso avançado do Helium é o uso de predicação vetorial. Com ela, é possível aplicar operações apenas sobre partes específicas de um vetor, sem ramificações (if/else) e sem penalidades de pipeline:

cCopiarEditar// Exemplo: aplicar operação apenas nos elementos > 0
mve_pred16_t mask = vcmpgtq_n_s16(vec, 0);
vec = vaddq_m(vec, vec, offset, mask);

Essa técnica é ideal para algoritmos de IA que envolvem atenção seletiva, ativação ReLU e manipulação de janelas móveis em sinais.

4. Facilidade de debug e manutenção

Embora seja uma extensão vetorial de baixa complexidade, o Helium possui suporte completo a ferramentas de depuração modernas, como:

• Keil MDK com suporte gráfico para registradores Q0–Q7,
• Arm Development Studio com simuladores de execução Helium,
• Visualização em IDEs com CMSIS-SVD para rastreamento de performance vetorial.

Isso reduz significativamente o tempo de identificação de gargalos e bugs de desempenho.

Considerações Finais e Caminhos para o Desenvolvimento com Helium

A introdução da extensão Helium no núcleo Cortex-M55 marca um novo capítulo para a computação embarcada de baixo consumo, ao unir desempenho vetorial com a simplicidade e eficiência do ecossistema Arm Cortex-M. Para desenvolvedores e engenheiros que atuam em áreas como IoT, automação industrial, wearables, saúde digital e voz embarcada, o Helium oferece um novo patamar de otimização com baixo impacto de migração.

Quando usar Helium

Você deve considerar Helium em seus projetos quando:

• O processamento envolve sinais, imagens ou séries temporais com alta taxa de amostragem.
• Há uso intensivo de algoritmos de filtro digital, compressão ou FFT.
• Modelos de aprendizado de máquina estão sendo executados diretamente na borda, com restrições de tempo ou energia.
• O firmware precisa ser otimizado em espaço de código e energia, sem migrar para processadores complexos como Cortex-A.

Caminhos para adoção prática

Para adotar Helium de forma eficiente em seus projetos, siga estas etapas:

1. Verifique o suporte no seu ambiente de build: use compiladores atualizados com suporte -march=armv8.1-m.main+mve e inclua as bibliotecas CMSIS.
2. Reutilize bibliotecas otimizadas: CMSIS-DSP, CMSIS-NN e TFLite Micro já trazem suporte a Helium.
3. Analise trechos críticos do seu código com perfis e identifique blocos candidatos à vetorização.
4. Aplique instruções MVE manualmente apenas quando necessário — muitos ganhos já vêm do uso das bibliotecas.
5. Teste em simuladores ou kits com Cortex-M55, como os baseados em Ethos-U55 ou placas com IPs da Arm com suporte nativo.

Fechamento

O Helium representa a maturação da proposta “performance at the edge” — executar algoritmos de IA e DSP em microcontroladores acessíveis, confiáveis e eficientes. A combinação do Cortex-M55 com Helium e bibliotecas bem integradas oferece uma solução elegante para sistemas modernos que exigem mais do que um simples controle digital: eles precisam aprender, ouvir, prever e adaptar-se localmente, sem depender da nuvem.

Seja você um desenvolvedor migrando de um Cortex-M4, um projetista de sensores inteligentes ou um entusiasta do edge AI, explorar o potencial do Helium pode ser o diferencial do seu próximo produto embarcado.

The post Helium e o Cortex-M55: Vetorizando o Futuro do DSP e da IA nos Microcontroladores first appeared on MCU & FPGA.