Skip to content
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

Add support for NRF52 to the WS281x driver #19859

Closed
jimporter opened this issue Aug 5, 2023 · 3 comments · Fixed by #19891
Closed

Add support for NRF52 to the WS281x driver #19859

jimporter opened this issue Aug 5, 2023 · 3 comments · Fixed by #19891

Comments

@jimporter
Copy link
Contributor

Description

There are currently only a couple of CPUs/architectures that support WS281x LEDs. It should be possible to add support for the NRF52, since some NRF52-based Adafruit devboards (e.g. the Feather) have a WS281x on-board, and the Arduino libs mention support for NRF52 as well.

I'm happy to work on this (and will probably tinker with it regardless of the response here), but before I go too far on this, I though it would be wise to file an issue for discussion and to hopefully steer me in the right direction.

Useful links

https://learn.adafruit.com/introducing-the-adafruit-nrf52840-feather/ (specs include a NeoPixel/WS2812 on the board)

@chrysn
Copy link
Member

chrysn commented Aug 16, 2023

I've attempted to write a generic one based on timer and gpio_ll peripherals, and while my LEDs are blinking colorfully, I'm not convinced yet it's as stable as I'd hope it' be (especially because I had to take a few shortcuts such as hardcoding what could be a busy-loop-until-compare-is-triggered function in the timer API).

If we do need to go the per-chip route for nRF52 and similar, let's aim for something that doesn't block the CPU (similar to the ESP32 implementation that uses hardware). What would be a good peripheral to implement this on? The UARTE is too slow (maximum baud rate 1MBaud, we need 3 at least). PWM may be an option. The FastLED project uses SPI on the nRF52 (among other options); that we might manage in a platform independent way as well (provided we can get the actual clock rate back, which AIU is being worked on in #18374).

CC'ing @maribu who has also worked on this.

@jimporter
Copy link
Contributor Author

@chrysn Yeah, a generic implementation would be ideal, assuming it's possible. SPI sounds reasonable enough to me, though I'm definitely not an expert in this area.

I see there's also #19158 for RPI Pico support which I could look at eventually too. That issue might actually have a clearer path forward since it sounds like PIO would be the ideal way to handle this.

@chrysn
Copy link
Member

chrysn commented Aug 17, 2023

Would you mind giving #19891 a try? It's not nRF specific, but was developed on it.

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 a pull request may close this issue.

2 participants