原创：给大家一点关于BASCOM编译器的参考
扫描二维码
随时随地手机看文章
首先，它的优点是有目共睹的，我想选择它的哥们也一定是看上了它的这个优点：易用上手快，容易出成果！BASCOM确实很容易上手，2002年初我刚开始接触AVR的时候，就是完全靠它的HELP系统加老龙的SL系列实验开发器自己摸索的，就是现在，我也还经常在HELP系统中CTRL+C和CTRL+V例子代码，代码很简单易懂，对格式要求也不很严格，不用做芯片的初始化工作，有时就是连简单的CONFIG语句都省了，编译一样成功，但是C语言就要在写程序之前先写大量初始化芯片的语句，比较烦人。同时，它支持部分汇编语句也是值得高级用户称道的，如DDR=XXX语句就可以配置IO口的寄存器等，比CONFIG语句更灵活更好用，结合使用更是能随心所欲，方便极了。对于部分比较常用的模块化功能如读取RC5遥控编码，读写LCD等都简单到了一句搞定的地步，很适合业余开发者和学生兴趣班使用。
但是它的某些方面确实有些问题！比较严重的是:
1、程序结构化能力差。常用的功能想做成函数或模块调用以节省空间，但是最终往往达不到效果，而编译器却没有提示出错，给人摸不着头脑的感觉。例如，想把AD转换作为一个自定义函数，供主程序反复调用，但是最终转换结果却出现很多严重的错误，远远偏离正确值，如果直接把该段代码写在主程序模块中就一切OK，很是伤脑筋，这点对于程序规模比较大的，或是初学者是很不利的，解决办法只有将公用代码放在某个程序段中不断的GOSUB和RETURN，要想跟C语言的优秀的结构化风格比是不可能的。
2、部分语句有兼容性问题。如RC5SEND语句，在90S系列芯片中完全通过，而在MEGA系列芯片中完全失效，没有任何动静，编译过程中又没有任何提示，这意味着MEGA系列无法使用这种简单的办法来扩展键盘了。
3、用户很少，网上例子代码贫乏，无法跟其他用户交流，这点对于初学者比较惨。
4、现成的算法少，很多需要自己重头研究编写，比较辛苦。
5、程序代码空间的利用率低，完成同样功能的程序，编译的结果往往比C编译器的大的多，比如一个写LCD语句就会编译出几百的字节来，无法根据源程序大小来估计最终FLASH的使用率，而且一旦超出FLASH大小范围只有干瞪眼的份，无法根据自己程序的实际情况来优化空间，毕竟是调用现成的模块嘛。
6、对硬件的操作很模糊，似乎隔离了用户跟硬件打交道的权利，这当然是为了给用户简单易用着想的，但当用户用了很多年BASCOM以后再想换换其他的编译器，却发现自己天天在用的芯片自己却一点也不知道它的硬件结构和使用方法，没法放弃BASCOM了，贪图方便的结果，惨啊！
以上是我这些年研究BASCOM的“成果”，供大家参考。总体上来说，这款软件是可以给80分的，还算是不错的编译器，适合简单的作些端口控制的小程序，不适合包含大量算法和运算量比较密集的项目；适合像我这样的业余玩家（不过今年我已经逐步放弃BASCOM而转向ICC了）和作为非该专业学校的学生使用，不适合靠单片机混饭吃和将来打算深入研究的用户。
另外，还想对坛子里某些哥们的一些观点提出异议：
1、BASCOM语言的AVR开发工具编译出来的程序执行效率低。我认为，这恐怕是受了计算机GW-BASIC或是TURBO-BASIC时代的影像，想当然的把这顶帽子扣在BASCOM-AVR身上了，以前计算机的BASIC语言包括VB确实效率低，原因是他们生成的代码不是最终目标机器的代码，而是经过一个RUNTIME的程序在内存解释后运行的。而单片机的BASIC编译器是直接将代码编译成AVR相应芯片的机器码的，不需要在单片机的内存驻留RUNTIME程序，执行效率不会很低（垃圾代码多则另当别论），排除垃圾代码的影像，执行效率是跟其他编译器编译出来的一样的。
2、BASIC语言结构化能力差。我认为这也是受了早期计算机教科书的误导而以讹传讹，BASIC发展到了QuickBASIC以后，结构化能力已经很强，具备很多结构化的思想和编程方式，已经具有函数、模块、局部变量、全局变量、数据传递等，已经摆脱了早期BASIC语言GOTO和程序行号的阴影，而上面我提到的BASIC-AVR结构化差的问题则是这个软件开发的个别问题了，毕竟它只能尽量兼容QUICKBASIC，这点在HELP里也说得很清楚了。
乱七八糟谈了一大堆，有什么不对的还请各位大侠不吝赐教，谢谢！
下载文档
