chinese直男口爆体育生外卖, 99久久er热在这里只有精品99, 又色又爽又黄18禁美女裸身无遮挡, gogogo高清免费观看日本电视,私密按摩师高清版在线,人妻视频毛茸茸,91论坛 兴趣闲谈,欧美 亚洲 精品 8区,国产精品久久久久精品免费

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

探析STM32上UART丟失的那一字節(jié)數(shù)據(jù)

lcdz66 ? 來源:雨飛工作室 ? 作者:雨飛工作室 ? 2022-12-19 15:36 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

串口UART=Universal Asynchronous Receiver / Transmitter,通用異步收發(fā)傳輸器,是工程師最常用的一種串行外設,常見的接口形式有TTL、 RS232、 RS485,但在實際應用中還是會經(jīng)常遇到各種問題,比如:丟失一字節(jié)數(shù)據(jù)。下面就結合STM32來講講UART相關內容,談談容易丟失一字節(jié)數(shù)據(jù)的問題。

1、UART幾個標志位

STM32上UART狀態(tài)寄存器中的幾個標志位:TXE、TC、RXNE、ORE。這幾個標志位在編程中經(jīng)常使用,數(shù)據(jù)丟失有可能就是對它們操作不當而導致出錯。

9edda93c-7f1b-11ed-8abf-dac502259ad0.png ?

TXE=Transmit dataregister empty,發(fā)送數(shù)據(jù)寄存器為空

0:數(shù)據(jù)未傳輸?shù)揭莆患拇嫫鳎?/span>

1:數(shù)據(jù)傳輸?shù)揭莆患拇嫫?/span>

TC=Transmission complete,發(fā)送完 0:傳送未完成;

1:傳送已完成

RXNE=Read dataregister not empty,取數(shù)據(jù)寄存器不為空

0:未接收到數(shù)據(jù);

1:已準備好讀取接收到的數(shù)據(jù)

ORE=Overrun error,上溢錯誤 0:無上溢錯誤;

1:檢測到上溢錯誤

2、UART接收丟失數(shù)據(jù)

UART接收丟失數(shù)據(jù)與軟件和硬件都有可能有關系,下面說幾個常見丟失數(shù)據(jù)的原因及解決辦法。
問題描述 解決辦法
1.接收溢出丟失數(shù)據(jù) 指未及時取走數(shù)據(jù)導致溢出錯誤而丟失數(shù)據(jù),通常是發(fā)生在大量數(shù)據(jù)、以查詢方式接收數(shù)據(jù)的情況下。MCU啟動過程中、接收數(shù)據(jù)過多處理不及時、復雜系統(tǒng)響應不及時等情況都會出現(xiàn)數(shù)據(jù)丟失的情況。

(1)及時清除溢出錯誤標志;(2)利用通信協(xié)議過濾因數(shù)據(jù)丟失導致的問題

2.接收中斷丟失數(shù)據(jù) 使用UART中斷接收數(shù)據(jù)相比查詢接收數(shù)據(jù)的方式更常見,中斷方式比查詢方式響應更及時,但不合理處理同樣也會存在數(shù)據(jù)丟失的情況。在數(shù)據(jù)量大時,UART接收中斷函數(shù)耗時、優(yōu)先級低等情況下容易丟失數(shù)據(jù)。 (1)中斷函數(shù)里減少不必要的耗時;(2)合理分配中斷優(yōu)先級;(3)使能中斷前清除標志位。
3.時鐘誤差導致丟失數(shù)據(jù) 在通信波特率較高的情況下,如果時鐘誤差加大,很可能導致數(shù)據(jù)丟失。 (1)使用更高精度晶振;(2)降低通信波特率。
在編程時需要考慮通信接口方式,在長距離通信的時候,需要考慮線路上的延時,如果操作不當也會導致數(shù)據(jù)丟失。

3、串口發(fā)送的幾種寫法

串口發(fā)送的幾種寫法:一、STM32用USART發(fā)送字符串

	
void UART_Send_Message(u8 *Data)
{
  while(*Data!='')
  {
      USART_SendData(USART1, *Data);
      while(USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET);//讀取串口狀態(tài)
      Data++;
  }
}


void main(void)
{
  u8 str_buf[500];
  memset((char *) &str_buf, 0, sizeof(str_buf));
  UART_Send_Message(str_buf);
}
9f147b74-7f1b-11ed-8abf-dac502259ad0.jpg
while(SET == USART_GetFlagStatus(USART1,USART_FLAG_RXNE));

