<div dir="ltr"><div dir="ltr"><div>Hi All,</div><div><br></div><div>This is to present the updated CAN message structure.</div><div><br></div><div><b>Updating the CAN message structure:</b></div><div><br></div><div><span>struct can_message {</span></div><div><span><span> uint32_t id; // 32 bits to support extended id (29 bits)</span></span></div><div><span> uint32_t timestamp;<br> uint16_t flags; // RTR | BRS | EXT ...<br> uint16_t len;<br> uint8_t data[64]; // For supporting data transfer up to 64 bytes.<br> };</span></div><div><span><br></span></div><div><span>Regards</span></div><div><span>Prashanth S<br></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 21 Jun 2022 at 14:43, Oliver Hartkopp <<a href="mailto:socketcan@hartkopp.net" target="_blank">socketcan@hartkopp.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Christian,<br>
<br>
I'm not subscribed to the RTEMS ML so my mail has not been forwarded.<br>
<br>
I'm with you about the 16 bit length info.<br>
<br>
See below ...<br>
<br>
On 6/21/22 08:55, Oliver Hartkopp wrote:<br>
> Hello all,<br>
> <br>
> I'm definitely with Pavel's suggestions here!<br>
> <br>
> I added some small remarks regarding the current CAN XL discussion in-line:<br>
> <br>
> On 20.06.22 22:57, Pavel Pisa wrote:<br>
>> Hello Prashanth S and others,<br>
>><br>
>> excuse me for lower activity last weeks. We have exams period<br>
>> and I have lot of other duties and was even ill. I am at Embedded<br>
>> World in Nuremberg now, so may it be there is some chance to meet<br>
>> somebody other from RTEMS community.<br>
>><br>
>> As for the e-mail it is better to add one of my personal e-mails<br>
>> (<a href="mailto:pisa@cmp.felk.cvut.cz" target="_blank">pisa@cmp.felk.cvut.cz</a> or <a href="mailto:ppisa@pikron.com" target="_blank">ppisa@pikron.com</a>)<br>
>> to notice me for something important, I do not check every<br>
>> message comming through my list subscription. I go through<br>
>> RTEMS, NuttX, CAN, etc. forums only when I have spare time.<br>
>><br>
>> On Monday 20 of June 2022 18:37:38 Prashanth S wrote:<br>
>>> This is a request for suggestions and feedback for the CAN message<br>
>>> structure.<br>
>>><br>
>>> *CAN message structure that represents the can messages from <br>
>>> application to<br>
>>> driver:*<br>
>>><br>
>>> struct can_message {<br>
>>> uint32_t timestamp;<br>
>>> uint32_t id; // 32 bits to support extended id (29 bits)<br>
>>> uint16_t flags; // RTR | BRS | EXT ...<br>
>>> uint8_t dlc; // (0 - 8) | 12 | 16 | 20 | 24 | 32 | 48 <br>
>>> | 64<br>
>>> uint8_t res; // reserved for alignment.<br>
>>> uint8_t data[64]; // For supporting data transfer up to 64 <br>
>>> bytes.<br>
>>> };<br>
>>><br>
>>> This is the CAN messages structure created based on the suggestions <br>
>>> in the<br>
>>> mail chain and looking through other CAN solutions (Nuttx, GRCAN, <br>
>>> LinCAN).<br>
>><br>
>> Yes I like solution with explicit and aligned fields.<br>
>> I confirm that I think that length representing real data length is <br>
>> better<br>
>> and it has been chosen for CAN FD by SocketCAN.<br>
> <br>
> Yes. Handling the DLC/Length conversion in every user program is a mess. <br>
> That's why we actually changed the dlc to len even for Classical CAN <br>
> frames in the struct can_frame:<br>
> <br>
> struct can_frame {<br>
> canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */<br>
> union {<br>
> /* CAN frame payload length in byte (0 .. CAN_MAX_DLEN)<br>
> * was previously named can_dlc so we need to carry that<br>
> * name for legacy support<br>
> */<br>
> __u8 len;<br>
> __u8 can_dlc; /* deprecated */<br>
> } __attribute__((packed)); /* disable padding added in some <br>
> ABIs */<br>
> __u8 __pad; /* padding */<br>
> __u8 __res0; /* reserved / padding */<br>
> __u8 len8_dlc; /* optional DLC for 8 byte payload length (9 .. <br>
> 15) */<br>
> __u8 data[CAN_MAX_DLEN] __attribute__((aligned(8)));<br>
> };<br>
> <br>
> You might also think about a union to carry the Classical CAN length and <br>
> the CAN FD length in one 8 bit value and add the extra Classical CAN raw <br>
> DLC in another 8 bit value - and make a union with a 16 bit length value <br>
> which is needed for CAN XL.<br>
> <br>
> <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/uapi/linux/can.h?id=ea7800565a128c1adafa1791ce80afd6016fe21c" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/uapi/linux/can.h?id=ea7800565a128c1adafa1791ce80afd6016fe21c</a> <br>
> <br>
> <br>
> But in fact the raw DLC value has been introduced only because of some <br>
> people doing security testing. The Classical CAN raw DLC value has no <br>
> value for normal CAN applications and therefore using a simple 16 bit <br>
> length value would be the best choice IMHO (see below).<br>
> <br>
>> I confirm that flags implemented with explicit sized field seem to be <br>
>> more<br>
>> safe to me. Bitfields are tricky due to endianing and have problem with<br>
>> initialization and copying when new field is added.<br>
>><br>
>> I am not sure if the field name "dlc" (data length code) is right<br>
>> when the field represents real length, may be "len" is a better<br>
>> match.<br>
> <br>
> Yes, definitely!<br>
> <br>
>> I think that fields order makes sense as well (alignment, purpose etc..).<br>
>> Only think to consider is possibility to swap<br>
>><br>
>> uint32_t timestamp;<br>
>> uint32_t id;<br>
>><br>
>> because id is the first and the most important and accessed field,<br>
>> so when the pointer to structure is give it can be small win<br>
>> on some targets that it can be accessed without offset addition.<br>
>> But that is probably neglectable and there can be arguments against.<br>
> <br>
> The 'id' really defines the CAN frame so it can be seen as a 'key' - <br>
> like in a data base. It makes sense to put it first.<br>
> <br>
> Btw. adding RTR and EXT to the flags field is something I would do today <br>
> too. Good choice!<br>
> <br>
>> Another think to consider is a size of "dlc" and or "len" code.<br>
>> There is ongoing standardization process for CAN XL and it<br>
>> would allow CAN frames up to 2kB and the length will be with<br>
>> byte granularity. But CAN XL adds datatype filed and much more<br>
>> options so it is probably out of the actual RTEMS scope<br>
>> and would require variable length read and write systemcalls<br>
>> because 2kB overhead for some 1 or 2 byte message is too high.<br>
>><br>
>> So even 8 bit length field is OK for now and may be res field<br>
>> can solve CAN XL compatibility one day.<br>
> <br>
> Why not defining the len as an uint16_t right now?<br>
> <br>
> In fact we (at SocketCAN) need to move the length structure element for <br>
> CAN XL now which is no fun.<br>
> <br>
> As you would have a 16 bit length field and a 16 bit flags field you <br>
> will be CAN XL ready from the beginning.<br>
> <br>
> The only element that needs to be introduced 'before' the data[] is the <br>
> 32 bit acceptance field ('AF').<br>
> <br>
> The fact whether AF is present or not could probably be determined by a <br>
> CAN XL flag in the flags element.<br>
> <br>
> The 8 bit virtual CAN ID (vcid) of CAN XL will likely not be visible in <br>
> struct canxl_frame as the vcid will be transported and accessed similar <br>
> to the vlan id in ethernet in Linux. You will need to create a tagged <br>
> network interface analogue to the ethernet vlan handling.<br>
> <br>
>> So generally I agree with the message structure, I declare<br>
>> minor weight vote to switch from "dlc" to "len".<br>
>> I think that switch to common message structure based API<br>
>> on RTEMS would be big win and that (at least for<br>
>> now) keeping character device like API with IOCTLs<br>
>> is simpler and matches better actual RTEMS CAN implementations.<br>
>><br>
>> Best wishes,<br>
>><br>
>> Pavel<br>
> <br>
> Best regards,<br>
> Oliver<br>
</blockquote></div>
</div>