简介：IAR中文用户手册-官方版PDF面向使用IAR Embedded Workbench进行嵌入式开发的工程师与在校学习者，尤其适合基于Atmel AVR微处理器做项目、需要查阅官方IDE用法的人群。手册系统讲解嵌入式IAR Embedded Workbench IDE、C-SPY调试器与调试系统、C/C++编译器、汇编器、XLINK连接器，以及XAR库创建器和XLIB库管理器等组件的功能与配置；教程部分从新建工程、编译连接，到C-SPY断点调试、C与汇编混合编程、C++工程创建及中断模拟，逐步给出可跟做的操作路径，可作为随时查阅的速查资料，也可作为系统学习的参考资料。压缩包内共1个PDF文件，约859KB，体积轻便，便于离线保存与打印查阅。该手册已有3380人学习下载，说明其在AVR开发群体中具有较高的实用认可度。对于想弄清工程目录结构、文件类型与文档组织方式，或需要排查编译连接与调试环节问题的读者，这份官方文档能提供较为权威的答案。

1. 手册不是拿来读的：一份 AVR 工程从建到调的真实时间线

多数人下载 IAR中文用户手册 之后，第一个动作是把它拖进“资料”文件夹，然后继续在群里问“工程建好了为什么链接一堆重复定义”。这份 PDF 的价值从来不在通读，而在于它把一条完整链路写死了：从安装目录里 Avr\config 下的模板文件，到 C-SPY 连上目标板落下第一个断点。它面向的是拿 AVR 系列微控制器做嵌入式开发的人，尤其是刚接手别人工程、需要快速弄清“哪个选项在哪一层生效”的工程师。我按真实推进顺序拆：先认工具链分工，再建工程编译，再调中断和混合编程，最后说手册里没加粗、但能让你卡半天的几处。中间会夹带命令行、目录表和省时间的做法，能直接抄。

2. 工具链全景：编译器、汇编器、XLINK 与 C-SPY 各自管什么

开工之前先把“谁产出什么”搞清楚，后面所有报错都能对号入座。这套 IDE 不是一个单体程序，而是一串可单独调用的可执行文件：编译器和汇编器把源码变成可重定位目标，链接器把它们拼成可下载的机器码，库工具负责打包和裁剪，调试器靠前面几步输出的扩展调试信息做源码级调试。手册第一部分 1.1 到 1.1.7 讲的就是这套分工，只是写成了产品说明的口吻，落地时得换个读法。

2.1 从源码到可执行文件：四段流水线与各自的产物

把链路拆成四段，每段的输入输出都很明确。第一段是 C/C++ 编译器，输入 .c/.cpp，输出可重定位目标文件，同时生成扩展调试信息；第二段是汇编器，输入汇编源文件，输出同样是可重定位目标，并且它内置了 C 预处理器，所以条件汇编可以直接用；第三段是 XLINK 链接器，输入一个或多个可重定位目标加库，输出完整的可执行目标文件，可以下载到芯片或送进硬件仿真器；第四段是库工具，XAR Library Builder 负责建库，XLIB Librarian 负责列举、添加、插入、更换、移除库里的模块。

这四段里最容易被跳过的是“库”这一环。手册里明确写了，XLINK 只把应用程序真正用到的库模块拉进来，所以库里放一百个函数不等于固件就大一百个函数。反过来，某个模块一旦被引用，它会连带把它内部依赖的东西全拖进来，一个格式化输出函数可能顺手带来几 KB 的代码。评估固件体积时，先看链接结果里被引入的库模块清单，比盯着源码删函数有效得多。

命令行这条路手册也提到了：编译器、汇编器和链接器都能脱离 IDE 运行。我一般在怀疑 IDE 选项没生效时会走一次命令行，把变量隔离掉。

# 先看清本机安装目录里真实存在的可执行文件名，别照抄博客 ls "<安装路径>/avr/bin" ls "<安装路径>/common/bin" # 单文件编译：输出可重定位目标，保留调试信息 iccavr main.c -o main.r90 --debug # 链接：-f 指向链接命令模板，具体文件名以本机 avr/config 目录为准 xlink main.r90 -f "<安装路径>/avr/config/lnkavr.xcl" -o app.d90

