> 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 > Hi Daniel, Sounds interesting, I'll take a look at the repo, and will look at what it would take for my firmware to be multi-protocol. I suppose stream sync loss will be rare, and could do a USB reset as a worst case recovery. This is my first USB device, so haven't done much error / stream sync recovery on USB yet, just UART where I needed explicit synchronization. I need to do some more hardening on my device side. It would be difficult for my code as-is to resync on a failed USB packet since the payload is just dumped in a FIFO that the app is waiting on and the application part doesn't even really know it is USB or where the packet boundaries are. Probably just need to add some event hooks for errors the app can use. - Jacob
