How to make USB HID Keyboard Keystrokes Faster using uTasker??

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How to make USB HID Keyboard Keystrokes Faster using uTasker??

Jump to solution
2,669 Views
alresarena
Contributor III

How to make USB HID Keyboard Keystrokes Faster using uTasker??

 

I tried tweaking uTasker's USB HID Keyboard for faster keystrokes and i achieve 6302 wpm keystrokes but when I combined it with other interfaces like Mass Storage Device (MSD) or uTasker USB To SDCard Device it Drops down to 1503 wpm keystrokes.

Please Help!!  :smileysad:

1 Solution
2,001 Views
mjbcswitzerland
Specialist V

Hi Alres

I don't understand the 6302 "wpm". If it is "words per minute" you also need to define the number of characters in a word so that the 'typing' speed can be known.
However, HID keyboard works based on an interrupt endpoint, which can have polling rates of 64, 32, 16, 8, 4, 2, 1ms and the rate is defined in the descriptor:

    {                // interrupt in endpoint descriptor for the interface
    DESCRIPTOR_TYPE_ENDPOINT_LENGTH,  // descriptor size in bytes (0x07)
    DESCRIPTOR_TYPE_ENDPOINT,         // endpoint descriptor (0x05)
    (IN_ENDPOINT | 0x01),             // direction and address of endpoint
    ENDPOINT_INTERRUPT,               // endpoint attributes
    {LITTLE_SHORT_WORD_BYTES(8)},     // endpoint FIFO size (little-endian - 8 bytes)
    10                                // polling interval in ms
    }

In the usb_keyboard_decsriptors.h you seem to have been able to increase the speed by modifying the 10ms (which is the reference) to 1, which would explain an increase in speed by up to a factor of 8 (10 will in fact cause 8 to be used).

Beware that when you configure a composite keyboard with MSD the descriptor file usb_msd_descriptors.h will be used instead (it contains MSD + Keyboard) and you will need to adjust it there instead, which may explain why you get a drop in speed when switching to this configuration.

The interrupt rate is a value that the USB host will "guarantee" and so the composite configuration shouldn't make any difference - the keyboard should always be polled by the host at the defined fixed rate.

