[Xenomai-core] 2.4.32 compilation error + old timer example problem

[Xenomai-core] 2.4.32 compilation error + old timer example problem

[Hannes Mayer]

I checked out xeno.trunk just a few minutes ago.
With kernel 2.4.32, kernel compilation fails with this:

mq.c: In function `mq_notify':
mq.c:475: error: `SIGEV_SIVNAL' undeclared (first use in this function)
mq.c:475: error: (Each undeclared identifier is reported only once
mq.c:475: error: for each function it appears in.)

kernel/xenomai/skins/posix/mq.c
SIGEV_SIVNAL => SIGEV_SIGNAL

..with that it succeeds.

But still my timer example doesn't work - see:
https://mail.gna.org/public/xenomai-help/2005-12/msg00020.html

With 2.6.14.3 it works...

Thanks for any hints, Happy New Year,
Hannes.

Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

Hannes Mayer wrote:
> I checked out xeno.trunk just a few minutes ago.
> With kernel 2.4.32, kernel compilation fails with this:
> 
> mq.c: In function `mq_notify':
> mq.c:475: error: `SIGEV_SIVNAL' undeclared (first use in this function)
> mq.c:475: error: (Each undeclared identifier is reported only once
> mq.c:475: error: for each function it appears in.)
> 
> kernel/xenomai/skins/posix/mq.c
> SIGEV_SIVNAL => SIGEV_SIGNAL
> 
> ..with that it succeeds.
> 
> But still my timer example doesn't work - see:
> https://mail.gna.org/public/xenomai-help/2005-12/msg00020.html
> 

Is this problem only related to the periodic timer mode?

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem

[Hannes Mayer]

Hi Jan!

Jan Kiszka wrote:
> Hannes Mayer wrote:
> 
>>I checked out xeno.trunk just a few minutes ago.
>>With kernel 2.4.32, kernel compilation fails with this:
>>
>>mq.c: In function `mq_notify':
>>mq.c:475: error: `SIGEV_SIVNAL' undeclared (first use in this function)
>>mq.c:475: error: (Each undeclared identifier is reported only once
>>mq.c:475: error: for each function it appears in.)
>>
>>kernel/xenomai/skins/posix/mq.c
>>SIGEV_SIVNAL => SIGEV_SIGNAL
>>
>>..with that it succeeds.
>>
>>But still my timer example doesn't work - see:
>>https://mail.gna.org/public/xenomai-help/2005-12/msg00020.html
>>
> 
> 
> Is this problem only related to the periodic timer mode?

I've modified my example with rt_task_set_periodic as in the
rt_serial_uprog example
http://www.captain.at/xenomai-timer-task.php
and this variant is working.
I'm just curious why the original example (#2 on my page) suddenly
stopped working (rt_task_sleep seems to do nothing, so the messages
from the task are flooding the screen).

Thanks & best regards,
Hannes.

Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem

[Philippe Gerum]

Hannes Mayer wrote:
> Hi Jan!
> 
> Jan Kiszka wrote:
> 
>> Hannes Mayer wrote:
>>
>>> I checked out xeno.trunk just a few minutes ago.
>>> With kernel 2.4.32, kernel compilation fails with this:
>>>
>>> mq.c: In function `mq_notify':
>>> mq.c:475: error: `SIGEV_SIVNAL' undeclared (first use in this function)
>>> mq.c:475: error: (Each undeclared identifier is reported only once
>>> mq.c:475: error: for each function it appears in.)
>>>
>>> kernel/xenomai/skins/posix/mq.c
>>> SIGEV_SIVNAL => SIGEV_SIGNAL
>>>
>>> ..with that it succeeds.
>>>
>>> But still my timer example doesn't work - see:
>>> https://mail.gna.org/public/xenomai-help/2005-12/msg00020.html
>>>
>>
>>
>> Is this problem only related to the periodic timer mode?
> 
> 
> I've modified my example with rt_task_set_periodic as in the
> rt_serial_uprog example
> http://www.captain.at/xenomai-timer-task.php
> and this variant is working.
> I'm just curious why the original example (#2 on my page) suddenly
> stopped working (rt_task_sleep seems to do nothing, so the messages
> from the task are flooding the screen).

It would be nice to have the error codes possibly returned by 
rt_timer_start() and/or rt_task_sleep() if any.

-- 

Philippe.

Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]

Philippe Gerum wrote:
> Hannes Mayer wrote:
> 
>> Hi Jan!
>>
>> Jan Kiszka wrote:
>>
>>> Hannes Mayer wrote:
>>>
>>>> I checked out xeno.trunk just a few minutes ago.
>>>> With kernel 2.4.32, kernel compilation fails with this:
>>>>
>>>> mq.c: In function `mq_notify':
>>>> mq.c:475: error: `SIGEV_SIVNAL' undeclared (first use in this function)
>>>> mq.c:475: error: (Each undeclared identifier is reported only once
>>>> mq.c:475: error: for each function it appears in.)
>>>>
>>>> kernel/xenomai/skins/posix/mq.c
>>>> SIGEV_SIVNAL => SIGEV_SIGNAL
>>>>
>>>> ..with that it succeeds.
>>>>
>>>> But still my timer example doesn't work - see:
>>>> https://mail.gna.org/public/xenomai-help/2005-12/msg00020.html
>>>>
>>>
>>>
>>> Is this problem only related to the periodic timer mode?
>>
>>
>>
>> I've modified my example with rt_task_set_periodic as in the
>> rt_serial_uprog example
>> http://www.captain.at/xenomai-timer-task.php
>> and this variant is working.
>> I'm just curious why the original example (#2 on my page) suddenly
>> stopped working (rt_task_sleep seems to do nothing, so the messages
>> from the task are flooding the screen).
> 
> 
> It would be nice to have the error codes possibly returned by
> rt_timer_start() and/or rt_task_sleep() if any.
> 

