Rtems timer can not be disabled

[bacinchel]

I think Rtems OS_timerset() not satisfy it's description in API document

osal/src/os/rtems/ostimer.c

Line 368 in 75beb86

if ( start_time > 0 )

In POSIX API, Call OS_timerSet() with "start_msec = 0" causes timer stop but Rtems just ignore that parameter

I hope to change OSAL rtems api code to

if ( start_time > 0 ) {
OS_UsecsToTicks(start_time, &timeout);
status = rtems_timer_fire_after(OS_timer_table[timer_id].host_timerid,
timeout,
OS_TimerSignalHandler, (void *)timer_id );
if ( status != RTEMS_SUCCESSFUL )
{
return ( OS_TIMER_ERR_INTERNAL);
}
} else {
status = rtems_timer_cancel(OS_timer_table[timer_id].host_timerid);
if ( status != RTEMS_SUCCESSFUL )
{
return ( OS_TIMER_ERR_INTERNAL);
}
}

[skliper]

@jphickey is this non-compliance with the API documentation still true?

[jphickey]

Yes, it appears that it is still an issue. This is certainly a lesser-used API "feature" and as far as I can tell there is no unit test to check for compliance with this. Also, the API document says that the interval is optional, but also I cannot see any test that checks this "one-shot" behavior either. For CFE, the use case is always to set it using and interval and then forget it.

There are two possible resolutions:

• Add a unit test for this, then use this test to validate the POSIX, RTEMS, and VxWorks are all implementing this feature correctly (I suspect they are not consistent here).
• Remove this statement from the API document, since it wasn't really implemented consistently to begin with. For FSW applications it is unlikely that one would "unset" a timer; we do have the TimerDelete() call to remove a timer and that should work and it is already tested by the unit tests.

[joelsherrill]

Should requesting a timer for 0 ticks really be a cancel? Could OS_UsecsToTicks() return a 0 if Usecs is below the RTEMS CONFIGURE_MICROSECONDS_PER_TICK?

Just asking to make sure this isn't potentially covering up a problem with a timer request below the clock tick quantum.

[jphickey]

No I do not think that setting a start_time of 0 should mean to cancel the timer, because if used with a nonzero interval_time it makes sense; it would mean to start a periodic timer with the first expiration occurring immediately.

But mainly because a timer can be canceled by way of OS_TimerDelete() so I am not sure of the value-add, there is no justification that I can see of having an additional, less obvious way of canceling the timer inside the OS_TimerSet API too. It only creates more testing permutations and risk factors, as pointed out by @joelsherrill for a feature that is unlikely to be used.

Going forward I would recommend that the documentation be changed to indicate that timers should be canceled with OS_TimerDelete(). Any call to OS_TimerSet with both parameters of zero should return OS_ERROR (this is an easy check). This should avoid possible inconsistencies here.

[skliper]

Opened the two new issues above to address this issue, closing this thread.