Is the return value of rtems_clock_get_ticks_since_boot() guaranteed to be different before and after a call to rtems_task_wake_after(1) (provided, of course that the tick counter does not wrap around)?
In RTEMS 6.1, I have a task that essentially runs:
uint32_t a = rtems_clock_get_ticks_since_boot();
...
rtems_task_wake_after(1);
...
uint32_t b = rtems_clock_get_ticks_since_boot();
and at one occasion I found that b == a after the second assignment.
I would have expected that b >= a + 1 (provided the tick count does not wrap around).
This expectation is based on two assumptions:
rtems_task_wake_after(1) wakes up no earlier than after the next tick.
rtems_clock_get_ticks_since_boot() returns a number that is constant between two ticks, and is increased by one at every tick.
Ok, thanks then this makes sense for the following reason. In an SMP architecture, the rtems_clock_get_ticks_since_boot() returns the number of ticks on the boot processor. So what you might be observing is something like the following, suppose you have CPU0 as the boot processor:
Task is executing on CPU1
Reads a Ticks on CPU0
call rtems_task_wake_after(1) to sleep for a partial tick
Wake up and read b Ticks on CPU0
Because the first interval of the rtems_task_wake_after is a partial tick (it does not start on a clock tick), the task sleeps for less than a full clock tick. Due to asynchrony between CPU0 and CPU1 you get the behavior you observe.
I don’t think we currently expose an API to view the clock ticks for the executing core. This value is stored in Per_CPU_Control.Watchdog.ticks in case you’d like to check with a debugger.