Launchpad USB example and documentation additions/labs

[Rhys 0]

That would be great.  I've nearly got the library compiling correctly.  Fixed all the variable type errors, down to two warnings and two errors.  One error is with the USBHIDCompositeInit call, which now requires a third variable passed (tCompositeEntry *psCompEntry) which I'm not sure how to handle, and the line directly above it referring to PrivateHIDData I haven't been able to fix.  It looks like PrivateHIDData has been renamed to PrivateData, but when I do so in the code, I get an error #515 a value of type "tHIDInstance *" cannot be assigned to an entity of type "tHIDInstance".

 

The two warnings I'm getting are

#515-D a value of type "unsigned long (*)(void *, unsigned long, unsigned long, void *)" cannot be assigned to an entity of type "tUSBCallback" on the pfnRxCallback and pfnTxCallback lines.

[Rhys 0]

Ok, reading through the migration document, looks like the PrivateData call isn't needed anymore, so I commented it out.  I just put in a 0 for CompEntry for the moment, and the library compiled with just the warnings about tUSBCallback.  I was able to get the usb_dev_volume example to compile as well with the same warning.  I'd load it to my board and see if it works, but I don't have it with me....  I look forward to your updated package as well, I'm guessing it fixes the issues better than mine does

[lawrence_jeff 3]

Here you go-  https://github.com/lawrence-jeff/TivaLaunchpad

 

For now I only have the volume example included but I will add additional examples as I get time (and update the documentation)

[Rhys 0]

Thank you!  Took a small amount of tweaking, but I was able to get everything compiled and working.  You had the includes for the Volume example pointed to ek-lm4f232 rather than the ek-tm4c123gxl and Tivaware 1.0 rather than 1.1, but that was easily corrected.

[Rhys 0]

Never mind, I just realized that for this to work the way I want it too, I'm going to have to significantly restructure my code.  Your Volume example won't keep up with the 125Hz polling rate for USB HID devices, and I need to hit that for the smooth mouse/trackball input.  Hmmmm, more research.  I think I'll have to look into to how to set it up to send a single report for the entire composite HID device like you suggested. The rest of the code is coming along nicely though

[Rhys 0]

@@lawrence_jeff - Well, I have had some limited success now!  I have the Launchpad showing up as a dual gamepad and mouse, my code to scan the GPIO pins works the way I want it to, down to one last problem.  It may show up, and is reading input, but the input isn't making it to the computer??  If I pull a pin to ground that corresponds to a button press on one of the gamepads, I can see in the debugger that the correct value is in the report array, but when I look at the gamepad control panel, the corresponding button does not show up as being pressed.  Not sure what isn't working and not sure where to look to find it.  My code seems to be functioning as intended, so I'm guessing something in the USB stack isn't working correctly.  If you would be willing to take a look at my custom HID code and see if maybe I missed something, it would be greatly appreciated.

usbdhidmame.zip

[lawrence_jeff 3]

At a glance I don't follow the first report - the comments say 12 bits of buttons followed by 4 bits of padding (to end up an even 2 bytes). However you declare 8 buttons/bits not 12 

 

ReportSize(1),

ReportCount(8),

 

and then pad that with 4 bits for a total of 12 bits (not at an even byte boundary).

[Rhys 0]

@@lawrence_jeff - I didn't update the comments, I reduced the button count to 8, as I am going to use the JTAG pins for the other four and was attempting to reduce complexity for debugging.  The 4bit padding is temporarily commented out and I reduced the report count to 8.

[lawrence_jeff 3]

@@lawrence_jeff - I didn't update the comments, I reduced the button count to 8, as I am going to use the JTAG pins for the other four and was attempting to reduce complexity for debugging.  The 4bit padding is temporarily commented out and I reduced the report count to 8.

 

