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

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

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

串口中斷打開之后，當接收到BUFF_SIZE個數(shù)據(jù)后就會進入

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart);

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

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

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

printf("hello world\r\n");

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

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

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

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

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

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

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

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

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

這個函數(shù)會使能發(fā)送中斷，然后挨個發(fā)數(shù)據(jù)，發(fā)完之后執(zhí)行一個回調(diào)函數(shù)，然后自己關掉發(fā)送中斷。一條龍服務，用戶什么都不用管。如果用戶想多管閑事，可以把代碼寫在回調(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\r\n");

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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時，會進行線程切換，好處是CPU不堵了，壞處是串口要延后1ms才能發(fā)送下一個字符串，但也遠好于每個字符都延后1ms的方式，況且連續(xù)地debug也不是特別常見。在實際應用中，根據(jù)需求來使用吧。