我之前的文章提到了為什么我們需要關(guān)注CPU利用率的問題，總結(jié)一句話就是，利用率越低，你的系統(tǒng)效率越高、響應(yīng)越快，實時性越高。但是并沒有具體說該如何計算CPU利用率。 今天，借助國產(chǎn)操作系統(tǒng)RT-Thread，我們開始實操一番。在實操之前，需要簡單了解幾個概念。鉤子函數(shù)，即以hook命名的那些函數(shù)。那么什么是鉤子函數(shù)呢？說白了，就是一個函數(shù)指針，只是這個函數(shù)比較特殊一點。 特殊在哪？操作系統(tǒng)某些指定位置才會設(shè)置鉤子函數(shù)，比如程序運行到空閑任務(wù)了，為了不修改系統(tǒng)源碼（沒事別修改源碼，很危險的事情，除非你是真大佬），系統(tǒng)會提供一個設(shè)置鉤子函數(shù)的函數(shù)接口給你，當(dāng)你需要在空閑任務(wù)中執(zhí)行某些功能時，用這個函數(shù)設(shè)置你的需要功能函數(shù)就可以了，等系統(tǒng)運行到空閑任務(wù)，他就會幫你調(diào)用這個函數(shù)了。 這個功能看著是不是有點眼熟，對的，和所謂的回調(diào)函數(shù)是一個道理（我也不明白為啥叫鉤子函數(shù)，可能是因為和系統(tǒng)有關(guān)，和通用的回調(diào)函數(shù)又有點區(qū)別，所以就稱之為鉤子函數(shù)吧，不過你不要管名稱，只要知道意思就行了）。 除了在空閑任務(wù)可以設(shè)置鉤子函數(shù)，還有可能在任務(wù)切換、系統(tǒng)啟動、任務(wù)創(chuàng)建等等關(guān)鍵的地方設(shè)置，當(dāng)然了，這里的每一個鉤子函數(shù)都是一個單獨的函數(shù)指針。 前面也說了，設(shè)置鉤子函數(shù)的目的只有一個，那就是可以讓你在不修改系統(tǒng)源碼的情況下達(dá)到私人目的，讓系統(tǒng)的擴展性更強，比如今天說的內(nèi)容（還有下次介紹的線程CPU使用率問題），如果系統(tǒng)沒有空閑鉤子函數(shù)的存在，你只能去修改系統(tǒng)源碼才能達(dá)到目的啦。 還有文章所說的線程（task）、任務(wù)（thread），其實在RTOS中都是一樣的。在 uCOS、FreeRTOS 中，叫任務(wù)，RT-Thread 叫線程，只是叫的名稱不一樣，內(nèi)容都是差不多的。 然后再大概說說怎么計算的問題。也就是在空閑鉤子函數(shù)里面，我們需要干什么事情才能到達(dá)CPU計算的目的。 首先，第一步肯定是設(shè)置鉤子函數(shù)，其次就是鉤子函數(shù)該怎么寫的問題。這個網(wǎng)上一搜就出現(xiàn)了（魚鷹也是網(wǎng)上搜的代碼），然后就要分析為什么這么寫。 前面說過，CPU利用率其實是首先計算一段時間內(nèi)空閑任務(wù)執(zhí)行時間，然后反推其他任務(wù)的執(zhí)行時間。 這里有兩個問題，一段時間是多少？空閑任務(wù)的執(zhí)行時間怎么計算？先說第二個問題。用定時器時間掐？好像不好，因為你不知道什么時候程序就離開了空閑任務(wù)跑去執(zhí)行其他任務(wù)了，而即使你可以知道它什么時候離開空閑任務(wù)的，那也會增加計算難度，不是好的方式。 那怎么辦？還記得剛學(xué)單片機時你是怎么進行軟件延時的嗎？對，就是用這個方法，軟件延時！ 只要程序執(zhí)行到空閑任務(wù)了，就用一個變量不停自加。這樣就可以根據(jù)變量值來大概計算空閑任務(wù)的執(zhí)行時間。 但是這里又存在一個問題：如果這個變量一直自加，肯定會溢出，該怎么解決。 加大變量的大小，比如原先使用一個字節(jié)、兩個字節(jié)的，那么如果溢出，就用四個字節(jié)、八個字節(jié)。 但32位系統(tǒng)最大能支持的也就8個字節(jié)了，如果還是溢出了咋辦？再套一個循環(huán)，一個循環(huán)的數(shù)加完了，再加另一數(shù)就行了。 但是還有一個問題，如果說自加的時間不做限制，那么再多的變量也不行，而且還會影響CPU計算的實時性，也就不能實時反映CPU利用率了；而如果時間太短，如果剛好有任務(wù)的執(zhí)行時間在這個范圍，那么很可能你計算CPU利用率就直接是100%了。 比如說你一個任務(wù)需要執(zhí)行10毫秒，然后你計算CPU的周期也是10毫秒，那么可能剛好開始計算時跳到了那個任務(wù)執(zhí)行，那么你的變量就沒有自加了，也就會顯示100%利用率了。 這里其實說的是前面的第一個問題，一段時間是多少？ 對于這個時間，因為魚鷹看的書籍比較少，所以也沒有理論支撐（如果有道友知道的，不如留言）。 但是肯定既要考慮變量溢出（這個可以通過加循環(huán)方式解決），又要考慮實時性，還要考慮其他任務(wù)的最大執(zhí)行時間，否則本來系統(tǒng)沒有問題的，但是因為你追求實時性，導(dǎo)致CPU利用率80%、90%的，那就很尷尬了。 以上討論如果沒有經(jīng)驗可能比較難理解，所以建議大家在看完后面內(nèi)容，實操過后，再回頭重新看一遍，這樣才有更深的理解。 現(xiàn)在再看CPU計算公式：

