曾多次碰到過有人在使用STM8或STM32的UART通信時因為相關接收中斷請求標志未清除導致接收中斷無限循環的問題，從而讓人小受折磨。
STM8 與 STM32各系列MCU的UART功能框架基本是一樣的。寄存器及相關位的定義和命名也基本一樣，只是個別地方有些差異。圍繞UART通信MCU可以產生發送中斷、接收中斷、出錯中斷以及其它特征信號中斷。
STM8系列 MCU UART中斷請求事件及標志列表與中斷框架圖
先看看STM8的UART接收中斷。其接收中斷使能位是RIEN,相應的中斷請求事件有兩個，一個接收數據寄存器非空，另一個是在接收數據寄存器非空情況下，又接收到新的數據，它們對應中斷請求標志分別是RXNE和OR。也就是說，RXNE或OR事件都可以產生UART接收中斷，而且OR事件是在RXNE事件的基礎上進一步發生的。
既然這樣，如果在UART接收中斷里只檢查RXNE標志以及清除動作，就有可能因為已經發生了OR中斷請求而又未作處理。那麻煩就來了，OR中斷請求事件會不停地產生UART接收中斷，沒完沒了。遺憾的是，我們經常可能想不到是這里的原因。
鑒于此，建議在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
//結合第1、2步也就清了OR位
......
}
}
再來簡單看看STM32 MCU uart的接收中斷。
同樣，下面兩幅圖表是關于STM32F4系列 MCU UART中斷請求事件及標志列表和中斷框架圖。相比上面STM8系列，可以很直觀地看出除了些許表述上的差異和極個別地方外，STM8與STM32的UART中斷框架及相關中斷請求事件是一樣的。
STM32F4系列 MCU UART中斷請求事件及標志列表與中斷框架圖
還是看看STM32的UART接收中斷。除了個別寫法差異外，跟STM8基本一樣，其接收中斷使能位是RXNEIE,相應的接收中斷請求事件也是兩個，一個接收數據寄存器非空，另一個是在接收數據寄存非空情況下，又接收到新的數據，它們對應中斷請求標志分別是RXNE和ORE。同樣，RXNE或ORE事件都可以產生UART接收中斷。
顯然，跟上面STM8 uart談到的一樣，如果在STM32 UART接收中斷里忽視了ORE事件及標志，同樣可能會出現跟STM8 一樣的情形，即UART接收中斷沒完沒了循環進入的問題。
為避免因為ORE中斷請求標志未清除而導致UART接收中斷循環進入的麻煩，處理辦法跟上面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.zg4o1577.cn/bbs/) | Powered by Discuz! X3.1 |