Jump to content
43oh

lawrence_jeff

Members
  • Content Count

    42
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by lawrence_jeff

  1. 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.
  2. 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)
  3. Also a UMR alum (ee 99) Hope you had some luck, I'm also in STL (in IT)
  4. 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.
  5. 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
  6. @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.
  7. 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.
  8. 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?
  9. 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
  10. Can you provide a snipet of the code sending the data that corresponds to that descriptor?
  11. 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
  12. @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...
  13. @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
  14. @@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
  15. 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 w
  16. This should be covered in the pdf included with my stuff you need the size to be the size of the largest report.
  17. 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.
  18. 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).
  19. Important to note the example above is fairly simple and not very efficient (in the fact that it sends 3 different reports, one for each device in the descriptor and waits for each reply before sending the next one) in reality once you understand what the code is doing you probably want to read all your buttons/joysticks then create one larger report that includes the identifier and info for each HID device and send that all at once in one USBDHIDCustomHidStateChange call.
  20. 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)
  21. One of the main reasons I created my framework was to support the lack of composite HID support in the framework, I'm guessing that is what USB_PID_COMP_HID_HID stands for. Just feel free to either use that value instead of USB_PID_CUSTOM or if you want just assign PID_CUSTOM to an unused value. Product IDs really don't matter they just need to be unique per device you create (and across any examples you install) since the OS caches it and can get confused if the same PID is used for multiple devices. Also I did manage to port my files over to Tivaware this weekend - I can try to post
  22. I would still recommend installing stellarisware and using the instructions to get familiar with the process of using CCS and compiling the library there are lots of little gotchas that can burn lots of time (it would also let you see how it behaves when it works as expected) stellarisware is just a directory tree so you can have it installed in parallel with Tivaware and just delete it when you get comfortable and are ready to tackle Tivaware (which is almost exactly the same except they changed all the variable types) Either way if you do port any of the stuff over please drop me a copy
  23. This descriptor put in the usbhidcustom.c file from my framework will make the Launchpad a dual gamepad + mouse device. (Each gamepad has 8 buttons + joystick) static const unsigned char g_pucCustomHidReportDescriptor[]= { UsagePage(USB_HID_GENERIC_DESKTOP), Usage(USB_HID_GAMEPAD), Collection(USB_HID_APPLICATION), Collection(USB_HID_PHYSICAL), ReportID(1), // // 8 - 1 bit values for the first set of buttons. // UsagePage(USB_HID_BUTTONS), UsageMinimum(1), UsageMaximum(8), LogicalMinimum(0), LogicalMaximum(1), ReportSize(1), ReportCount(8), Inpu
×
×
  • Create New...