實戰(zhàn)經驗:stm32cubMX自動生成遇到的坑爹問題(Freertos)

我們來看這段程序:

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

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

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

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

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

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

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

我們跟蹤斷點，進入xSemaphoreGiveFromISR這個函數，看看是為什么就卡死了呢？

這是一個宏，實際上是調用了xQueueGiveFromISR這個函數，我們繼續(xù)跟進斷點

我們再單步進這個斷言：

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

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

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

在中斷服務函數里對標志進行判斷：

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

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

我們先讓代碼跑到初始化任務里，這是也就標記著OS已經啟動了。

然后再把斷點打到剛剛串口中斷接收的函數里。

然后單步進入看看

這時候我們發(fā)現，這個值已經不為NULL 了。

完美解決問題。

往期精彩

侃侃單片機的裸奔程序的框架

C語言將xxx.bin文件轉為數組

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

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

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

若覺得本次分享的文章對您有幫助，隨手點[在看]并轉發(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;">