modify usbFunctionRead

[nxtv2]

I saw sites that refere to the poll rate as refresh rate so i thought they are same.
I stand corrected.

The fastest poll rate i got was 1ms, can i go faster?.

[ulao]

You already asked that...

You seem to be failing at understating here. As mentioned a few times now...

1) The poll rate/refresh rate/speed/whatever you want to call it is 8ms or 125Hz.
2) There is no way to change this other then hacking the driver.

So you said I was able to get 1ms, if you explain how you did that maybe I can offer advice. As it stands there is no way to do that other then a driver hack. The driver hack is a whole number so you can not put in .5 thus 1 is as low as you can go.

[nxtv2]

I got it by setting

Code: Select all

USB_CFG_INTR_POLL_INTERVAL

to 1.

Can i get faster?
I have tried setting it to 0 , but it just defaults to 8.

[ulao]

#define USB_CFG_INTR_POLL_INTERVAL 1
/* If you compile a version with endpoint 1 (interrupt-in), this is the poll
* interval. The value is in milliseconds and must not be less than 10 ms for
* low speed devices.
*/

Again, your not understating things. All the info is right in front of you.

1) This is the setting for the endpoint 1 not the default endpoint.
2) V-USB is a software-only implementation of a low-speed USB
3) see bold above, it tells you, it can not go lower the 10.
4) This is a Hex value! Values are whole numbers so the next step lower would be 0, which means no value, what did you expect it would use 0 ms?

Just because you can set it to a 1 does not mean its actually going that fast. Stop trying to argue with yourself, you WILL NOT be able to go any faster the 8ms on window using v-usb.

[nxtv2]

But it is going at 1ms

It reports in my python script at 8KB/s
which means it is going at 1ms.

If i set it to 8ms it reports 1KB/s as expected.

So i guess your the one arguing.

[ulao]

No the usb poll rate is not going at 1. Not only is that just embarrassing thing to say, it's technically impossible. You would need to prove this with a usb analyzer. A script is not suffice.

Again, this setting is for the enpoints 1 in this case. If you are talking about control transfers then sure it could be 1 as we already discussed. That is what the setting is for and yes you can get a 1ms control transfer speed. What I'm telling you is that the USB interrupt pol rate can not go lower then 8 ms without some serious hacking. V-usb has no seettings for that because its not changeable. The host picks the speed not the device. If you don't believe me then say that. Read back over the posts, all I'm doing is giving you info that is already known. I'm essentially digging it up for you to read for yourself but your not getting it. You are under the impression you can do some magic and cheat a well known limitation.

Condenser.

1, V-usb is a bit bang AVR chip that is only capable of the speed of your clock and the over head of the code. The only usb speed it can do is usb 1.1 low speed. That means 8 packets max over 8ms polls. To change this you need to fake something....
2, lots of people hack drives to get a faster pol rate. Why would they do that if it was as easy as a setting.
3, The OS driver determines the speed capabilities. Low speed usb 1.1 is 10 ms, the host must obey this. No device can over throw the host, and the host can not over throw the driver. There is a pecking order for a reason.
4, You really think your the first one to try this? A team of hackers had to Hack v-usb to get it to fake an xbox device in to think it a full speed device. You think they would go thru all of that trouble if they could change a number?
5, Your proof is a py script? It is more then likely just reading the descriptor. If you set the descriptor to a 1, what do you think it will say? Yeah... 1. Measure the speed and you will see its still 8ms.
6. Why would anyone take the time to write this is the wiki "The first widely used version of USB was 1.1, which was released in September 1998. The 12 Mbit/s data rate was intended for higher-speed devices such as disk drives, and the lower 1.5 Mbit/s rate for low data rate devices"
7. About going lower then 1ms.... The USB 1.1 Keep alive signal is 1 ms apart, so it's impossible to send data outside this. 1ms would be the smallness sample rate possible.


If your so convenience it's running at 1ms, then be happy. If you think you can make it .1 or 0 (even though that is absurd ) then do it. Stop asking for help because you got this..

[nxtv2]

Ok Maybe i am getting it wrong.