cpu_usage = (total_count – count）/ total_count × 100 %（滑動查看） cpu_usage: CPU利用率； total_count：單位時間內(nèi)全速運行下的變量值； count：單位時間內(nèi)空閑任務(wù)自加的變量值。 total_count這個值表現(xiàn)了單片機全速運行下，所能達(dá)到的最大值。所謂全速運行，即不響應(yīng)中斷，也不去執(zhí)行其他任務(wù)，就單純讓它在一個地方持續(xù)運行一段時間，這個值可以體現(xiàn)CPU的算力有多大。 比如，51單片機，可能這個值自加10毫秒之后只有100，STM32F1單片機自加能到1000，而STM32F4單片機能到2000，這樣就能體現(xiàn)他們之間的算力差別了。 這個值可以是動態(tài)的，也可以是靜態(tài)的。靜態(tài)有靜態(tài)的好處，動態(tài)有動態(tài)的好處。 所謂的靜態(tài)是指，在系統(tǒng)沒有運行任務(wù)時，關(guān)閉所有的中斷，自加這個值。這樣，這個值比較準(zhǔn)確，但是如果一開始這個值計算錯了，那么后面的計算肯定也是有問題的，而且如果系統(tǒng)啟動后長時間既不啟動任務(wù)，也不響應(yīng)中斷，肯定對系統(tǒng)有一定的影響。但是好處是，系統(tǒng)消耗更少，因為他只計算一次。 而動態(tài)計算，則是在空閑任務(wù)中，當(dāng)這個值為零時，計算一次，之后只會在空閑任務(wù)自加的變量值超過這個數(shù)時，才會更新這個值，這樣一來，最終還是能準(zhǔn)確反映CPU利用率的。好處是，不需要在開機時關(guān)閉所有中斷，當(dāng)然壞處是，前期可能不是很準(zhǔn)，因為可能由于中斷原因?qū)е掠嬎愕闹递^小（中斷處理時消耗了算力）。 廢話太多了一些，直接開始干吧。新建一個文件，拷貝如下代碼：

