Is that possible to control the polling rate of a mouse in USB host mode?

[ZIgon.1]

HI,

I'm using an STM32F4 device and CubeIDE SW to interface with a mouse as a host with an HID. I use the USBH_HID_EventCallback function to trigger mouse readings.

Can I change the mouse's polling rate so that it will be triggering faster?

The current polling rate (per USBH_HID_GetPollInterval function) is 10ms. In the mouse's data sheet, it states it can reach 1kHz polling rate.

Thanks

[waclawek.jan]

The deal is, that Device (here mouse) tells to Host, how often shall Host poll Device's endpoint, within the Configuration Descriptor, in each Endpoint Descriptor. Dissect the mouse's Configuration descriptor to see that value - is it 10?

However, Host is your program and nothing can prevent you to ignore that value and poll as fast as you wish. If you do so, you are operating outside specification and then it's upon the mouse whether it will honor the polls or not, and whether such polling has any side effects or not.

Most probably it will be working just fine, but don't be surprised, if not.

JW

[ZIgon.1]

Thanks JW,

From my understanding, if I use the event callback function, it is the mouse that controls the data rate.

I don't mind to request the data in the main program but once I do that (using the Mouse_Info = USBH_HID_GetMouseInfo(phost) function), starting from the second reading I'm getting thrown to the hardfault_handler. I believe there is some procedure I don't do after reading the mouse to set the host back to reading state.

Is there any source I can read how to do the readings manually (without event callback)?

Thanks for your answer.

[Pavel A.]

USBH_HID_GetMouseInfo tries to pull the available data from the (software) FIFO buffer. It cannot get more reports than stored in the FIFO.

Do you check the return value of USBH_HID_GetMouseInfo? It can return NULL.

It looks like the ST library ignores the poll interval value in the descriptor and just polls as fast as it goes. 

[ZIgon.1]

Thanks Pavel,

I think you are correct.

But per your assumption, the rate with which the FIFO is getting data, is controlled by the mouse, eventually.

I will try to implement the manual reading and update the thread.

Thanks

[waclawek.jan]

I don't use Cube/CubeMX.

Cube is open source, so you can check yourself. I'm looking at the HID example in some older versino of Cube, maybe your's the same, maybe different.

The received Configuration Descriptor is dissected in [CubeF4]\Middlewares\ST\STM32_USB_Host_Library\Class\HID\Src\usbh_hid.c, and the respective endpoint's bInterval field is extracted in this way:

    HID_Handle->poll      = phost->device.CfgDesc.Itf_Desc[phost->device.current_interface].Ep_Desc[0].bInterval ;
    
    if (HID_Handle->poll  < HID_MIN_POLL) 
    {
      HID_Handle->poll = HID_MIN_POLL;
    }

where HID_MIN_POLL is defined in ../Inc/usbh_hid.h as

#define HID_MIN_POLL                               10

so even if the mouse requests faster polling, the library falls back to 10ms. You can override this by overwriting HID_Handle->poll after the enumeration, as it's then used for timing of the scheduler through USBH_HID_SOFProcess().

JW

[ZIgon.1]

Thanks Jan for the detailed response.

So if understand correctly, reducing the HID_Handle->poll value to minimum shall move the HID_Handle->state to HID_GET_DATA earlier.

In that case I can modify the HID_MIN_POLL value and keep using the event callback.

Am I correct?

Thanks                

[waclawek.jan]

Probably yes.. As I've said I don't use CubeMX.

JW

[Pavel A.]

Ah, this is in SOFProcess. Then I stand corrected, thanks.

[ZIgon.1]

Thank you guys, for your time and efforts!

I will give it a try and update the thread, in case someone else will have the same issue.

Thanks