做了一些修改，隱去了項目的真實名稱。
1 概述
這裏想進一步談談軟件編程中的想法
我期望的編程方法爲如下方法的結合：信號驅動、狀態機、模式、面向對象、分層
現在24xx的方法爲固定週期的處理方法，我想先談談目前軟件優缺點、我們期望的軟件框架是什麼樣的（或者框架的改進方向），最後談談基於信號驅動、狀態機編程模式的優缺點。
這篇文章，是在參加完公司年終會議，提出對目前軟件框架有改進的意願的情況下寫的，也是對20080123寫的一些東西的整理。
2 目前的軟件框架
2.1 目前的軟件框架是什麼樣的
我們目前的軟件框架，x project 2406上的軟件框架，是無操作系統、基於控制流程劃分模塊、固定週期調用模塊入口函數的框架。
2.2 優點
1 簡單。符合大多數人的思維習慣。
2 程序空間、RAM空間的利用比較有效。
3 固定週期調用模塊入口函數，系統負荷穩定。不會出現系統計算能力不夠的情況，
即1ms內無法跑完一個主循環的情況，這個情況比較容易控制。
2.3 缺點
1 模塊的劃分方式有改進的餘地。基於流程的模塊劃分方式，當流程變更時，會導致程序大量修改。
也會導致多個模塊的耦合嚴重。
2 硬件層和業務層沒有隔離。例如：在縫製模塊內直接讀寫IO口，使代碼緊緊的約束在2406這個CPU上，
很難遷移，從而代碼的複用也困難。
3 非C語言。彙編語言的學習、維護難度大。
4 固定週期調用模塊入口函數，帶來了性能上的不確定性。例如：
原來縫製模塊是1ms調用1次，會造成某些處理不及時，一個信號來了，例如用戶踩下踏板，則踏板模塊
置起踏板踩下的變量標誌，但縫製模塊處理該信號，會等待0~2ms,等待的時間雖然不超過2ms，但仍然有
時間的不確定性。這種情況，是降低停針精度、系統控制性能無法進一步提高的原因之一。
5 會浪費一部分CPU計算能力。如下的情況，在這種架構下比較常見：固定週期到後，某個模塊的函數被
調用，進入較深的層次後，檢查標誌後，發現沒有什麼事情，就退出。則無形之中浪費了CPU資源，
延緩了其他信號的的處理。
6 文檔的維護比較困難。流程圖比較複雜，主要的流程淹沒在分支的跳轉上。
看懂、看清楚比較困難。軟件修改後，流程圖的同步更新也比較困難。
3 期望的軟件框架
我們從兩個方面來談理想的軟件框架，一是軟件設計過程如何劃分步驟，二是理想的軟件框架。兩者有一定的關係，
如果軟件框架在一定程度上能夠反映設計步驟，則我們的框架應該是反映了軟件設計的本質的，說明軟件框架是正確的。
3.1 軟件設計步驟
我們將軟件設計過程分爲如下步驟：
瞭解CPU + 瞭解控制對象 + 瞭解需求-> 設計流程 -> 考慮例外 -> 寫成文檔 -> 寫成軟件 -> 測試
(1) 瞭解CPU: 指我們要看CPU的手冊，知道CPU提供了哪些硬件資源，這些資源的極限條件是多少，例如RAM多少，
Flash多少，通訊的最大速度是多少；還要了解編程環境。
(2) 瞭解控制對象：例如電磁鐵，我們要知道吸合的延遲時間是多少，釋放的延遲時間是多少，chopping
的佔空比多少；對於電機來說，就是速度最高是多少，電流最大是多少，加速度是多少等等，這些都是控制對象的瞭解。
(3) 瞭解需求：需求，就是用戶期望做什麼。
(4) 設計流程：根據以上的內容，根據各種約束條件，爲了實現用戶期望的目標，我們如何設計一個過程，
來實現用戶的目標。
(5) 考慮例外：這一條本來是“設計流程”的一部分，單獨拿出來，是爲了強調。任何流程，都有一條主線，即一般
情況是什麼樣的，同時，應該有例外情況的考慮。例外情況也就是相對主要情況的差異，也就是說，這裏強調
使用按照差異來進行設計。
(6) 寫成文檔：將以上對各種瞭解、流程、以及例外情況，寫成文檔。
(7) 寫成軟件：軟件應該是對文檔的一個翻譯，將文字語言（往往是更適合計算機表達的文字語言，例如流程圖）
翻譯成計算機的語言，例如C語言。
(8) 測試：根據測試的結果，再返回到前面的環節，做進一步的修正。
3.2 理想的軟件框架
下面談談我們期望的軟件框架。理想的框架，應該能夠反映軟件設計過程，解決部分原來軟件框架的缺點。
(1) 軟件的底層和應用達到一定的解耦。這個步驟，也是將CPU的理解，和對需求、控制對象的理解分開。
例如縫製模塊，和用的CPU無關。而且底層模塊，也和具體的應用沒有緊密的關係。
則會增強軟件的複用，使公司的投入得到最大限度的重複使用。而且，軟件從一個
CPU更換到另外一個CPU也比較容易。
(2) 文檔的編寫和軟件的編寫達到更加一致的地步。一個人寫完文檔，另外一個人即可以根據文檔實現軟件。
(3) 使編程人員比較容易思考。要形成一種一致的、固定的模式讓軟件人員去思考，從而使軟件設計人員
比較容易表達出自己對控制流程的理解。
(4) CPU的計算能力達到按需分配的地步。比較理想的是：哪個模塊有事情發生，其接口就會被調用；否則，就不調用。
不會將CPU資源浪費在無效的標誌查詢上。
(5) 軟件的設計，對測試要有支持。即用軟件來測試軟件，而且軟件框架要能夠支持這種情況，
能夠比較容易插入、刪除測試代碼。
(6) 按照控制對象劃分模塊。我們去理解一個系統時，是按照控制對象爲單元去理解的，例如：倒縫電磁鐵、剪線電磁鐵、
機頭、電機、HMI，是當作一個個獨立的對象去理解的，硬件人員也會這樣去測試及獲取這些對象的特性，但在軟件
編寫時，傳統方式卻是按照流程去控制這些對象的，將所有對象的控制混合在一個流程中，因此，有個轉換的過程，
這個轉換就會造成思考和編程的困難。
能否軟件設計反映人理解這些對象的過程呢？即軟件中也是按照對象去劃分模塊的，實際上面向對象
就是解決這個問題的軟件思想工具。
(7) 爲了解決以上問題，會消耗部分RAM和Flash，但增加的部分，應該是受控而且是可以承受的。
天下沒有免費的午餐，實際上，隨着CPU技術的發展，硬件資源相對寬裕
（例如28xx，它的flash和ram對平縫應用是用不完的），而軟件複雜度的增加，是我們更難以控制的方面，
如何用一定的硬件資源來換取複雜度的降低，這是軟件框架要做的事情。
4 我期望的編程框架
我期望的編程框架爲如下方法的結合：分層、面向對象、信號驅動、狀態機、模式
(1) 分層。分層的設計方法，能夠隔離CPU和應用層，更換一個CPU，就不用更改縫製流程的代碼了。
當然，合理的劃分更多的層次，可以帶來更多的好處。我一般將程序分爲CPU層、驅動層、應用層。
(2) 面向對象。這是現代軟件發展的方向，不僅僅是隻有PC機編程可以用這種思想，單片機也一樣可以用，這種思想將人去理解被控對象和編程方法一致起來，使代碼的編寫、維護難度都降低。這種方式的另外一個好處，促使軟件人員不要將編碼和對對象的理解混合在一起。
(3) 信號驅動。我們可以設想，如果一個信號來了，就去調用對應模塊入口函數；信號密集，則入口函數調用得頻繁；信號少，則入口函數調用頻率低；沒有信號，則對應的模塊入口函數不會被調用；實現CPU計算能力的最大利用，按需分配計算資源。
(4) 狀態機。按照狀態去思考流程，會使編程人員的思維集中在當前的狀態上，是程序員的思維更集中；同時，使文檔的描述和代碼的編寫一致起來。
(5) 模式。模式是前人編程經驗的總結，是軟件結構的模板。信號驅動、狀態機是模式當中的兩個模式，是模式的子集。模式的學習相對來說有難度，但如果掌握了，按照模式的方式去思考、設計、編寫軟件，去思考軟件框架，將會極大的促進軟件質量。
總之，按照分層的方式去組織代碼，按照面向對象的方式去劃分模塊，按照信號驅動-狀態機模式去實現軟件框架，將使我們的軟件框架具有更好的性能、可移植性、可維護性，編碼起來也更容易。
