Hi Jeroen, > Are you aware of https://github.com/candle-usb/candleLight_fw? > That uses a one on one binary version of the socketcan driver. > > That _might_ be straightforward to extend to FD. And that really > is a might, since I don't know how it is implemented, but I would > guess it is a flag. I have used a device that used the candleLight_fw, but our board is not compatible and we already have our own implementation of the Lawicel text protocol working. I could add support for another protocol, it looks like candlelight is dropping a struct defined here https://github.com/candle-usb/candleLight_fw/blob/master/include/gs_usb.h, padded out with zeros to fill a max size USB packet. I guess this is the can/usb/gs_usb.c driver on Linux's side? I think it would be easier (for me at least) to extend the text mode protocol used by net/can/slcan.c. It would also keep it possible to use the device by hand in a pinch. Since I'm high speed USB, the extra protocol overhead for ascii encoding seems ok. Hmm. Extending both gs_usb.c and slcan.c for CAN FD might be useful : ). For gs_host_frame, I guess what is needed is making the data field longer and adding code to decode can_dlc and update appropriately everywhere? I'm not sure if there is any other packet framing/header or if it is assumed that a packet starts and finishes within a USB transaction? A full size CAN FD packet doesn't fit in a single USB FS packet, so would need a way to split across 2 USB FS packets. It might force the protocol to look a bit different. Thanks, - Jacob
