打開電腦的任務管理器，看著跳動的CPU使用率，發現很舒服。每一個線程占用了多少CPU清清楚楚，也就能針對性的確認為啥你的電腦跑的慢了。

今天這篇筆記不講每個任務（或線程）CPU的使用情況，而是單片機整體的CPU使用情況，先易后難嘛。

為什么要知道這個呢？知道這個有啥用呢？魚鷹看的書少，就不寫官方話了，只說說自己的理解。

CPU使用率越高，意味著系統越繁忙，對于一些事情的響應也就越慢。比如你的電腦CPU使用率占到90%以上，你會發現打字變慢了，鼠標移動變慢了，這都是因為CPU占用過高，導致系統來不及處理你的鍵盤和鼠標數據，所以才會有慢悠悠的表現。

電腦是非實時系統，要求不高，即使電腦變慢，電腦死機，后果都不是很嚴重，但是如果說你的嵌入式系統是國防、醫療領域的，如果也出現了這些情況，那后果不堪設想。比如呼吸機突然出問題了，那么對于病人來說，就是災難，所以醫療行業的產品都會經過嚴格的測試，否則不允許上市。

嵌入式系統使用的大部分應該都是實時操作系統，即所謂的RTOS，它必須對外界的各種情況作出非常快的響應，如果不能，那你設計的系統就是有問題的。

那么如何快速響應外界信息呢？就看CPU使用情況了，CPU平時的使用率越低，越能快速響應。怎么理解這句話？

比如一天時間里，你要上8個小時的班，其他時間才屬于你自己，如果按一天來計算的話，你的CPU利用率是8/24=33.3%，其他時間可以快速響應其他事情，比如別人叫你出去吃飯，如果是在下班時間，你隨叫隨到，如果是上班時間，那么叫了你也沒用，只能等下班之后才行。所以雖然你的CPU利用率才33.3%，但是上班的時候還是不能及時響應其他事情，因為上班是優先級最高的任務（假設上班是最高優先級任務）。

這個例子可能不是很好，換成學生的例子可能更好一些。比如一個學生，每天上7節課，課間都有休息時間，假設還是要上8小時，但是因為中間不是連續的，所以雖然你的CPU利用率還是33.3%，但是你在課間時總能對一些其他事情做出快速響應，所以整體性能可能比前一個例子好一些。

所以設計系統時，千萬別讓一個高優先級任務持續占用CPU太長時間，如果可能的話，盡可能拆分長任務，否則低優先級的任務很可能無法及時運行，外在表現是，系統卡了。

看完這個，很多人就會想了，我的系統該怎么計算CPU使用率呢？對了，我的系統是裸機的……

不好意思，裸機系統CPU使用率100%，算不了……

那好，帶操作系統的怎么算，比如uCOS、FreeRTOS、RT-Thread？

嚴格來說，如果不采用休眠等機制的話，不管是裸機還是操作系統，CPU使用率都是100%。

為什么這么說呢？你看系統的CPU使用率的計算方法就知道了（這里說的是RTOS中簡單的計算方式，而不是電腦那種，那種計算應該比較復雜，魚鷹也不清楚）。

簡單的說，一個操作系統里有很多用戶任務，還有一個特別的系統任務，就是空閑任務。這個任務平時啥也不敢，就在那里空跑，CPU沒有其他任務執行的時候，就會跑到空閑任務中執行。

除了空跑，空閑任務還有什么特點？優先級最低，不允許掛起空閑任務，即該任務永遠處于就緒狀態。

正因為這些特點，它變得非常特殊，也是我們能夠計算CPU使用率的核心所在。

說白了，所謂的CPU使用率計算，就是先計算空閑任務的運行時間，然后反推其他任務的運行時間。

比如說，1秒時間內，空閑任務運行了700毫秒，那么空閑任務的CPU使用率是70%，反推一下，其他任務的使用率就是30%。但是特別注意的是，這里說空閑任務運行700毫秒，不是說空閑任務持續不斷的運行了700毫秒，而是中間穿插了其他任務的執行，中間穿插就是300毫秒執行其他任務的時間。

看這個圖就清楚了：

事實上，1秒時間內的任務切換遠比上圖顯示的要多的多，只是為了更好的說明，才沒畫那么多切換過程。

真正好的系統，一個任務不會長時間占用CPU，而是會不停的主動交出使用權，像上圖任務2有100毫秒的占用，如果這個是高優先級任務，那么低優先級的任務的響應肯定在100毫秒以上了。

當然，如果說這個響應時間滿足設計要求，那么在系統任務數比較少的情況下，倒是無所謂的事情。

可能你還有疑惑，你怎么不說說空閑任務啊，空閑任務有長達300毫秒的CPU占用哩！

不好意思，真不需要說它，因為它的優先級任務最低，所以如果說它能在300毫秒內持續運行，那肯定是因為沒有其他任務需要處理才會讓空閑任務一直運行的。

為什么這么說呢？因為在操作系統中，除了主動切換任務外，還有被動切換一說。

所謂主動切換任務，就是任務本身認為自己執行完了，然后自己主動調用系統函數進行切換，比如系統延時函數等；而被動切換有所不同，被動切換是時時刻刻都在發生的，只要滿足條件，那么你的任務可能還沒有完全執行完畢，就可能切換到其他任務先執行了。

怎么理解呢？假如四個人組成一個小組討論問題，其中一個是小組長（操作系統），小組長有絕對發言權，可以隨時打斷其他成員（任務）的發言，所以當組員發言時，他每隔幾分鐘都會檢查一下，看看誰舉手準備發言，一旦發現有等級高的成員舉手，那么不管目前發言的組員是否發言完畢，小組長都會立刻讓高等級的組員先發言，等他發言完畢，才會讓之前未發言完成的組員繼續發言。這樣可能不是很人性，但是確實能保證高效！

在上面這張圖中，其實還有一個非常重要的東西沒有畫出來，那就是操作系統每隔一段時間對就緒任務的檢查。在操作系統中，這種檢查工作一般是由定時中斷完成的（stm32中有專門為操作系統準備的定時中斷，即SysTick）。

中斷是凌駕于所有任務（或線程）之上的超級任務。

但是檢查時間（即中斷時間）也是有講究的，如果檢查時間過短，那么整個系統就會忙于切換任務，花費在任務切換的時間占比就會很大；而檢查時間過長，那么高優先級任務就不能得到更快速的響應，所以這個時間一定要謹慎選擇。

一般來說，任務切換CPU占比在1%以內應該是比較好的（這個沒有理論依據哈，魚鷹瞎寫的），即如果各個任務只調用一個延時函數，如果你的CPU占用在這個范圍，那么就是比較合適的。

當你學會了CPU使用率計算，不如嘗試著修改中斷時間，你會發現不同的中斷時間，CPU使用情況是不同的，原因就在于操作系統本身的消耗！

本篇主要從整體介紹系統CPU使用率是什么鬼，下篇筆記將在rt-thread系統上為大家實操一番，這樣既能把握概念，也能掌握細節，這才是學習的節奏嘛。