做了一些修改，隱去了專案的真實名稱。

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)模式。模式是前人程式設計經驗的總結，是軟體結構的模板。訊號驅動、狀態機是模式當中的兩個模式，是模式的子集。模式的學習相對來說有難度，但如果掌握了，按照模式的方式去思考、設計、編寫軟體，去思考軟體框架，將會極大的促進軟體質量。


總之，按照分層的方式去組織程式碼，按照面向物件的方式去劃分模組，按照訊號驅動-狀態機模式去實現軟體框架，將使我們的軟體框架具有更好的效能、可移植性、可維護性，編碼起來也更容易。