At 1ms interrupt (polling) rate the host will be requesting the keyboard 1000x a second and if the device then returns a new key code each time it will result in 1000 key strokes a second, or 60'000 key strokes a minute - this will ultimately give your 'wpm'.
If however the same key is sent, rather than different keys, the speed can drop because it is necessary to insert a key release between two identical key strokes so that they are recognised as two. The uTasker keyboard driver handles this but the result is that if you were to try to do the test with the same key all the time the effective typing speed will be half the maximum. For general text it is probably around 95% the maximum value due to occasional double-keystroke (eg. "session" will need to be sent as"ses#sion", where the # shows the location of a key release being inserted).

If you don't achieve the maximum throughput it will probably mean that you don't keep the keyboard queue primed with new data. If there is no new key strokes waiting when the host polls there will be nothing sent and so the next chance to sent it will be 1 polling interval later.
I have seen that you are using the keyboard FIFO, which is the method to use for speed, but make sure that you set a decent FIFO depth, fill up the fifo so that the driver can really send key strokes at each poll, and make sure that you keep the fifo stocked up (supply it with more key strokes before it becomes empty) so that the maximum throughput is retained - like this the maximum will be achieved.

Beware that the USB speed efficiency is a cooperation between the application (supplying data) and the driver/endpoint bandwidth. I have heard of people complaining that when they switch to HS USB (480Mb/s) the speed doesn't improve. This is often logical since the speed can only be improved if the application can also supply the data adequately fast. If the application is not designed so that it can do it with FS USB (11Mb/s) it probably won't do any better by switching to HS USB....

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html

USB: http://www.utasker.com/docs/uTasker/USB_User_Guide.PDF
USB composites: http://www.utasker.com/kinetis/USB_Device.html
USB-CDC host<->device video: https://www.youtube.com/watch?v=XhISV1czIo4&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=16

Free Open Source solution: https://github.com/uTasker/uTasker-Kinetis
Working project in 15 minutes video: https://youtu.be/K8ScSgpgQ6M

Professional Kinetis support, one-on-one training and complete fast-track project solutions: http://www.utasker.com/support.html

View solution in original post

3 Replies
2,001 Views
alresarena
Contributor III

I tested your methods and it works perfectly. :smileyhappy:  I achieve constant 6302 words per minute with Mass Storage Device enabled :smileyhappy:... 

0 Kudos
2,001 Views
alresarena
Contributor III

Thank you for the advise Sir Mark :smileyhappy: I really appreciate your detailed response :smileyhappy: :smileyhappy: 

0 Kudos
2,002 Views
mjbcswitzerland
Specialist V

Hi Alres

I don't understand the 6302 "wpm". If it is "words per minute" you also need to define the number of characters in a word so that the 'typing' speed can be known.
However, HID keyboard works based on an interrupt endpoint, which can have polling rates of 64, 32, 16, 8, 4, 2, 1ms and the rate is defined in the descriptor:

    {                // interrupt in endpoint descriptor for the interface
    DESCRIPTOR_TYPE_ENDPOINT_LENGTH,  // descriptor size in bytes (0x07)
    DESCRIPTOR_TYPE_ENDPOINT,         // endpoint descriptor (0x05)
    (IN_ENDPOINT | 0x01),             // direction and address of endpoint
    ENDPOINT_INTERRUPT,               // endpoint attributes
    {LITTLE_SHORT_WORD_BYTES(8)},     // endpoint FIFO size (little-endian - 8 bytes)
    10                                // polling interval in ms
    }

In the usb_keyboard_decsriptors.h you seem to have been able to increase the speed by modifying the 10ms (which is the reference) to 1, which would explain an increase in speed by up to a factor of 8 (10 will in fact cause 8 to be used).

Beware that when you configure a composite keyboard with MSD the descriptor file usb_msd_descriptors.h will be used instead (it contains MSD + Keyboard) and you will need to adjust it there instead, which may explain why you get a drop in speed when switching to this configuration.

The interrupt rate is a value that the USB host will "guarantee" and so the composite configuration shouldn't make any difference - the keyboard should always be polled by the host at the defined fixed rate.

At 1ms interrupt (polling) rate the host will be requesting the keyboard 1000x a second and if the device then returns a new key code each time it will result in 1000 key strokes a second, or 60'000 key strokes a minute - this will ultimately give your 'wpm'.
If however the same key is sent, rather than different keys, the speed can drop because it is necessary to insert a key release between two identical key strokes so that they are recognised as two. The uTasker keyboard driver handles this but the result is that if you were to try to do the test with the same key all the time the effective typing speed will be half the maximum. For general text it is probably around 95% the maximum value due to occasional double-keystroke (eg. "session" will need to be sent as"ses#sion", where the # shows the location of a key release being inserted).

If you don't achieve the maximum throughput it will probably mean that you don't keep the keyboard queue primed with new data. If there is no new key strokes waiting when the host polls there will be nothing sent and so the next chance to sent it will be 1 polling interval later.
I have seen that you are using the keyboard FIFO, which is the method to use for speed, but make sure that you set a decent FIFO depth, fill up the fifo so that the driver can really send key strokes at each poll, and make sure that you keep the fifo stocked up (supply it with more key strokes before it becomes empty) so that the maximum throughput is retained - like this the maximum will be achieved.

Beware that the USB speed efficiency is a cooperation between the application (supplying data) and the driver/endpoint bandwidth. I have heard of people complaining that when they switch to HS USB (480Mb/s) the speed doesn't improve. This is often logical since the speed can only be improved if the application can also supply the data adequately fast. If the application is not designed so that it can do it with FS USB (11Mb/s) it probably won't do any better by switching to HS USB....

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html

USB: http://www.utasker.com/docs/uTasker/USB_User_Guide.PDF
USB composites: http://www.utasker.com/kinetis/USB_Device.html
USB-CDC host<->device video: https://www.youtube.com/watch?v=XhISV1czIo4&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=16

Free Open Source solution: https://github.com/uTasker/uTasker-Kinetis
Working project in 15 minutes video: https://youtu.be/K8ScSgpgQ6M

Professional Kinetis support, one-on-one training and complete fast-track project solutions: http://www.utasker.com/support.html