含義是:當接收引腳有數(shù)據(jù)時,狀態(tài)寄存器的USART_FLAG_RXNE就會為1,此時USART_GetFlagStatus(USART1,USART_FLAG_RXNE)的返回值就為1(SET),若無數(shù)據(jù)則為RESET。


	
		二、USART_FLAG_TXE和USART_FLAG_TC怎么用這里主要說的是在特殊情況下發(fā)送字符軟件代碼的寫法:特殊情況指的是:1)調用發(fā)送字符串函數(shù)“發(fā)送完”本機立即掉電;2)調用發(fā)送字符串函數(shù)“發(fā)送完”從機立即掉電;【上面兩種主要用于芯片對電源控制的項目中】3)調用發(fā)送字符串函數(shù)“發(fā)送完”立刻進入待機或停機。
		主要說的是兩個標志位:USART_FLAG_TXE 和 USART_FLAG_TC。USART_FLAG_TXE發(fā)送緩沖區(qū)空標志:說明可以往數(shù)據(jù)寄存器寫入數(shù)據(jù)了,但并不代表數(shù)據(jù)發(fā)送完成了。USART_FLAG_TC發(fā)送完成標志:這個才是代表USART在緩沖區(qū)的數(shù)據(jù)發(fā)送完成了,即從機接收到了數(shù)據(jù)。這兩個標志的區(qū)別在于:它們分別表示數(shù)據(jù)在發(fā)送過程中,在兩個不同的階段中的完成情況。TXE表示數(shù)據(jù)被從發(fā)送緩沖區(qū)中取走,轉移到的移位寄存器中,此時發(fā)送緩沖是空的,可以向其中補充新的數(shù)據(jù)了。而TC則表示最后放入發(fā)送緩沖區(qū)的數(shù)據(jù)已經(jīng)完成了從移位寄存器向發(fā)送信號線Tx上的轉移。所以,判定數(shù)據(jù)最終發(fā)送完成的標志是TC,而不是TXE。
		
		
					

4、UART發(fā)送丟失數(shù)據(jù)

UART發(fā)送丟失數(shù)據(jù)很多工程師都遇到過,通常情況下是傳輸未完成的原因。HAL庫已經(jīng)有幾年了,但還是有很多工程師都使用標準外設庫,這時如果自己封裝接口不當,就會存在發(fā)送最后一字節(jié)數(shù)據(jù)丟失的問題。 1.UART傳輸未完成導致數(shù)據(jù)丟失:如下代碼,只考慮非空,但實際傳輸并未完成。
void UART_SendByte(uint8_t Data)
{
while(RESET==USART_GetFlagStatus(USART1,USART_FLAG_TXE));  
USART_SendData(USART1, Data);
}
但發(fā)送非空不代表發(fā)送完成,雖然在某些場合更高效,但某些場合就會導致數(shù)據(jù)丟失。比如:使用此函數(shù)發(fā)送之后進入休眠、關閉接收端設備電源等情況下。解決辦法:等待發(fā)送完成之后,再次發(fā)送數(shù)據(jù)。
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));
}
如果使用標準外設庫,要根據(jù)實際情況封裝函數(shù),比如發(fā)送超時。或者使用HAL封裝的接口,代碼包含判斷傳輸完成:
HAL_StatusTypeDefHAL_UART_Transmit(UART_HandleTypeDef*huart,uint8_t*pData,uint16_tSize,uint32_tTimeout)

