手上同时开三个项目一个 STM32F103 的老固件锁在 IAR 8.50 里一个新板子用的是 9.40还有一个客户丢过来的 8051 工程必须在 IAR for 8051 里才能编过。这种场面做嵌入式的人应该都不陌生。这时候你会发现IAR 各个历史版本集合这件事不是收藏癖而是实实在在的生产力问题——电脑里到底该装哪几个版本、新老工程怎么互不打架、License 怎么管、老版本上移植 RTOS 为什么特别容易翻车全都是每天要面对的。这篇就把我这些年攒下来的 IAR 版本档案整理一遍各个产品线的版本脉络长什么样、版本号里那串数字到底代表什么、怎么在一台机器上让多个历史版本和平共处、老版本上跑 FreeRTOS 和 RT-Thread 时最常踩的坑在哪以及历史版本到底该怎么合法获取和归档。适合正在维护老项目、需要多版本并存的嵌入式工程师也适合刚开始接触 IAR、被这个工程我打不开劝退过的朋友。1. 老工程为什么对新版 IAR 这么挑食很多人以为换个更高版本的 IDE 就是升级点一下 Convert 就完事。真到项目上你会发现一个 2013 年用 IAR 6.50 建的 STM32F103 工程用 9.40 打开编译报错能刷满一屏。这不是 IAR 做得不好而是嵌入式工具链的代际问题——编译器内核、运行时库、ABI、器件描述文件、工程文件格式这五样东西任意一个变了老工程都可能不认。1.1 编译器内核换代的连带影响IAR 的 ARM 编译器叫 ICCARM它本身有自己的版本线。EWARM 5.x 时代用的是 ICCARM 7.x 内核6.x 到 7.x 对应 ICCARM 8.x8.x 之后是 ICCARM 9.x 一路走到现在。内核换代最直接的影响是默认语言标准和优化策略。老版本的默认可能是 C89 或者 gnu99 的某个变体新版本默认语言标准更高一些以前能过的隐式类型转换、函数声明缺失在新编译器下会直接升级成 error。我印象比较深的是 8.x 引入新优化器之后同一份代码在 8.30 和 7.80 上编出来的汇编差得挺多。绝大多数情况下结果是好的——代码更小、跑得更快但如果你代码里有对时序很敏感的裸机延时、或者依赖某个变量的读写顺序新优化器可能会把它优化掉。这类问题特别隐蔽编译期一声不响跑起来偶发死机。提醒跨大版本升级老工程时先把优化等级统一降到 Low 跑一轮功能测试确认逻辑没问题再逐级调到 High比一上来就 High 直接 Debug 效率高得多。1.2 工程文件格式的转换是不可逆的IAR 的工程由.ewp项目、.eww工作区、.ewd调试配置、.ewt、.dep这几个文件组成。新版本打开老工程会弹一个转换对话框点完之后.ewp里的节点名和 option 的取值都会被重写成新格式。这个动作是单向的——转换过的工程老版本再也打不开了直接提示工程由更高版本创建。所以我的习惯是拿到任何一个需要升级的老工程第一件事是整目录复制一份重命名成xxx_ewarm850和xxx_ewarm940这样的后缀各自独立维护谁也不动谁。用 Git 管也行但注意.ewp转换后会整文件重写diff 里几乎全是噪音行级审查意义不大。1.3 器件支持文件是跟着版本走的IAR 的器件支持不是插件式的它跟着安装包走。你在 8.20 里是找不到某些国产 MCU 或者 STM32 后期型号的器件选项的下拉列表里根本没有。这时候要么升级到有支持的版本要么让这个版本认识这颗芯片路径有两条用 IAR 的Device File Updater从官方渠道更新器件描述文件.ddf/.men一类补齐器件库在工程里选一个最接近的通用 Cortex-M 器件然后用自定义链接器配置.icf和自定义启动文件接管内存布局把它当编译器认识的裸核来用。第二条路我更常用尤其碰到国产替代芯片的时候。反正链接脚本和启动文件都要自己改器件下拉框选哪个只影响默认的头文件和中断向量名手动接管之后差异就不大了。2. IAR 各产品线的版本脉络与版本号解码IAR 不是只有 ARM 一条线。它按目标架构分了好几条产品线各自有完全独立的版本号。很多人搞混我装的是 IAR 几其实说的是不同产品线的版本两个数字放在一起比较没有意义。2.1 主流产品线的大致分布下面这张表是我手头整理过、在工作中实际碰到的版本分布具体以官方发布记录和你手上的授权为准产品线全称常见版本跨度典型使用场景EWARMIAR Embedded Workbench for Arm5.50 / 6.50 / 7.80 / 8.20 / 8.30 / 8.50 / 9.10 / 9.20 / 9.30 / 9.40 / 9.60STM32、GD32、NXP、国产 Cortex-MEW8051IAR Embedded Workbench for 80517.x / 8.x / 9.x / 10.xCC2530、传统 8051 工控板EWSTM8IAR Embedded Workbench for STM81.x / 2.x / 3.xSTM8S、STML 系列EWAVRIAR Embedded Workbench for AVR5.x / 6.x / 7.x老 AVR 项目、部分 Arduino 底层EWRL78IAR Embedded Workbench for RL783.x / 4.x瑞萨低功耗 MCUEWRISCVIAR Embedded Workbench for RISC-V1.x / 2.x / 3.x新起来的 RISC-V 芯片有个地方要特别注意STM8 这条线基本停在 3.x 不再更新了8051 线也进入维护状态。如果你手上的 STM8 工程是十几年前建的不用指望升级到新版本能带来什么改善找到能开的版本稳定用着才是正解。2.2 版本号里那串数字怎么读以8.50.9这个版本号为例拆开看是三段8.50是主版本号决定编译器内核、工程文件格式、器件库的基线。跨主版本升级才需要转换9是补丁号Service Pack / Update修 bug、补器件、偶尔加小功能格式不变可以无痛替换有时候还会看到9.30.1这样更长的或者带 hotfix 后缀通常是紧急修复。搞清这个层级的好处是你不需要把每个补丁版本都收一遍。同一主版本内留最高的那个补丁就够用了比如 8.50 系列留 8.50.9 就行。真正需要并存的是不同主版本因为编译器内核不同。反过来讲如果某个项目明确要求必须用 8.30.3 编出来的固件那就别自作主张换 8.40因为编译器一变二进制就不一样了做固件版本追溯的时候会对不上。2.3 命令行构建工具其实也在版本里顺带说一个埋得比较深的点IAR 从某个版本起把命令行构建工具也打包进来了叫IarBuild.exe位置一般在安装目录的common\bin下。做持续集成的时候直接调它就行# 编译 Debug 配置 IarBuild.exe project.ewp -build Debug # 清理后重编 IarBuild.exe project.ewp -make Debug # 输出编译日志方便 CI 抓取 IarBuild.exe project.ewp -build Release -log all这里有个坑IarBuild.exe是跟着安装版本走的。如果你的 CI 机器上装了 9.40但项目要求用 8.50 编那指定错版本会直接编不过或者产出物不对。我的做法是每台 CI 机器上用绝对路径写死一个构建脚本绑定一个 IAR 版本不做系统默认版本这种依赖。3. 让多个历史版本在同一台机器上共存好消息是IAR 的安装设计对多版本共存是友好的——默认就装到Embedded Workbench x.y这样的版本专属目录里不像某些工具一升级就把老版本覆盖掉。但能装和用着舒服是两码事下面这些细节是我踩过之后才总结出来的。3.1 安装顺序与目录规划我的建议是从旧版本装到新版本因为 IAR License ManagerILM是共用组件新版本的 ILM 向下兼容旧版本授权反过来不一定。先装新版 ILM 再装老版有时候会把 ILM 降级回去导致新版本的授权识别出问题。目录规划上我会在盘符根目录建一个清晰的归档结构D:\Tools\IAR\ ├── EWARM_8.50.9\ # 安装主体也可以直接用默认 Program Files 路径 ├── EWARM_9.40.1\ ├── EW8051_10.30\ ├── _installers\ # 原始安装包归档 │ ├── EWARM-8.50.9.exe │ └── EWARM-9.40.1.exe └── _notes\ # 每个版本的说明、授权信息、已知问题顺手把每个版本的release_notes和安装包一起存档以后遇到这个功能哪个版本才有的这种问题翻记录比上网查快得多。3.2 授权管理别把问题想复杂了这一块我只讲正规路径因为嵌入式工具链的授权是有明确使用边界的走歪路既有法律风险出了问题也没人帮你排查。IAR 的授权是通过IAR License Manager统一管理的常见的授权形态有这么几类绑定单机的授权、网络浮动授权、以及官方提供的评估授权。授权文件通过官方渠道获取用 License Manager 导入和管理。日常最常遇到的报错是Fatal Error[LMS001]: License check failed看到这个先别慌按下面的顺序排查八成能定位现象可能原因排查动作昨天还能编今天报 License 错授权服务没启动检查 IAR License Manager 服务状态重启服务换电脑或换网卡后报错单机授权绑定硬件标识变了就不认向官方申请重新生成绑定当前机器的授权系统时间被改过之后报错授权有效期校验依赖系统时间把系统时间恢复到正确值多人同时用报错浮动授权的并发数用满了联系管理员看谁占着或者释放未使用的会话新版本装了报错老版本正常授权维护期覆盖不到新版本确认授权覆盖的版本范围用维护期内的版本最后一条特别值得说。IAR 的授权通常带维护期维护期到期后你能用的最高版本就被锁住了。比如维护期到某个时间点截止那之后发布的新版本装了也用不了会直接报 License 校验失败。这时候不是装坏了是版本超出授权范围了老老实实用维护期内的最高版本。注意授权文件、激活信息属于受法律保护的商业许可只从官方渠道获取和申请。任何绕过授权的做法都不在讨论范围内。3.3 工程在两个版本之间来回切的注意点同一台机器装了 8.50 和 9.40工程怎么切几个实操细节输出目录要分开。两个版本对.o、.d、.pbi这类中间文件的格式定义不一样如果共用Debug目录切版本的时候会出现改了代码没重新编或者莫名其妙的链接错误。我一般把配置名改成Debug_850和Debug_940输出目录自然分开了。Startup 文件和链接脚本要按版本准备。有些老工程里带着cstartup.s这类汇编文件不同版本的 ICCARM 对汇编语法的支持有差别尤其是在宏、条件汇编和SECTION指令上。同一份启动文件在两个版本下可能需要做条件编译用#if defined(__IAR_SYSTEMS_ICC__)加版本判断来区分。IAR 提供了__VER__宏可以拿到当前编译器版本号写条件编译很方便。自定义命令行参数别写绝对路径。工程选项里如果塞了自定义参数比如预编译脚本、代码检查工具、第三方打包命令尽量用$PROJ_DIR$这种内置变量而不是硬编码路径否则换台机器或者换个人接手就得重新配一遍。4. 老版本 IAR 上移植 RTOS 的实战细节热词里FreeRTOS 学习篇一STM32F103C8T6 下的移植IAR 移植 RT-Thread这类搜索量一直很高说明大量人是在老版本 IAR 上做这件事。我拿 STM32F103C8T6 这种小容量芯片 老版本 IAR 的组合把最容易出问题的地方捋一遍。4.1 为什么老版本上移植更容易出内存布局的坑STM32F103C8T6 是 64KB Flash、20KB RAM 的配置RAM 本来就紧张加上 FreeRTOS 的堆heap和任务栈很容易把 RAM 吃到见底。老版本 IAR 的默认链接脚本里堆和栈的预分配往往偏保守或者偏大需要手动调.icf文件。典型的一段.icf配置长这样/* STM32F103C8 的 RAM 只有 20K堆栈要精打细算 */ define symbol __ICFEDIT_size_cstack__ 0x400; /* 主栈 1K */ define symbol __ICFEDIT_size_heap__ 0x000; /* 应用程序自管堆这里给 0 */ define region RAM_region mem:[from 0x20000000 to 0x20004FFF]; place in RAM_region { readwrite, block CSTACK };关键点是size_heap__给 0。因为 FreeRTOS 用自己的heap_1.c到heap_5.c之一来管内存它需要一个大的静态数组当堆池。如果你让 IAR 也留一块堆等于两边各占一份白白浪费 RAM。那 FreeRTOS 的堆数组怎么指定段很多人见过这种写法/* 让编译器把这个数组放到指定的段里 */ #pragma section .heap uint8_t ucHeap[ configTOTAL_HEAP_SIZE ] .heap;或者在FreeRTOSConfig.h里打开configAPPLICATION_ALLOCATED_HEAP自己定义ucHeap。老版本 IAR 对 段名这种写法支持是有的但要注意如果.icf里根本没定义这个段编译器会把它丢到默认的 readwrite 区间结果就是段落点不可控堆的位置可能和别的变量叠在一起。所以要么在.icf里显式place in RAM_region { block HEAP };要么就别折腾段直接用__no_init加大数组。4.2 启动文件、中断向量和 PendSV老工程迁移过来的时候启动文件经常是随手从别的工程拷的。这里有两个易错点第一是中断向量表的段名和放置位置。IAR 的启动文件通常用SECTION .intvec:CODE:NOROOT(2)定义向量表链接脚本里要用place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };把它放到 Flash 起始处。如果这个地址和芯片的启动地址对不上比如某些芯片有 bootloader 偏移程序会直接从跑飞开始。第二是PendSV 和 SysTick 的优先级。FreeRTOS 依赖 PendSV 做任务切换它必须被设成最低优先级否则在中断里调用 RTOS API 会踩栈。FreeRTOSConfig.h里这几个宏一定要配对#define configPRIO_BITS 4 /* STM32F1 用 4 位优先级 */ #define configKERNEL_INTERRUPT_PRIORITY (15 (8 - configPRIO_BITS)) #define configMAX_SYSCALL_INTERRUPT_PRIORITY (5 (8 - configPRIO_BITS))老版本 IAR 里__NVIC_SetPriority这类内联函数可能不存在或者签名不同用寄存器直接写NVIC-IP[...]更稳妥不依赖 CMSIS 版本。4.3 编译过了但跑飞的典型症状对照移植 RTOS 最难受的不是编译报错是编译干干净净、下载进去直接进 HardFault。下面这张表是我这些年攒下来的症状对照症状高概率原因定位手段上电就进 HardFaultmain 都没进向量表地址不对或者栈指针初值错在 C-SPY 里看 PC 和 SP对照.map文件确认向量表落点main 跑了创建第一个任务就挂RTOS 堆太小pvPortMalloc返回空指针加大configTOTAL_HEAP_SIZE打印剩余堆大小单任务正常切到第二个任务死机PendSV 优先级高于 SysTick或者任务栈太小检查优先级宏把任务栈先调到 512 字再逐步缩中断里调用 API 后卡死中断优先级高于configMAX_SYSCALL_INTERRUPT_PRIORITY把所有调用 RTOS API 的中断优先级调到 5 及以下串口打印几行就停半主机模式semihosting阻塞或者 MISRA 检查拖慢时序关掉半主机改用寄存器直接写 UART半主机这个坑值得单独提一句。IAR 默认的printf走的可能是半主机模式需要调试器配合一旦脱离调试器独立运行就卡在BKPT指令上。老工程里常见做法是重定向__write直接用寄存器操作串口size_t __write(int handle, const unsigned char *buf, size_t len) { for (size_t i 0; i len; i) { while (!(USART1-SR USART_SR_TXE)); USART1-DR buf[i]; } return len; }5. 历史版本从哪来、怎么归档、怎么隔离5.1 获取渠道和授权边界历史版本的获取有个现实约束官方下载页一般只放当前在维护期内的版本更早的版本不一定公开挂着。能走的路子是自己机器上以前装过的安装介质和安装目录都留着别急着删通过官方支持渠道申请特定版本有合法授权的前提下公司内部如果有版本库找管理员要这是最靠谱的方式。明确一点版本归档的目的是维护已有工程的兼容性不是为了规避授权。每个版本该有的授权一个都不能少。5.2 目录命名和备份策略我用了很多年的命名规则是产品线_版本_平台比如EWARM_8.50.9_win64、EW8051_10.30_win32。好处是排序之后天然按产品线和版本排好一眼能找到。备份我分三层安装包层原始 exe/iso 归档附上官方给的校验值定期校验有没有损坏配置层每个版本的授权信息、已知问题笔记、常用工程的模板配置产物层装好之后导出一份最小可用环境的说明比如需要哪些环境变量、哪些组件可以不装。5.3 虚拟机隔离多版本并存的终极方案如果公司对环境的干净程度要求高或者你同时要维护好几个差异巨大的老项目那虚拟机是最省心的方案。思路很简单一个虚拟机装一个 IAR 主版本装完打好快照。好处有三一是 License Manager 环境完全隔离不会互相干扰二是工程文件彻底分开不存在手滑用错版本打开的风险三是快照可以回滚装崩了直接恢复不用重装系统。代价是磁盘占用和性能开销跑编译的时候能感觉到慢一些但换来的是可复现。如果不想上虚拟机退一步的做法是在 Windows 上开不同的用户账户每个账户装一套环境变量和开始菜单都是分开的比共享一个账户干净。最后分享一个我一直在用的小技巧给每个 IAR 版本的快捷方式重命名成带版本号的名字比如IAR 8.50 (STM32F103 老项目)、IAR 9.40 (新板子)图标也顺手换一下颜色。听起来很琐碎但当你在赶工期的深夜手忙脚乱地打开工程时这点视觉区分能帮你少犯好几次用错版本打开了工程、还顺手点了转换的低级错误——这个错误我犯过一次代价是花了一个下午从备份里恢复工程文件。