01

前言

STM32上hello world，說白了就是使用串口向PC上的上位機(jī)軟件或者串口調(diào)試助手發(fā)送字符串。

串口的使用方法百度一下就能知道了，簡單來說就是下面這樣。

uint8_t buff[BUFF_SIZE];//定義一個(gè)緩存數(shù)組 HAL_UART_Receive_IT(&huart1, (uint8_t *)buff, BUFF_SIZE);//打開串口接收中斷

串口中斷打開之后，當(dāng)接收到BUFF_SIZE個(gè)數(shù)據(jù)后就會(huì)進(jìn)入

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart);

然后我們就可以在上面這個(gè)函數(shù)下操作收到的數(shù)據(jù)啦，簡單方便快捷。當(dāng)然實(shí)際操作一遍后大家就會(huì)發(fā)現(xiàn)，這個(gè)程序只能進(jìn)入一次中斷，之后就再也收不到數(shù)據(jù)了，這是因?yàn)镠AL庫在每次進(jìn)入串口中斷時(shí)都會(huì)把這個(gè)中斷關(guān)閉，所以我們處理完數(shù)據(jù)之后，要重新打開中斷。

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart){ //處理數(shù)據(jù)... HAL_UART_Receive_IT(&huart1, (uint8_t *)buff, BUFF_SIZE);}

而發(fā)送數(shù)據(jù)呢，就用

HAL_UART_Transmit(&huart1, (uint8_t *)buff, BUFF_SIZE，0xffff);

知道串口怎么用了，我們就可以想辦法hello world。重定向printf的方法百度一搜一大片，fputc這個(gè)函數(shù)是_weak定義的，自己寫一個(gè)就可以覆蓋過去了。

int fputc(int ch, FILE *f){ HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1，0xffff); return ch;}

然后寫下終極代碼，完美。

printf("hello world ");

上面的內(nèi)容百度上可以找到很多很多文章，而且講的又詳細(xì)又生動(dòng)，這里我只是帶大家復(fù)習(xí)一下，如果你能夠熟練掌握上面的內(nèi)容了，那接下來就可以進(jìn)入正題，看看如何變得更優(yōu)雅。

02

變優(yōu)雅第一步

