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

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

[Matthieu]

Hi,

I have a problem with xntbase_update(wind_tbase,1000000); because it
doesn't give me a 1ms period. The period is given as a count of nanoseconds
as it is said in the API documentation. I search solution around
tick/nanoseconds conversion or periodic/aperiodic timebase but I didn't
solve my problem. Moreover, when I call this instruction,
/proc/xenomai/timebases gives me a vxworks resolution of 1000000, what is
correct, but the period seem's to be 0.452ms . Could you tell me what I've
done wrong ?

Thank you.

Matthieu.

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

[Matthieu]

On Thu, 17 Jul 2008 09:49:19 +0200, Matthieu
<matthieu.connaulte_xenomai@domain.hid> wrote:
> Hi,
> 
> I have a problem with xntbase_update(wind_tbase,1000000); because it
> doesn't give me a 1ms period. The period is given as a count of
> nanoseconds
> as it is said in the API documentation. I search solution around
> tick/nanoseconds conversion or periodic/aperiodic timebase but I didn't
> solve my problem. Moreover, when I call this instruction,
> /proc/xenomai/timebases gives me a vxworks resolution of 1000000, what is
> correct, but the period seem's to be 0.452ms . Could you tell me what
I've
> done wrong ?
> 
> Thank you.
> 
> Matthieu.
> 
> 

Hi,

As I have no news, I would like to know if there is any solution to this
problem ?

PS : I also have no return concerning xntbase_bind/unbind implementation.
Is it still planned ?

Thank you in advance for your answers

Matthieu

> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

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

[Matthieu]

On Mon, 21 Jul 2008 16:41:52 +0200, Matthieu
<matthieu.connaulte_xenomai@domain.hid> wrote:
> 
> On Thu, 17 Jul 2008 09:49:19 +0200, Matthieu
> <matthieu.connaulte_xenomai@domain.hid> wrote:
>> Hi,
>>
>> I have a problem with xntbase_update(wind_tbase,1000000); because it
>> doesn't give me a 1ms period. The period is given as a count of
>> nanoseconds
>> as it is said in the API documentation. I search solution around
>> tick/nanoseconds conversion or periodic/aperiodic timebase but I didn't
>> solve my problem. Moreover, when I call this instruction,
>> /proc/xenomai/timebases gives me a vxworks resolution of 1000000, what
> is
>> correct, but the period seem's to be 0.452ms . Could you tell me what
> I've
>> done wrong ?
>>
>> Thank you.
>>
>> Matthieu.
>>
>>
> 
> Hi,
> 
> As I have no news, I would like to know if there is any solution to this
> problem ?
> 
> PS : I also have no return concerning xntbase_bind/unbind implementation.
> Is it still planned ?
> 
> Thank you in advance for your answers
> 
> Matthieu
> 

Hi,

I didn't archieve in using xntslave_start/stop(), as I didn't find the
header and/or the lib to link. Could you help me ?

Matthieu


>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

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

[Gilles Chanteperdrix]

Matthieu wrote:
> 
> On Mon, 21 Jul 2008 16:41:52 +0200, Matthieu
> <matthieu.connaulte_xenomai@domain.hid> wrote:
>> On Thu, 17 Jul 2008 09:49:19 +0200, Matthieu
>> <matthieu.connaulte_xenomai@domain.hid> wrote:
>>> Hi,
>>>
>>> I have a problem with xntbase_update(wind_tbase,1000000); because it
>>> doesn't give me a 1ms period. The period is given as a count of
>>> nanoseconds
>>> as it is said in the API documentation. I search solution around
>>> tick/nanoseconds conversion or periodic/aperiodic timebase but I didn't
>>> solve my problem. Moreover, when I call this instruction,
>>> /proc/xenomai/timebases gives me a vxworks resolution of 1000000, what
>> is
>>> correct, but the period seem's to be 0.452ms . Could you tell me what
>> I've
>>> done wrong ?
>>>
>>> Thank you.
>>>
>>> Matthieu.
>>>
>>>
>> Hi,
>>
>> As I have no news, I would like to know if there is any solution to this
>> problem ?
>>
>> PS : I also have no return concerning xntbase_bind/unbind implementation.
>> Is it still planned ?
>>
>> Thank you in advance for your answers
>>
>> Matthieu
>>
> 
> Hi,
> 
> I didn't archieve in using xntslave_start/stop(), as I didn't find the
> header and/or the lib to link. Could you help me ?

We have helped you a lot already. You have a full mailing thread of
advices, you have online documentation, if that is not enough, xenomai
installs documentation locally. If that is still not enough, you can
resort to the sources.

So now, stop asking questions, read what you have at hand and get the
job done.

-- 
                                                 Gilles.

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

[Matthieu]

Hi

I tried to use xntslave_start/stop in my rtdm module, but it seems that,
despite xntslave_start/stop instructions are present in my System.map, the
linker don't archive :
    > grep xntslave_start /boot/System.map-2.6.25-pae
    c01629b9 T xntslave_start
    > depmod -F /boot/System.map-2.6.25-pae -e vxworks_tick_time_module.ko
    WARNING: vxworks_tick_time_module.ko needs unknown symbol
xntslave_start
    WARNING: vxworks_tick_time_module.ko needs unknown symbol xntslave_stop
I looked at the sources and found that xntbase_start/stop have the same
goals, so I use this instead of xntslave_start/stop.

My RTDM driver works well and all my ioctls work too.

I encounter something not expected : when I use xntbase_update to change
vxworks timebase period, /proc/xenomai/timebase file gives me the right
Resolution for vxworks timebase, but my test program that calculate this
value (with a task that waits for a tick thanks to a watchdog and semaphore
mechanism) gives me a really wrong value. And I don't know why.

I have an other problem : my rtdm module allows me to get the master time
base value using xntbase_get_time(&nktbase), but it seems like the value
returned isn't given in nanosecond. I test that getting the value in an
approximate 1 second interval, and when I check for the difference between
the two values, I get something like 15 to 30 seconds !!

Could you tell me what can I do to find where is the problem ?

Thank you

Matthieu

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

[Matthieu]

On Tue, 15 Jul 2008 21:07:02 +0200, Philippe Gerum <rpm@xenomai.org> wrote:
> Matthieu wrote:
>> Hi,
>>
>> I would like to know if you finally plan to implement
> xntbase_bind/unbind ?
>>
> 
> Why?