I meassure data rate.

With interrupt 1 , setting it to 1ms yeilds: 8KB/s.
That is measured and know to be correct.

So is that true 1ms or it is just the normal for 8ms?


I am not talking about control endpoints.
This is the endpoint 0x81

[nxtv2]

To further explain my point.

When i set

Code: Select all

USB_CFG_INTR_POLL_INTERVAL

to 1, i get 8 times faster transmission than settings it to 8.

[horo]

Hi,

Some time ago I did some "research" regarding the polling speed.
Also my recent measurements were quite similar.

Ciao, Martin

[ulao]

Again, one more time. That value does not make the OS go faster.

If the OS is 2ms, and you set 8ms, than yes it will slow down to 8ms. If you change it to 1ms, the OS will still be 2ms. So set it to 1, and tell yourself it can not go lower, and setting it higher will only slow it down. Best to leave it at 1.

Now, as Horo just proved and as I said many times , its up to the OS. Windows will always be 8, its just the way it is. Linux seems to go faster. Even though it's technically illegal, linux allows lower rates. But again, Windows is allowing 8ms, and the written law is 10ms for usb low speed devices.

linux:
bmAttributes=2 (bulk), bIntervall don't care -> 2ms poll, low cpu load
bmAttributes=3 (interrupt), bIntervall=1..3 -> 2ms poll, low cpu load
bmAttributes=3 (interrupt), bIntervall=4..7 -> 4ms poll, low cpu load
bmAttributes=3 (interrupt), bIntervall=8..15 -> 8ms poll, low cpu load
bmAttributes=3 (interrupt), bIntervall=16..31 -> 16ms poll, low cpu load
bmAttributes=3 (interrupt), bIntervall=0 or 32..63 -> 32ms poll, low cpu load
bmAttributes=3 (interrupt), bIntervall=64..127 -> 64ms poll, low cpu load
bmAttributes=3 (interrupt), bIntervall=128..255 -> 128ms poll, low cpu load

winxp:
bmAttributes=2 (bulk), bIntervall don't care -> permanent poll, high cpu load
bmAttributes=3 (interrupt), bIntervall don't care -> 8ms poll, low cpu load

I can not comment on that 10 version thing, or that 8 version of window (if that is even called windows anymore). I never owned it, I will never own it. So if you are on Win10 maybe things changed. Either way, the OS decides the speed and the poll rate option in V-usb will only slow it down if greater then the OS speed. Please understand that!

The reason it's left at 8, is to guarantee it is going to be 8 for any OS. Normally you don't want that changing from OS to OS. It is proly' ls safest to set to 10.

[nxtv2]

I am using ubuntu 16.04 LTS
And by all my measurments
it IS going at 1ms.

[nxtv2]

Horo,
Can you please post how did you measure the real pol in your post from 2009?

Thanks.

[horo]

Hi,

Please have a look at the MIDI thread, esp. viewtopic.php?f=8&t=1352&start=15#p9413

The code fragment mentioned is:

Code: Select all

for (;;) {
      PORTD ^= 0x80;
      wdt_reset();
      usbPoll();
      usbSetInterrupt(midiMsg, 8);
}

When you put a scope on line PD7 and the USB bus you can see the CPU activity (toggling PD7) and the USB activity (PD7 stays constant). This is also visible on the USB lines. My tests at debian linux on a ATmega16, 12 MHz gave:

I see activity on usb lines every 2 ms for about 120 µs (and the SOF "heartbeat" on D- every 1ms). So we have 6% usb load and more than 90% cpu time remaining for our application - that's ok.

ATtiny85, 16,5 MHz, same test program, but using PB1

EDIT 20170403:
I did some timing tests with an empty main loop, PB1 toggles every 3µs (idle) with a gap of 150µs (USB transfer) every 2ms.
So we still have >90% CPU time for our program available. This looks similar to my measurements from 2009.
Test system: Lenovo T400 with Linux 4.10.8-towo.1-siduction-amd64 #1 SMP PREEMPT siduction 4.10-14 (2017-03-31) x86_64 GNU/Linux.

HTH - Ciao, Martin