radio2radio 发表于 2019-12-22 15:16
我估计是，你MPU6050每5ms触发一次+传送大量数据（不知道你的I2C速度是多少？硬件I2C？），已经搞到CPU很繁 ...

采用的HAL硬件I2C，不是模拟I2C，速率是4M。
尝试降低了MPU6050的中断频率，MPU6050产生中断频率从200Hz（5ms），直到降低到16Hz（62.5ms）时，串口中断可以接收到数据（MPU6050中断频率16Hz以上时，串口中断无法正常接收数据）。但是串口中断接收一定数据后，不再持续中断接收。“一定”数据的个数似乎是随机的，目前测试与MPU6050的中断频率有关：当频率为16Hz时，大约能正常接收4组字节的数据（51个字节为一组，分组发送，每组之间有1秒以上时间间隔）；当MPU6050中断频率为5Hz时，大约能正常接收30组字节数据。

谢谢分享

     参考各位的提醒和建议，分析了我的应用场景：MPU6050每隔20ms产生中断，在EXIT4回调函数中，I2C读取MPU6050数据，并打包发送到上位机；上位机的控制信息通过UART2 接收中断接收，并解析协议数据。
    这个方案选择是有问题的：20ms外部中断比较频繁，而UART2的发送速度较低。同时UART2中断接收，每收到一个字节中断一次，并尝试处理协议解析。CPU很繁忙。
    改进方案：1）将UART2向上位机发送MPU6050数据从EXIT4回调函数中移到main（）中 ；  2）将UART2接收改为DMA IDLE模式。DMA接收到数据后，协议处理放到main（）中进行。
   上述改进方案后，UART2可正常接收到上位机的控制命令，同时MPU6050每20ms中断读取也可正常进行。达到目标要求。

   当前在EXIT4的回调函数中，还要一部分进行数据处理，协议解析的的函数。后续也可考虑移到main（）中，进一步降低中断占用时间。

    再次感谢各位的建议。

pkoko 发表于 2019-12-27 14:57
参考各位的提醒和建议，分析了我的应用场景：MPU6050每隔20ms产生中断，在EXIT4回调函数中，I2C读取MP ...

基本原则上中断中只进行赋值与将标记位置位，然后在循环体中解析协议。
如果中断会在某一段短时间内集中更新数据的话，还需要用到消息队列，然后在循环体中将消息队列中的数据读取出来，一条一条按协议解析出来。

奏奏奏 发表于 2019-12-27 19:15
基本原则上中断中只进行赋值与将标记位置位，然后在循环体中解析协议。
如果中断会在某一段短时间内集中 ...

是的。当初想着没多少数据，应该能应付。
经验教训就是中断的处理时间要尽量短