Use diozero for GPIO

[thatcomputerguy0101]

Description

The old GPIO abstraction was replaced with diozero, which supports most hardware running Linux due to its use of GPIO character devices provided by the Linux kernel. diozero also supports alternate providers if for some reason the character device API is insufficient. Certain capabilities outside of the character device API is also implemented for common hardware.

Custom GPIO commands are implemented via a custom diozero provider. The configuration for custom GPIO will need manually updated according to the Hardware Config documentation page.

The status LED class was also reworked to support additional statuses or LED indication types, although none have been added yet.

This was tested on a RPi 5 with LL3 illumination LEDs and an RGB status led attached. All capabilities worked as expected. All 8 status LED colors were tested and functional via modifying the code. Basic functionality of custom GPIO was tested with dummy commands.

closes #2062

Meta

Merge checklist:

• Pull Request title is short, imperative summary of proposed changes
• The description documents the what and why
• If this PR changes behavior or adds a feature, user documentation is updated
• If this PR touches photon-serde, all messages have been regenerated and hashes have not changed unexpectedly
• If this PR touches configuration, this is backwards compatible with settings back to v2025.3.2
• If this PR touches pipeline settings or anything related to data exchange, the frontend typing is updated
• If this PR addresses a bug, a regression test for it is added

[samfreund]

Looks like tests need to be fixed.

[samfreund]

Also seems like you grabbed some commits off a different branch when you created this one. You can fix that using interactive rebase.

[Gold856]

Looks pretty good at first glance. The big question I have is boards that support setting LEDs via a command of some sort, but not via diozero. If we do want to support LEDs on that kind of board, we still need CustomGPIO (I think). If not, we should clean up our config to not have those command fields.

[thatcomputerguy0101]

I am currently planning to leave custom GPIO commands unimplemented, since diozero should work for the vast majority of boards with built-in GPIO. An advanced user could inject an alternate provider invisible to the rest of PhotonVision if for some reason the built-in provider does not work. The diozero.devicefactory system property could be set from a Photon setting, which will try and load the specified class dynamically, but a user capable of adding another provider is likely also capable of modifying the service file that launches Photon to specify it there.

The commit history and unit tests will be fixed before the draft status of this PR is removed.

[thatcomputerguy0101]

I am revisiting custom GPIO before unmarking this as a draft. I have some new ideas on how to make that happen.

[samfreund]

Can we make a PR to https://github.com/PhotonVision/photon-image-modifier as well to remove the installation of pigpio which is no longer needed?

[thatcomputerguy0101]

Can we make a PR to https://github.com/PhotonVision/photon-image-modifier as well to remove the installation of pigpio which is no longer needed?

This was on my plans.

[thatcomputerguy0101]

I elected to break compatibility with the older GPIO commands due to differences in behavior for the new GPIO commands. Specifically, the presence of new GPIO command dictates if they are enabled, instead of the platform. Also, setPWMCommand now takes a decimal between 0.0 and 1.0, instead of an integer percentage.

[thatcomputerguy0101]

An option for ledPWMFrequency exists in the documentation, but not in the code. Is it better to restore this option considering that it is often unnecessary to change, or finish removing it?

[Gold856]

If there's a good use case for ledPWMFrequency, maybe implement it? Otherwise, you can just delete it.

[thatcomputerguy0101]

This is the IC that an LL3 uses to drive its LEDs: https://www.diodes.com/assets/Datasheets/AL8860.pdf. The data sheet recommends a PWM frequency under 500Hz, so it is probably good to make it configurable.

[Gold856]

Then yeah, you can add it.

[thatcomputerguy0101]

This is the IC that an LL2+ uses to control its LEDs, which doesn't appear to have any PWM input frequency recommendations: www.ti.com/lit/ds/symlink/lm3407.pdf

[thatcomputerguy0101]

The default PWM frequency is 50Hz. I confirmed that the frequencies and duty cycles were being set accurately through an oscilloscope. I also confirmed that LL3 leds act weird with frequencies significantly above 500Hz, with no apparent difference between 50Hz and 500Hz.

[thatcomputerguy0101]

I am considering bypassing diozero's threaded blink implementation by creating a custom one with Photon's TimerTaskManager. Potential benefits include not interrupting performance critical code blocks on the main thread due to switching threads, and not needing to synchronize in ShellExec. Any other thoughts on if this would be an improvement?

[thatcomputerguy0101]

Since TimedTaskManager still uses threads, I left in the synchronization within ShellExec. I also refactored StatusLED such that it manages its own color and output state, while also opening the possibility for more detailed error indication in the future.

[Gold856]

Ooh, if we're gonna completely remove all the old GPIO classes and put in new ones, we may as well adjust the package name so that GPIO is all lowercase to match the styleguide. That's been bothering me for a while now.

[thatcomputerguy0101]

I think I got the package renamed? Changing the capitalization of a folder when the underlying filesystem treats folders as case-insensitive is tricky.

[Gold856]

Looks great! Thank you so much for all the work you put into this and for seeing it through to the end! We really appreciate the long overdue cleanup.