stm單片機(jī)串口發(fā)送的疑問

ID:525511 · 發(fā)表于 2023-11-28 11:39

在串口數(shù)據(jù)發(fā)送操作中，單片機(jī)代碼一般是這樣寫的：void USART_SendByte(USART_TypeDef* USARTx, uint8_t Data){ while(USART_GetFlagStatus(USARTx, USART_FLAG_TXE) == RESET); USART_SendData(USARTx,Data); }
那么這里while不是一直在死等嗎？這個過程程序是不做任何事的，和delay有什么分別？都說程序中不要用延時死等，那么這里怎么辦？如果要發(fā)送的數(shù)據(jù)很多的話，每次都在這里死等一下，整體會拖慢程序運行速度吧？不加這個while的話還有其它方法實現(xiàn)發(fā)送功能嗎？我知道可以用DMA，但好像不是所有片子都有DMA吧？虛心求教

ID:401564 · 發(fā)表于 2023-11-28 14:35

雖然說都是死等,但效率并不會太慢
你看一下代碼就知道了
調(diào)用函數(shù)之后并不是先發(fā)送數(shù)據(jù),而是先查詢發(fā)送完成標(biāo)志位
然后,就發(fā)送數(shù)據(jù),函數(shù)就返回了,程序在返回之后就可以去做其它的事了
其實這就已經(jīng)可以了,串口本身就是不用來進(jìn)行超高速數(shù)據(jù)傳送的

ID:94031 · 發(fā)表于 2023-11-28 14:50

while是檢測到發(fā)送完就進(jìn)行下一步，delay不可能比while時間短，最好用while。

ID:744809 · 發(fā)表于 2023-11-28 15:23

可以寫一個發(fā)送隊列,然后用發(fā)送中斷的方式進(jìn)行發(fā)送，每發(fā)送一個字節(jié)會進(jìn)入發(fā)送中斷一次，此時在中斷里判斷發(fā)送buf還有沒有待發(fā)送的字節(jié)，有則繼續(xù)發(fā)送，沒有則說明此次發(fā)送已經(jīng)好了。

ID:470485 · 發(fā)表于 2023-11-28 16:12

不是死等，是反復(fù)檢查，當(dāng)檢測到發(fā)送完（時間可長可短），就進(jìn)入下一步
Delay等待只能固定時間，不能靈活控制。

ID:1093268 · 發(fā)表于 2023-11-28 16:12

大部分應(yīng)用對于：“串口阻塞發(fā)送”，并不會對其他進(jìn)程的時效有多大影響。除非要發(fā)送很多很多字節(jié)或其他進(jìn)程的實時要求特別高，才不會選擇這種阻塞發(fā)送。如果不能用阻塞發(fā)送，可以利用串口BUF空中斷+串口發(fā)送完成中斷+軟件做個發(fā)送緩沖器。

ID:124486 · 發(fā)表于 2023-11-28 18:43

不是死等，是檢測是否接收或者發(fā)送完成等待，任務(wù)不需要即時響應(yīng)的話，波特率調(diào)快一點還好這種方式也還行，如果不想等就用中斷做

ID:384109 · 發(fā)表于 2023-11-28 19:33

改中斷發(fā)送方式就好了

ID:883242 · 發(fā)表于 2023-11-28 22:43

可以把這個死等程序放主循環(huán)里面，其他功能在中斷完成，就不會有卡死的現(xiàn)象了。這個死等只要別放在中斷里面等就沒問題。

ID:744809 · 發(fā)表于 2023-11-29 16:53

Hephaestus 發(fā)表于 2023-11-28 22:43
可以把這個死等程序放主循環(huán)里面，其他功能在中斷完成，就不會有卡死的現(xiàn)象了。這個死等只要別放在中斷里面 ...

你這太抽象了，哪有把串口放主函數(shù)，其他放中斷的。本末倒置了不是

ID:525511 · 發(fā)表于 2023-12-1 15:51

好的，明白了，多謝各位

帳號		自動登錄	找回密碼
密碼			立即注冊