
Clang/LLVM 工具链项目概述 十余年来,意法半导体一直提供STM32 GNU工具作为开发STM32应用的免费参考工具链。该工具链在整个STM32Cube生态系统中获得全面支持,并将持续获得来自意法半导体的维护更新。 Clang/LLVM工具链将逐步为STM32开发人员带来更优的代码密度和执行速度。本次发布是提升工具链性能与深化STM32Cube生态系统整合的第一步。该工具链将在STM32CubeMX和STM32Cube for Visual Studio Code中获得支持。 本次发布提供首个基于Arm LLVM源代码树构建的ST Arm Clang 工具链版本。早期用户可以体验与当前GCC性能相当的工具链。该版本提供更完善的代码检查机制和更优化的C代码库,编译器基准测试数据将后续公布。 后续开发将分为两个步骤:
采用分阶段推进策略,确保开发优先级与开发人员需求保持一致。ST Arm Clang版本将很快提供示例项目,同时STM32CubeMX和STM32Cube for Visual Studio Code将为STM32开发人员提供入门支持。 ST Arm Clang 工具链特性 ST Arm Clang 是专为STM32开发设计的全新C/C++工具链,基于现代LLVM编译器架构和Arm嵌入式工具链构建。 这套基于LLVM的新工具链在保持与现有项目的兼容性的同时,为开发人员提供更高效、灵活且面向未来的开发环境。 ST Arm Clang 设计为STM32 GNU工具链的无缝替代方案,最大限度降低过渡过程中的干扰。但由于底层架构差异,可能存在少量不兼容性或不同特性。为简化过渡过程,我们提供两种版本的工具链:
STM32CubeMX 支持 STM32CubeMX 6.15版本新增对ST Arm Clang的支持。具体而言,STM32CubeMX可为混合版本的ST Arm Clang工具链生成项目配置。这使得STM32开发人员能够快速将现有GCC项目迁移到ST Arm Clang工具链,无需重写链接脚本或考虑Newlib与Picolibc的兼容性问题。 选择CMake与ST Arm Clang组合将创建一个混合工具链 项目:
如果用户希望从混合 版本切换到完整LLVM版本,可参照下文说明在STM32Cube for Visual Studio Code中操作。 STM32Cube for Visual Studio Code 开发人员在STM32Cube生态系统内可通过两个方式启动项目:
本教程假设已按前章所述通过STM32CubeMX创建了一个项目。 STM32CubeMX 项目导入与Visual Studio Code 开发环境初始化介绍 在STM32Cube for Visual Studio Code中,打开包含使用STM32CubeMX生成的项目的文件夹。 选择STM32CubeMX项目生成路径。 允许STM32Cube for Visual Studio Code加载STM32扩展模块。系统将要求您配置项目和STM32Cube项目,然后选择“Yes”。 Visual Studio Code将读取项目元数据并检测是否已安装ST Arm Clang工具链。 如果是首次针对该新工具链创建项目,开发环境将自动下载、安装并为此项目激活该工具链。下载量约700 MB,安装占用2.5 GB。 Visual Studio Code环境不会全局配置为使用ST Arm Clang工具链。工具链选择和环境路径管理仅在Visual Studio Code内部本地进行,并且每个项目可独立配置。 项目构建与结果分析 ST Arm Clang安装完成后,系统将调用CMake执行项目配置步骤。 可在CMake/Build输出通道中查看新的ST Arm Clang工具链。 点击“Build”按钮编译项。 结果将显示在输出控制台。编译分析器可用于进一步了解编译结果。右键单击任意映射文件,选择Open memories analysis 。 了解CMake 文件结构与工具链选择机制 CMakePresets.json 使用starm-clang.cmake 文件作为CMake工具链文件。 若STM32CubeMX项目是针对GCC生成的,该文件将指向gcc-arm-none-eabi.cmake 。STM32CubeMX 6.15 及后续版本会同时生成两个文件 gcc-arm-none-eabi.cmake和starm-clang.cmake ,方便开发人员在IDE内切换工具链。这些文件一经生成便不再修改。 配套的starm-clang.cmake 文件允许开发人员选择可供选择的C库组合。 默认情况下,选择ST Arm Clang工具链的混合版本,因其与现有STM32 GNU工具的兼容性最好。建议开发人员尝试使用此工具链进行代码编译与测试。如上所示,通过修改STARM_TOOLCHAIN_CONFIG变量值即可切换至依赖Newlib或Picolib的完整LLVM版本,这一过渡步骤有助于开发人员熟悉新版工具链。 STM32Cube for Visual Studio Code用户指南提供更多关于ST Arm Clang的文档,并将根据用户反馈持续补充资源。 活动时间:即日起-8月31日 🎉️ 有奖互动: 1、针对STM32Cube优化的功能,评论区回复你的看法。请走心回复。 ❤️ 回复有奖:抽15位送10京东卡 2、在【STM32团队】分享一篇Clang/LLVM工具链体验心得 🚀️ 分享有奖:优质分享者抽5位送STM32随机开发板一块 |
有奖直播 | STM32WL3x助力低功耗长距离无线应用(文末有奖)
STM32CubeMX应用结构选择指南
经验分享 | STM32CubeMX 生成时钟获取函数的分析
兔哥的最强U5图显【000】——U5G9最小系统绘制
兔哥的ST67——【000】ST67模组订购
基于LORA的环境感知系统
有奖直播 | 智启芯程,共探STM32MP2产品迭代与生态进阶
经验分享 | 使用CubeMx配置NVIC时为何不见子优先级?
经验分享 | 三个 ADC 同步模式配置以及 CubeMx 错误配置的解决方法
兔哥的边缘AI【001】——DIY-STM32N6全IO扩展板
cubemx升级,之前版本的也能加入Clang,兼容之前的版本吗
HAL库有些中断处理函数延迟较高,希望可以自动给出一些优化建议。
生成工程的代码包含大量HAL库抽象层,对资源受限的MCU不友好
换了前端 Clang,链接、启动文件、库都估计还是 GNU 那套,CubeMX 一键生成 CMake 预设,之前的项目搞进来应该无痛
另外VSC 可以自动下载、激活、切换,每个项目隔离,不影响全局 PATH