这两条命令的作用是验证“源码到目标”“目标到可执行”两段是否通。参数上要盯住三处：第一个是输出文件的扩展名，它决定后续工具怎么识别这个文件；第二个是链接命令模板，它里面写死了存储器布局、段分配和要包含哪些库，换芯片或换存储器型号时必须换模板；第三个是调试信息开关，关掉之后体积会小一点，但 C-SPY 就只能看反汇编，源码级断点和变量观察全部失效。命令行的选项名各版本有差异，别把博客里的参数当圣旨，以本机 help 输出和 config 目录里的模板为准。

还有一个选型点值得单独说：运行库有两套。DLIB 兼容 ISO/ANSI C 和 C++，支持 IEEE 754 浮点、多字节参数和局部参数；CLIB 是轻型库，不完全兼容标准，也不支持 IEEE 754 和 C++。判断方法很简单——工程里用了 C++、用了浮点格式化输出、或者要跨模块传结构体参数，就必须 DLIB；反过来，一个纯 C、只做寄存器操作、Flash 和 RAM 都掐着字节数算的小固件，才值得考虑 CLIB。混用是最常见的翻车来源，后面第 5 章会展开。

2.2 C-SPY 五种驱动怎么选：仿真器 / ICE200 / JTAGICE / JTAGICE MKII / CCR

C-SPY 是这套工具链里最值钱的部分，但“C-SPY”本身只是个壳，真正干活的是驱动。手册 1.1.3 列了五种：软仿真器、ICE200、JTAGICE、JTAGICE MKII、以及面向智能卡开发板的 CCR 驱动。选错驱动的表现很直接——要么连不上，要么连上了但断点行为和你预期完全不一样。

选型不用纠结：手上没板子，或者板子还没焊回来，先用软仿真器把纯逻辑跑通，它的价值在于“在拿到硬件之前就能验证程序逻辑”，而且外围设备也能通过宏系统做一定程度的模拟；有 MKII 就用 MKII，4 个硬件断点加不限量软件断点，日常够用；ICE200 和 JTAGICE 现在多半只在维护老项目时才会遇到，注意它们都不支持代码和数据覆盖，做覆盖率统计时别指望。

这里有个反直觉的点：软仿真器“没有硬件断点限制”，但不代表它更好用。它是指令级仿真，跑一段延时循环要一条条指令走完，实际耗时可能比真机慢几个数量级；而且外设行为是模拟出来的，寄存器读写看着对，时序特性却和真实芯片不是一回事。我见过有人用软仿真调通了串口收发时序，烧进芯片后波特率对不上——仿真器不会告诉你晶振误差和中断响应延迟。

注意：切换驱动后要重新确认工程里的设备型号和链接命令模板。驱动换了但模板还指着上一块芯片的存储器布局，链接能过，跑起来就是随机崩。

2.3 安装目录一次看全：Avr\config、Avr\inc、Avr\lib 里到底放什么

手册 1.2 节把目录结构讲得很细，但它是按“有什么”组织的，实际用起来应该按“什么时候会进去”组织。默认根目录在系统盘的 Program Files 下，版本号挂在路径末尾，安装路径可以自定义，但改了之后所有模板里的相对路径都得跟着对。

这张表里最该记住的是 Avr\config 和 Avr\tutor。前者是你所有“换个芯片试试”的动作入口，后者是唯一能让手册教程真正跑起来的东西——很多人照着第 2 章敲了一遍发现编译不过，就是因为没打开 tutor 目录里那份现成工程，自己手敲漏了选项。

在 config 目录里动手有个铁律：先复制再改。安装目录下的文件在升级或重装时会被覆盖，改了半天的心血一夜清零，这种后悔药没地方买。正确做法是把目标 .xcl 或 .ddf 复制到工程目录，然后在工程选项里把路径指过去，安装目录保持出厂状态。

3. 建工程与首次编译：把教程第 2 章翻成可复现步骤

手册第二部分是教程，从新建工程一路写到用库模块。它的顺序是对的，但省略了“为什么这么设”。工程建错的表现往往不是当场报错，而是三天后你发现某个文件的优化等级和别的不一样，行为对不上，查一整天。这一章把教程的每一步补上判断依据。

3.1 工程层级与选项继承：工作区、工程、组、文件四级

