MD1系列CAN STACK协议栈DEMO问题

[yifeng_xie]

使用此DEMO时发现MCU接收上位机报文时出现问题，表现为上位机正常发，但是MCU没有打印接收到的信息。

CANoe的硬件设置如上所示。

CANoe设置CAN报文如上所示。

CANoe设置CANFD报文如上所示。

仿真的时候发现代码在这里直接break了，最终接收中断回调函数RxIndication并没有进入。

想问下，是CANoe哪里配置有问题，还是YCT需要额外配置别的东西呢？

[jiankang_wang]

你 CanStack 开得有padding，接收到的can报文长度不是7就丢掉了

[yifeng_xie]

jiankang_wang

YCT里面看到CAN2的padding功能并没有开启呀

[jiankang_wang]

这个不是在Can模块的配置界面配置的。要在CanStack配置界面里：

[yifeng_xie]

jiankang_wang 在 MD1系列CAN STACK协议栈DEMO问题 中说：

最后由 编辑
#4
这个不是在Can模块的配置界面配置的。要在CanStack配置

想再问下，为什么是7字节不到就丢弃了呢？正常周期性报文，DLC是8字节的，这8字节并不是长度字节。但是看代码实现，确实是拿了第一字节用于判断长度。不是很理解这个padding的作用

[yifeng_xie]

代码里面是在这里使用了第0字节的数据来判断长度。

CANoe的发送的报文，第0字节是4。

[jiankang_wang]

开了padding，长度不够的消息会被丢掉，这是协议规定的。

代码里面这部分分支是根据接收到的can报文和配置项计算允许的SF的长度，所以这里的SF_DL就是取第0个或者第1个字节。至于这里的RX_DL，就是can报文的长度。

padding的意思，就是在消息长度不够一个can报文长度的时候，使用填充字节填充消息长度到can报文长度，例如发送8个字节的can报文，消息长度是1，填充是0xcc，总线上实际应该看到的报文是：

0    1    2    3    4    5    6    7
0x01 0x55 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 

如果不开，就是这样的

0    1
0x01 0x55

[yifeng_xie]

jiankang_wang
王工，是不是哪里有问题？
ISO-15765-2处理的是TP层的事情，那用来接收周期性的应用报文是不是有问题？标准周期性报文还不涉及ISO-15765-2，只是老老实实搬运一下RX_DL长度的数据就好了。

[jiankang_wang]

你们是需要TP接收到无关的消息的时候转到Can报文的处理逻辑是吧？这个的话CanStack确实是没做处理的，需要你自己改下EventCallback函数。

[yifeng_xie]

jiankang_wang
好的，谢谢王工。额外咨询下，后续CAN STACK会支持解析普通周期性报文吗（YCT上勾选是否周期性报文，中断内判断报文类型，然后有2个分支）？或者现有的CAN STACK/UDS STACK怎么与周期性报文的收发融合呢？

[jiankang_wang]

后续不会增加对应内容。

因为不管是只用flexcan还是只用CanStack，或者两者都需要用，都是需要修改对应的中断callback，而中断callback是只有一个的，所以就只能注入一次。而CanStack是一个middleware，不应该去修改flexcan的驱动。

CanStack注册的中断callback是这样的：

如果用户有其他普通的can报文需要处理，可以直接再这个函数中修改，就跟直接使用flexcan接收是一样的

[yifeng_xie]

jiankang_wang
懂了，手动修改代码后，经TP层转发，报文收发已经正常。想问下，CAN STACK现在每个TP Channel都是1个发送ID与1个接收ID，那对于仅有发送或者仅有接收的情况是否支持呢？

[jiankang_wang]

目前TP层是固定了的，一个通道占用两个邮箱，一个用于发送，一个用于接收。不管这个TP Channel是否是功能寻址。

TP Channel在接收长消息的时候，还需要回复流控帧，所以不管是只接收还是只发送，都用到了两个邮箱。

如果只是接收或者发送短消息，就当作一个正常 Can 报文转发就行了，不需要使用TP