On Apr 4, 2013, at 12:23 PM, Gareth McMullin <[email protected]> wrote:
> On Thu, Apr 4, 2013 at 12:00 PM, Jason Kotzin <[email protected]> wrote: >> I had a simple loopback test that would test the throughput of the USB and >> found that almost every time, the first four bytes would get dropped. >> Putting a substantial delay in the firmware on receipt of the setup packet >> fixed the problem, but obviously we couldn't take the bandwidth hit. > > USB Control transfers are not intended for high bandwidth. As far as > I know, this problem doesn't present itself on bulk transfers which > are intended for high bandwidth. I don't know the nature of your > application or if you were required to use control transfers for some > other reason, but this may have been a better solution. This was not meant to be a high bandwidth pipe, just a sanity check test. the i < 1000 turned out not to be substantial enough. We needed a delay on the order of 50-100ms. We had a bulk endpoint. > >> After all that, management concluded that we couldn't put anymore time on >> it, so we used STM's USB stack in conjunction with the rest of the libopencm >> source. >> >> We never found a solution and being that the same loopback test worked with >> the STM stack, I'd have to bare the unfortunate news that it's not in >> silicon, it's in libopencm. > > I'm not sure I agree with this conclusion. ST's code is much bigger > and slower, and an added delay in libopencm3 hides the problem. If > there is a condition we need to wait for and the silicon doesn't > provide a mechanism to do so, this is a bug in the silicon. I agree, from what we saw, there was a flag that would report when the last byte had transferred into the fifo, and that flag was not correct because the 4 bytes were missing. But ST micro's code did not suffer from this problem in the same test. I couldn't determine why, they checked the same flag. > >> We walked through stm's branch and compared this against libopencm's, but >> they were just too different, and stm's code was substantially larger. Also >> interesting, ST micro has their code stamped as USB certified, it would be >> curious to know if anyone's done the same certification test from usb.org on >> libopencm. > > In earlier days when I was actively working on this the libopencm3 > stack passed the compliance tests on the stm32f103. The HID example > failed some HID specific tests, but the CDC ACM example passed > everything. This was a while back, so we may have regressed, but I > think it's unlikely. The f105/f4 driver didn't exist at the time and > as far as I know hasn't been tested. Yes, larger is not better, no one at the company liked their implementation, but we ran out of time. > > Regards, > Gareth > > -- > Black Sphere Technologies Ltd. > > Web: www.blacksphere.co.nz > Mobile: +64 27 777 2182 > Tel: +64 9 478 8885 > Skype: gareth.mcmullin > LinkedIn: http://nz.linkedin.com/in/gsmcmullin ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html _______________________________________________ libopencm3-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
