In order to be consistent with what is possible in Devicetree, always
take a period in nanoseconds. Other scales or units may be specified by
using, e.g., the PWM_MSEC() macros (all of them converting down to
nanoseconds). This change then deletes the "_nsec" and "_usec" versions
of the pwm_set call.
Note that this change limits the period to UINT32_MAX nanoseconds,
~4.3s. PWM is, in generali, used with periods below the second so it
should not be a problem.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Samples should run on a board if they have the peripheral connected, in
this case, if any LED on the board is connected to a PWM output. A
shield could be used to demonstrate a sample on a board that doesn't
have the required peripheral. In this case, it was also unclear where
that "external LED" had to be connected, unless one checks where channel
1 for PWM1 is routed to. All board LEDs are connected to pins that
cannot be driven by PWM.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The board had PWM LEDs defined in the blinky_pwm sample, mainly because
it conflicts with SPI1 pinmux. A better approach is to still define the
PWM LEDs in the board but keep the PWM controller disabled by default.
Then, samples just need to enable the PWM controller (and disable SPI if
used simultaneously).
Also updated period to 20ms (reasonable value for a PWM-driven LED).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The board had PWM LEDs defined in the blinky_pwm sample, mainly because
it conflicts with SPI1 pinmux. A better approach is to still define the
PWM LEDs in the board but keep the PWM controller disabled by default.
Then, samples just need to enable the PWM controller (and disable SPI if
used simultaneously).
Also updated period to 20ms (reasonable value for a PWM-driven LED).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The board had PWM LEDs defined in the blinky_pwm sample, mainly because
it conflicts with SPI1 pinmux. A better approach is to still define the
PWM LEDs in the board but keep the PWM controller disabled by default.
Then, samples just need to enable the PWM controller (and disable SPI if
used simultaneously).
Also updated period to 20ms (reasonable value for a PWM-driven LED).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
While the pwm-led0 alias may exist, it could happen that the node with
pwm-leds compatible is disabled, making the sample fail compilation.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Adding an overlay to configure the nucleo_l4r5zi for testing the pwm
blinky application on red led (PB14 on nucleo board)
Each has a specific pwm output from different timers/channels
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The overlay are defined to run the samples application with PWM
feature on the nucleo_l073rz,nucleo_f091rc, nucleo_g474re
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Blinky PWM sample minimum pwm period was too high for iMX.RT PWM module.
decrease the minimum pwm period so sample will pass pwm calibration
phase.
Fixes#38954
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
- adds overlayed board info to support PWM LED
- adds support for blinky_pwm sample code.
Signed-off-by: Glauber Maroto Ferreira <glauber.ferreira@espressif.com>
Create a board overlay file in the application directory to add
pwm-led0 entry over default device tree. Also, include instruction
in the README file that connection of external LED at pin PA8 is
required for the demo to work.
Signed-off-by: Waqas Mazhar <waqas.mazhar@planetinnovation.com.au>
Move to CMake 3.20.0.
At the Toolchain WG it was decided to move to CMake 3.20.0.
The main reason for increasing CMake version is better toolchain
support.
Better toolchain support is added in the following CMake versions:
- armclang, CMake 3.15
- Intel oneAPI, CMake 3.20
- IAR, CMake 3.15 and 3.20
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The README gives as example the command to build
the sample with west. The path of the sample as
stated does not exist. This fixes it to blinky_pwm.
Signed-off-by: Jennifer Williams <jennifer.m.williams@intel.com>
Clean up logging menuconfig by grouping configuration into
sections like: mode, processing configuration, backends.
Additionlly, removed LOG_ENABLE_FANCY_OUTPUT_FORMATTING which is no
longer in use.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Now that the relevant APIs generalize properly for bindings without
flags, we can remove some special case checks from the tree.
I couldn't find any more, but I did this kind of quickly, so it's
possible I missed some.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This provides a better error message when building with CMake and
forgetting ZEPHYR_BASE or not registering Zephyr in the CMake package
registry. See parent commit for more details (split from parent for
better readability).
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The difference between "blinky" and "blink_led" is not clear.
This rename makes it more obvious that "blinky_pwm", well,
blinks an LED using PWM.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
