GPIO-based Turbo SHMUP mode toggles

[mortencombat]

Problem

I would like to have the possibility of toggling turbo mode for predefined button(s) using a hardware-based toggle (such as a latching SPST rocker switch).

The Turbo add-on SHMUP feature provides always-on turbo mode for (up to 4) predefined button(s), but I would like to be able to quickly disable/enable without having to also press the button on which to enable it (since in my case it would always be the same primary fire button). I am planning a joystick build with only 3 buttons but with 1-2 rocker switches to enable certain features.

Solution

I am proposing to add this feature as optional functionality to the existing Turbo add-on SHMUP MODE.

For each of the up to 4 buttons, I propose to add the option Hold to Enable Pin X (for each of 1, 2, 3 and 4).

The default value of Hold to Enable Pin will be -1. In this case the add-on will work exactly as it does today. The specified buttons without Hold to Enable will be added to alwaysEnabled in TurboInput::setup() as today.

If Hold to Enable Pin X is specified as a valid GPIO pin, the button will not be added to alwaysEnabled. Turbo mode for that button will instead be determined in TurboInput::process() based on the current state of the specified Hold to Enable pin.

Note

A related PR #1572 has previously been proposed by someone else. This PR also contains implementation of a specific expander and more, for that and other reasons it has not been merged into the codebase. What I am proposing is a more basic solution of some added functionality limited to the Turbo add-on itself.

Do you plan to work on this feature yourself?

I am willing and should be able to implement the feature myself.

I am asking for comments/suggestions and confirmation that this is something that you would be interested in merging into the main branch.

[TheTrainGoes]

Hey @mortencombat ,

I would be open to a PR that has a simplified approach to individually toggable GPIO for dedicated turbo.

[mortencombat]

Thanks @TheTrainGoes, sounds good. I will have a go at it.

[mortencombat]

I'm pretty much done with the implementation of the SHMUP Enable feature. A few issues came up:

I decided on a single Turbo SHMUP Enable action that can be assigned in GPIO Pin Mapping, which will cover all 1-4 SHMUP Turbo buttons. If using 4 different actions, it would not readily be possible to combine these actions/toggles on the same GPIO pin which I think should be possible. For my own use it's not that important since I only use one turbo button, so I can do it either way. Thoughts are welcomed.

Working on this, I could not make the SHMUP charge button feature work (even in base 0.7.12). Might just be me, but I believe it is caused by this part of the add-on not having been migrated to use GPIO Pin Mapping? I've updated it to use GPIO Pin Mapping and will include that in the PR. I don't myself have experience with usage of this particular feature, but I'm seeing what I think is unexpected behaviour. @TheTrainGoes Is my understanding correct, that if Simultaneous Priority Mode is Charge Priority, then if the Charge button is pressed, the corresponding Turbo button should not be sent (should be suppressed, even if it is pressed)?

[mortencombat]

Follow-up on above, this is my understanding of how the SHMUP Turbo/Charge should work:

Example scenario 1:
Always On B1, Charge Pin 2 -> B1
Any input mapped to B1 pressed: autofire B1
Pin 2 pressed (held): continuous B1
Both pressed: autofire B1 (if Turbo Priority), continuous B1 (if Charge Priority)

Example scenario 2:
Always On B1, Charge Pin 2 -> B2
Any input mapped to B1 pressed: autofire B1
Pin 2 pressed (held): continuous B2
Both pressed: autofire B1 + continuous B2 (regardless of Turbo/Charge Priority), OR
Both pressed: autofire B1 only (if Turbo Priority), continuous B2 (if Charge Priority) ?

Hope someone can clarify my understand of this 😄