mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-09-05 22:01:56 +00:00
3e729b2b1c
The period argument of a k_timer needs an offset of one tick from the value computed in user code (because periods get reset from within the ISR, see the comment above this code for an explanation). When the computed tick value was 1, it would become 0. This is actually perfectly correct as a k_timeout_t to be passed to z_add_timeout(). BUT: to k_timer's API, K_NO_WAIT means "never" (i.e. the same as K_FOREVER) and not "as soon as possible", so the period timer would not be reset. This is sort of a wart, but it's the way the API has been specified forever. The upshot is that for the case of calling k_timer_start() with a minimal period argument (i.e. one that produces "one tick"), the period would be ignored and the timer would act like a one shot. Fix the clamp so it can't produce K_NO_WAIT. This also adds a filter for absolute timeouts, which (while that's sort of a pathological usage) were getting that one tick offset when it wasn't appropriate. Signed-off-by: Andy Ross <andrew.j.ross@intel.com> |
||
|---|---|---|
| .. | ||
| include | ||
| atomic_c.c | ||
| CMakeLists.txt | ||
| compiler_stack_protect.c | ||
| device.c | ||
| errno.c | ||
| fatal.c | ||
| futex.c | ||
| idle.c | ||
| init.c | ||
| Kconfig | ||
| Kconfig.power_mgmt | ||
| kheap.c | ||
| mailbox.c | ||
| mem_domain.c | ||
| mem_slab.c | ||
| mempool_sys.c | ||
| mempool.c | ||
| msg_q.c | ||
| mutex.c | ||
| pipes.c | ||
| poll.c | ||
| queue.c | ||
| sched.c | ||
| sem.c | ||
| smp.c | ||
| stack.c | ||
| system_work_q.c | ||
| thread_abort.c | ||
| thread.c | ||
| timeout.c | ||
| timer.c | ||
| userspace_handler.c | ||
| userspace.c | ||
| version.c | ||
| work_q.c | ||