我們使用微控制器去做一些任務的時候，通常把程式寫成順序結構，基本可以解決大部分的設計要求了。而且這種結構便於理解，而且程式易構成模組化，在各個模組中呼叫實現更複雜的任務。
然而順序結構的寫法，有時候避免不了沉重冗長的時間等待。例如鍵盤掃瞄，你就給我弄了乙個delay_20ms()函式，而在這延時的過程，其實mcu可以做很多事情的，這不白白的浪費掉這段時間嗎？其實，delay的這段時間用數碼管顯示代替，也就是在等待的過程，我們可以做一下顯示。但僅此而已？
之前，我在做3寸大數碼鐘的時候就遇到過乙個時間要求苛刻的問題，我採用了17個數碼管，分成兩組來動態顯示。為了不閃爍，那麼重新整理頻率起碼大於50hz。而微控制器還有其他任務，比如說讀ds1302實時時鐘，串列埠收發資料，按鍵掃瞄，讀ds18b20等等，而其中最要命的是讀取ds18b20溫度感測器的資料，大家都知道其中等待溫度轉換的時間，基本要達到900ms了，這樣一來，數碼管就會閃爍得很厲害了。
所以，我網上找了一些資料學習。大家都採用「時間片輪詢」演算法的程式架構來寫，這樣既保證了實時，也充分利用了任務等待的時間。
下面簡單來看看，關於時間片輪調的程式思想，而按照這種思路，可以衍生出很多程式結構。
假定，微控制器要執行的任務有task_1(); task_2(); task_3(); ……task_n(); 各個任務對時間要求不同。
下面是我對時間片輪調的相關認識。
系統基準時間片：
我們採用定時器中斷來產生系統的基準時間片，也叫系統的基準節拍，例如每4ms中斷一次。這可以形象的比喻成脈搏心跳。
任務（事件）的輪調：
每一次心跳，我們就給任務執行的時間標誌計數。當標誌計數到了，就執行該任務函式！
事件的要求：
1.每乙個事件的執行時間不允許超過乙個時間片。
2.事件中不使用較長的delay();函式，可以使用定時延時等待，但永遠必須遵守第一條要求。
3.執行時間較長的任務，或者較為複雜的任務，可以分割到多個時間片內執行。
實時性任務要求：
對於實時性要求較高的任務。比如串列埠收發事件，可以考慮放在主迴圈呼叫，或者再定時中斷中呼叫。
引數傳遞要求：
各個任務函式之間引數傳遞，建議使用全域性變數。任務中的內部函式，可以使用區域性變數。
程式結構：
分析一下上面的程式結構，使用了乙個定時器產生系統時鐘滴答，然後時鐘滴答到了，就更新時間標誌，然後統一用乙個事件函式來根據時間標誌分時的執行各個任務函式。
但任務執行完後，時間標誌被重置，並重新計數。那麼這個任務函式就相當於被排程在了任務佇列的末尾了！（感覺是不是有點任務排程管理的意思了？）
當然，各個任務函式呼叫的時間不同，就造成了任務執行頻率的不同。這也是時間片的大小商定，以及時間片分布的問題，這需要從實際的任務考慮，並取得乙個最佳的時間片，以及合理的安排各個任務函式的關係。
另外一種時間片輪調程式結構
其實，原理大致相同。執行機制不同罷了，各種程式結構有它優缺點，有最適合使用的地方。
下面，簡單了解。
程式結構：
對於時間片輪詢法的程式結構，無疑有比順序結構程式更多的優點，但任務函式有時候被拆分成多段，不方便理解程式整體思路。
程式設計之美 詳論微控制器韌體模組化架構設計
微控制器系統開發人員的目標之一是在程式設計環境中建立韌體，以實現低成本系統 軟體可靠性以及快速的開發迭代時間。實現這種程式設計環境的最佳方法實踐是使用統一的韌體架構體系結構，該體系結構在產品開發過程中充當框架並支援 韌體模組化 或稱為子系統。如果不採用統一的設計架構，那麼其業務需求耦合關係複雜，不採...
salesforce 架構設計 從架構設計到架構師
因為碎片化的時間多了，所以開始刷起某乎了，關注了架構相關的板塊，也順手回答了一些問題。發現有很多同道中人正在經歷著我前兩年經歷的階段，對於做架構沒有相對具象的一些理解，更沒有系統化的認識。所以把最近回答的一些內容整理一下，權當記錄，留給3年後的自己 按慣例，容許我裝x開頭 一 架構的定義 在軟體開發...
mysql架構設計 初識mysql架構設計
一 應用系統如何與mysql進行一次互動？最開始接觸jdbc的時候，我們系統如何完成一次sql操作呢？第一步，建立資料庫連線 第二步，操作sql 第三步，釋放連線。但是每次建立與資料庫的連線非常耗時和資源，所以我們加入了連線池的概念。第一步的獲取連線是從連線池中獲取乙個可用的連線，第三步的釋放連線不...