非FD("遗留"(CAN帧在SocketCAN中具有以下格式:
struct can_frame {
canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
__u8 can_dlc; /* frame payload length in byte (0 .. 8) */
__u8 __pad; /* padding */
__u8 __res0; /* reserved / padding */
__u8 __res1; /* reserved / padding */
__u8 data[8] __attribute__((aligned(8)));
};
帧 ID、长度和数据都有清晰的位置,还有一些我们不担心的填充。 但是,对于CAN-FD框架,还有一个额外的字段:
struct canfd_frame {
canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
__u8 len; /* frame payload length in byte (0 .. 64) */
__u8 flags; /* additional flags for CAN FD */
__u8 __res0; /* reserved / padding */
__u8 __res1; /* reserved / padding */
__u8 data[64] __attribute__((aligned(8)));
};
flags
字段看起来很有用,但我没有找到关于它实际包含的文档。 它是内部的(即由内核设置(吗? 可能的标志是什么,它们是什么意思?
谢谢!
我在这里找到了一些信息:
http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/can.h#L112
/*
* defined bits for canfd_frame.flags
*
* The use of struct canfd_frame implies the Extended Data Length (EDL) bit to
* be set in the CAN frame bitstream on the wire. The EDL bit switch turns
* the CAN controllers bitstream processor into the CAN FD mode which creates
* two new options within the CAN FD frame specification:
*
* Bit Rate Switch - to indicate a second bitrate is/was used for the payload
* Error State Indicator - represents the error state of the transmitting node
*
* As the CANFD_ESI bit is internally generated by the transmitting CAN
* controller only the CANFD_BRS bit is relevant for real CAN controllers when
* building a CAN FD frame for transmission. Setting the CANFD_ESI bit can make
* sense for virtual CAN interfaces to test applications with echoed frames.
*/
如果我理解正确,ESI 位仅用于测试虚拟 CAN 交互。 但是,BRS 位是相当低级的,这并没有指定硬件是自动设置还是取消设置它。