阻抗匹配一般问题不大，我们甚至在CAN总线上总电阻在40甚至30欧姆的情况下都能读到正确的CAN报文。当然官方建议还是两端各跨接一个120欧姆电阻。 1.认真规划总线使用波特率和ID分配。良好的ID分配应该有深入的考虑，例如CANOpen或者J1939都是很好的范例。通过ID定义报文的优先级，在出现总线竞争的时候能够仲裁胜出。此外，还要便于报文的过滤，一个CAN网络，在1秒内可能产生超过1k条的CAN报文，如果没有良好的过滤机制，筛选报文也是一个头疼的事情。 2.单个控制器向外界发送周期性报文的时候，可以考虑在其中加入一个Live值，就是每个报文中某个字段比前一个+1，这样当其他设备读到这个值不符合预期时，可以判断报文丢失或通讯错误。 3.节点的CAN控制器应该考虑仲裁失利是否重发，重发带来的问题是可能会一直被堵塞。 4.配置BUS OFF。当控制器发现自己发送错误帧超过一定数目的时候可以考虑主动脱离CAN网络。
其实我有详细看了一下你的问题。你说搬运132个点正常，2112个点时间长就不正常。如果是我，我就再试一下。如果我搬运一半呐？会不会失真？ 你说这个情况我之前有点怀疑硬件，但你这个132个点一直正常我就觉得应该又不是硬件。 再说在线仿真。正常我猜你先单步调试，然后全速运行。再失真之前你可以先暂停全速调试，单步调试一下，看看正常运行有没有什么逻辑问题。如果过你暂停的话，arm的内核应该是pause的状态，外设应该是按照之前的输出自动输出。然后你等待一段时间看还失真吗（这时是暂停状态）？如果失真，会不会是电磁干扰？就是你的电源stage和控制这部分设计的不太好。 说的有点乱，希望你了解我的大致想法。 另外从你的描述里302除了问题。但是你没有描述303的情况。所以我不知道303是不是正常。而且你程序基本一致。
你也在用TM32CubeMX吗，我现在想法是TM32CubeMX生成的*.c源码直接使用，关于硬件的配置使用TM32CubeMX生成（不再手动编写），自定义逻辑功能使用C++开发，将stm32 板级配置与自定义逻辑处理分开。但是TM32CubeMX中使用FreeRTOS自动生成代码（*.c）中需要调用自定义逻辑功能C++代码（具有C++特性，extern "C"不适应）。如果将TM32CubeMX中使用FreeRTOS自动生成代码（*.c）改为*.cpp可以解决，但是TM32CubeMX重新生成后需要手动修改，如果能直接指定TM32CubeMX中使用FreeRTOS自动生成代码（*.c）使用arm-xxx-g++编译器进行编译就好了。
微信公众号
手机版
.png)
