This is a follow-up to commit 4cc21e2f4a.
That short sleeping before starting the test was removed together with
accuracy improvements (specifically, with moving of the first readout
of the cycle counter). Nevertheless, this tick alignment it still
needed, as without it in specific conditions the test may undesirably
fail.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This patch adds a way to simplify using an external tool to measure
timer behaviour on Zephyr. It modifies the timer behaviour
jitter_drift.c tests to toggle a GPIO pin (defined via a new DTS
compatible, "test-kernel-timer-behavior-external") that can be connected
to an external tool, such as a logic analyzer, to measure timer
behaviour.
This GPIO pin toggle is behind a new CONFIG_TIMER_EXTERNAL_TEST Kconfig.
A new pytest test is added so that it can collect the statistics from
the external tool and assert some measurements. To collect statistics
from the external tool, one needs to provide a Python module which
provides a `run(seconds, config)` method, that will perform the test and
return the statistics. Check the README file for more information about
this interface.
Finally, this on twister, this new test is behind a new fixture,
"gpio-timerout".
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Commit a1d21ca69b ("tests: timer_behavior: don't fail the test with
timer wrap-arounds") simply ignored the total time validation whenever
any rollover was detected. Let's adjust the end timestamp according
to the number of rollovers instead.
Documentation for sys_clock_cycle_get_32() says it should count up
monotonically through the full 32 bit space, wrapping at 0xffffffff.
Therefore we just need to add 2^32 times the number of rollovers to
the end timestamp.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
If the timer driver only implements sys_clock_cycle_get_32() (meaning
CONFIG_TIMER_HAS_64BIT_CYCLE_COUNTER=n) and the hardware clock is high
enough then the reported cycle count may wrap an uint32_t during the
test. This makes validating the total test duration pointless as it
cannot be measured. Just print a warning instead of failing the test
in that case.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Don't sample the first entry outside the timer as this is a different
code path which produces a different offset from the clock tick.
Use sys_clock_hw_cycles_per_sec() to be compatible with systems that
read their hardware clock frequency at run time.
Perform cycle difference computations with uint64_t. If ever the
magnitude of the absolute clock cycle values is greater than 52 bits
then the cast to a double will actually lose accuracy.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
An assertion statement was a bit too strict. Period drift may come about
not only from kernel ticks being large but also from time conversion being
inexact due to division truncation.
Fixes: #55136
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Provide an estimate of the test duration.
Make the output nicer than a few overloaded and wrapped lines.
Provide more context in the presence of period time drift.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Print the "perfect" reference period for easier evaluation.
Suggest a remedy to the missed ticks problem.
Still, that wasn't satisfactory. Implemented a count of missed ticks
to get to the bottom of this issue. Found that missed ticks always came
to a perfect count of 40.
Incidentally, the busy loop prints a line every 250 ms and the test spans
10 seconds. There are no such coincidences.
Turns out that CONFIG_PRINTK_SYNC was set by default. This disables IRQs
for the serial output duration, which can be quite long at 115200 bauds.
Given a 60-ish character line length, this represents more than 5 ms of
no IRQ servicing during a timer latency measurement test which is bad.
So make sure CONFIG_PRINTK_SYNC=n for proper statistics.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The requirement of being able to spend only 10% of processing time
on execution of timer handlers that are scheduled on every tick is
not really possible to fulfill on platforms like the nRF ones where
the tick period is quite short (~30 us in this case). Relax this
requirement and accept if at least one-third of the processing time
is available for other work while handling the timer tick train.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Test timers with a train of one tick timers to test that
a configured SYS_CLOCK_TICKS_PER_SEC is sensible. If the TICKS_PER_SEC
is too high the timer train will take longer than expected to reach
the station. Worse, if the timer driver has too short of a minimum
delay for its processing power and the tick rate is too high its
possible the device will get caught in an interrupt loop
preventing any threads from running while processing timers.
This test validates that the tick rate configured is actually able to be
processed without delays while also having work done in threads ensuring
that no thread scheduling delays occur either from delayed timers or an
interrupt loop from preventing threads from running.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Adds a custom test_main and renames the test suite for jitter_drift.
Runs the jitter_drift test suite.
The order of these tests matter on hardware as the counter is often
reset on loading the test program. This is useful as its far less likely
to encounter a clock counter rollover. On arm this is especially useful.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Move the main.c timer behavior test code to jitter_drift.c
so that other tests may be added to the suite.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Zephyr timer is based on system ticks, there usually exists some time drift
due to round up/down errors between cycles, ticks and time delay, we
need to add those expected time drift into the bound calculation for
running this test.
Add a new config TIMER_TEST_PERIOD_MAX_DRIFT_PERCENT for users to set
expected maximum drift percentage for the timer period.
Signed-off-by: Chen Peng1 <peng1.chen@intel.com>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Test and validate the behavior of a timer driver.
Takes a number of absolute timer cycle samples of a periodic timer then
calculates statistical mean, variance, stddev along with total drift over
the entire test time. Ensures standard deviation and drift are within
a given configurable bound.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
