Player LED indexes (RGB) treated as GPIO pins

[jakubkoziol]

Prerequisites

Please check the following before posting an issue / bug report.

• I am running the latest version of the firmware found HERE
• I have checked the documentation HERE and found no answer
• I checked to make sure that this issue has not already been filed HERE
• I am reporting the issue to the correct repository

Context

• Firmware Version: 0.7.6
• Name of device: any
• Link to where you purchased the device: N/A
• Is this a custom build?: no
• Operating System: N/A
• Browser: any

Expected Behavior

Player LED in RGB mode uses assigned LED indexes at the end of the LED strip to indicate player number.
Assigned LED indexes are not related to GPIO pins so they don't have impact on which GPIO pins are blocked.

Current Behavior

Assigning LED index to Player LED in RGB mode appears to treat LED indexes as GPIO pins.

This results in:

• Blocked GPIO pins with numbers corresponding to Player LEDs (RGB) index.
• Player LEDs (RGB) not working properly in XInput mode.

Steps to Reproduce

1. Flash firmware 0.7.6.
2. In LED Configuration set Player LEDs to RGB.
3. Set PLED Index to any values between 0 and 29.
4. Save.
5. Go to Pin Mapping.
6. Observe that pins with numbers equal to the LED index assigned to Player LEDs are displayed as "Assigned to addon".

[bsstephan]

* Player LEDs (RGB) not working properly in XInput mode.

I see why the rest of the reported issue is happening, but I'm not sure why the bug I introduced would break the LEDs. "Assigned to addon" basically means "core isn't going to touch this", so while the reservation is wrong, the LED addon should still be processing these fields normally.

[bsstephan]

Assigning this to me to fix the webconfig part, but I need someone else to tell me if the other issue described has anything to do with my change (and I'm currently skeptical as above).

[jakubkoziol]

I was doing some more testing and I ran into an issue that may be related to the second part.
Running in XInput mode while connected to Mac results in the controller hanging on the splash screen and not showing up as available device.
Other modes seem to be fine.
Running XInput on Windows also seems to be fine.

[bsstephan]

Interesting, I've pinged some folks who know more about the recent XInput changes to see if they suspect anything. I'll be sure to fix the webconfig part though.

[bsstephan]

@InfraredAces reminded me that this is something we discussed and missed. RGB player LEDs use the same configuration fields as the PWM player LEDs, and the PWM LEDs are GPIO based, hence the reservation. Probably the right thing to do is to add new fields for RGB player LED indexes. Sadly, this will be a bit more work, but I can take a crack at it soonish.

[bsstephan]

@jakubkoziol if you are up for beta testing, see my branch in #735 --- it should fix the issue. You can either nuke the board and start with a fresh config where RGB indexes are not reserved in Pin Mappings, or...

1. switch PLED mode to PWM temporarily
2. set all the pins to -1
3. switch PLED mode back to RGB
4. set the proper indexes (they probably aren't, due to new deduped fields)
5. save
6. confirm Pin Mappings no longer reserved the indexes

[jakubkoziol]

I saw on discord you already got info that it works but just to confirm, it's OK on my end as well!

One more related, minor issue I found, i2c pins defined in board config are not blocked in pin mapping on a freshly flashed board. Clicking save in peripheral mapping makes things work as intended.

As for the PLEDs not working when assigned, I had a few instances where they didn't work but I can't find a reliable repro steps. I'll post it as a separate issue if I figure out what's happening (and it doesn't turn out to be a user error).

[bsstephan]

Thanks for confirming #735 is good! Can you open a new issue for the I2C pins not being ASSIGNED_TO_ADDON on a fresh board? We should fix that but it doesn't sound critical, so we'll get to it soonish but not "hotfix" soon. :)

[jakubkoziol]

I couldn't get to it sooner but just posted #778.
Definitely not critical with pin to button mapping but I can imagine someone getting confused sooner or later.

[TheTrainGoes]

This has all been resolved. Closing issue