Introdução

A escolha da cadeia de ferramentas de compilação (toolchain) pode influenciar o tamanho do firmware e seu desempenho em tempo de execução. No ecossistema STM32, duas das opções disponíveis gratuitamente são a Arm Toolchain for Embedded, baseada em LLVM/Clang, e a Arm GNU Toolchain, baseada em GCC. Embora ambas permitam desenvolver software para microcontroladores com arquitetura Arm, os resultados podem variar de acordo com o código-fonte, as opções de otimização, a configuração de compilação e o núcleo de destino.

A Arm GNU Toolchain possui uma longa trajetória de desenvolvimento e uso, o que contribuiu para sua ampla adoção no ecossistema de sistemas embarcados. Por sua vez, a Arm Toolchain for Embedded, lançada em 2025, representa uma alternativa mais recente, baseada em LLVM/Clang. Essa diferença de maturidade torna interessante investigar como as duas soluções se comportam em condições equivalentes.

Este artigo compara os resultados obtidos com essas duas toolchains em três famílias de microcontroladores da STMicroelectronics: STM32C0, STM32C5 e STM32WB. A escolha dessas plataformas foi motivada pela disponibilidade dos kits de desenvolvimento utilizados nos experimentos, e não por uma seleção arbitrária. As famílias contemplam diferentes núcleos de processamento: Cortex-M0+ na STM32C0, Cortex-M33 na STM32C5 e Cortex-M4 na STM32WB. 

Foram avaliados o consumo de memória Flash e RAM, bem como os tempos de execução registrados em diferentes benchmarks. O objetivo é observar como os resultados produzidos por GCC e Clang diferem quando aplicados ao mesmo alvo e sob configurações equivalentes.

As conclusões se restringem aos códigos-fonte, às opções de compilação, às versões das toolchains e às plataformas utilizadas neste experimento. A partir dos resultados, busca-se oferecer subsídios para que o leitor compreenda as diferenças observadas e avalie qual toolchain e quais opções de otimização são mais adequadas às necessidades de seu próprio projeto.

Configuração testadas

Foram avaliadas as seguintes plataformas de microcontroladores:

• STM32C031: núcleo Arm Cortex-M0+, com 32 KB de Flash e 12 KB de RAM.
• STM32C542: núcleo Arm Cortex-M33, com 256 KB de Flash e 64 KB de RAM.
• STM32WB5M: núcleo Arm Cortex-M4, com 512 KB de Flash e aproximadamente 192 KB de RAM considerados na configuração de memória utilizada nos testes.

A frequência de operação da CPU foi fixada em 48 MHz em todas as plataformas.

Foram comparadas as seguintes toolchains:

• Arm Toolchain for Embedded, baseada em LLVM/Clang, versão 22.1.0.
• Arm GNU Toolchain, baseada em GCC, versão 15.2.Rel1.

As opções de otimização avaliadas foram -O0, -Os, -Oz e -O2, com e sem -flto, conforme detalhado a seguir:

• O0: desativa a maioria das otimizações, facilitando a depuração, mas geralmente produz código maior e mais lento.
• Os: habilita otimizações que priorizam a redução do tamanho do código gerado.
• Oz: prioriza ainda mais a redução do tamanho do código, podendo sacrificar desempenho para economizar memória.
• O2: habilita um conjunto amplo de otimizações voltadas ao desempenho, sem priorizar o menor tamanho possível.
• flto: habilita otimizações entre diferentes arquivos durante a linkagem, podendo reduzir o tamanho e melhorar o desempenho, sem garantir ambos os ganhos simultaneamente.

As métricas de desempenho são expressas em microssegundos (µs). Os percentuais de utilização de Flash e RAM são calculados em relação às regiões de memória declaradas para cada alvo nos respectivos arquivos de linker. Por esse motivo, os percentuais não devem ser comparados diretamente entre famílias diferentes sem considerar as capacidades e configurações de memória de cada plataforma.

Observação metodológica

Para tornar a comparação entre as toolchains tão justa quanto possível, foram mantidos equivalentes o código-fonte, as condições de execução, as frequências de operação e as opções de compilação que permitiam uma comparação direta. Também foram controladas, sempre que aplicável, as versões e as opções das ferramentas auxiliares.

A seguir, é apresentado um trecho de exemplo do arquivo CMakeLists.txt utilizado na configuração dos testes.

Figura 1 – Exemplo do trecho do CmakeList utilizado com as flags de otimização

Tipo de testes avaliados

A avaliação contempla métricas de tamanho e benchmarks de execução. O tamanho é apresentado como percentual de uso de Flash e RAM. Os tempos, expressos em microssegundos (µs), correspondem ao tempo médio de uma chamada ao respectivo cálculo durante a janela de medição.

• fixed_q15: cálculo escalar de produto escalar com valores de ponto fixo Q15.
• integer: sequência de operações aritméticas com inteiros.
• float: cálculo de produto escalar utilizando números de ponto flutuante.
• memory: preenchimento de um vetor em memória e cópia dos dados para outro vetor.
• division: operações de divisão inteira e cálculo do resto.
• branch: execução de condicionais com decisões dependentes dos dados.

Resultados obtidos

Tabela 1 – Resultados do benchmark no STM32C0

Tabela 2 – Resultados do benchmark no STM32C5

