STM32如何優(yōu)雅地hello world
點(diǎn)擊上方藍(lán)字關(guān)注我哦~
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\r\n");
上面的內(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\r\n");
愛動(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ù),但我們?cè)趂putc中使用時(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 (const char *format, ...)
{
static char tmpStr[64];
/*在靜態(tài)區(qū)申請(qǐng)一塊緩存,因?yàn)镃PU開啟中斷之后不會(huì)原地等待,而是退出這個(gè)函數(shù),
如果在棧上申請(qǐng)空間,函數(shù)退出時(shí)緩存區(qū)會(huì)直接釋放掉,導(dǎo)致串口發(fā)送數(shù)據(jù)錯(cuò)誤。
因此把緩存區(qū)申請(qǐng)?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é)請(qǐng)百度這個(gè)API,<stdio.h>里的
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ù)需求來使用吧。
/ The End /
免責(zé)聲明:本文轉(zhuǎn)載自知乎,版權(quán)歸原作者所有。如涉及作品版權(quán)問題,請(qǐng)與我聯(lián)系刪除。
掃碼關(guān)注我們
看更多嵌入式案例
喜歡本篇內(nèi)容請(qǐng)給我們點(diǎn)個(gè)在看
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場,如有問題,請(qǐng)聯(lián)系我們,謝謝!