#include #include #define CPU_USAGE_CALC_TICK 10#define CPU_USAGE_LOOP 100 static rt_uint8_t cpu_usage_major = 0, cpu_usage_minor= 0;static rt_uint32_t total_count = 0; static void cpu_usage_idle_hook(void){ rt_tick_t tick; rt_uint32_t count; volatile rt_uint32_t loop; if (total_count == 0) { /* get total count */ rt_enter_critical(); tick = rt_tick_get(); while(rt_tick_get() - tick < CPU_USAGE_CALC_TICK) { total_count ++; loop = 0; while (loop < CPU_USAGE_LOOP) loop ++; } rt_exit_critical(); } count = 0; /* get CPU usage */ tick = rt_tick_get(); while (rt_tick_get() - tick < CPU_USAGE_CALC_TICK) { count ++; loop = 0; while (loop < CPU_USAGE_LOOP) loop ++; } /* calculate major and minor */ if (count < total_count) { count = total_count - count; cpu_usage_major = (count * 100) / total_count; cpu_usage_minor = ((count * 100) % total_count) * 100 / total_count; } else { total_count = count; /* no CPU usage */ cpu_usage_major = 0; cpu_usage_minor = 0; }} void cpu_usage_get(rt_uint8_t *major, rt_uint8_t *minor){ RT_ASSERT(major != RT_NULL); RT_ASSERT(minor != RT_NULL); *major = cpu_usage_major; *minor = cpu_usage_minor;} void cpu_usage_init(void){ /* set idle thread hook */ rt_thread_idle_sethook(cpu_usage_idle_hook);}以上的代碼網(wǎng)上找的，首先分析這兩個宏，第二個宏就是前面所說的防止變量溢出用的，而第一個值就是CPU計算周期，這個值比較關(guān)鍵，后面再說。 ? 首先在系統(tǒng)啟動前設(shè)置鉤子函數(shù)：

然后，就沒有然后了。 對的，設(shè)置完之后就可以了，但為了讓我們能觀察到，可以打印出來。

我們可以觀察效果如何，開始設(shè)置計算周期和任務(wù)延時函數(shù)一樣，10毫秒。 測試結(jié)果：

可以看到，因為是動態(tài)計算的，所以開始為0，因為系統(tǒng)首先運行其他任務(wù)，只有其它任務(wù)不運行時，才會開始運行空閑任務(wù)，所以CPU利用率為0。 但是即使后面有值了，你也會發(fā)現(xiàn)CPU利用率變化很大，0.82%~1.5%。而且你會發(fā)現(xiàn)除了開始的0.0%，后面又再次出現(xiàn)了，這又是怎么回事？ 通過設(shè)置斷點分析，發(fā)現(xiàn)，這是因為計算值超出了開始的值，重新設(shè)置了：

這就是動態(tài)計算的一些問題了，它在一開始的一段時間里，因為無法完全表現(xiàn)算力，只能通過后面不停的修正該值才能達(dá)到穩(wěn)定。 現(xiàn)在修改計算周期 20 毫秒：

發(fā)現(xiàn)它的表現(xiàn)更差勁，4.3%~11.61%，而且會周期性出現(xiàn)低利用率的情況。 再改，100毫秒：

可以看到這個比較穩(wěn)定了，13.71%~14.35%。 那么這個測試代碼實際情況的CPU利用率是多少呢？ 我們可以通過前面的筆記《KEIL 下如何準(zhǔn)確測量代碼執(zhí)行時間？》大概計算線程執(zhí)行時間：

1.59毫秒，10毫秒執(zhí)行周期，如果只有這個任務(wù)執(zhí)行，大概1.59/10=15.9%（準(zhǔn)確計算應(yīng)該是 1.59/(10 + 1.59) =13.7%）。 和前面的100毫秒類似。 我們先不管前面的結(jié)果，先理解一下里面的計算方法。 首先，如果total_count開始為0，那么開始第一次計算。這次計算會關(guān)閉調(diào)度器。

計算過后，就不再進入。 之后就是動態(tài)計算過程：

