Hello Jacob, On 11/4/19 3:29 PM, Jacob Schloss wrote: >> 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'll be doing a destructive commit to master soon and my USB protocol is not currently working correctly. I've tagged where I am for historical purposes as original-master, but it's not pretty at the moment. > 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. Well I haven't thoroughly analyzed this yet, but my current notation is adding a serial number to each URB, probably 8-bits, for ordering. iirc, bulk URBs are only dropped when there is insufficient bandwidth because they don't get allocated bandwidth like isochonus URBs do -- something I'm generally not counting. (I don't consider myself a USB expert, so if anything I say is wrong please correct me.) I'm only planning on supporting this from device to host for now, since the heavy throughput will almost always be when used as a sniffer. Host to device I'm leaving as-is. So my current notion is to just queue up out-of-order bulk IN URBs on the host side and wait until any missing ones are retransmitted in order to resume the stream. > 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 > I don't like how frame buffers work in candleLight or candy right now at all. I'll restructure this when I implement the FD CAN support. Daniel
