External RGB LEDs support

[SeongGino]

Not implemented yet, but will be soon (when I get my hands on another camera and a Pico to use with generic four-pin LEDs).

However, there are some things to note:

• Currently we use Adafruit's DotStar and NeoPixel libraries. While these could indeed be used, it leads to generally messier code and would necessitate variables/preprocessor defines for each and every one.
  • FastLED has been considered, and I even implemented in a local build. However, that comes with build issues on Pico/RP2040 devices. These can be worked around on Pico by setting the compiler optimization to "Small (-Os) (Standard)".
    • Even so, this comes with some scary-looking compiler messages when built - none that are fatal, but may confuse a new user. Should we implement this anyways as an option (via a separate branch)?
• Separate support for normal/"dumb" four-pin LEDs needs to be implemented separately.
  • Main limiting factor here is the Pico's four analog pins - three is all that's needed, but would likely conflict with #5 when it's implemented (as analog sticks need an X and Y pin available at minimum).
  • Should it just behave the same as the onboard LEDs on Adafruit boards does currently?

[cmjdbb]

Why not use the WS2812B RGB LED? It only requires one IO port.

[SeongGino]

As in an external NeoPixel? Yeah, we could use that for sure. But I'm mainly anticipating that users will put in their own LED of choice, whether that be a different kind of addressable unit or a regular 4-pin (I have a build I'm planning soon which I intend to use a 4-pin emitter), so using one single library could be a way to streamline things code-wise (the FastLED version I have locally is a bit cleaner wrt LED calls than the original IF DOTSTAR ELSE IF NEOPIXEL clauses in use now) while letting people only have to change a few lines depending on what their chosen unit is (or simply pick from a selection of devices, should I ever get around to making an embedded WebUI like what was suggested a while ago...).

Simple emitters will likely need their own path alongside FastLED-supported devices, since the only thing provided uniquely by the library is conversion to different color methods, but since we're just sending R/G/B values directly, that part isn't really necessary. It also seems like the LED pins don't have to be on the analog pins specifically, just that they're on PWM-capable pins - though it does go to show we are running out of pins on an ItsyBitsy board with fully stocked features, so maybe that's a different conversation to be had entirely aha. Pico users probably won't have that issue as much.

[larrybud2004]

@SeongGino "These can be worked around on Pico by setting the compiler optimization to "Small (-Os) (Standard)"."

Can you tell me how to do that? I added -Os to the "build_flags" in platformio.ini and it didn't have any effect on the build error. I'm building in debug mode, which is when this build error popped up.

Also added it to the "debug_build_flags" and that had no effect either.

[SeongGino]

Can you tell me how to do that? I added -Os to the "build_flags" in platformio.ini and it didn't have any effect on the build error. I'm building in debug mode, which is when this build error popped up.

Also added it to the "debug_build_flags" and that had no effect either.

These only refer to building within the Arduino IDE--someone more well-versed in PlatformIO would have to answer, unfortunately.

[cmjdbb]

(https://github.com/SeongGino/ir-light-gun-plus/assets/120959774/a6ba32d9-f268-4970-a469-b8732f0ca047)

[SeongGino]

Yes, I know what a Neopixel is, thank you lol.

[SeongGino]

Well, this took forever.

Freshly committed four-pin support in ff3af0c - feel free to test how this goes for y'all. Remember to keep in mind the differences between common anode (connect to 5V) and common cathode (GND), and connect to the board using appropriate resistors (apparently around 270- to 330 ohms is the sweet spot?).

I'm also reconsidering my decision of pulling in FastLED--just to reign in the scope a bit, I'll continue using the individual Adafruit NeoPixel/DotStar libraries for the short term and keep it restricted to just one at a time from those three options (along with fourpins, ofc). It'll make the eventual transition to a GUI-based install/OOBE process easier; if someone happens to want other addressable LED modules supported, we can re-reconsider switching libraries then.

Issue will remain ongoing until I add custom addressable support (and using the Wikicolors for fourpins).

[SeongGino]

So it turns out that FastLED does not support using pin numbers that aren't a constant, so it wasn't going to work out at all unfortunately.

This did give me the opportunity to focus on only one type of addressable, and cleanup/unify the RGB update implementation in general. Therefore, 6e9a22d has switched to NeoPXL8 and we now support external NeoPixels! (Even PXL8 decided to be a pain in the ass about working properly for whatever reason, even for just a builtin Pixel, so we're just sticking with the reference lib for the long run.)

Note that I have no idea if people will use strips, and for how long, so we only address the "first" pixel. If someone happens to have a need for that, I'll update things at a later time to accept a longer chain of Pixels. 8156b12 (the partial-PXL8 revert-fix) implements configurable length of NeoPixel strips, so even that's covered now.

All that's left now is addressing Wikicolors for Fourpins.

[SeongGino]

47d0976 now covers extracting packed color info into individual channels, so addressables and fourpins should be fully supported now, which completes RGB support for the next release. Closing...