Ti的C28x系列的DSP(28069)(28377D)使用经验,CAN通讯经验(2)
在一个项目中,笔者接触过这样一个通讯系统,整个系统的通讯架构大概如下图,典型的一主多从。
如果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 |
|
|