Tabela 3 – Resultados do benchmark no STM32WB

Como interpretar os resultados: cada linha compara GCC e Clang no mesmo microcontrolador e com as mesmas opções de compilação. Em todas as métricas, valores menores indicam menor uso de memória ou menor tempo de execução. A diferença percentual é calculada por (Clang / GCC − 1) × 100, usando o GCC como referência: valores negativos favorecem o Clang, positivos favorecem o GCC e zero indica empate. Os tempos são expressos em microssegundos (µs), e o uso de Flash e RAM, em percentual das regiões de memória definidas para cada alvo.

Conclusão

Os resultados mostram que a escolha da toolchain deve considerar tanto o microcontrolador quanto o perfil da aplicação. Neste experimento, o Clang destacou-se pelo menor uso de RAM em todas as comparações e pelos menores tempos na maioria dos benchmarks. O GCC, por sua vez, manteve vantagens importantes no processamento de ponto fixo e em algumas configurações de uso de Flash.

No STM32C0, o Clang apresentou o melhor equilíbrio entre tamanho e desempenho, com redução média de 31,6% no uso de Flash e menor tempo em todos os testes de integer, float, memory, division e branch. A principal exceção foi fixed_q15, em que o GCC venceu nas configurações otimizadas. Para esta plataforma, os resultados favorecem o Clang quando a prioridade é economizar Flash sem comprometer o desempenho das demais cargas avaliadas.

No STM32C5, a vantagem do Clang foi mais expressiva no desempenho, especialmente em float, cujo tempo foi, em média, 73,5% menor. Também houve ganhos relevantes em operações inteiras e memória. Em contrapartida, o GCC produziu binários menores nas configurações com -O2 e foi mais rápido na maioria das comparações de fixed_q15. Assim, a escolha depende do compromisso desejado: os resultados favorecem o Clang para as cargas gerais de execução, mas mantêm o GCC como alternativa relevante para ponto fixo ou menor Flash com -O2.

No STM32WB, o Clang também se destacou na maioria dos benchmarks, com redução média de 67,6% no tempo de float. O GCC, entretanto, foi mais rápido em fixed_q15 nas configurações otimizadas e utilizou menos Flash com -O2. Embora o Clang tenha produzido binários menores na maioria das combinações, essas duas exceções foram suficientes para tornar seu uso médio de Flash ligeiramente superior. Isso reforça a importância de avaliar a configuração específica da aplicação, em vez de escolher apenas pelo resultado agregado.

A opção -O0 não se mostrou vantajosa para versões finais cujo objetivo seja reduzir o tamanho do firmware ou melhorar o desempenho. Em relação à configuração de menor Flash de cada compilador e plataforma, sua ocupação foi aproximadamente 40% a 116% maior, além de apresentar tempos geralmente superiores aos das configurações otimizadas. Seu uso pode ser adequado durante a depuração, mas os resultados favorecem a adoção de otimizações para builds de produção com restrições de memória ou velocidade.

Para minimizar Flash, Clang -Oz -flto foi a melhor combinação nas três plataformas. Já o uso de LTO não assegurou ganhos de velocidade e, em alguns casos, esteve associado a regressões. Reduzir o binário e acelerar a execução são, portanto, objetivos que precisam ser avaliados separadamente.

Em síntese, o Clang apresentou os resultados gerais mais favoráveis neste conjunto de testes, sem eliminar as vantagens específicas do GCC. Mais do que apontar um vencedor, a comparação mostra que a combinação entre toolchain e opções de otimização deve acompanhar as prioridades de cada projeto, seja para reduzir o uso de memória, acelerar a execução ou equilibrar esses dois objetivos.

Referências

[1] ALHERAKI, Ayman. C++ Low-Level Optimization: Performance Secrets in a Concise Guide. [S. l.]: Simplify C++, nov. 2025. Disponível em: https://simplifycpp.org/books/minibooklet/mini_booklet_CPP_Low_Level_Optimization.pdf. 

[2] ARM. Arm Support: documentação técnica — KA006435. [S. l.], [s. d.]. Disponível em: https://support.arm.com/documentation/ka006435/latest.

[3] STMICROELECTRONICS. STM32Cube further facilitates code development with Clang/LLVM support. STMicroelectronics Community, 8 jul. 2025. Disponível em: https://community.st.com/stm32-software-tools-165/stm32cube-further-facilitates-code-development-with-clang-llvm-support-153936.

[4] ARM. GNU Compiler: Arm GNU Toolchain installation guides. Arm Learning Paths, [s. d.]. Disponível em: https://learn.arm.com/install-guides/gcc/.

[5] STMICROELECTRONICS. STM32CubeC5 MCU Software Package. GitHub, [s. d.]. Disponível em: https://github.com/STMicroelectronics/STM32CubeC5. 

[6] STMICROELECTRONICS. STM32CubeWB MCU Firmware Package. GitHub, [s. d.]. Disponível em: https://github.com/STMicroelectronics/STM32CubeWB. 

[7] STMICROELECTRONICS. STM32CubeC0 MCU Firmware Package. GitHub, [s. d.]. Disponível em: https://github.com/STMicroelectronics/STM32CubeC0.

Arihe Ramos

1 post

Esta obra está licenciada com uma Licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional.