在一个项目中，笔者接触过这样一个通讯系统，整个系统的通讯架构大概如下图，典型的一主多从。
如果Slave_N的N超过10，那这样一个通讯系统还是比较复杂的。
笔者认为要这套系统有以下几点需要考虑：
1、通讯故障处理
（1）如果整个系统中，主机或这从机出现通讯故障，此时应该怎么处理？
笔者目前的做法是，每个DSP的CAN的收发函数，首先有一个故障检测，一旦检测到故障，则CAN停止收发数据，进入软件复位状态，如果没有检测到故障，则继续进行通讯。这故障是CAN寄存器总的故障位。但这个做法，笔者还没仔细测试过，是否有用，因为目前这套通讯系统还能够正常运行，没有出现特别奇怪的通讯故障问题。
Uint16 ECanFaultHandle(void) //从机的故障检测函数
{
struct ECAN_REGS ECanaShadow;
//ECanaRegs.CANTEC.bit.TEC //发送错误计数器
//ECanaRegs.CANREC.bit.REC //接收错误计数器
if (ECanaRegs.CANES.bit.EW == 1) //出现警告状态
{
EALLOW;
ECanaShadow.CANMC.all = ECanaRegs.CANMC.all;
ECanaRegs.CANMC.bit.SRES = 1; //开始软件复位
ECanaRegs.CANMC.bit.ABO = 1; //自动总线连接使能
ECanaRegs.CANMC.all= ECanaShadow.CANMC.all;
EDIS;
return 0;
}
else if(ECanaRegs.CANES.bit.EP == 1) //被动错误
{
EALLOW;
ECanaShadow.CANMC.all = ECanaRegs.CANMC.all;
ECanaRegs.CANMC.bit.SRES = 1; //开始软件复位
ECanaRegs.CANMC.bit.ABO = 1; //自动总线连接使能
ECanaRegs.CANMC.all= ECanaShadow.CANMC.all;
EDIS;
return 0;
}
else if(ECanaRegs.CANES.bit.BO == 1) //离线
{
EALLOW;
ECanaShadow.CANMC.all = ECanaRegs.CANMC.all;
ECanaRegs.CANMC.bit.SRES = 1; //开始软件复位
ECanaRegs.CANMC.bit.ABO = 1; //自动总线连接使能
ECanaRegs.CANMC.all= ECanaShadow.CANMC.all;
EDIS;
return 0;
}
else return 1;
}（2）如果主机通讯没有故障，而从机出现故障怎么办？
笔者的做法是，主机会对从机的CAN通讯进行检测，一旦检测到某个从机不再发送数据，则主机会报一个CAN通讯故障，提示用户检查故障源。
2、总线的带宽
一主多从的通讯系统，如果主机和从机同时进行向CAN总线发送数据，此时CAN总线的数据势必非常多，但CAN总线的带宽是有限制的，当从机越来越多的时候，这势必会影响数据传输的速度，为了避免这个现象，怎么办？
当Slave_N的N超过20之后，该主机与从机该采用怎样的方式进行通讯呢？
笔者目前的做法，是采用的是主机请求，从机响应的方式，即一问一答，这有点类似Modbus协议。这样的方式，势必能够保证单位时间CAN总线的带宽不会影响数据传输的速度，但这种做法的缺点，如果从机数量过多，主机遍历从机的时间肯定越来越长，笔者认为，针对这种情况，一方面可以提高CAN通讯的波特率，另一方面可以缩短主机访问从机的周期。
3、通讯的效率
通讯效率，这个词可能描述得不够恰当，但针对这个一主多从的系统，我们确实得考虑，数据交换的数量，数据交换的便利性，代码量等方面的问题。在本次系统设计时，从机作为仅仅作为被动相应者，只有主机请求时，从机才会响应，所有从机只对主机负责，一个从机不请求另一个从机，也不响应另一个从机。
目前本次系统采用简化版的CANOpen协议，真正的CANOpen协议，笔者没有还接触过，这个CANOpen协议是基于CAN的标准帧而制定的。
下面具体介绍下整个系统的一些细节
-
CAN通讯格式：标准帧
暂时因为项目中进行CAN的主机与从机数量有限，故采用标准帧即可，以后项目如果需求提高，可以采用扩展帧，扩展帧与标准帧的格式仅仅是ID长度的区别。
-
通讯速率：100Kbps
这是一个比较保守的波特率，因为暂时能够满足项目需求，故没有追求更高的波特率，在闭环总线上，CAN通讯速率最高可达1Mbps。
-
通讯周期：100ms
这是主机请求从机的周期，即主机每隔100ms，请求一个从机，然后相应的从机收到请求后，再响应。
-
CAN总线的物理连接方式：闭环总线通讯网络
即主机与最后一个从机的CAN通讯接口，会并联一个120欧姆的电阻，这是为了阻抗匹配，那什么叫阻抗匹配，笔者也不懂，百度了下，大家自行了解下：阻抗匹配是指负载阻抗与激励源内部阻抗互相适配，得到最大功率输出的一种工作状态。对于不同特性的电路，匹配条件是不一样的。阻抗匹配（Impedance matching）是微波电子学里的一部分，主要用于传输线上，来达至所有高频的微波信号皆能传至负载点的目的，不会有信号反射回来源点，从而提升能源效益。
-
通讯协议
通讯协议，怎么解释呢，笔者认为一方面是主机与从机的通讯的时候，具体的数据交换方式，这种方式决定着通讯数据的误码率、可靠性，决定整个系统的数据交换效率。另一方面，进行通讯的数据，如何存储，这决定着代码量等。
目前本系统中采用的通讯协议为简化版本的CANOpen协议，基于这套协议，从机可以将要和主机交换的数据都放在一个int型的数组中，该数组的长度为256，当然也可以更长，只是下面的协议要随之更改。
然后从机的数据存储方式，决定着整个系统的通讯协议，这套协议是基于CAN标准帧的最小单元而定的，也就是一帧标准帧数据而定的。主机在每帧数据中，可以访问不同从机，可以对从机中不同的数组元素进行访问，可以是读数组中的元素，也可以赋值给数组中的元素。然后从机收到主机的请求后，经处理之后，再发送给主机一个标准帧，这帧数据，是从机告诉主机通讯是否成功，同时也包含主机想要的内容。
| SDO |
|||||
|
|
|
序号 |
数据长度 |
说明 |
注释 |
| ID |
标志位 |
xFlag |
4bit |
SDO1Tx 0x0B SDO1Rx 0x0C |
发送 接收 |
| 节点ID |
NodeID |
7bit |
拨码开关 |
由硬件决定 |
|
| Hdata |
数据字典地址 |
DicDataID |
8bit |
0x00~0Xff |
对应数组的256个元素 |
| 指令 |
DicOrder |
8bit |
0x00 写 0x01 写成功 0x10 读 0x11 读成功 |
|
|
| 数据字典内容 |
DicData（w/r） |
16bit |
|
|
|
| Ldata |
保留 |
|
32bit |
|
|