Hello Jacob, On 10/26/19 9:27 PM, Jacob Schloss wrote: > Hi, > > We've made a little CAN-USB adapter that is mostly compatible with the > Lawicel AB text mode protocol that is common for serial-to-can > adapters, but with some extensions for CAN FD. > > https://github.com/suburbanembedded/hadoucan-fw > https://www.tindie.com/products/suburbanembedded/hadou-can-usb-can-fd-adapter/ > > User Guide > https://drive.google.com/open?id=1MtYEAVDF2ImoV_6nmfjP3o9sGMMwxck2wRqLRCWhaTU > > The device supports CAN FD, and I arbitrarily picked a new ascii > command to support sending and receiving CAN FD packets, but it would > be interesting if we could standardize FD support and add it to slcan. > > Right now I'm using 'd' for an FD message with an 11 bit id, 'D' for a > FD message with a 29 bit id, and permitting FD frames to have DLC > codes 9-F. I can change that if needed. BRS is enabled separately via > a config setting. > > Does it make sense to try and coordinate an extension to the text mode > protocol? I'd like to be able to send CAN FD frames through > slcand/cansend etc and keep compatibility with any new hardware that > might start coming out. 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. With kind regards, Jeroen
