Use this short header style in all Kconfig files:
# <description>
# <copyright>
# <license>
...
Also change all <description>s from
# Kconfig[.extension] - Foo-related options
to just
# Foo-related options
It's clear enough that it's about Kconfig.
The <description> cleanup was done with this command, along with some
manual cleanup (big letter at the start, etc.)
git ls-files '*Kconfig*' | \
xargs sed -i -E '1 s/#\s*Kconfig[\w.-]*\s*-\s*/# /'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
The CONFIG_CLOCK_CONTROL and CONFIG_NRF_RTC_TIMER were
unconditionally selected when enabling any nRF SoC. But since
timers can be disabled in the kernel, depend instead on
CONFIG_SYS_CLOCK_EXISTS, which is only defined when kernel
timer support is included.
Note that ideally we would enable CONFIG_NRF_RTC_TIMER only, and
that would select CONFIG_CLOCK_CONTROL (on which the RTC timer
depends) but there is a circular Kconfig dependency that prevents
us from doing so.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
This reverts commit bd24b31139.
While the test case failure described in #14186 is associated with the
cycle-based busy-wait implementation, that test is fragile, and fails
less frequently once the incongruence between ticks-per-second and the
32 KiHz RTC clock are resolved. It also assumes that the system clock
is more stable than the infrastructure underlying the the busy-wait
implementation, which is not necessarily true.
The gross inaccuracies in the standard busy-wait on Nordic described in
issue #11626 justify restoring the custom solution.
As this applies to all Nordic devices, move the setting to the top-level
Kconfig.defconfig.
See: https://github.com/zephyrproject-rtos/zephyr/issues/11626#issuecomment-487243369
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
The default system clock on all Nordic devices is based on a 32 KiHz
(2^15 Hz) timer. Scheduling ticks requires that deadlines be specified
with a timer counter that aligns to a system clock. With the Zephyr
default 100 clocks-per-sec configuration this results in 100 ticks every
32700 ticks of the cycle timer. This reveals two problems:
* The uptime clock misrepresents elapsed time because it runs 0.208%
(68/32768) faster than the best available clock;
* Calculation of timer counter compare values often requires an integer
division and multiply operation to produce a value that's a multiple
of clock-ticks-per-second.
Integer division on the Cortex-M1 nRF51 is done in software with a
(value-dependent) algorithm with a non-constant runtime that can be
significant. This can produce missed Bluetooth deadlines as discussed
in upstream #14577 and others.
By changing the default divisor to one that evenly divides the 2^15
clock rate the time interrupts are disabled to manage timers is
significantly reduced, as is the error between uptime and real time. Do
this at the top level, moving SYS_CLOCK_HW_CYCLES_PER_SEC there as well
since the two parameters are related.
Note that the central_hr configuration described in upstream #13610 does
not distinguish latency due to timer management from other
irq_block/spinlock regions, and the maximum observed latency will still
exceed the nominal 10 us allowed maximum. However this does occur
much less frequently than changing the timer deadline which can happen
multiple times per tick.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
This commit introduces the Kconfig file structure for nrf9160
SoC in the Zephyr tree.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Ulf Magnusson