2.線路延時導致數(shù)據(jù)丟失UART通常會使用232或者485以增加傳輸距離和增強干擾。但是一旦數(shù)據(jù)線路太長就存在傳輸延時的情況,特別是485傳輸長距離,并使用MCU控制傳輸方向的情況下。解決辦法:軟件增加延時處理;使用通信協(xié)議增加應答機制。 3.其他原因UART應用的場景比較多,有些應用在復雜的工廠,干擾較大從而導致數(shù)據(jù)丟失;有些應用在溫差較大的環(huán)境,時鐘偏移較大導致數(shù)據(jù)丟失。解決辦法需要根據(jù)實際情況,有針對性解決問題。比如:使用更好的通信線,軟件做好容錯處理等。 下面講述在不同代碼寫法下,得到不同實驗效果【調試助手接收數(shù)據(jù)】:常見寫法一:9f5bf9e0-7f1b-11ed-8abf-dac502259ad0.png ?9f74f774-7f1b-11ed-8abf-dac502259ad0.png這種寫法在不是特殊(不掉電、不待機等)情況下,問題不大,USART數(shù)據(jù)會成功發(fā)送出去。但是在上面說的特殊情況下,問題就來了,代碼只將數(shù)據(jù)放到了發(fā)送緩沖區(qū),而沒有發(fā)送出去就掉電或待機了,這個時候其實最后兩個字符是沒有發(fā)送出去的。2、常見寫法二:9f8444ea-7f1b-11ed-8abf-dac502259ad0.png ?9f932b40-7f1b-11ed-8abf-dac502259ad0.png這種寫法達到的效果和上面存在不同的就是倒數(shù)第二個數(shù)據(jù)發(fā)送出去了,也就是只有最后一個字符是沒有發(fā)送出去的。3、常見寫法三:9fa14630-7f1b-11ed-8abf-dac502259ad0.png ?9fb6976a-7f1b-11ed-8abf-dac502259ad0.png這種寫法達到的效果和上面兩種寫法又不一樣,發(fā)送了10個字符。4、寫法四:9fc86ada-7f1b-11ed-8abf-dac502259ad0.png ?9fe21340-7f1b-11ed-8abf-dac502259ad0.png這種寫法按理說可以實現(xiàn)功能,但實際多次試驗結果卻是第一字節(jié)數(shù)據(jù)丟失了。5、寫法五(正確寫法):9ff57f48-7f1b-11ed-8abf-dac502259ad0.png ?a0104742-7f1b-11ed-8abf-dac502259ad0.png這種寫法是比較完整,為了保守起見,在特殊情況下使用該寫法。

審核編輯 :李倩


聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權轉載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 寄存器
    +關注

    關注

    31

    文章

    5587

    瀏覽量

    128992
  • 數(shù)據(jù)

    關注

    8

    文章

    7314

    瀏覽量

    93914
  • STM32
    +關注

    關注

    2305

    文章

    11118

    瀏覽量

    370949
  • uart
    +關注

    關注

    22

    文章

    1304

    瀏覽量

    106062

原文標題:探析STM32上UART丟失的那一字節(jié)數(shù)據(jù)

