EEPW论坛

问 我是刚准备学AVR单片机的学生，我在网上找了一些资料。但是有些问题不甚明了，希望有各位有经验的前辈多多指教。不胜感激。

问题一：ICC好还是GCC好。。ICC一套要一千多，而GCC是免费的。但网上有些帖子说GCC比ICC要好，不知道是不是真的。希望有用过两种编译器的高手说说体会。
问题二：据说GCC支持C++，那到底是用C++来控制AVR好还是C好？哪个代码效率高一点？
问题三：初学者有必要准备一台仿真器吗？

希望各位高手不吝赐教。谢谢。 答 1: 首先声明我不是高手，只是抛砖引玉。1、ICC、GCC罗卜青菜各有所爱。GCC只能在网上寻求支持，没有厂商的支持；另外需要另外安装一个外壳程序，否则只能在DOS下使用。
2、IAR也支持C++，但用C++生成的代码相对要大一些。
3、不一定，借助于AVR的ISP和FLASH特点，自己多动脑的话，完全没有必要使用仿真机。 答 2: 我也抛块砖头，入了门，哪种都差不多。青菜罗卜。在http://www.AVRfreaks.net/Tools/jindex.php?preopen=Compiler上的投票中：
编译器　　　　　　　　　　等级
CodeVisionAVR-Light    *****
CodeVisionAVR-Standard *****
ImageCraft ICCAVR V6   ****
ImageCraft ICCtiny V6  ****
GNU AVR-gcc            ****(Version: 3.2 20020612)
WinAVR (GNU GCC)       *****(Ver 20030115 gcc3.3 )
IAR Embedded Workbench  ***
IAR C-SPY Debugger     ***

支持C++的就有WinAVR和IAR，gcc默认支持C＋＋，如果文件名是cpp,就使用AVR-c++编译，如果是C，就使用AVR-gcc编绎,大概是这样子吧。我也不是很清楚。不过C＋＋的代码率和C是有些差距，当然是C的要高些了。
我觉着初学用一个自己作一条并口下载线就可以了，如果要正式干活，建议还是弄台仿真吧，效率要高许多，切肤之痛啊。
答 3: icc有没有专门的书啊？？ 答 4: GCC 不支持C++ 答 5: 凑凑热闹    如果从来没真正的作过MCU的课题/项目且有zlei这位学生大侠那样用几千大元来学AVR的魄力和财力，就考虑一款仿真器。以起事半功倍之效。条件不允许的话，用并口下载线吧。AVR比较容易上手，只要你有信心！
    祝早日成为AVR侠侠：） 答 6: 补充CodeVisionAVR-Professional    ****** 答 7: ICC AVR三四月份将由清华出版! 答 8: To: zleiAVR-GCC部分支持C++。一些在嵌入式系统有限资源下难以实现的功能它不支持。

下面是AVR-libc文档中的描述。

CAN I use C++ on the AVR?
Basically yes, C++ is supported (assuming your compiler has been configured and compiled to support it, of course). Source files ending in .cc, .cpp or .C will automatically cause the compiler frontend to invoke the C++ compiler. Alternatively, the C++ compiler could be explicitly called by the name AVR-c++.

However, there's currently no support for libstdc++, the standard support library needed for a complete C++ implementation. This imposes a number of restrictions on the C++ programs that CAN be compiled. Among them are:


Obviously, none of the C++ related standard functions, classes, and template classes are available.
The operators new and delete are not implemented, attempting to use them will cause the linker to complain about undefined external references. (This could perhaps be fixed.)
Some of the supplied include files are not C++ safe, i. e. they need to be wrapped into
extern "C" { . . . }

(This could certainly be fixed, too.)
Exceptions are not supported. Since exceptions are enabled by default in the C++ frontend, they explicitly need to be turned off using -fno-exceptions in the compiler options. Failing this, the linker will complain about an undefined external reference to __gxx_personality_sj0.
Constructors and destructors are supported though, including global ones.
When programming C++ in space- and runtime-sensitive environments like microcontrollers, extra care should be taken to avoid unwanted side effects of the C++ calling conventions like implied copy constructors that could be called upon function invocation etc. These things could easily add up into a considerable amount of time and program memory wasted. Thus, casual inspection of the generated assembler code (using the -S compiler option) seems to be warranted.