和第一次計算一樣，都是在一定時間內(nèi)自加計數(shù)器，不同的是，這次不會關(guān)閉調(diào)度器，也就是說，如果有高優(yōu)先級任務(wù)就緒，那么是可以執(zhí)行其他任務(wù)的。 并且計時時間使用的是系統(tǒng)函數(shù)rt_tick_get()，單位為系統(tǒng)調(diào)度時間。測試環(huán)境中，系統(tǒng)調(diào)度時間為 1 毫秒。 有意思的是，在進行最終的計算時，采用了分步計算，首先計算整數(shù)，再計算小數(shù)。 為什么要這樣做？效率！ 這樣的計算方法，可以將浮點運算轉(zhuǎn)化成整型運算，這在沒有浮點運算單元的單片機中，能大大減少計算時間。 另外，為了防止溢出，還使用了一個循環(huán)結(jié)構(gòu)。 理解了以上內(nèi)容，現(xiàn)在開始進行魚鷹式深度思考：

上面的分步計算是否存在問題？

關(guān)調(diào)度器只關(guān)閉了任務(wù)調(diào)度，但還是會響應(yīng)中斷，這能夠體現(xiàn)單片機最大算力嗎？

使用rt_tick_get() 函數(shù)進行計時，精度是多少，會影響最終的計時嗎？

有必要使用循環(huán)體嗎？如果單位時間內(nèi)不溢出，是否不用循環(huán)體會更好？

前面的CPU使用率為什么會跳動，按理說任務(wù)的執(zhí)行時間應(yīng)該是確定的，也只有一個任務(wù)在運行，不應(yīng)該跳動才對？

10毫秒的計算和100毫秒的計算差別在哪？

7. 終極問題，如何精確計算CPU使用率？ 上面的問題，如果只是粗略計算，其實都可以不用考慮，本著對技術(shù)的熱愛，還是聊一聊好了。 1、分步計算，不知道你想到了什么BUG？這個問題其實在以往的筆記都提過，這次再說一次。 當(dāng)你在獲取CPU使用率時，如果剛好在更新這兩個值，那么可能整數(shù)部分是上一次計算的值，而小數(shù)部分卻是這次計算的值，那么肯定有問題。 這就涉及到數(shù)據(jù)完整性獲取的問題。怎么解決。關(guān)調(diào)度器、關(guān)中斷都可以。 但是因為是粗略計算，那么小數(shù)部分即使是錯誤的，也沒事。 2、因為只關(guān)調(diào)度器，所以對于中斷還是會響應(yīng)，比如說你設(shè)定計算周期為100毫秒，那么1毫秒一次的systick中斷肯定會執(zhí)行，那么在100毫秒中，有100次進入中斷執(zhí)行，而這些算力在上述算法中是無法體現(xiàn)的。 3、rt_tick_get() 函數(shù)精度問題，因為這個是系統(tǒng)的軟件計時器，所以在測試環(huán)境中為1毫秒遞增一次，也就是說它的精度在1毫秒。因此，在100毫秒的計算周期里面，有1% 的誤差存在，在10毫秒的計算周期里面，誤差10%！ 4、有沒有必要用循環(huán)體？在1秒計算一次的情況下，即使不用循環(huán)體，也不會導(dǎo)致溢出問題。而且使用了循環(huán)體，還會導(dǎo)致精度降低，畢竟樣本少了。比如使用循環(huán)體最大值為100，不使用時為10000，哪個精度高？ 5、CPU使用率跳動問題。因為是測試，所以只有一個任務(wù)在運行，而且任務(wù)很簡單。