Sorry I should have looked more closely - so if you do this as individual reports they are all 4 bytes (for example the gamepad is 1 byte reportID, 1 byte of buttons and 2 bytes of axes so 4 bytes total

 

But in your header file you declare the size to be 1 byte

 

#define CUSTOMHID_REPORT_SIZE       1

 

You need this to be 4.

[Rhys 0]

@@lawrence_jeff - knew I had to be missing something stupid....  Now the question is, what do I do when the reports for the various devices are of different lengths?

[Rhys 0]

Well, that worked, partially....  Gamepad 2 and the mouse now report, but I'm not getting any response on gamepad 1.  USBlyzer is not showing reports coming in from ID1 either....  Hmmm, more debugging....

[lawrence_jeff 3]

@@lawrence_jeff - knew I had to be missing something stupid....  Now the question is, what do I do when the reports for the various devices are of different lengths?

 

This should be covered in the pdf included with my stuff you need the size to be the size of the largest report.

[Rhys 0]

@@lawrence_jeff - Thank you so much for all of your (very patient!) assistance!!!  I have the whole thing up and working, at least as a proof of concept.  Input seems a bit laggy, USBlyzer Is putting the turnaround time for each report at about 32ms +/- .1ms.  Should be fine for the gamepad devices, that's about once per frame, but it mouse input is likely to be fairly jumpy.  I don't have any quadrature devices at the moment to test that with, arcade trackballs are almost $100, which I don't have lying around at the moment.

 

I've been digging around, but so far I haven't seen a better way to go about the HID report.  I am guessing it would be faster to send the entire report for all three devices in one shot, but I have not found any information on how to do that.  I'll keep looking

 

In the mean time, I'll post the code to my Github when I get a chance.

 

Thank you again!

[lawrence_jeff 3]

@@lawrence_jeff - Thank you so much for all of your (very patient!) assistance!!!  I have the whole thing up and working, at least as a proof of concept.  Input seems a bit laggy, USBlyzer Is putting the turnaround time for each report at about 32ms +/- .1ms.  Should be fine for the gamepad devices, that's about once per frame, but it mouse input is likely to be fairly jumpy.  I don't have any quadrature devices at the moment to test that with, arcade trackballs are almost $100, which I don't have lying around at the moment.

 

I've been digging around, but so far I haven't seen a better way to go about the HID report.  I am guessing it would be faster to send the entire report for all three devices in one shot, but I have not found any information on how to do that.  I'll keep looking

 

In the mean time, I'll post the code to my Github when I get a chance.

 

Thank you again!

 

 

 

 

No problem. I took a look at this and I gave you bad info, it seems you have to send individual reports you can't send it as one report with the report ID embedded, but even with minor changes it should work fine - I have a non Tiva stellaris using interrupt code and reading a QEI Golden Tee trackball and its smooth as silk in Windows with no real optimization - keep in mind mouse movement is incremental so all I do is start at 0 for an axis and then either add or remove 1 for each encoder detection and then when I call the HID function report the delta since the last successful report. This way even if your mouse moves from X value 25 to X value 30 before you send the report, once you report the X value of +5 it syncs things up in Windows (you can't see any choppiness)

 

However if you do want to speed up your code - first in your usbhidmame reduce the endpoint polling interval to a value lower than 16 (last value in uint8_t g_pui8HIDInEndpoint)

 

Then if your main code follows the TI examples and only sends a single report per systick - make sure you have SYSTICKS_PER_SECOND fairly high (the example of 100 means a mandatory delay of 10ms between reports). I changed both these values and if I'm reading that USB analyze tool correctly it looks like it is taking <10 ms to send all 3 reports.

 

I would be interested in your code for reading the buttons - are you reading 8 at a time and reporting it as a byte of gamepad buttons or are you doing some sort of looping?

 

[Rhys 0]

@@lawrence_jeff - I'll have to check out the polling rate.  I have SysTick set at 1000 with the USB handler set to run >=8.  I should probably reduce that a little....

 

I setup the QEI ports with a max value of 255 and a start value of 128.  When I read the position, I subtract 128 from the value read, giving a -128 to 127 range, then reset the position to 128 for the next interval.  I have Gamepad1's first 8 buttons mapped to PortA, the last 4 buttons mapped to the first half of PortC, Gamepad2's 8 buttons are mapped to PortB, and the Mouse buttons are mapped to PortE Pins 1 and 2.  I set the initial value in the array to 0xFF,  then when I read the port, I use an XOR Equals to bit flip the port values.  I have XY on the gamepads mapped to four pin blocks on two ports, and use an IF / ELSE IF for X and Y to check the pin states and report an appropriate -127 or 127 value for each axis.  I would set up XY as digital axis with a min/max of 0/1 and use the same XOR method I use for the buttons, but I'm not sure how.  Is it possible to just set the min/max to 0/1 for the axis in the HID descriptor instead of -127/127?  That would turn four IF/ ELSE IF statements into two XOR Equals bit flips and probably speed things along a little.

 

 

Much better!!!  Changed the polling interval to 1 and now I'm showing about 7ms for each gamepad and 2ms for the mouse

 

I've attached my code for you to peruse at your leisure. Not particularly pretty, but it does what I want it to!

USB Hid Mame.zip