You told in one of your answers :

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.

...End of quote.

Well, it works for me. So do you intend to implement xntbase_bind/unbind
calls or do I use directly xntslave_start/stop ? Both solutions are ok for
me ...

 
>> Matthieu
>>
>>
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>>
> 
> 
> --
> Philippe.


Matthieu

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

[Philippe Gerum]

Matthieu wrote:
> 
> On Tue, 15 Jul 2008 21:07:02 +0200, Philippe Gerum <rpm@xenomai.org> wrote:
>> Matthieu wrote:
>>> Hi,
>>>
>>> I would like to know if you finally plan to implement
>> xntbase_bind/unbind ?
>> Why?
> 
> You told in one of your answers :
> 
> 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.
> 
> ...End of quote.
> 
> Well, it works for me. So do you intend to implement xntbase_bind/unbind
> calls or do I use directly xntslave_start/stop ? Both solutions are ok for
> me ...
>

Well, "it works for me" is the kind of feedback I have been waiting for so far.
In extenso, my latest reply should read as: "why do you want me to care about
xntbase_bind/unbind, since I have no idea of whether my suggestion worked for
you or not?".

Now that I do have that information, the answer to your question is yes, likely.
ETA: undefined yet.

-- 
Philippe.

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

[Philippe Gerum]

Matthieu wrote:
> Hi,
> 
> I would like to know if you finally plan to implement xntbase_bind/unbind ?
>

Why?

> Matthieu
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 
Philippe.

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

[Matthieu]

Hi,

I would like to know if you finally plan to implement xntbase_bind/unbind ?

Matthieu

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

[Philippe Gerum]

Matthieu wrote:
> On Mon, 07 Jul 2008 16:16:36 +0200, Philippe Gerum <rpm@xenomai.org> wrote:
>> Matthieu wrote:
>>> On Mon, 07 Jul 2008 15:55:33 +0200, Philippe Gerum <rpm@xenomai.org>
>> wrote:
>>>> Matthieu wrote:
>>>>>>> I need a clock to get the time with a 10 µs precision. I tought
>> using
>>>>>> this
>>>>>>> master timebase, as it gives me a time in nanoseconds, irrespective
>> of
>>>>>>> vxworks timebase.
>>>>>> That will work. The master timebase is always active and does return
>>>>>> nanoseconds
>>>>>> when inquired.
>>>>> What instruction I use to get this time ?
>>>>> I tried :
>>>>>
>>>>> #include <native/timer.h>
>>>> #include <nucleus/timebase.h>, but that's not the point.
>>>>
>>>>> xntbase_get_time(&nktbase);
>>>>>
>>>>> But it doesn't work
>>>> It ought to work, otherwise nothing would. What's the issue? Unpected
>>>> result?
>>> I want to get the actual time at a 10µs precision. I will truncate the
>>> result as the master timebase is a nanosecond precision time.
>>>
>> xntbase_get_time(&nktbase) will get you that value. Really. What does not
>> work
>> for you?
> 
> error: 'nktbase' undeclared (first use in this function)
> I include #include <nucleus/timebase.h> but when I look at the source code,
> I see that I need to be un KERNEL space ??
>

Of course you do, that's Xenomai nucleus code. You need to return that value
from your ioctl.

>>>> --
>>>> Philippe.
>>> Matthieu
>>>
>> --
>> Philippe.
> 
> Matthieu
> 
> 
> 


-- 
Philippe.

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

[Philippe Gerum]

Matthieu wrote:
> 
> On Mon, 07 Jul 2008 15:55:33 +0200, Philippe Gerum <rpm@xenomai.org> wrote:
>> Matthieu wrote:
>>>>> I need a clock to get the time with a 10 µs precision. I tought using
>>>> this
>>>>> master timebase, as it gives me a time in nanoseconds, irrespective of
>>>>> vxworks timebase.
>>>> That will work. The master timebase is always active and does return
>>>> nanoseconds
>>>> when inquired.
>>> What instruction I use to get this time ?
>>> I tried :
>>>
>>> #include <native/timer.h>
>> #include <nucleus/timebase.h>, but that's not the point.
>>
>>> xntbase_get_time(&nktbase);
>>>
>>> But it doesn't work
>> It ought to work, otherwise nothing would. What's the issue? Unpected
>> result?
> 
> I want to get the actual time at a 10µs precision. I will truncate the
> result as the master timebase is a nanosecond precision time.
>

xntbase_get_time(&nktbase) will get you that value. Really. What does not work
for you?

>> --
>> Philippe.
> 
> Matthieu
> 
> 
> 


-- 
Philippe.

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

[Philippe Gerum]

Matthieu wrote:
>>> I need a clock to get the time with a 10 µs precision. I tought using
>> this
>>> master timebase, as it gives me a time in nanoseconds, irrespective of
>>> vxworks timebase.
>> That will work. The master timebase is always active and does return
>> nanoseconds
>> when inquired.
> 
> What instruction I use to get this time ? 
> I tried :
> 
> #include <native/timer.h>

#include <nucleus/timebase.h>, but that's not the point.

> xntbase_get_time(&nktbase);
> 
> But it doesn't work

It ought to work, otherwise nothing would. What's the issue? Unpected result?

-- 
Philippe.

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

[Matthieu]

On Mon, 07 Jul 2008 15:33:01 +0200, Philippe Gerum <rpm@xenomai.org> wrote:
> Matthieu wrote:
>> On Mon, 07 Jul 2008 13:45:36 +0200, Philippe Gerum <rpm@xenomai.org>
> wrote:
>>> 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.
>>>
>>
>> Sorry, it was a mistake from me, semaphores are used instead of
>> suspend/resume.
>>
>>>> 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.
>>>
>>
>> I need a clock to get the time with a 10 µs precision. I tought using
> this
>> master timebase, as it gives me a time in nanoseconds, irrespective of
>> vxworks timebase.
> 
> That will work. The master timebase is always active and does return
> nanoseconds
> when inquired.

What instruction I use to get this time ? 
I tried :

#include <native/timer.h>
xntbase_get_time(&nktbase);

But it doesn't work

