短小、高效是兩個很好理解的詞語，對于寫程序來說，就是要求代碼短，體積小，程序功能正確，沒有或者很少BUG（缺點或者漏動），執行時間短，占用內存少。

五一電子網站的全站ASP動態網頁代碼都是我一人用記事本寫的，僅管在美工方面的確是不堪入目，但是，在“短小、高效”方面，我自己還是很滿意的。

我沒有上過大學，為什么我自學單片機匯編語言的進度還有這么快的速度？說我聰明，那只是我在自以為聰明，事實上，我估計，我最多也只不過能算得上中等偏下的智商。我要告訴大家的是，大家的智慧都差不多，只不過環境對人的影響不同罷了。

我擁有電子基礎、有應用經驗、有電腦基礎的環境決定了我自學單片機最終能夠獲得成功，特別是在最后有了非常高速的進步，并且提出了《三十分鐘學會單片機》這一超前的觀念，當然，30分鐘學會是有前提的，這只適合剛剛好在這個“會與不會”的十字路口徘徊的學員。

我現在將我寫程序的一點方法或者想法寫出來，希望對正在程序入門的朋友有點幫助。

我認為，寫程序，首先要確定功能，再圍繞功能去編寫代碼，因此，功能是第一重要的，如果程序寫出來的主要功能達不到要求，這個程序就是賣不出去的廢品；如果主要功能正常，但有一些嚴重的缺點，這就是不值錢的次品；如果主要功能正常，沒有嚴重缺點，這只能是合格品，賣不出高價錢；如果全部功能正確，沒有任何缺點，這就是優等品，可以賣高價錢。

第一步：確定功能。在這一步上，大家一定要符合實際情況，將全部的功能列出來，主要的功能，次要的功能，可有可無的功能都根據實際情況寫下來。要想程序寫得短小高效，這就很重要，對于單片機程序來說，這更重要，因單片機程序還受到有限的硬件資源限制。

第二步：功能理論驗證。人心比天高，確定功能時總是會想得很好很好，有時可能會制定出不合實際的功能，或者功能最終能否實現，還需要驗證。這是因為單片機的資源是限制，速度也是有限的。常見的情況是硬件資源不夠用，再就是速度不夠快，或者精度不夠高。例如，如果硬要用89C51的芯片做LED點陣顯示板，那么能存儲的字符圖形就非常少（這里不討論外接存儲器），如果硬要用89C51做點陣驅動還要做實時接收數據并計算，這樣肯定也是做不來的。這時，我們就只好更換其它的單片機，例如89C52 ，89C58等等，必要時甚至可以更換16位、32位的單片機。
對于功能理論驗證，這其實也就是在做一個大個框架。當然，一般的產品開發，如果不涉及到多媒體的圖象、聲音內容，用8位的51單片機基本上都是夠用的，這也就是為什么計算機已經發展到64位了，而8位的單片機仍然占據市場主導，我們完全有理由相信，不論技術如何發展，8位單片機會永遠存在，這就好象上世紀70年代，商場里沒有今天這么豐富的千百種含高科技的食物，但是，現在人們依然在買賣著最常用的大米白菜，如果說大米白菜是基本食物，那么8位單片機就是基本單片機，會永遠存在并實用。

第三步：做好原理方框圖。這實際上是第二步的延伸，在第一步中，功能往往是客戶的要求，或者自己的制作目的，但是，現在就是要把這種要求和目的讓單片機實現�？瞻椎膯纹瑱C是什么都不會的，跟嬰兒一樣，會的只是本能的哭和吃，而這些本能就相當于單片機的指令，你輸入任何一條指令，它都會執行，但這沒有用，這不能幫你做任何事，離你的結果有10萬8千里遠。

這時，我們就必須分解我們的功能，分解成一個一個的小框框，一個小框框完成一個基本的功能。這些小框框對于最終的功能來說，可能是風牛馬不相及的，但這是必須的。并且特別要注意的是，你現在還要為每個小框框分配物品和權利，讓這些小框框最終能為需要的功能努力服務。第三步中，相當于畫好了的工作原理以及方框圖，并明確了各部分的功能和責任。

第四步：將小框框的功能用代碼來實現。每個小框框的功能，都已經是很簡單的了，所以是完全可以用代碼來快速實現的。這里要說明的，小框框，相當于小小的子程序，我們不能將小框框分得太多太多，太多了會難以管理，所以，我們要盡量分成少少的框框，但又要求每個子程序的復雜程序我們能用代碼方便的實現。到了現在這個時候，就相當于嬰兒已經長大，已經會走跑了，會說笑了，但是，現在能幫你做出事嗎？還不行，還需要組織協調各種動作，還需要一些技能培訓練習。

第五步：調試驗證修改程序。先要保證每個子程序的功能是能夠實現的，再才能進行協調工作。這時，需要編程者全心全意專心致致的用嚴謹的發展的正確思維來調試程序。這里你相當于是在跟程序同步運行，程序運行到哪里了，哪些功能實現了，哪些功能不行了。實際上情況是，有時這里好了，那里又不行了，那里好，這里又不行了，有時甚至好象全部都好了，但有時又好象全部都不行了，完全不知道錯在哪里。

第五步是最花時間最花精力的一步，能做到這一步的人，一定是會單片機的，僅管，到最后，他可能仍做出不來，最后也無法將程序調通，但是大家是會單片機了，剩下的差別就是經驗的積累和靈感的發揮了。

第六步自然就是成功了。不過會有很多人卡在第五步，仍然到不了第六步。這里，我沒有什么話好說，僅管，我自己認為，沒有什么功能是用匯編語言寫不出來的，我覺得我的51單片機匯編語言已經很好了，但我要告訴大家的事，吃虧時往往是在很簡單的事上吃的。這里我只能講講第五步會用到的一些經驗了。（也不用硬件仿真器解決問題的方法）

a、用軟件仿真找死循環。
只要是程序死機那就是一定是進入了死循環，我們可以按全速，然后再按停止，這時光標所在的行或者子程序就是故障相關的地方。最多，我們可以多按幾下，程序一定會停在有故障相關的代碼部分，仔細檢查分折這幾句。

b、但是，上步有不靈的時候，因為程序運行正確與否還跟相關的數據有關系，這就要檢查，是什么原歷導致程序在這里失��？這就要一一排除其它子程序是否非法修改了相關的數據。

c、如果什么問題都找不到，那只好自己再加入簡單代碼來調試程序了。
一般，可以用多余的IO口（如果沒有強行的借來用吧）對他進行取反操作，這樣我們就可以在外部接個發光管或者用表示波器去測量了。例如，在串行中斷程序加一條cpl p1.0，就可以通過觀查或者測量p10的狀態來知道程序運行的狀態了。

如果P10從頭到尾都是高，那就說中斷從來沒有調用來，如果只變低了，那說明只中斷過一次，當然，長期中斷就是產生方波了，測量方波就知道程序運行情況了。

再就是將數據用串口送出，電腦可以收到數據分析故障出在哪里

可以檢查，