文章出處:【微信號:雨飛工作室,微信公眾號:雨飛工作室】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關推薦
    熱點推薦

    GPIOB模擬SCCB的方法

    。 如上圖所示,在開始和結束中間的數(shù)據(jù)傳輸階段,當SCL為高電平時需保證SDA穩(wěn)定,并因此將數(shù)據(jù)采集下來。寫入一字節(jié)數(shù)據(jù)需分別寫入器件地址、寄存器地址和寫入內容,三者均為一個字節(jié)
    發(fā)表于 10-30 06:00

    UART接口數(shù)據(jù)線接收和發(fā)送數(shù)據(jù)

    FIFO,F(xiàn)IFO會按照先入先出的順序將數(shù)據(jù)依次彈出,每彈出個表項的字節(jié)數(shù)據(jù),則將此字節(jié)數(shù)據(jù)依照UART協(xié)議格式串行發(fā)送出去。 2.2通過
    發(fā)表于 10-29 07:37

    PIC16F18054/55/74/75 微控制器:功能豐富的高性能 8 位 MCU

    Microchip Technology PIC16F18054/55/74/75微控制器 (MCU) 是外形小巧、功能豐富的器件,具有強大的模擬和數(shù)字外設。這些微控制器功能包括128字節(jié)數(shù)據(jù)閃存
    的頭像 發(fā)表于 10-11 15:31 ?320次閱讀
    PIC16F18054/55/74/75 微控制器:功能豐富的高性能 8 位 MCU

    使用fal api 來讀寫1024 字節(jié)數(shù)據(jù),需要需要考慮被高優(yōu)先級線程打斷嗎?

    使用fal api 來讀寫1024 字節(jié)數(shù)據(jù),需要需要考慮被高優(yōu)先級線程打斷嗎?
    發(fā)表于 10-10 07:16

    為什么rt_device_read()只能讀取到兩個字節(jié)數(shù)據(jù)?

    已經(jīng)確定了設備每次會發(fā)送9字節(jié)數(shù)據(jù),但是每次都只能讀取到兩字節(jié)數(shù)據(jù),而且串口的配置都沒問題 /* 接收數(shù)據(jù)回調函數(shù) */ static rt_err_t uart
    發(fā)表于 09-17 06:24

    在rt-thread系統(tǒng)中,使用stm32,怎樣設置接收中斷字節(jié)數(shù)?

    在rt-thread系統(tǒng)中,使用stm32,怎樣設置接收中斷字節(jié)數(shù)
    發(fā)表于 09-15 06:17

    請問cyw20719b2的nvram的存儲空間有多少字節(jié)?

    1)請問cyw20719b2的nvram 的存儲空間有多少字節(jié)? 2)用wiced_hal_write_nvram()或wiced_hal_read_nvram()從nvram 寫入或讀出一字節(jié)數(shù)據(jù)需要多少時間
    發(fā)表于 07-08 07:41

    求助,關于STM32F030的iic主收問題求解

    我現(xiàn)在用stm32f030,在IIC的主模式下,想在收到一個字節(jié)數(shù)據(jù)后就回NACK和stop,但是現(xiàn)在實際情況是,我在接收到一個字節(jié)后進入接收中斷再使能STOP,看波形是收到這個字節(jié)
    發(fā)表于 06-24 07:54

    使用CyU3PDmaChannelCommitBuffer提交超過1024字節(jié)數(shù)據(jù)時usb包異常大怎么解決?

    你好,我正在嘗試使用fx3實現(xiàn)USB3Vision設備,但是當我使用CyU3PDmaChannelCommitBuffer函數(shù)提交超過1024字節(jié)數(shù)據(jù)時,主機獲取到的USB數(shù)據(jù)包變得非常大
    發(fā)表于 05-13 06:11

    STM32CubeIDE STM32H743XIH6串口無法重定向,且發(fā)送內容波特率不對亂碼怎么解決?

    了PA9&PA10,但是兩者配置內容一模一樣 int fputc(int ch, FILE [i]f){HAL_UART_Transmit(&huart1, (uint8_t )&ch, 1, 100); // 發(fā)送單
    發(fā)表于 03-11 06:42

    使用HAL_UART_Transmit函數(shù),發(fā)送200個左右字節(jié)數(shù)據(jù)的時候就會造成MemManage_Handler中斷,怎么解決?

    當我使用HAL_UART_Transmit函數(shù) 發(fā)送大概 200個左右字節(jié)數(shù)據(jù)的時候,就會造成 MemManage_Handler中斷,短小就沒事,請問這個是什么問題,怎么解決啊
    發(fā)表于 03-07 10:17

    STM32F767+DP83848與電腦進行直連通信,發(fā)送數(shù)據(jù)大于1472字節(jié)時,CPU會自動分片發(fā)送,為什么?

    STM32F767+DP83848 與電腦進行直連通信,采用LWIP+UDP形式,當發(fā)送數(shù)據(jù)大于1472字節(jié)時,CPU自動分片發(fā)送,用Wireshark抓包工具抓取數(shù)據(jù)中出現(xiàn)問題?如下
    發(fā)表于 03-07 06:28

    TL16C554發(fā)送數(shù)據(jù),在回環(huán)測試中總讀不出最后一字節(jié)數(shù)據(jù),為什么?

    用TL16C554已經(jīng)實現(xiàn)了發(fā)送數(shù)據(jù)沒有問題 接收數(shù)據(jù)出現(xiàn)以下問題 發(fā)送數(shù)據(jù),在回環(huán)測試中總讀不出最后一字節(jié)數(shù)據(jù) 發(fā)送單個字符的時候,
    發(fā)表于 01-22 06:57

    ADS1293在中斷采用Stream mode讀取數(shù)據(jù),數(shù)據(jù)字節(jié)數(shù)不對是哪里出了問題?

    mode讀取數(shù)據(jù)(按照datasheet33頁的介紹做的),發(fā)現(xiàn)數(shù)據(jù)字節(jié)數(shù)不對,后用示波器測量此時DRDYB管腳變成200Hz方波了; 3、使用的配置DRDYB_SRC_REG(地址0x27)的值是0x08, CH_CNFG_REG(地址0x2F)值是0x70。 不知道
    發(fā)表于 01-13 08:32

    用ads1158在讀取數(shù)據(jù)的時候,后面兩個字節(jié)數(shù)據(jù)讀不到,為什么?

    我現(xiàn)在用的ads1158在讀取數(shù)據(jù)的時候,通道號是可以正常讀取的,但是后面兩個字節(jié)數(shù)據(jù)讀不到,不管輸入信號怎么變化,讀到的兩個字節(jié)數(shù)據(jù)始終是
    發(fā)表于 12-24 06:16