STM32F4 Custom board HID device

[VCapu]

Hello. I am developing a custom board with STM32F405. I want it to work as custom HID device. The board must connect to the PC through an already existent driver software.

I tested he board with the Keyboard and Custom HID device examples in the package "STM32_USB_training_Content". I don't know what part of the code I must modify to send the correct data to the driver. My custom board must work as a keyboard, but it must be programmed as a Custom HID device because the conversion of the data in a printable character must be done by the driver.

[VCapu]

These are the data that I am sending:

buffer[0]=1; //reportID

buffer[1]=0; //modifier

buffer[2]=0; //OEM

buffer[3]=0x04; //keycode data - a

buffer[4]=0; //keycode data

buffer[5]=0; //keycode data

buffer[6]=0; //keycode data

buffer[7]=0; //keycode data

USBD_HID_SendReport(&hUsbDeviceFS,buffer,8);

The problem is that in both the Keyboard and Custom HID examples, the result is that the character is always printed. Instead I want that the character is printed only if the driver software is running on the PC. I don't know what I have to modify.

[GRama.4]

I'm a newbie myself, but maybe you can try something with AutoHotKey.

You can write a simple script that conditions the key press to a running software.

[VCapu]

Thank you. I managed with a buffer composed in this way:

 buffer[0]=1; // number of bytes

 buffer[1]=4; // keycode data

 buffer[2]=0; 

 buffer[3]=0; 

 buffer[4]=0; 

 buffer[5]=0; 

 buffer[6]=0; 

 buffer[7]=0;

[Pavel A.]

About "legacy"-type keyboard report (that have 6 places for scan codes) - see for example:

https://www.microchip.com/forums/m438695.aspx

https://gist.github.com/MightyPork/6da26e382a7ad91b5496ee55fdc73db2

Custom reports (not legacy compatible) can be different.

If the device describes itself as a keyboard, it does not need any driver on the host. The host OS will understand and convert scan codes to characters.

AFAIK the USB HID specification has no provision for direct input of 'cooked' Unicode characters.

It only defines that a keyboard can send scan codes, so the host OS driver must couple that with some language mapping table and "shift states" to produce characters. Please correct me if I'm wrong.

Therefore, if you want to send characters (not scan codes), a custom driver or app will be needed on host, and the device must not have keyboard subclass.

--pa