我們知道，在rtos中會提供若干延時函式的api。對於沒有仔細了解過rtos的同學而言，可能會產生這樣疑惑：這些api與普通自寫的延時函式相比究竟有何優勢呢？為什麼要額外提供這些api？
在這篇文章中，我們來分析下這些api介面的工作原理、特點以及其相比自寫的延時函式，究竟有什麼優缺點，我們該如何選擇。
在沒有使用rtos之前，我們可能通過以下方式實現延時或定時。
在比較簡單、各條指令執行時間可**的mcu上，也許你寫過如下類似的**。
void delay () }}
有的同學可能會借助於定時器實現軟延時，**大致如下：
void delay ()但這種方式也有著明顯的缺點：為了延時而占用乙個硬體定時器資源。
上述兩種方式還存在另乙個問題；在延時期間，程式什麼也幹不了，只能原地等待。也許有的人會在等待期間插入一些**來減少一些無謂的箸待開銷；但這種做法並不多見。
所以，有時我們會考慮設定定時器，配置定時器中斷，在定時器中斷中執行相應的功能；或者在中斷中設定時間到達標記，然後在主程式中處理。例如：
void timerisr ()
int main ()
}return 0;
}
上面幾種方式，同時還存在幾個嚴重的問題，很難做到同時給多個任務使用。例如rtos提供的延時api，相比於軟延時，其最大的特點是：在任務延時過程中，能夠切換到其它任務去執行。這樣就避免了死等，可用於執行一些其它功能的**。顯然cpu的利用率就大大提高。實種介面的實現原理大體類似：所以, rtos還有必要提供另一種模式的延時api。
通過乙個硬體定時器定期產生中斷，稱之為時間節拍。在每個時鐘節拍發生時，遞減任務內部的乙個延時計數器，當延時計數器減至0時，將任務插入到就緒列表等待獲取cpu執行。而在延時期間，任務一直在延時佇列中，此時cpu執行其它非延時任務。可以看到，只需要乙個定時器資源，就要以給系統中所有任務提供延時功能。每次延時的基本單位是乙個時鐘節拍週期。也就是說每次任務延時，必須至少延時1個周期長。這正是使用這種方式存在的問題，即不能實現更小的時間延時。此外，在實際使用過程 ，我們會發現在某些情況下會出現延時存在較大誤差的情況，下圖中說明了這種情況。
因此，這種方式是通過軟體資源+犧牲了一定的功能條件下，換取了cpu利用率的提公升以及可被多工通用。
前面介紹的幾種方式，在實際使用時，並不一定說某種延時方式是最好的。
各種延時方式各有優缺點，根據實際需要選擇。當然，以上只是建議，並不是絕對的。在實際使用過程，還要考慮個人習慣、精度要求等。在某些要求並不苛刻的應用中，有少量的延時誤差或者cpu利用率不高，其實也沒有多大關係。沒有最好的方式，只有最適合的方式！該文章同時發布在：
延時輸出 與 即時輸出系統時間
相信我們大家都用過ppt的自動放映功能，但是聯絡到c語言我們難免會想到 在c的世界中能不能做到利用延時輸出來達到自動放映的效果呢？當然是可以的，下面將在這乙個知識點的基礎上進行放射性展開。是不是覺得這個system 函式很有意思？那就再看幾個，下面給出乙個示例 控制計算機關機 include inc...
JS中的延時與Timer函式
延時 settimeout code,millisec 用於設定在指定的毫秒數後呼叫函式 設定延時 var timeoutid settimeout function 5000 cleartimeout timeoutid 用於取消由 settimeout 函式設定的延時 週期呼叫 timer se...
linux系統下的定時任務與延時任務
at 時間 在指定時間執行命令 at rm rf mnt 命令內容 at ctrl d發起任務 at now 15min 十五分鐘後執行任務 at l 檢視任務列表 c 任務號 檢視指定任務號的任務內容 r 任務號 取消指定任務執行 當延時任務有輸出時 輸出會以郵件的形式傳送給at任務的發起者 可以...