[Xenomai-help] Handling irq

[Xenomai-help] Handling irq

[Bosko Radivojevic]

Hi,

First of all, is there any example for enabling, requesting & handling
IRQ from Xenomai (user-task or kernel-thread, nevermind)?

I'm using AT91SAM9260 based board. I have one peripheral connected to
PC12 pin of microcontroller. If wanted to do it from kernel module I
would do something like:
[..]
at91_set_gpio_input(AT91_PIN_PC12, 1);  // I want pullup
[..]
platform_device_register(..)
request_irq(irq, &myhandler, ...);

I quess it is OK to do at91_set_gpio_input() from kernel, but latter
should be done from Xenomai?

Kind regards,
Bosko

Re: [Xenomai-help] Handling irq

[Gilles Chanteperdrix]

On Tue, Mar 18, 2008 at 1:27 PM, Bosko Radivojevic
<bosko.radivojevic@domain.hid> wrote:
> Hi,
>
>  First of all, is there any example for enabling, requesting & handling
>  IRQ from Xenomai (user-task or kernel-thread, nevermind)?

There is an example in user-space, in ksrc/skins/native/snippets/user_irq.c

>
>  I'm using AT91SAM9260 based board. I have one peripheral connected to
>  PC12 pin of microcontroller. If wanted to do it from kernel module I
>  would do something like:
>  [..]
>  at91_set_gpio_input(AT91_PIN_PC12, 1);  // I want pullup
>  [..]
>  platform_device_register(..)
>  request_irq(irq, &myhandler, ...);
>
>  I quess it is OK to do at91_set_gpio_input() from kernel, but latter
>  should be done from Xenomai?

You can probably call at91_set_gpio_input from Xenomai context if it
does not use Linux spinlocks or fiddles with local interruptions, as
Philippe told you in a previous mail. platform_device_register is not
related with Xenomai, at all. request_irq should be replaced with a
Xenomai call, you have the choice to use any skin, but rtdm is the
preferred one.

-- 
 Gilles Chanteperdrix

Re: [Xenomai-help] Handling irq

[Bosko Radivojevic]

OK, thanks. I'll try that.

I have another problem. I have a task (kernel thread) that sleeps and
wakes up every (almost) 1ms (actually, task is reading sync timers
from EtherCAT and calculate how long should sleep). It is the only RT
task. After some time measuring different things it looks to me that
my task is interrupted from time to time (I can acknowledge that it is
interrupted every second time in different stages). I've measured time
needed for one single memcpy (I set one pin on microcontroller to 1
before memcpy, and set to 0 after it, using __raw_writel). Usually it
takes a few us, but, some times, time for memcpy just grows to 50us.
Is it possible that timer interrupt handler is stopping my task? How I
can mask/disable "all" interrupt handlers during that RT task
execution?

Thanks again! :)

Kind regards,
Bosko

Re: [Xenomai-help] Handling irq

[Gilles Chanteperdrix]

Bosko Radivojevic wrote:
 > OK, thanks. I'll try that.
 > 
 > I have another problem. I have a task (kernel thread) that sleeps and
 > wakes up every (almost) 1ms (actually, task is reading sync timers
 > from EtherCAT and calculate how long should sleep). It is the only RT
 > task. After some time measuring different things it looks to me that
 > my task is interrupted from time to time (I can acknowledge that it is
 > interrupted every second time in different stages). I've measured time
 > needed for one single memcpy (I set one pin on microcontroller to 1
 > before memcpy, and set to 0 after it, using __raw_writel). Usually it
 > takes a few us, but, some times, time for memcpy just grows to 50us.
 > Is it possible that timer interrupt handler is stopping my task? How I
 > can mask/disable "all" interrupt handlers during that RT task
 > execution?

Yes, it is possible. But what is also possible is that you get a cache
flush due to the cache line you are memcpying to being shared with some
unrelated piece of memory. Only the tracer [1] may tell you what
happens.

[1] http://www.xenomai.org/index.php/I-pipe:Tracer

What hardware are you using ? If it is an ARM, you have to realize that
ARM is slow hardware, and that there is little we can do against this.

-- 


					    Gilles.

Re: [Xenomai-help] Handling irq

[Bosko Radivojevic]