这套 IDE 的组织结构是四层：工作区里可以放一个或多个工程，工程里可以建组，组里放文件。选项能在工程级、组级、文件级三个位置设置，低层级覆盖高层级。这个继承关系是所有人第一天就会踩的坑——你在工程级把优化调成体积优先，某个早期从别处拷来的文件在文件级还留着速度优先，于是整个工程只有它一个的表现和别的不同，日志里也看不出来。

新建工程的推荐路径是走模板。Avr\config 下放着工程和库工程的模板文件，创建时选对应模板能直接把链接命令模板、设备描述、库配置这些一次性配对，比手工从空工程配要稳。选模板时唯一需要你自己确认的是目标芯片型号，这个选错，后面所有寄存器地址全错，且编译器不一定报错。

第 6 步的 Make 和 Rebuild All 区别要弄清。Make 只重编必要的文件，这是它的设计目的，但它依赖工程记录的依赖关系；如果你改了头文件而工程里没记录这层依赖，它就不会重编用到该头文件的源文件，于是你拿着旧目标文件调试新代码。血泪经验是：改过头文件、换过编译选项、动过库配置之后，第一次编译一律 Rebuild All，别省那几十秒。

编译产物里有两类文件值得分开看：编译器的输出（可重定位目标和可选的汇编列表）与链接器的输出（可执行目标和映像文件）。前者告诉你单个文件的代码生成情况，后者告诉你整个程序在存储器里怎么排。查“这个函数到底被编译成什么样”看前者，查“为什么 RAM 超了”看后者。

3.2 .xcl 与 .ddf：改哪里、别改哪里

.xcl 是链接命令模板，里面写的是存储器布局、段怎么分配到哪个地址区间、要包含哪些库、输出什么格式。它决定了代码和数据最终落在哪，所以换芯片、改存储器型号、加 bootloader 分区，动的是它。改法前面说过：复制到工程目录，改副本，工程选项指过去。

.ddf 是 C-SPY 的设备描述文件，调试器靠它认识这颗芯片有哪些寄存器、存储器映射长什么样、中断向量表怎么排。绝大多数情况下不该动它——芯片在支持列表里，选对型号就够了。只有在用自定义板、或者芯片型号不在列表里时，才需要照着相近型号改一份出来。改 .ddf 出错的表现很有辨识度：程序能下载能跑，但调试器里寄存器窗口显示的值和芯片手册对不上，或者中断断点永远不触发。

.sfr 是特殊功能寄存器的描述文件，编译器和汇编器用它把寄存器名翻译成地址。如果你在代码里写寄存器名提示未定义，先确认头文件包含路径，再确认这颗芯片的 .sfr 里到底有没有这个寄存器，最后才怀疑写错名字。顺序反过来会浪费很多时间。

提示：动 .xcl 之前先把原始文件里和你相关的段命令抄到笔记里。链接报“段溢出”时，第一个要对照的就是这份原始布局，而不是凭记忆改。

3.3 从编译日志和映像文件读链接结果

手册在文件类型那一节埋了一个很实在的提醒：从命令行运行链接器时，映像文件默认扩展名是 lst，而这个扩展名和编译器生成的汇编列表文件撞了，会直接覆盖掉编译器那份。后果是隐蔽的——你以为在看某个源文件的汇编列表，实际看到的是整个程序的映像，或者反过来，编译器的列表被悄悄冲掉，回头对汇编时发现内容和源码根本对不上。

解决办法不复杂：把链接器的映像输出显式命名，带上完整后缀，比如 project1.map；在 IDE 里则去链接器选项把列表输出改名，别用默认值。这个小习惯救过我一次——某次排查一个段被莫名其妙放到 RAM 高地址的问题，靠的就是几个月前留下的 map 文件对比出来的差异。

map 文件怎么读，我一般按三步：

1. 先看总体占用，Flash 和 RAM 各用了多少、还剩多少，判断是不是已经贴着上限。
2. 再看被引入的库模块清单，尤其是那些你没想到会用到的模块，它们往往是体积失控的真凶。
3. 最后看段的起始地址和大小，对照 .xcl 里的布局，确认没有段被放到了不该去的地方。

第 3 步最容易被忽略。一个段被放到错误地址，程序可能照样编译链接通过，甚至简单功能也能跑，直到某个变量被外设的 DMA 缓冲踩掉才暴露。这种事没有 map 文件根本查不出来。

