Re: [Xenomai-core] Towards periodic mode over aperiodic timers

[Philippe Gerum <rpm@xenomai.org>]

On Thu, 2006-08-17 at 15:27 +0200, Jan Kiszka wrote:
> Hi,
> 
> the conflict between skins preferring aperiodic timing vs. skin
> requiring periodic mode popped up once again on xenomai-help. One way
> out of this, likely THE way, is to map such tick-driven skins on a
> periodic timer over aperiodic mode (and drop periodic low-level support
> completely at the same time).
> 
> Let's start some discussion how this can be done, specifically as Gilles
> and I are already turning the xntimer subsystem upside down (almost). If
> we want co-existence of high-res timing of, say, the posix skin while
> the vxworks skin runs over a tick-timer, we need some kind of "context"
> for timing related functions.
> 
> Simple example: xnpod_suspend_thread() expects a timeout as "xnticks",
> i.e. either in nanoseconds or in ticks of the underlying periodic timer.
> This depends on the global timer mode of the pod, and that's a no-go for
> concurrent modes as sketched above. Rather, the thread should encode
> which kind of timing mode to use, even better the threads timers.
> 
> We currently dispatch xntimer_start globally to the different timer
> subsystems (if periodic mode is enabled). What about deriving the start
> function from the timer itself in the future? If a timer was created as
> aperiodic, things happen as usual in aperiodic mode, and the timeout are
> interpreted as nanoseconds. If the timer is periodic, we interpret the
> timeout in ticks and map them on a second-level timing subsystem
> (probably a wheel) that itself is driven by a single periodic timer in
> the first-level system (just like the host tick).
> 
> Am I heading in the right direction? Is it feasible? Any other ideas?

I like this idea; it's simple and elegant, having only a low impact on
the existing interfaces.

The two-level timer handling moving the BSD wheel on top of the
aperiodic shot is definitely a clean approach, which adds no overhead to
the existing periodic timer management. This would also allow to get rid
of the specific Adeos support for periodic hw management.

-- 
Philippe.