ChibiOS Free Embedded RTOS

It should be an interrupt endpoint, I think it is part of the standard but it is not used in demos.

Giovanni

Giovanni wrote:It should be an interrupt endpoint, I think it is part of the standard but it is not used in demos.

Yep, but shouldn't I be able to write to it? It may mess up the host end, but I would expect it to transmit the bytes)?

The EP is available and you should be able to send data through it, I don't really know if hosts really listen to it.

It would be a good idea to find it in the relevant specification which is not exactly easy to browse.

Giovanni

Ok, I got back to this project again and tried a fresh tact.

I found an older demo code in the forum pointing to this repo

https://github.com/guiduc/usb-hid-chibios-example.git

Which was based upon 2.6.x Chibi release, but it worked as advertised and was simple enough to understand. I then modified it slightly, and added my descriptors, and it continued to work just fine. I then just worked the problem from both ends until I figured out what was wrong.

In the end, my project was working all along. However, on Linux (and others I'm sure), if no one on the host is currently reading from the USB HID device, it simply stops talking to it (it may also attempt to suspend it which I have to investigate and handle). That's why my usbTransmit() calls would stall, the host was simply not allocating a time slot for it. It's always difficult for me to remember that even with an "interrupt" endpoint, the host is _ALWAYS_ in control of the traffic.

Anyway, I figured once I whip this application into shape a bit more and make it handle the cases I spoke of above, that I could donate a simple example of a HID gamepad device that could ship with Chibi as a testhal/ or demo/. Many times this has come up in forums and might help people getting started. Giovanni, would this be acceptable? This application I'm writing is for a "blue pill" board, but I could port it to F4 or F3 discovery boards which I have access to and have USB ports. Which would get the wider audience in your opinion?

Dave

Discovery boards are quite common, probably a preferable option for a generic demo.

It is better if you try to keep it minimal so it can be reused easily.

Giovanni

Yep, simple is what I'm thinking.

I have found that modern desktop OS's usually have some UI support for reading and displaying the state of joystick/gamepad devices but the trick is in making a descriptor that it accepts as such. I've found that just having a HID with some buttons isn't enough, you usually have to define at a minimum some axes before it treats it as a joystick.

I'm thinking of boiling down my descriptors to the absolute minimum that a Windows/Linux desktop will see as a joystick so that it is easy to verify it was enumerated properly. After that I can hook up the single push-button on the F4 disco board to send reports and let people see it twiddle a single bit.

Sound reasonable?
Dave