patrick/zephyr
1
0
Fork 0
Code Issues Pull requests Actions 7 Packages Projects Releases Wiki Activity
zephyr/drivers/led_strip/Kconfig.ws2812

50 lines
1.4 KiB
Plaintext
Raw Normal View History

drivers: led_strip: add WS2812-ish driver The WS2812 LED driver IC has a one-wire interface which encodes bit values as pulse widths. The ICs themselves are basically shift registers. Roughly speaking, a "short" pulse shifts in a zero bit, a "long" pulse shifts in a one bit, and an inter-pulse gap exceeding a reset time threshold causes a pixel to latch the shifted-in color values. Each chip has an output pin for daisy chaining. Refer to the chip datsheets and comments in Kconfig.ws2812 for more details. To meet timing without hogging the core, this driver generates pulses using SPI. To work, this requires the MOSI line to stay low between SPI frames, and for inter-frame delays to be less than the reset pulse time. There are other ways do it (PWM + DMA on some SoCs, GPIO bit-banging if no other tasks need the core), but this is a reasonably general-purpose implementation. Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
2017-10-17 05:28:15 +02:00
# Copyright (c) 2017 Linaro Limited
drivers: led_strip: modernize and fix up ws2812 drivers/sample Convert the GPIO based driver to the new GPIO API. (Only the gpio_configure() call is affected). Move configuration to DT where appropriate for both SPI and GPIO drivers, only leaving the SPI vs. GPIO decision in Kconfig (in addition to the basic enable for the driver.) Move some files around to clean up as a result of this change. led_ws2812 sample changes: - make the pattern easier to look at by emitting less light - use led_strip alias from DT to get strip device, allocate appropriate struct led_rgb buffer, etc. - move the pins around and remove 96b_carbon support (I have no board to test with) GPIO driver specific changes: - str is required to write OUTSET/OUTCLR, not strb. The registers are word-sized. - the str[b] registers must all be in r0-r7, so "l" is the correct GCC inline assembly constraint for both "base" and "pin" SPI driver specific changes: - match the GPIO driver in not supporting the update_channels API method, which never made sense for this type of strip - return -ENOMEM when the user tries to send more pixel data than we have buffer space for instead of -EINVAL Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2019-11-06 18:28:54 +01:00
# Copyright (c) 2019 Nordic Semiconductor ASA
#
drivers: led_strip: add WS2812-ish driver The WS2812 LED driver IC has a one-wire interface which encodes bit values as pulse widths. The ICs themselves are basically shift registers. Roughly speaking, a "short" pulse shifts in a zero bit, a "long" pulse shifts in a one bit, and an inter-pulse gap exceeding a reset time threshold causes a pixel to latch the shifted-in color values. Each chip has an output pin for daisy chaining. Refer to the chip datsheets and comments in Kconfig.ws2812 for more details. To meet timing without hogging the core, this driver generates pulses using SPI. To work, this requires the MOSI line to stay low between SPI frames, and for inter-frame delays to be less than the reset pulse time. There are other ways do it (PWM + DMA on some SoCs, GPIO bit-banging if no other tasks need the core), but this is a reasonably general-purpose implementation. Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
2017-10-17 05:28:15 +02:00
# SPDX-License-Identifier: Apache-2.0
# The following blog post is an excellent resource about pulse timing:
#
# https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/
menuconfig WS2812_STRIP
kconfig: remove Enable from boolean prompts According to Kconfig guidelines, boolean prompts must not start with "Enable...". The following command has been used to automate the changes in this patch: sed -i "s/bool \"[Ee]nables\? \(\w\)/bool \"\U\1/g" **/Kconfig* Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-03-09 12:05:12 +01:00
bool "WS2812 (and compatible) LED strip driver"
drivers: led_strip: modernize and fix up ws2812 drivers/sample Convert the GPIO based driver to the new GPIO API. (Only the gpio_configure() call is affected). Move configuration to DT where appropriate for both SPI and GPIO drivers, only leaving the SPI vs. GPIO decision in Kconfig (in addition to the basic enable for the driver.) Move some files around to clean up as a result of this change. led_ws2812 sample changes: - make the pattern easier to look at by emitting less light - use led_strip alias from DT to get strip device, allocate appropriate struct led_rgb buffer, etc. - move the pins around and remove 96b_carbon support (I have no board to test with) GPIO driver specific changes: - str is required to write OUTSET/OUTCLR, not strb. The registers are word-sized. - the str[b] registers must all be in r0-r7, so "l" is the correct GCC inline assembly constraint for both "base" and "pin" SPI driver specific changes: - match the GPIO driver in not supporting the update_channels API method, which never made sense for this type of strip - return -ENOMEM when the user tries to send more pixel data than we have buffer space for instead of -EINVAL Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2019-11-06 18:28:54 +01:00
select LED_STRIP_RGB_SCRATCH
drivers: led_strip: add WS2812-ish driver The WS2812 LED driver IC has a one-wire interface which encodes bit values as pulse widths. The ICs themselves are basically shift registers. Roughly speaking, a "short" pulse shifts in a zero bit, a "long" pulse shifts in a one bit, and an inter-pulse gap exceeding a reset time threshold causes a pixel to latch the shifted-in color values. Each chip has an output pin for daisy chaining. Refer to the chip datsheets and comments in Kconfig.ws2812 for more details. To meet timing without hogging the core, this driver generates pulses using SPI. To work, this requires the MOSI line to stay low between SPI frames, and for inter-frame delays to be less than the reset pulse time. There are other ways do it (PWM + DMA on some SoCs, GPIO bit-banging if no other tasks need the core), but this is a reasonably general-purpose implementation. Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
2017-10-17 05:28:15 +02:00
help
led_strip: ws2812: claim compatibility with Everlight B1414 This patch states that the Everlight B1414 LED controller is compatible with the Worldsemi WS2812. Some information about it is added to the WS2812 DT binding and driver Kconfig files. Signed-off-by: Simon Guinot <simon.guinot@seagate.com>
2021-05-19 12:19:38 +02:00
Enable LED strip driver for daisy chains of WS2812-ish (or WS2812B,
WS2813, SK6812, Everlight B1414, or compatible) devices.
drivers: led_strip: add WS2812-ish driver The WS2812 LED driver IC has a one-wire interface which encodes bit values as pulse widths. The ICs themselves are basically shift registers. Roughly speaking, a "short" pulse shifts in a zero bit, a "long" pulse shifts in a one bit, and an inter-pulse gap exceeding a reset time threshold causes a pixel to latch the shifted-in color values. Each chip has an output pin for daisy chaining. Refer to the chip datsheets and comments in Kconfig.ws2812 for more details. To meet timing without hogging the core, this driver generates pulses using SPI. To work, this requires the MOSI line to stay low between SPI frames, and for inter-frame delays to be less than the reset pulse time. There are other ways do it (PWM + DMA on some SoCs, GPIO bit-banging if no other tasks need the core), but this is a reasonably general-purpose implementation. Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
2017-10-17 05:28:15 +02:00
drivers: led_strip: modernize and fix up ws2812 drivers/sample Convert the GPIO based driver to the new GPIO API. (Only the gpio_configure() call is affected). Move configuration to DT where appropriate for both SPI and GPIO drivers, only leaving the SPI vs. GPIO decision in Kconfig (in addition to the basic enable for the driver.) Move some files around to clean up as a result of this change. led_ws2812 sample changes: - make the pattern easier to look at by emitting less light - use led_strip alias from DT to get strip device, allocate appropriate struct led_rgb buffer, etc. - move the pins around and remove 96b_carbon support (I have no board to test with) GPIO driver specific changes: - str is required to write OUTSET/OUTCLR, not strb. The registers are word-sized. - the str[b] registers must all be in r0-r7, so "l" is the correct GCC inline assembly constraint for both "base" and "pin" SPI driver specific changes: - match the GPIO driver in not supporting the update_channels API method, which never made sense for this type of strip - return -ENOMEM when the user tries to send more pixel data than we have buffer space for instead of -EINVAL Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2019-11-06 18:28:54 +01:00
choice WS2812_STRIP_DRIVER
kconfig: Replace some single-symbol 'if's with 'depends on' I think people might be reading differences into 'if' and 'depends on' that aren't there, like maybe 'if' being needed to "hide" a symbol, while 'depends on' just adds a dependency. There are no differences between 'if' and 'depends on'. 'if' is just a shorthand for 'depends on'. They work the same when it comes to creating implicit menus too. The way symbols get "hidden" is through their dependencies not being satisfied ('if'/'depends on' get copied up as a dependency on the prompt). Since 'if' and 'depends on' are the same, an 'if' with just a single symbol in it can be replaced with a 'depends on'. IMO, it's best to avoid 'if' there as a style choice too, because it confuses people into thinking there's deep Kconfig magic going on that requires 'if'. Going for 'depends on' can also remove some nested 'if's, which generates nicer symbol information and docs, because nested 'if's really are so simple/dumb that they just add the dependencies from both 'if's to all symbols within. Replace a bunch of single-symbol 'if's with 'depends on' to despam the Kconfig files a bit and make it clearer how things work. Also do some other minor related dependency refactoring. The replacement isn't complete. Will fix up the rest later. Splitting it a bit to make it more manageable. (Everything above is true for choices, menus, and comments as well.) Detected by tweaking the Kconfiglib parsing code. It's impossible to detect after parsing, because 'if' turns into 'depends on'. Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-08 03:45:50 +01:00
prompt "Driver backend"
default WS2812_STRIP_SPI
depends on WS2812_STRIP
drivers: led_strip: add WS2812-ish driver The WS2812 LED driver IC has a one-wire interface which encodes bit values as pulse widths. The ICs themselves are basically shift registers. Roughly speaking, a "short" pulse shifts in a zero bit, a "long" pulse shifts in a one bit, and an inter-pulse gap exceeding a reset time threshold causes a pixel to latch the shifted-in color values. Each chip has an output pin for daisy chaining. Refer to the chip datsheets and comments in Kconfig.ws2812 for more details. To meet timing without hogging the core, this driver generates pulses using SPI. To work, this requires the MOSI line to stay low between SPI frames, and for inter-frame delays to be less than the reset pulse time. There are other ways do it (PWM + DMA on some SoCs, GPIO bit-banging if no other tasks need the core), but this is a reasonably general-purpose implementation. Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
2017-10-17 05:28:15 +02:00
drivers: led_strip: modernize and fix up ws2812 drivers/sample Convert the GPIO based driver to the new GPIO API. (Only the gpio_configure() call is affected). Move configuration to DT where appropriate for both SPI and GPIO drivers, only leaving the SPI vs. GPIO decision in Kconfig (in addition to the basic enable for the driver.) Move some files around to clean up as a result of this change. led_ws2812 sample changes: - make the pattern easier to look at by emitting less light - use led_strip alias from DT to get strip device, allocate appropriate struct led_rgb buffer, etc. - move the pins around and remove 96b_carbon support (I have no board to test with) GPIO driver specific changes: - str is required to write OUTSET/OUTCLR, not strb. The registers are word-sized. - the str[b] registers must all be in r0-r7, so "l" is the correct GCC inline assembly constraint for both "base" and "pin" SPI driver specific changes: - match the GPIO driver in not supporting the update_channels API method, which never made sense for this type of strip - return -ENOMEM when the user tries to send more pixel data than we have buffer space for instead of -EINVAL Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2019-11-06 18:28:54 +01:00
config WS2812_STRIP_SPI
kconfig: tweak Kconfig prompts Tweak some Kconfig prompts after the removal of "Enable...". Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-03-09 12:31:16 +01:00
bool "SPI driver"
drivers: led_strip: modernize and fix up ws2812 drivers/sample Convert the GPIO based driver to the new GPIO API. (Only the gpio_configure() call is affected). Move configuration to DT where appropriate for both SPI and GPIO drivers, only leaving the SPI vs. GPIO decision in Kconfig (in addition to the basic enable for the driver.) Move some files around to clean up as a result of this change. led_ws2812 sample changes: - make the pattern easier to look at by emitting less light - use led_strip alias from DT to get strip device, allocate appropriate struct led_rgb buffer, etc. - move the pins around and remove 96b_carbon support (I have no board to test with) GPIO driver specific changes: - str is required to write OUTSET/OUTCLR, not strb. The registers are word-sized. - the str[b] registers must all be in r0-r7, so "l" is the correct GCC inline assembly constraint for both "base" and "pin" SPI driver specific changes: - match the GPIO driver in not supporting the update_channels API method, which never made sense for this type of strip - return -ENOMEM when the user tries to send more pixel data than we have buffer space for instead of -EINVAL Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2019-11-06 18:28:54 +01:00
depends on SPI
drivers: led_strip: add WS2812-ish driver The WS2812 LED driver IC has a one-wire interface which encodes bit values as pulse widths. The ICs themselves are basically shift registers. Roughly speaking, a "short" pulse shifts in a zero bit, a "long" pulse shifts in a one bit, and an inter-pulse gap exceeding a reset time threshold causes a pixel to latch the shifted-in color values. Each chip has an output pin for daisy chaining. Refer to the chip datsheets and comments in Kconfig.ws2812 for more details. To meet timing without hogging the core, this driver generates pulses using SPI. To work, this requires the MOSI line to stay low between SPI frames, and for inter-frame delays to be less than the reset pulse time. There are other ways do it (PWM + DMA on some SoCs, GPIO bit-banging if no other tasks need the core), but this is a reasonably general-purpose implementation. Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
2017-10-17 05:28:15 +02:00
help
drivers: led_strip: modernize and fix up ws2812 drivers/sample Convert the GPIO based driver to the new GPIO API. (Only the gpio_configure() call is affected). Move configuration to DT where appropriate for both SPI and GPIO drivers, only leaving the SPI vs. GPIO decision in Kconfig (in addition to the basic enable for the driver.) Move some files around to clean up as a result of this change. led_ws2812 sample changes: - make the pattern easier to look at by emitting less light - use led_strip alias from DT to get strip device, allocate appropriate struct led_rgb buffer, etc. - move the pins around and remove 96b_carbon support (I have no board to test with) GPIO driver specific changes: - str is required to write OUTSET/OUTCLR, not strb. The registers are word-sized. - the str[b] registers must all be in r0-r7, so "l" is the correct GCC inline assembly constraint for both "base" and "pin" SPI driver specific changes: - match the GPIO driver in not supporting the update_channels API method, which never made sense for this type of strip - return -ENOMEM when the user tries to send more pixel data than we have buffer space for instead of -EINVAL Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2019-11-06 18:28:54 +01:00
The SPI driver is portable, but requires significantly more
memory (1 byte of overhead per bit of pixel data).
drivers: led_strip: add WS2812-ish driver The WS2812 LED driver IC has a one-wire interface which encodes bit values as pulse widths. The ICs themselves are basically shift registers. Roughly speaking, a "short" pulse shifts in a zero bit, a "long" pulse shifts in a one bit, and an inter-pulse gap exceeding a reset time threshold causes a pixel to latch the shifted-in color values. Each chip has an output pin for daisy chaining. Refer to the chip datsheets and comments in Kconfig.ws2812 for more details. To meet timing without hogging the core, this driver generates pulses using SPI. To work, this requires the MOSI line to stay low between SPI frames, and for inter-frame delays to be less than the reset pulse time. There are other ways do it (PWM + DMA on some SoCs, GPIO bit-banging if no other tasks need the core), but this is a reasonably general-purpose implementation. Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
2017-10-17 05:28:15 +02:00
drivers: led_strip: add WS2812 I2S-based driver Add a driver implementation that uses the I2S peripheral. Based off this blog post: https://electronut.in/nrf52-i2s-ws2812/ Should help with #33505, #29877 and maybe #47780, as there is no garbage data at the end of transmissions on nRF52832, and no gaps. Signed-off-by: Jonathan Rico <jonathan@rico.live>
2022-11-07 21:42:43 +01:00
config WS2812_STRIP_I2S
bool "I2S driver"
depends on I2S
help
Uses the I2S peripheral, memory usage is 4 bytes per color,
times the number of pixels. A few more for the start and end
delay. The reset delay has a coarse resolution of ~20us.
drivers: led_strip: modernize and fix up ws2812 drivers/sample Convert the GPIO based driver to the new GPIO API. (Only the gpio_configure() call is affected). Move configuration to DT where appropriate for both SPI and GPIO drivers, only leaving the SPI vs. GPIO decision in Kconfig (in addition to the basic enable for the driver.) Move some files around to clean up as a result of this change. led_ws2812 sample changes: - make the pattern easier to look at by emitting less light - use led_strip alias from DT to get strip device, allocate appropriate struct led_rgb buffer, etc. - move the pins around and remove 96b_carbon support (I have no board to test with) GPIO driver specific changes: - str is required to write OUTSET/OUTCLR, not strb. The registers are word-sized. - the str[b] registers must all be in r0-r7, so "l" is the correct GCC inline assembly constraint for both "base" and "pin" SPI driver specific changes: - match the GPIO driver in not supporting the update_channels API method, which never made sense for this type of strip - return -ENOMEM when the user tries to send more pixel data than we have buffer space for instead of -EINVAL Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2019-11-06 18:28:54 +01:00
config WS2812_STRIP_GPIO
kconfig: tweak Kconfig prompts Tweak some Kconfig prompts after the removal of "Enable...". Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-03-09 12:31:16 +01:00
bool "GPIO driver"
drivers: led_strip: modernize and fix up ws2812 drivers/sample Convert the GPIO based driver to the new GPIO API. (Only the gpio_configure() call is affected). Move configuration to DT where appropriate for both SPI and GPIO drivers, only leaving the SPI vs. GPIO decision in Kconfig (in addition to the basic enable for the driver.) Move some files around to clean up as a result of this change. led_ws2812 sample changes: - make the pattern easier to look at by emitting less light - use led_strip alias from DT to get strip device, allocate appropriate struct led_rgb buffer, etc. - move the pins around and remove 96b_carbon support (I have no board to test with) GPIO driver specific changes: - str is required to write OUTSET/OUTCLR, not strb. The registers are word-sized. - the str[b] registers must all be in r0-r7, so "l" is the correct GCC inline assembly constraint for both "base" and "pin" SPI driver specific changes: - match the GPIO driver in not supporting the update_channels API method, which never made sense for this type of strip - return -ENOMEM when the user tries to send more pixel data than we have buffer space for instead of -EINVAL Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2019-11-06 18:28:54 +01:00
# Only an Cortex-M0 inline assembly implementation for the nRF51
# is supported currently.
depends on SOC_SERIES_NRF51X
drivers: led_strip: add WS2812-ish driver The WS2812 LED driver IC has a one-wire interface which encodes bit values as pulse widths. The ICs themselves are basically shift registers. Roughly speaking, a "short" pulse shifts in a zero bit, a "long" pulse shifts in a one bit, and an inter-pulse gap exceeding a reset time threshold causes a pixel to latch the shifted-in color values. Each chip has an output pin for daisy chaining. Refer to the chip datsheets and comments in Kconfig.ws2812 for more details. To meet timing without hogging the core, this driver generates pulses using SPI. To work, this requires the MOSI line to stay low between SPI frames, and for inter-frame delays to be less than the reset pulse time. There are other ways do it (PWM + DMA on some SoCs, GPIO bit-banging if no other tasks need the core), but this is a reasonably general-purpose implementation. Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
2017-10-17 05:28:15 +02:00
help
drivers: led_strip: modernize and fix up ws2812 drivers/sample Convert the GPIO based driver to the new GPIO API. (Only the gpio_configure() call is affected). Move configuration to DT where appropriate for both SPI and GPIO drivers, only leaving the SPI vs. GPIO decision in Kconfig (in addition to the basic enable for the driver.) Move some files around to clean up as a result of this change. led_ws2812 sample changes: - make the pattern easier to look at by emitting less light - use led_strip alias from DT to get strip device, allocate appropriate struct led_rgb buffer, etc. - move the pins around and remove 96b_carbon support (I have no board to test with) GPIO driver specific changes: - str is required to write OUTSET/OUTCLR, not strb. The registers are word-sized. - the str[b] registers must all be in r0-r7, so "l" is the correct GCC inline assembly constraint for both "base" and "pin" SPI driver specific changes: - match the GPIO driver in not supporting the update_channels API method, which never made sense for this type of strip - return -ENOMEM when the user tries to send more pixel data than we have buffer space for instead of -EINVAL Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2019-11-06 18:28:54 +01:00
The GPIO driver does bit-banging with inline assembly,
and is not available on all SoCs.
drivers: led_strip: add WS2812-ish driver The WS2812 LED driver IC has a one-wire interface which encodes bit values as pulse widths. The ICs themselves are basically shift registers. Roughly speaking, a "short" pulse shifts in a zero bit, a "long" pulse shifts in a one bit, and an inter-pulse gap exceeding a reset time threshold causes a pixel to latch the shifted-in color values. Each chip has an output pin for daisy chaining. Refer to the chip datsheets and comments in Kconfig.ws2812 for more details. To meet timing without hogging the core, this driver generates pulses using SPI. To work, this requires the MOSI line to stay low between SPI frames, and for inter-frame delays to be less than the reset pulse time. There are other ways do it (PWM + DMA on some SoCs, GPIO bit-banging if no other tasks need the core), but this is a reasonably general-purpose implementation. Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
2017-10-17 05:28:15 +02:00
led_strip: ws2812: claim compatibility with Everlight B1414 This patch states that the Everlight B1414 LED controller is compatible with the Worldsemi WS2812. Some information about it is added to the WS2812 DT binding and driver Kconfig files. Signed-off-by: Simon Guinot <simon.guinot@seagate.com>
2021-05-19 12:19:38 +02:00
Note that this driver is not compatible with the Everlight B1414
controller.
drivers: led_strip: modernize and fix up ws2812 drivers/sample Convert the GPIO based driver to the new GPIO API. (Only the gpio_configure() call is affected). Move configuration to DT where appropriate for both SPI and GPIO drivers, only leaving the SPI vs. GPIO decision in Kconfig (in addition to the basic enable for the driver.) Move some files around to clean up as a result of this change. led_ws2812 sample changes: - make the pattern easier to look at by emitting less light - use led_strip alias from DT to get strip device, allocate appropriate struct led_rgb buffer, etc. - move the pins around and remove 96b_carbon support (I have no board to test with) GPIO driver specific changes: - str is required to write OUTSET/OUTCLR, not strb. The registers are word-sized. - the str[b] registers must all be in r0-r7, so "l" is the correct GCC inline assembly constraint for both "base" and "pin" SPI driver specific changes: - match the GPIO driver in not supporting the update_channels API method, which never made sense for this type of strip - return -ENOMEM when the user tries to send more pixel data than we have buffer space for instead of -EINVAL Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2019-11-06 18:28:54 +01:00
endchoice
Reference in a new issue Copy permalink