zephyr

History

Gerard Marull-Paretas 79e6b0e0f6 includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h> As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>. This patch proposes to then include <zephyr/kernel.h> instead of <zephyr/zephyr.h> since it is more clear that you are including the Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a catch-all header that may be confusing. Most applications need to include a bunch of other things to compile, e.g. driver headers or subsystem headers like BT, logging, etc. The idea of a catch-all header in Zephyr is probably not feasible anyway. Reason is that Zephyr is not a library, like it could be for example `libpython`. Zephyr provides many utilities nowadays: a kernel, drivers, subsystems, etc and things will likely grow. A catch-all header would be massive, difficult to keep up-to-date. It is also likely that an application will only build a small subset. Note that subsystem-level headers may use a catch-all approach to make things easier, though. NOTE: This patch is NOT removing the header, just removing its usage in-tree. I'd advocate for its deprecation (add a #warning on it), but I understand many people will have concerns. Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>		2022-09-05 16:31:47 +02:00
..
src	includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h>	2022-09-05 16:31:47 +02:00
CMakeLists.txt	cmake: increase minimal required version to 3.20.0	2021-08-20 09:47:34 +02:00
README.rst	samples: basic: rgb_led: use pwm_dt_spec	2022-04-28 11:29:38 +02:00
prj.conf	…
sample.yaml	…

README.rst

.. _rgb-led-sample:

PWM: RGB LED
############

Overview
********

This is a sample app which drives an RGB LED using PWM.

There are three single-color component LEDs in an RGB LED. Each component LED
is driven by a PWM port where the pulse width is changed from zero to the period
indicated in Devicetree. Such period should be fast enough to be above the
flicker fusion threshold (the minimum flicker rate where the LED is perceived as
being steady). The sample causes each LED component to step from dark to max
brightness. Three **for** loops (one for each component LED) generate a gradual
range of color changes from the RGB LED, and the sample repeats forever.

Requirements
************

The board must have red, green, and blue LEDs connected via PWM output channels.

The LED PWM channels must be configured using the following :ref:`devicetree
<dt-guide>` aliases, usually in the :ref:`BOARD.dts file
<devicetree-in-out-files>`:

- ``red-pwm-led``
- ``green-pwm-led``
- ``blue-pwm-led``

You will see at least one of these errors if you try to build this sample for
an unsupported board:

.. code-block:: none

   Unsupported board: red-pwm-led devicetree alias is not defined
   Unsupported board: green-pwm-led devicetree alias is not defined
   Unsupported board: blue-pwm-led devicetree alias is not defined

See :zephyr_file:`boards/arm/hexiwear_k64/hexiwear_k64.dts` for an example
:file:`BOARD.dts` file which supports this sample.

Wiring
******

No additional wiring is necessary if the required devicetree aliases refer to
hardware that is already connected to LEDs on the board.

Otherwise, LEDs should be connected to the appropriate PWM channels.

Building and Running
********************

For example, to build and flash this board for :ref:`hexiwear_k64`:

.. zephyr-app-commands::
   :zephyr-app: samples/basic/rgb_led
   :board: hexiwear_k64
   :goals: build flash
   :compact:

Change ``hexiwear_k64`` appropriately for other supported boards.