裸機(jī)編程切到RTOS之后任務(wù)之間的通信和同步永遠(yuǎn)是躲不開的坎。前面聊過隊(duì)列、信號(hào)量、互斥鎖、事件組這次把FreeRTOS任務(wù)通知Task Notification單獨(dú)拎出來講透。原因很簡單任務(wù)通知是FreeRTOS里最容易用錯(cuò)、也最容易被低估的一套機(jī)制。用好了它能替掉一大部分信號(hào)量和事件組的活兒還省內(nèi)存、省CPU時(shí)間用不好數(shù)據(jù)覆蓋、通知丟失、任務(wù)卡死排查起來能讓你懷疑人生。這篇是系列第7篇專注任務(wù)通知。我會(huì)從內(nèi)核實(shí)現(xiàn)、五個(gè)發(fā)送動(dòng)作、四種實(shí)戰(zhàn)模式講到中斷里的用法最后附上我在實(shí)際項(xiàng)目中踩過的坑和排查清單。適合正在學(xué)FreeRTOS的嵌入式開發(fā)者也適合那些已經(jīng)把任務(wù)通知用起來但偶爾覺得“哪里不對(duì)勁”的人。1. 任務(wù)通知到底是什么1.1 內(nèi)核里存的不是消息是一個(gè)32位數(shù)字任務(wù)通知在FreeRTOS里并不是一個(gè)獨(dú)立的內(nèi)核對(duì)象不需要像隊(duì)列那樣先創(chuàng)建隊(duì)列控制塊、再分配存儲(chǔ)區(qū)。它的本質(zhì)非常簡單每個(gè)任務(wù)的TCB任務(wù)控制塊里都內(nèi)置了兩個(gè)字段一個(gè)是32位的通知值 ulNotifiedValue一個(gè)是通知狀態(tài) ucNotifyState。這兩個(gè)字段在任務(wù)創(chuàng)建時(shí)就存在了不管你用不用它它都在那里不額外占堆內(nèi)存。當(dāng)你調(diào)用 xTaskNotify 往某個(gè)任務(wù)發(fā)通知時(shí)內(nèi)核做的事情其實(shí)非常直接找到目標(biāo)任務(wù)TCB改一改它的通知值再改一下通知狀態(tài)然后看這個(gè)任務(wù)是不是阻塞在等待通知上如果是就把它的狀態(tài)從Blocked切到Ready等待調(diào)度器調(diào)度它。這就引出了任務(wù)通知最大的優(yōu)勢(shì)沒有隊(duì)列復(fù)制數(shù)據(jù)的開銷沒有創(chuàng)建內(nèi)核對(duì)象的步驟操作的是每個(gè)任務(wù)自己TCB里的東西。我在Cortex-M4上做的簡單對(duì)比測(cè)試?yán)锶蝿?wù)通知發(fā)送一個(gè)喚醒信號(hào)的耗時(shí)大約是二進(jìn)制信號(hào)量的60%左右內(nèi)存節(jié)省更是直觀——一個(gè)信號(hào)量至少需要一個(gè)Queue_t結(jié)構(gòu)加上存儲(chǔ)區(qū)而任務(wù)通知什么都不用建。官方文檔給過一個(gè)數(shù)據(jù)任務(wù)通知比二進(jìn)制信號(hào)量快約45%RAM占用更低。我實(shí)測(cè)下來沒有45%那么夸張但在頻繁觸發(fā)的中斷里這個(gè)差距確實(shí)能感受到。1.2 任務(wù)通知、信號(hào)量、隊(duì)列、事件組的本質(zhì)差異很多新手會(huì)問已經(jīng)有了隊(duì)列和信號(hào)量為什么還要任務(wù)通知我的回答是任務(wù)通知解決的是一個(gè)非常特定的場(chǎng)景——一個(gè)任務(wù)向另一個(gè)明確的任務(wù)發(fā)送狀態(tài)變化這個(gè)信息。它適合一到一的通知只要數(shù)據(jù)量不超過一個(gè)整數(shù)并且你不需要讓多個(gè)任務(wù)同時(shí)收到這個(gè)消息。特性任務(wù)通知二進(jìn)制信號(hào)量隊(duì)列事件組數(shù)據(jù)長度32位整數(shù)無數(shù)據(jù)任意字節(jié)最多24/8位標(biāo)志接收者數(shù)量1個(gè)必須指定目標(biāo)任務(wù)多個(gè)任務(wù)可等待多個(gè)任務(wù)可讀寫多個(gè)任務(wù)可等待是否需要?jiǎng)?chuàng)建對(duì)象不需要需要需要需要ISR中發(fā)送支持支持支持支持阻塞接收支持支持支持支持?jǐn)?shù)據(jù)是否排隊(duì)否覆蓋或保留最新值是多次give會(huì)累積是FIFO僅狀態(tài)位典型RAM開銷0使用TCB內(nèi)字段約80~120字節(jié)隊(duì)列頭存儲(chǔ)區(qū)事件組對(duì)象這個(gè)表里最值得注意的兩行是接收者數(shù)量和數(shù)據(jù)是否排隊(duì)。任務(wù)通知發(fā)給誰由參數(shù)里的任務(wù)句柄直接決定無法像信號(hào)量那樣讓多個(gè)任務(wù)競(jìng)爭同一個(gè)資源任務(wù)通知保存的永遠(yuǎn)是最新的一個(gè)整數(shù)值不會(huì)像隊(duì)列那樣把多次發(fā)送的值按順序存起來。理解不了這兩點(diǎn)后面用起來必踩坑。2. 任務(wù)通知API全解析與選型思路2.1 八個(gè)核心API一次性說清楚任務(wù)通知的API看著多但其實(shí)可以分成四組發(fā)送組、接收組、ISR組、狀態(tài)清理組。我平時(shí)最常用的就下面這幾個(gè)全部列成表方便對(duì)照。API作用關(guān)鍵參數(shù)說明xTaskNotify(任務(wù)句柄, 通知值, eAction)向指定任務(wù)發(fā)送通知eAction決定如何修改通知值xTaskNotifyGive(任務(wù)句柄)等價(jià)于xTaskNotify(句柄, 0, eIncrement)通知值加1最常用的給信號(hào)xTaskNotifyWait(清除位入口, 清除位出口, 輸出值指針, 超時(shí))阻塞等待通知可同時(shí)讀取/清除通知值可同時(shí)等待多個(gè)標(biāo)志位ulTaskNotifyTake(是否清零, 超時(shí))阻塞等待通知取走計(jì)數(shù)值pdTRUE清零取出pdFALSE遞減xTaskNotifyFromISR(句柄, 值, eAction, 高優(yōu)先級(jí)任務(wù)標(biāo)記)中斷版發(fā)送返回是否需要上下文切換vTaskNotifyGiveFromISR(句柄, 高優(yōu)先級(jí)任務(wù)標(biāo)記)中斷版Give用法與FromISR版本一致xTaskNotifyStateClear(句柄)清除任務(wù)的通知狀態(tài)讓ucNotifyState回到未通知狀態(tài)xTaskNotifyIndexed系列使用通知數(shù)組新版功能需要開啟configTASK_NOTIFICATION_ARRAY_ENTRIES這里特別說明一下xTaskNotifyGive和ulTaskNotifyTake這對(duì)組合。xTaskNotifyGive每次調(diào)用讓目標(biāo)任務(wù)的通知值加1ulTaskNotifyTake則把通知值取走——如果第二個(gè)參數(shù)傳pdTRUE取走時(shí)通知值清零并把原值作為返回值如果傳pdFALSE通知值減1。這就相當(dāng)于一個(gè)不需要?jiǎng)?chuàng)建對(duì)象、計(jì)數(shù)上限為2^32的計(jì)數(shù)信號(hào)量只是接收方變成了固定的那個(gè)任務(wù)。2.2 eAction五種動(dòng)作每種都是不同語義xTaskNotify函數(shù)里的eAction參數(shù)是整個(gè)任務(wù)通知的精華它決定了這次通知到底要怎么改變目標(biāo)任務(wù)的通知值。新手最容易在這里犯迷糊我把這五種動(dòng)作拆開講。eNoAction只喚醒任務(wù)不修改通知值。適合那種我就想叫他一下的場(chǎng)景比如通知另一個(gè)任務(wù)去做一次輪詢具體做什么由別的條件決定。eSetBits按位或。通知值 舊值 | 新值。這是把任務(wù)通知當(dāng)事件組用的關(guān)鍵動(dòng)作。eIncrement通知值加1。xTaskNotifyGive的內(nèi)部實(shí)現(xiàn)就是這個(gè)做計(jì)數(shù)信號(hào)量時(shí)用。eSetValueWithOverwrite直接覆蓋寫。通知值 新值。舊數(shù)據(jù)直接丟掉無論目標(biāo)任務(wù)是否已讀走上次的值。適合傳遞最新溫度讀數(shù)這種只要最新的數(shù)據(jù)。eSetValueWithoutOverwrite如果通知值當(dāng)前為非零有未讀通知本次寫入失敗返回pdFAIL如果通知值為0則寫入新值。這個(gè)有點(diǎn)像長度為1的隊(duì)列的非阻塞嘗試寫。我做過一個(gè)傳感器數(shù)據(jù)采集項(xiàng)目需要把ADC采樣結(jié)果傳給處理任務(wù)用的就是eSetValueWithOverwrite。因?yàn)閭鞲衅鞑蓸又芷诒热蝿?wù)處理周期快中間丟掉幾幀完全沒關(guān)系只要拿到最新值就行。而有個(gè)同事在通信協(xié)議解析里用了這個(gè)動(dòng)作結(jié)果因?yàn)橹虚g某幀還沒被處理就被新幀覆蓋直接導(dǎo)致協(xié)議解析錯(cuò)位——選哪個(gè)動(dòng)作取決于你的業(yè)務(wù)能不能接受舊數(shù)據(jù)被丟。2.3 阻塞、超時(shí)與立即返回的三種等待狀態(tài)任務(wù)通知的接收函數(shù)都帶超時(shí)參數(shù)這個(gè)參數(shù)的單位是Tick。你可以傳0表示不等待立刻檢查一次傳portMAX_DELAY表示無限期等下去直到有通知或者用pdMS_TO_TICKS(毫秒)把毫秒轉(zhuǎn)成Tick。具體到調(diào)用行為任務(wù)進(jìn)入xTaskNotifyWait或ulTaskNotifyTake后如果通知值條件不滿足任務(wù)會(huì)被掛到Blocked狀態(tài)不占CPU。這時(shí)候有兩種方式能喚醒它一是別的任務(wù)或中斷往它發(fā)通知二是超時(shí)時(shí)間到了。被通知喚醒后函數(shù)返回pdPASS超時(shí)喚醒返回pdFAIL取函數(shù)返回值是pdFAIL。這里有個(gè)容易忽略的細(xì)節(jié)任務(wù)通知的等待是只要通知值滿足條件就立刻返回但它不會(huì)像隊(duì)列那樣自動(dòng)把消息彈出。你用xTaskNotifyWait接收時(shí)拿到的是通知值的完整快照清除哪些位、怎么處理值全由你自己在代碼里控制。所以任務(wù)通知的靈活性高但自動(dòng)管理程度低出錯(cuò)時(shí)也更難看出來。3. 四種實(shí)戰(zhàn)模式把任務(wù)通知用出花來3.1 模式一輕量級(jí)信號(hào)量替代二進(jìn)制/計(jì)數(shù)信號(hào)量這是任務(wù)通知最基礎(chǔ)的用法。生產(chǎn)者任務(wù)或中斷調(diào)用xTaskNotifyGive消費(fèi)者任務(wù)調(diào)用ulTaskNotifyTake來等待。直接上代碼。/* 生產(chǎn)者任務(wù)采集完成通知處理任務(wù) */ void vProducerTask(void *pvParameters) { for (;;) { /* 模擬采集耗時(shí) */ vTaskDelay(pdMS_TO_TICKS(100)); /* 通知處理任務(wù)通知值 1 */ xTaskNotifyGive(xHandlerTaskHandle); } } /* 消費(fèi)者任務(wù)等待采集完成信號(hào) */ void vHandlerTask(void *pvParameters) { uint32_t ulSignalCount; for (;;) { /* 阻塞等待通知值清零并返回原值 */ ulSignalCount ulTaskNotifyTake(pdTRUE, portMAX_DELAY); /* 處理一次采集結(jié)果 */ vProcessData(); /* 如果 ulSignalCount 1說明生產(chǎn)者已經(jīng)積累了多個(gè)信號(hào) */ if (ulSignalCount 1) { /* 需要把積壓的處理完防止信號(hào)堆積 */ for (uint32_t i 1; i ulSignalCount; i) { vProcessData(); } } } }注意順手看了一眼ulTaskNotifyTake的返回值這是良好習(xí)慣。雖然大多數(shù)場(chǎng)景下你只關(guān)心被喚醒了但返回值能告訴你這次喚醒積累了多少個(gè)信號(hào)幫助判斷生產(chǎn)者是不是已經(jīng)跑得比消費(fèi)者快了。3.2 模式二輕量級(jí)事件組用eSetBits置位當(dāng)你想讓一個(gè)任務(wù)等待多個(gè)事件中的某些事件發(fā)生了但又不希望為此創(chuàng)建一個(gè)完整的事件組對(duì)象時(shí)可以用eSetBits配合xTaskNotifyWait。/* 任務(wù)A準(zhǔn)備數(shù)據(jù)完成 */ xTaskNotify(xEventTaskHandle, EVENT_DATA_READY, eSetBits); /* 任務(wù)B外設(shè)初始化完成 */ xTaskNotify(xEventTaskHandle, EVENT_PERIPH_OK, eSetBits); /* 等待事件的任務(wù)兩種事件都到位才開始工作 */ uint32_t ulNotifiedValue; if (xTaskNotifyWait(0x00, 0x00, ulNotifiedValue, pdMS_TO_TICKS(500)) pdPASS) { if ((ulNotifiedValue (EVENT_DATA_READY | EVENT_PERIPH_OK)) (EVENT_DATA_READY | EVENT_PERIPH_OK)) { /* 所有條件滿足 */ vStartWork(); } } else { /* 超時(shí)至少有一個(gè)條件未滿足 */ vLogError(); }這里有兩個(gè)隱藏重點(diǎn)。第一xTaskNotifyWait的第一個(gè)參數(shù)是進(jìn)入時(shí)清除位第二個(gè)參數(shù)是退出時(shí)清除位它們?cè)谑录囊淮涡韵M(fèi)語義里非常關(guān)鍵。如果你希望事件標(biāo)志被讀取后立即清零就把對(duì)應(yīng)位放在第二個(gè)參數(shù)里比如xTaskNotifyWait(0, EVENT_DATA_READY | EVENT_PERIPH_OK, value, timeout)這樣退出函數(shù)后這兩個(gè)位自動(dòng)清零。第二任務(wù)通知做事件組時(shí)依然只能有一個(gè)任務(wù)等待多個(gè)任務(wù)同時(shí)等同一組事件時(shí)老老實(shí)實(shí)用事件組。3.3 模式三4字節(jié)消息傳遞WithOverwrite實(shí)現(xiàn)最新值傳遞任務(wù)通知雖然只有一個(gè)32位值但用來傳遞最新狀態(tài)是完全夠用的。比如溫控系統(tǒng)里傳感器任務(wù)每隔50ms讀一次溫度控制任務(wù)希望拿到最新的溫度值但處理一幀控制計(jì)算可能要100ms。用隊(duì)列的話要么存很多過時(shí)數(shù)據(jù)要么用隊(duì)列的覆蓋寫特性xQueueOverwrite——任務(wù)通知的eSetValueWithOverwrite干的就是這件事。/* 傳感器任務(wù)每50ms讀一次發(fā)送最新溫度 */ int16_t sTemperature vReadSensor(); xTaskNotify(xControllerTaskHandle, (uint32_t)sTemperature, eSetValueWithOverwrite); /* 控制任務(wù)循環(huán)讀取最新溫度并計(jì)算控制量 */ uint32_t ulTemperature; if (xTaskNotifyWait(0xFFFFFFFF, 0xFFFFFFFF, ulTemperature, pdMS_TO_TICKS(200)) pdPASS) { int16_t sTemp (int16_t)ulTemperature; vCalcControlOutput(sTemp); }我特意把xTaskNotifyWait的兩個(gè)清位參數(shù)都寫成0xFFFFFFFF表示進(jìn)入函數(shù)時(shí)把通知值清零這樣每次讀走的值必然是從上次讀走到現(xiàn)在寫入的最新值。如果你不這么做通知值會(huì)一直保留舊數(shù)據(jù)你會(huì)陷入為什么值一直沒變的困惑。3.4 模式四中斷到任務(wù)最簡單的ISR通知版本中斷里發(fā)任務(wù)通知是最常見的用法按鍵、定時(shí)器、DMA傳輸完成、UART接收空閑統(tǒng)統(tǒng)可以把事件發(fā)生了通過任務(wù)通知扔給任務(wù)去處理減少中斷里做慢速邏輯的時(shí)間。/* 中斷服務(wù)函數(shù)外部按鍵按下 */ void EXTI_IRQHandler(void) { BaseType_t xHigherPriorityTaskWoken pdFALSE; /* 清除中斷標(biāo)志 */ CLEAR_EXTI_FLAG(); /* 發(fā)送任務(wù)通知計(jì)數(shù)模式 */ vTaskNotifyGiveFromISR(xKeyTaskHandle, xHigherPriorityTaskWoken); /* 如果喚醒了高優(yōu)先級(jí)任務(wù)需要進(jìn)行上下文切換 */ portYIELD_FROM_ISR(xHigherPriorityTaskWoken); }這個(gè)xHigherPriorityTaskWoken是ISR版API的經(jīng)典參數(shù)等會(huì)第4節(jié)專門展開。簡單理解它告訴內(nèi)核有沒有喚醒了比當(dāng)前被中斷任務(wù)更高優(yōu)先級(jí)的任務(wù)如果有中斷退出時(shí)不能回到原任務(wù)繼續(xù)跑而應(yīng)該直接切到那個(gè)高優(yōu)先級(jí)任務(wù)。portYIELD_FROM_ISR實(shí)際執(zhí)行的行為在Cortex-M上就是觸發(fā)一次PendSV調(diào)度器會(huì)重新選一次任務(wù)。4. 中斷環(huán)境下的任務(wù)通知細(xì)節(jié)4.1 為什么ISR版本必須有xHigherPriorityTaskWoken很多剛從裸機(jī)轉(zhuǎn)RTOS的人會(huì)忽略ISR版本API的返回值處理直接不檢查就往下跑。這在大多時(shí)候看起來正常但一旦發(fā)生中斷喚醒了高優(yōu)先級(jí)任務(wù)系統(tǒng)不會(huì)立刻切換到那個(gè)任務(wù)而是回到被中斷的任務(wù)繼續(xù)執(zhí)行。表現(xiàn)就是響應(yīng)變慢嚴(yán)重的會(huì)破壞實(shí)時(shí)性尤其在高優(yōu)先級(jí)任務(wù)是控制類、保護(hù)類任務(wù)時(shí)這個(gè)延遲可能是致命的。正確姿勢(shì)是上面那段代碼的寫法先定義一個(gè)局部變量xHigherPriorityTaskWoken并初始化為pdFALSE傳入ISR版API調(diào)用后立即判斷該變量如果為pdTRUE調(diào)用portYIELD_FROM_ISR觸發(fā)一次調(diào)度。有一個(gè)細(xì)節(jié)很多人不知道xHigherPriorityTaskWoken定義為局部變量是必須的不能用一個(gè)全局變量初始化為pdFALSE就反復(fù)傳進(jìn)去。因?yàn)槊看沃袛嗾{(diào)用的上下文都是獨(dú)立的全局變量可能在并發(fā)場(chǎng)景下出現(xiàn)競(jìng)態(tài)導(dǎo)致漏掉調(diào)度或者重復(fù)調(diào)度。這是我在審查代碼時(shí)經(jīng)常發(fā)現(xiàn)的問題。4.2 什么時(shí)候用xTaskNotifyFromISR什么時(shí)候用vTaskNotifyGiveFromISR這兩個(gè)函數(shù)的區(qū)別其實(shí)就是eAction的區(qū)別。vTaskNotifyGiveFromISR內(nèi)部就是xTaskNotifyFromISR寫成eIncrement動(dòng)作所以只需要通知值加1用vTaskNotifyGiveFromISR代碼簡短。需要置位、覆蓋寫、無覆蓋寫時(shí)用xTaskNotifyFromISR配合對(duì)應(yīng)的eAction。/* 中斷里置事件位 */ xTaskNotifyFromISR(xTaskHandle, BIT_TIMER_EXPIRED, eSetBits, xHigherPriorityTaskWoken); /* 中斷里傳最新值 */ xTaskNotifyFromISR(xTaskHandle, (uint32_t)ulStatus, eSetValueWithOverwrite, xHigherPriorityTaskWoken);另外注意ISR版本的API不能在臨界區(qū)里反復(fù)調(diào)用太多次雖然FreeRTOS的ISR版本API內(nèi)部會(huì)自己處理臨界區(qū)但如果你在中斷里循環(huán)通知幾百個(gè)任務(wù)中斷時(shí)間會(huì)變長。比如你要通知所有任務(wù)系統(tǒng)要休眠了用一個(gè)for循環(huán)調(diào)用幾百次每次都有進(jìn)出臨界區(qū)的開銷這種情況下不如用一個(gè)事件組廣播或者用一個(gè)全局標(biāo)志軟定時(shí)器回調(diào)的方式。4.3 中斷里用任務(wù)通知替代二值信號(hào)量的注意點(diǎn)傳統(tǒng)做法里ISR給任務(wù)發(fā)信號(hào)是用xSemaphoreGiveFromISR任務(wù)用xSemaphoreTake等待。用任務(wù)通知替代后代碼確實(shí)精簡了但有一個(gè)語義差異要心里有數(shù)二值信號(hào)量在任務(wù)持有信號(hào)量時(shí)再give一次信號(hào)量保持滿狀態(tài)不會(huì)變2而任務(wù)通知加1模式多次give會(huì)累積成大于1的計(jì)數(shù)值。這說明什么如果你的ISR和任務(wù)是一一對(duì)應(yīng)的事件通知計(jì)數(shù)累積反而不是壞事任務(wù)可以通過返回值的數(shù)值判斷ISR發(fā)生了多少次但如果你的本意是只發(fā)一次信號(hào)ISR里頻繁觸發(fā)導(dǎo)致計(jì)數(shù)不斷累加任務(wù)處理時(shí)就要用ulTaskNotifyTake(pdFALSE, ...)配合循環(huán)把計(jì)數(shù)值消化完否則通知計(jì)數(shù)會(huì)越積越多。我見過一個(gè)項(xiàng)目按鍵中斷用任務(wù)通知給任務(wù)發(fā)信號(hào)用戶快速連按三下通知值變成3任務(wù)只處理了一次剩下兩次信號(hào)殘留導(dǎo)致后面“無故喚醒”就是這個(gè)原因。5. 配置宏、調(diào)試技巧和常見坑5.1 這些配置宏不打開API都不能用任務(wù)通知的大部分功能默認(rèn)就是可用的因?yàn)閏onfigUSE_TASK_NOTIFICATIONS默認(rèn)是1。但有幾個(gè)相關(guān)的宏你需要確認(rèn)configUSE_TASK_NOTIFICATIONS總開關(guān)設(shè)為1啟用任務(wù)通知。某些廠商提供的庫可能默認(rèn)關(guān)閉用之前查一下。INCLUDE_xTaskNotifyWait如果要使用xTaskNotifyWait這個(gè)宏必須為1否則API不會(huì)編譯。INCLUDE_xTaskNotifyStateClear使用狀態(tài)清理時(shí)需要。configTASK_NOTIFICATION_ARRAY_ENTRIES如果使用較新的xTaskNotifyIndexed系列API通知數(shù)組需要把它設(shè)為大于0最常見的就是設(shè)為1代表每個(gè)任務(wù)有1個(gè)通知槽位。設(shè)為N時(shí)每個(gè)任務(wù)TCB里就有N個(gè)通知值你可以給一個(gè)任務(wù)的不同用途發(fā)不同類型的通知彼此不干擾。新版FreeRTOS V10.4之后任務(wù)通知數(shù)組已經(jīng)是標(biāo)準(zhǔn)功能了我用它做過一個(gè)很舒服的場(chǎng)景同一個(gè)任務(wù)掛兩個(gè)通知槽槽0接收外設(shè)中斷的數(shù)據(jù)就緒信號(hào)槽1接收管理命令的參數(shù)更新信號(hào)兩個(gè)互不干擾。不過老項(xiàng)目的代碼如果用的舊APIxTaskNotify系列是操作槽0的行為不受影響兼容性沒問題。5.2 調(diào)試任務(wù)通知狀態(tài)的辦法任務(wù)通知是藏在TCB里的狀態(tài)不像隊(duì)列能用隊(duì)列統(tǒng)計(jì)函數(shù)看到隊(duì)列中有多少消息。調(diào)試起來更費(fèi)勁我一般用三個(gè)辦法。第一個(gè)辦法是看返回值。xTaskNotifyWait、ulTaskNotifyTake的返回值直接告訴你成功還是超時(shí)配合通知值輸出參數(shù)基本能判斷出發(fā)送和接收是否匹配。第二個(gè)辦法是查看任務(wù)狀態(tài)。如果任務(wù)卡在ulTaskNotifyTake用vTaskList / vTaskGetRunTimeStats之類的手段能看到這個(gè)任務(wù)處于Blocked狀態(tài)且阻塞原因是等待通知。在串口調(diào)試終端里定期打印所有任務(wù)狀態(tài)你會(huì)很清楚地看到哪個(gè)任務(wù)在等什么。第三個(gè)辦法是借助FreeRTOS內(nèi)核的斷言和Trace工具。比如可以臨時(shí)打開configUSE_TRACE_FACILITY或者掛接vApplicationStackOverflowHook、vApplicationMallocFailedHook之類的鉤子看是不是任務(wù)棧不夠或者消息處理不及時(shí)導(dǎo)致的溢出。注意不推薦一上來就懷疑內(nèi)核問題任務(wù)通知這種機(jī)制本身在FreeRTOS里非常成熟99%的情況問題出在應(yīng)用層的動(dòng)作選型或標(biāo)志清除邏輯上。5.3 經(jīng)典踩坑清單這些問題我全遇到過下面這個(gè)表是我自己和身邊同事在任務(wù)通知上踩過的典型坑每條都有實(shí)際項(xiàng)目背景。錯(cuò)誤現(xiàn)象根因正確解法通知值一直在漲任務(wù)處理不過來使用了eIncrement且接收端沒有及時(shí)把計(jì)數(shù)消化合理設(shè)置超時(shí)或用ulTaskNotifyTake(pdTRUE, ...)一次性清零通知值明明是0發(fā)通知卻失敗eSetValueWithoutOverwrite語義非0值存在時(shí)會(huì)拒絕寫入先調(diào)用xTaskNotifyStateClear清狀態(tài)或改用eSetValueWithOverwrite任務(wù)沒有被喚醒但通知值已經(jīng)變了任務(wù)沒有進(jìn)入阻塞態(tài)就收到了通知通知狀態(tài)停留在已通知用xTaskNotifyWait的入口清位參數(shù)把舊值清掉或用xTaskNotifyStateClear懸空任務(wù)句柄系統(tǒng)崩潰目標(biāo)任務(wù)被刪除后仍往它的句柄發(fā)通知?jiǎng)h除任務(wù)前置空句柄或使用任務(wù)通知數(shù)組后注意索引越界ISR里調(diào)用了帶阻塞的API誤以為任務(wù)通知的ISR版能像普通版一樣等待ISR環(huán)境只能發(fā)不能等需要等就把數(shù)據(jù)丟給任務(wù)去處理多個(gè)任務(wù)同時(shí)調(diào)用ulTaskNotifyTake只有一個(gè)能收到任務(wù)通知是單對(duì)單的定向機(jī)制多方等待請(qǐng)使用信號(hào)量、隊(duì)列或事件組這里再展開說一個(gè)最容易陰溝翻船的xTaskNotifyWait的入口清除位和出口清除位。很多人看到API原型時(shí)以為這兩個(gè)參數(shù)是收什么通知和清什么通知其實(shí)它們的作用是進(jìn)入等待時(shí)把通知值中對(duì)應(yīng)位先清掉退出時(shí)再把通知值中對(duì)應(yīng)位清掉。如果你寫的代碼是xTaskNotifyWait(0x01, 0x00, ...)那進(jìn)入時(shí)bit0直接被清零了你這個(gè)bit0的事件標(biāo)志就永遠(yuǎn)等不到了。我在用任務(wù)通知模擬事件組時(shí)被這個(gè)坑過一次排查了大半天最后打印通知值才發(fā)現(xiàn)是這個(gè)原因。6. 什么時(shí)候不該用任務(wù)通知6.1 一對(duì)多廣播場(chǎng)景事件組才是正解任務(wù)通知的接收方由任務(wù)句柄唯一確定無法實(shí)現(xiàn)當(dāng)某個(gè)事件發(fā)生時(shí)讓所有等待它的任務(wù)都醒來。如果需要多個(gè)任務(wù)同時(shí)響應(yīng)一個(gè)事件比如多個(gè)任務(wù)都要在系統(tǒng)休眠命令發(fā)出后各自保存狀態(tài)請(qǐng)用事件組xEventGroupSetBits配合xEventGroupWaitBits讓每個(gè)任務(wù)獨(dú)立等待同一個(gè)事件位。6.2 超過4字節(jié)的數(shù)據(jù)傳輸用隊(duì)列或流緩沖區(qū)任務(wù)通知能裝下的數(shù)據(jù)量就一個(gè)機(jī)器字長多數(shù)平臺(tái)32位。你要傳一個(gè)結(jié)構(gòu)體、一包字節(jié)流、一組浮點(diǎn)數(shù)任務(wù)通知直接出局。哪怕你覺得我把它拆成兩個(gè)通知也別這么干拆開傳會(huì)有中間狀態(tài)接收方可能在收到一半時(shí)被調(diào)度走導(dǎo)致數(shù)據(jù)錯(cuò)亂。這種場(chǎng)景用隊(duì)列、流緩沖區(qū)Stream Buffer或者消息緩沖區(qū)Message Buffer更合適它們有完整的復(fù)制和排隊(duì)機(jī)制。6.3 FIFO場(chǎng)景任務(wù)通知沒有排隊(duì)能力隊(duì)列的典型價(jià)值是FIFO先發(fā)進(jìn)去的先被取出來消息按順序處理。任務(wù)通知保存的是最新值后來的覆蓋先來的完全不具備順序性。如果業(yè)務(wù)邏輯要求發(fā)10次就要處理10次按順序來別用任務(wù)通知的覆蓋寫用計(jì)數(shù)模式計(jì)數(shù)還可以如果還要攜帶不同的數(shù)據(jù)內(nèi)容就必須上隊(duì)列。6.4 共享計(jì)數(shù)型信號(hào)量場(chǎng)景多個(gè)任務(wù)競(jìng)爭同一信號(hào)量二值信號(hào)量或者計(jì)數(shù)信號(hào)量的經(jīng)典用途是多個(gè)任務(wù)競(jìng)爭一個(gè)資源使用權(quán)比如三個(gè)任務(wù)搶一個(gè)串口外設(shè)誰先take到誰發(fā)送。任務(wù)通知做不到這種競(jìng)爭關(guān)系因?yàn)樗l(fā)通知時(shí)已經(jīng)明確指定了目標(biāo)任務(wù)的句柄不可能讓多個(gè)任務(wù)去搶同一個(gè)通知值。這種場(chǎng)景用真正的信號(hào)量配合互斥鎖做資源保護(hù)別用任務(wù)通知硬湊。我在一個(gè)數(shù)據(jù)采集網(wǎng)關(guān)項(xiàng)目里做過一次整體替換把原來用的3個(gè)二值信號(hào)量、1個(gè)事件組全部改成任務(wù)通知同時(shí)刪除對(duì)應(yīng)的隊(duì)列對(duì)象最后內(nèi)存占用下降了將近1KB所有功能測(cè)試通過。但另一個(gè)項(xiàng)目里我試圖把5個(gè)等待同一啟動(dòng)命令的任務(wù)全部改成任務(wù)通知結(jié)果代碼寫得極其繞最后換回事件組兩行搞定。任務(wù)通知適合的是明確的一對(duì)一通知任何企圖共享和廣播的用法都是在跟自己過不去。寫在最后做嵌入式這些年我見過太多把任務(wù)通知用成玄學(xué)的代碼通知值莫名其妙變大、任務(wù)偶爾卡死、中斷發(fā)通知后任務(wù)不響應(yīng)。每次排查到最后幾乎都是同一個(gè)原因——沒有把通知當(dāng)成一種有明確語義的同步原語來用而是把它當(dāng)成了一個(gè)神秘的黑盒子。它是FreeRTOS里最高效的通信方式之一但這種高效是有前提的你要清楚地知道自己在用哪種動(dòng)作、清除哪些標(biāo)志、是否允許覆蓋、接收方是誰。最后分享一個(gè)我一直在用的小技巧在每個(gè)接收任務(wù)里把xTaskNotifyWait返回后的通知值打印到調(diào)試串口形成一個(gè)歷史記錄。任務(wù)通知最大的調(diào)試難點(diǎn)就是看不見中間狀態(tài)這個(gè)習(xí)慣能幫你把無形變成有形。等你在實(shí)際項(xiàng)目里跑過一輪信號(hào)量替換成任務(wù)通知的優(yōu)化之后你會(huì)回來認(rèn)同那句話任務(wù)通知不是萬能的但用對(duì)了地方它是整個(gè)FreeRTOS里最順手的一把刀。