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