xtimer: Add xtimer_periodic_msg #7496
Conversation
|
I removed chronos from the insufficient memory blacklist for the other xtimer_periodic_ test, it was probably just a copy pasta from some other test since these tests are pretty tiny with the current settings. |
If you're designing the MAC layer around this, keep in mind that messages from ISR's are not reliable, as they get silently discarded if the receiving thread is not waiting (or it's queue is full). |
|
Thanks for the warning. We will be using this for scheduling transceiver wake times for the RX schedule. The thread will use this function to send a message to itself to trigger an event at the beginning of the next receive window. This is necessary in order for still be able to handle TX operations while idling with the RX part turned off. |
|
have you thought about using thread_flags for the periodic wakeup? |
|
@haukepetersen I have not. How do I use them? |
|
I have looked into using thread flags and I think it will be a better solution than a pure msg based event loop. I will do some experiments and possibly add something more to this PR. |
|
perfect. |
sys/xtimer/xtimer.c
Outdated
| * For very small offsets, spin. | ||
| */ | ||
| /* | ||
| * Note: last_wakeup _must never_ specify a time in the future after |
There was a problem hiding this comment.
accidentally messed up the indentation...
| DEBUG("xps, abs: %" PRIu32 "\n", target); | ||
| _xtimer_set_absolute(timer, target); | ||
| } | ||
| } while (0); | ||
| *last_wakeup = target; |
There was a problem hiding this comment.
this is a problem for the _msg variant, the last wakeup time will increment before that time has actually passed, leading to the situation described above in the long comment about not returning early.
Calling xtimer_periodic_msg twice without waiting for the first message to send will mess up the timer.
| DEBUG("xps, abs: %" PRIu32 "\n", target); | ||
| _xtimer_set_absolute(timer, target); | ||
| } | ||
| } while (0); |
There was a problem hiding this comment.
why do you need the do { ... } while(0);?
There was a problem hiding this comment.
So that the break replaces the goto
af7bf3b to
67a8361
Compare
When the target is inside the next long_period, the previous condition was incorrect. The new condition should give the same result regardless of whether there is a long_period tick coming soon or not.
75c8d8d to
e996db1
Compare
|
|
|
needs rebase |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
This PR splits the
xtimer_periodic_wakeupfunction into one generic part which is reused byxtimer_periodic_wakeupandxtimer_periodic_msg, and one specific part for setting up the callback.xtimer_periodic_msgis functionally similar toxtimer_set_msg, but the target time is computed in the same way as forxtimer_periodic_wakeup.xtimer_periodic_msgcan be used to create periodic messages. This is especially useful if a thread has an event loop for handling asynchronous events, but some events need to occur periodically on a schedule. Usingxtimer_periodic_wakeupin these kinds of applications would cause the asynchronous events to be delayed until the next wakeup, instead of processed immediately.This is in preparation for some future MAC layer functionality that we are working on.