lawrence_jeff

Its been long enough that I would have to take a look to figure it out - can you post your code? Or email lawrence underscore jeff at hotmail.

Sometimes Windows does get confused. I thought I had some info in the document about that but don't have it in front of me. If you change the PID it should see it as a new device. (Shouldn't be necessary if you delete the device)

Also a UMR alum (ee 99) Hope you had some luck, I'm also in STL (in IT)

If you are using a stellaris launchpad that is your only option. My code example was for a tiva launchpad which has the pwm module.

Ok - I forked your code and made the changes required for my device (I have less buttons on mine). The trackball code worked fine except you need to put () before the multiply (I think without it is multiplying the -127 * 2.) Great work, it seems to do the job quite well - Keep us in the loop as you make other improvements!! I made some changes to your code in my revision though: Moved all the pin assignments to Mame_pins.c and h (I only have pad 1 defined in .c at this point) Moved the X and Y reads of the trackball to the StoreSwitches function so all the reads were together Simplif

Sounds awesome, I will test it out and get back to you!

@ryhs Check out http://www.ganssle.com/debouncing-pt2.HTML specifically the section Handling Multiple Inputs. It describes exactly what I was thinking. With so many buttons potentially being pressed at the same time I think you need to individually denounce vs the whole device.

So your debouncing requires that no buttons change for 5 cycles before they are reported? What about if button A is held down for say 100 but button B cycles state every 4 cycles? Would it ever send button A? I was thinking something like a circular buffer where you save the last 5 states of all buttons and then AND'ing the states of each bit across the last 5 and any that have stayed the same get reported (if its different than the last sent value). I think in the example above that would send button A after 5 cycles but not send button B until it had been stable for 5.

Awesome - I had meant to work on that but haven't had a chance, will try it out tonight! When you say the DPAD is pins 0-3 can you confirm the ordering, is 0 up and 1 right and so on clockwise or do you use a different approach?

Couple things I noticed, typo here QEIPositionSet(QEI0_BASE, 128); - One of these should be QEI1 Also the bigger issue with the trackball code is using 128 as the center of a report that maxes out at 256 doesn't work, mine which uses 256 and 512 works fine. I believe this is because the function uses signed char which has a maximum value of 127 per axis and this code is sending 128 at rest. I think the only reason my code works using 256 and 512 is coincidental because its rolling over and ending up within a valid range. So I think its back to taking the QEI value and shifting it so t

Can you provide a snipet of the code sending the data that corresponds to that descriptor?

I don't understand that descriptor, it indicates using a 2 bit report to send a value between -1 and 1, i don't see how you can do that since you need a signed value. You could do it in 2 8 bit reports since -1 is 11111111 and +1 is 00000001, but that really isn't that much simpler than -127 and 127. The V-USB mamepanel project uses a similar descriptor (-1 to 1) and somehow does each axis in 4 bits but I would have to dig through his code to understand how. A hat control which I have working can also do it in 4 bits since you send value 1-8 (1 represents straight up, 2 is up/right, 3 is

@Rhys Please share that descriptor if you get that working, I haven't seen that but it would seem to be ideal (make sure it supports the diagonals since those are valid in an 8 way joystick.). You will probably need to add those descriptor constants to the file which contains the Rz and Hat constants since TI didn't seem to include anything related to gamepads/joysticks in their HID files. On the jumpers, with those in place if they are both used for buttons pressing one should register the change on both pins, at least I hope that's the case since I spent the time to remove them...

@Rhys The bit shifting (multiplying the value by 2) is just to double the incremental value sent so that a smaller trackball movement has a larger impact to the onscreen mouse. This is something that probably needs to be tweaked per specific trackball but on mine (Happ) without this you have to roll it quite a bit to have significant movement of the mouse, it just way too fine a pitch, doubling the value makes it appear to be more responsive. On the QEI hitting zero or maxing out - I don't think you need to worry about this, the reporting (and subsequent reset of the QEI) should keep u

@@Rhys Looks really good - mostly worked out of the box but I did have to make some changes with the QEI code. For a mouse you need to report the incremental changes since the last report sent, your code reports the absolute QEI value of the encoder each time it hits the report. Here is how I modified it to get it working with my trackball: In the QEIConfigure I set the max value to 256 (This represents the max before the encoder rolls) In the default QEIPositionSet code I set it to 128 (This represents 0) In the handler I mapped these values to the range supported by a mouse (-127 to