理解HAL_UARTEx_ReceiveToIdle_IT的工作过程
先只看没错误发生, 没开DMA时候的情况
将会面临3种结局,
- 收满数据时候IDLE正好发生,
- 数据发多了, 数据已经收满时候IDLE还没发生
- IDLE发生了数据没收满,
首先: 接收开始
主要的动作是
1. status = UART_Start_Receive_IT(huart, pData, Size); 开始中断接口
2. SET_BIT(huart->Instance->CR1, USART_CR1_IDLEIE); 使能IDLE中断
上面开接收中断调用的这里
主要作用是打开了RXNE 中断
到目前为止, 打开了RXNE和IDLE两个中断
如果串口收到数据将会进入中断处理HAL_UART_IRQHander , 中断处理里面一个部分是处理RXNE, 也就是收到的数据
当不是错误导致进入的中断, 而且SR的RXNE和CR1的RXNEIE都是被使能了
去调用中断接收函数 UART_Receive_IT(huart);
UART_Receive_IT, 在没收满要收的数量的时候, 展开状态:
这里从DR拿一个字节, 把这个计数减一 RxXferCount.
如果已经到了最后一个要读的字节, 再减就0了, 那么就顺便处理了收满了数据的动作
关各个中断 , 清标志, 如果这时候碰巧IDLE标志也发生了, 那就是IDLE时候正好收满了数据, 那把ILDE的标志也清了, 这里是清的SR里的IDLE, 顺便清了一次DR. 最后进入用户可以重新定义的weak回调函数, 顺手还把收到的数据数量(其实这里直接就传了要收的数据量!!!)传给了回调函数
这时候完成了一次数量对得上的接收, IDLE发生时候正好收到了要收的数据量. 结局1
如果这时候数据数量收满了, 但是没收到IDLE, 就是外界往串口发来了数量大于要收的数量的数据, 那就不会在这里清SR的IDLE标志, 但是也去调用了回调, 这是 结局2
HAL_UART_IRQHander 另一个部分是处理IDLE, SR的IDLE
这个情况就是接收数据量没满的时候, 由于IDLE进来了中断
这时候做了和UART_Receive_IT几乎一样的动作序列, 关中断最后调用回调, 这是结局3
但是, 解决3和结局1往回调函数里传的数据数量计数值是不一样的
结局1:(收满时候正好发生IDLE)
结局3: (数据量没收满, 就因为IDLE进了中断)
重新梳理一下另一条线, 接收数量的计数值. RxXferSize和RxXferCount
他们在HAL_UARTEx_ReceiveToIdle_IT时候, 调用UART_Start_Receive_IT, 一同被赋值为了用户要收的数据量
RxXferSize 结局1(收满正好IDLE)时候 被传进回调函数给用户使用.
RxXferCount 在UART_Receive_IT里 先--, 在判断是否为0, 以此判断是否刚好收满了要收的数据
UART_Receive_IT是谁调用的? 是中断处理函数HAL_UART_IRQHandler, 也就是说是因为每次的RXNE时候进行减1.
那么结局3 传递给回调函数的计数值就能理解了
count是从size往下减, size-count的结果是当前实际收到的 字节数
coutn>0是没收满的意思, nb_rx_data>0是还真收到了不止一个字节的意思
至此 分析完毕!