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>
Since Pygments 2.7.0 devicetree syntax is supported, so there is no need
to use a custom lexer. Version 2.9.0 introduces a fix that is required
for some devicetree snippets.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Originally added in 7733b94224.
This filter is not well-formed. It's meant to match nodes like
/leds/led_0 in this DTS:
/ {
aliases {
led0 = &led0;
};
leds {
compatible = "gpio-leds";
led0: led_0 {
gpios = <...>;
label = "LED 0";
};
};
};
Uses look like this:
filter: dt_compat_enabled_with_alias("gpio-leds", "led0")
But notice how the led_0 node doesn't have compatible "gpio-leds";
it's actually the *parent* node that has that compatible.
Replace this with a new filter, dt_enabled_alias_with_parent_compat(),
which is used like this:
filter: dt_enabled_alias_with_parent_compat("led0", "gpio-leds")
This has a name and argument order that makes the meaning of the
filter clearer.
Replace in-tree users with the new filter.
Deprecate the old filter and warn about its use using the standard
logging module.
Signed-off-by: Martí Bolívar <marti.bolivar@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>
- Remove SYS_ prefix
- shorten POWER_MANAGEMENT to just PM
- DEVICE_POWER_MANAGEMENT -> PM_DEVICE
and use PM_ as the prefix for all PM related Kconfigs
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This adds the option to disable kernel memory pool when
multithreading is also not enabled. This saves some
code space.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
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>
Though there were issues with this sample before e959386bd2 ("samples:
servo_motor: cleanups and changes"), that commit introduced further
bugs. This happened because the new pwm-servo alias that commit
switched to wasn't provided by any boards, so it wasn't built in CI.
Before that, however, the recommendation to use bbc_microbit in the
sample documentation was also buggy in a couple of ways:
1. bbc_microbit doesn't have the pwm-0 alias the sample
previously required, so it didn't build on that board
2. the documentation's comment to use pin 0 on the edge connector
is wrong; PWM channel 0 is wired to GPIO P0.0 on the SoC,
which is actually pin 21 on the connector
Fix it all up.
Tested on bbc_microbit. I verified the pinout and also made sure that
the sample correctly generates pulses from 700 to 2300 usec.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Align the docs and source code with other changes done to the basic
samples.
Use numbers 0 and 1 to refer to the LEDs consistently. This matches
the generic devicetree aliases used by Zephyr, instead of using USR1
and USR2, which are specific to 96b_carbon.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Align the sample with changes made to other basic samples.
Move away from 'pwm-0' as a devicetree alias, requiring applications
to define a 'pwm-servo' alias. We are getting rid of the aliases that
just bounce through to node labels as soon as we can, might as well
get the applications ready now.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Align the sample and its documentation with the other basic samples.
Adjust the fade algorithm so that it looks better and takes less time
to verify by taking 2.5 seconds instead of 10.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
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>
Align this sample's source code and documentation with other basic
samples.
Adjust the logging configuration and output some additional printk()s
at startup to make it more obvious that initial errors are device
specific and related to calibration.
Fix the period calculation logic so the sample does not stick at the
maximum and minimum periods for two consecutive four-second periods.
That is, instead of setting the pin period to MIN_PERIOD_USEC twice in
a row, do it only once before doubling again, and similarly for
max_period.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Clean up the code and fix the documentation, which is out of date and
still refers to information from the days of board.h.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Several reviewers agreed that DT_HAS_NODE_STATUS_OKAY(...) was an
undesirable API for the following reasons:
- it's inconsistent with the rest of the DT_NODE_HAS_FOO names
- DT_NODE_HAS_FOO_BAR_BAZ(node) was agreed upon as a shorthand
for macros which are equivalent to
DT_NODE_HAS_FOO(node) && DT_NODE_HAS_BAR(node) &&
- DT_NODE_HAS_BAZ(node), and DT_HAS_NODE_STATUS_OKAY is an odd duck
- DT_NODE_HAS_STATUS(..., okay) was viewed as more readable anyway
- it is seen as a somewhat aesthetically challenged name
Replace all users with DT_NODE_HAS_STATUS(..., okay), which is
semantically equivalent.
This is mostly done with sed, but a few remaining cases were done by
hand, along with whitespace, docs, and comment changes. These special
cases include the Nordic SOC static assert files.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The devicetree link is rendering as "Devicetree Guide" instead of
"devicetree". Fix that.
My guess is that most users won't care about the details of the
requirements, and rather just want to know if their board is supported
or not. So move the error you'll see on unsupported boards before the
details about how to add support (which involve a pretty significant
learning curve).
Also mention overlays as a way to get this working.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Rename DT_HAS_NODE to DT_HAS_NODE_STATUS_OKAY so the semantics are
clear. As going forward DT_HAS_NODE will report if a NODE exists
regardless of its status.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Rather than redefining a macro which might be generated we should create
a new define name that should get used in the code. Replace redefining
DT_ALIAS_LED0_GPIOS_FLAGS with LED0_FLAGS and DT_ALIAS_LED1_GPIOS_FLAGS
with LED1_FLAGS.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Rather than redefining a macro which might be generated we should create
a new define name that should get used in the code. Replace redefining
DT_ALIAS_SW0_GPIOS_FLAGS with SW0_FLAGS and DT_ALIAS_LED0_GPIOS_FLAGS
with LED0_FLAGS.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
This commit renames the Kconfig `FLOAT` symbol to `FPU`, since this
symbol only indicates that the hardware Floating Point Unit (FPU) is
used and does not imply and/or indicate the general availability of
toolchain-level floating point support (i.e. this symbol is not
selected when building for an FPU-less platform that supports floating
point operations through the toolchain-provided software floating point
library).
Moreover, given that the symbol that indicates the availability of FPU
is named `CPU_HAS_FPU`, it only makes sense to use "FPU" in the name of
the symbol that enables the FPU.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Enables PWM support using the built-in red LED. Tested with:
- samples/basic/blink_led
- samples/basic/fade_led
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Run the int_literal_to_timeout Coccinelle script to fix places where
it is clear that an integer duration is being passed where a timeout
value is required.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Kernel timeouts have always been a 32 bit integer despite the
existence of generation macros, and existing code has been
inconsistent about using them. Upcoming commits are going to make the
timeout arguments opaque, so fix things up to be rigorously correct.
Changes include:
+ Adding a K_TIMEOUT_EQ() macro for code that needs to compare timeout
values for equality (e.g. with K_FOREVER or K_NO_WAIT).
+ Adding a k_msleep() synonym for k_sleep() which can continue to take
integral arguments as k_sleep() moves away to timeout arguments.
+ Pervasively using the K_MSEC(), K_SECONDS(), et. al. macros to
generate timeout arguments.
+ Removing the usage of K_NO_WAIT as the final argument to
K_THREAD_DEFINE(). This is just a count of milliseconds and we need
to use a zero.
This patch include no logic changes and should not affect generated
code at all.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