On Wed, Mar 19, 2008 at 9:58 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
>  Yes, it is possible. But what is also possible is that you get a cache
>  flush due to the cache line you are memcpying to being shared with some
>  unrelated piece of memory. Only the tracer [1] may tell you what
>  happens.

Yes, sounds reasonable. The 'delaying' happens in all other stages,
not only in memcpy. How I could disable "all" interrupt handlings
during my task execution? And, of course, enable them, after it :)

>  [1] http://www.xenomai.org/index.php/I-pipe:Tracer

I've already tried with Tracer, but system just hangs when I load my
module (with Tracer enabled). I'll try with CONFIG_IPIPE_TRACE_VMALLOC
enabled.

>  What hardware are you using ? If it is an ARM, you have to realize that
>  ARM is slow hardware, and that there is little we can do against this.

Yes, ARM9 based, AT91SAM9260.

Kind regards,
Bosko

Re: [Xenomai-help] Handling irq

[Bosko Radivojevic]

I have much better results using rtdm_lock_get_irqsave and
rtdm_lock_put_irqrestore. I hope this is the "appropriate method" of
doing it :)

Thanks!

On Wed, Mar 19, 2008 at 9:58 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
>
> Bosko Radivojevic wrote:
>   > OK, thanks. I'll try that.
>   >
>   > I have another problem. I have a task (kernel thread) that sleeps and
>   > wakes up every (almost) 1ms (actually, task is reading sync timers
>   > from EtherCAT and calculate how long should sleep). It is the only RT
>   > task. After some time measuring different things it looks to me that
>   > my task is interrupted from time to time (I can acknowledge that it is
>   > interrupted every second time in different stages). I've measured time
>   > needed for one single memcpy (I set one pin on microcontroller to 1
>   > before memcpy, and set to 0 after it, using __raw_writel). Usually it
>   > takes a few us, but, some times, time for memcpy just grows to 50us.
>   > Is it possible that timer interrupt handler is stopping my task? How I
>   > can mask/disable "all" interrupt handlers during that RT task
>   > execution?
>
>  Yes, it is possible. But what is also possible is that you get a cache
>  flush due to the cache line you are memcpying to being shared with some
>  unrelated piece of memory. Only the tracer [1] may tell you what
>  happens.
>
>  [1] http://www.xenomai.org/index.php/I-pipe:Tracer
>
>  What hardware are you using ? If it is an ARM, you have to realize that
>  ARM is slow hardware, and that there is little we can do against this.
>
>  --
>
>
>                                             Gilles.
>

Re: [Xenomai-help] Handling irq

[Gilles Chanteperdrix]

On Fri, Mar 21, 2008 at 11:50 AM, Bosko Radivojevic
<bosko.radivojevic@domain.hid> wrote:
> I have much better results using rtdm_lock_get_irqsave and
>  rtdm_lock_put_irqrestore. I hope this is the "appropriate method" of
>  doing it :)
>
>  Thanks!

Shutting interrupts off for long periods of time is not a good idea:
- it does not scale well, since it does not work for more than one task;
- it kills the precision of timers by delaying the timer interrupt.
And I am sure we can find many more drawbacks.

-- 
 Gilles

Re: [Xenomai-help] Handling irq

[Jan Kiszka]

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

Gilles Chanteperdrix wrote:
> On Fri, Mar 21, 2008 at 11:50 AM, Bosko Radivojevic
> <bosko.radivojevic@domain.hid> wrote:
>> I have much better results using rtdm_lock_get_irqsave and
>>  rtdm_lock_put_irqrestore. I hope this is the "appropriate method" of
>>  doing it :)
>>
>>  Thanks!
> 
> Shutting interrupts off for long periods of time is not a good idea:
> - it does not scale well, since it does not work for more than one task;
> - it kills the precision of timers by delaying the timer interrupt.
> And I am sure we can find many more drawbacks.

- it only reduces the probability of your problem, it doe not
   eliminate it completely

You can still be interrupted right after task wakeup, before 
rtdm_lock_get_irqsave. And there is still the possibility to be delayed 
by interrupts BEFORE your task is even triggered.

If you cannot live with this conceptual jitter (which you'll find on any 
RTOS with more than one job running), you have to do ahead-of-time 
scheduling with busy waiting until the actual release date. That will 
mean disabling IRQs for a really long time + burning a lot of CPU power. 
Kind of last resort, not generally recommended.

Jan


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