CAN FD for ThingSet

[sAlexander]

(Feature request for consideration)

Have you considered adding support for CAN-FD to ThingSet? The increased payload capacity could significantly reduce the amount of overhead for each message (as a % of the message size) and increase throughput; experiments with the Linux ISO-TP and ISO-TP:2015 drivers showed a 9-11x increase in the throughput for CAN-FD for larger message sizes with little impact on the smaller messages [0].

CAN-FD MCUs are certainly not as prevalent as CAN MCUs, but they are becoming more and more common. From STMicro, the STM32G4 (Cortex M4) already supports CAN FD, and the upcoming STM32G0B1 (Cortex M0+) will support CAN FD. I'm experimenting with the Atmel SAM C21 (Cortex M0+), which has support for CAN FD.

It doesn't have to be all or nothing: ThingSet could support a mixed network of CAN and CAN-FD devices. ISO-TP was extended to have some interoperability between CAN and CAN-FD devices [1] and of course CAN itself supports interoperation with other CAN-FD devices. ThingSet devices could advertise support for CAN-FD (with an info object for each device); when CAN-FD compatible devices are communicating, they could use CAN-FD and otherwise use CAN.

A majority of ThingSet would support CAN-FD without any modification. The one area that might benefit from a bit of adaptation would be the publish protocol. Currently, the publish object expects that exactly one item will be published per can message. With the 64 byte payload in a CAN-FD message, it would make sense to publish many values at once.

[0] "With the relatively short STmin of 100µs the PDU data throughput can be increased by factor 11 (230.769 / 20.533) – even with a configured block size of 15 which requires the receiving node to acknowledge every 15th CF frame. Without bitrate setting (BRS) the benefit of 64 byte CAN frames reduces to factor 2.5 due to the better overhead ratio. Finally the measurements points out that using CAN FD without BRS and with LL_DL of 8 preforms worse than classic CAN. As CAN FD introduces additional control bits, an increased CRC field size and a stuff bit counter in the latest ISO implementation this performance reduction was expected."
https://www.can-cia.org/fileadmin/resources/documents/proceedings/2015_hartkopp.pdf
[1] See section "ISO 15765-2:2015 with CAN FD" of https://www.can-cia.org/fileadmin/resources/documents/proceedings/2015_hartkopp.pdf

[martinjaeger]

I fully agree, CAN FD would be a nice option to increase throughput.

You may have noticed that the newest MPPT design uses the mentioned STM32G4, so it would be prepared for CAN FD.

We are currently in the process of porting the MPPT firmware to Zephyr (which is almost finished). Already got the "normal" CAN with ISO-TP running a few weeks ago in the BMS firmware.

The Zephyr driver will probably support CAN FD quite soon, as there is a promising PR ongoing: zephyrproject-rtos/zephyr#22832

Having some sort of data object to advertise support of CAN FD seems like a good idea. In general it shouldn't be a big change for the protocol to support longer messages. I'm not sure, does ISO-TP support CAN FD, i.e. is there an updated version of the standard?

[sAlexander]

does ISO-TP support CAN FD, i.e. is there an updated version of the standard?

It looks as though ISO 15765-2:2016 is the updated version of the standard. Quoting from the abstract of that standard (which is not freely available -- errgggg):

"ISO 15765-2:2016 specifies a transport protocol and network layer services tailored to meet the requirements of CAN‑based vehicle network systems on controller area networks as specified in ISO 11898‑1"

"ISO 11898‑1 specifies variable length CAN frames with a maximum payload size dependent on the protocol device used. A CLASSICAL CAN protocol device can transmit/receive frames with payload sizes ranging from 0 bytes to 8 bytes per frame. A CAN FD (flexible data rate) protocol device can transmit/receive frames with payload sizes from 0 bytes to 64 bytes. A CAN FD protocol device is also capable of transmitting/receiving CLASSICAL CAN frames."