這個任務(wù)的執(zhí)行時間應(yīng)該是固定的才對，但即使是使用了后面的高精度計算方式，CPU使用率還是會跳動，這是為什么？ 第一，rt_kprintf函數(shù)執(zhí)行時間是不固定的，不固定在哪，比如要顯示的變量開始是1，后面是1000，因此它輸出的字符串不一樣，并且打印時間也不一樣，因為是查詢方式打印，所以差別很大！這就是我為什么推薦DMA打印的原因，未使用前是10%，使用后可能就是1%，甚至更低。 第二點，也是非常容易忽視的一點，插入的中斷執(zhí)行時間。 系統(tǒng)每隔1毫秒需要進入systick執(zhí)行一次（或者其他中斷執(zhí)行時間），如果說任務(wù)的執(zhí)行時間超過1毫秒，那么中間必然會先執(zhí)行中斷，再執(zhí)行任務(wù)，這樣一來，因為中斷的插入，導(dǎo)致時間不再那么準(zhǔn)確了。而當(dāng)你把打印的時間控制在 1 毫秒以內(nèi)，那么CPU使用率會變的非常穩(wěn)定。 第三：延時rt_thread_delay()函數(shù)本身的誤差，受到系統(tǒng)精度的影響，這個延時時間其實也不是固定的，會有一定的浮動。 6、10毫秒和100毫秒計算的差別？ 如果說你的任務(wù)執(zhí)行時間小于1毫秒，那么在10毫秒和100毫秒的計算差別不是很大，但是如果說計算周期變成了5毫秒，即使任務(wù)執(zhí)行時間小于1毫秒的情況下，計算值也是會在最大和最小之間來回跳動的。而執(zhí)行時間一旦超過1毫秒，那么10毫秒和100毫秒的計算就有較大的差別。 并且測試的時候，因為系統(tǒng)延時時間是10毫秒，而計算的時候也是10毫秒的周期，所以出現(xiàn)了比較詭異的事情，因為按理說延時10毫秒，任務(wù)執(zhí)行時間2.56毫秒，任務(wù)運行周期為12 毫秒（還記得前面所說的延時誤差嗎），CPU 使用率按理應(yīng)該是 21.3 左右，實際上卻是 6.5% 左右，相差太大了，這就非常奇怪了。而且如果更改執(zhí)行時間為1.5毫秒時（通過修改代碼修改執(zhí)行時間），發(fā)現(xiàn)計算值又正常了；而即使不修改執(zhí)行時間，修改計算時間為100毫秒，又正常了，這是怎么回事？ 通過深入分析發(fā)現(xiàn)，剛好在主任務(wù)延時10毫秒的時候，切換到了空閑任務(wù)進行空閑時間計算，執(zhí)行了9.4毫秒的時候，又切回到了主任務(wù)，所以計算時，得到了6.5%的計算值。 粗略表示如下所示：

通過這個分析，你應(yīng)該知道，計算CPU的時候，盡量不要使用和任務(wù)延時時間一樣的計算周期，否則會出現(xiàn)莫名其妙的事情；還有一點就是，任務(wù)的執(zhí)行周期 = 任務(wù)執(zhí)行時間 + 系統(tǒng)延時，而前面所介紹的計算方法只是粗略的表示，嚴(yán)格來說是有問題的。 7、終極問題，如何提高計算精度？通過以上分析，我們其實已經(jīng)知道了計算時的一些問題點。首先，計算周期問題，這個可以根據(jù)系統(tǒng)來確定，但是千萬要注意前面的提到的問題。如果說500毫秒計算周期可以滿足要求的話，就沒必要使用50毫秒，不然你會發(fā)現(xiàn)計算值跳動很大。 其次，時間精度問題，這個問題老生常談了，魚鷹建議是DWT，如果沒有，找一個定時器代替也是可以的。 最后是單位時間算力問題，為了保證精確，可以關(guān)閉中斷進行第一次計算，或者用短一點的時間，比如1毫秒得到一個算力，如果計算周期為100毫秒，那這個算力乘以100就行了。當(dāng)然如果系統(tǒng)時鐘不經(jīng)常變的話，也可以通過靜態(tài)方式先得到單位時間的算力，之后就以它為標(biāo)準(zhǔn)就可以了。這樣就不會有長時間關(guān)中斷的情況出現(xiàn)了。 但是計算算力的時候，千萬千萬要注意一點的是，C語言轉(zhuǎn)化為匯編代碼時，可能一樣的代碼，在不同的地方執(zhí)行時間是不一樣的（比如前面代碼的第一次計算和后面的計算，看似一樣，但實際上有較大差別，原因就在于執(zhí)行效率不一樣），這個涉及到寄存器比內(nèi)存效率更高的問題，所以計算算力時，可以把它封裝成一個函數(shù)，這樣，只要優(yōu)化等級不變，那么函數(shù)的執(zhí)行時間就可以認(rèn)為是確定的。