The clock/timer APIs are not application facing APIs, however, similar
to arch_ and a few other APIs they are available to implement drivers
and add support for new hardware and are documented and available to be
used outside of the clock/kernel subsystems.
Remove the leading z_ and provide them as clock_* APIs for someone
writing a new timer driver to use.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The test_timeout_abs case had baked in similar mistakes to the
off-by-one in the absolute timer implementation. FOR THE RECORD:
If you have an absolute timeout expiration set for a tick value "N",
and the current time returned by k_uptime_ticks() is "T", then the
time returned (at the same moment) by any of the *_remaining_ticks()
APIs must ALWAYS AND FOREVER BE EXACTLY "N - T" (also: "N - T > 0"
always, until the moment the kernel ISR hands off control to the first
timeout handler expiring at that tick).
The tick math is exact. No slop is needed on any systems, no matter
whether their clocks divide by milliseconds or not.
The only gotcha is that we need to be sure that the calls don't
interleave with a real time tick advance, which we do here with a
simple retry loop.
But, about slop... This patch also includes a related fix for the
test_sleep_abs(). On an intel_adsp (which has 50 kHz ticks, a
comparatively slow idle resume and interrupt entry, and even has two
CPUs to mess with latency measurements) I would occasionally see the
k_sleep() take more than a tick to wake up from the interrupt handler
until the return to application code. Add some real time slop there
(just 100us) to handle systems like this.
Fixes#32572
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Absolute timeouts were covered, but nothing was testing their actual
expiration time and there was an off-by-one.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Correct a bunch of precision/analysis errors in this test:
* Test items weren't consistent about tick alignment and resetting of
the timestamp, so put these steps into init_timer_data() and call
that immediately before k_timer_start().
* Many items would calculate the initial timestamp AFTER
k_timer_start(), leading to an extra (third!) point where the timer
computation could alias by an extra tick. Always do this
consistently before the timer is started (via init_timer-data()).
* Tickless systems with high tick rates can easily advance the system
uptime while the timer ISR is running, so the system can't expect
perfect accuracy even there (this test was originally written for
ticked systmes where the ISR was by definition happening "at the
same time").
(Unfortunately our most popular high tick rate tickless system,
nRF5, also has a clock that doesn't divide milliseconds exactly, so
it had a special path through all these precision comparisons and
avoided the bugs. We finally found it on a x86 HPET system with 10
kHz ticks.)
* The interval validation was placing a minimum bound on the interval
time but not a maximum (this mistake was what had hidden the failure
to reset the timestamp mentioned above).
Longer term, the millisecond precision math in these tests is at this
point an out of control complexity explosion. We should look at
reworking the core OS tests of k_timer to use tick precision (which is
by definition exact) pervasively and leave the millisecond stuff to a
separate layer testing the alternative/legacy APIs.
Fixes#31964 (probably -- that was reported against up_squared, on
which I had trouble reproducing, but it was a common failure on
ehl_crb).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This reverts commit b98058ecd0.
With icount finally working in QEMU for ARC these tests start to
pass reliably, so no need to exclude them any longer.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Add some error condition or testing cases to verify whether the
robustness of API. Such as give a NULL to some API and check
the response if get result that we were expacted.
Signed-off-by: Jian Kang <jianx.kang@intel.com>
- 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>
Add a k_usleep() in test_timer_duration_period test to align ticks
before starting the timer. This fixes some rare off-by-1 failures.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Move init_timer_data() out of k_usleep() tick alignment.
Compute rem_ticks just after busy_wait_ms() to avoid slew
due to 'now' and 'rem_ms' computations.
With slow CPU 32MHz: -2 Ticks.
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
Insert k_usleep(1) just before k_timer_start()
to guaranty tick alignment for step "test_timer_k_define"
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
Add new test cases for timer to improve testing infrastructure.
Add different waiting time in existing cases. For new test cases,
restart timer and check for status of timer.
Signed-off-by: Jian Kang <jianx.kang@intel.com>
Several of the values passed to the conversion failure diagnostic are
unsigned and/or 32-bit values, while all format specifiers are for
signed 64-bit integers. Make the specifiers consistent with the
argument.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Unit tests were failing to build because random header was included by
kernel_includes.h. The problem is that rand32.h includes a generated
file that is either not generated or not included when building unit
tests. Also, it is better to limit the scope of this file to where it is
used.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Add timer label for this test suite, so it is included
in sanity check runs with -t timer.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
After the Qemu Cortex-M0 timer driver rework, we may
enable the test-suite that had been (always) excluded
from running on this platform.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
The converted target value for remaining ticks was increased by one to
match original code, which used a one-sided test. The current test is
two-sided, so that increment is already present in the allowed 1 tick
error for boards with no slew, and incorporating it into the absolute
error can cause the test to fail.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
