openstickcommunity / gp2040-ce Goto Github PK

Add the on-board analog add-on to add-on pin selection.

I had it set to boardconfig.h only and not in the web-config. I'll have to add limits so it can only select Pin 26, 27, or 28.

From: https://gp2040-ce.info/#/?id=installation

Clicking on the link for the config folder leads to a 404 (https://gp2040-ce.info/#/configs)

I have built several flatboxes now and this button (4th from the left, or 1st of the second grouping of 3 buttons) never seems to do anything on the gamepad-tester site. Every other button works. Is it a console-only button or something? I have not had a chance to test on a PlayStation yet.

Currently, when the Player LEDs are set to RGB they default to green.

This can be changed via:
https://github.com/OpenStickFoundation/GP2040-CE/blob/main/src/addons/neopicoleds.cpp

Line 153-164

// Apply the player LEDs to our first 4 leds if we're in NEOPIXEL mode if (PLED_TYPE == PLED_TYPE_RGB) { switch (inputMode) { // HACK case INPUT_MODE_XINPUT: for (int i = 0; i < PLED_COUNT; i++) { float level = (static_cast<float>(PLED_MAX_LEVEL - neoPLEDs->getLedLevels()[i]) / static_cast<float>(PLED_MAX_LEVEL)); float brightness = as.GetBrightnessX() * level; rgbPLEDValues[i] = ((RGB)ColorGreen).value(neopico->GetFormat(), brightness); frame[PLED_PINS[i]] = rgbPLEDValues[i]; } } }

Specifically the (RGB)ColorGreen) value.

If this could be added into the boardconfig.H and web UI that would be great.

There are two parts to this:

1 - Add this into boardconfig.h as a #define that can be set to any of the available colors, this should be added into the sectino of the boardconfig file where the player LED info is set.

2 - Add this into web-config. This is more challenging since we do not currently have the ability to enable any of the player LED info. Ideally this would live in a new section of the LED configuration called Player LEDs

First drop down box - Player LED type
Option 1 - 'PLED_TYPE_NONE' - "No player LEDS"
Option 2 - 'PLED_TYPE_PWM' - "Player LEDs via GPIO" (will need to check for conflicts with other assigned pins)
Option 3 - 'PLED_TYPE_RGB' - "Player LEDs via RGB LED"

Entry box 1 - Player 1 assignment (when PWM selected above this becomes the GPIO for P1 LED, when in RGB this becomes the LED number in the chain)
Entry box 2 - Player 2 assignment (when PWM selected above this becomes the GPIO for P2 LED, when in RGB this becomes the LED number in the chain)
Entry box 3 - Player 3 assignment (when PWM selected above this becomes the GPIO for P3 LED, when in RGB this becomes the LED number in the chain)
Entry box 4 - Player 4 assignment (when PWM selected above this becomes the GPIO for P4 LED, when in RGB this becomes the LED number in the chain)

Second drop down box - Player LED color (only available if 'PLED_TYPE_RGB' is chosen)
Options are all the available colors.

as a note - the Player LEDs (if RGB) must be at the end of the chain and must be in order [example 10,11,12,13]).

I honestly don't know if we can or how we'd do it, but that would be neat.

It might not be possible outside of running a debugger on the chip, but the FlashPROM issue made me think about it.

If there's no way, we can close this issue.

Hi, I have tested the switch mode and I detected that the arcade stick doesn't work in all games. But in the Switch menu it does. Is this an expected behavior? It's necessary the game support this control ?

I have tested with the following games:

Sonic Mania: It works
Alex Kidd: It doesn't work
Hades: It doesn't work

I'd like to be able to support a split or multi-piece controller with GP2040-CE.

Ideally, this would be accomplished by running two separate controllers with their own RP2040 and own copy of the firmware. Each one would use a different configuration file when built. Each configuration file would specify whether the device it's intended for is a main/host or sub/client controller. The host would be the one that plugs into the console/computer and reports the inputs. The client would only connect to computers for firmware updates, and would otherwise only send its button state to the host and receive LED data from the host.

This should also support Issue 101 in such a way that the same gamepad button can be bound on both the host and client units, and the input would be triggered when either physical button is pressed.

The comms between the host and client need to happen with a simple 2 wire protocol so minimal cabling over 2 GPIO pins can be used. For example, a TRRS cable like many split keyboards. Ideally UART can be used, but having support for more advanced protocols like RS485 would be great for future proofing if possible.

Splash display is not respecting the default time properly

We need to look at the logic for #define SPLASH_DISPLAY

Additionally, we started having Get* functions in the StorageManager.h which breaks our current coding conventions. We need to remove these and make the StorageManager.h get functions single option only rather than option.

This means we need to get rid of