4. 调试与中断仿真：C-SPY 里真正省时间的三件事

调试器用得好不好，差距不在会不会下断点，而在你知不知道断点是怎么实现的、什么时候它会骗你。手册第四到第六部分讲调试器概念和各驱动的特殊性质，1.1.2 节列了总体特性，其中几条在实际排错时价值极高。

4.1 断点体系：代码断点、数据断点、条件断点

代码断点管“执行到这儿停”，数据断点管“这块内存被读写时停”，条件断点在前两者基础上加表达式过滤。三者背后机制不同：代码断点在硬件调试器上通常要占用芯片的硬件断点资源，数据断点同样如此；软件断点靠改写指令实现，数量不受限但要求代码在可写存储器里。

MKII 驱动的规格是 4 个硬件断点加不限数量软件断点。这意味着你同时挂五个数据断点，第五个大概率静默失效——不报错，就是不停。我踩过这个坑，当时以为是变量没被写，查了两小时才发现是断点数量超了。判断方法：把不相关的断点先全删，只留一个，如果它开始正常停了，那就是数量问题。

还有一个更隐蔽的：优化等级高的时候，源码行号和实际指令的映射会错位，变量可能被完全放进寄存器，你在变量窗口看到的“当前值”是个过时快照。C-SPY 支持在调试时直接改源码（改动在重启后生效），也支持在启动调试器之前就设好源码断点并让它跟着语句走——即使中间插入了新代码，断点仍关联到原来那一段逻辑，这个特性很实用。但优化带来的观察失真没法靠它解决。

常见做法是维护两个构建配置：一个调试构建，优化关掉或调到最低，用来单步和看变量；一个发布构建，优化全开，用来测体积和时序。在发布构建里怀疑逻辑问题时，先把可疑变量加 volatile 再看，别对着被优化掉的变量较劲。

4.2 用宏系统搭一个中断仿真环境

软仿真器最有用也最少人用的功能是中断仿真。手册教程 2.5 节把它拆成四步：加入中断句柄、创建仿真环境、执行中断仿真、以及在断点中配合宏使用。这四步的顺序不能乱，因为仿真环境没建好之前触发中断，调试器不知道向量表在哪，触发了也没反应。

C-SPY 的宏系统是这套调试器里最强的部分，能定义一串复杂动作并执行，可以单独用，也可以和断点联合。软仿真器驱动把外围设备仿真和宏系统、直接断点绑在一起，所以像“串口收到一个字节”这种事件，可以靠宏去写数据寄存器加置标志位来模拟。

宏的具体命令名我不在这里写死，因为不同版本的下拉列表不一样，硬抄容易错。稳妥的做法是打开 IDE 的宏编辑器，从自带示例里复制一份改，把里面的寄存器名和值换成你要模拟的外设，然后挂到一个断点上。第一次跑建议只做一件事：置一个标志位，观察中断函数有没有进去。确认通了再往里加动作。一次写十个动作的宏，出错时你根本不知道是哪一步的问题。

注意：软仿真器里的中断响应时序和真机不同，用它验证的是“中断进没进去、现场保没保护对”，不是“响应延迟多少微秒”。后者必须上硬件。

中断句柄写完之后，还有一件事要确认：中断向量表有没有正确建立。有些工程的启动文件里向量表是弱定义，你没提供句柄它就指向默认处理，编译链接都不报错，中断来了直接跳进死循环。查这个的办法是看 map 文件里向量表那一段的地址分布，或者干脆在默认处理函数里下个断点，跑一遍看它会不会被撞上。

4.3 C 与汇编混合：先确认调用规则再动手

手册教程 2.3 节讲混合模式，第一小节标题就是“检查调用规则”，这个顺序是对的。C 调汇编或者汇编调 C，出错的表现往往不是编译报错，而是“函数返回后某个 C 变量莫名其妙变了”“参数传进去是垃圾值”，本质都是调用约定没对上。

调用约定要确认的项不多，但每一项错了都很难查：

我的习惯是：先在 C 里写一个签名相同的空壳函数，编译出汇编列表，照着它生成的函数序言和尾声写自己的汇编。这比翻文档快得多，而且保证和当前编译器版本、当前优化等级下的实际约定一致——文档写的是规范，编译器生成的是事实，两者在边界情况下不一定完全一样。

