@Wuerfel_21 said:
Ah, I see, that's what's going on with the USB connector. They designed it to plug into the Pi Zero. Yeah that's just doing OTG, which should work passively if you're just trying to be a host. I think an actual OTG device needs that extra 5th pin to do something to switch into host mode, but we just assume we're a host (and I think the Pi Zero does, too? I don't think it can do device mode?) So trying it with the Serial Device accessory is fine if you can manage that.
You're saying this USB connector doesn't have GND and VBUS connected to anything? That'd be odd.
Yeah they both float, only D-/D+ pass through the flex cable to the card edge fingers. I guess the controller doesn't really need ground and VBUS because it's supplied internally and grounded separately. 5V already directly powers the Pi from the Case 2W Lipo boost converter, so there's really no need to feed 5V back via VBUS into the controller with the Pi acting as a host..even though normally the Pi would want to power the device being plugged into its OTG port.
The fifth ID pin thing I believe is just a way to identify which end of the OTG cable A or B is plugged into the port so it knows what to default to at startup, although there are more advanced protocols nowadays that can control a lot of that. I am hoping this USB controller is kinda dumb and not too smart for it's own good so it will interwork with your driver. https://en.wikipedia.org/wiki/USB_On-The-Go
Don't want to put the cart before the horse but if initial testing works out we might be able to make a 64MB PSRAM P2 board that fits neatly inside the cartridge...and could look a bit like this. Maybe HDMI out is an option as well (micro or mini socket). Or if we can figure out USB-C alternate modes we could dual purpose that instead for carrying HDMI and/or a PropPlug input path via USB.
UPDATE: we could do something like this perhaps...
P0 - uSD card power reset/detect pin?
P1 - PSRAMCS1
P2 - PSRAMCS2
P3 - PSRAMCLK1
P4 - PSRAMCLK2
P5 - LCD VSYNC
P6 - LCD HSYNC
P7 - LCD DE
P8,9 - USB D-/D+
P10-15 - BLUE
P16,17 - PWM1, PWM2
P18-23 - GREEN
P24,25 - POWERON, !POWERDOWN
P26-P31 - RED
P32-P39 - HDMI
P40-P55 - PSRAM DATA
P56 - LCD PIXELCLK
P57 - independent uSD card DO pin or !CS to interfere less with boot Flash?
Looking good for USB. I just hooked up a janky connection to the handheld case via the Parallax serial device breakout on a P2-EVAL and a separate ground wire and loaded USBNEW's hidpad_to_vga.binary application. Am now seeing all front buttons (except the turbo "star" which I think only acts locally inside the controller to turbo press a nominated switch in-game), report binary 1 when pressed, also including the rear trigger switches and extra "home" switch on the front panel which can be used to jump out to a menu. The 4 way direction switch reports as a HAT with values from 00-07 or 0F depending on which direction(s) are actively pressed down on the 8 way switch. The USB PID/VID reports this as an XBOX360 controller.
This is great news so far. I didn't do a lot of experimenting with P2 resets and shutdowns etc, but so far so good and means really it's just the LCD that needs to work now for this to be a success. I do hope it's not flipped or something, then we might be screwed.
Tried feeding a P2 OPN2 cog demo audio output into the GPi Case 2W's GPIO19 pogo pin position (which should be one of the audio PWM channel inputs) with the unit switched on but couldn't hear anything with volume level slid fully up/down. Might be a couple of things. Perhaps the internal amp path is only turned on when active video is present, to avoid clicks/pops at startup, or perhaps P2 DAC line level outputs are no good and PWM logic levels are needed if filtered/processed internally. Harder to reach GPIO18, but that might also be it if it uses a mono amp only internally - I should retry this from the headphone outputs too. EDIT: no output on headphone socket L&R either.
Comments
Yeah they both float, only D-/D+ pass through the flex cable to the card edge fingers. I guess the controller doesn't really need ground and VBUS because it's supplied internally and grounded separately. 5V already directly powers the Pi from the Case 2W Lipo boost converter, so there's really no need to feed 5V back via VBUS into the controller with the Pi acting as a host..even though normally the Pi would want to power the device being plugged into its OTG port.
The fifth ID pin thing I believe is just a way to identify which end of the OTG cable A or B is plugged into the port so it knows what to default to at startup, although there are more advanced protocols nowadays that can control a lot of that. I am hoping this USB controller is kinda dumb and not too smart for it's own good so it will interwork with your driver. https://en.wikipedia.org/wiki/USB_On-The-Go
Don't want to put the cart before the horse but if initial testing works out we might be able to make a 64MB PSRAM P2 board that fits neatly inside the cartridge...and could look a bit like this. Maybe HDMI out is an option as well (micro or mini socket). Or if we can figure out USB-C alternate modes we could dual purpose that instead for carrying HDMI and/or a PropPlug input path via USB.
UPDATE: we could do something like this perhaps...
P0 - uSD card power reset/detect pin?
P1 - PSRAMCS1
P2 - PSRAMCS2
P3 - PSRAMCLK1
P4 - PSRAMCLK2
P5 - LCD VSYNC
P6 - LCD HSYNC
P7 - LCD DE
P8,9 - USB D-/D+
P10-15 - BLUE
P16,17 - PWM1, PWM2
P18-23 - GREEN
P24,25 - POWERON, !POWERDOWN
P26-P31 - RED
P32-P39 - HDMI
P40-P55 - PSRAM DATA
P56 - LCD PIXELCLK
P57 - independent uSD card DO pin or !CS to interfere less with boot Flash?
Looking good for USB. I just hooked up a janky connection to the handheld case via the Parallax serial device breakout on a P2-EVAL and a separate ground wire and loaded USBNEW's hidpad_to_vga.binary application. Am now seeing all front buttons (except the turbo "star" which I think only acts locally inside the controller to turbo press a nominated switch in-game), report binary 1 when pressed, also including the rear trigger switches and extra "home" switch on the front panel which can be used to jump out to a menu. The 4 way direction switch reports as a HAT with values from 00-07 or 0F depending on which direction(s) are actively pressed down on the 8 way switch. The USB PID/VID reports this as an XBOX360 controller.
This is great news so far. I didn't do a lot of experimenting with P2 resets and shutdowns etc, but so far so good and means really it's just the LCD that needs to work now for this to be a success. I do hope it's not flipped or something, then we might be screwed.
Tried feeding a P2 OPN2 cog demo audio output into the GPi Case 2W's GPIO19 pogo pin position (which should be one of the audio PWM channel inputs) with the unit switched on but couldn't hear anything with volume level slid fully up/down. Might be a couple of things. Perhaps the internal amp path is only turned on when active video is present, to avoid clicks/pops at startup, or perhaps P2 DAC line level outputs are no good and PWM logic levels are needed if filtered/processed internally. Harder to reach GPIO18, but that might also be it if it uses a mono amp only internally - I should retry this from the headphone outputs too. EDIT: no output on headphone socket L&R either.