You need to change few others things to make it work as a gamepad. In usbd_hid_core.c you need to change :
0x02, //nInterfaceProtocol : 0=none, 1=keyboard, 2=mouse
to the 0x00 value.
Other thing, the report descriptor has to be changed, this is mine for a 3-buttons 2-axis gamepad, (you can change it to add button or anything else with the HIDtool) :
__ALIGN_BEGIN static uint8_t HID_MOUSE_ReportDesc[HID_MOUSE_REPORT_DESC_SIZE] __ALIGN_END =
{
0x05, 0x01, // USAGE_PAGE (Generic Desktop)
0x09, 0x05, // USAGE (Game Pad)
0xA1, 0x01, // COLLECTION (Application)
0xA1, 0x00, // COLLECTION (Physical)
0x05, 0x09, // USAGE_PAGE (Button)
0x19, 0x01, // USAGE_MINIMUM (Button 1)
0x29, 0x03, // USAGE_MAXIMUM (Button 3)
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x25, 0x01, // LOGICAL_MAXIMUM (1)
0x95, 0x03, // REPORT_COUNT (3)
0x75, 0x01, // REPORT_SIZE (1)
0x81, 0x02, // INPUT (Data,Var,Abs)
0x95, 0x01, // REPORT_COUNT (1)
0x75, 0x05, // REPORT_SIZE (5)
0x81, 0x07, // INPUT (Cnst,Var,Rel)
0x05, 0x01, // USAGE_PAGE (Generic Desktop)
0x09, 0x30, // USAGE (X)
0x09, 0x31, // USAGE (Y)
0x15, 0x81, // LOGICAL_MINIMUM (-127)
0x25, 0x7F, // LOGICAL_MAXIMUM (127)
0x75, 0x08, // REPORT_SIZE (8)
0x95, 0x02, // REPORT_COUNT (2)
0x81, 0x02, // INPUT (Data,Var,Abs)
0xC0, 0xC0 // END_COLLECTION x2
};
The size of the report descriptor has changed so modify it in usbd_hid_core.c :
#define HID_MOUSE_REPORT_DESC_SIZE 48
Now the gamepad would be recognized. You only need to send a 3 bytes report (the first for the button, et the two others for the axis).
For a test you could do it by using this code in stm32xx_it.c :
static uint8_t *USBD_HID_GetPos (void)
{
static uint8_t HID_Buffer[3] = {0};
static int8_t val_abs_x=0;
static uint8_t sens_x=0;
HID_Buffer[1] = 0;
HID_Buffer[2] = 0;
// X move
if (val_abs_x > 120)
{
sens_x = 0; // --
HID_Buffer[0]=0;
}
else if (val_abs_x < -120)
{
sens_x = 1; // ++
HID_Buffer[0]=1;
}
if (sens_x == 1)
val_abs_x = val_abs_x + 3;
else
val_abs_x = val_abs_x - 3;
HID_Buffer[1] = val_abs_x;
HID_Buffer[2] = 0;
return HID_Buffer;
}
Anf finally change the line (in the same file) :
USBD_HID_SendReport (&USB_OTG_dev, buf, 4);
to :
USBD_HID_SendReport (&USB_OTG_dev, buf, 3);
This should work well on the STM32f4 discovery board. If not try change the PID by adding 1 (like 0x5711) in usbd_desc.c).
Ok, so you need a device with at least 2 USB ports. One of these must be a slave port which you will connect to a host PC and the other port must be a host which you will connect a keyboard/mouse/whatever.
Your device will then enumerate and handle the slave device(s) on its host port, process any information and/or events from these devices, and then forward this data out of its slave port up to the host PC.
So to answer your question simply: yes this is possible.
But, I don't think its going to be possible with either of the boards you're looking at.
The one half would be fairly straightforward. These boards would be quite happy using one of their USB ports to talk to your keyboard/mouse device(s).
The problem comes about when you want to use them to emulate a particular type of slave device to your host PC.
These kind of boards are typically configured to provide a very limited selection of USB profiles to choose from when connecting them to a PC (such as a mass-storage device, serial port emulation, camera or possibly some kind of debugging interface) and you'd find it quite difficult to change this to look like something else - in your case a HID device like a keyboard and/or mouse.
I'm not saying its impossible, but I don't know enough about these boards and its not obvious from their simple overviews that they support this.
This is the kind of application where you will probably need to work at a lower level - more directly with the firmware on a suitable microcontroller or microprocessor.
If I were to try to pull something like this off, I'd be inclined to set up a pair of microcontrollers back-to-back. One of them is the USB OTG host to your keyboard/mouse, the other one acts as a keyboard/mouse compound device to your host PC, and they're connected to each other using SPI.
Best Answer
You will need to use a device that has USB controller capability, or you can use an external chip. The actual device I would recommend depends on what kind of output the sensor has. Is this output On or off? If it's something so simple, I highly recommend using an ATTINY device like this. ATTiny simulates USB and works nicely without too much complexity.
However, if your IR sensor needs an ADC and some processing, you can use an MSP430, PIC, Cortex M3/M4 and many others depending on whether you need some processing of that signal.
Lets assume that you have the USB connectivity. In reality you need to choose a class for your USB device and for this I recommend CDC since it basically opens a COM port on the computer and you can send data as it arrives, then process it with any kind of program you like.