KEIL RVMDK VS IAR EWARM

KEIL RVMDK VS IAR EWARM

项目实战比较（谁更有效率？）！！

http://bbs.ednchina.com/BLOG_ARTICLE_1741482.HTM

    KEIL 和 IAR Systems都是嵌入式领域系统开发工具和服务商（IDE）的供应商，前者成立于-1986年，总部在德国（如今已被大名鼎鼎的美国ARM公司收购)；后者于成立1983年,公司总部位于北欧的瑞典。

二者的最著名的产品分别是 KEIL uVision IDE 和 IAR Embeded Workbench。目前他们最新的产品（用于ARM的开发工具，当然也可以用于开发51单片机）的IDE分别是RealView MDK -ARM（4.10）和IAR EWARM 5.40。

    对于二者，嘿嘿，各位具有丰富设计经验的GGMM恐怕都不陌生吧，估计大部分的开发人员都用过。因为他们都可以很好的支持各种不同版本的MCU。对于不同的开发环境，用久了，便会日久生情。用得顺不顺手，快不快乐，或喜欢，或讨厌等等，都因人而异的。然而我们不能不考虑这个问题：能选择到最适合自己，更有效率的工具，才是最好的。

先说说本人的个人经历吧。 先说KEIL，个人感觉KEIL的IDE界面比较通俗易懂，属于平易近人的那种，尤其软件仿真功能做得很不错，各种外设的仿真都很好，软件仿真，没得说，就是栩栩如生，不好一点呢，印象中总是那个大名鼎鼎的文字编辑的BUG了，KEIL的有些版本对于EDIT编辑对于汉字支持，怎一个烂字了得! 而IAR呢，界面简洁明了，软件仿真虽然没那么强悍，但仿真起来也没什么问题，该咋地就咋地，整体感觉——专业。不好一点呢，就是对初学者来说入来说不太容易掌握。但用上手了，你就会感到有安全感。

    曾几何时，在用51单片机的时候一直用KEIL C51 这个工具，刚刚用的时候从不考虑各种效率和技巧的问题，毕竟当时经验也不是很多，追求的是会用。用久了，对其的各种操作久了，对其风格也渐轻车熟驾，版本前变万变也就那样，操作仍如往常。渐渐的便觉得KEIL还不赖，因此再用其他工具变很容易产生一种排斥之感（地方保护主义，嘿嘿）。

    然而现实总是有压力的，对于学习，也是这样。很多情况下还不得不‘被’接触其他工具。终于有一次项目开发，用到IAR，开发IC也是基于51内核的IC，是TI公司的一片RF IC CC1110。刚开始确实对IAR不感冒，总喜欢拿KEIL来做比较，有一种本能的排斥。总感觉IAR，很小儿科，不专业，比起KEIL来根本不是一个档次。当项目开发完的时候，又用回了KEIL C51。但是，后来发现错了，真的错了。就是我们常说的，当你失去一件宝贵的东西的时候，你才发现，原来学会珍惜，是多么的重要。这次用了KEIL C51，竟然让我时常的怀念起了IAR。。。

    这是为什么呢， 回想当时在用IAR，自己用得很顺手，那感觉就是像座上宝马做开发一样，而现在用KEIL，有时你真的不得不鸟它几句，像驴一样的东西。怀念IAR它简洁明了的界面，高效编译的速度，甚至有时让你感到它的就是对的，错的就是你。想想这次用的KEIL 怎么没有像IAR的那种感觉呢。我想这一切总会是有原因的。

    而现在用上ARM了，开发IC为STM32F系列，基于ARM公司的最新内核CORTEX-M3。目前有个项目既可用KEIL RVMDK平台也可用IAR EWARM平台。但一直想弄个明白，RVMDK VS IAR 到底谁效率更高，下面我用同一个项目做测试比较。希望能解开心中纠结。

测试版本：

Keil uVision V4.00,RVMDK 3.5(1999-20009) + IAR EWARM 5.40(2002-2009)

测试项目： 

pwhid

测试性能主要从以下两个方面来测试：

A. 项目整体编译速度   B. 代码产生效率（即最终代码大小,为HEX文件）

测试日期：2010年05月23日

 

测试结果及过程：

A.整体编译速度（Built ALL)

在等同配置，即KEIL的时候要求Target 设置的Ouput项：

选上：Debug Information + Create HEX File + Browse Information

其他保持默认（要选中C的LIST项）。

同样在IAR环境下，需要尽量配置成等同的配置，其他需要全部选中LIST项。

二者，在Rebuilt All 的时候：

KEIL RVMDK的表现：

编译的完成的速度约为17s（目测速度）

IAR EWARM的变现：

编译完成的速度约为12s（目测速度）

结论：