> 
>>
>>> 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.
>>>
>>
>> You are right. It was un misunderstanding because I still don't know the
>> impact of tick_arg.
>> What you propose is very interesting. I's easier than what I tried to
> do.
>> xntbase_bind/unbind seems to be a good solution. I would like to know
> from
>> where I would be able to use these calls (kernel/user space) ?
> 
> Kernel space. If you need to relay requests to switch on/off timebase
> coupling
> from userland, then you just need your small RDM driver to do so, via
some
> ioctl
> command of your own.
> 
>> What I need is to select the simulation working mode (without the card)
> or
>> the PCI IRQ mode during the execution of my code (whose exectution is in
>> user space). If I'm working in simulation mode, I also need to specify
> the
>> tick period at the begining of the execution (1ms or 5ms).
>>
> 
> Then you will also need to change the period of the VxWorks timebase on
> the fly,
> using xntbase_update() when applicable.
> 
>>> --
>>> Philippe.
>>
>> Matthieu
>>
>>
>>
> 
> 
> --
> Philippe.

That great. Thank you for all

Matthieu

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

[Philippe Gerum]

Matthieu wrote:
> On Mon, 07 Jul 2008 13:45:36 +0200, Philippe Gerum <rpm@xenomai.org> wrote:
>> 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.
>>
> 
> Sorry, it was a mistake from me, semaphores are used instead of
> suspend/resume.
> 
>>> 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.
>>
> 
> I need a clock to get the time with a 10 µs precision. I tought using this
> master timebase, as it gives me a time in nanoseconds, irrespective of
> vxworks timebase. 

That will work. The master timebase is always active and does return nanoseconds
when inquired.

> 
>> 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.
>>
> 
> You are right. It was un misunderstanding because I still don't know the
> impact of tick_arg.
> What you propose is very interesting. I's easier than what I tried to do.
> xntbase_bind/unbind seems to be a good solution. I would like to know from
> where I would be able to use these calls (kernel/user space) ?

Kernel space. If you need to relay requests to switch on/off timebase coupling
from userland, then you just need your small RDM driver to do so, via some ioctl
command of your own.

> What I need is to select the simulation working mode (without the card) or
> the PCI IRQ mode during the execution of my code (whose exectution is in
> user space). If I'm working in simulation mode, I also need to specify the
> tick period at the begining of the execution (1ms or 5ms).
> 

Then you will also need to change the period of the VxWorks timebase on the fly,
using xntbase_update() when applicable.

>> --
>> Philippe.
> 
> Matthieu
> 
> 
> 


-- 
Philippe.

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

[Matthieu]

On Mon, 07 Jul 2008 13:45:36 +0200, Philippe Gerum <rpm@xenomai.org> wrote:
> 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.
> 

Sorry, it was a mistake from me, semaphores are used instead of
suspend/resume.

>>
>> 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.
>

I need a clock to get the time with a 10 µs precision. I tought using this
master timebase, as it gives me a time in nanoseconds, irrespective of
vxworks timebase. 

> 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.
> 

You are right. It was un misunderstanding because I still don't know the
impact of tick_arg.
What you propose is very interesting. I's easier than what I tried to do.
xntbase_bind/unbind seems to be a good solution. I would like to know from
where I would be able to use these calls (kernel/user space) ?
What I need is to select the simulation working mode (without the card) or
the PCI IRQ mode during the execution of my code (whose exectution is in
user space). If I'm working in simulation mode, I also need to specify the
tick period at the begining of the execution (1ms or 5ms).

> --
> Philippe.

Matthieu

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

[Philippe Gerum]

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.

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

[Matthieu]

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...

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. 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. I'm going
to test your modifications. Thank you for that.

I will also need to get a precise time, and Gilles suggest me to use
xntbase, but xntbase_get_time(&nktbase); isn't recognized. I will see more
information in the timebase programming documentation I think.
(http://www.xenomai.org/documentation/branches/v2.4.x/html/api/group__timebase.html
?)

I hope these information will help you in understanding what i want to
archieve.

Thank you again for you help

Matthieu

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

[Philippe Gerum]

Matthieu wrote:
> Hi
> 
> As I have no answer to my questions, I would like to know if you have any
> solution ?
> 

Nobody answered likely because nobody actually understands what you are trying
to achieve, at least it is still vastly unclear to me. You will find a somewhat
fixed version below; this said, using a periodic RTDM task to do that does not
bring much value, except perhaps to demonstrate the use of decoupled timebases.

What has been suggested earlier was to use RTDM to relay tick forwarding
requests from a userland process to pace the VxWorks skin in kernel space (e.g.
using ioctl calls).

Again: read the timebase programming documentation to have a clearer view of the
timer core internals.

--- orig.c	2008-07-07 09:36:01.000000000 +0200
+++ frags/tickoverride/module.c	2008-07-07 09:33:52.000000000 +0200
@@ -5,7 +5,7 @@
 struct drv_context {
 };

-long tick_period=1;
+long tick_period=100000000;

 // RT_TASK vxworks_tick_task;
 rtdm_task_t vxworks_tick_task;
@@ -29,31 +29,31 @@
 /**********************************************************/
 /*            DRIVER OPEN                                 */
 /**********************************************************/
