[FR] Ability to customize remaining GPIO pins after DPI screen connection

CemTezcan commented 4 years ago

Hello,

It would be great to customize GPIO pins which remains after connecting DPI screens. especially RGB 565 type of pinout has bunch of unused GPIO pins.

https://www.raspberrypi.org/documentation/hardware/raspberrypi/dpi/dpi-packing.png

https://www.raspberrypi.org/documentation/hardware/raspberrypi/dpi/README.md

rhester72 commented 3 years ago

Can you be (much) more specific on what the actual ask is, here? I'm not clear on what's being requested.

randyrossi commented 3 years ago

Some DPI adapters don't use all the GPIO pins so there are some left over that could be used for (maybe) 1 joystick. There is a board out there (can't remember name/model) that has DPI for video and a few GPIO pins on a header. Currently if you use DPI, GPIO joystick support is effectively shut down because the code assumes you're going to use them all for video. So that logic needs to have some side configuration to reserve specific pins for GPIO and then allow them to be used for joysticks.

On Tue, Feb 2, 2021 at 2:43 PM rhester72 notifications@github.com wrote:

Can you be (much) more specific on what the actual ask is, here? I'm not clear on what's being requested.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/randyrossi/bmc64/issues/126#issuecomment-771925981, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI3HKA6OCZWZ6LIWMES2FTS5BIX5ANCNFSM4MGKATVQ .

-- Randy Rossi

"There are only two things that are hard about computer science; Naming things, Cache Invalidation, and Off-by-one errors."

CemTezcan commented 3 years ago

The DPI adapter that @randyrossi mentioned about is RGB LCD HAT of Waveshare. According to its schematics (https://www.waveshare.com/w/upload/8/8a/RGB-LCD-HAT-Schematic.pdf) it uses the RGB666 pinout on the 5th row of this image (https://www.raspberrypi.org/documentation/hardware/raspberrypi/dpi/dpi-packing.png)

Since GPIO 22 to 27 is available for this hat, we can assign 4 directions and fire (even space button!) to these GPIO pins by making them available to be reconfigured when DPI screen is presented on the machines.txt with "enable_dpi=true". This setting sets the GPIO --> Config menu as Disabled.

If you can add a secondary config section under GPIO submenu to reconfigure GPIO 22, 23, 24, 25, 26 and 27 when DPI screen is present that would be super awesome!

rhester72 commented 3 years ago

OK...the place where this gets sticky is that you're now special-casing a subset of DPI, which raises the following questions:

As there's no way to know which DPI system is in use with "enable_dpi=true", are you proposing something like "enable_dpi_waveshare=true" (or perhaps enable_dpi=waveshare so we don't end up with a billion combinations later) so we know it's safe to repurpose those inputs?
Assuming the above or an equivalent solution, (asking out of ignorance because I don't have the hardware) do we lock the only possible GPIO config to #3 (Waveshare Hat), or is this a different fixed GPIO config? If the latter, what should go to which pin? (Obviously, the closer we can keep to some sort of standard, the better.)
Do we still allow "Configure Custom GPIO" with that subset of pins?
Do the GPIOs work the same way on Pi Zero? (I'm asking because my current test bench is this lovely piece of kit and I am not keen on messing about with GPIOs on there ;)

randyrossi commented 3 years ago

If you look at viceapp.cpp, there's a function called SetupGPIOForDPI() It sets all 28 pins to DPI (function alt2). So first, that would have to get some config to no longer assume they should all get Alt2. I would add something that would let the user explicitly define which of the pins should be reserved for dpi and which can still live on for either in / out for other purposes. That can be in config.txt or settings.txt.. It would be up to the user to know their hardware. I would not add UI for it. The default should be all pins go to alt2.

The way things are written now, though, it just cuts off all gpio to other features if dpi is enabled. So you'd probably have to add another array to hold the purpose of a pin and remove that restriction. It would take some careful thought to ensure the Pi gets the pins it wants set to Alt2 while the code that wants to use other GPIO pins for other purposes can still operate. Then you'd have to consider UI changes to not allow the user to select pins that have been allocated to DPI too for a better user experience/safety. It's not a trivial task.

On Tue, Feb 2, 2021 at 4:24 PM rhester72 notifications@github.com wrote:

OK...the place where this gets sticky is that you're now special-casing a subset of DPI, which raises the following questions:

As there's no way to know which DPI system is in use with "enable_dpi=true", are you proposing something like "enable_dpi_waveshare=true" (or perhaps enable_dpi=waveshare so we don't end up with a billion combinations later) so we know it's safe to repurpose those inputs?

Assuming the above or an equivalent solution, (asking out of ignorance because I don't have the hardware) do we lock the only possible GPIO config to #3 https://github.com/randyrossi/bmc64/issues/3 (Waveshare Hat), or is this a different fixed GPIO config? If the latter, what should go to which pin? (Obviously, the closer we can keep to some sort of standard, the better.)

Do we still allow "Configure Custom GPIO" with that subset of pins?

Do the GPIOs work the same way on Pi Zero? (I'm asking because my current test bench is this lovely piece of kit https://www.ebay.de/itm/Faszination-C64-Portplatine-Raspberry-Pi-Commodore-64-Emulator-BMC64-2110/164599327502 and I am not keen on messing about with GPIOs on there ;)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/randyrossi/bmc64/issues/126#issuecomment-771998427, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI3HKBLFXUBRN4FVKXY46DS5BUQTANCNFSM4MGKATVQ .

-- Randy Rossi

"There are only two things that are hard about computer science; Naming things, Cache Invalidation, and Off-by-one errors."

CemTezcan commented 3 years ago

@rhester72 I don't know all the answers but will try to answer them in any case,

Acquirable DPI screens mostly use the waveshare RGB LCD hat (or it's clone). I would start with this one (row 5 on the dpi-packing.png) on this master build by not customizing the enable_dpi=true function, and if it's a success than I would enlarge the scope to other minor RGBXXX possibilities by finally adding an option like enable_dpi=RGB_rowX (where X stands for the row number of the dpi-packing.png from 1 to 6)
*3 Waveshare Hat option is not the DPI RGB LCD hat... it's gaming hat https://www.waveshare.com/game-hat.htm So, no need to touch to it.
I would allow configure custom gpio just for the remaining pins of RGBxxx pinout. maybe by adding a different submenu for it.
Yes pizero and pi3 GPIO pinout is same.

rhester72 commented 3 years ago

@randyrossi Agreed - this is not a few lines of code change, and I have no means of effectively testing it. @CemTezcan I think I conceptually understand the ask, but I don't think I'm the right guy to implement it, to be honest.

CemTezcan commented 3 years ago

@rhester72 I see. Thanks anyway. Also thanks for the gamepad update. At least feature request has been more detailed while we're discussing over it.

We will be waiting for you to be available hopefully soon @randyrossi :)

Thanks so much to you both.

CemTezcan commented 2 years ago

@randyrossi hello Randy. Any luck on adding this feature to menu?

randyrossi / bmc64

[FR] Ability to customize remaining GPIO pins after DPI screen connection #126