- Changed the return type for vtimer_init,vtimer_set_msg and vtimer_remove.
- Current return value is not used anywhere and has no meaning attached to it.
- Fix for #1533
- Removed tests which checked for vtimer_set_msg being set.
- Done doxygen adaption for corresponding vtimer functions.
Before, the longterm_tick_timer had special handling in update_shortterm.
This approach was bad because the longterm_tick_timer's shooting microseconds time
had different semantics like the rest and thus it could end up in a blocking
position in the priority queue at some point in time, although it should
get executed at another point in time.
Made the longterm_tick_timer handling / meaning of its microseconds the same
as the other timers and also removed seconds, because it is now the same
as longertm_tick_timer.absolute.seconds.
See also https://github.com/RIOT-OS/RIOT/pull/2515
vtimer does not handle well the different timers (vtimer <-> hwtimer)
with regard to their overflows:
* in update_shortterm HWTIMER_TICKS cannot be just applied to next, this will be wrong when next overflows.
* in vtimer_now wrong parentheses mix up vtimer and hwtimer ticks.
Maybe related issues:
* https://github.com/RIOT-OS/RIOT/issues/2435
* https://github.com/RIOT-OS/RIOT/issues/1753
I enabled debug output in all files to poke around
and there were some errors (seemingly) due to code
changes that were not tested with debug enabled. This
commits tries to fix these issues.
Currently, when using vtimer_set_msg the corresponding msg_t is filled
with the MSG_TIMER ("12345") type.
This approach makes it difficult to differentiate between incoming
messages via vtimer_set_msg.
In this PR I introduce another parameter for the vtimer_set_msg
function to specify a custom msg_t type.
Boards should define HWTIMER_SPIN_BARRIER that is used to decide
whether it makes sense to set a timer and yield or call hwtimer_spin
instead.
Used by `core/hwtimer.c` and `sys/vtimer/vtimer.c`.
A default value is provided and a warning is printed when it is used.
Instead of using differing integer types use kernel_pid_t for process
identifier. This type is introduced in a new header file to avoid
circular dependencies.
It seems that there are corner cases where a vtimer was removed, but
still there comes a hwtimer callback. This is a bug somewhere in the
vtimer or hwtimer. If there still was a vtimer set, then the next one
gets called before its time. If there was no other vtimer scheduled,
then `timer->action(timer)` crashes.
This PR simply fixes the crash, but does not attempt to find the more
fundamental bug.
For many modules the `Makefile` contains a line like
```
MODULE:=$(shell basename $(CURDIR))
```
This conclusively shows that we do not have to set the module name
manually.
This PR removes the need to set the module name manually, if it is the
same as the basename. E.g. for `…/sys/vtimer/Makefile` the variable
make `MODULE` will still be `vtimer`, because it is the basename of the
Makefile.
There is no need to test the "handler" set in the vtimer struct, and
have some code executed then. We just can make the code to execute the
handler. To lengthy `if else if`, just a call.
RIOT's gettimeofday needs to be called from syscalls.c to assure that gcc actually links it.
If an RTC if available and enabled it will be used instead.
