简介：这是ARM Compiler v5.05 Build 169的Windows版本安装更新包，主要为使用Keil MDK及ARM Compiler 5工具链的嵌入式开发者提供。它用于在已有相应许可证的ARM Compiler 5产品上完成版本替换，适用于需要锁定编译器版本、保证构建可复现的工程项目，也可作为安全更新在开发环境中使用。需要留意的是，该编译器允许安装多个不同的功能发行版，但同一发行版的多个更新版不能共存，安装前应仔细阅读说明。整个资源共3个文件，rar解压后可看到分别承担安装引导、主程序安装与说明文档功能的exe、msi与html三类文件，能够覆盖离线部署、补丁升级和版本核对等场景，整体大小约79.71MB，体积适中，便于团队共享与归档。对开发者而言，使用该版本有利于保持与官方工具链一致，避免因编译器差异引发编译行为不同，从而为嵌入式固件的持续迭代提供稳定基础。目前已有2387人学习或下载，适合需要在Windows下配置稳定编译工具链的开发者参考使用。 前阵子帮一个朋友收拾他几年前接手的固件项目，遇到的第一道坎不是代码，而是编译环境——他机器上只有 Keil MDK 的新版本，默认编译器已经切到了 AC6，而工程还是当年用 ARM Compiler v5.05 Build 169 建的。一编译，Build Output 里直接甩出一句 missing: compiler version 5。这场景我太熟了，干嵌入式的人早晚都会撞上一次。今天就把 ARM Compiler v5.05（Build 169）for Windows 这套东西从头到尾捋一遍：它是什么、怎么在 Windows 上装好并跑通、常用编译选项怎么用、和 ARM Compiler 6 到底差在哪，以及我踩过的那些报错和解决办法。无论你是在维护老项目、搭 CI 构建机，还是刚打开一个十年老工程的压缩包，这篇应该都能用得上。
1. 先搞清楚：v5.05 这套东西到底是什么
1.1 一个编译器，其实是五件套
ARM Compiler 5（行内一般叫 AC5）是 ARM 公司提供的专有编译工具链，主要面向 Cortex-M 以及更老的 ARM7/ARM9/ARM11 这类内核。v5.05 Build 169 是其中一个具体版本，装好之后在 Keil MDK 的安装目录下可以看到一整套工具：armcc.exe 是 C/C++ 编译前端，armasm.exe 是汇编器，armlink.exe 负责链接，fromelf.exe 做格式转换和反汇编，armar.exe 用来打包静态库。很多人以为“装了个 ARM Compiler”就是装了一个编译器，其实装的是这一整套工具链，uVision 只是它的图形外壳。
默认路径一般是C:\Keil_v5\ARM\ARMCC。这个目录结构是有讲究的：bin里放工具，include里是标准库头文件，lib里是各类库以及 microlib 的支撑文件。armcc 在编译时会依赖 include 和 lib 的相对位置来定位内部头文件，所以千万不要把某个 exe 单独拷出来用，整套目录最好保持完整。这也是很多“绿色精简版”莫名其妙的根源——缺了目录结构，工具链行为就是不对。
1.2 2024 年了，为什么还有人非它不可
按 ARM 的官方节奏，AC5 早就进入停售停维状态，最后一个版本是 5.06 Update 7（Build 960）。那为什么老工程还要盯着 v5.05 Build 169 不放？我总结下来主要是三个原因：
- 历史包袱。十年前上线的产品，固件、启动文件、芯片厂 SDK 都是用 AC5 调通的，换编译器等于重新做一遍完整回归测试，周期和风险都扛不住。
- 语法宽松。AC5 对部分未定义行为比较“温柔”，老代码里大量依赖
__packed、位域、隐式类型转换等写法的工程，在 AC6 下会爆出一墙的 warning 甚至直接 error。 - 构建复现。有些项目 CI 里写死的就是 “ARM Compiler v5.05, Build 169”，不同小版本的代码生成结果有细微差异，为了保证 bin 可复现，大家只能统一锁在一个版本上。
所以 v5.05 不是“过时”，而是“稳定到不想动”。这也是我觉得值得写一篇的原因：不是教你追新，而是教你把该用的环境稳稳跑起来。
2. Windows 部署：从安装到命令行跑通
2.1 获取渠道与版本选择
AC5 最正统的获取方式是安装 Keil MDK 时捎带进来。MDK 5.37 及之前的版本还会默认带 AC5，再往后的 uVision 版本逐渐把默认编译器换成 AC6，老编译器需要额外安装 legacy 支持。如果你手头有老安装包，建议保留一份，最好把安装后的 ARMCC 目录也备份到移动硬盘——等你真正需要的时候，官网下载页可能已经不好找老版本了。
对于网络上流传的绿色版、精简包，我的态度很明确：生产环境别用。编译器这种核心工具来历不明，轻则行为怪癖，重则后门风险，省那点事不值当。正规渠道是 Keil 官网注册下载，以及 ARM 官方的 legacy software 归档，按要求注册、同意条款就能拿到。
2.2 安装验证与环境变量
装完先验证版本。打开 cmd，进到 ARMCC 的 bin 目录：
cd C:\Keil_v5\ARM\ARMCC\bin armcc --vsn正常会打印出类似 “ARM Compiler 5.05 (Build 169)” 的版本信息和许可证状态。如果提示“不是有效的 Win32 应用程序”，或者缺 msvcr90.dll 之类的运行库，多半是目录拷得不完整，或者组件被安全软件隔离了。
命令行用得多的话，把 bin 目录加进 PATH。Windows 10/11 上在“编辑系统环境变量”里把C:\Keil_v5\ARM\ARMCC\bin加进去即可。这里有个经验：uVision 自己调用 armcc 不依赖 PATH，但如果你要用脚本、CI、Makefile 编译，PATH 里能不能找到 armcc 直接决定构建成败。我做 CI 构建机时第一件事就是把 PATH 写死进系统环境变量，避免每个任务重复配。
2.3 命令行最小工程验证
光会--vsn不够，我习惯写一个最小 C 文件，把“编译、链接、转二进制、反汇编”整条链路走一遍，确认工具链真能干活。新建 smoke.c：
int main(void) { volatile unsigned int i = 0x55AA; while (1) { i++; } return 0; }然后执行：
armcc --cpu Cortex-M3 -Ospace --c99 -g --split_sections -c smoke.c -o smoke.o armlink --cpu Cortex-M3 --ro_base=0x08000000 --rw_base=0x20000000 --entry main -o smoke.axf smoke.o fromelf --bin smoke.axf --output smoke.bin fromelf --text -c smoke.axf --output smoke.dis解释一下每一步：armcc 用--cpu Cortex-M3指定内核，-Ospace面向代码尺寸优化，--c99选 C99 标准，-g带调试信息，--split_sections让每个函数独立成节，方便链接器后续丢弃没用的函数；armlink 用--ro_base/--rw_base指定只读区和读写区地址，--entry main告诉链接器入口；fromelf 则把 AXF 转成 bin，再导出一份反汇编文本，方便检查。
注意：这个最小的 bin 没有向量表和启动代码，不能当真固件烧录，它只是验证“编译-链接-转换”链路是否正常。真实工程请使用芯片对应的启动文件和 scatter 文件，下面会讲。
3. 核心编译选项与日常用法
3.1 CPU、FPU 和 interwork 怎么选
armcc 的第一个关键参数是--cpu，它决定编译器生成什么架构的指令。常见取值有 Cortex-M0、Cortex-M0+、Cortex-M3、Cortex-M4、Cortex-M4.fp。带.fp后缀表示这颗 M4 具备硬件单精度浮点单元，编译器可以直接生成浮点指令。如果你的 M4 不带 FPU，却用了--cpu Cortex-M4.fp，生成的固件一碰浮点大概率进 HardFault。手动命令行最省心的做法是：有 FPU 就选--cpu Cortex-M4.fp，没有就用--cpu Cortex-M4，让浮点运算走软浮点。只有少数需要定制 FPU ABI 的场景才需要额外配--fpu。
另一个经典参数是--apcs=interwork，它控制 ARM/Thumb 状态切换。对 Cortex-M 来说，全部代码都是 Thumb-2 指令集，本身不需要 interwork；但老工程如果还保留 ARM7TDMI、ARM9 的代码，这个选项就很重要，它保证 ARM 函数和 Thumb 函数互相调用时能正确切换状态。我的建议：保持启动文件、链接配置和全局编译选项一致，别一半工程设 interwork 一半不设，否则链接阶段容易出现奇奇怪怪的 Undefined symbol。
3.2 优化等级：O 系列与 Ospace/Otime
AC5 的优化选项分两类。第一类是 -O0、-O1、-O2、-O3，控制优化强度；第二类是-Ospace和-Otime，控制优化偏向。我用一个表把常用组合整理出来：
| 选项 | 含义 | 适用场景 |
|---|---|---|
| -O0 | 不优化，编译最快 | 调试阶段 |
| -O1 | 基础优化 | 调试加一定性能 |
| -O2 | 较高优化 | 一般发布 |
| -O3 | 激进优化 | 性能优先 |
| -Ospace | 面向代码体积 | flash 紧张的项目 |
| -Otime | 面向运行速度 | 性能敏感场景 |
有个细节容易被忽略：优化开得高，变量会被优化没、函数会被内联、循环会被重排，单步调试体验很差。所以建议调试用-O0 -g，发布时再开-Ospace或-Otime。AC5 的-Ospace比 AC6 的-Oz更“舍得下狠手”，这也是它到现在还在老项目里吃香的原因之一。
再加一个省 flash 的组合拳：armcc 加--split_sections把每个函数拆成独立节，armlink 加--remove把没被引用的节全部丢弃。对那种把整个第三方库一股脑编译进来的工程，这套组合经常能省下 10%~20% 的 flash 占用，建议做体积优化时优先尝试。
3.3 和 Keil MDK 工程配合的关键设置
图形界面下，AC5 的切换位置在 Options for Target -> Target 页面最上方的 “ARM Compiler” 下拉框。里面会列出机器上可用的编译器，包括 “Use default compiler version 5”“Use default compiler version 6” 这类默认项和具体版本号。如果你的下拉框里没有 version 5，说明机器上没装 AC5，按 2.1 的方式补上即可。
MDK 工程里真正决定链接布局的，是 Target 页面上的 ROM/RAM 起始地址，或者一个 scatter 文件。比如 STM32F103 工程常见的 scatter 是这样的：
LR_IROM1 0x08000000 0x00080000 { ER_IROM1 0x08000000 0x00080000 { startup_stm32f1xx.o (RESET, +First) * (+RO) } RW_IRAM1 0x20000000 0x00010000 { * (+RW +ZI) } }第一块是加载域也是执行域，放在片内 flash；startup 的 RESET 段放最前面，保证向量表在镜像最开头。第二块是 RAM，放 RW 和 ZI 数据，Keil 会自动生成初始化代码完成 RW 拷贝和 ZI 清零。手工改 scatter 前，一定把链接器的 map 文件打开看一眼，确认每块内存都被安排明白，否则很容易出现越界或重叠。
4. ARM Compiler 5 和 6 的恩怨
4.1 从 armcc 到 armclang，变的不只是名字
AC6 的前端换成了基于 LLVM 的 armclang 编译器，编译速度快、对 C11/C++17 支持好，但这些优势在一些老 MCU 生态里根本不重要——芯片库、启动文件、操作系统移植层全是用 AC5 时代约定写的。AC6 的编译器和汇编器都更严格，AC5 能当警告放过去的写法，在 AC6 可能就是 error。
一个最典型的差异就是内联汇编。AC5 支持__asm { ... }这种块状内联汇编，AC6 改用 GCC 风格的__asm volatile("...")字符串内联汇编。老代码里如果驱动临界区、中断开关大量使用块状内联汇编，迁到 AC6 就得整段重写。我把两者差异整理成一张表，方便对照自查：
| 项目 | AC5 | AC6 |
|---|---|---|
| 编译器前端 | armcc | armclang（LLVM） |
| C 标准支持 | C90/C99，C++03 | C11，C++17 |
| 内联汇编风格 | __asm { ... }块状 | __asm volatile("...")GCC 风格 |
| 告警严格度 | 宽松 | 严格 |
| 代码体积优化 | 经验老到，-Ospace 狠 | -Oz 更依赖新特性 |
4.2 老项目迁移到 AC6 常见的坑
真到了必须迁移的时候，我一般按这个顺序排查：先看编译日志里有没有明确报错的函数和行号，AC6 的报错定位通常很准；再把所有告警屏蔽选项重新整理一遍，老工程里常堆着一堆“已知警告”，AC6 下这些警告可能升级成 error；然后重点检查启动文件（.s）和链接脚本，AC6 需要的可能不是同一份。CMSIS 版本太老也会出问题，很多老工程的 CMSIS 是为 armcc 准备的，AC6 下建议换成配套的 CMSIS 5。
还有一类坑发生在“看起来编译过了”之后：AC6 优化出的代码 size 和 AC5 差异很大，有时性能变好，有时反而膨胀。所以迁移后必须做 code size、运行速度、中断延迟的对比，别只看功能正常就交付。我见过最夸张的一次，同一个算法从 AC5 换到 AC6，flash 占用涨了 15%，最后只能部分文件保留 AC5 编译。
4.3 该不该迁移：我的判断标准
我的经验是三个“不迁”：老产品稳定出货、代码量巨大、测试资源不足，不迁；SDK 和第三方库只有 AC5 版本且供应商不更新，不迁；团队里没有熟悉 AC6 差异的人，不迁。反过来，新项目、新 SDK、团队有精力做完整回归的，尽早用 AC6。AC5 终归是被时代抛下的工具链，能用，但会用一次少一次，别在新项目里再造新债。
5. 高频报错与排查实录
5.1 missing: compiler version 5（最经典）
这个问题在搜索热词里排第一，我太有发言权了。现象就是打开一个老工程点 Build，uVision 的 Build Output 里出现 missing: compiler version 5 之类的话，然后整个编译中止。原因很简单：工程文件里记录的编译器版本是 “Use default compiler version 5”，而当前机器的 MDK 只装了 AC6。
排查分三步。第一步，到 Options for Target -> Target 页看 ARM Compiler 下拉框，确认是否有 AC5 选项；如果没有，就是没装。第二步，补装 AC5：最省事的是安装一个带 AC5 的 MDK 老版本（比如 5.37），或者把 ARMCC 目录从同配置的机器原样拷过来，前提是你有合法的 MDK 授权。第三步，把下拉框显式选到已有的 AC5 版本，重新编译。有些工程还会在 Options 里存了绝对路径，换机器后路径不对也会报类似错误，顺手检查一下 Header 路径和输出目录。
5.2 License、路径与 Windows 环境问题
armcc 是商业编译器，许可证缺失时会在编译阶段直接报错，现象是 license 相关错误，有时还会带 0x37 之类的错误码。这种问题多发生在重装系统、更换主板、许可证到期之后。处理方式：打开 uVision，进 File -> License Management，重新导入 license 文件，或走在线激活。如果公司用的是浮动许可证，要保证 license server 地址可达，防火墙别拦截对应端口。
Windows 上还有几个环境坑值得记录。一是路径带空格，装在C:\Program Files\Keil\...下时，批处理里记得给路径加引号。二是命令行长，项目大了 -I 和 -D 参数几十个，命令行长度超限就莫名失败，AC5 支持--via参数文件，把一堆选项写进 rsp 文件再--via=build.rsp传给工具，干净利落。三是安全软件，老版本 armcc 有时会被误报，给 ARMCC 目录加白名单能少很多麻烦。
5.3 编译结果不一致与构建复现
还有一种问题不报错，但更坑：同一份源码，两个工程师电脑上编出来的 hex 不一样。多数原因是编译器版本不同。AC5 的 5.05、5.06 各 build 之间，代码生成都会有小差异；如果 CI 明确要求 “Build 169”，本地就别装 Build 750。锁定版本之后，尽量保持相同的库选项（比如 microlib）和相同的优化参数，这样固件才能可复现。
我见过最折腾的情况是：代码完全没动，只是换了一个 MDK 版本，结果 flash 占用多了 4%。后来定位到是 MDK 自动启用了 link-time optimization 之类的新特性。所以老项目我建议把完整的工具链版本号、编译参数、库选项都写进构建脚本，不要让 IDE 的默认值“顺手”改变工程行为。
6.1 值得长期坚持的几条习惯
最后分享几个我亲测有效的做法。第一，老机器上留一个装有 MDK 5.37 和 AC5 的 Windows 虚拟机，平时不用，碰到老工程救急，比四处找安装包强太多。第二，凡是进过 CI 的固件，构建脚本第一行打印 armcc 版本号，配合--vsn直接输出到日志，能省掉很多“为什么又编不过”的排查时间。第三，维护老工程时，代码里能用__packed的地方绝不依赖默认对齐，能用显式类型转换就不要让编译器猜，这样以后哪怕是迁移到 AC6，也能少一层风险。
6.2 一个百试百灵的排查起手式
如果哪天你在一台新电脑上打开老工程，遇到各种莫名其妙的编译报错，我的起手式永远是：先确认编译器版本、确认 include 路径、确认许可证。这个“铁三角”没问题，再去看代码。ARM Compiler v5.05 Build 169 已经不是一个新东西，但在大量存量设备、老 SDK 和成熟产品线里，它依旧是那个最可靠的后盾。工具链换代是大趋势，可一脚踩进 missing: compiler version 5 的坑时，你能做的不是抱怨，而是把环境弄清楚、把选项用到位、把坑记下来。希望这篇能帮到正在跟老编译环境搏斗的你。
本文还有配套的精品资源，点击获取
