Skip to content

add pico_status_led #2501

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: develop
Choose a base branch
from

Conversation

peterharperuk
Copy link
Contributor

Add a status led library to make adapting to a "normal" led and the cyw43 led a bit easier.
Bonus support for ws2812 leds.

@kilograham
Copy link
Contributor

I think the color setting should be orthogonal to the On/Off and the color method should not mention WS2812 in their name - they should probably (and all the methods really) have a bool which says whether they do anything (so you can still use the library with no LEDs at all)

I'm not quite sure about the color APIs right now - somewhat leaning towards uint32_t so you can read, and allow r,g,b or w,r,g,b methods - maybe make it a #define what WRGB LEDs do when you set r,g,b (either 0 for WRGB or auto set)

@peterharperuk
Copy link
Contributor Author

I think the color setting should be orthogonal

Ah right. I was thinking you'd use the ws2812 as the blinking led. But just having a function to set the ws2812 colour might be better - as most boards seem to have both a simple led and a ws2812 led.

@lurch
Copy link
Contributor

lurch commented Jun 4, 2025

as most boards seem to have both a simple led and a ws2812 led.

There are definitely several boards with only a WS2812 and no normal LED though.

EDIT: Hmmm, so given that this is a "status LED" library and not a "WS2812 library", and we're basically using the ws2812 as though it were a normal LED; perhaps it makes sense to only have the "on" colour configurable, and always have the "off colour" as blank? 🤔 Because otherwise it might not be clear that e.g. "red" is "on" and "turquoise" is "off"! 🌈

@peterharperuk
Copy link
Contributor Author

I'll get rid of the on off thing and just have a method that sets the RGB of a colour status led.

@lurch
Copy link
Contributor

lurch commented Jun 4, 2025

I'll get rid of the on off thing and just have a method that sets the RGB of a colour status led.

IMHO being able to simply turn on/off an RGB LED would mean that a board with an RGB LED (using this status_led library) could be used identically (after a recompile of course) to a board with a normal LED? (e.g. the canonical "status-LED-blink" example)
Perhaps we've just got a different mental-model of what it is that this status_led library is actually for?

@peterharperuk
Copy link
Contributor Author

But most boards are configured with both. Who's to say that you shouldn't be able to control both individually?

@lurch
Copy link
Contributor

lurch commented Jun 4, 2025

But most boards are configured with both. Who's to say that you shouldn't be able to control both individually?

I'm not saying that you shouldn't be able to control both LEDs individually, I guess I was just kinda expecting a status_led library to control only one of them, with the other LED then free for user-purposes. 💡

So, entirely IMVHO:

  • board has a regular LED (i.e. PICO_DEFAULT_LED_PIN or CYW43_WL_GPIO_LED_PIN) but no RGB LED : status_led on/off turns the regular LED on/off
  • board has an RGB LED (i.e. PICO_DEFAULT_WS2812_PIN) but no regular LED : status_led on/off turns the RGB led on/off, with optional control of the "on" colour (defaults to "white")
  • board has both a regular LED and an RGB LED (i.e. PICO_DEFAULT_LED_PIN and PICO_DEFAULT_WS2812_PIN) : status_led on/off turns the regular LED on/off, with the RGB LED then left free for any other purposes
  • board has both a regular LED and an RGB LED and the user sets the PICO_STATUS_LED_USE_WS2812_PIN define (or equivalent) : status_led on/off turns the RGB led on/off, with the regular LED then left free for any other purpose
  • board has lots of regular LEDs and lots of RGB LEDs : user is free to set whatever PICO_CONFIG defines they want, in order to customise which LED the status_led on/off functions will control

That way any example-code that's using the status_led on/off functions will "just work" on any type of board? 🤷

@peterharperuk
Copy link
Contributor Author

Let's keep it simple. If @kilograham disagrees we can change it

@peterharperuk peterharperuk force-pushed the status_led branch 2 times, most recently from 074d424 to fcada13 Compare June 5, 2025 14:19
The cyw43-driver enables LwIP if CYW43_LWIP is not defined.
Allow LwIP to be disabled by default if CYW43_LWIP is not defined so we
can use the driver to access the led without needing to link to LwIP.

Add CYW43_LWIP_DEFAULT to enable this.
@kilograham
Copy link
Contributor

kilograham commented Jun 5, 2025

But most boards are configured with both. Who's to say that you shouldn't be able to control both individually?

I'm not saying that you shouldn't be able to control both LEDs individually, I guess I was just kinda expecting a status_led library to control only one of them, with the other LED then free for user-purposes. 💡

So, entirely IMVHO:

* board has a regular LED (i.e. `PICO_DEFAULT_LED_PIN` or `CYW43_WL_GPIO_LED_PIN`) but no RGB LED : `status_led` on/off turns the regular LED on/off

* board has an RGB LED (i.e. `PICO_DEFAULT_WS2812_PIN`) but no regular LED : `status_led` on/off turns the RGB led on/off, with optional control of the "on" colour (defaults to "white")

* board has both a regular LED and an RGB LED (i.e. `PICO_DEFAULT_LED_PIN` and  `PICO_DEFAULT_WS2812_PIN`) : `status_led` on/off turns the regular LED on/off, with the RGB LED then left free for any other purposes

* board has both a regular LED and an RGB LED **and** the user sets the `PICO_STATUS_LED_USE_WS2812_PIN` define (or equivalent) : `status_led` on/off turns the RGB led on/off, with the regular LED then left free for any other purpose

* board has lots of regular LEDs and lots of RGB LEDs : user is free to set whatever `PICO_CONFIG` defines they want, in order to customise which LED the `status_led` on/off functions will control

That way any example-code that's using the status_led on/off functions will "just work" on any type of board? 🤷

This is somewhat similar to what i was expecting.

  1. The ability to blink a LED on any old board. If it has a WS812 or similar, the ability to set the color too (the API can exist but return false)
  2. Possibly in the future, some helpers, like "blink error pattern" (possibly incorporating colors for colored LEDs)
  3. The ability to target these APIs at a particular LED pin or WS2812 pin, or WIFI LED is probably nice too

Sorry, i haven't given a lot of though yet to how i would like this to look

Functions for turning a binary led on and off and setting value of a
colour status led.

Fixes raspberrypi#188
@peterharperuk peterharperuk marked this pull request as ready for review June 5, 2025 17:30
* \param True if the status led could be set, otherwise false
*/
static inline bool pico_status_led_set(bool led_on) {
#if defined PICO_DEFAULT_LED_PIN
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I tihnk this method should support WS2812 leds too - it can call into a method in that case
  2. I think there should be a PICO_STATUS_LED config to pick WS2812 over LED for status LED if both are present

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What colour would you use for on and off? Would it be onfigurable at build time? Would it be configurable at run time?

@kilograham
Copy link
Contributor

looking nice - one comment in code

@kilograham kilograham changed the title Status led add pico_status_led Jun 12, 2025
@kilograham kilograham added this to the 2.1.2 milestone Jun 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants