Okay, a futher issue in my legion of apparent curses:
The UPCB works for the most part in Vista now. However, when I hold down Start+Select to enter “bootloader” mode (is that what you call it?). Vista freaks out and tells me it can’t find a driver for the device, even if I try to force it to use the driver included in your firmware file. It also exhibits the same behavior when I short the “PROG” pins on the motherboard - except in that case I don’t need to hold anything down, it just barfs up the “USB error” message.
So, thinking Vista is probably the culprit, I got ahold of a laptop with XP installed on it. Surprisingly, it gave me the exact same behavior. ST+SEL held down on plugin (or PROG pins shorted) spits out a USB device error, it refuses to install your provided driver.
straaange stuff, the logitech coreless precision for ps3 has the EXACT same hid descriptor as the vshg, with errors and all - at least that’s what sniffusb says.
Device monitoring studio comes up with a bunch of “unknown” for the last part, but it turns out it is pressure sensitivity data for all the buttons, including the d-pad. The PS button however is not pressure sensitive…
Screenshots would be helpful. Take a peek at the Instructable for updating the firmware, list what steps were taken and where it goes awry. Does the device show up in device manager? Can you use the Update Driver or Install driver option from the device in Device Manager? What happens when you remove the device from device manager and then replug it?
It doesn’t matter if you hold down Start + Select, or hold the Program button; either one is as good as the other.
The string descriptions should be different; the VSHG I had specifically said VIRTUA STICK HIGH GRADE in the string. I’d also expect the ProductID, ManufacturerID, etc. to be different. If the product ID and Manufacturer ID’s are different, but the configuration descriptor, interface descriptor, HID descriptor and endpoint descriptors are the same, then you’ll know for sure. Post up a log if you would. You may also want to try Snoopy ( http://sourceforge.net/projects/usbsnoop/ ); the other sniffer seems to refresh the list of devices every half second, giving me an instant headache. As for the pressure sensitive buttons, that’s correct, especially if they are going off of the SIXAXIS descriptor. http://ps3.jim.sh/sixaxis/usb/
I updates the USB code as best I could to match the information from the SIXAXIS and Pelican, but the PC doesn’t care for it and lists it and an unknown USB device without drivers. What sucks is that it doesn’t get far enough in the process for it to register as a snoopable device in either sniffer program, so I can’t see or record what happens when it gets plugged in. Everything seems in order, but USB is some complicated stuff sometimes.
I’m going to have to take some time studying USB itself, and trying to make heads or tails of the damn Microchip USB code. I’m seriously thinking that I need to switch over to Brad Minch’s USB code; its much smaller (750 lines versus, what, 2500 lines) and easier to understand. I know some changes are definitely going to have to be made to the rest of the USB code to support the additional endpoint the SIXAXIS describes, but finding where and what will be a lot easier with Brad Minch’s code.
At any rate, here’s the USB c and h files updated as best I could with the SIXAXIS information. If anyone can find errors, I’d love to hear about it. usbtemplate.c: usbtemplate.h:
You might want to comment out the FrameUpdate() function. That’s a surprise for the next revision.
The HID descriptor is what is identical, which is what logically should be the issue PS button. Started to look for other things, which didn’t pan out. Changed the max packet size to 64 instead of 8 bytes (EP0_BUFF_SIZE) to be identical to the logitech, set protocol type to zero, class type to 3, and put “PS/3” in the string which also did nothing. There must be *something *that makes the PS/3 think aha, a PS3 controller, the PS button must be X…
I don’t think it’s the framework itself, as basic USB communications is working fine…
I agree the USB communication for some things, like the simple HID stuff, is working fine. But I don’t think the framework supports the additional endpoints; the basic HID stuff only has endpoint 0 for control stuff, and EP1In to ship all of the button data to the host. I have no idea how it will or would react to any information on the EP2Out line; In fact, I can’t see anything that would actually enable it through the UEP2 register in the Microchip code. It wouldn’t surprise me that the host would send a GET_STATUS packet to endpoint 2, and then freak when the endpoint is shown as still halted or otherwise unavailable.
I’m going through the Brad Minch USB firmware, hand in hand with the USB made simple site, and the 4550 datasheet. The firmware will probably be twice as long with my comments added in, but it’ll be worth it. So damn much easier to follow than Microchip’s code.
Yeah… I always wondered why the HFS3 was just always on when I started a PS2 game and I didn’t have to press the PS button to put it on like the sixaxis and DS3.
Appreciated Canto. Zim, Im guessing that’s the same report descriptor you get on the VSHG.
I’ve gone through the Brad Minch USB code, and everything’s making a lot more sense now. I’ve got a busy weekend, but I’ll be trying to implement the SIXAXIS with the Minch code as soon as I can.
This pretty much proves it. With all the liberties you can take with a HID descriptor, there is NO way that the VSHG, Logitech and the HRAP has the exact same HID descriptor by chance. It can ONLY be the result of a specification/recommendation by Sony, which also includes the procedure for the PS button.
I just doublechecked the VSHG descriptor I had and it has those same funky declarations you got. http://topic.csdn.net/t/20040623/17/3116919.html
From what Im seeing, I’m guessing the 0x0A is part of USAGE. I can get USAGE declarations that start with 0x09 and 0x0B from the descriptor tool, but Im guessing I just havent found the extended page that starts with 0x0A yet.
I did have the VSHG descriptor up and going, and it worked great on the PC, but I got no reaction from the PS3, not even normal stick behavior. Take a peek if you like. ps3usb.c usbps3.h
I need to setup a way for the UPCB to record oddball requests like vendor requests…
It’s step 2 in the instructable. When plugging in the UPCB with Sta+Sel held down (ie bootloader mode), windows immediately comes up with an error message (see screenshot 1).
Clicking on the error message brings up screenshot 2.
When I attempt to install the MCHPUSB driver, I tell it I want to select a location, and then point it to the directory where the MCHPUSB/release driver is located.
Windows doesn’t even attempt to install it. It gives me the “better driver is installed” message in screenshot 4, even though it shows no driver installed (screenshot 3)!
Note it does this exact same routine on a Windows XP laptop I tried it on.
Got something for you to try.
Download this: http://ww1.microchip.com/downloads/en/DeviceDoc/MCHPFSUSB_Setup_v1.3.exe
Run it, it will extract a bunch of stuff to C:\MCHPFSUSB\ directory.
Go back to device manager, and either remove the existing device and refresh, or just update the driver. When it asks, point it to the C:\MCHPFSUSB\Pc\MCHPUSB Driver\Release\ directory, and see if it will take the INF in there. Let me know if it takes. If it does take, try to go through the updating steps using the pdfsusb.exe in the C:\MCHPFSUSB\Pc\pdfsusb\ directory. You may have to set the pdfsusb.exe to run under XP or 2k compatability mode; Im not sure if the 1.3 version in that download package require it.
Exact same result with the new drivers, at least in Vista. Can’t remove the old drivers because it shows no driver installed, yet it claims a better one is installed when I try to update it. I’ll update the post when I get to try XP again.
Keep in mind, I’m pretty ignorant about Vista, but you should be able to remove the device from device manager, even if there is no driver installed for it. Just right click->uninstall. Then either replugging it, or Action ->Scan for hardware changes should force a new ‘New Hardware Detected’ window to come up.
btw based on the schematics from the PIC should right, left, up, down, and all the buttons have a line to vcc after the resistor. or do they each connect to some sort of connector that goes to each button and direction.
in other words should pin 19(RD0/SPP0) on the PIC(accordin to your schematics its JAB) have a line going to a jab push button right after the resistor, or should it have a line going to VCC right after the resistor
oh and 2 more questions but how did you make the output to db15 connector with the multicolored cable(digikey part MC16M-5-ND)
and whats vcc, it looks like ground
edit: lol i keep finding more questions, in the optional buttons of the schematics do i add a trace from RA1 and RA0 to ground. oh and i assume that nothing should be done to RB5, its already done
oh and whats the OPT_DC_CONN for, can i ignore it?
The label for Jab is reffered to as a net. Everything with that labelled is connected together. So, the PIC pin RD0, one of the pushbutton microswitch pins, and one leg of a resistor are all connected together. The other pin of the pushbutton microswitch goes to ground, and the other leg of the resistor goes to VCC.
Take your ribbon cable, squish a 16 pin IDC connector onto one end. Determine which wire is pin 1 (GND) by how and where it plugs in. On the other end of the cable, slightly separate pin 1 from the rest of the ribbon, and solder to pin 1 of the Dsub cable. The next wire in the cable goes below pin 1 to pin 9; solder it. Next wire is pin 2, then pin 10, then pin 3, etc. The very last, sixteenth, wire isn’t needed; either get rid of it, or connect it to the Dsub shell if its connected to ground on the board.
Quite the opposite, its the power line (positive voltage), which always comes from the Dsub as pin 8.
For the optional extra buttons (RA0, RA1) and the program button (RB5), you do want to tie them high with a pull up resistor, whether you plan on connecting them to pushbuttons or not.
OPT_DC_CONN is me trying to properly handle future Dreamcast support. You can safely ignore it.
