Re: [Xenomai-help] xenomai scheduler's ticks period

[Philippe Gerum <rpm@xenomai.org>]

Matthieu wrote:
> Hi
> 
> Well I'm going to try to be clear :
> 
> I work on a project that aims at migrating VxWorks tasks from PPC boards on
> VME crate to X86 Computer ruuning with Linux. The cost of using Xenomai API
> instead of vxworks skin seems very costly. The idea is to keep the maximum
> of mechanisms.
> 
> As there is no implementation of vxworks periodic task instruction, the
> idea was to use watchdogs. In fact, as watchdogs are counting from ticks,
> it's easy to make tasks periodic if the period of the task is a multiple of
> the tick period. So each task starts it's watchdog, executes some routine,
> and suspends itself. The watchdog, when the specified delay ticks elapsed,
> resumes the task. And so on...

You may want to use a semaphore to synchronize your wd handler with the task
instead of suspend/resume calls.

> 
> The use of multiple PPC boards, with periodic tasks that need to be
> synchronized, has required the use of an hardware interrupt, spread to all
> CPUs, and which handler tickAnnouce() vxworks. I know that this mechanism
> isn't still necessary as there is only one vxworks tick on Xenomai, even if
> I work with many CPUs.

Wrong, Xenomai ticks on each CPU because internal timers are per-cpu resources;
only the boot CPU tracks jiffies, but that's a different issue.

 But in the new configuration, I have a PCI card that
> will send this interrupt. So I need to stop the automatic vxworks tick with
> tick_arg=0 and to handle this interrupt to tickAnnouce() manually. As I
> will don't have this card all the day, I need to simulate this mecanism,
> and I need to create something that will tickAnnouce() at a periodic time.
> 
> I created a module that, in on case, will handle the interrupt, and on an
> other case, will create a xenomai rt_task that tickAnnouce. And this
> doesn't work. I want the ioctl method send the period to the module in
> order to modify the period of the tick.
> 
> I still have created this driver has you see but it doesn't work.

What your code did is switching the VxWorks timer to aperiodic mode which stops
periodic timing; in that mode, the time unit is nanosecond, so every timeout
data is interpreted as a count of nanoseconds. This is likely not what you want.

 I'm going
> to test your modifications. Thank you for that.
> 

Forget about this example; actually, those changes do not fix the logic, but
only provide some hints about xntbase_switch(), and fix return code issues.

> I will also need to get a precise time, and Gilles suggest me to use
> xntbase, but xntbase_get_time(&nktbase); isn't recognized.

What Gilles told you is that solely switching the VxWorks clock to aperiodic
mode (by passing period == 0) would wreck the underlying timing logic of a
VxWorks app, which does not pass/expect nanoseconds but jiffies/ticks. In short,
doing so is not enough.

Normally, solving your issue would require to make the master timebase paced by
your PCI card, which would in turn provide the correct timing for the VxWorks
timebase (as the timebase doc states, periodic timebases are cascaded from the
master aperiodic one). However, doing so would also require to adapt the Xenomai
HAL code accordingly, and a PCI hw that is oneshot programmable as well.

If you want to hack the Xenomai timer sub-system in order to only affect the
VxWorks timebase, what you actually need is to control the coupling between the
master timebase (paced by decrementer) and the slave VxWorks one, so that
decrementer ticks may be prevented from kicking the VxWorks timebase. This way,
you would be able to call tickAnnounce() freely to announce any incoming VxWorks
tick (i.e. from your PCI handler).

In short, when paced by the PCI interrupt, you will need to:

- call xntslave_stop(base2slave(wind_tbase))
- call tickAnnounce() from your PCI IRQ handler

When paced normally (simulation, "somebody stole by PCI card" mode), just leave
the burden to the system timer (i.e. ppc decrementer) as usual, by coupling the
VxWorks slave timebase to the master one anew:

- call xntslave_start(base2slave(wind_tbase),  xnarch_get_cpu_time() + period,
period); /* period is given in nanoseconds, depends on the master timebase */

In any case, you don't need to change the VxWorks tick period. Starting/stopping
the VxWorks timebase should do the trick. NOTE: this is a hack exposing Xenomai
internals -- we should probably encapsulate this into new xntbase_bind/unbind
calls if this does eventually works for you.

-- 
Philippe.