做嵌入式项目时，很多人会碰到“IAR编译选项怎么配置，IAR编译选项导致代码体积变大怎么排查”这类问题。IAR里一个选项看起来只是勾选或切换级别，实际可能影响优化策略、调试信息、库函数选择、浮点处理、链接结果和最终烧录文件大小。排查时不要只盯着某一行代码，先把编译、链接、库文件和输出文件类型分开看，问题会清楚很多。

　　一、IAR编译选项怎么配置

　　在进行嵌入式项目开发的时候，很多技术人员都会遇到关于IAR编译选项如何去设置，以及因为选项问题让代码占用的空间变大该怎么去查找原因的问题。在IAR软件里面，虽然表面上看起来只是用鼠标去勾选一个地方或者切换一下里面的级别，但是在实际运行的时候，这可能会对优化的策略产生影响，调试的信息、库函数怎么选、浮点数怎么算、链接出来的结果还有最后要烧录的文件大小也都会被它影响。

　　1、确认目标芯片和工程模式

　　技术人员在电脑上点击进入【Project】→【Options】这个界面以后，需要先去对【General Options】里面的东西进行检查，这里面包括了目标芯片、CPU内核、FPU还有运行库的配置。

如果在这些地方把选项给选错了，那么在后面不管怎么去调整优化，系统都是不稳定的。在项目处于调试的那个阶段里，Debug配置通常是被拿来使用的，等到要发布或者量产版本的时候，再把配置切换到Release上面去，在一个配置里面来回反复地修改是不被建议的，因为到了后面，这样操作会很难做出对比。

　　2、设置优化等级

　　当进入到【C/C++Compiler】→【Optimizations】的页面之后，开发者可以根据当前项目进行到了哪一步，来选择合适的优化级别。

在刚把代码移植过去的时候，较低的优化是可以先被采用的，因为这样在单步调试还有找变量位置的时候比较省事；等到功能基本上稳定了，再把它换成高一点的优化，而且像Size或者Balanced这些选项是可以优先去试一试的。那些对运行速度要求很高的任务，比如进行快速采样、算一些算法、处理通信的实时性，局部的一些Speed优化是可以考虑的，但是全工程都瞎用这个是不行的。

　　3、区分调试信息和烧录体积

　　很多开发者一看到诸如.out、.elf或者调试文件这些东西的个头变大了，就会产生一种误会，以为Flash的占用空间也跟着变大了。但其实调试符号只是会让工程输出的文件体积在表面上变大很多，最终的烧录镜像里面不一定会包含它们。如果想要知道代码是不是真的变大了很多，应该去优先查看.map文件、.hex文件、.bin文件，还有被链接之后的ROM占用情况，而不是只盯着工程目录下面的某个输出文件的大小去瞅。

　　4、合理配置预处理宏和库函数

　　在进到【C/C++Compiler】→【Preprocessor】里面之后，大家要检查一下宏定义，看看是不是把一些用不到的功能模块给打开了。比如像日志、断言、测试用的代码、全套的驱动、兼容层、协议栈的调试开关这些，它们都可能会让代码的体积变多。

　　二、IAR编译选项导致代码体积变大怎么排查

　　代码的体积要是突然变大，大家不要一着急就去改动业务代码。比较稳妥的做法是，先去把到底是ROM变大了、RAM变大了，还是调试输出的文件变大了这几个事情给弄明确。这三个概念代表的意思是不一样的，所以它们后面对应的排查方向也是有区别的。

　　1、先看.map文件定位增量

　　开发人员先去打开【Project】→【Options】→【Linker】→【List】，把里面的链接列表输出给开启掉，然后再重新把代码编译一遍。

在这之后，就可以在生成的.map文件里面去瞧一瞧各个模块、函数还有库文件到底占了多少地方。必须要先把哪个.c文件、哪个库或者哪一个段突然之间变大了给找出来。

　　2、对比Debug和Release配置

　　同一份代码可以用Debug和Release这两个配置分别去编译一下，把产生的ROM、RAM、.hex、.bin的大小给记录下来。要是Debug编译出来的明显很大，但是Release编译出来的却挺正常的，这通常就是因为优化级别、断言、日志还有调试宏这些东西引起的，它并不一定就是代码出问题了。

　　3、检查优化目标是否选错

　　如果原本在工程里使用的是Size，但是在后面把它改成了Speed，那么代码的体积变大其实是比较平常的一个现象。因为速度优化为了换取执行的效率，它可能会去展开循环、增加内联、把调用的结构进行调整，但是这对于Flash空间本来就很挤的MCU来说，不一定是很合适的。

　　三、怎样把IAR代码体积压回合理范围

　　体积的优化并不是说简单地把优化等级给调到最高就能解决的。在做嵌入式项目的时候，大家更在乎的是稳定、能不能调、好不好维护，特别是在面对安全相关的、通信相关的、还有Bootloader相关的代码时，绝对不能为了省下那么几个KB就把风险给搞大了。

　　1、优先关闭无用功能开关

　　开发者要先把预处理宏给清理一遍，把调试日志、测试用的命令、没有用到的外设、示例代码、多余的协议还有临时的诊断功能都给关掉。很多项目的体积之所以超标，并不是说算法本身写得太大了，而是因为工程里面塞了太多“暂时还没有去删掉”的模块。把这些东西给清理干净了之后，再去跟编译器谈优化的问题，这样产生出来的效果通常会更加直接。

　　2、控制内联和速度优化范围

　　要是有些函数因为内联的关系导致体积变得很大，那就可以去减少头文件里面大函数的实现，尽量别把复杂的逻辑给写成大量的static inline。对于那些对性能非常敏感的函数，是可以把它们单独拿出来做优化的，而普通的业务逻辑则完全没有必要全都按照Speed去处理。采用这种办法，既能把关键路径的性能给保住，工程总的体积也不会变得无法控制。

　　3、精简标准库使用

　　printf这种东西要尽量把它改成轻量级的日志接口，格式化输出里面也要少用浮点数。还有字符串的处理、格式的转换、动态内存以及复杂的数学函数，在引入的时候全都要小心谨慎。在一些小容量的MCU项目里面，标准库函数自己占掉的体积，比业务代码占得还要明显，这个在map文件里面一般都能直接看清。

　　总结

　　在对IAR编译选项进行设置的时候，重点需要去看的地方有【General Options】里面的目标环境、【C/C++Compiler】里面的优化等级还有预处理宏、【Linker】里面的链接输出以及map文件。在碰到因为IAR编译选项导致代码个头变大的时候，要先把调试文件变大和实际ROM占用变大这两件事给区分开，然后再靠着.map文件去找到具体是哪个模块增大了。只要把这些地方挨个地去对齐核对一下，代码的体积基本上都是能够被压回到比较能接受的范围之内的。