Commit 16d8ce519c introduced changes
that caused this sample to no longer behave according to documentation
and for some hardware to no longer work at all.
On nRF51 SoCs for instance, the reported number of cycles per second
is 16M, what makes the calculated max_period and min_period to be 16
and 0 microseconds, respectively, what effectively makes it impossible
for the sample to return to the initial blinking frequency. Moreover,
with such short PWM periods, the blinking is not even noticeable.
This patch partially reverts the changes mentioned above, and instead
of calculating max_period and min_period basing on the reported clock
rate, it tries to only decrease the max_period if needed, accordingly
to what the used hardware can handle.
Documentation is also updated to mention the possible change in
observed behavior of the sample on some hardware.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This commit removes the disco sample because it is basically
the same as blinky but with two LESs and adds no new value
to the samples.
Signed-off-by: Alexander Wachter <alexander.wachter@student.tugraz.at>
convert sample and test yaml filters that utilize a DT_ define to
instead use a dt_ function. The intent is to remove the Kconfig
generated DT defines and just make directy queries into the device tree.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
DTSpec writes this as a single word, presumably to make it easier to
grep for / more precise. Follow along in the rest of the docs now that
our main DT docs page agrees with this usage.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Instead of having a mix of west and CMake/ninja instructions for
building and flashing, document it using only west. This will help
clarify that west is the default build tool in Zephyr and should also
reduce confusion over what tool to use.
Note that the biggest change is changing the default in
doc/extensions/zephyr/application.py for :tool:, from all to west.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The maximum period a PWM controller can generate depends on its input
clock and its resolution (16-bit, 32-bit...). Setting a 1s max period
generates error with some hardwares (mimxrt1064_evk) because of clock
limitation.
This patch fixes this issue by calculating maximum period of the PWM
device to adjust max and min periods accordingly.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
k_cycle_get_32() returns an unsigned 32-bit integer, while the '%d'
specifier denotes a signed integer.
Using the proper C99 format specifier resolves the problem.
Signed-off-by: Reto Schneider <code@reto-schneider.ch>
This board and SoC was discontinued some time ago and is currently not
maintained in the zephyr tree.
Remove all associated configurations and variants from the tree.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
When tickless is available, all existing devices can handle much
higher timing precision than 10ms. A 10kHz default seems acceptable
without introducing too much range limitation (rollover for a signed
time delta will happen at 2.5 days). Leave the 100 Hz default in
place for ticked configurations, as those are going to be special
purpose usages where the user probably actually cares about interrupt
rate.
Note that the defaulting logic interacts with an obscure trick:
setting the tick rate to zero would indicate "no clock exists" to the
configuration (some platforms use this to drop code from the build).
But now that becomes a kconfig cycle, so to break it we expose
CONFIG_SYS_CLOCK_EXISTS as an app-defined tunable and not a derived
value from the tick rate. Only one test actually did this.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
We use the following commands to rename any
LED._GPIO_{CONTROLLER,PIN,FLAGS} to
DT_ALIAS_LED._GPIOS_{CONTROLLER,PIN,FLAGS}
git grep -l LED._GPIO_CONTROLLER | xargs sed -i 's/LED\(.\)_GPIO_CONTROLLER/DT_ALIAS_LED\1_GPIOS_CONTROLLER/g'
git grep -l LED._GPIO_PIN | xargs sed -i 's/LED\(.\)_GPIO_PIN/DT_ALIAS_LED\1_GPIOS_PIN/g'
git grep -l LED._GPIO_FLAGS | xargs sed -i 's/LED\(.\)_GPIO_FLAGS/DT_ALIAS_LED\1_GPIOS_FLAGS/g'
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We use the following commands to rename any
SW._GPIO_{CONTROLLER,PIN,FLAGS} to
DT_ALIAS_SW._GPIOS_{CONTROLLER,PIN,FLAGS}
git grep -l SW._GPIO_CONTROLLER | xargs sed -i 's/SW\(.\)_GPIO_CONTROLLER/DT_ALIAS_SW\1_GPIOS_CONTROLLER/g'
git grep -l SW._GPIO_PIN | xargs sed -i 's/SW\(.\)_GPIO_PIN/DT_ALIAS_SW\1_GPIOS_PIN/g'
git grep -l SW._GPIO_FLAGS | xargs sed -i 's/SW\(.\)_GPIO_FLAGS/DT_ALIAS_SW\1_GPIOS_FLAGS/g'
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We use the following commands to rename any _PWM_{CONTROLLER,CHANNEL}
to *_PWMS_{CONTROLLER,CHANNEL}
Used the following commands to make these changes:
git grep -l '[A-Z_0-9]*_PWM_CONTROLLER' | xargs sed -i 's/\([A-Z_0-9]*\)_PWM_CONTROLLER/DT_ALIAS_\1_PWMS_CONTROLLER/g'
git grep -l '[A-Z_0-9]*_PWM_CHANNEL' | xargs sed -i 's/\([A-Z_0-9]*\)_PWM_CHANNEL/DT_ALIAS_\1_PWMS_CHANNEL/g'
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
move misc/util.h to sys/util.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
move misc/printk.h to sys/printk.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
move misc/__assert.h to sys/__assert.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
move pwm.h to drivers/pwm.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
move gpio.h to drivers/gpio.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Convert DT_.*_GPIO_{CONTROLLER,PIN,FLAGS} ->
DT_.*_GPIOS_{CONTROLLER,PIN,FLAGS)
Used the following commands to make these conversions:
git grep -l DT_.*_GPIO_CONTROLLER | xargs sed -i 's/DT_\(.*\)_GPIO_CONTROLLER/DT_\1_GPIOS_CONTROLLER/g'
git grep -l DT_.*_GPIO_PIN | xargs sed -i 's/DT_\(.*\)_GPIO_PIN/DT_\1_GPIOS_PIN/g'
git grep -l DT_.*_GPIO_FLAGS | xargs sed -i 's/DT_\(.*\)_GPIO_FLAGS/DT_\1_GPIOS_FLAGS/g'
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Removed Quark D2000 SoC files and first-order related DT bindings.
A few config options have been moved from the CONFIG_* space to
the DT_* space, as they were defined in the D2000 Kconfig files
and "leaked" into the other Quark trees.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
YAML document separators are needed e.g. when doing
$ cat doc1.yaml doc2.yaml | <parser>
For the bindings, we never parse concatenated documents. Assume we don't
for any other .yaml files either.
Having document separators in e.g. base.yaml makes !include a bit
confusing, since the !included files are merged and not separate
documents (the merging is done in Python code though, so it makes no
difference for behavior).
The replacement was done with
$ git ls-files '*.yaml' | \
xargs sed -i -e '${/\s*\.\.\.\s*/d;}' -e 's/^\s*---\s*$//'
First pattern removes ... at the end of files, second pattern clears a
line with a lone --- on it.
Some redundant blank lines at the end of files were cleared with
$ git ls-files '*.yaml' | xargs sed -i '${/^\s*$/d}'
This is more about making sure people can understand why every part of a
binding is there than about removing some text.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Cleanup references to boards in some of the example and use the same
boards through the examples. Other minot cleanups and make the text more
generic and not specific to certain boards.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Hardware PWM make sense for servo control even in a sample, add HW PWM
choice for NRF52 family, which support it.
Signed-off-by: Aaron Tsui <aaron.tsui@outlook.com>
Add a minimal sample that showcases minimal ROM sizes. It can be built
in several configurations, all very restrictive when it comes to
features enabled in order to verify the fact that we can fit in small
devices and to be able to accurately measure the sizes of the kernel's
basic features.
Signed-off-by: Carles Cufi <carles.cufi@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 sample did not enable gpio driver, so nothing happens after flash
firmware into a board.
By enabling gpio driver to fix it.
Signed-off-by: Aaron Tsui <aaron.tsui@outlook.com>
A new role :zephyr_file: is available that renders to a link to the file
or folder in GitHub. Find appropriate references using :file: and
convert to :zephyr_file: to take advantage of its linking capability.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Most of the basic tests trigger LEDs or expect button press and would
hang in device testing because we can't parse success or failure from
the console. Define harness for this with the intent to skip those in
sanitycheck device testing and until we have a better way to test those.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Some boards' configuration does not enable GPIO by default,
like nrf52_pca10056, it causes ASSERTION FAIL when running
this application. This fix is to enable GPIO by default for
the basic threads sample, like basic blinky sample does.
Signed-off-by: Aaron Tsui <aaron.tsui@outlook.com>
commit ddf744deee ("drivers: pwm_nrfx: Use Device Tree label as
instance name") removed the config setting for PWM names and replaced
it with DT_NORDIC_NRF_PWM_PWM_*_LABEL.
This change is causing the blink_led and fade_led samples to break
when compiled for nRF52 boards.
Let's update the samples to use the DT setting.
Signed-off-by: Michael Scott <mike@foundries.io>
Update the filters that are extracting info from DT to use a define that
has a DT_ prefix so its clear that its coming from DT_. Also this lets
us remove any non-DT prefixed defines in the conf db.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Indicate that PWM is supported on several Nordic DK boards so that
the pwm_nrf5_sw and pwm_nrfx drivers are covered by CI builds.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Enable HW PWM driver instead of the SW one on nRF SoCs where the PWM
peripheral is present.
Default PWM instances are also enabled on Nordic DK boards so that it
is possible to build the basic fade_led sample for them without extra
adjustments.
After the above changes are applied, some configuration alterations
in basic samples blink_led and fade_led become no longer needed.
These are removed. And the blink_led sample is corrected so that it
works with the nRF HW PWM driver as well.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Supported PWM at pins A0, D3, D5 and D6 which are also Arduino
compatible. Also the onboard red LED can be used with PWM.
The basic/{fade_led, blink_led} samples to apply to this board
seemlessly and operate on the onboard red LED.
Also supported RTC.
Signed-off-by: Ioannis Konstantelias <ikonstadel@gmail.com>
Move to latest cmake version with many bug fixes and enhancements.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
blinky/button and disco samples are now using definitions
generated from boards dts files.
Update samples README files accordingly.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
It is safe to assume that if X_GPIO_CONTROLLER is defined (hence
generated) X_GPIO_PIN should also be defined.
If this is not the case, this is an issue and letting the sample
build will reveal the issue.
Update the yaml filter to rely only on _GPIO_CONTROLLER #define's
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
In disco basic sample, same GPIO controller was used for LED0
and LED1, which is actually a particular case.
This change implements the general case, where LED0 an LED1 might
not have the same gpio controller.
Tested on nucleo_f429zi and frdm_k64f.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Since the Arduino 101 and the Quark SE C1000 are not actively developed
boards, default to other boards that are maintained and used.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Andrzej Głąbek