Hello Jacob, On 10/29/19 5:26 AM, Jacob Schloss wrote: > 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? It is indeed the gs_usb driver and send a struct as binary compatible with socketcan, it is not padded though. It also support status events / error counters / loopback etc. > 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. Understood, I have nothing against that. Only wanted to mention that there are other options.. > 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. > What could perhaps be done, is concatenate the messages, since the size is known. Some care has to be taken though how to get in "sync" again perhaps and likely some handshaking that both side support that. I think the kvaser does something similar. I haven't look at that in detail though, but it might be interesting for throughput reasons as well. With kind regards, Jeroen
