你碰着过串口去世机吗_串口_数据

文章目录 [+]

2.回调函数吸收数据

嵌入式物联网须要学的东西真的非常多，千万不要学错了路线和内容，导致人为要不上去！

你碰着过串口去世机吗_串口_数据科学

无偿分享大家一个资料包，差不多150多G。
里面学习内容、面经、项目都比较新也比较全！
某鱼上买估计至少要好几十。

点击这里找小助理0元领取：加微信领取资料

理论上通过以上配置，可以正常吸收到DMA收到的不定长数据，经大略测试，每次通过串口助手，手动发送数据，确实都能正常吸收并处理。

但是，一旦发送数据帧的周期太快，或者发送的数据量超过20个字节后，串口就很随意马虎涌现去世机的征象。

通过进入仿真创造，暴力发送数据后，不会再进入中断。
把数据解析函数屏蔽掉往后，再进入仿真，进行同样的测试，每次又都能进入中断。

通过比较两次的仿真，创造ISR中断状态寄存器ORE标志位被置位后，不会再进入中断。

缘故原由剖析：

查阅数据手册：

这个ORE的检测是CubeMX默认打开的，在UART的配置里面，如下：

产生中断和状态寄存器：

Interrupt & status register (LPUART_ISR)

打消中断和状态寄存器：

Interrupt flag clear register (LPUART_ICR)

通过以上数据手册中内容可知，ORE标志位置位后，必须通过ORECF寄存器打消ORE，否则吸收不到新数据。

剖析HAL库的代码创造：发生溢出错误后，HAL_UART_IRQHandler，经由了三个步骤：1.打消ORE标志位2.关闭串口吸收3.调用缺点回调函数

void HAL_UART_IRQHandler(UART_HandleTypeDef huart){ uint32_t isrflags = READ_REG(huart->Instance->ISR); uint32_t cr1its = READ_REG(huart->Instance->CR1); uint32_t cr3its = READ_REG(huart->Instance->CR3); uint32_t errorflags; uint32_t errorcode; / If some errors occur / if ((errorflags != 0U) && (((cr3its & USART_CR3_EIE) != 0U) || ((cr1its & (USART_CR1_RXNEIE | USART_CR1_PEIE | USART_CR1_RTOIE)) != 0U))) { / UART Over-Run interrupt occurred -----------------------------------------/ if (((isrflags & USART_ISR_ORE) != 0U) && (((cr1its & USART_CR1_RXNEIE) != 0U) || ((cr3its & USART_CR3_EIE) != 0U))) { __HAL_UART_CLEAR_FLAG(huart, UART_CLEAR_OREF);//1.打消ORE标志位 huart->ErrorCode |= HAL_UART_ERROR_ORE; } / If Error is to be considered as blocking : - Receiver Timeout error in Reception - Overrun error in Reception - any error occurs in DMA mode reception / errorcode = huart->ErrorCode; if ((HAL_IS_BIT_SET(huart->Instance->CR3, USART_CR3_DMAR)) || ((errorcode & (HAL_UART_ERROR_RTO | HAL_UART_ERROR_ORE)) != 0U)) { / Blocking error : transfer is aborted Set the UART state ready to be able to start again the process, Disable Rx Interrupts, and disable Rx DMA request, if ongoing / UART_EndRxTransfer(huart);//2.关闭串口吸收 } /Call legacy weak error callback/ HAL_UART_ErrorCallback(huart);//3.调用缺点回调函数 }}

以是办理办法是，只须要在HAL_UART_ErrorCallback缺点回调函数中重新打开串口吸收即可。

void HAL_UART_ErrorCallback(UART_HandleTypeDef huart){ if(huart == &hlpuart1) { __HAL_UNLOCK(huart); HAL_UARTEx_ReceiveToIdle_DMA(&hlpuart1, (uint8_t)receive_buff, 20); }}

经由以上剖析，已经知道了串口去世机的缘故原由，和初步办理方案，在缺点回调函数中重新打开串口。

但是在实际利用过程中，难免会有大量数据的收发，通过缺点回调函数中重新打开串口只是治标不治本，ORE溢出错误的本意是奉告用户目前通信超负荷须要进行调度，要么波特率太高，要么数据量太大数据处理不过来。

波特率一样平常是终端用户指定哀求的，无法变动，那么只能变动在中断中的数据处理函数了。

办理方案：

要想知道怎么改中断中的数据处理函数，就须要明白在一个2MHz主频系统下，利用中断（或DMA）模式来吸收串口数据，波特率为115200的情形下，中断处理程序许可的理论最大安全韶光是多少？

115200的波特率在范例的“1起始位+1终止位+无校验位+8数据位”的配置下（每个数据帧对应10个bit），实际上对应最大11.52KB/s的数据率——或者说，USART完成中断每秒钟发生 11.52K次。
即在这一系统中最大许可屏蔽中断多永劫光——1/11.52KHz ≈87us。

由此可知：中断中的数据处理函数最长实行韶光不能超过87us，否则将涌现通信超载。

通过perf_counter工具实际丈量data_parser代码的周期花费：修正代码如下：

经丈量处理函数实行了2211个指令周期，由1MHz对应1us，1us对应一个指令周期可打算，2.097M的主频，1us可以实行2.097个指令周期，以是一共须要2211/2.097=1054us,超过了87us。

优化掉data_parser内部的耗时期码后，重新丈量指令周期如下：

经丈量处理函数实行了137个指令周期，一共须要137/2.097=66us,低于87us，经暴力测试，未涌现溢出中断，符合预期。

把稳：