AVR开发利器“免费专业编译器GCC” PK “2W准专业编译器IAR”

只看该作者 · 2007-8-23 08:34

前几天想在IAR上编写ATMEGE128的程序，好像找不到相应的头文件嘛，哪位兄弟指点一下

1万 · 2007-8-23 09:46

IAR在WINDOWS下的MCU开发毕竟老牌，ATMEL不想掉失习惯了IAR介面的开发人员，当然要同IAR合作。

GCC是开源社区的产物，而它的维护是由全世界的顶级程序精英维护。大家如果玩过嵌入式编程，相信对GCC一定不会陌生，你肯定会赞叹超大型程序项目用make和Makefile做管理是那么的合理！

在开源项目面前，如果你末能达到一定的水平，不是沉迷于技术的人，是不可能看懂并修改开源项目的程序，例如：GCC编译器，vi编辑器等项目源代码的修改！也就是说，有能力修改这些超大型项目源代码的人肯定是技术上的精英！

GCC延生到现在已经有15年多历史，其中经过全世界无数技术爱好者提出的意见作不断完善修改，发展到现在，整个算法架构已经是相当的稳定和经典！

并且由于开源项目的性质，其中强大灵活的源代码管理方式，注定了GCC以后要增加对另一些新问世的MCU支持是非常之容易的事情！

俺对于选择IAR还是GCC做MCU开发？当然是选GCC了！GCC不但免费，而且最重要的是功能强大灵活专业！

只看该作者 · 2007-8-23 15:08

可能是习惯了Makefile的项目管理和GCC的命令集使用，现在看到IAR的界面反而不太适应，特别是看到很笨的界面对话框时更是有点晕了，真不知如何是好？哪天IAR真流行了，俺等GCC菜鸟岂不是失业，拼死捍护GCC！GCC 万岁，GCC 万岁万岁万岁。。。。。来吧！砖头！

只看该作者 · 2007-8-23 16:34

2万 · 2007-8-23 18:48

哪天GCC真流行了，俺等IAR菜鸟岂不是失业，拼死捍护IAR！IAR 万岁，IAR 万岁万岁万岁。。。。。来吧！砖头！

呵呵，GCC流行了，俺不玩AVR总行了把，估计到那时候，俺也老了……

只看该作者 · 2007-8-23 19:03

一开始用AVR的原因是因为它快，用其他代替不了。
一开用GCC，是因为网上资源多，当时IAR等的D版很难寻。
后来在某公司开发新产品，由于功能的不断增加，使程序也相应加长，到最后只有几十B的Flash。
这时客户要增加功能，或公司自己也要修改，导致程序增加。
这时只有三条路：一是精减程序，二是换IC，三是换编译器。
由于不是新手、要增加的程序量不小，所以第一点放弃。
第二点大概谁也不想做。
所以只能选择第三。
经我的经验，相同功能的程序，原用GCC写，后改用IAR，除对小部分作修改外，几乎不改变。原程序约7.9K，用IAR后约7K，即大约省1K。
比较一下：花钱买IAR与改用更大ROM的芯片，就是SL所说的物超所值。

不同场合使用不同工具，没什么好不好可说的。
锄头好还是拖拉机好？

1万 · 2007-8-24 08:43

GCC竟然跟俺的汇编思维相符！俺不知你们怎么用GCC的，每个项目规划通常都会预留三分之一以上的存空间以备做功能扩展。

对于特定的算法，代码要做最小化，混合编程就是了。对于几K的容量，如果真要最省FLASH，干脆直接用汇编就是了。

事实的数据表明，GCC的控制编译算法比IAR代码还短！

只看该作者 · 2007-8-24 09:57

只看该作者 · 2007-8-24 10:46

搬张板凳

只看该作者 · 2007-8-24 10:48

偶一直用ICCAvr

在超过1kk的芯片上跑着。

只看该作者 · 2007-8-24 12:58

我也用CodeVision,特别是对于eeprom操作方面那真是不错

2万 · 2007-8-24 13:32

那段编译器对比资料在5年前就见过，现在看没有意义。

1万 · 2007-8-24 13:54

CodeVision在Flash， EEprom的使用方法明显比GCC要好。

只看该作者 · 2007-8-24 15:02

2万 · 2007-8-25 00:20

这份资料从双龙流出来的，跟上面的对比一下，可以看出多了条GCC的数据。
我不知道那组GCC的数据是什么时候加上去的，但可以肯定，其他几组数据是2003年初就已经看过了，所以我认为是2002年的事了，这事还是由双龙来证实一下吧。

1万 · 2007-8-25 11:02

如果有熟悉这几种编译器的客户，不妨拿段程序出来，用最新版的各个编译器测试下，看看这几年来，编译器有什么进步。

2万 · 2007-8-26 21:44

只看该作者 · 2007-8-27 09:47

1、免费：这个地球人都知道了吧？

2、标准化程度高，移植性好：gcc 写的程序，可以非常方便的移植到不同cpu上，这一点在ARM<->PC之间表现得尤为明显，基本上一个项目除了底层驱动外，其它程序都可以先用PC验证算法，然后直接把编译脚本中的"gcc"改成"arm-linux-gcc"就一切OK了——当然要是有人说他一辈子就只打算用8-bit mcu，那就当我没说好了……不过话说回来了，即使是avr<->PC，仍然可以用后者验证算法，只要注意整数长度和代码容量就好了……

3、未来发展好：就算不提ARM，可ATMEL的AVR32就是明确优先支持linux-gcc环境的，我不知道有什么人有胆量用除微软产品以外的任何商业编译器编译需要MMU的操作系统，反正我是不敢的，怕死得很……

另外，就我个人的经验看，当一个项目同时需要用到

PC(上位机)
ARM(远程终端)
AVR(传感器和模拟电路控制)

的时候，GCC就是最好的选择，至少，在我的知识中，没有其它的编译器方案能够做到对整个工程只需一个项目文件并统编统调的，而做不到这一点的话，实际上就会增加很多额外的维护工作量（想象一下，当你上下位机以及传感器需要进行数据传输——这几乎是肯定的——但定义数据结构的头文件版本却各自不同时会发生什么情况吧，尤其一般来说，数据结构定义中往往最后修改的部分是最少用到的，也就意味着更加难以在初期测试中查出错误）

只看该作者 · 2007-8-27 16:59

只看该作者 · 2007-8-28 10:45

习惯了。

AVR开发利器“免费专业编译器GCC” PK “2W准专业编译器IAR”

正在入门IAR for avr

ATMEL官方一直支持GCC并同IAR合作，这对于ATMEL来说是很重要，

俺选GCC是因为GCC容易使用，IAR太难用,

自已习惯了使用GCC！

呵呵，热闹热闹……

我有亲身经历，不说不快

GCC所做的跟俺用汇编的写的长度差不多，俺用汇编想到的，

性能不是吹出来的，说好就是好，当俺等老鸟们是吃干饭的

用适合自己的编译器

不怕人笑

支持

上面

试过一次，CodeVision产生的代码效率要高于GCC

56楼说的是2002年前的事？可有证据？快快呈上来！

好不容易找到的

双龙很早之前是做过一个比较，过了那么久，编译器都升级

没事俺来比一下

个人说说 gcc 的优点

看来同道中人还真不少！

还是GCC吧

涓涓之细流

常驻人口

技术高手奖章

核心会员奖章

七世轮回

技术导师奖章

沉静之湖泊

技术新星奖章

终身成就奖章

坚毅之洋流

十世金身

技术领袖奖章