首先，它的優(yōu)點是有目共睹的，我想選擇它的哥們也一定是看上了它的這個優(yōu)點：易用上手快，容易出成果！BASCOM確實很容易上手，2002年初我剛開始接觸AVR的時候，就是完全靠它的HELP系統加老龍的SL系列實驗開發(fā)器自己摸索的，就是現在，我也還經常在HELP系統中CTRL+C和CTRL+V例子代碼，代碼很簡單易懂，對格式要求也不很嚴格，不用做芯片的初始化工作，有時就是連簡單的CONFIG語句都省了，編譯一樣成功，但是C語言就要在寫程序之前先寫大量初始化芯片的語句，比較煩人。同時，它支持部分匯編語句也是值得高級用戶稱道的，如DDR=XXX語句就可以配置IO口的寄存器等，比CONFIG語句更靈活更好用，結合使用更是能隨心所欲，方便極了。對于部分比較常用的模塊化功能如讀取RC5遙控編碼，讀寫LCD等都簡單到了一句搞定的地步，很適合業(yè)余開發(fā)者和學生興趣班使用。
但是它的某些方面確實有些問題！比較嚴重的是:
1、程序結構化能力差。常用的功能想做成函數或模塊調用以節(jié)省空間，但是最終往往達不到效果，而編譯器卻沒有提示出錯，給人摸不著頭腦的感覺。例如，想把AD轉換作為一個自定義函數，供主程序反復調用，但是最終轉換結果卻出現很多嚴重的錯誤，遠遠偏離正確值，如果直接把該段代碼寫在主程序模塊中就一切OK，很是傷腦筋，這點對于程序規(guī)模比較大的，或是初學者是很不利的，解決辦法只有將公用代碼放在某個程序段中不斷的GOSUB和RETURN，要想跟C語言的優(yōu)秀的結構化風格比是不可能的。
2、部分語句有兼容性問題。如RC5SEND語句，在90S系列芯片中完全通過，而在MEGA系列芯片中完全失效，沒有任何動靜，編譯過程中又沒有任何提示，這意味著MEGA系列無法使用這種簡單的辦法來擴展鍵盤了。
3、用戶很少，網上例子代碼貧乏，無法跟其他用戶交流，這點對于初學者比較慘。
4、現成的算法少，很多需要自己重頭研究編寫，比較辛苦。
5、程序代碼空間的利用率低，完成同樣功能的程序，編譯的結果往往比C編譯器的大的多，比如一個寫LCD語句就會編譯出幾百的字節(jié)來，無法根據源程序大小來估計最終FLASH的使用率，而且一旦超出FLASH大小范圍只有干瞪眼的份，無法根據自己程序的實際情況來優(yōu)化空間，畢竟是調用現成的模塊嘛。
6、對硬件的操作很模糊，似乎隔離了用戶跟硬件打交道的權利，這當然是為了給用戶簡單易用著想的，但當用戶用了很多年BASCOM以后再想換換其他的編譯器，卻發(fā)現自己天天在用的芯片自己卻一點也不知道它的硬件結構和使用方法，沒法放棄BASCOM了，貪圖方便的結果，慘啊！
以上是我這些年研究BASCOM的“成果”，供大家參考?？傮w上來說，這款軟件是可以給80分的，還算是不錯的編譯器，適合簡單的作些端口控制的小程序，不適合包含大量算法和運算量比較密集的項目；適合像我這樣的業(yè)余玩家（不過今年我已經逐步放棄BASCOM而轉向ICC了）和作為非該專業(yè)學校的學生使用，不適合靠單片機混飯吃和將來打算深入研究的用戶。
另外，還想對壇子里某些哥們的一些觀點提出異議：
1、BASCOM語言的AVR開發(fā)工具編譯出來的程序執(zhí)行效率低。我認為，這恐怕是受了計算機GW-BASIC或是TURBO-BASIC時代的影像，想當然的把這頂帽子扣在BASCOM-AVR身上了，以前計算機的BASIC語言包括VB確實效率低，原因是他們生成的代碼不是最終目標機器的代碼，而是經過一個RUNTIME的程序在內存解釋后運行的。而單片機的BASIC編譯器是直接將代碼編譯成AVR相應芯片的機器碼的，不需要在單片機的內存駐留RUNTIME程序，執(zhí)行效率不會很低（垃圾代碼多則另當別論），排除垃圾代碼的影像，執(zhí)行效率是跟其他編譯器編譯出來的一樣的。
2、BASIC語言結構化能力差。我認為這也是受了早期計算機教科書的誤導而以訛傳訛，BASIC發(fā)展到了QuickBASIC以后，結構化能力已經很強，具備很多結構化的思想和編程方式，已經具有函數、模塊、局部變量、全局變量、數據傳遞等，已經擺脫了早期BASIC語言GOTO和程序行號的陰影，而上面我提到的BASIC-AVR結構化差的問題則是這個軟件開發(fā)的個別問題了，畢竟它只能盡量兼容QUICKBASIC，這點在HELP里也說得很清楚了。
亂七八糟談了一大堆，有什么不對的還請各位大俠不吝賜教，謝謝！
下載文檔
