On 10/27/20 2:23 PM, Oliver Hartkopp wrote: > On 27.10.20 14:06, Marc Kleine-Budde wrote: >> On 10/23/20 10:30 PM, Oliver Hartkopp wrote: >>> ISO 11898-1 Chapter 8.4.2.3 defines a 4 bit data length code (DLC) table which >>> maps the DLC to the payload length of the CAN frame in bytes: >>> >>> DLC -> payload length >>> 0 .. 8 -> 0 .. 8 >>> 9 .. 15 -> 8 >>> >>> Although the DLC values 8 .. 15 in Classical CAN always result in a payload >>> length of 8 bytes these DLC values are transparently transmitted on the CAN >>> bus. As the struct can_frame only provides a 'len' element (formerly 'can_dlc') >>> which contains the plain payload length ( 0 .. 8 ) of the CAN frame, the raw >>> DLC is not visible to the application programmer, e.g. for testing use-cases. >>> >>> To access the raw DLC values 9 .. 15 the len8_dlc element is introduced, which >>> is only valid when the payload length 'len' is 8 and the DLC is greater than 8. >>> >>> The len8_dlc element is filled by the CAN interface driver and used for CAN >>> frame creation by the CAN driver when the CAN_CTRLMODE_CC_LEN8_DLC flag is >> >> CC stands for Classic CAN? Is this the "official" name? > > No. It is 'Classical CAN'. I'm not very happy with that naming as there > was already a 'CAN2.0B' specification to separate from the first version > which only had 11 Bit identifiers. This could be Ancient CAN now :-D So Classical CAN is CAN2.0B? >> For example there was a press release to harmonize the CAN transceiver nameing >> recently: >> >> https://can-cia.org/news/press-releases/view/harmonized-transceiver-naming/2020/7/16/ > > Yes, there you can find: > > "CAN high-speed transceivers might be used in Classical CAN, CAN FD, or > CAN XL networks" Doh! I should have re-read that article :) We found it, when we were searching for consistent naming for the different CAN transceivers. > Maybe we could update some comments and documentation for CAN2.0 -> > Classical CAN later. Good point. [...] >>> + union { >>> + /* CAN frame payload length in byte (0 .. CAN_MAX_DLEN) >>> + * was previously named can_dlc so we need to carry that >>> + * name for legacy support >>> + */ >>> + __u8 len; >>> + __u8 can_dlc; /* deprecated */ >>> + }; >> >> There was an old compiler version, which struggled with C99 initialized unions >> within structs.....So this change would break existing source, but I think that >> old compilers are long gone (for good). > > Good to know. Do you know 'version numbers', so that we may place a > warning somewhere? No, I don't remember. Some old gcc-3.x > I still have a 2.6.28 system here (gcc 2.95) - but I would not know why > updating the can-utils there today. Maybe for the cansniffer ;-) > > Btw. when it is only about the initialization of static struct > can_frame's, I can also check for these cases in can-utils. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: OpenPGP digital signature
