曾多次碰到過有人在使用STM8或STM32的UART通信時因為相關(guān)接收中斷請求標志未清除導(dǎo)致接收中斷無限循環(huán)的問題，從而讓人小受折磨。
STM8 與 STM32各系列MCU的UART功能框架基本是一樣的。寄存器及相關(guān)位的定義和命名也基本一樣，只是個別地方有些差異。圍繞UART通信MCU可以產(chǎn)生發(fā)送中斷、接收中斷、出錯中斷以及其它特征信號中斷。
STM8系列 MCU UART中斷請求事件及標志列表與中斷框架圖
先看看STM8的UART接收中斷。其接收中斷使能位是RIEN,相應(yīng)的中斷請求事件有兩個，一個接收數(shù)據(jù)寄存器非空，另一個是在接收數(shù)據(jù)寄存器非空情況下，又接收到新的數(shù)據(jù)，它們對應(yīng)中斷請求標志分別是RXNE和OR。也就是說，RXNE或OR事件都可以產(chǎn)生UART接收中斷，而且OR事件是在RXNE事件的基礎(chǔ)上進一步發(fā)生的。
既然這樣，如果在UART接收中斷里只檢查RXNE標志以及清除動作，就有可能因為已經(jīng)發(fā)生了OR中斷請求而又未作處理。那麻煩就來了，OR中斷請求事件會不停地產(chǎn)生UART接收中斷，沒完沒了。遺憾的是，我們經(jīng)常可能想不到是這里的原因。
鑒于此，建議在UART 接收中斷里考慮做OR位的清除操作。對RXNE的清除可以通過讀USART_DR寄存器或直接寫0來清除。對OR標志的清除，稍微有點講究，有人也在這犯錯，對它簡單直接寫0是不會生效的。對OR清零要先讀USART_SR,再讀 USART_DR的操作。
如下示例代碼里的1、2步就能做到清除RXNE和OR中斷請求標志。
void USARTx_IRQHandler(void)
{
if(UARTx_GetITStatus(USARTx, UARTx_IT_RXNE)==SET) //1、讀USART_SR
{
RxData = USARTx_ReceiveData(USARTx); //2、讀USART_DR,清零RXNE
//結(jié)合第1、2步也就清了OR位
......
}
}
再來簡單看看STM32 MCU uart的接收中斷。
同樣，下面兩幅圖表是關(guān)于STM32F4系列 MCU UART中斷請求事件及標志列表和中斷框架圖。相比上面STM8系列，可以很直觀地看出除了些許表述上的差異和極個別地方外，STM8與STM32的UART中斷框架及相關(guān)中斷請求事件是一樣的。
STM32F4系列 MCU UART中斷請求事件及標志列表與中斷框架圖
還是看看STM32的UART接收中斷。除了個別寫法差異外，跟STM8基本一樣，其接收中斷使能位是RXNEIE,相應(yīng)的接收中斷請求事件也是兩個，一個接收數(shù)據(jù)寄存器非空，另一個是在接收數(shù)據(jù)寄存非空情況下，又接收到新的數(shù)據(jù)，它們對應(yīng)中斷請求標志分別是RXNE和ORE。同樣，RXNE或ORE事件都可以產(chǎn)生UART接收中斷。
顯然，跟上面STM8 uart談到的一樣，如果在STM32 UART接收中斷里忽視了ORE事件及標志，同樣可能會出現(xiàn)跟STM8 一樣的情形，即UART接收中斷沒完沒了循環(huán)進入的問題。
為避免因為ORE中斷請求標志未清除而導(dǎo)致UART接收中斷循環(huán)進入的麻煩，處理辦法跟上面STM8的一樣。在接收中斷里先讀USART_SR,然后再讀USART_DR.這樣達到既清了RXNE又清了ORE位的目的。比如在下方官方庫例程代碼里，接收中斷處理程序就做了RXNE和ORE的清除操作,他們由藍色代碼完成。
void USARTx_IRQHANDLER(void)
{
if(USART_GetITStatus(EVAL_COM1, USART_IT_RXNE) != RESET) // 1讀_SR
{
/* Read one byte from the receive data register */
aRxBuffer[RxCounter++] = (USART_ReceiveData(EVAL_COM1) & 0x7F);//2讀 _DR
。。。。。。
}
。。。。。。
}
| 歡迎光臨 (http://www.denmoz.com/bbs/) | Powered by Discuz! X3.1 |