drivers/ws281x: Add GPIO ABC backend #12020
Conversation
7d0caa5 to
79a75ee
Compare
|
I have an LED strip with this chip at home somewhere. I put this on my TODO list to test at some point (but only in case I can find it ^^) |
|
Hm FastLED manages to drive those strips using DMA - I used the version for the esp8266 and it worked pretty well. |
|
@benpicco: Are you sure? FastLED also supports SPI based RGB controllers, maybe it was one of them? The NeoPixels have a custom single wire protocol, so there is no hardware acceleration for that. I think however that I read how someone used the I2S hardware of the ESP with DMA for same magic bitbanging stuff. But that would be a driver specific for the ESPs, while software bitbanging can be used on more devices. But I see no reason to not provide I2S bases driver in addition, if someone want to give it a try. |
|
@maribu yes you are right. The esp8266 support uses i2s whereas the ARM ports of FastLED also resort to bitbanging. |
|
Btw: Once this is merged I plan to also add AVR support. (I really hate it when people say "This works on Arduino, why not on RIOT?"). Sadly, GPIO ABC cannot be used on AVR for performance reasons, so I will have to add a custom |
An application/test/module that requires one feature out of a set of
alternatives (let's say either periph_uart, periph_spi, or periph_i2c) can
request this now using:
FEATURES_REQUIRED_ONE_OUT_OF += periph_uart|periph_spi|periph_i2c
The submodule periph_gpio_abc extends the GPIO driver by Advanced Bitbanging Capabilities (ABC). It provides means to control GPIOs with a precision of 0.15µs or better.
Added a backend for the ws281x using the GPIO Advanced Bitbanging Capabilities (ABC) API.
|
For the reviews that were now pulled in as code owners: Only the last commit actually belongs to this PR, the rest are dependencies that need to be merged prior. Most (all?) code owners were pulled in due to the dependencies rather than the actual (rather minor) contribution. So feel free to unsubscribe to not get SPAM when I occasionally rebase this PR to solve merge conflicts. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
|
#12015 (comment) applies: Tested w/ nrf52, please rebase on a rebased #12015 |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
|
The way I understand things is that while the driver would look a bit different, it'd still be a good addition after #14602 or #16787 is in. (When that time comes it may be easier to replace it with a fresh PR from that API, but until then I'd suggest keeping this here open as it does represent the plan to do ws281x style LEDs on some bitbangable GPIO API). |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
Contribution description
The WS2812/SK6812 RGB LEDs (more famously known as NeoPixels) have an integrated RGB controller and can be controlled with a single GPIO using a custom one wire protocol. A nice feature of these LEDs is that they can be chained ad inifinitum by connecting the data in pin of one LED to the date out pin of its predecessor. Each LED will use the first three bytes received to set its color and will pass on all remaining bits to its successors.
As custom one wire protocol has tight timing requirements, which cannot be met with the GPIO and the xtimer interface. For that reason, it uses the newly propose GPIO ABC (Advanced Bitbanging Capabilities) API proposed in #12015.
Testing procedure
Hook up some NeoPixels to an STM32F1 based board (e.g. the blue pill) and flash and run the provided test application. You'll know when the driver is working ;-) (You can also use a SAM3 or an STM32F3 board, but you will have to pull in the GPIO ABC implementations for the corresponding PRs.)
Some pitfalls: The supply voltage has to be in the range of 4V to 7V and the power supply needs to be able to source some decent current. The logic level has to be at least 0.7 times the supply voltage, so using 5V for power supply and 3.3V for logic is out of spec. (But this seems to still work reliable when the power supply pretty beefy and stable and the cables are high quality. So just give it a try and have a logic level shifter ready if you experience any issues.)
Issues/PRs references