UART:Universal Asynchronous Receiver / Transmitter,通用異步收發(fā)傳輸器,即我們通常說的串口。
串口是工程師最常用的串行外設(shè)之一,但在實(shí)際應(yīng)用中還是會(huì)經(jīng)常遇到各種問題。比如:丟失一字節(jié)數(shù)據(jù)。
今天我們就結(jié)合STM32來講講UART相關(guān)內(nèi)容,以及容易丟失一字節(jié)數(shù)據(jù)的問題。
UART幾個(gè)標(biāo)志位
這里重點(diǎn)說一下UART狀態(tài)寄存器中的幾個(gè)標(biāo)志位:TXE、 TC、 RXNE、 ORE。
這幾個(gè)標(biāo)志位在編程中經(jīng)常使用,直接用函數(shù)庫的同學(xué)可能沒有關(guān)心過這幾個(gè)標(biāo)志位,數(shù)據(jù)丟失有可能就是對(duì)它們操作不當(dāng)而導(dǎo)致出錯(cuò)。
TXE:發(fā)送數(shù)據(jù)寄存器為空 (Transmit data register empty)
0:數(shù)據(jù)未傳輸?shù)揭莆患拇嫫?/p>
1:數(shù)據(jù)傳輸?shù)揭莆患拇嫫?/p>
TC:發(fā)送完成 (Transmission complete)
0:傳送未完成
1:傳送已完成
RXNE:讀取數(shù)據(jù)寄存器不為空 (Read data register not empty)
0:未接收到數(shù)據(jù)
1:已準(zhǔn)備好讀取接收到的數(shù)據(jù)
ORE:上溢錯(cuò)誤 (Overrun error)
0:無上溢錯(cuò)誤
1:檢測到上溢錯(cuò)誤
UART通信硬件接口常見有:TTL、 RS232、 RS485。 在編程時(shí)需要考慮通信接口方式,在長距離通信的時(shí)候,需要考慮線路上的延時(shí),如果操作不當(dāng)也會(huì)導(dǎo)致數(shù)據(jù)丟失。
1.TTL
TTL比較簡單,就是直接連接UART的Tx和Rx引腳,不需要外部轉(zhuǎn)換。如圖:
注意:Tx和Rx引腳需要交叉連接。
2.RS232
RS-232標(biāo)準(zhǔn)接口是常用的串行通信接口標(biāo)準(zhǔn)之一,規(guī)定邏輯“1”的電平為-5V~-15 V,邏輯“0”的電平為+5 V~+15 V。
選用該電氣標(biāo)準(zhǔn)的目的在于提高抗干擾能力,增大通信距離。
3.RS485
RS485一般采用兩線制接線方式,這種接線方式為總線式拓?fù)浣Y(jié)構(gòu),在同一總線上可以掛接多個(gè)節(jié)點(diǎn)。
在低速、短距離、無干擾的場合可以采用普通的雙絞線;反之,在高速、長線傳輸時(shí),則必須采用阻抗匹配(一般為120Ω)的RS485專用電纜;而在干擾惡劣的環(huán)境下還應(yīng)采用鎧裝型雙絞屏蔽電纜。
UART接收丟失數(shù)據(jù)
UART接收丟失數(shù)據(jù)與軟件和硬件都有可能有關(guān)系,下面說幾個(gè)常見丟失數(shù)據(jù)的原因及解決辦法。
1.接收溢出丟失數(shù)據(jù)
指未及時(shí)取走數(shù)據(jù)導(dǎo)致溢出錯(cuò)誤而丟失數(shù)據(jù),通常是發(fā)生在大量數(shù)據(jù)、以查詢方式接收數(shù)據(jù)的情況下。在MCU啟動(dòng)過程中、接收數(shù)據(jù)過多處理不及時(shí)、復(fù)雜系統(tǒng)響應(yīng)不及時(shí)等情況都會(huì)出現(xiàn)數(shù)據(jù)丟失的情況。
解決辦法:
及時(shí)清除溢出錯(cuò)誤標(biāo)志
利用通信協(xié)議過濾因數(shù)據(jù)丟失導(dǎo)致的問題
2.接收中斷丟失數(shù)據(jù)使用UART中斷接收數(shù)據(jù)相比查詢接收數(shù)據(jù)的方式更常見,中斷方式比查詢方式響應(yīng)更及時(shí),但不合理處理同樣也會(huì)存在數(shù)據(jù)丟失的情況。 在數(shù)據(jù)量大時(shí),UART接收中斷函數(shù)耗時(shí)、優(yōu)先級(jí)低等情況下容易丟失數(shù)據(jù)。 解決辦法:
中斷函數(shù)里減少不必要的耗時(shí)
合理分配中斷優(yōu)先級(jí)
使能中斷前清除標(biāo)志位
3.時(shí)鐘誤差導(dǎo)致丟失數(shù)據(jù)在通信波特率較高的情況下,如果時(shí)鐘誤差加大,很可能導(dǎo)致數(shù)據(jù)丟失。 解決辦法:
使用更高精度晶振
降低通信波特率
UART發(fā)送丟失數(shù)據(jù)
UART發(fā)送丟失數(shù)據(jù)很多工程師都遇到過,通常情況下是傳輸未完成的原因。 HAL庫已經(jīng)有幾年了,但還是有很多工程師都使用標(biāo)準(zhǔn)外設(shè)庫,這時(shí)如果自己封裝接口不當(dāng),就會(huì)存在發(fā)送最后一字節(jié)數(shù)據(jù)丟失的問題。 1.UART傳輸未完成導(dǎo)致數(shù)據(jù)丟失如下代碼,只考慮非空,但實(shí)際傳輸并未完成。
void UART_SendByte(uint8_t Data){ while(RESET==USART_GetFlagStatus(USART1,USART_FLAG_TXE)); USART_SendData(USART1, Data);} 但發(fā)送非空不代表發(fā)送完成,雖然在某些場合更高效,但某些場合就會(huì)導(dǎo)致數(shù)據(jù)丟失。 比如:使用此函數(shù)發(fā)送之后進(jìn)入休眠、關(guān)閉接收端設(shè)備電源等情況下。 解決辦法:等待發(fā)送完成:
void UART_SendByte(uint8_t Data){ while(RESET==USART_GetFlagStatus(USART1,USART_FLAG_TXE)); USART_SendData(USART1, Data); while(RESET == USART_GetFlagStatus(USART1, USART_FLAG_TC));}如果使用標(biāo)準(zhǔn)外設(shè)庫,要根據(jù)實(shí)際情況封裝函數(shù),比如發(fā)送超時(shí)。 或者使用HAL封裝的接口,代碼包含判斷傳輸完成:
HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout)2.線路延時(shí)導(dǎo)致數(shù)據(jù)丟失UART通常會(huì)使用232或者485以增加傳輸距離和增強(qiáng)干擾。但是一旦數(shù)據(jù)線路太長就存在傳輸延時(shí)的情況,特別是485傳輸長距離,并使用MCU控制傳輸方向的情況下。 解決辦法:
軟件增加延時(shí)處理
使用通信協(xié)議增加應(yīng)答機(jī)制
3.其他原因UART應(yīng)用的場景比較多,有些應(yīng)用在復(fù)雜的工廠,干擾較大從而導(dǎo)致數(shù)據(jù)丟失;有些應(yīng)用在溫差較大的環(huán)境,時(shí)鐘偏移較大導(dǎo)致數(shù)據(jù)丟失。 解決辦法需要根據(jù)實(shí)際情況,有針對(duì)性解決問題。比如:使用更好的通信線,軟件做好容錯(cuò)處理等。
審核編輯 :李倩
-
寄存器
+關(guān)注
關(guān)注
31文章
5432瀏覽量
124114 -
STM32
+關(guān)注
關(guān)注
2292文章
11029瀏覽量
363909 -
串口
+關(guān)注
關(guān)注
15文章
1587瀏覽量
79703
原文標(biāo)題:串口丟數(shù)據(jù)的幾個(gè)常見原因
文章出處:【微信號(hào):FANYPCB,微信公眾號(hào):凡億PCB】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
常見的網(wǎng)絡(luò)丟包故障定位?法

常見串口通信的幾個(gè)問題請(qǐng)教?
ESP8266_RTOS3.0串口0傳輸大量數(shù)據(jù)丟包的原因?
串口連續(xù)讀取數(shù)據(jù)錯(cuò)包,丟包,死機(jī)
TFT畫點(diǎn)丟數(shù)據(jù),所謂的丟數(shù)據(jù)怎么丟?
網(wǎng)絡(luò)數(shù)據(jù)及攝像機(jī)丟包的原因
如何解決stm32DMA+消息隊(duì)列串口數(shù)據(jù)接收丟包的問題?
N76E003雙串口+MC8618無卡校時(shí)會(huì)丟數(shù)據(jù)的原因?
網(wǎng)絡(luò)數(shù)據(jù)丟包的原因及攝像機(jī)丟包的原因
常見的云網(wǎng)絡(luò)丟包故障定位?法

分享一個(gè)比較常見的?絡(luò)問題--丟包

基于V682-SONiC交換機(jī)的實(shí)現(xiàn)網(wǎng)絡(luò)丟包檢測的可視化

GD32 串口接受異常的幾個(gè)原因

評(píng)論