Go Down

Topic: USB Game Controller Firmware, being able to receive data (Read 2029 times) previous topic - next topic

skombijohn

Hi,

I basically want to build a USB HID "joystick" thing, with buttons, that acts as a standard game controller in windows. I dont have any analogue axes, just buttons.
I guess this is not a big problem, as I read about USB HID firmwares more or less ready to go.
Anyway, the HID abilities are just one half of what I have in my head.
The second part of the device would consist of several displays on the device like LEDs and 7segment displays.
The arduino implementing this device must receive data from the windows PC to enable/disable the LED's according to the data content.

The thing is, I already have the second part completely up and running. I designed and built the circuit for driving all the LEDs / 7 segments and so on, which is connected to an arduino Nano. I have written a firmware, that parses a bytestream received from the PC. The PC currently sees the device as the arduino-standard-COM port, so the programming on the PC is pretty straight forward and nothing special.
Actually that works pretty well. Very nice.

The challenge now is, that I now wanna have that as a HID device being a gamecontroller.

So the questions I have are:
- Is it generally possible to have a HID device send "button events" and also receive "data events" at the same time ?
- How can I write the PC utility/driver/software/whatever that has to provide the "data events" ? What is the communication protocol/frame?
- How do I implement the firmware to send AND receive the events on the arduino?

It's not that I am too lazy to read about how to write HID firmware for the arduino, I am just not sure, IF the concept is realizable without major hurdles like driver signing and so on.
Plus, I am not really sure, what I am exactly looking for solutionwise.

I really appreciate any help, as I am kinda stuck there.

Thank you very much :)

Cheers,

Chris

Mike T


- Is it generally possible to have a HID device send "button events" and also receive "data events" at the same time ?


Sure, each HID device can have IN and OUT sections. Even a normal keyboard has the LEDs as OUT reports. You have to define the reports (telegrams) and how each bit is handled.

You should read the following documents from http://www.usb.org:


"USB in a Nutshell" is also a good starting point to understand USB.

Quote
- How can I write the PC utility/driver/software/whatever that has to provide the "data events" ? What is the communication protocol/frame?


Normally you use a standard driver and only write the application part.

For MS Windows you can use a user level dll and don't need to write a kernel mode driver:
http://msdn.microsoft.com/en-us/library/windows/hardware/jj126193%28v=vs.85%29.aspx


Quote
- How do I implement the firmware to send AND receive the events on the arduino?


The question is if it will be easier to do it with LUFA or Arduino. Arduino provides some support for standard USB devices, but it is not easy to extend this features. LUFA only provides an open framework to make your own USB devices (see the examples). Both require a lot of learning to make your own USB device with custom USB reports.

Quote
It's not that I am too lazy to read about how to write HID firmware for the arduino, I am just not sure, IF the concept is realizable without major hurdles like driver signing and so on.


For joysticks, you don't need an own driver for HID devices because the operating system already provides one. HID devices describe their features themselve.

   Michael




skombijohn

Thank u very much Michael :)

Yes, basically that is what I expected...a lot of reading and learning, which is always difficult for part time hobby projects.

One other question comes up now, it's already a little beyond the scope of this forum I guess, but still inside the topic:

The original PC software is a simple executable that fetches the data for sending to the ┬ÁC from different games. Each game has a pretty proprietary way to provide the data, examples are shared memory, others by a own API and so on. It was quite obvious to handle that in an executable in different timer based threads and so on.
But how can I implement that in a dll?
I'll have to provide an interface to the user (that's me) to select the current active game for example.
Should I still have that executable that does its own collecting and provide the collected data to send to the dll somehow?
Anyway, then the dll would still need some sort of periodic collecting/sending thread....hmmmmm

This ocean is quite big to swim through :)

Mike T


The original PC software


Did you write this software? Do you want to replace the original software? I don't understand what you want to do...

Quote from: skombijohn
It was quite obvious to handle that in an executable in different timer based threads and so on.
But how can I implement that in a dll?


It doesn't depend if the code is written as a DLL or directly in the EXE. The question is who is loading the DLL and calling its functions.

Quote from: skombijohn
Should I still have that executable that does its own collecting and provide the collected data to send to the dll somehow? Anyway, then the dll would still need some sort of periodic collecting/sending thread....hmmmmm


It might make sense to have one DLL which does the communication to the microcontroller and one for each game which provides data. The application could then select which of the game DLLs to load and activate at a time and also create a thread which polls the DLLs for new data from the games.

   Michael

Go Up