martinjaeger
commented
4 years ago 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: https://github.com/zephyrproject-rtos/zephyr/pull/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
(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