-void open_rt(struct rtdm_dev_context    *context,
+int open_rt(struct rtdm_dev_context    *context,
                  rtdm_user_info_t           *user_info,
                  int                        oflags)
 {
-
+  return 0;
 }

 /**********************************************************/
 /*            DRIVER CLOSE                                */
 /**********************************************************/
-void close_rt(struct rtdm_dev_context   *context,
+int close_rt(struct rtdm_dev_context   *context,
                   rtdm_user_info_t          *user_info)
 {
-
+  return 0;
 }

 /**********************************************************/
 /*            DRIVER IOCTL                                */
 /**********************************************************/
-void ioctl_rt(struct rtdm_dev_context   *context,
+int ioctl_rt(struct rtdm_dev_context   *context,
                   rtdm_user_info_t          *user_info,
-                  int                       request,
+                  unsigned                  request,
                   void                      *arg)
 {
-
+  return 0;
 }


@@ -103,11 +103,19 @@
     proc_name:          tick_driver.device_name,
 };

+extern xntbase_t *wind_tbase;
+
 /**********************************************************/
 /*            INIT DRIVER                                 */
 /**********************************************************/
 int init_module(void)
 {
+    int ret;
+
+    ret = xntbase_switch("vxworks", tick_period, &wind_tbase);
+    if (ret)
+        return ret;
+
     rtdm_dev_register(&tick_driver);
     rtdm_task_init(&vxworks_tick_task, "vxworks_tick_task", &vxworks_tick,
 NULL, 99, 0);
{rpm@xenomai.org} diff -u orig.c frags/tickoverride/module.c
--- orig.c	2008-07-07 09:36:01.000000000 +0200
+++ frags/tickoverride/module.c	2008-07-07 09:33:52.000000000 +0200
@@ -5,7 +5,7 @@
 struct drv_context {
 };

-long tick_period=1;
+long tick_period=100000000;

 // RT_TASK vxworks_tick_task;
 rtdm_task_t vxworks_tick_task;
@@ -29,31 +29,31 @@
 /**********************************************************/
 /*            DRIVER OPEN                                 */
 /**********************************************************/
-void open_rt(struct rtdm_dev_context    *context,
+int open_rt(struct rtdm_dev_context    *context,
                  rtdm_user_info_t           *user_info,
                  int                        oflags)
 {
-
+  return 0;
 }

 /**********************************************************/
 /*            DRIVER CLOSE                                */
 /**********************************************************/
-void close_rt(struct rtdm_dev_context   *context,
+int close_rt(struct rtdm_dev_context   *context,
                   rtdm_user_info_t          *user_info)
 {
-
+  return 0;
 }

 /**********************************************************/
 /*            DRIVER IOCTL                                */
 /**********************************************************/
-void ioctl_rt(struct rtdm_dev_context   *context,
+int ioctl_rt(struct rtdm_dev_context   *context,
                   rtdm_user_info_t          *user_info,
-                  int                       request,
+                  unsigned                  request,
                   void                      *arg)
 {
-
+  return 0;
 }


@@ -103,11 +103,19 @@
     proc_name:          tick_driver.device_name,
 };

+extern xntbase_t *wind_tbase;
+
 /**********************************************************/
 /*            INIT DRIVER                                 */
 /**********************************************************/
 int init_module(void)
 {
+    int ret;
+
+    ret = xntbase_switch("vxworks", tick_period, &wind_tbase);
+    if (ret)
+        return ret;
+
     rtdm_dev_register(&tick_driver);
     rtdm_task_init(&vxworks_tick_task, "vxworks_tick_task", &vxworks_tick,
 NULL, 99, 0);

-- 
Philippe.

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

[Matthieu]

Hi

As I have no answer to my questions, I would like to know if you have any
solution ?

Thank you in advance

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

[Matthieu]

I tried an other code, but I didn't succeed too. Can anybody help me ?

here is my code :


#include <rtdm/rtdm_driver.h>
#include <vxworks/vxworks.h>

// our driver context struct: used for storing various information
struct drv_context {
};

long tick_period=1;

// RT_TASK vxworks_tick_task;
rtdm_task_t vxworks_tick_task;


/************************************************************/
/*Tache temps rel priodique, qui tick le scheduler vxworks*/
/************************************************************/
void vxworks_tick(void *arg)
{
	while (1) {
		// dort pendant tick_periode ms
		rtdm_task_sleep(tick_period*1000000);
		// tick le scheduler vxworks
		tickAnnounce();
		// rtdm_printk("TickAnnounce\n");
        }
}


/**********************************************************/
/*            DRIVER OPEN                                 */
/**********************************************************/
void open_rt(struct rtdm_dev_context    *context,
                 rtdm_user_info_t           *user_info,
                 int                        oflags)
{

}

/**********************************************************/
/*            DRIVER CLOSE                                */
/**********************************************************/
void close_rt(struct rtdm_dev_context   *context,
                  rtdm_user_info_t          *user_info)
{

}

/**********************************************************/
/*            DRIVER IOCTL                                */
/**********************************************************/
void ioctl_rt(struct rtdm_dev_context   *context,
                  rtdm_user_info_t          *user_info,
                  int                       request,
                  void                      *arg)
{
 
}


/**********************************************************/
/*            DRIVER OPERATIONS                           */
/**********************************************************/
static struct rtdm_device tick_driver = {
    struct_version:     RTDM_DEVICE_STRUCT_VER,

    device_flags:       RTDM_NAMED_DEVICE,
    context_size:       sizeof(struct drv_context),
    device_name:        "vxworks_tick_mod0",

/* open and close functions are not real-time safe due kmalloc
   and kfree. If you do not use kmalloc and kfree, and you made
   sure that there is no syscall in the open/close handler, you
   can declare the open_rt and close_rt handler.
*/
    open_rt:            open_rt,
    open_nrt:           NULL,

    ops: {
        close_rt:       close_rt,
        close_nrt:      close_rt,

        ioctl_rt:       ioctl_rt,
        ioctl_nrt:      NULL,

        read_rt:        NULL,
        read_nrt:       NULL,

        write_rt:       NULL,
        write_nrt:      NULL,

        recvmsg_rt:     NULL,
        recvmsg_nrt:    NULL,

        sendmsg_rt:     NULL,
        sendmsg_nrt:    NULL,
    },

    device_class:       RTDM_CLASS_EXPERIMENTAL,
    device_sub_class:   222,
    driver_name:        "vxworks_tick_mod",
    peripheral_name:    "vxworks_tick_mod",
    provider_name:      "-",
    proc_name:          tick_driver.device_name,
};

/**********************************************************/
/*            INIT DRIVER                                 */
/**********************************************************/
int init_module(void)
{
    rtdm_dev_register(&tick_driver);
    rtdm_task_init(&vxworks_tick_task, "vxworks_tick_task", &vxworks_tick,
NULL, 99, 0);
    return 0; 
}

/**********************************************************/
/*            CLEANUP DRIVER                              */
/**********************************************************/
void cleanup_module(void)
{
    rtdm_task_destroy(&vxworks_tick_task);
    rtdm_dev_unregister(&tick_driver, 1000);
}



Matthieu.

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

[Matthieu]

Hi,

I finally succeed in using tick_arg=0 : The use of a watchdog (wdStart) is
a goog test to show the effect of tick_arg. With tick_arg=0, the watchdog
doesn't start the specified routine as no tick has elapsed. When
tick_arg=0, I really think that taskDelay and tickGet or tickSet
instructions don't use the ticks anymore but a timer for time arguments or
returns. For my application, it doesn't matter anyway. I only need
watchdogs.

As Philippe suggest me, I tried a tiny RTDM driver, but tickAnnouce()
doesn't works. Here is the code of my RTDM driver. Could you tell me what
doesn't work ?


#include <linux/module.h>
#include <linux/init.h>
#include <linux/fs.h>
#include <vxworks/vxworks.h>
#include <rtdm/rtdm_driver.h>

static int major = 0;
int tick_period = 1; // dure d'un tick par dfaut en ms

// RT_TASK vxworks_tick_task;
rtdm_task_t vxworks_tick_task;

/* Tache temps reel priodique, qui tick le scheduler vxworks */
void vxworks_tick(void *arg)
{
        while (1) {
		// dort pendant tick_periode ms
		rtdm_task_sleep(tick_period*1000000);
		// tick le scheduler vxworks
		tickAnnounce();
        }
}

/* ioctl qui permet d'envoyer a la tache temps reel priodique la valeur de
la priode (en ms) */
static int my_ioctl_function(struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg)
{
	//recupere la priode
	tick_period = cmd;
	printk(KERN_DEBUG "vxworks_tick_mod : modification de la dure d'un tick :
%d ms\n",tick_period);
	return 0;
}

static struct file_operations fops =
{
	ioctl : my_ioctl_function
};

static int __init vxworks_tick_mod_init (void)
{
	int ret;
	int err;
	ret = register_chrdev(major,"vxworks_tick_mod", &fops);
	if (ret < 0)
	{
		printk(KERN_WARNING "vxworks_tick_mod : Problme sur le major\n");
	}
	printk(KERN_DEBUG "vxworks_tick_mod : Module charg !\n");
	err = rtdm_task_init(&vxworks_tick_task, "vxworks_tick_task",
&vxworks_tick, NULL, 99, 0);
	if (err) {
    		printk("vxworks_tick_mod: error rt_task_spawn\n");
    		return 0;
  	}
	return 0;
}

static void __exit vxworks_tick_mod_exit(void)
{
	int ret;
	unregister_chrdev(major, "vxworks_tick_mod");
	rtdm_task_destroy(&vxworks_tick_task);
	printk(KERN_DEBUG "vxworks_tick_mod : Module dcharg !\n");
}

module_init(vxworks_tick_mod_init);
module_exit(vxworks_tick_mod_exit);



Thank you in advance

Matthieu

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

[Matthieu]

Hi

Do I have to understand that with no tick taskDelay(xxx) wait xxx
nanoseconds ?

Well, I've made other tests, and it's a little confuse to me because I try
tickGet() instruction when tick_arg=0 and the result is that tickGet give
me an inceasing number, while I should have been a fixe value. Is it the
same think : tickGet get nanosecond time since epoch ? I really need to
know if I can use tick_arg=0 and tickAnnounce to have a manual tick, in
order to use watchdog (wdStart which takes as arguments the number of ticks
to delay is going to use nanoseconds ?)

Thak you in advance

Matthieu


On Tue, 24 Jun 2008 19:10:24 +0200, Matthieu
<matthieu.connaulte_xenomai@domain.hid> wrote:
> On Tue, 24 Jun 2008 18:40:51 +0200, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> Matthieu wrote:
>>>
>>> On Tue, 24 Jun 2008 16:27:42 +0200, Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>> Matthieu wrote:
>>>>> Let me know if I've done something wrong ...
>>>> rt_timer_read belongs to the native skin, not to the vxworks skin !
>>>>
>>>> --
>>>>                                                   Gilles.
>>>
>>> Ok, but I don't really see why does mixing vxworks task with a xenomai
>>> instruction that not depends on vxworks scheduler is a problem. if I
>> just
>>> get time, does the task switch to xenomai scheduler ?. However, if it's
>>> really a problem, what can I use to get a pricise time, as I can't use
>>> getTick anymore. Philippe suggested xntbase time base services ?
>>
>> You can use rt_timer_read(), but you should not assume that this returns
>> a nanoseconds count, this depends on the timing configuration of the
>> native skin.
>>
>> --
>>
>                                            Gilles.
> Ok, but in fact, that's not my problem : I don't understand why the loop
> doesn't stop on taskDelay(1), as there is no tick on vxworks scheduler
> (due
> to tick_arg=0) ?
> 
> Matthieu
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

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

[Matthieu]

On Tue, 24 Jun 2008 19:10:24 +0200, Matthieu
<matthieu.connaulte_xenomai@domain.hid> wrote:
> On Tue, 24 Jun 2008 18:40:51 +0200, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> Matthieu wrote:
>>>
>>> On Tue, 24 Jun 2008 16:27:42 +0200, Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>> Matthieu wrote:
>>>>> Let me know if I've done something wrong ...
>>>> rt_timer_read belongs to the native skin, not to the vxworks skin !
>>>>
>>>> --
>>>>                                                   Gilles.
>>>
>>> Ok, but I don't really see why does mixing vxworks task with a xenomai
>>> instruction that not depends on vxworks scheduler is a problem. if I
>> just
>>> get time, does the task switch to xenomai scheduler ?. However, if it's
>>> really a problem, what can I use to get a pricise time, as I can't use
>>> getTick anymore. Philippe suggested xntbase time base services ?
>>
>> You can use rt_timer_read(), but you should not assume that this returns
>> a nanoseconds count, this depends on the timing configuration of the
>> native skin.
>>
>> --
>>
>                                            Gilles.
> Ok, but in fact, that's not my problem : I don't understand why the loop
> doesn't stop on taskDelay(1), as there is no tick on vxworks scheduler
> (due
> to tick_arg=0) ?
> 
> Matthieu
> 
> 

I've tested a programme with a task that suspend itself, and a main loop
that resume the task when it is suspended. The task has to be rescheldue to
continue its execution but the tick_arg value has no influence on the time
the task waits for rescheduling. That's make me think the vxworks scheduler
isn't rhythmed by this tick. Could you explain me what's going on ?

thank you in advance

Matthieu

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

[Matthieu]

On Tue, 24 Jun 2008 18:40:51 +0200, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Matthieu wrote:
>>
>> On Tue, 24 Jun 2008 16:27:42 +0200, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> Matthieu wrote:
>>>> Let me know if I've done something wrong ...
>>> rt_timer_read belongs to the native skin, not to the vxworks skin !
>>>
>>> --
>>>                                                   Gilles.
>>
>> Ok, but I don't really see why does mixing vxworks task with a xenomai
>> instruction that not depends on vxworks scheduler is a problem. if I
> just
>> get time, does the task switch to xenomai scheduler ?. However, if it's
>> really a problem, what can I use to get a pricise time, as I can't use
>> getTick anymore. Philippe suggested xntbase time base services ?
> 
> You can use rt_timer_read(), but you should not assume that this returns
> a nanoseconds count, this depends on the timing configuration of the
> native skin.
> 
> --
>       
                                           Gilles.
Ok, but in fact, that's not my problem : I don't understand why the loop
doesn't stop on taskDelay(1), as there is no tick on vxworks scheduler (due
to tick_arg=0) ?

Matthieu

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

[Gilles Chanteperdrix]

Matthieu wrote:
> 
> On Tue, 24 Jun 2008 16:27:42 +0200, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> Matthieu wrote:
>>> Let me know if I've done something wrong ...
>> rt_timer_read belongs to the native skin, not to the vxworks skin !
>>
>> --
>>                                                   Gilles.
> 
> Ok, but I don't really see why does mixing vxworks task with a xenomai
> instruction that not depends on vxworks scheduler is a problem. if I just
> get time, does the task switch to xenomai scheduler ?. However, if it's
> really a problem, what can I use to get a pricise time, as I can't use
> getTick anymore. Philippe suggested xntbase time base services ?

You can use rt_timer_read(), but you should not assume that this returns
a nanoseconds count, this depends on the timing configuration of the
native skin.

-- 
                                                 Gilles.

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

[Matthieu]

Hi

I encounter a problem. I patch my xeno_vxworks module. It seem's working
well. But the result doesn't seem to be the one looked for. In fact, I
create a vxworks task that enter in a while loop and give me the time spend
to the next tick using taskDelay(1). Here is the code of my task :

#include <vxworks/vxworks.h>
#include <native/timer.h>
#include <stdio.h>
#include <sys/mman.h>

long tid;

void tick_value(void *cookie){
	RTIME now, previous;
	long tick;
	previous = rt_timer_read();
	while (1) {
		now = rt_timer_read();
		tick = (long)((now - previous));
		printf("Duree du tick : %1ld,%06ld ms\n",tick/1000000,tick%1000000);
                  previous = now;
		taskDelay(1);
	}
}

void clean_exit(int dummy) {
  taskDelete(tid);
}

int main(int argc, char* argv[])
{
	mlockall(MCL_CURRENT | MCL_FUTURE);
	tid = taskSpawn ( "tick", 100, 0x100, 2000,( FUNCPTR)tick_value, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0);
	pause();
	fflush(NULL);
	return 0;
}

When I use modprobe xeno_vxworks tick_arg=3D1000, I have a 1ms tick period,
so that's good.
What I expected is that with a tick_arg=3D0, taskDelay(1) suspend my task
until an announceTick come. But when I execute my task, taskDelay doesn't
wait. I think that the scheduler is always ruuning : I have a minimum tick
period around 10 =C2=B5s (limitation due to the changing context from
printf I think).

Let me know if I've done something wrong ...

Matthieu

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

[Matthieu]

On Mon, 23 Jun 2008 19:18:19 +0200, Philippe Gerum <rpm@xenomai.org> wrote:
> Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Philippe Gerum wrote:
>>>>> Matthieu wrote:
>>>>>
>>>>>> I have a segmentation fault error when I use modprobe xeno_vxworks
>>>>>> tick_arg=0 (tick_arg=1000 works)
>>>>>>
>>>>> Any kernel log?
>>>>>
>>>> wind_sysclk_init uses its argument for a division.
>>>>
>>> --- ksrc/skins/vxworks/sysLib.c	(revision 3975)
>>> +++ ksrc/skins/vxworks/sysLib.c	(working copy)
>>> @@ -39,12 +39,12 @@
>>>  int wind_sysclk_init(u_long period)
>>>  {
>>>  	extern u_long sync_time;
>>> -	u_long init_rate = ONE_BILLION / period;
>>> +	u_long init_rate = period ? ONE_BILLION / period : XN_APERIODIC_TICK;
>>>  	int err;
>>>
>>>  	err = xntbase_alloc("vxworks", period, sync_time ? 0 : XNTBISO,
>>>  			    &wind_tbase);
>>> -	if (err)
>>> +	if (err || period == 0)
>>>  		return err;
>>>
>>>  	err = sysClkRateSet(init_rate);
>>
>> Ok, but what about sysClkRateGet then ? It is needed for conversion
>> between durations and ticks count. It will not work since sysClkRateSet
>> was not called, and we can not call sysClkRateSet since it would start
>> the timer.
>>
>>
> 
> We don't have to care about this. If people want to override the system
> timer,
> then they should deal with the xntbase interface themselves. What is
> provided is
> a mean to disable internal timing so that it does not conflict with the
> user-provided stuff, nothing more.
> 
> --
> Philippe.
> 

Thank you for all, I'll test it tomorrow. I understand that these
modifications are sufficient and I will have no problem with "modprobe
xeno_vxworks tick_arg=0" command and with tickAnnounce vxworks scheduler in
my own rtdm linux module driver. (I'm about using a rtdm driver as Philippe
suggest me, directly in a rtdm_irq_handler_t interrupt handler).

Matthieu

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

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> Gilles Chanteperdrix wrote:
>>> Philippe Gerum wrote:
>>>> Matthieu wrote:
>>>>
>>>>> I have a segmentation fault error when I use modprobe xeno_vxworks
>>>>> tick_arg=0 (tick_arg=1000 works)
>>>>>
>>>> Any kernel log?
>>>>
>>> wind_sysclk_init uses its argument for a division.
>>>
>> --- ksrc/skins/vxworks/sysLib.c	(revision 3975)
>> +++ ksrc/skins/vxworks/sysLib.c	(working copy)
>> @@ -39,12 +39,12 @@
>>  int wind_sysclk_init(u_long period)
>>  {
>>  	extern u_long sync_time;
>> -	u_long init_rate = ONE_BILLION / period;
>> +	u_long init_rate = period ? ONE_BILLION / period : XN_APERIODIC_TICK;
>>  	int err;
>>
>>  	err = xntbase_alloc("vxworks", period, sync_time ? 0 : XNTBISO,
>>  			    &wind_tbase);
>> -	if (err)
>> +	if (err || period == 0)
>>  		return err;
>>
>>  	err = sysClkRateSet(init_rate);
> 
> Ok, but what about sysClkRateGet then ? It is needed for conversion
> between durations and ticks count. It will not work since sysClkRateSet
> was not called, and we can not call sysClkRateSet since it would start
> the timer.
> 
> 

We don't have to care about this. If people want to override the system timer,
then they should deal with the xntbase interface themselves. What is provided is
a mean to disable internal timing so that it does not conflict with the
user-provided stuff, nothing more.

-- 
Philippe.

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

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>>> Matthieu wrote:
>>>
>>>> I have a segmentation fault error when I use modprobe xeno_vxworks
>>>> tick_arg=0 (tick_arg=1000 works)
>>>>
>>> Any kernel log?
>>>
>> wind_sysclk_init uses its argument for a division.
>>
> 
> --- ksrc/skins/vxworks/sysLib.c	(revision 3975)
> +++ ksrc/skins/vxworks/sysLib.c	(working copy)
> @@ -39,12 +39,12 @@
>  int wind_sysclk_init(u_long period)
>  {
>  	extern u_long sync_time;
> -	u_long init_rate = ONE_BILLION / period;
> +	u_long init_rate = period ? ONE_BILLION / period : XN_APERIODIC_TICK;
>  	int err;
> 
>  	err = xntbase_alloc("vxworks", period, sync_time ? 0 : XNTBISO,
>  			    &wind_tbase);
> -	if (err)
> +	if (err || period == 0)
>  		return err;
> 
>  	err = sysClkRateSet(init_rate);
> 

Ok, but what about sysClkRateGet then ? It is needed for conversion
between durations and ticks count. It will not work since sysClkRateSet
was not called, and we can not call sysClkRateSet since it would start
the timer.



-- 
                                                 Gilles.

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

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> Matthieu wrote:
>>
>>> I have a segmentation fault error when I use modprobe xeno_vxworks
>>> tick_arg=0 (tick_arg=1000 works)
>>>
>> Any kernel log?
>>
> 
> wind_sysclk_init uses its argument for a division.
> 

--- ksrc/skins/vxworks/sysLib.c	(revision 3975)
+++ ksrc/skins/vxworks/sysLib.c	(working copy)
@@ -39,12 +39,12 @@
 int wind_sysclk_init(u_long period)
 {
 	extern u_long sync_time;
-	u_long init_rate = ONE_BILLION / period;
+	u_long init_rate = period ? ONE_BILLION / period : XN_APERIODIC_TICK;
 	int err;

 	err = xntbase_alloc("vxworks", period, sync_time ? 0 : XNTBISO,
 			    &wind_tbase);
-	if (err)
+	if (err || period == 0)
 		return err;

 	err = sysClkRateSet(init_rate);

-- 
Philippe.

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

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> Matthieu wrote:
> 
>> I have a segmentation fault error when I use modprobe xeno_vxworks
>> tick_arg=0 (tick_arg=1000 works)
>>
> 
> Any kernel log?
> 

wind_sysclk_init uses its argument for a division.

-- 
                                                 Gilles.

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

[Philippe Gerum]

Matthieu wrote:

> I have a segmentation fault error when I use modprobe xeno_vxworks
> tick_arg=0 (tick_arg=1000 works)
> 

Any kernel log?

-- 
Philippe.

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

[Philippe Gerum]

Matthieu wrote:
> Hi
> 
> I would like to know if there is a sheduler per CPUs or one scheduler for
> all CPUs ? I understand that there is one sheduler per skin for all CPUs,
> so it's only to be sure...

One global scheduler, per-CPU scheduling runqueues, per-skin timing obtained
through separate time bases, see /proc/xenomai/timebases. The reason why we have
time bases is documented:
http://www.xenomai.org/documentation/branches/v2.4.x/html/api/group__timebase.html

> 
> Well, my application has two working mode. One with a PCI hardware that
> send an interrupt to tickAnnounce the Scheduler ; one with no hardware and
> something that will simulate this hardware interrupt (something like a
> periodic xenomai real-time task that send this same interrupt). So I need
> to use an interrupt to tickAnnounce vxworks scheduler. I think that I have
> to disabe the periodic tick (but I don't know how), and I need an interrupt
> handler that send a tickAnnounce. It is during the execution that the
> presence of the PCI hardware is tested and whether a hardware interrupt or
> software interrupt is used. Can somebody explain me if it's possible, and
> in that case, how can I disable the automatic vxworks tick ?
>

modprobe xeno_vxworks tick_arg=0

> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 
Philippe.

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

[Matthieu]

Hi

I would like to know if there is a sheduler per CPUs or one scheduler for
all CPUs ? I understand that there is one sheduler per skin for all CPUs,
so it's only to be sure...

Well, my application has two working mode. One with a PCI hardware that
send an interrupt to tickAnnounce the Scheduler ; one with no hardware and
something that will simulate this hardware interrupt (something like a
periodic xenomai real-time task that send this same interrupt). So I need
to use an interrupt to tickAnnounce vxworks scheduler. I think that I have
to disabe the periodic tick (but I don't know how), and I need an interrupt
handler that send a tickAnnounce. It is during the execution that the
presence of the PCI hardware is tested and whether a hardware interrupt or
software interrupt is used. Can somebody explain me if it's possible, and
in that case, how can I disable the automatic vxworks tick ?

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

[Gilles Chanteperdrix]

Matthieu wrote:
 > So, do I have to understand that all skins have their own scheduler ?
 > To schedule at 1ms, the instriction tickSet(1000) seems to works but
 > specifying option tick_arg=1000 to xeno_vxworks module doesn't ! I thing
 > that I do it in a bad way, endeed I added "options xeno_vxworks
 > tick_arg=1000" to /etc/modprobe.conf/local ... (In fact I must add this
 > module manually, it isn't loaded automatically while a vxworks instruction
 > need to execute).

I already answered this mail. You will find my answer in the mailing
list archives here:
https://mail.gna.org/public/xenomai-help/2008-06/msg00063.html

-- 


					    Gilles.

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

[Gilles Chanteperdrix]

On Wed, Jun 11, 2008 at 11:18 AM, Matthieu
<matthieu.connaulte_xenomai@domain.hid> wrote:
> So, do I have to understand that all skins have their own scheduler ?

Starting with Xenomai 2.4, every skin has its own tick source, yes.

> To schedule at 1ms, specifying option tick_arg=1000 to xeno_vxworks module
> doesn't ! I thing
> that I do it in a bad way, endeed I added "options xeno_vxworks
> tick_arg=1000" to /etc/modprobe.conf/local ... (In fact I must add this
> module manually, it isn't loaded automatically while a vxworks instruction
> need to execute).

We never even thought about auto module loading usually people know
which module they need. Note that it seems that the module
auto-loading feature is somewhat deprecated by kernel people, since it
is now possible to disable it, and the udev daemon loads all possible
modules at boot time instead of waiting that a module is really needed
before loading it, thereby killing module auto-loading.

However you should note that /etc/modprobe.conf/something will only
work if you use "modprobe" to load module. If you use insmod, the
arguments should be passed on insmod command line.

If you use modprobe and the tick_arg parameter does not work, could
you post the example program showing the issue you met?

-- 
 Gilles

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

[Matthieu]

So, do I have to understand that all skins have their own scheduler ?
To schedule at 1ms, specifying option tick_arg=1000 to xeno_vxworks module
doesn't ! I thing
that I do it in a bad way, endeed I added "options xeno_vxworks
tick_arg=1000" to /etc/modprobe.conf/local ... (In fact I must add this
module manually, it isn't loaded automatically while a vxworks instruction
need to execute).

Matthieu

On Tue, 10 Jun 2008 11:43:39 +0200, "Gilles Chanteperdrix"
<gilles.chanteperdrix@xenomai.org> wrote:
> On Tue, Jun 10, 2008 at 10:43 AM, Matthieu
> <matthieu.connaulte_xenomai@domain.hid> wrote:
>> Hi
>>
>> Is it possible to change the value of the xenomai scheduler's ticks
> period
>> ? I would like the tasks to be scheduled each 1 millisecond for exemple.
> I
>> found out xnpod_tick_announce, but I didn't find any documentation and I
>> didn't find the sources.
>
> Xenomai scheduler has no tick period. If you want, you may change a
> skin period, either by using Kconfig options, or by using module
> parameters. You will find documentation about the module parameters
> either by using modinfo or in the text file documenting the skin you
> want to use.
>
> --
>  Gilles

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

[Matthieu]

So, do I have to understand that all skins have their own scheduler ?
To schedule at 1ms, the instriction tickSet(1000) seems to works but
specifying option tick_arg=1000 to xeno_vxworks module doesn't ! I thing
that I do it in a bad way, endeed I added "options xeno_vxworks
tick_arg=1000" to /etc/modprobe.conf/local ... (In fact I must add this
module manually, it isn't loaded automatically while a vxworks instruction
need to execute).

Matthieu

On Tue, 10 Jun 2008 11:43:39 +0200, "Gilles Chanteperdrix"
<gilles.chanteperdrix@xenomai.org> wrote:
> On Tue, Jun 10, 2008 at 10:43 AM, Matthieu
> <matthieu.connaulte_xenomai@domain.hid> wrote:
>> Hi
>>
>> Is it possible to change the value of the xenomai scheduler's ticks
> period
>> ? I would like the tasks to be scheduled each 1 millisecond for exemple.
> I
>> found out xnpod_tick_announce, but I didn't find any documentation and I
>> didn't find the sources.
> 
> Xenomai scheduler has no tick period. If you want, you may change a
> skin period, either by using Kconfig options, or by using module
> parameters. You will find documentation about the module parameters
> either by using modinfo or in the text file documenting the skin you
> want to use.
> 
> --
>  Gilles

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

[Gilles Chanteperdrix]

On Tue, Jun 10, 2008 at 10:43 AM, Matthieu
<matthieu.connaulte_xenomai@domain.hid> wrote:
> Hi
>
> Is it possible to change the value of the xenomai scheduler's ticks period
> ? I would like the tasks to be scheduled each 1 millisecond for exemple. I
> found out xnpod_tick_announce, but I didn't find any documentation and I
> didn't find the sources.

Xenomai scheduler has no tick period. If you want, you may change a
skin period, either by using Kconfig options, or by using module
parameters. You will find documentation about the module parameters
either by using modinfo or in the text file documenting the skin you
want to use.

-- 
 Gilles

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

[Matthieu]

Well I have to specify a little. My current vxworks application uses
tickAnounce() on an interrupt clock handler. I see that this routine is
implemented is vxworks skin. Moreover, I'm sure that tickAnnouce is the
only way the scheduler is swinging over my PPC. What I have to do is to get
a hardware interrupt, or I have simulate a hardware interrupt.
Concerning the hardware interrupt, I don't really see what can I use.
Concerning the simulation, I think about creating a periodical xenomai
rt_task. But the problem is what is the influence of tickAnnouce over this
task ? Is there differencies running task over different CPUs ? How can I
be sure vxworks tasks are scheduled with tickAnnouce and Xenomai task are
schedule normally ?

matthieu

On Tue, 10 Jun 2008 10:43:13 +0200, Matthieu
<matthieu.connaulte_xenomai@domain.hid> wrote:
> Hi
> 
> Is it possible to change the value of the xenomai scheduler's ticks
period
> ? I would like the tasks to be scheduled each 1 millisecond for exemple.
I
> found out xnpod_tick_announce, but I didn't find any documentation and I
> didn't find the sources.
> 
> Thank you in advence
> 
> Matthieu

[Xenomai-help] xenomai scheduler's ticks period

[Matthieu]

Hi

Is it possible to change the value of the xenomai scheduler's ticks period
? I would like the tasks to be scheduled each 1 millisecond for exemple. I
found out xnpod_tick_announce, but I didn't find any documentation and I
didn't find the sources.

Thank you in advence

Matthieu