500k波特率，从我的计算结果中得出250us Per EXT格式帧的消息给出了750us的开销。什么是更典型的CAN传输更新速率？

100 ms的间隔被认为是快速的。主要标准（例如：j1939）通常指定消息不得在100毫秒内重复。所以是的，也许10毫秒。但是1毫秒，绝对不是在你不控制所有节点的网络中。

好的很棒，谢谢你们的提醒！

是的，这对我来说似乎合情合理。虽然激光雷达外围设备可能忙的最长时间是多少？如果超过1毫秒，那么您可能会错过传输机会。也许繁忙的情况应该只是跳过数据读取而不是循环回来轮询状态。
是的，优先级较低的中断处理程序将在高优先级中断处理程序运行时保持关闭状态。如果优先级较高的定时器中断处理程序运行的时间超过CAN外设接收到足够的消息溢出所需的时间，则会丢失消息。这就是为什么保持中断处理程序简短是一个很好的经验法则。如果所有的定时器中断都设置了标志，那么我怀疑你是否会遇到问题。
另一种考虑这种情况的方法是，当另一个中断处理程序被延迟时，惩罚是什么。当CAN中断被定时器中断延迟时，您会在CAN响应中添加延迟，或者在最坏情况下丢弃消息。当CAN中断延迟定时器中断时，您将向定时器中断添加抖动。最糟糕的情况是下降一毫秒，但CAN中断必须运行超过一毫秒才能实现。那么你的应用程序不太理想，有点滞后还是有点抖动？
令人怀疑的是，任何一个中断都会破坏I2C通信。您可能正在使用I2C控制器外设，它主要独立于CPU发送/接收位。I2C控制器将根据需要继续输入和输出位，而不会受到中断的影响。（如果你对每个位进行位冲击，那么会产生更大的影响，因为单个时钟可能会被一个不相关的中断延长。但是，由于I2C的同步特性，这甚至不一定是个问题。从器件不应该'如果I2C时钟脉冲伸展，请注意。）
轮询激光雷达状态可能是可以接受的。如果CPU没有其他任何功能，那么有什么危害呢？但是如果激光雷达外设有某种“数据就绪”中断，那么你可以启用该中断并等待中断而不是轮询状态。

我会尝试一下，跳过读取距离reg而不是轮询状态。它实际上没有提到如果在状态繁忙时应用读取命令会发生什么，我想它会给我reg值但是在测量完成之前不会更新。