I think enabling vtimer to await an absolute point in time would be useful,
something like this . Otherwise you end up subtracting the current time
and adding it again in vtimer_set.
I think something like this could indeed be helpful. However, I think we
should try to collect all the different requirements for the timer system
somewhere and think about a redesign. Not only that certain features are hard
or even impossible to achieve with the current hwtimer/vtimer/RTC concept, but
also the API could be improved and simplified quite a bit - not speaking about
all the bugs and races in the current implementation.
All in all, I think it's quite urgent to establish a task force for the timer
system in a similar fashion like we do for the network stack or OTA, for
example. Would you be interested to participate in such a task force and maybe
start already by setting up a wiki page or similar to collect the different
while I see the point of a timer task force, I am not sure I am of great help rewriting it. I have no clue how it works besides a bit experience with the API. But if I can help, sure. Are there wiki pages for the other task forces?
while I see the point of a timer task force, I am not sure I am of great
help rewriting it. I have no clue how it works besides a bit experience
with the API.
The first thing we should do before rewriting or even re-designing the timer system is collecting the requirements - and for this task, everybody having a (concrete) requirement is definitely of great help.
But if I can help, sure. Are there wiki pages for the
other task forces?
Not sure. You might look at the wiki pages about the network stack design or let inspire yourself by the TinyOS pages (Philipp, can you help with a link here?). But as far as I'm concerned: just start with any kind of form, we can work on this latter on. The content is much more important.
You could even start an issue in the Github tracker with a checklist or similar.