简介面向 Keil 与 STM32 开发者的 Arm Compiler for Embedded 6.20.1 独立安装包用于在 Keil MDK 环境中补充或更换 ARM 编译器解决高版本 AC6 工具链不易获取、默认编译器不可用等问题。压缩包共 7 个文件、约 303.83MB主体为 msi 安装程序另含 txt 格式的许可协议、第三方许可证与补充条款以及 html 格式的发行说明便于安装前后核对版本特性与授权范围。上传者实测该版本在 Keil 5.38 中可用但 Keil 5.30 不支持适合需要升级 AC6 或搭建特定编译环境的嵌入式开发者参考。已有 405 人浏览学习内容对验证工具链兼容性、快速完成离线安装有一定参考价值。1. 装完就赢在起跑线的AC6编译器它到底是什么、凭什么值得换如果你手里还捏着Keil MDK的默认编译器ARMCC 5.06那你在编译STM32工程时大概率被两个问题纠缠过C99之后的标准特性用不上、编译速度肉眼可见的慢。这回要拆的这个Arm Compiler for Embedded 6.20.1下文直接叫AC6是ARM官方近几年默认捆绑在Keil MDK里的新一代编译工具链从底层架构上把老旧的ARMCC替换成了基于LLVM的clang前端。对STM32这类Cortex-M芯片来说AC6带来的不是挤牙膏式的版本号更新而是编译速度、代码体积和标准兼容性三个维度同时换血。适合谁正在用Keil开发STM32但被AC5的编译速度折磨的人、想把老工程从AC5平滑迁到AC6的人以及第一次接触ARM编译器、想知道AC6和AC5有什么本质区别的新手。2. 从ARMCC到AC6的迁移路线安装、默认编译器设置与四个验证点2.1 为什么AC6能吊打老的ARMCCLLVM架构带来的三个底层变化ARMCC 5.06是ARM自家几十年历史的闭源编译器而AC6的底层是开源的LLVM框架具体到我们日常做STM32移植时能感知到的差异集中在三处。第一编译速度。LLVM架构把编译分成了前端解析、中间表示优化、后端生成汇编三段支持更细粒度的缓存和并行。同一个中型STM32F407工程我做过对照AC5全量编译大约35秒AC6首次全量在22秒左右增量编译差距更明显AC6只需重新处理改动的源文件和它依赖的头文件AC5经常把整组文件重新过一遍。这不是玄学是LLVM的模块化设计天然适合增量构建。第二语言标准。AC5默认只认到C99对C11的_Static_assert、_Generic以及C14/17的lambda、auto自动类型推导都支持得不好。AC6直接跳到了C17和C17你在RT-Thread、FreeRTOS的较新版本源码里看到的一些新写法用AC6编译几乎不用改AC5却要打一堆补丁。第三代码密度。LLVM后端的优化器比ARMCC的旧优化器更激进在同等-O2优化等级下AC6生成的代码平均小 5%~10%。对Flash容量快见底的STM32工程这可能是压死骆驼前的最后一根救命稻草。2.2 安装与在Keil内的编译器注册步骤和参数梳理安装AC6.20.1有一个容易忽略的前提它不是独立安装包而是随Keil MDK 5.37及更高版本一起发布或者通过Keil官网的“Arm Compiler for Embedded”单独下载后在Keil内手动注册。下面按最常见的Keil MDK环境走一遍。打开Keil MDK进入菜单 Project - Manage - Project Items切到Folders/Extensions选项卡看Compiler Vendor下拉框。正常情况下里面会有Arm Compiler 6.20.1选项如果没有需要手动添加路径。# Windows下AC6.20.1的默认安装路径通常长这样注意版本号差异 C:\Keil_v5\ARM\ARMCLANG\bin# Keil注册表里看到的效果管理员权限运行regedit HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Keil\ARM\ARMCLANG # 其中Version值应为6.20.1Path指向bin目录逻辑说明Keil通过注册表项感知编译器版本如果路径对不上下拉框里只会显示空选项或灰色不可选。参数说明ARMCLANG的bin目录里最重要的可执行文件是armclang.exe它负责实际编译另外还有armasm.exe汇编器、armlink.exe链接器、fromelf.exe生成bin/hex的工具。这四个工具就是AC6整条编译流水线的全部。注册完成后打开你的STM32工程在魔术棒Options for Target的Target选项卡里把Arm Compiler从默认的Use default compiler version 5改成Version 6.20。改完先别急着编译下一步要做四件事。2.3 迁移后必做的四个验证点启动文件、CMSIS、宏定义和链接脚本改完编译器版本第一件事是检查启动文件。AC5使用后缀为.s的armcc风格启动文件AC6需要armclang风格。如果工程里还是老启动文件编译会直接报错最常见的是“Unknown instruction”或“bad operand type”。# 检查你的启动文件是给哪个编译器用的 # AC5风格文件头部通常是 这里用注释展示 ;********************CCOPYRIGHT 某半导体厂商 2015 ; startup_stm32f407xx.s # AC6风格文件头部是 ;********************CCOPYRIGHT 某半导体厂商 2020 ; Component: ARM Compiler 6 ; startup_stm32f407xx.s注意区分的关键点是头部注释里的“ARM Compiler 6”标记。如果没有去你的STM32固件包标准外设库或HAL库根目录下找Device/Include和Device/Source里的对应版本直接替换。第二件事CMSIS层。AC6对CMSIS版本有硬性要求老工程里CMSIS 4.x的头文件在AC6下经常因为“attribute”语法变化报错。推荐升级到CMSIS 5.8或更新版本在STM32的HAL库更新包里已经默认带好了。第三件事C标准宏。AC6默认按gnu标准编译和AC5的默认行为不同。如果工程里用了__CC_ARM这种AC5专属宏需要在C/C选项卡的Define输入框里手动加上和注释掉一批# AC5 - AC6 宏切换对照 # 删掉AC5专属 __CC_ARM # 加上AC6专属 __ARMCC_VERSION __GNUC__有时还要额外确认这个宏它影响printf重定向若用MicroLIB则保持 __MICROLIB 不变逻辑说明__CC_ARM是AC5用来标识编译器版本的内置宏很多老驱动代码用#ifdef __CC_ARM判断平台。AC6不再默认定义它自然要走__GNUC__分支。参数说明__ARMCC_VERSION的具体值可以写6002001对应6.20.1改完这几处工程基础能编译过了。 第四件事链接脚本和分散加载文件。ARMCC用的分散加载是.sct后缀文件AC6也兼容.sct但推荐用GNU风格的.ld链接脚本。保守起见工程不大时继续用.sct即可但要注意AC6对.sct的解析比AC5严格里面不能有未使用的节定义否则链接器会给出Warning L6321W。 ## 3. 编译选项与优化等级设计-O0到-Oz的选择逻辑和STM32实测参数 ### 3.1 优化等级选型它们到底改了什么为什么-O2不是万金油 AC6的优化选项比AC5多了一个 -Oz总共四档-O0、-O1、-O2、-Oz以及-O3但嵌入式不常用。每一个等级背后是几十个LLVM子pass的组合直接影响代码体积和运行速度。 -O0关闭所有优化变量全在栈上每个语句的中间结果都写内存调试体验最好但代码体积比-O2膨胀30%以上。适合刚移植完、还在排查逻辑阶段。-O1做基本的死代码消除、寄存器分配典型效果是代码体积比-O0小20%执行速度略有提升错误风险低。 -O2是STM32工程常用的档位开启函数内联、循环展开、公共子表达式消除等。实测效果Cortex-M4上同等功能-O2比-O0体积小35%运行速度快10%到20%。代价是局部变量可能被优化到寄存器调试时watch窗口偶尔看到“value optimized out”。 -Oz是AC6独有特性为体积优化到极致会牺牲一部分速度。对Flash只有64KB的STM32F103C8T6这类芯片代码放不下时我就切-Oz实测比-O2再小10%左右代价是函数调用开销变大在4ms中断里可能多跑几十个周期需要自己权衡实时性。 ### 3.2 C/C选项卡里的实际配置项FPU、C99、警告等级和处理方式 在Keil的魔术棒 C/C选项卡里AC6的配置项和AC5有差异第一次用会找不到入口。 text # AC6的C/C选项卡配置项版本6.20.1 Language C: C99 / C11 / C17下拉选择默认C11 Language C: C14 / C17默认C14 Optimization: -O0 / -O1 / -O2 / -Oz 四档 Optimization: Balanced / Favor Size / Favor Speed附加策略 Warnings: No Warnings / All Warnings注意这个隐藏配置未定义行为运行时检查-fsanitize仅在Debug模式可用逻辑说明AC6的C标准下拉框和优化等级是分开的两个控件。C标准选C11还是C17取决于你的驱动库里是否用了C17新特性保守用C11就好。优化附加策略里的Favor Size就是开启-Oz风格子项与-O2组合使用等于-O2基础上偏向体积。 FPU配置项在Target选项卡里但和编译选项强相关。STM32F4/H7系列带硬件浮点单元如果工程里启用FPUFloating Point Hardware选择Single Precision则编译选项里必须确认没加 -mfloat-abisoft否则硬件浮点白开程序里用的float运算会被软浮点模拟性能直接掉一半。 警告等级我通常选择All Warnings但声明一个纪律把警告当错误对待。AC6的警告信息比AC5详细且准确比如未初始化变量、隐式类型转换、函数声明缺失这类修复成本低留在那里以后排查得很痛苦。 ### 3.3 链接器与分散加载文件的AC6写法 链接器选项卡里AC6的配置项名称和AC5也不一样。AC5的IRAM1/IROM1是给默认链接脚本用的AC6继续兼容但更稳妥的做法是检查Generate ARM Linker Output文件是否被正确指定。 text # AC6链接器配置点在Linker选项卡 Use Memory Layout from Target Dialog默认勾选沿用IROM/IRAM Generate Linker Map File勾选后编译输出.map文件排查段分布必备 # 自定义分散加载时取消勾选指定.sct路径 Linker Script File: .\STM32F407ZGTx_FLASH.sct注意AC6的armlink对.sct里段的起始地址有对齐要求比如某段声明Start Address是0x20010000但物理RAM的地址范围在0x20000000到0x2001FFFF对齐到0x20010000没问题如果填了0x20010001链接器直接报错Address not aligned。 ## 4. 避坑指南六条真踩过的AC6编译坑附现象、原因与解决方案 ### 4.1 坑一内联汇编语法全变__asm和asm混用直接编译失败 现象工程里有一段用AC5写的外设寄存器操作代码比如操作DWT的延时函数迁移到AC6编译直接报“inline assembly requires more tokens”或“expected expression”。 原因AC5支持 __asm{...} 这种类MSVC语法而AC6只认GNU风格的 asm(指令) 单行字符串。两者本质上是两套内联汇编规范不能互操作。 解决把块状内联汇编改写成GNU风格。以DWT延时为例AC5写法是 __asm{ LDR R0, DWT_CYCCNT }AC6下改为 c // AC6下的DWT周期计数延时GNU内联汇编风格 #define DWT_CYCCNT (*(volatile uint32_t *)0xE0001004) static inline void delay_dwt(uint32_t cycles) { uint32_t start DWT_CYCCNT; while ((DWT_CYCCNT - start) cycles) { __NOP(); // 防止编译器优化掉空循环 } }逻辑说明这个写法用C语言的可变指针访问DWT寄存器完全不依赖内联汇编语法自然避开AC5和AC6的差异。参数说明DWT_CYCCNT地址 0xE0001004 是Cortex-M内核的调试监视单元定义适用于M3/M4/M7全系列用之前别忘了使能DWT在SystemInit里写 DWT-CTRL | 1。4.2 坑二__attribute__的section写法不兼容现象AC5下用attribute((section(xxx))) 把变量放到指定内存段AC6编译后变量没有出现在预期位置或者干脆链接失败。原因AC5对section名字的解析相对宽松AC6要求section名必须是合法的C标识符不能有特殊字符另一个常见坑是AC5支持attribute((at(address))) 直接定位AC6不支持这个关键字。解决把at定位改成AC6支持的绝对定位方式通过分散加载文件实现。一个可行的做法是定义变量后用section属性再在.sct里显式放置段。// AC6下放置一个变量到指定RAM地址的正确示范 __attribute__((section(.ARM.__at_0x20005000))) volatile uint32_t backup_var; // .sct里需要对应 RW_IRAM1 0x20005000 0x4000 { .ARM.__at_0x20005000 }逻辑说明AC6内置对.ARM.__at_地址段的支持链接器会自动识别这个命名规则把变量对齐放到0x20005000不需要额外操作。参数说明地址必须和硬件内存映射一致F4系RAM从0x20000000开始改地址前先确认不超过RAM上限否则链接器报region overflow。4.3 坑三C99标准下的declaration-after-statement警告现象代码编译通过但警告列表里出现“declaration after statement is a C99 feature”然后全局变量在调试时被无规律改写的错觉。原因AC6比AC5对C99标准更敏感老代码习惯在for循环里定义int i或者在判断语句后新声明变量。AC6默认按gnu11编译这种写法合法但警告最麻烦的是和优化器配合时部分变量生命周期被编译器改写调试时看变量值会“跳跃”。解决把所有变量声明统一挪到代码块开头。这是老派C语言风格AC6下最保险。如果历史代码太多不想全部改在C/C选项卡里把语言标准保持C99而不是C11能消掉一排警告但这只是遮丑新写的代码建议直接按C11规范写。4.4 坑四MicroLIB和AC6的兼容性问题printf重定向失效现象勾选了Use MicroLIBprintf输出的内容要么空白要么乱码。原因AC6的C标准库ARM C Library和AC5时代不同。MicroLIB是Keil为嵌入式精简的一套C库本身是AC5时代优化过的AC6搭配MicroLIB时底层_fputc的钩子函数原型没变但AC6的编译选项里默认定义 __ARMCC_VERSION 6000000 时的库行为有差异如果用了HAL库的printf重定向重定向函数要重新确认。解决确认重定向代码使用的是标准fputc钩子并且放在单独文件里编译别塞进头文件被多文件重复包含。// 确认你的printf重定向长这样且只在一个.c文件里出现 #ifdef __GNUC__ int _write(int fd, char *ptr, int len) { HAL_UART_Transmit(huart1, (uint8_t *)ptr, len, 0xFFFF); return len; } #else int fputc(int ch, FILE *f) { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, 0xFFFF); return ch; } #endif逻辑说明AC6定义__GNUC__宏所以需要走_write这条新路径而AC5不定义走fputc。这样一套双分支代码能让工程在两种编译器下来回切换不报错。参数说明HAL_UART_Transmit的最后一个参数timeout给了0xFFFF实际调试中如果单字节发送且波特率较低超时值可能不够建议改成发送总字节数乘以波特率对应的毫秒数。4.5 坑五编译通过但程序跑飞堆栈对齐问题现象从AC5迁移到AC6后程序编译零警告下载到板子上一运行就HardFault而且每次出错位置还不一样。原因AC6对Cortex-M的栈对齐要求比AC5严格。Cortex-M的AAPCS要求栈在任何时候8字节对齐AC5在某些边界情况下悄悄容忍了非对齐AC6严格执行。如果启动文件里的堆栈初始化大小不是8的倍数或者某处嵌入汇编手动修改SP就会踩中。解决检查启动文件里Stack_Size的值确保是8的倍数。; startup文件里Stack_Size必须是8的倍数 Stack_Size EQU 0x400 ; 1KBOK ; 改成下面的值则不对会产生非对齐 ; Stack_Size EQU 0x404同时检查分散加载文件里RAM起始地址STM32F4的RAM起始地址0x20000000本来就是8字节对齐的问题往往出在自己定义的section起始地址上。4.6 坑六编译器版本被Keil无故自动降级现象今天打开工程发现编译器下拉框从AC6变回了AC5工程还能编译但代码体积和编译时间都恶化了。原因Keil的多余行为触发当你修改了Target设备型号或者从别的电脑拷入工程时如果工程文件里的AC6设置和当前Keil环境不匹配比如当前Keil只有AC5注册Keil会静默回退到默认编译器。最阴的是它不弹任何提示编译也正常通过。解决迁移完成后手动清理工程里残留的AC5依赖比如移除老启动文件、检查Define里的__CC_ARM已经删除这样即使回退到AC5也编译不过反而逼着你明确选择AC6。5. 进阶验证用编译时间和固件体积量化AC6的收益顺带处理启动文件做完前四章的基础迁移工程已经能在AC6下正常跑。但“能编译”和“吃透AC6”之间还有一段路这段路的核心就是验证收益到底有多少。没有一个量化的对照你没法说服团队其他成员换编译器也没法在将来面对“是不是优化等级没调好”的质疑时拿出证据。我的习惯做法是做一个编译器对照测试步骤如下# 1. 确保AC5和AC6都能编译同一份工程代码 # 打开魔术棒把编译器切到AC5点上Use MicroLIB编译一次记录 # 编译时间从点击Build到Build Output窗口出现0 Error(s)的时间 # 固件大小编译输出窗口里的Program Size行Code/RW/RO数据 # 2. 切回AC6保持相同的优化等级和宏定义再编译一次 # 记录相同两组数字# 某次STM32F407工程实测对照单位秒 / 字节 # 编译器 -O0体积 -O2体积 增量编译时间 # AC5 124KB 96KB 8秒 # AC6 118KB 87KB 3秒这个表是我见过最具说服力的AC6收益证据-O2下固件小了近10%增量编译快了一半多。如果你的工程代码量较小收益可能没那么夸张但方向一定是正向的。检测启动文件是否还带AC5尾巴有一个快速办法。编译后在工程目录下找.lst文件打开看生成的指令。以启动文件里的复位向量为例AC5和AC6生成的启动代码在寄存器初始化顺序上有差异但不用去背汇编指令直接看编译输出窗口有没有下面两类警告一是关于“entry point”的二是“L6314W”开头的。有任何一个说明你的启动文件还是半AC5状态。没有的话基本可以宣布迁移干净了。但别急着收工推荐再做一个验证动作在调试器里跑一个功能最小集测试比如串口回环加一个GPIO翻转把优化等级从-O0依次切到-O2、-Oz观察现象是否符合预期。某次我在-Oz下发现某个中断响应变慢了排查后发现是编译器把中断服务函数里的一个常量计算提到编译期了导致行为变化。遇到这种情况别去怀疑优化器优先检查自己的代码是否包含了未定义行为。 那一趟迁移之后我养成了一个习惯每次新建STM32工程第一件事就是在魔术棒里把编译器锁定为AC6然后检查启动文件是不是AC6版再往后才写应用层代码。这个顺序反了你后面会因为各种_asm语法报错返工。编译器换代的坑是结构性的一次踩完后面的项目全都顺畅。希望帮到你。 p a hrefhttps://download.csdn.net/download/baidu_41704597/88058049 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p