I am working on creating a driver for Texas Instrument’s TCAN4551 IC that integrates a CAN controller and transceiver in one package. It is compatible with both classical CAN and CAN-FD and allows you to add this functionality to any MCU supporting SPI.
From my understanding, CAN-FD is really not much different from classical CAN (currently supported).
The main differences I have identified:
- CAN-FD allows a faster bit-rate during the data frame of the CAN transmission (so there are two frequencies to set, arbitration/nominal and data-rate)
- CAN-FD supports payloads in several additional lengths beyond 8-bytes. Namely, 12, 16, 20, 24, 32, 48, and 64
- CAN-FD has a slightly different packet format (a few extra bytes in the header)
I’m wondering what would be a better path forward for adding these extensions:
1.) Rework the mbed::CAN class itself to add CAN-FD when DEVICE_CANFD is 1
2.) Create an entirely new sub-class of mbed::CAN that is mbed::CAN_FD
I’m leaning more towards option 1. It would look more like the asynchronous APIs then and wouldn’t add another code file to read. There aren’t many extra operations.
Furthermore, to reduce the possible size of CANMessage structs, the max CAN size can be configured by a user’s mbed_app.json. If a user only needs up to 16-byte payloads, they can modify this parameter and save the extra 48-bytes usually allocated to the 64-byte maximum in CAN-FD.
Anyone else have any thoughts?