實(shí)戰(zhàn)經(jīng)驗(yàn):stm32cubMX自動生成遇到的坑爹問題(Freertos)

我們來看這段程序:

上面這段程序，是串口2的中斷服務(wù)函數(shù)，在這里面完成的是接收一幀\r\n的數(shù)據(jù)。

這樣看來，這段程序保護(hù)得挺好，在串口在執(zhí)行接收的過程中不會被中斷打斷。但如果不注意的話，會被坑，我們來看下面這種情況。

如果是使用stm32cubeMX生成代碼，我們會看到在main.c中調(diào)用了串口初始化函數(shù)，在代碼編寫規(guī)則制定的區(qū)域定義了一個信號量，用于處理傳感器數(shù)據(jù)。

這樣看來沒毛病，編程思路都是對的，但是災(zāi)難就快要發(fā)生了，于是我們在msp初始化函數(shù)里添加這么一段。

如果在串口初始化過后，傳感器設(shè)備不通過串口發(fā)送數(shù)據(jù)，在未觸發(fā)串口接收中斷的時候，慶幸你的設(shè)備是可以正常開機(jī)運(yùn)行的。

如果在串口初始化過后，傳感器立馬就上報數(shù)據(jù)給MCU，這時候你會突然發(fā)現(xiàn)，設(shè)備開不了機(jī)了？What?這是為什么？

斷點(diǎn)調(diào)試后發(fā)現(xiàn)問題了，我們在這里發(fā)出了一個信號量，但信號量還沒有初始化吧？？

我們跟蹤斷點(diǎn)，進(jìn)入xSemaphoreGiveFromISR這個函數(shù)，看看是為什么就卡死了呢？

這是一個宏，實(shí)際上是調(diào)用了xQueueGiveFromISR這個函數(shù)，我們繼續(xù)跟進(jìn)斷點(diǎn)

我們再單步進(jìn)這個斷言：

結(jié)果發(fā)現(xiàn)死在這里了，這就說明我們并沒有創(chuàng)建隊(duì)列句柄。這就是stm32cubeMX給我們帶來的坑爹問題了，既要按照它的要求來定義和編寫代碼，又要防止這樣的問題產(chǎn)生。

那如何來解決這樣的問題呢？其實(shí)很簡單，加一個標(biāo)志變量就可以了，在os沒起來之前，我們不讓發(fā)送信號量的這句話執(zhí)行，等os起來以后，才讓發(fā)送信號量這句話執(zhí)行，否則會帶來災(zāi)難性的結(jié)果。

在os還沒有起來之前，我們還沒有使用數(shù)據(jù)，而且信號量還沒有創(chuàng)建，這時就不要使用os的信號量的發(fā)送和接收函數(shù)，于是想到一個解決辦法，定義一個is_use_os變量，在os未起來之前這個標(biāo)志為false，當(dāng)os起來以后，這個標(biāo)志就為true。

在中斷服務(wù)函數(shù)里對標(biāo)志進(jìn)行判斷：

這樣，當(dāng)os沒啟動之前，is_use_os這個變量為false，對應(yīng)的代碼不執(zhí)行，當(dāng)os啟動以后，is_use_of這個變量為true。

我們再來看os啟動以后，這個變量還是不是為NULL了?

我們先讓代碼跑到初始化任務(wù)里，這是也就標(biāo)記著OS已經(jīng)啟動了。

然后再把斷點(diǎn)打到剛剛串口中斷接收的函數(shù)里。

然后單步進(jìn)入看看

這時候我們發(fā)現(xiàn)，這個值已經(jīng)不為NULL 了。

完美解決問題。

往期精彩

侃侃單片機(jī)的裸奔程序的框架

C語言將xxx.bin文件轉(zhuǎn)為數(shù)組

數(shù)組和指針一道非常值得深思的筆試題

開源按鍵組件MultiButton支持菜單操作(事件驅(qū)動型)

第1期 | MultiButton，一個小巧簡單易用的事件驅(qū)動型按鍵驅(qū)動模塊

若覺得本次分享的文章對您有幫助，隨手點(diǎn)[在看]并轉(zhuǎn)發(fā)分享，也是對我的支持。

osoft YaHei", Arial, sans-serif;letter-spacing: 0.544px;white-space: normal;color: rgb(0, 0, 0);background-color: rgb(255, 255, 255);text-align: center;box-sizing: border-box !important;word-wrap: break-word !important;">