CAN: Forbidding DLC>8 is more restrictive than the CAN 2.0 specs.

[ocornu]

A CAN 2.0 frame may carry a data payload, 0 to 8 bytes long. The DLC header field, coded over 4 bits (0 to 15), serves as an indicator for this length. However, it is not the payload length (hence the name: Data Length Code):

1. The most obvious case is Remote Transmission Request frames, which carry no payload, yet may have a DLC>0 (usually interpreted as the size of the data payload requested).
2. A less common case is frames with a DLC>8 (9 to 15): they still code for a payload of size 8 (the longest payload possible for a CAN 2.0 frame) but also carry extra information.

This extra information is not part of the CAN 2.0 standard itself, yet the standard does not forbid it explicitly either. Thus it is common for hardware controllers to support it.

For example, the very popular MCP2515 manual states (p. 22):

It is possible to set the DLC[3:0] bits to a value greater than eight; however, only eight bytes are
transmitted.

It is also commonly supported by embedded controllers, for example the ESP32-S3 TWAI (p. 1205):

The Frame Data field contains the payloads of transmitted or received data frame, and can range from 0 to eight bytes. The number of valid bytes should be equal to the DLC. However, if the DLC is larger than eight, the number of valid bytes would still be limited to eight.

As it is, the embedded-can traits are more restrictive than the CAN standard and do not allow this legitimate use of the DLC field, both on the Tx and Rx side:

/// A CAN2.0 Frame
pub trait Frame: Sized {
    /// Creates a new frame.
    ///
    /// This will return `None` if the data slice is too long.
    fn new(id: impl Into<Id>, data: &[u8]) -> Option<Self>;

    /// Creates a new remote frame (RTR bit set).
    ///
    /// This will return `None` if the data length code (DLC) is not valid.
    fn new_remote(id: impl Into<Id>, dlc: usize) -> Option<Self>;

    ...

    /// Returns the data length code (DLC) which is in the range 0..8.
    ///
    /// For data frames the DLC value always matches the length of the data.
    /// Remote frames do not carry any data, yet the DLC can be greater than 0.
    fn dlc(&self) -> usize;

• Frame::new() does not support specifying a custom DLC: it is designed for data.len()
• Frame::new_remote() straight up returns None if DLC > 8
• Frame::dlc() assumes that DLC is the actual length of the data (when there is any): "For data frames the DLC value always matches the length of the data", and therefore constrains it to the [0; 8] range

As a result, developers are stuck between a rock and hard place: support real world devices (and the CAN 2.0 standard), or be compatible with embedded-can.