Yea, maybe that periodic timer mode is not compiled in and
rt_timer_start fails in your original example. I think it's off by
default now.

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem

[Philippe Gerum]

Philippe Gerum wrote:
> Hannes Mayer wrote:
> 
>> Hi Jan!
>>
>> Jan Kiszka wrote:
>>
>>> Hannes Mayer wrote:
>>>
>>>> I checked out xeno.trunk just a few minutes ago.
>>>> With kernel 2.4.32, kernel compilation fails with this:
>>>>
>>>> mq.c: In function `mq_notify':
>>>> mq.c:475: error: `SIGEV_SIVNAL' undeclared (first use in this function)
>>>> mq.c:475: error: (Each undeclared identifier is reported only once
>>>> mq.c:475: error: for each function it appears in.)
>>>>
>>>> kernel/xenomai/skins/posix/mq.c
>>>> SIGEV_SIVNAL => SIGEV_SIGNAL
>>>>
>>>> ..with that it succeeds.
>>>>
>>>> But still my timer example doesn't work - see:
>>>> https://mail.gna.org/public/xenomai-help/2005-12/msg00020.html
>>>>
>>>
>>>
>>> Is this problem only related to the periodic timer mode?
>>
>>
>>
>> I've modified my example with rt_task_set_periodic as in the
>> rt_serial_uprog example
>> http://www.captain.at/xenomai-timer-task.php
>> and this variant is working.
>> I'm just curious why the original example (#2 on my page) suddenly
>> stopped working (rt_task_sleep seems to do nothing, so the messages
>> from the task are flooding the screen).
> 
> 
> It would be nice to have the error codes possibly returned by 
> rt_timer_start() and/or rt_task_sleep() if any.
> 

PS: the same goes for the calls involved in the message pipe related 
issue you recently posted and which is still pending in my log.

-- 

Philippe.

Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem

[Hannes Mayer]

Jan Kiszka wrote:
[...]
> Yea, maybe that periodic timer mode is not compiled in and
> rt_timer_start fails in your original example. I think it's off by
> default now.

Yeah, got it! Sorry for not supplying error code earlier!

In Xeno source:
int xnpod_start_timer (u_long nstick, xnisr_t tickhandler)
[...]
#ifndef CONFIG_XENO_HW_PERIODIC_TIMER
     if (nstick != XN_APERIODIC_TICK)
         return -ENODEV; /* No periodic support */
#endif /* CONFIG_XENO_HW_PERIODIC_TIMER */

..and guess what: I got -ENODEV back on rt_timer_start!

In .config I have
# CONFIG_XENO_HW_PERIODIC_TIMER is not set

So the puzzle is solved!

Just one question: what's the reason why the periodic mode
is disabled by default ?

Thanks & best regards,
Hannes.

Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem

[Philippe Gerum]

Hannes Mayer wrote:
> Jan Kiszka wrote:
> [...]
> 
>> Yea, maybe that periodic timer mode is not compiled in and
>> rt_timer_start fails in your original example. I think it's off by
>> default now.
> 
> 
> Yeah, got it! Sorry for not supplying error code earlier!
> 
> In Xeno source:
> int xnpod_start_timer (u_long nstick, xnisr_t tickhandler)
> [...]
> #ifndef CONFIG_XENO_HW_PERIODIC_TIMER
>     if (nstick != XN_APERIODIC_TICK)
>         return -ENODEV; /* No periodic support */
> #endif /* CONFIG_XENO_HW_PERIODIC_TIMER */
> 
> ..and guess what: I got -ENODEV back on rt_timer_start!
> 
> In .config I have
> # CONFIG_XENO_HW_PERIODIC_TIMER is not set
> 
> So the puzzle is solved!
> 
> Just one question: what's the reason why the periodic mode
> is disabled by default ?
>

Because AFAICT, most people would rather use the aperiodic timing mode 
in usual configurations for a much better accuracy. Since the periodic 
mode uses the available hw PIT and programs it once (or even some 
decrementer but without handling the time drift when reprogramming it 
after each shot), it suffers from cumulated rounding errors of the 
period. If you look at the jitter results of a trivial periodic loop 
over a broad timescale, you will see the wakeup time irremediably drift, 
whilst the average interval between shots remains stable and reasonably 
accurate. The periodic timer should be used for configurations that only 
need to enforce delays or timeouts, and not, well, precise timings.

> Thanks & best regards,
> Hannes.
> 


-- 

Philippe.

Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem

[Hannes Mayer]

Philippe Gerum wrote:
[...]
>> Just one question: what's the reason why the periodic mode
>> is disabled by default ?
>>
> 
> Because AFAICT, most people would rather use the aperiodic timing mode 
> in usual configurations for a much better accuracy. Since the periodic 
> mode uses the available hw PIT and programs it once (or even some 
> decrementer but without handling the time drift when reprogramming it 
> after each shot), it suffers from cumulated rounding errors of the 
> period. If you look at the jitter results of a trivial periodic loop 
> over a broad timescale, you will see the wakeup time irremediably drift, 
> whilst the average interval between shots remains stable and reasonably 
> accurate. The periodic timer should be used for configurations that only 
> need to enforce delays or timeouts, and not, well, precise timings.

Thanks Philippe!
If it's for accuracy, keep it that way!

Best regards,
Hannes.