Add driver that based on RPI-PICO's PIO feature for ws2812.
This driver can handle WS2812 or compatible LED strips.
The single PIO node can handle up to 4 strips.
Any pins that can be configured for PIO can be used for strips.
I verified the samples/driver/led_ws2812 sample
working with WS2812(144 pcs) led strip using following patches.
- samples/drivers/led_ws2812/boards/rpi_pico.overlay
```
/ {
aliases {
led-strip = &ws2812;
};
};
&pinctrl {
ws2812_pio0_default: ws2812_pio0_default {
ws2812 {
pinmux = <PIO0_P21>;
};
};
};
&pio0 {
status = "okay";
pio-ws2812 {
compatible = "worldsemi,ws2812-rpi_pico-pio";
status = "okay";
pinctrl-0 = <&ws2812_pio0_default>;
pinctrl-names = "default";
bit-waveform = <3>, <3>, <4>;
ws2812: ws2812 {
status = "okay";
output-pin = <21>;
chain-length = <144>;
color-mapping = <LED_COLOR_ID_GREEN
LED_COLOR_ID_RED
LED_COLOR_ID_BLUE>;
reset-delay = <280>;
frequency = <800000>;
};
};
};
```
- samples/drivers/led_ws2812/boards/rpi_pico.conf
```
CONFIG_WS2812_STRIP_RPI_PICO_PIO=y
```
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
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>
the tlc5971 driver uses spi for controlling the global brightness
and individiual pixel brightness of a daisy chain of tlc5971
devices.
Signed-off-by: Mikkel Jakobsen <mikkel.aunsbjerg@escolifesciences.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
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>
Update the files which contain no license information with the
'Apache-2.0' SPDX license identifier. Many source files in the tree are
missing licensing information, which makes it harder for compliance
tools to determine the correct license.
By default all files without license information are under the default
license of Zephyr, which is Apache version 2.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This driver uses a bit-banging based technique of generating a signal
for the WS2812B LED strip. Since bit-banging is very timing sensitive,
where each CPU cycle counts, the driver uses inline assembly to
perform the most critical operataions. This initial version of the
driver only supports a Cortex-M0 implementation, and can e.g. be used
with the ZIP Halo LED strip for the BBC microbit:
https://www.kitronik.co.uk/5625-zip-halo-for-the-bbc-microbit.html
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The APA102 is a RGB LED with integrated controller. LEDs can be
daisy-chained and use SPI for communication. The SPI port is
configured via Device Tree.
Tested on the Adafruit Trinket M0.
Signed-off-by: Michael Hope <mlhx@google.com>
Introducing CMake is an important step in a larger effort to make
Zephyr easy to use for application developers working on different
platforms with different development environment needs.
Simplified, this change retains Kconfig as-is, and replaces all
Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild
offers is replaced by a set of CMake extentions. These extentions have
either provided simple one-to-one translations of KBuild features or
introduced new concepts that replace KBuild concepts.
This is a breaking change for existing test infrastructure and build
scripts that are maintained out-of-tree. But for FW itself, no porting
should be necessary.
For users that just want to continue their work with minimal
disruption the following should suffice:
Install CMake 3.8.2+
Port any out-of-tree Makefiles to CMake.
Learn the absolute minimum about the new command line interface:
$ cd samples/hello_world
$ mkdir build && cd build
$ cmake -DBOARD=nrf52_pca10040 ..
$ cd build
$ make
PR: zephyrproject-rtos#4692
docs: http://docs.zephyrproject.org/getting_started/getting_started.html
Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
