Hello, and thank you for CCing me Jeroen. I am working on firmware for CAN FD using the STM32G4xx line. I've forked candleLight_fw and am modifying the gs_usb driver. In short, my immediate need is to have "classic" CAN working on this chip so we can push a firmware update later when customers start needing FD CAN. So while FD CAN isn't implemented yet, there are very few changes needed in the firmware to support it (once classic CAN is done). The firmware is still in a *very experimental* state, but if you like looking ugly code, then: https://git.gsat.us/dansan/candy On 10/31/19 2:41 PM, Jeroen Hofstee wrote: > 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. In my firmware fork, I'm pulling in a number of headers from the Linux kernel (making it GPL2), but I have a conflict with the license of ST's USB stack (so I'll have to replace the USB stack we're using eventually). I plan on submitting a patch to separate out the common structs and #defines in gs_usb.c into a include/linux/can/gs_usb.h (or such) solely for the purpose of facilitating cleaner integration with various firmware code. Then I can just import or #include that into the firmware project. >> 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 I have been forced to modify the USB protocol because I need get 2Mbps of CAN to work on FS USB and the current protocol won't get there. I cobbled together a crude bit-packed mechanism, but I had forgotten about the FD CAN 64-byte payload scenario! Since this is still in flux it would be a perfect time to design a better protocol. I haven't used slcan and I don't know about it's protocol, other than it would have to be ascii-based. Given all of this, I *think* I'll design the USB protocol to always re-submit dropped bulk IN URBs and drop any CAN/FD frames that are received in excess of the device's internal buffer. I *think* I would rather do that than design a re-sync mechanism for when a bulk IN URB is dropped (i.e., instead of dropping the frames in that failed URB). I'm working by the general assumption that the device is attached to a hub that is HS and that the bottleneck will be between the device and the first hub. Daniel
