简介：ARM 编译器 5.06 版本是一套面向 ARM 架构嵌入式开发的优化编译工具链，专门针对 Cortex-A/R/M 系列处理器设计，适用于在 Keil MDK 5.37 环境中进行固件构建与性能调优的开发者。压缩包共 3 个文件，包含 exe 安装引导、MSI 组件和 HTML 说明文档，大小约 80.94 MB，其中 HTML 文档记录版本更新、新特性及已知问题，方便安装前核对。此版本在代码生成、调试支持与数学库方面均有增强，能够生成更小更快的机器码，尤其在 ARM Cortex 系列处理器上表现优异；同时支持 ARMv4 至 ARMv8-A 指令集，并提供 armcc、armasm、armlink 等完整工具链，配合增强的调试工具，可提高嵌入式项目的编译效率与稳定性。对于希望补充 Keil MDK 默认编译器、开展裸机或 RTOS 项目开发的嵌入式工程师而言，这份资源能提供清晰的版本信息和安装依据。目前已有 15904 人浏览学习，值得作为 ARM 开发工具链选择与配置的实用参考。
1. ARM Compiler 5.06：为什么旧工程仍然绕不开 armcc
在 Keil MDK 的安装界面里，ARM Compiler 5.06 update 6 很容易被当成一个过时的默认项忽略掉。但如果你手上有一个五年前甚至十年前发布的嵌入式硬件项目，芯片厂商提供的外设库、启动文件和分散加载文件全部按 armcc 的语法习惯来写，那 AC5 就是这些代码唯一能无缝衔接的编译器。它的核心价值不在性能，而在兼容性：从__irq中断声明到__attribute__((at()))绝对地址定位，AC5 提供了与老工程完全一致的关键字和语义。这篇笔记的目标读者是维护存量设备的开发者，我会把 AC5 的安装选择、工程配置、编译排错和命令行集成方法串起来，帮你把旧代码在现代工具链中安全地跑起来。
2. 工具链安装与选型：AC5 与 AC6 的差异和版本切换
2.1 安装包构成与路径规划
实际在嵌入式开发中，AC5 不像 AC6 那样可以通过命令行工具链单独安装。一般有两种来源：一是完整安装 Keil MDK 时默认携带的版本；二是从官方下载中心获取的 ARM Compiler 5.06 update 6 离线包。无论是哪种，最终在 Windows 下都会落到一个固定的目录层次：
Keil_v5/ARM/ARMCC/ bin/ armcc.exe、armasm.exe、armlink.exe、fromelf.exe include/ 标准 C 头文件与内建类型定义 lib/ 运行时库与底层启动代码在相关项目中，我发现把 MDK 装在中文路径下会带来莫名其妙的包含错误，所以建议整个工具链放在纯英文目录，并设置环境变量ARMCC5_DIR指向ARMCC目录。Win10 以上系统可以直接在系统环境变量里新建一个用户变量，编译时工程文件会优先读取这个变量来定位编译器。
2.2 armcc 与 armclang 的语法不兼容点
很多人以为 AC5 和 AC6 只要改一下编译器选项就能互换，但实际上二者的语言前端从 ARMCC 变成了 Clang/LLVM，语法细节差异很大。
| 特性 | AC5 (armcc) | AC6 (armclang) |
|---|---|---|
| C 语言标准 | C90 / C99（需显式开启） | C11 / C++14 默认 |
| 中断函数声明 | __irq | __attribute__((interrupt)) |
| 绝对地址定位 | __attribute__((at(addr))) | __attribute__((section(".ARM.__at_0x..."))) |
| 内存对齐 | __align(n) | __attribute__((aligned(n))) |
| 结构体压缩 | __packed | __attribute__((packed)) |
| 内联汇编 | __asm { ... }或__asm("...") | GNU 风格asm("...") |
| 变量声明于指定段 | __attribute__((section("name"), zero_init)) | __attribute__((section("name"), used)) |
这里最关键的是__attribute__((at(addr)))。AC5 允许把变量直接定位到某个固定地址，这在寄存器映射和共享内存场景很好用。AC6 不再直接支持at，要先声明到某个段，再在分散加载文件中重定位段地址。遇到这类代码时，我会先统计工程里用了多少处at，如果数量多，继续用 AC5 比逐一改写更划算。
2.3 在 Keil MDK 中切换编译器版本
切换界面的操作并不复杂：打开工程后，右键目标，进入 Options for Target -> Target 页，在 ARM Compiler 下拉框中选择 Use default compiler version 5。需要注意，如果只安装了 MDK 自带的 AC6，这个下拉框里根本没有 version 5 选项，必须先去把 AC5 离线包装上。
提示：其他编辑器或 IDE 想要用 AC5 时，可以直接在 makefile 里将
CC变量指向armcc.exe的绝对路径，而不是依赖 IDE 的自动发现。
替换之后，MDK 会重新解析工程的编译选项，此时记得确认 Preprocessor Symbols 里的宏定义没有__GNUC__这类与编译器强相关的宏，否则头文件会走错分支。还有一个容易忽略的点：AC5 和 AC6 对 C 标准的默认处理不同，AC5 不会默认打开 C99，如果工程里大量使用for(int i=0;...)这类声明，需要在 Misc Controls 里手动加上--c99，否则编译到一半就会被一堆语法错误淹没。
3. 编译与链接实战：移植旧工程必经的 armcc 参数与修复
3.1 编译单个 C 文件：armcc 参数说明
在命令行下使用 AC5 时，常用命令如下：
armcc --cpu Cortex-M3 --apcs=interwork -O2 --c99 \ -I./inc -I../../../CMSIS/Include \ -D__UVISION_VERSION=5 -DUSE_STDPERIPH_DRIVER \ -c ./src/main.c -o ./build/main.o这段命令里面几个参数在实际工程中作用很明确：
--cpu Cortex-M3指定目标内核，会影响到后续指令集选择。对于带浮点单元的 M4，要写成--cpu Cortex-M4F，才能编译出硬件浮点指令。--apcs=interwork告诉编译器生成同时支持 ARM 和 Thumb 状态切换的代码，否则从汇编启动代码跳转到 C 的main时会发生状态不匹配。-O2是平衡优化等级。AC5 在-O3下对循环展开较激进，容易让 Flash 空间翻倍，所以老工程一般不建议盲目拉高。--c99是 AC5 的重要开关。armcc 默认只按 C90 编译，遇到//注释以外的 C99 特性会直接报语法错，加上这个选项才能真正处理 C99 代码。
编译成功后，目录下会生成main.o文件，这是 ELF 格式的可重定位目标文件。可以用fromelf -c main.o直接查看反汇编，检查关键路径有没有生成预期指令。
3.2 链接与镜像生成：armlink 和 fromelf 的配合
单文件编译只是第一步，整个工程必须链接之后才能生成可烧录镜像。这儿是一个典型的两段式命令：
armlink --cpu Cortex-M3 --ro-base 0x08000000 --rw-base 0x20000000 \ --entry Reset_Handler --first Reset_Handler \ --scatter ./build/target.sct \ -o ./build/app.axf \ ./build/main.o ./build/stm32f10x_it.o ./build/startup.o然后生成烧录文件：
fromelf --bin --output ./build/app.bin ./build/app.axf与 GCC 的-T链接脚本不同，AC5 使用分散加载文件.sct来定义内存布局。--ro-base 0x08000000表示只读代码段基地址，--rw-base 0x20000000表示可读写数据段基地址。使用--scatter时，这两个参数会被分散加载文件中的LOAD_REGION覆盖，所以实际以.sct内的描述为准。
注意：
--first Reset_Handler配合--entry Reset_Handler是为了保证中断向量表放在镜像开头。如果复位入口被编译优化链接到其他位置，芯片上电后会飞掉。
3.3 移植代码时最常见的三类语法修复
第一类：中断函数声明。AC5 里__irq是内建关键字，函数头直接写__irq void TIM2_IRQHandler(void)。AC6 不认这个，需要改成void TIM2_IRQHandler(void) __attribute__((interrupt))。
第二类：寄存器定义。旧固件库常写：
#define GPIOA_BASE ((uint32_t)0x40010800UL) #define GPIOA ((GPIO_TypeDef *) GPIOA_BASE)这种写法在 AC5 下没问题，但如果升级到 AC6 且开了 LTO，编译器可能认为 GPIOA 指向的地址是未定义的，从而误删寄存器写操作。AC5 对这类 volatile 指针的处理保守一些，更贴近寄存器操作语义。
第三类：变量放置。
uint8_t buffer[1024] __attribute__((at(0x20001000)));这种写法是 AC5 专有的，AC6 里无法直接编译。如果想保留代码不动，可以给 AC6 定义一个宏：
#define AT_ADDR(addr) __attribute__((section(".ARM.__at_0x" #addr)))但这只是语法层面的兼容，分散加载文件还是要同步添加对应的执行区域。实际上，我发现用 AC5 编译这类固定地址变量有一个隐含优势：编译器能直接算出变量之间的相对偏移，避免因段重排导致的地址错乱。
4. 避坑排查：armcc 5.06 最容易翻车的五个场景
4.1 现象：MDK 提示 AC5 未安装
现象：在 Options for Target 里明明选好了 AC5，点击 OK 后编译状态栏却弹出Target uses ARM Compiler 5 but is not installed。
原因：我遇到的情况是离线安装包版本不完整，或者安装到了非默认目录，MDK 的 TOOLS.INI 中没有正确记录路径。
解决：首先检查C:\Keil_v5\TOOLS.INI，看[ARM]段里是否有PATH="C:\Keil_v5\ARM"，如果没有，手动指定路径后重启 MDK。还有一种情况是电脑上装了多个 MDK 版本，环境变量ARMCC5_DIR指向了旧路径，删掉该变量，让 MDK 走默认识别逻辑。
4.2 现象：链接阶段找不到自定义段符号
现象：使用__attribute__((section("shared_mem")))定义变量后，链接报L6218E: Undefined symbol，但使用这个变量的代码明明写了 extern。
原因：AC5 对 section 属性有一个隐藏行为。如果没有指定zero_init，且变量未显式初始化，它默认会被放入RW段而不是ZI段，链接器在分散加载文件中找不到对应的执行区域，就会干脆放弃这个符号。
解决：给这种变量补上zero_init属性：
__attribute__((section("shared_mem"), zero_init)) unsigned char shared_buf[64];同时确认.sct文件中有一段RW或ZI执行区域与shared_mem对应。
4.3 现象：浮点运算导致 HardFault
现象：Cortex-M4 工程在 AC5 下编译，函数里加了float运算，烧录后一执行到该函数就进入HardFault_Handler。
原因：这不是编译器 bug，而是编译选项与硬件浮点单元没有对齐。AC5 默认按软件浮点生成代码，也就是调用__aeabi_fmul这类辅助函数，而启动代码又没有保存硬件浮点寄存器上下文，一旦函数内部使用了vfp指令，现场就被破坏了。
解决：在编译参数里加上--fpu=vfpv4（针对 M4F）或--fpu=vfpv5（针对 M7），并且链接时保持完全一致的--fpu参数。如果用的是 armcc 的 IDE 工程，在 Options -> Target 里的 Floating Point Hardware 选择Single precision，同时在 C/C++ 选项卡里把--fpu填进 Misc Controls。
4.4 现象：Linux 命令行无许可证报错
现象：在 Linux 服务器上用 Wine 调用 armcc.exe，一执行就报Fatal error: L3014E: License 错误。
原因：AC5 是 Keil 授权体系的一部分，不像 AC6 那样可以简单地通过ARM_LICENSE环境变量绕过。Wine 环境下许可证文件路径无法被 Keil 的 license 管理服务正常识别。
解决：更好的做法是不要在 Linux 下硬折腾 armcc，而是把编译放在 Windows 从机或者 Windows 容器上完成，把 Linux 这边只负责触发生成，这样许可证校验就不会出问题。如果非要在 Wine 下用，把license.dat放到模拟的 Windows 系统目录下，并设置环境变量ARMLMD_LICENSE_FILE指向该文件，成功概率会高一些，但稳定性仍看具体环境。
4.5 现象：CMSIS 头文件直接报不支持的编译器
现象：更新了 CMSIS 版本后，老工程编译第一行就报#error "Unsupported compiler!"。
原因：新版 CMSIS 5.9 及以上版本完全放弃了 AC5 分支，代码里只保留#if defined(__ARMCC_VERSION) && (__ARMCC_VERSION >= 6010050)这样的判断，AC5 的版本号（如 5060750）无法匹配。
解决：优先把 CMSIS 固定到 5.8.0 及以前版本使用。如果因为芯片支持必须用新版 CMSIS，可以在编译器预定义列表里手动加__CC_ARM宏，并在头文件包含路径中放置一个自定义补丁头文件，把__attribute__等宏在 AC5 下预先替换掉。这种做法要花点时间，但能让整个 SDK 的兼容层继续工作。
5. 进阶用法：用命令行工具链把 AC5 固化进 CI 构建
5.1 从工程文件提取编译参数
真实维护中，与其手工敲每个 C 文件的 armcc 命令，不如先从.uvprojx里把公共参数抽出来。这个文件本质是 XML，用 Python 解析<VariousControls>节点中的<IncludePath>和<Define>即可：
import xml.etree.ElementTree as ET tree = ET.parse('project.uvprojx') root = tree.getroot() ns = {'m': 'http://www.keil.com/schema/manifest'} for target in root.findall('.//Target'): inc = target.find('.//IncludePath').text defines = target.find('.//Define').text print('INC:', inc.replace(';', '\n')) print('DEF:', defines)这个脚本只是帮你把 IDE 里填好的路径和宏定义还原出来，真正的编译逻辑建议放在构建脚本里统一管理，避免多人往工程里随手加路径。
5.2 一键构建与反汇编验证
下面是一个简单的 Windows batch 构建脚本骨架：
@echo off set ARMCC_DIR=C:\Keil_v5\ARM\ARMCC set BUILD=build if not exist %BUILD% mkdir %BUILD% %ARMCC_DIR%\bin\armcc.exe --cpu Cortex-M3 --apcs=interwork -O2 --c99 --fpu=none ^ -I.\inc -I.\cmsis -DUSE_STDPERIPH_DRIVER ^ -c .\src\main.c -o %BUILD%\main.o %ARMCC_DIR%\bin\armlink.exe --cpu Cortex-M3 --scatter .\target.sct ^ --entry Reset_Handler --first Reset_Handler ^ -o %BUILD%\app.axf %BUILD%\main.o %BUILD%\startup.o %ARMCC_DIR%\bin\fromelf.exe --bin --output %BUILD%\app.bin %BUILD%\app.axf %ARMCC_DIR%\bin\fromelf.exe --text -d -c %BUILD%\app.axf > %BUILD%\app.dis脚本的最后一步就是我的验证习惯：生成反汇编文件，然后直接查找关键函数名，确认它被编译成了预期的指令序列。比如在app.dis中搜索Reset_Handler，应该能看到LDR指令读取向量表首地址跳转，而不是被优化成奇怪的跳板函数。
5.3 给工具链上一次“保险”
最后说一个我自己的教训。某一次维护设备协议栈，同事把构建机上的默认编译器从 AC5 换成了 AC6，结果所有用__attribute__((at()))定义的共享内存变量全部被链接到错误的地址，设备每隔几分钟就出现通信超时，排查花了两天。
从那以后，我每次拿到一个必须长期维护的嵌入式工程，都在构建脚本第一行强制设置CC=armcc的绝对路径，并在编译日志里输出armcc --vsn的版本号，确保任何人重新执行构建，都会用同一个编译器版本和同一套编译参数。希望帮到你。
本文还有配套的精品资源，点击获取
