串口發送數據的方式:
1、串口發送數據
最直接的方式就是標準調用庫函數 。
voidUSART_SendData(USART_TypeDef*USARTx,uint16_tData);
第一個參數是發送的串口號,第二個參數是要發送的數據,但是用過的朋友應該覺得不好用,一次只能發送單個字符,所以我們有必要根據這個函數加以擴展:
voidSend_data(u8*s) { while(*s!='?') { while(USART_GetFlagStatus(USART1,USART_FLAG_TC)==RESET); USART_SendData(USART1,*s); s++; } }
以上程序的形參就是我們調用該函數時要發送的字符串,這里通過循環調用USART_SendData來一 一發送我們的字符串。
while(USART_GetFlagStatus(USART1,USART_FLAG_TC)==RESET);
這句話有必要加,它是用于檢查串口是否發送完成的標志,如果不加這句話會發生數據丟失的情況。這個函數只能用于串口1發送。有些時候根據需要,要用到多個串口發送,那么就還需要改進這個程序。如下:
voidSend_data(USART_TypeDef*USARTx,u8*s) { while(*s!='?') { while(USART_GetFlagStatus(USARTx,USART_FLAG_TC)==RESET); USART_SendData(USARTx,*s); s++; } }
這樣就可實現任意的串口發送。但有一點,我在使用實時操作系統的時候(如UCOS,Freertos等),需考慮函數重入的問題。
當然也可以簡單的實現把該函數復制一下,然后修改串口號也可以避免該問題。然而這個函數不能像printf那樣傳遞多個參數,所以還可以再改進,最終程序如下:
voidUSART_printf(USART_TypeDef*USARTx,char*Data,...) { constchar*s; intd; charbuf[16]; va_listap; va_start(ap,Data); while(*Data!=0)//判斷是否到達字符串結束符 { if(*Data==0x5c)//'' { switch(*++Data) { case'r'://回車符 USART_SendData(USARTx,0x0d); Data++; break; case'n'://換行符 USART_SendData(USARTx,0x0a); Data++; break; default: Data++; break; } } elseif(*Data=='%') {// switch(*++Data) { case's'://字符串 s=va_arg(ap,constchar*); for(;*s;s++) { USART_SendData(USARTx,*s); while(USART_GetFlagStatus(USARTx,USART_FLAG_TXE)==RESET); } Data++; break; case'd': //十進制 d=va_arg(ap,int); itoa(d,buf,10); for(s=buf;*s;s++) { USART_SendData(USARTx,*s); while(USART_GetFlagStatus(USARTx,USART_FLAG_TXE)==RESET); } Data++; break; default: Data++; break; } } elseUSART_SendData(USARTx,*Data++); while(USART_GetFlagStatus(USARTx,USART_FLAG_TXE)==RESET); } }
該函數就可以像printf使用可變參數,方便很多。通過觀察函數但這個函數只支持了%d,%s的參數,想要支持更多,可以仿照printf的函數寫法加以補充。
2、 直接使用printf函數。
很多朋友都知道STM32直接使用printf不行的。需要加上以下的重映射函數:
如果不想添加以上代碼,也可以勾選以下的Use MicroLI選項來支持printf函數使用:
串口接收數據
串口接收最后應有一定的協議,如發送一幀數據應該有頭標志或尾標志,也可兩個標志都有。這樣在處理數據時既能能保證數據的正確接收,也有利于接收完后我們處理數據。串口的配置在這里就不再贅述,這里以串口2接收中斷服務程序函數且接收的數據包含頭尾標識為例。
#defineMax_BUFF_Len18 unsignedcharUart2_Buffer[Max_BUFF_Len]; unsignedintUart2_Rx=0; voidUSART2_IRQHandler() { if(USART_GetITStatus(USART2,USART_IT_RXNE)!=RESET)//中斷產生 { USART_ClearITPendingBit(USART2,USART_IT_RXNE);//清除中斷標志 Uart2_Buffer[Uart2_Rx]=USART_ReceiveData(USART2);//接收串口1數據到buff緩沖區 Uart2_Rx++; if(Uart2_Buffer[Uart2_Rx-1]==0x0a||Uart2_Rx==Max_BUFF_Len)//如果接收到尾標識是換行符(或者等于最大接受數就清空重新接收) { if(Uart2_Buffer[0]=='+')//檢測到頭標識是我們需要的 { printf("%s ",Uart2_Buffer);//這里我做打印數據處理 Uart2_Rx=0; } else { Uart2_Rx=0;//不是我們需要的數據或者達到最大接收數則開始重新接收 } } } }
數據的頭標識為“ ”既換行符,尾標識為“+”。該函數將串口接收的數據存放在USART_Buffer數組中,然后先判斷當前字符是不是尾標識,如果是,說明接收完畢,然后再來判斷頭標識是不是“+”號,如果還是,那么就是我們想要的數據,接下來就可以進行相應數據的處理了。但如果不是,那么就讓Usart2_Rx=0重新接收數據。
這樣做有以下好處:
-
可以接收不定長度的數據,最大接收長度可以通過Max_BUFF_Len來更改
-
可以接收指定的數據
-
防止接收的數據使數組越界
這里得把接收正確數據直接打印出來,也可以通過設置標識位,然后在主函數里面輪詢再操作。
以上的接收形式是中斷一次就接收一個字符,這在UCOS等實時內核系統中頻繁的中斷,非常消耗CPU資源,在有些時候我們需要接收大量數據時且波特率很高的情況下,長時間中斷會帶來一些額外的問題。
所以,以DMA形式配合串口的IDLE(空閑中斷)來接收數據將會大大的提高CPU的利用率,減少系統資源的消耗。首先還是先看代碼。
#defineDMA_USART1_RECEIVE_LEN18 voidUSART1_IRQHandler(void) { u32temp=0; uint16_ti=0; if(USART_GetITStatus(USART1,USART_IT_IDLE)!=RESET) { USART1->SR; USART1->DR;//這里我們通過先讀SR(狀態寄存器)和DR(數據寄存器)來清USART_IT_IDLE標志 DMA_Cmd(DMA1_Channel5,DISABLE); temp=DMA_USART1_RECEIVE_LEN-DMA_GetCurrDataCounter(DMA1_Channel5);//接收的字符串長度=設置的接收長度-剩余DMA緩存大小 for(i=0;i//設置傳輸數據長度 DMA_SetCurrDataCounter(DMA1_Channel5,DMA_USART1_RECEIVE_LEN); //打開DMA DMA_Cmd(DMA1_Channel5,ENABLE); } }
之前的串口中斷是一個一個字符的接收,現在改為串口空閑中斷
,就是一幀數據過來才中斷進入一次。而且接收的數據時候是DMA來搬運到我們指定的緩沖區(也就是程序中的USART1_RECEIVE_DMABuffer數組),是不占用CPU時間資源的。
最后,講下DMA的發送:
#defineDMA_USART1_SEND_LEN64 voidDMA_SEND_EN(void) { DMA_Cmd(DMA1_Channel4,DISABLE); DMA_SetCurrDataCounter(DMA1_Channel4,DMA_USART1_SEND_LEN); DMA_Cmd(DMA1_Channel4,ENABLE); }
這里需要注意下DMA_Cmd(DMA1_Channel4,DISABLE)函數需要在設置傳輸大小之前調用一下,否則不會重新啟動DMA發送。
有了以上的接收方式,對一般的串口數據處理是沒有問題的了。下面再講一下,在ucosiii中我使用信號量+消息隊列+儲存管理的形式來處理我們的串口數據。先來說一下這種方式對比其他方式的一些優缺點。
一般對串口的處理形式是"生產者"和"消費者"的模式,即本次接收的數據要馬上處理,否則當數據大量涌進的時候,就來不及"消費"掉生產者(串口接收中斷)的數據,那么就會丟失本次的數據處理。所以使用隊列就能夠很方便的解決這個問題。
在下面的程序中,對數據的處理是先接收,再處理,如果在處理的過程中,有串口中斷接收數據,那么就把它依次放在隊列中,隊列的特征是先進先出,在串口中就是先處理先接收的數據,所以根據生產
和消費的速度,定義不同大小的消息隊列緩沖區就可以了。缺點就是太占用系統資源,一般51單片機是沒可能了。
下面是從我做的項目中截取過來的程序:
OS_MSG_SIZEUsart1_Rx_cnt;//字節大小計數值 unsignedcharUsart1_data;//每次中斷接收的數據 unsignedchar*Usart1_Rx_Ptr;//儲存管理分配內存的首地址的指針 unsignedchar*Usart1_Rx_Ptr1;//儲存首地址的指針 voidUSART1_IRQHandler() { OS_ERRerr; OSIntEnter(); if(USART_GetFlagStatus(USART1,USART_FLAG_RXNE)!=RESET)//中斷產生 { USART_ClearFlag(USART1,USART_FLAG_RXNE);//清除中斷標志 Usart1_data=USART_ReceiveData(USART1);//接收串口1數據到buff緩沖區 if(Usart1_data=='+')//接收到數據頭標識 { //OSSemPend((OS_SEM*)&SEM_IAR_UART,//這里請求信號量是為了保證分配的存儲區,但一般來說不允許 //(OS_TICK)0,//在終端服務函數中調用信號量請求但因為 //(OS_OPT)OS_OPT_PEND_NON_BLOCKING,//我OPT參數設置為非阻塞,所以可以這么寫 //(CPU_TS*)0, //(OS_ERR*)&err); //if(err==OS_ERR_PEND_WOULD_BLOCK)//檢測到當前信號量不可用 //{ //printf("error"); //} Usart1_Rx_Ptr=(unsignedchar*)OSMemGet((OS_MEM*)&UART1_MemPool,&err);//分配存儲區 Usart1_Rx_Ptr1=Usart1_Rx_Ptr;//儲存存儲區的首地址 } if(Usart1_data==0x0a)//接收到尾標志 { *Usart1_Rx_Ptr++=Usart1_data; Usart1_Rx_cnt++;//字節大小增加 OSTaskQPost((OS_TCB*)&Task1_TaskTCB, (void*)Usart1_Rx_Ptr1,//發送存儲區首地址到消息隊列 (OS_MSG_SIZE)Usart1_Rx_cnt, (OS_OPT)OS_OPT_POST_FIFO,//先進先出,也可設置為后進先出,再有地方很有用 (OS_ERR*)&err); Usart1_Rx_Ptr=NULL;//將指針指向為空,防止修改 Usart1_Rx_cnt=0;//字節大小計數清零 } else { *Usart1_Rx_Ptr=Usart1_data;//儲存接收到的數據 Usart1_Rx_Ptr++; Usart1_Rx_cnt++; } } OSIntExit(); }
上面被注釋掉的代碼為了防止當分區中沒有空閑的存儲塊時加入信號量,打印出報警信息。當然我們也可以將存儲塊直接設置大一點,但是還是無法避免當沒有可用存儲塊時會程序會崩潰現象的發生。
下面是串口數據處理任務,這里刪去了其他代碼,只把他打印出來了而已。
voidtask1_task(void*p_arg) { OS_ERRerr; OS_MSG_SIZEUsart1_Data_size; u8*p; while(1) { p=(u8*)OSTaskQPend((OS_TICK)0,//請求消息隊列,獲得儲存區首地址 (OS_OPT)OS_OPT_PEND_BLOCKING, (OS_MSG_SIZE*)&Usart1_Data_size, (CPU_TS*)0, (OS_ERR*)&err); printf("%s ",p);//打印數據 delay_ms(100); OSMemPut((OS_MEM*)&UART1_MemPool,//釋放儲存區 (void*)p, (OS_ERR*)&err); OSSemPost((OS_SEM*)&SEM_IAR_UART,//釋放信號量 (OS_OPT)OS_OPT_POST_NO_SCHED, (OS_ERR*)&err); OSTimeDlyHMSM(0,0,1,500,OS_OPT_TIME_PERIODIC,&err); } }
-
STM32
+關注
關注
2270文章
10895瀏覽量
355744 -
串口
+關注
關注
14文章
1551瀏覽量
76429 -
發送數據
+關注
關注
0文章
4瀏覽量
6073 -
接收數據
+關注
關注
0文章
7瀏覽量
6075
原文標題:STM32串口發送數據和接收數據方式總結
文章出處:【微信號:雨飛工作室,微信公眾號:雨飛工作室】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論