IAR EWARM的编译速度要比KEIL RVMDK快！

 

也就是说，在你使用KEIL RVMDK编译同一个项目的时候你每一次，都需要多等5秒钟。

这一小5秒，积累起来就成了很大的5秒了，无形中为自己的开发节省了多少时间。

为什么KEIL需要那么长时间呢，主要因为在编译产生 Browse Information的时间太多。

如果把这个取消掉就会快了很多了。

这里有一个使用小诀窍，每一次都Rebuilt ALL，是不明智的，当第一次Rebuilt All的时候

如果其他文件并无改变的话，直接用Built 就行了，这样编译速度就很快了。

B.代码产生效率。

不同的编译器都有自己的不同之点。然而，编译的结果终究是要产生可执行的文件。

这次以HEX文件为例，分别在编译器不优化和最佳优化这两种情况

下作比较。

在IDE都不进行优化的时候：

KEIL的优化配置选LEVEL 00，IAR的优化配置选NONE，其他默认。

KEIL RVMDK的表现：

HEX文件大小为：68.5KB

IAR EWARM的表现：

HEX文件大小为：48.0KB

结论：

真是不比不知道，一比吓一跳。没想到同一个项目，RVMDK产生的垃圾代码真不少。

在IDE都进行最佳优化的时候：

KEIL的优化配置选为LEVEL 03，IAR的优化配置选HIGH（BALANCE），其他默认。

KEIL RVMDK的表现：

HEX文件大小为：53.6KB

IAR EWARM的表现：

HEX文件大小为：35.7KB

在二者编译器默认的优化配置时

KEIL MVDK是defualt（即LEVEL02），IAR EWARM是LOW。

二者表现分别是：

53.5KB 和 45.6KB

结论：

相差8~18KB，还是人比人吓死人，鸡比鸡吓死鸡。

想想，为什么KEIL MVDK的编译效率那么低呢，如果在KEIL未被ARM公司收购之前，KEIL的这般效率，也不足奇怪。究其原因，那是因为KEIL MVDK在编译的时候都统统把文件中所有的函数编译成目标文件了。但是有一些永远都不会用到的（即未调用的函数）。那么如何去掉这个不负责任的编译呢。 有办法，那就是在KEIL的TARGET 选项上，要选上Use Cross-Module 和 Use MricoLib。 这样KEIL的优化效率就飞速提升了，甚至超过了IAR的编译效率（IAR配置为HIGH，size）。 分别如下：

KEIL RVMDK的表现：

HEX文件大小为：33KB

IAR EWARM的表现：

HEX文件大小为：34KB

结论：

得益于ARM的鼎力支持(其实KEIL已属于ARM的一个部门了)，KEIL的编译优化方面已有一定的提升。不过IAR也不赖，编译速度一直很稳定。

最后总结：

在这次实测中，发现KEIL 在编译速度方面确实比IAR慢一些，而且奇怪的发现了KEIL每次的编译结果有可能都不一样，要想得到最终结果，你可能需要多编译几次才行，这一点真让人恐怖！

对于IAR，用得多了，偶尔也会发现一些令人不满意的地方，就是，IAR，有时会‘休克’，装死，当然KEIL也多多少少存在一点。 至于是不是IAR本身的问题，这个就不得而知了。 因为XP系统也不是很可靠的东西。另外这次只是中等项目编译的比较。

以上是这侧项目的实测结果，但是还不知道程序能不能跑，稳定性能如何。但是无论怎样，是驴是马，跑出来溜溜就知道了。经程序下载检验，一切正常。至于稳定性能如何还有待测试。

如果那个网友感兴趣可以下载到自己的硬件板上做测试。发现什么问题别忘了提出来（硬件平台为STM32F103C8或RB，最小系统即可，有USB功能），下面是我测试的程序运行结果和测试文件：

令温馨提示一下：

这里应该算是MDK的一个BUG，

在KEIL MDK中，硬件仿真时，对于数组变量的擦看，如果数组量很多时候，你所看到的数据有可能不对，而IAR EWARM则没有发现这个问题，我曾在21IC上发过贴（有兴趣，可以去搜搜看）

另外，编译器的优化，要慎用。

毕竟这是机器优化，有时会出现一些令人惊奇的，莫名奇妙的错误。

比如说，你在函数内部要使用一个变量的时候，它就无缘无故的把你要想用的变量优化掉了，变成了永远的 unavailable !

最好的办法，是要对自己要写的代码有信心。

 

呀呀USB_hid上位机及程序文件请到dz561的个人博客上下载：

http://www.ednchina.com/blog/itspy

终上PK 结果，心底终于有点数了。整体上，感觉还是IAR略胜一筹。不过话又说回来，事物总会在变的，这些只是工具而已，罗布青菜各有所爱吧。