Tool/software:
According to the Technical Reference Manual for the 2838x, the DCAN End of Block flag should be set to 1 when working with a single message object.
[EoB value of 1 indicates] The message object is a single message object or the last message object in a FIFO Buffer Block.
Note: This bit is used to concatenate multiple message objects to build a FIFO Buffer. For single message
objects (not belonging to a FIFO Buffer), this bit must always be set to one.
In our application each mailbox is configured to send or receive a single CAN ID. I was stress testing our MCAN and DCAN implementations to see what happens when messages are not read as fast as they are received and noticed an unexpected (and apparently undefined) behavior. Here is a snippet of the code to illustrate the mailbox configuration:
frame = CAN_MSG_FRAME_STD;
filter = CAN_MSG_OBJ_USE_ID_FILTER;
filter |= CAN_MSG_OBJ_FIFO; // Toggle EoB here
CAN_setupMessageObject(obj->portHandle, aMailBox + 1, aId, frame,
CAN_MSG_OBJ_TYPE_RX, 0x1FFFFFFF, filter,
aLen);
- With EoB = 0, we read the most resent message sent (older messages appear to be overwritten)
- With EoB = 1, we read the first message sent since the last read (new messages are thrown away)
Personally I refer the first option, where I receive the newest data. I don't want to operate on stale data. We provide a general purpose tool, so it would be preferable to me to always have fresh data as a default, in case a user has configured their CAN reads at an imperfect rate relative to the message transmit rate. However the documentation seems to suggest this is an erroneous configuration and the behavior (which seems consistent in my testing) would appear to be undefined.
Can you comment on the use of EoB for single message objects? If I expected anything it would have been the reverse of these results.
Thanks!
Zia