Is there an example USB HID host that supports both a mouse and a keyboard at the same time?

[Pavel A.]

Are your mouse and keyboard separate devices connected to two USBH controllers, or one multifunction (composite) device, or you want to use one USBH controller with a hub?

In the former case you can combine the keyboard and mouse examples, on two USB controllers.

ST has long ago promised hub support, but AFAIK still not there. Look at github, especially https://github.com/hathach/tinyusb.

For composite device examples, look on github.

Note that many mice found in the wild are multifunction, with several vendor specific functions of unknown purpose. Many have complicated report format (more than 8 bits of X/Y/scroll, extra buttons...). Examples usually support only simple fixed report format rather than do full parsing of report descriptor.

[BBert]

It is the second (one multifunction composite device). In fact, it is a wireless Ritek Rii model i4 device with a USB dongle that connects to the HID host. I will check the tiny-USB site but the last time I looked they didn't support the HID host.

[Pavel A.]

Then you need to parse the descriptors and find the endpoint numbers for kbd and mouse, and the report format. Keyboards tend to be more standard, mice can surprise.

If you want to work with only this device, you can capture the descriptors and parse offline.

Then use the endpoint numbers to read the reports, as in the examples. Keyboard, then mouse.

[BBert]

Thanks for the response. The problem I have is I don't understand how to get the example code to talk to both the devices at the same time. The example code will talk to either the mouse or the keyboard but not both. I am already parsing the descriptors and finding the endpoints. I have implemented an alternative approach using a MAX3421e based board, However, I would rather use the sth32H743 USB port to access the device.

[Pavel A.]

You cannot talk to both the devices at the same time - exactly because there's only one USBH controller and one physical link. You send IN request to one device's endpoint, get NAK or data reply. Then send IN request to another device's endpoint, and so on in turns.

If both functions use only the control endpont (0) - I don't recall the details - the control request must contain the index of the addressed function. This is how the device knows to which function the request is sent.

[BBert]

I disagree with you somewhat on this. It seems to me that as long as you use different endpoints you can send a message (packet) to the endpoint without receiving a reply. The reply may come after packets are sent. I think the key to handling composite devices is being able to send packets to the devices asynchronously. Of course, you are right in stating that only one packet can be transmitted physically over the serial connection.