串口發(fā)送數(shù)據(jù)

1、串口發(fā)送數(shù)據(jù)最直接的方式就是標準調(diào)用庫函數(shù) 。

voidUSART_SendData(USART_TypeDef*USARTx,uint16_tData);

第一個參數(shù)是發(fā)送的串口號，第二個參數(shù)是要發(fā)送的數(shù)據(jù)了。但是用過的朋友應該覺得不好用，一次只能發(fā)送單個字符，所以我們有必要根據(jù)這個函數(shù)加以擴展：

以上程序的形參就是我們調(diào)用該函數(shù)時要發(fā)送的字符串，這里通過循環(huán)調(diào)用USART_SendData來一 一發(fā)送我們的字符串。

這句話有必要加，他是用于檢查串口是否發(fā)送完成的標志，如果不加這句話會發(fā)生數(shù)據(jù)丟失的情況。這個函數(shù)只能用于串口1發(fā)送。有些時候根據(jù)需要，要用到多個串口發(fā)送那么就還需要改進這個程序。如下：

這樣就可實現(xiàn)任意的串口發(fā)送。但有一點，我在使用實時操作系統(tǒng)的時候（如UCOS,Freertos等），需考慮函數(shù)重入的問題。

當然也可以簡單的實現(xiàn)把該函數(shù)復制一下，然后修改串口號也可以避免該問題。然而這個函數(shù)不能像printf那樣傳遞多個參數(shù)，所以還可以在改進，最終程序如下：

該函數(shù)就可以像printf使用可變參數(shù)，方便很多。通過觀察函數(shù)但這個函數(shù)只支持了%d,%s的參數(shù)，想要支持更多，可以仿照printf的函數(shù)寫法加以補充。

2、 直接使用printf函數(shù)。

很多朋友都知道想要STM32要直接使用printf不行的。需要加上以下的重映射函數(shù)：

如果不想添加以上代碼，也可以勾選以下的Use MicroLI選項來支持printf函數(shù)使用：

串口接收數(shù)據(jù)

串口接收最后應有一定的協(xié)議，如發(fā)送一幀數(shù)據(jù)應該有頭標志或尾標志，也可兩個標志都有。

這樣在處理數(shù)據(jù)時既能能保證數(shù)據(jù)的正確接收，也有利于接收完后我們處理數(shù)據(jù)。串口的配置在這里就不在贅述，這里我以串口2接收中斷服務程序函數(shù)且接收的數(shù)據(jù)包含頭尾標識為例。

數(shù)據(jù)的頭標識為“ ”，即換行符，尾標識為“+”。該函數(shù)將串口接收的數(shù)據(jù)存放在USART_Buffer數(shù)組中，然后先判斷當前字符是不是尾標識，如果是說明接收完畢，然后再來判斷頭標識是不是“+”號，如果還是那么就是我們想要的數(shù)據(jù)，接下來就可以進行相應數(shù)據(jù)的處理了。但如果不是那么就讓Usart2_Rx=0重新接收數(shù)據(jù)。

這樣做的有以下好處：

可以接受不定長度的數(shù)據(jù)，最大接收長度可以通過Max_BUFF_Len來更改

可以接受指定的數(shù)據(jù)

防止接收的數(shù)據(jù)使數(shù)組越界

這里我的把接受正確數(shù)據(jù)直接打印出來，也可以通過設置標識位，然后在主函數(shù)里面輪詢再操作。

以上的接收形式，是中斷一次就接收一個字符，這在UCOS等實時內(nèi)核系統(tǒng)中頻繁的中斷，非常消耗CPU資源，在有些時候我們需要接收大量數(shù)據(jù)時且波特率很高的情況下，長時間中斷會帶來一些額外的問題。

所以以DMA形式配合串口的IDLE（空閑中斷）來接受數(shù)據(jù)將會大大的提高CPU的利用率，減少系統(tǒng)資源的消耗。首先還是先看代碼。

之前的串口中斷是一個一個字符的接收，現(xiàn)在改為串口空閑中斷，就是一幀數(shù)據(jù)過來才中斷進入一次。而且接收的數(shù)據(jù)時候是DMA來搬運到我們指定的緩沖區(qū)（也就是程序中的USART1_RECEIVE_DMABuffer數(shù)組），是不占用CPU時間資源的。

最后在講下DMA的發(fā)送：

這里需要注意下DMA_Cmd(DMA1_Channel4,DISABLE)函數(shù)需要在設置傳輸大小之前調(diào)用一下，否則不會重新啟動DMA發(fā)送。

有了以上的接收方式，對一般的串口數(shù)據(jù)處理是沒有問題的了。下面再講一下，在ucosiii中我使用信號量+消息隊列+儲存管理的形式來處理我們的串口數(shù)據(jù)。先來說一下這種方式對比其他方式的一些優(yōu)缺點。

一般對串口的處理形式是"生產(chǎn)者"和"消費者"的模式,即本次接收的數(shù)據(jù)要馬上處理，否則當數(shù)據(jù)大量涌進的時候，就來不及"消費"掉生產(chǎn)者（串口接收中斷）的數(shù)據(jù)，那么就會丟失本次的數(shù)據(jù)處理。所以使用隊列就能夠很方便的解決這個問題。

在下面的程序中，對數(shù)據(jù)的處理是先接受，在處理，如果在處理的過程中，有串口中斷接受數(shù)據(jù)，那么就把它依次放在隊列中，隊列的特征是先進先出，在串口中就是先處理先接受的數(shù)據(jù)，所以根據(jù)生產(chǎn)和消費的速度，定義不同大小的消息隊列緩沖區(qū)就可以了。缺點就是太占用系統(tǒng)資源，一般51單片機是沒可能了。下面是從我做的項目中截取過來的程序：

上面被注釋掉的代碼為我是為了防止當分區(qū)中沒有空閑的存儲塊時加入信號量，打印出報警信息。當然我們也可以將存儲塊直接設置大一點，但是還是無法避免當沒有可有存儲塊時會程序會崩潰現(xiàn)象。希望懂的朋友能告知下~。

下面是串口數(shù)據(jù)處理任務，這里刪去了其他代碼，只把他打印出來了而已。

責任編輯：lq6