我們實(shí)際運(yùn)行這個(gè)代碼，發(fā)現(xiàn)在串口接收幾次數(shù)據(jù)之后，又突然會(huì)再也接收不到數(shù)據(jù)了。因?yàn)榧词鼓阌浀迷谔幚硗陻?shù)據(jù)之后及時(shí)打開了接收中斷，開啟中斷的的函數(shù)也不一定總是能正確開啟，我一直覺得這是HAL庫的一個(gè)坑。我翻了很久的百度，終于找到一種解決方案。

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart){ //處理數(shù)據(jù)... int i=0; while(HAL_UART_Receive_IT(&huart1,(uint8_t *)&buff,1) != HAL_OK ) { i++; if(i>10000) { huart6.RxState=HAL_UART_STATE_READY; __HAL_UNLOCK(&huart1); i=0; } }}

事情就是這么神奇，單單執(zhí)行一句開中斷不一定能成功的，開完還要檢查一下是不是真的開成功了，不行的話再打開一下試試，試了10000次還不行，生氣了，強(qiáng)制開。

03

變優(yōu)雅第二步

百度上看到的串口教程，大家都是用下面這個(gè)函數(shù)

HAL_UART_Transmit(&huart1, (uint8_t *)buff, BUFF_SIZE，0xffff);

就是說，CPU找到串口，給串口huart1安排好任務(wù)：

“從這個(gè)buff的地址開始，挨個(gè)發(fā)BUFF_SIZE個(gè)數(shù)據(jù)，我就在邊上守著，等你0XFFFF的時(shí)間，干不完就別給我干了！”

其實(shí)看到這么個(gè)代碼我是很生氣的，CPU作為大領(lǐng)導(dǎo)，員工干活的時(shí)候不去喝咖啡？在邊上守著？這成何體統(tǒng)？

優(yōu)雅的辦法肯定是CPU交代好任務(wù)之后，轉(zhuǎn)身去忙自己的事情了，而串口接到命令之后，默默完成任務(wù)，然后再跟CPU匯報(bào)一下。所以我們不光接收要用中斷，發(fā)送也要用中斷。

所以我們要用下面這個(gè)串口中斷發(fā)送的函數(shù)

HAL_UART_Transmit_IT(&huart1, (uint8_t *)buff, BUFF_SIZE);

這個(gè)函數(shù)會(huì)使能發(fā)送中斷，然后挨個(gè)發(fā)數(shù)據(jù)，發(fā)完之后執(zhí)行一個(gè)回調(diào)函數(shù)，然后自己關(guān)掉發(fā)送中斷。一條龍服務(wù)，用戶什么都不用管。如果用戶想多管閑事，可以把代碼寫在回調(diào)函數(shù)里。

于是乎，我們優(yōu)雅地把串口發(fā)送改用中斷的方式，那我們重定向的fputc可以寫成

int fputc(int ch, FILE *f){ HAL_UART_Transmit_IT(&huart1, (uint8_t *)&ch, 1); return ch;}

這樣我們可以用先前的方法快樂地hello world了。

printf("hello world ");

愛動(dòng)手的小伙伴一旦嘗試一下就會(huì)發(fā)現(xiàn)，這***的文章里的代碼都沒法跑，hello world發(fā)了個(gè)h就不發(fā)了？？？

那么這是為什么呢？我們來分析一下這個(gè)程序執(zhí)行的過程。printf里是把格式化好的字符一個(gè)一個(gè)交給fputc發(fā)送的，當(dāng)發(fā)送第一個(gè)字符'h'時(shí)，串口處于空閑狀態(tài)，能夠正確地使能串口發(fā)送中斷。因此，字符'h'正確發(fā)送。

但我們注意到，CPU給串口安排好工作后，并沒有在原地等待，而是去執(zhí)行后續(xù)的任務(wù)了，那后續(xù)的任務(wù)就是發(fā)送字符'e'。CPU再次來到fputc函數(shù)內(nèi)，再次執(zhí)行

HAL_UART_Transmit_IT(&huart1, (uint8_t *)&ch, 1);

由于CPU的運(yùn)行速度比串口快得多，此時(shí)串口還沒有完成先前的字符'h'的發(fā)送任務(wù)，串口處于忙碌的狀態(tài)，因此現(xiàn)在是無法正確打開串口發(fā)送中斷的，因此字符'e'發(fā)送失敗。后續(xù)的字符也是同樣的情況。

這就說明，采用中斷發(fā)送方式時(shí)，連續(xù)發(fā)送是會(huì)發(fā)送失敗的，串口就只有這點(diǎn)速度，你槍頂著他腦袋他也快不起來。在每次使用串口發(fā)送中斷時(shí)，都要檢查一下是否正確打開了中斷，和先前提到的串口接收中斷一樣，打開中斷并不是總能成功的。于是，我們修改fputc函數(shù)成下面的樣子。

int fputc(int ch, FILE *f){ while(HAL_UART_Transmit_IT(&huart1, (uint8_t *)&ch, 1)!=HAL_OK); return ch;}

這樣子，CPU不斷地嘗試打開串口中斷直至成功為止。由于串口要完成先前的任務(wù)后才會(huì)由BUSY狀態(tài)變成READY狀態(tài)，所以這里際就是在等待串口發(fā)送。

仔細(xì)一想這個(gè)過程我們會(huì)發(fā)現(xiàn)，這不***嗎？用中斷發(fā)送就是為了不堵塞CPU的工作，結(jié)果搞了半天，還是在這兒堵著？

那我們還是要進(jìn)一步改進(jìn)一下。如果使用了多線程的話，那我們可以進(jìn)行任務(wù)切換，讓CPU切換到別的線程工作一會(huì)兒。

int fputc(int ch, FILE *f){ while(HAL_UART_Transmit_IT(&huart1, (uint8_t *)&ch, 1)!=HAL_OK) { osDelay(1);//ARM CMSIS的API，相當(dāng)于一般理解的sleep_ms(1); } return ch;}

但是這也有一個(gè)很明顯的問題，CPU雖然釋放出來了，但是串口堵了啊。當(dāng)我們連續(xù)發(fā)送字符的時(shí)候，CPU總是會(huì)在前一個(gè)字符發(fā)送完成之前嘗試發(fā)送下一個(gè)字符，然后中斷打開失敗，進(jìn)入osDelay(1)，要等1ms之后才會(huì)回來。這其實(shí)是非常慢的，hello world要大約10ms才能發(fā)送完畢，串口以1ms一個(gè)數(shù)據(jù)的速度發(fā)送，這依然不優(yōu)雅。

要么CPU堵，要么串口堵，總有一個(gè)要等待，這可怎么辦呢？我們回顧一下串口中斷的API

AL_StatusTypeDef HAL_UART_Transmit_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)

明顯看到這個(gè)函數(shù)的第三個(gè)參數(shù)是一個(gè)size，它可以一次設(shè)置發(fā)送很多個(gè)數(shù)據(jù)，但我們在fputc中使用時(shí)，由于fputc是單個(gè)字符發(fā)送的，因此我們只能把size設(shè)置成1。如果能夠一口氣把所有要發(fā)送的數(shù)據(jù)都設(shè)置好，我們就不用重復(fù)地打開中斷了，也就避免了前述的尷尬。

所以接下來要做的便是避開fputc這個(gè)令人尷尬的單個(gè)字符發(fā)送的函數(shù)，可是printf就是用這個(gè)函數(shù)的呀，要避開fputc，就不能用printf。我們自己搞一個(gè)更加優(yōu)雅的！起一個(gè)好聽的名字叫做debug，當(dāng)然你喜歡的話叫別的也可以。

void debug(const char *format, ...){ static char tmpStr[64]; /*在靜態(tài)區(qū)申請一塊緩存，因?yàn)镃PU開啟中斷之后不會(huì)原地等待，而是退出這個(gè)函數(shù)， 如果在棧上申請空間，函數(shù)退出時(shí)緩存區(qū)會(huì)直接釋放掉，導(dǎo)致串口發(fā)送數(shù)據(jù)錯(cuò)誤。 因此把緩存區(qū)申請?jiān)陟o態(tài)區(qū) */ /*等待串口發(fā)送完畢，在串口忙于發(fā)送先前的數(shù)據(jù)時(shí)，不能修改緩存區(qū)內(nèi)的數(shù)據(jù)， 否則數(shù)據(jù)會(huì)出錯(cuò)。等串口發(fā)送完成后，再把新的數(shù)據(jù)放進(jìn)緩存區(qū)。 */ while(huart6.gState!=HAL_UART_STATE_READY); //把數(shù)據(jù)放進(jìn)緩存區(qū)里 va_list list; va_start(list, format); vsprintf(tmpStr,format, list);//這一部分不懂得同學(xué)請百度這個(gè)API，里的 va_end(list); while(HAL_UART_Transmit_IT(&huart6,(uint8_t*)tmpStr,strlen(tmpStr))!=HAL_OK); //開啟中斷發(fā)送，由于先前已經(jīng)等待過串口發(fā)送完成了，按理說串口肯定是可以打開的 //但為了避免多線程或者中斷等原因在別的地方打開了這個(gè)中斷，依然用while嘗試打開直到成功為止}

上面的函數(shù)接收不定長的輸入，這個(gè)輸入和printf的格式化是一模一樣的，使用方法和printf完全一樣。這樣的話，每執(zhí)行一次debug，只會(huì)開啟一次中斷，只要等待一次中斷開啟就可以了，不必像先前重映射fputc那樣每發(fā)送一個(gè)字符都要開一次中斷。

重映射fputc時(shí)，必然會(huì)產(chǎn)生連續(xù)發(fā)送的情形，而用后面這種方法的話，如果你沒有連續(xù)地調(diào)用debug，很少會(huì)出現(xiàn)想發(fā)送卻串口忙碌的情況，while的等待時(shí)間是比較少的。

當(dāng)然如果你使用了多線程，并且串口發(fā)送數(shù)據(jù)沒有那么多，但是又希望CPU一點(diǎn)兒也不堵塞。那就更可以稍微修改一下。

void debug(const char *format, ...){ static char tmpStr[64]; while(huart6.gState!=HAL_UART_STATE_READY) { osDelay(1); } va_list list; va_start(list, format); vsprintf(tmpStr,format, list); va_end(list); while(HAL_UART_Transmit_IT(&huart6,(uint8_t*)tmpStr,strlen(tmpStr))) { osDelay(1); }}

這樣在連續(xù)執(zhí)行debug時(shí)，會(huì)進(jìn)行線程切換，好處是CPU不堵了，壞處是串口要延后1ms才能發(fā)送下一個(gè)字符串，但也遠(yuǎn)好于每個(gè)字符都延后1ms的方式，況且連續(xù)地debug也不是特別常見。在實(shí)際應(yīng)用中，根據(jù)需求來使用吧。