汇编模块加进工程时还有个小细节：汇编文件的扩展名和 C 文件不同，工程里要确认它被识别成汇编源文件而不是被当成别的类型。加错了的表现是链接时提示找不到符号，但源文件明明在工程树里躺着。手册 2.3.2 节专门写了“在工程中添加一个汇编模块”，照它走一遍能避开这类问题。

5. 踩坑记录：手册里没加粗、但能让你卡半天的五处

下面五条都是我在实际工程里撞过的，按“现象→原因→解决”写，每条都能对上手册里的某一段，只是原文没把它标成风险。

第一条：编译全过，链接报一堆重复定义或找不到符号。

现象是所有源文件单独编译都正常，一到链接就报符号重复或未定义，且报的符号看着都眼熟。原因是运行库混用了——工程里一部分模块按 DLIB 编译，另一部分链接时用的是 CLIB，两套库里有同名但实现不同的符号。手册里把两套库的差异写得很清楚：DLIB 兼容标准 C 和 C++、支持 IEEE 754 浮点，CLIB 是轻型库、不完全兼容。解决方法是把工程级和文件级的运行库设置统一，然后 Rebuild All，别指望 Make 能自己发现这个问题。

第二条：断点打上去，程序跑过去不停。

现象是断点图标变灰或者干脆不生效，程序一路跑到底。三个常见原因：一是优化等级高，那行代码被优化掉了或者被合并到别处，映射不到实际指令；二是断点数量超了硬件上限，MKII 只有 4 个硬件断点，超出的静默失效；三是断点打在了没被链接进来的代码里，比如被条件编译排除的分支。排查顺序是先删到只剩一个断点验证机制，再把优化关掉验证代码，最后才怀疑工程配置。

第三条：命令行跑一次链接，编译器的汇编列表被冲掉。

现象是回头对汇编时发现列表文件内容不对，像是整个程序的映像而不是单个文件。原因就是手册提醒过的那条：链接器的映像文件默认扩展名是 lst，和编译器列表文件撞了。解决办法是给映像文件显式命名成 .map，命令行和 IDE 里都要改，改完把旧的 lst 删掉重新生成一次，否则你分不清手里这份是新的还是被覆盖过的。

第四条：工程拷给别人，打开满屏红色路径。

现象是 .ewp 里存的是绝对路径，换台机器或者换个盘符，所有源文件引用全断。原因是添加文件时用了绝对路径引用，而不是相对工程目录的路径。解决办法是把工程文件和源文件放在同一个目录树下，引用时用相对工程目录的路径写法，加文件时从工程目录往里选而不是从资源管理器里拖。这条不是手册的锅，但它决定了工程能不能被别人接手。

第五条：数据断点看着设了，变量被改时却不停。

现象是明明监听了某个变量，程序里它被写了好几次，断点一次没触发。除了前面说的硬件断点数量问题，还有个更隐蔽的原因：变量被优化进了寄存器，根本没有内存地址，数据断点监听的是地址，地址不存在自然不停。解决方法是给该变量加 volatile，或者临时降优化等级重编，确认变量确实落在内存里再下断点。

6. 把手册用成查阅工具：三张速查表和一套验证习惯

这份 PDF 有几百页，通读一遍记不住，正确用法是当字典查。我把自己高频回查的内容整理成三张表，贴在工程目录旁边，比每次翻目录快。

第一张按症状查章节：

第二张按工具查产物：

第三张是每次换芯片必走一遍的检查项：模板是否换成对应芯片的、设备描述是否匹配、运行库是否和代码用的特性对得上、调试驱动是否选了实际连的那台、链接后 map 里的 RAM 和 Flash 是否还在预算内。这五项里任何一项漏掉，症状都不会当场出现，而是在你调了两小时之后突然给你一下。

验证习惯上，我只强调一件事：任何一次“改了配置”之后，第一次编译必须 Rebuild All，然后看一眼 map 文件的总体占用。这两个动作加起来不到一分钟，但能挡掉绝大部分“明明改了却没生效”的玄学问题。手册里没有哪一节教你这个，它是被坑出来的。

从那以后我每次动 .xcl 或者切运行库，都强制走一遍 Rebuild All 加 map 核对，哪怕只是改了一个段名。希望帮到你。

本文还有配套的精品资源，点击获取