int Storage::GetButtonLayout()}
int Storage::GetButtonLayoutRight()
int Storage::GetButtonLayout()
int Storage::GetButtonLayoutRight()
int Storage::GetSplashMode()
int Storage::GetSplashChoice()
int Storage::GetSplashDuration()
int Storage::GetSplashMode()
int Storage::GetSplashChoice()
int Storage::GetSplashDuration()

and start being more strict about PRs that do this.

There are a number of new OLEDs hitting AliExpress that appear to have their display flipped.

OneBitDisplay.h supports the ANGLE_FLIPX command:

enum {
  ANGLE_0=0,
  ANGLE_90,
  ANGLE_180,
  ANGLE_270,
  ANGLE_FLIPX,
  ANGLE_FLIPY
};```

It would be great to have this added into BoardConfig.H as well as the web-config for anyone using the new displays.

hello, can you add a separate debounce setting for each button to the web adjuster?
It can be assigned between 0-10ms.

There was a PR on the original GP2040 that had the foundation for input history from Sleep:

FeralAI/GP2040#48

I compiled and tested this.

It currently is a running line that will max out on screen length and will only resister one input of each input type in a row. As an example, if I were to press left and then left again, it would only register one instance of left.

For this to be more useful we would want to limit the amount of space it takes up and also have it include additional instances of input types that are pressed in a row.

Ability to add the turbo LED to the RGB LED stack + Web UI addition for configuring it.

I am unsure where it should be placed in the RGB LED chain.

Ideally after the Player LEDs, however they do not play will with having things after them.

The configuration for the LED should also include changing the color.

When you press a remapped button, the display will show the button's original position instead of its new position.

"Same as HayBox. Code for the TinyUSB keyboard implementation is already in Hay, not sure if Crane's uses TUSB.
They take the approach of registering a composite device that supports both KB and gamepad usage.
Button mapping in webconfig."

Fightboard (regular and mirrored) needs to be added to CMake for .UF2s on release.

Currently you cannot assign multiple instances of a button to different GPIO pins.

As an example, with UP mapped to GPIO2, I cannot add an additional instance of UP to GPIO22.

This would be an add-on that can be configured in the web-ui.

The first section would let you specify the GPIO that the additional button is hooked up to.
The section section would let you specify which button has the additional instance of assignment.

As an example, you may choose to assign UP to GPIO22, or P1 or even START.

Migrate away from PlatformIO and the Wizio-Pico dependencies, and use the Pico SDK directly via CMake.

Will need to adjust how we approach builds for community boards.

when using inverted DPAD if the down button is pressed the LED for the up button is illuminated and visa versa
video of bug:
https://photos.app.goo.gl/UAk4NvH8KEwhtYp29

To elaborate on this my suspicion is that when the invert DPAD shortcut is used it is not also switching the assigned RGB LEDs order.

A toggle is available to invert the Y-axis input of the D-pad, allowing some additional input flexibility. To toggle, press START + HOME + RIGHT. This is a temporary hotkey mapping for this feature, so keep an eye on updated releases for this to change.

Hello, I was reading through the documentation here. I've never written my own Raspberry Pi code, I've always used Arduino. I'm trying to make a custom encoder for an arcade cabinet that will use a true analog stick inputs with x input. I want to get real nitty gritty into the actual code of the encoder, like have switches that switch between 8 way vs 4 way vs 2 way vs true analog input for the left stick. I'm thinking I'm better off using the Arduino x input libraries as this GP2040 library is easier to set up but If I wanted to get into the deeper stuff like that then I would have to modify the library itself. For instance I can't find true analog input for the analog sticks with this library. Is true analog input possible? Is coding without the web interface using functions like "output left x input stick value +1035" possible or is this library built more to be plug and play?

The only Arduino downside is the USB+uploading code to it is janky haha which is why this library is appealing to me.

After some conversation in the BentoBox channel I am throwing a bounty up to see if we can get a new LED mode added that allows someone to configure a static on/off color per button / LED via web-config.

As an example, if I have a stickless layout I could make LEFT, DOWN, RIGHT, UP green and the rest red. Then on press LEFT, DOWN, RIGHT, UP could turn blue while the rest could turn pink.

We already define colors in the code so those could be whats provided via the web-config.

The web-config would have a section in the LED configuration to deal with this new mode.

https://github.com/OpenStickCommunity/GP2040-CE/tree/main/configs

The configs directory is REQUIRED for someone who is building a controller for hand-wired or otherwise trying to utilize this software to figure out which pico pin does what thing

Please add this https://github.com/OpenStickCommunity/GP2040-CE/tree/main/configs/Pico picture to the website.

It's not very user friendly to dig through source to find pictures!

I feel like this is just broken links though? The Installation part of : https://gp2040-ce.info/#/ shows a list of links to these dead internal links

• https://gp2040-ce.info/#/configs/DURAL
• https://gp2040-ce.info/#/configs/DURAL
• https://gp2040-ce.info/#/configs/FlatboxRev4
• https://gp2040-ce.info/#/configs/WaveshareZero
• https://gp2040-ce.info/#/configs/CrushCounter
• https://gp2040-ce.info/#/configs/OSFRD

These links all show "404-not found"

but if they linked to even just the blobs internal to the project it would be very useful to people looking into the project, I can tell you all are trying to make this project inclusive by basing on platformIO and documenting how to jump in, this would be a good use of time for someone who has the time. Thanks!

:)

Reverse Causing Simultaneal DP Inputs And LS RS Inputs in respective stick modes.

To recreate this issue - Enable Reverse mode in webcofig, restart in controller mode, change the Stick mode to LS or RS. This makes Both DP and LS RS enter inputs at the same time.

"0.5.2 version, I found OLED stick animation if I use DP is OK,
but if use LS model the OLED not have any move on joystick animation, just joystick ball on center not move"

I have tested this and it is due to LS and RS not being defined in the gamepad. Not sure if this can be fixed but we will look into it further

Currently the web-config mode does not work on Mac or Linux.

Adding support for the PCA9535 16bit GPIO expander from Texas Instruments
https://www.ti.com/document-viewer/PCA9535/datasheet/GUID-2E758BF2-C717-41D1-BC2E-80CE2E71C3C9

This will allow us to expand the number of digital pins by 16 per each expander added to the I²C bus.

Only focusing on using the latest Pico SDK, we want to update our reference to being the 1.5 SDK.

This is ONLY to update the SDK and fix any breaking changes.

Bluetooth support will be considered in a separate issue.

Add the ability to set the length of time that the splash screen is active for via the web-ui.

Options would include:
Default
5 seconds
10 seconds
30 seconds
Always on

Currently people who enjoy SHMUPS cannot use the charged shot feature if turbo is enabled on a the same button.

This requires the person to either turn off turbo to do a charged shot or assign another button in game to be a secondary shot button (not available in all games).

This bounty is to add a dedicated SHMUP section to the add-ons page which allows for the following:

1 - Ability to set an always-on turbo to a specific button or GPIO (this eliminates the need to set it on every reboot)
2 - Ability to set an additional instance of a button to a GPIO pin that would not be impacted by turbo

As a bonus

3 - Ability to have a pot or rotary dial setup which can be used to adjust the speed of the turbo on the fly without the need for shortcuts.

Trigger a build of the WebConfigurator project, and generate a new fsdata.c file, and upload it as an organizational artifact.
Then when GP2040-CE builds, always download latest artifact for fsdata to use in the build.

In the latest version there is an error when entering an example mvc2 game. Only the addresses work and the home button tested in version 0.6 and 0.6.1 on the home screen works perfectly. Greetings

It would be useful for diagnostic purposes if the LED on the pico could be used as an indicator light.

A few ideas:

• Fast Blink if power only and no USB data connection
• Solid if power+data
• Flicker on button press
• Slow Blink if in web-config mode

Add an option to force the SSH1106 / LCD options in the display settings. This will solve the edge case with certain SH1106 displays not showing our OLED code.

@thesuccubus current main fork supports this but should be changed:
https://github.com/thesuccubus/GP2040-CE

With the new ability to upload a custom image we can free up space by removing the others.

Our main logo should stay, and then have one other option which is the custom upload.

Right now the SOCD cleaner if its set to Up-Win or Neutral is too aggressive, I need to fix this

Up-Win
Gamepad Right, Dual Left, Dual Right SHOULD be Right ( R + (L + R) ) but is instead Neutral FIX THIS
Gamepad Down, Dual Down, Dual Up is UP (U + (D + U)) but only by coincidence

Neutral
Gamepad Right, Dual Left, Dual Right SHOULD be Right ( R + (L + R)) but is instead Neutral FIX THIS
Gamepad Down, Dual Down, Dual Up is Neutral (U + (D + U)) but should be Up FIX THIS

Last-Win
This is working fine, don't change it

Allow unassigned pins to dual directional.

This opens up the possibility of having a single extra directional button or just up/down,left/right combos instead of all 4 pins.

The reboot button pushes the drop-down on the top-right of the web UI too far to the right. Minor change and doesn't matter once @Lemon-King gets their changes in, but just aesthetics.

Was trying set up my own configuration for a board I'm working on and ran into cmake issues due to main missing fsdata.c from the lib/httpd directory.

Not sure if that's intended for some reason but I went and grabbed it from another branch that looked fairly recent.

I have loaded the GP2040-CE_0.6.2_Pico.uf2 binary on a Raspberry Pico WIFI without any board more and the controller stop working. After severals plugs and unplugs the wire the controller appears to work, but after a minute working the controller stop again.The system for gaming is a raspberry pi 3 with retropie. In the system logs, the controller appears to we installed correctly. I have to load again the firmware and the behaviour is the same as described. I have tested with a Raspberry Pico and the controller works fine. Is any issue with the pico wifi?

I can't know if the controller is ON, because I don't have a computer with windows and the web configuration doesn't work. is there any GPIO with a powerON led functionality?

The old link only goes to 0.4.3

https://docs.google.com/spreadsheets/d/1eeX0SCOYnUDZMYzt_69wDpjnB_XUtvsfvHJYxxgTj28/edit#gid=1559471406

Update this to a sheet owned by someone else, and go all the way up to 0.6.0

Currently the splash image is saved in 16 chunks to get around the maximum post payload size of 2kb. When chunk 0 is received the target buffer is cleared and when chunk 15 is recieved the current content of the buffer is saved.

Unfortunately, it is not guaranteed that the post request are received in order. If a request is received after chunk 15 it will be missing from the saved image, which will then have a black bar going through it.

This looks like this:

I added some logging to setSplashImage() to verify this.

This is a log from me using Firefox 109.0:

received setSplashImage with index 0
clean temp array
received setSplashImage with index 1
received setSplashImage with index 2
received setSplashImage with index 3
received setSplashImage with index 4
received setSplashImage with index 6
received setSplashImage with index 7
received setSplashImage with index 8
received setSplashImage with index 9
received setSplashImage with index 10
received setSplashImage with index 11
received setSplashImage with index 12
received setSplashImage with index 13
received setSplashImage with index 14
received setSplashImage with index 15
persist splash image data
received setSplashImage with index 5

As you can see chunk 5 is received after the save operation already happened.

I think that splitting up the image in multiple requests is not even necessary. A 128x64x1bit image is 1kb bytes, which could be base64 encoded into 1368 bytes. That is still well below the maximum of 2kb and would avoid all of the complexity of splitting the image and the problems that come with it.

Please add a 4-way input method to the new firmware ↖↗↙↘， The default 16, 17, 18, and 19 pins are good preset schemes that truly implement 8-way input. This is very necessary for combat games and players, thank you.

Currently we use a strange string of calculations to size and position inputs on the screen. This appears to be dynamic so I am guessing it was intended for displays that were in non-standard sizes.

I would like to see this changed to absolute positioning + size.

An example:

Button K1 (8, 20, 40)
Radius = 8 pixles
X location = 20 pixles
Y location = 40 pixles

We had to hot-fix this in 0.6.1

It looks like dual directional enabled with no pins assigned causes the dpad to reverse up and down.

in 0.53 ver if set to LS + switch mode on pc, up down right is no problem,
but left will same time out DP direction down

We need to update the documentation how to debug the code in our new CMake library. Right now the documentation is for our old Platform.IO approach.

It requires a launch.json and settings.json not currently in the repo, and only @deeebug and myself have it setup.

https://gnutoolchains.com/arm-eabi/openocd/ <-- OpenOCD for Windows (we'll need a Linux and Mac install doc as well)
https://github.com/raspberrypi/picoprobe/releases/tag/picoprobe-cmsis-v1.0.1 <-- cmsis-dap based picoprobe

This is actually for WebConfigurator, but the README has our old information about the build python.

Update the WebConfigurator with information about how to run npm run build and how fsdata.c works with our new CMake system.

When I plug in the board, my computer detects it as a POKKEN CONTROLLER, and I can't seem to open the web configuration to change the mappings.

"
See my comment in OpenStickFoundation/GP2040-CE#68
This feature could utilize the macro def functionality i discuss therein for the button chords, etc.
Also the game mode profile should be considered OpenStickFoundation/GP2040-CE#77

per button pair SOCD config - refactor code to allow a per-button pair config of SOCD behavior rather than a tuple for all directionals.
This functionality could really apply to any button pair, not just directionals, but that could also be a macro definition with some options for priority.
Can still offer the user pre-canned tuples for users in config for ease of use, but allow per-axis config, and storage
allow toggling through cleaning modes for a specific axis through a button combo. This way user toggles through cleaners for any axis up to 5 times to find the mode they want, rather than possibly having to toggle through 25 permutations
display SOCD mode for each axis on oled, possibly flash LEDS in pattern assigned to each mode (ie Neutrai or Max Cardinal)
Add option to disable SOCD alltogether
Ability to customize SOCD behavior. This is where the macro definition functionality referenced in my comment on OpenStickFoundation/GP2040-CE#68 comes into play. A socd cleaner for two buttons is a truth table with 4 rows. Each of these 4 rows can be described using the same methodology i suggested for macros, perhaps with some restrictions on what the user can specify when defining a macro vs a socd mode.
for example if @henrebotha wants there a single frame of neutral to be inserted when a clean for last input occurs, he could drag a node representing Neutral input for X milliseconds into each relevant row that corresponds to the truth table.
"