摘要
CAN线性组网项目开发过程中遇到的数据丢包问题，并尝试解决的记录和推测分析。
关键词
CAN串联多节点通讯、CAN10节点通讯、CAN数据丢包、STM32 CAN
背景/项目介绍
概述：
开发了一个多节点线性组网采集数据的项目。
系统包含1个供电和数据网关板还有最多10个节点。
节点之间和网关之间通过CAN通讯。
网关板主要功能：
1.是给总线上每个节点供电
2.并将CAN协议转换为USB CDC设备和PC上位机通讯。
节点的功能：
采集当前位置数据，并通过CAN协议上传给网关板。
通讯线束
CAT6 六类网线，用的网线来传输CAN信号，取网线中的1对双绞线来做CAN_H CAN_L通讯，再取2对网线来做供电，由网关板输出DC12到网线，以此给10个节点做供电，算是自己做了个POE供电，不过是非标的，哈哈哈哈。
节点硬件设计：
一个STM32单片机、两个不带网络变压器的RJ45插座。CAN收发器芯片。
两个RJ45插座完全并联，当接线时，一个用来插入上一个节点延展出的网线水晶头，另一个RJ45插座插入一条网线用来连接下一个节点。
整体系统总线布局
虽然系统物理宏观角度来看是线性连接的，但其实内部每个节点还是通过CAN_H CAN_L挂载到总线上的。类似上图的链接方式。
运行开发环境介绍
| 硬件环境 节点 | STM32F091CCT6 J-LINK V11 |
| 软件开发环境 节点 | IAR 8.32.1 VSCODE |
| 软件支持包 | ST HAL 库 |
| 硬件环境 网关板 | STM32F072C816 J-LINK V11 |
| 软件开发环境 节点 | KEIL5.14 VSCODE |
| 软件支持包 | ST HAL 库 |
| PC上位机环境 | windows10 |
| USB-CAN PC上位机 | CANAGAROO |
| PC串口助手 | Serial Port Utility |
实验1：
实验条件：
测试条件，在小二居室的房间内 实际面积不到69平方，6根5米的CAT6网线，1根10米的超CAT6网线，1根CAT6 20米网线。
因为空间受限，网线没有全延展开。
节点布局：
图中，圆圈为节点，长方形为网关板、菱形为PC上位机。因为是在家里实验，布线路径很奇葩。而且我的画图走位也很风骚，请忽略。 ：） ：） 哈哈哈哈。
节点ID就是CANID。
线束材料：
CAT6类网线，我是用网线来传输的CAN信号，并且用网线来传输12V DC给接点供电。
其中第一根网线10米，其余为5米。
通讯波特率：
125k
接入节点：
实验1接入的是2.3.4.5.6.7.8 这几个节点。
接点接入方法1：
先开启网关板的供电,然后一个个接入节点设备
节点接入方法2：
先不开启网关板供电，先将所有节点接好，然后再开启网关板供电，所有节点上电。或者是用“节点接入方法1”接好总线后，再给网关板断电，然后重新上电，都是为了实现一个所有节点同时上电。
实验发现
发现一个现象，如果是先开启网关板的供电,然后一个个接入节点设备，最后开启上位机的采集数据命令，这时候挂载的7个节点，都能收到数据。这个时候如果断电，然后重新上电，会发现，丢数据情况很严重。只有2、3、8几个节点能收到数据。 后来我分析应该是因为重新上电的过程中，所有节点板子近乎同时启动，这种情况下，收发数据存在异常。而线将网关板供电，然后再一个个插入节点的连接方式，会让不同节点的上电时间存在延时。
总结扩展
于是实验二考虑增加延时，我推测可能是节点收到上位机下发的启动自动上传数据命令后，同一时间所有节点都在总线上喊话，导致总线收发数据丢包了。下面实验增加延时尝试验证推测。
实验2：
实验条件：
线束材料：
和实验1 相同。
通讯波特率：
10k
实验没有严格控制变量，因为我当时时间比较紧急，同时考虑到，CAN总线理论上来说通讯速率越低，抗干扰越强，传输距离越远，所以实验2直接换10k波特率了。
关于CAN总线切换波特率的方法，请看这篇文章。
STM32 CAN 波特率设置。
接入节点：
也接入的是2.3.4.5.6.7.8 这几个节点。
线束布局：
2.3.4.5.6.7.8 这几个节点的时候，在他们的程序中的发送函数中设置，
ID *10 ms的间隔时间。
例如当前节点ID为1则延时1*10ms再发送，当前节点为10则延时10*100ms再发送。
因为我的CAN发送机制运用了队列的方式，再程序的其他部分判断需要发送数据的时候，将数据打包进发送队列，然后再在主循环里按时差发送队列是否为空，如果不为空，就取出将要发送的数据，然后通过CAN发送出去。
如果你的程序这个地方不是运用的消息队列的发送方式，或者对通讯的时序要求很高，则不能运用我这种方式。
最后将所有节点同时上电，然后发送广播启动采集数据命令。
实验发现
发现 只有6号总是收不到数据。
总结扩展
我寻思吧，这玩意特别规律的，总是6号收不到数据，是不是6*10= 60ms正好和数据在线束上传输的时间啥的冲着，我一共8个节点（7个子节点+1个网关），第6个就不行，那我扩展到10个呐？
还有就是，我之前做实验，把线束全伸展开拉的比较直的时候，是没有这种事情的，和线材布局也有关系。但如果我的客户就是要在线束不完全伸展开的情况下使用呐，那我就要研究一下，怎样在这种情况下还能保持CAN通讯的数据传输稳定性。
于是，下一个实验，增加节点数目到10，我这个系统，最多就是要10个节点。
实验3:
实验条件
线束材料、通讯波特率同实验2。
接入节点：
1 2 3 4 5 6 7 8 9 10
节点布局：
测试条件，在小二居室的房间内 实际面积不到69平方，6根5米的CAT6网线，1根10米的超CAT6网线，1根CAT6 20米网线。
和实验1和2相比，我在网关板附件新增了监听模块，上位机为cangaroo
因为空间受限，网线没有全延展开。
程序修改
将发送前的延时改为 ID*15ms
再在开启上电初始化中加一个和ID号有关的延时，例如，ID为1就延时1*100ms进入主while循环。
ID为10则进行10*100 = 1000ms的延时。
实验发现
采用节点接入法2的时候，即，节点同时供电的时候。
总是节点3数据丢失。
监听USB-CAN模块显示报文。
备注：
监听软件，CANGAROO。
思考：
协议中增加上位机的回复命令会更好，上位机收到节点上报的数据后，给节点回复一个命令。
再在节点的程序中增加判断，如果一定时间内收不到总线的回复，就重启节点程序。相当于手动模拟了实验1中的节点接入方法1。
上述思考方法还未编码
敬请期待
没来得及继续探究剩下的问题，欢迎关注，后面我会记录并更新我的程序更改和实验方案~
关注我不迷路。
