STM32庫函數USART_SendData問(wèn)題和解決方法
加入技術(shù)交流群
1. 問(wèn)題及現象
使用USART_SendData()函數非連續發(fā)送單個(gè)字符是沒(méi)有問(wèn)題的；當連續發(fā)送字符時(shí)(兩個(gè)字符間沒(méi)有延時(shí))，就會(huì )發(fā)現發(fā)送緩沖區有溢出現象。若發(fā)送的數據量很小時(shí)，此時(shí)串口發(fā)送的只是最后一個(gè)字符，當發(fā)送數據量大時(shí)，就會(huì )導致發(fā)送的數據莫名其妙的丟失。
本文引用地址：http://dyxdggzs.com/article/201611/319412.htm如：
1 2 | for(TxCounter = 0;TxCounter < RxCounter; TxCounter++) USART_SendData(USART1, RxBuffer[TxCounter]); |
2. 原因
此API函數不完善，函數體內部沒(méi)有一個(gè)判斷一個(gè)字符是否發(fā)送完畢的語(yǔ)句，而是把數據直接放入發(fā)送緩沖區，當連續發(fā)送數據時(shí)，由于發(fā)送移位寄存器的速度限制（與通信波特率有關(guān)），導致發(fā)送緩沖區的數據溢出，老的數據還未及時(shí)發(fā)送出去，新的數據又把發(fā)送緩沖區的老數據覆蓋了。
3. 解決方法
發(fā)送后等待一段時(shí)間延遲的方法就不說(shuō)了，等待時(shí)間不確定，此為下下策。提供下面2種方案：
方案1. 在每一個(gè)字符發(fā)送后檢測狀態(tài)位
USART_SendData(USART1, RxBuffer[TxCounter]);
while(USART_GetFlagStatus(USARTx, USART_FLAG_TXE) == RESET){} //等待發(fā)送緩沖區空才能發(fā)送下一個(gè)字符
方案2. 修改庫函數
修改USART_SendData()函數，在其內部加入發(fā)送緩沖區的USART_FLAG_TXE狀態(tài)檢測語(yǔ)句，確保一個(gè)字符完全發(fā)送出去，才進(jìn)行下一個(gè)字符的發(fā)送。
實(shí)現方法：每發(fā)送一個(gè)字符都檢測狀態(tài)寄存器，確保數據已經(jīng)發(fā)送完畢。具體操作步驟如下所示。
修改前的函數定義體
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | void USART_SendData(USART_TypeDef* USARTx, u16 Data) { assert_param(IS_USART_ALL_PERIPH(USARTx)); assert_param(IS_USART_DATA(Data)); USARTx->DR = (Data & (u16)0x01FF); } |
修改后的函數定義體
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | void USART_SendData(USART_TypeDef* USARTx, u16 Data) { assert_param(IS_USART_ALL_PERIPH(USARTx)); assert_param(IS_USART_DATA(Data)); USARTx->DR = (Data & (u16)0x01FF); while(USART_GetFlagStatus(USARTx, USART_FLAG_TXE) == RESET){} //等待發(fā)送緩沖區空才能發(fā)送下一個(gè)字符 } |
可能有人認為，為什么不預先在庫函數中處理這個(gè)問(wèn)題，而把解決方法拋給用戶(hù)。個(gè)人認為ST這么做的原因是：使用發(fā)送中斷功能。
STM32庫函數USART_SendData問(wèn)題和解決方法 | 小謝的小站 http://blog.xieyc.com/stm32-lib-function-usart-send-data-problem-and-solution/
評論