After the the recent flurry of patches, the situation with full-speed USB is somewhat ambiguous.
Enumeration of full-speed devices now usually succeeds. The time between the EOP of an incoming DATAx packet and the SOP of the ACK is also quite reasonable. E.g., this is an IN0/0 DATA1 ACK sequence: http://downloads.qi-hardware.com/people/werner/m1/usb/usb-951ns-ack.png The time between EOP and SOP is about 951 ns or 11.4 bit clocks. This time can vary a little, depending on where the Navre is in its poll loop when the EOP happens, but we now have what looks like a reasonable safety margin. Things aren't so great when it comes to data integrity afterwards. While my low-speed devices are performing pretty much like they always did, here are a few attempts at typing "the quick brown fox jumps over the lazy dog" on my HHKB Pro, a full-speed device: http://downloads.qi-hardware.com/people/werner/m1/usb/usb-fs-kbd-garbled.jpg While one may consider this a quite respectable result after an intense night at the club, my sober and reasonably well rested self can do better. The problems are lost key up/down events and also what looks like data corruption. I'm not quite sure where all this joy comes from. Possible candidates include: - poor (analog) signal integrity on the USB - contamination on the digital side (between FPGA and transceiver) - marginal bit clock recovery in the SoC - difficulty catching the SYNC and locking onto bytes - other weirdness in the SoC - data overruns in the SoC-to-Navre path - starting operations before the previous operation has finished - other bugs in the Navre firmware - data overruns in the Navre-to-LM32 path We currently don't have CRC checks on inbound data. The code is now structured such that dropping in CRC calculation shouldn't be overly difficult, but I first need to get the progmem increase to work, because the lookup table for a fast CRC implementation would exceed the ~120 bytes currently left. A CRC check would catch most bit-level issues and greatly reduce the probability for such problems to reach higher layers, but even if a CRC causes dramatic improvements, we should still try to solve the underlying problem that causes such a large amount of corruption. - Werner _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode
