Objective Development Forums

You are right. ms, not µs.

I just tested V-USB and Win10 for the first time - and yes, more things have changed to the worse. It seems that the win10 drivers reduce the time between USB reset and the first datapacket to less than 20µs. This means that osccalASM.s can not complete on devices using the internal oscillator. Imag...

It should be possible to detect if D+ is pulled low after the forced buis reset. The 10kOhm pull down of the host should do that. It may be beneficial to activate the pull up on the client side for D+.

Has anybody tried this, and does it work realiabilty?

Did I miss something or is V-USB never initializing the port register , but is instead relying on it having a default value of 00 for both D+ and D-?

I also noticed odd things when connecting V-USB devices to USB3.0 hubs.

- Somehow it takes much longer for a devices to be recognized. The host will simply wait forever to start enumeration? Why? Very confusing.

- Things get out of sync fairly often.

Very interesting, so the theoretical limit of +-0.35% with CRC is spot on. It should be +-0.43% when the CRC of incoming packets is ignored. An additional cycle of margin should increase the allowable clock deviation to 0.44% with CRC (5/1122). At 16MHz this is +-71kHz, while 0.35% equals +-57kHz. T...

So, my conclusion is that the allowed clock deviation is 0.35% or 0.43% at 16.5 Mhz for receiving data, and 1.5% for sending. I recently did some experiments with a high-precision clock generator (AD9850) to see how much deviation was tolerated. I tested the 16MHz version of V-USB, and it worked re...

Could you post a blog on getting the ATTINY841 working with V-USB? Actually that is not more complicated than getting it to work with an ATtiny85. You just have to include the osccal code (you can use my optimized osccalASM.s*) and set F_CPU to 12MHz or 12.8MHz. The latter results in larger code si...

Some write up for those interested:

http://cpldcpu.wordpress.com/2014/03/19 ... attiny-10/

No, V-USB only supports Low-Speed USB and even that only with limited throughtput. You will at least need a full-speed USB device for your requirements.

Also mirroring my response here Although I am not familiar with your problem, the reason could indeed be similar. I have also observed that things depend on the operating system and usb hub as well. You can easily emulate the behavior of the interrupt-free V-USB and avoid the NACKing problem by disa...

I wrote a blog article to explain the interrupt-free V-USB implementation that will be used in the upcoming USB Bootloader Micronucleus V2. The idea of implementing a polled-version of V-USB was brought up in this forum by blarrg. m I think it is pretty interesting, since the approach of intentional...

No answer? Where did all the USB experts go?

A lot of the complexity of V-USB comes from the requirement to do de-stuffing and xoring of the USB datalines in real time. I have been wondering - is this really necessary? V-USB does not process most of the packet contents in realtime, so why not move some more processing off-line? Basically only ...

I am wondering about the reasoning behind the clock accuracy requirements of V-USB. After all, the USB specification itself is much more relaxed: ⋅ High speed data is clocked at 480.00Mb/s with a data signalling tolerance of ± 500ppm. ⋅ Full speed data is clocked at 12.000Mb/s wi...