In order to bring consistency in-tree, migrate all samples to the use
the new prefix <zephyr/...>. Note that the conversion has been scripted:
```python
from pathlib import Path
import re
EXTENSIONS = ("c", "h", "cpp", "rst")
for p in Path(".").glob("samples/**/*"):
if not p.is_file() or p.suffix and p.suffix[1:] not in EXTENSIONS:
continue
content = ""
with open(p) as f:
for line in f:
m = re.match(r"^(.*)#include <(.*)>(.*)$", line)
if (m and
not m.group(2).startswith("zephyr/") and
(Path(".") / "include" / "zephyr" / m.group(2)).exists()):
content += (
m.group(1) +
"#include <zephyr/" + m.group(2) +">" +
m.group(3) + "\n"
)
else:
content += line
with open(p, "w") as f:
f.write(content)
```
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
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>
The sample did not use PWM in a proper way: it relied on a PWM device
handle, but channel or flags were hardcoded in the code. This patch
changes the sample to use a local binding ("pwm-servo") where the `pwms`
property is defined. This allows to make use of pwm_dt_spec facilities,
reducing the overall sample complexity and making it more portable
without editing the source code. The custom binding also requires to
provide the minimum/maximum pulse width so that different servos can be
easily plugged in without the need to edit sources.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
- add `channel-gpios` property with GPIO assignment for the used PWM
channel to the `sw_pwm` node
- replace ambiguous "pin 21" in the sample's README with "pin P19"
that uses notation from the official micro:bit documentation and
is consistent with this pin number within the edge_connector node
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
At some recent point, directory <zephyr-root>/include was moved to
<zephyr-root>/include/zephyr. However, links from documentation to
Zephyr source on Github were not updated. Update them now.
Signed-off-by: Aleksandar Markovic <aleksandar.markovic.sa@gmail.com>
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>
Using a gpio_dt_spec is the current best practice for getting at pins
defined in the DT, because it gets all the boilerplate and flags right
for you. Use that in blinky, keeping the documentation in sync with
the code.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
- 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>
Convert pin setting and getting to `struct gpio_dt_spec` variants to
demonstrate usage of the new API.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Use a gpio_dt_spec, dropping device_get_binding. This in turn lets us
write everything in a single main() without sacrificing readability
since the LED is optional.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
