All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai-help] Problems with user_irq.c Native example
@ 2010-08-01  7:03 Murilo Marinho
  2010-08-01  9:36 ` Philippe Gerum
  0 siblings, 1 reply; 6+ messages in thread
From: Murilo Marinho @ 2010-08-01  7:03 UTC (permalink / raw)
  To: xenomai

I tried running the user_irq.c example as described in the section
7.14 in the native PDF, which is written in the end of this mail.
At first, it froze my system every time I tried running it. I did some
changes in the code, trying to find out what was wrong with it.

>From what I understood this should work (I'm new to xenomai
programming), the rt_intr_wait function should pause the running task
until the interrupt comes, but after inserting some flow controls, I
found it to be freezing due to excessive processing of the irq_server,
which at first seemed to be receiving endless interruption signals.

In the next step, I added error handling, but the return value of the
function was -38, which didn't mean it worked ( as it wasn't a
positive
value), nor it was any of the errors described in the function documentation.

I also tried changing from TM_INFINITE to many numerical values to no
avail, got the same return value.

Have I misunderstood the way this function works? Does this error
means something?

I'm using ubuntu 9.10, xenomai 2.5.3 and kernel 2.6.34

7.14 user_irq.c
#include <sys/mman.h>
#include <native/task.h>
#include <native/intr.h>
#define IRQ_NUMBER 7 /* Intercept interrupt #7 */
#define TASK_PRIO 99 /* Highest RT priority */
#define TASK_MODE 0 /* No flags */
#define TASK_STKSZ 0 /* Stack size (use default one) */
RT_INTR intr_desc;
RT_TASK server_desc;
void irq_server (void *cookie)
{
for (;;) {
/* Wait for the next interrupt on channel #7. */
err = rt_intr_wait(&intr_desc,TM_INFINITE);
if (!err) {
/* Process interrupt. */
}
}
}
int main (int argc, char *argv[])
{
int err;
mlockall(MCL_CURRENT|MCL_FUTURE);
/* ... */
err = rt_intr_create(&intr_desc,"MyIrq",IRQ_NUMBER,0);
/* ... */
err = rt_task_create(&server_desc,
"MyIrqServer",
TASK_STKSZ,
TASK_PRIO,
TASK_MODE);
if (!err)
rt_task_start(&server_desc,&irq_server,NULL);
/* ... */
}
void cleanup (void)
{
rt_intr_delete(&intr_desc);
rt_task_delete(&server_desc);
}


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Xenomai-help] Problems with user_irq.c Native example
  2010-08-01  7:03 [Xenomai-help] Problems with user_irq.c Native example Murilo Marinho
@ 2010-08-01  9:36 ` Philippe Gerum
  2010-08-01 13:10   ` Henri Roosen
  2010-12-23  2:11   ` Bryan Hilterbrand
  0 siblings, 2 replies; 6+ messages in thread
From: Philippe Gerum @ 2010-08-01  9:36 UTC (permalink / raw)
  To: murilomarinho; +Cc: xenomai

On Sun, 2010-08-01 at 04:03 -0300, Murilo Marinho wrote:
> I tried running the user_irq.c example as described in the section
> 7.14 in the native PDF, which is written in the end of this mail.
> At first, it froze my system every time I tried running it. I did some
> changes in the code, trying to find out what was wrong with it.
> 
> >From what I understood this should work (I'm new to xenomai
> programming), the rt_intr_wait function should pause the running task
> until the interrupt comes, but after inserting some flow controls, I
> found it to be freezing due to excessive processing of the irq_server,
> which at first seemed to be receiving endless interruption signals.
> 
> In the next step, I added error handling, but the return value of the
> function was -38, which didn't mean it worked ( as it wasn't a
> positive
> value), nor it was any of the errors described in the function documentation.
> 
> I also tried changing from TM_INFINITE to many numerical values to no
> avail, got the same return value.
> 
> Have I misunderstood the way this function works? Does this error
> means something?
> 

CONFIG_XENO_OPT_NATIVE_INTR is disabled in your kernel configuration,
which causes -ENOSYS to be returned. You have to switch this on to
enable userland interrupt support.

Also note that such support may introduce serious issues down the road,
like not being able to use gdb over your application; using it in new
apps is a bad idea in the first place, because interrupt handling is
fundamentally a kernel thing, and should remain so.

Providing this interface was a mistake, it is now deprecated, and
scheduled for removal in 3.x. The right approach is to process
(real-time) interrupts in kernel space from a RTDM driver, waking up a
userland thread as needed. That thread may wait for events via blocking
ioctl()/read() requests directed at the driver, thus following the
standard programming model.

> I'm using ubuntu 9.10, xenomai 2.5.3 and kernel 2.6.34
> 
> 7.14 user_irq.c
> #include <sys/mman.h>
> #include <native/task.h>
> #include <native/intr.h>
> #define IRQ_NUMBER 7 /* Intercept interrupt #7 */
> #define TASK_PRIO 99 /* Highest RT priority */
> #define TASK_MODE 0 /* No flags */
> #define TASK_STKSZ 0 /* Stack size (use default one) */
> RT_INTR intr_desc;
> RT_TASK server_desc;
> void irq_server (void *cookie)
> {
> for (;;) {
> /* Wait for the next interrupt on channel #7. */
> err = rt_intr_wait(&intr_desc,TM_INFINITE);
> if (!err) {
> /* Process interrupt. */
> }
> }
> }
> int main (int argc, char *argv[])
> {
> int err;
> mlockall(MCL_CURRENT|MCL_FUTURE);
> /* ... */
> err = rt_intr_create(&intr_desc,"MyIrq",IRQ_NUMBER,0);
> /* ... */
> err = rt_task_create(&server_desc,
> "MyIrqServer",
> TASK_STKSZ,
> TASK_PRIO,
> TASK_MODE);
> if (!err)
> rt_task_start(&server_desc,&irq_server,NULL);
> /* ... */
> }
> void cleanup (void)
> {
> rt_intr_delete(&intr_desc);
> rt_task_delete(&server_desc);
> }
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Xenomai-help] Problems with user_irq.c Native example
  2010-08-01  9:36 ` Philippe Gerum
@ 2010-08-01 13:10   ` Henri Roosen
  2010-08-02  1:32     ` Flavio de Castro Alves Filho
  2010-12-23  2:11   ` Bryan Hilterbrand
  1 sibling, 1 reply; 6+ messages in thread
From: Henri Roosen @ 2010-08-01 13:10 UTC (permalink / raw)
  To: Philippe Gerum; +Cc: murilomarinho, xenomai

If you really want to use the rt_intr_xxx interface, you might want to
pass the RT_INTR_NOENABLE mode-flag to rt_intr_create and call
rt_intr_enable after you have acknowledged your interrupt source (or
just before you wait for the interrupt) in your interrupt handler.

But as Philippe mentioned it is cleaner to use the rtdm driver approach.

Henri.

On Sun, Aug 1, 2010 at 11:36 AM, Philippe Gerum <rpm@xenomai.org> wrote:
> On Sun, 2010-08-01 at 04:03 -0300, Murilo Marinho wrote:
>> I tried running the user_irq.c example as described in the section
>> 7.14 in the native PDF, which is written in the end of this mail.
>> At first, it froze my system every time I tried running it. I did some
>> changes in the code, trying to find out what was wrong with it.
>>
>> >From what I understood this should work (I'm new to xenomai
>> programming), the rt_intr_wait function should pause the running task
>> until the interrupt comes, but after inserting some flow controls, I
>> found it to be freezing due to excessive processing of the irq_server,
>> which at first seemed to be receiving endless interruption signals.
>>
>> In the next step, I added error handling, but the return value of the
>> function was -38, which didn't mean it worked ( as it wasn't a
>> positive
>> value), nor it was any of the errors described in the function documentation.
>>
>> I also tried changing from TM_INFINITE to many numerical values to no
>> avail, got the same return value.
>>
>> Have I misunderstood the way this function works? Does this error
>> means something?
>>
>
> CONFIG_XENO_OPT_NATIVE_INTR is disabled in your kernel configuration,
> which causes -ENOSYS to be returned. You have to switch this on to
> enable userland interrupt support.
>
> Also note that such support may introduce serious issues down the road,
> like not being able to use gdb over your application; using it in new
> apps is a bad idea in the first place, because interrupt handling is
> fundamentally a kernel thing, and should remain so.
>
> Providing this interface was a mistake, it is now deprecated, and
> scheduled for removal in 3.x. The right approach is to process
> (real-time) interrupts in kernel space from a RTDM driver, waking up a
> userland thread as needed. That thread may wait for events via blocking
> ioctl()/read() requests directed at the driver, thus following the
> standard programming model.
>
>> I'm using ubuntu 9.10, xenomai 2.5.3 and kernel 2.6.34
>>
>> 7.14 user_irq.c
>> #include <sys/mman.h>
>> #include <native/task.h>
>> #include <native/intr.h>
>> #define IRQ_NUMBER 7 /* Intercept interrupt #7 */
>> #define TASK_PRIO 99 /* Highest RT priority */
>> #define TASK_MODE 0 /* No flags */
>> #define TASK_STKSZ 0 /* Stack size (use default one) */
>> RT_INTR intr_desc;
>> RT_TASK server_desc;
>> void irq_server (void *cookie)
>> {
>> for (;;) {
>> /* Wait for the next interrupt on channel #7. */
>> err = rt_intr_wait(&intr_desc,TM_INFINITE);
>> if (!err) {
>> /* Process interrupt. */
>> }
>> }
>> }
>> int main (int argc, char *argv[])
>> {
>> int err;
>> mlockall(MCL_CURRENT|MCL_FUTURE);
>> /* ... */
>> err = rt_intr_create(&intr_desc,"MyIrq",IRQ_NUMBER,0);
>> /* ... */
>> err = rt_task_create(&server_desc,
>> "MyIrqServer",
>> TASK_STKSZ,
>> TASK_PRIO,
>> TASK_MODE);
>> if (!err)
>> rt_task_start(&server_desc,&irq_server,NULL);
>> /* ... */
>> }
>> void cleanup (void)
>> {
>> rt_intr_delete(&intr_desc);
>> rt_task_delete(&server_desc);
>> }
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>
> --
> Philippe.
>
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Xenomai-help] Problems with user_irq.c Native example
  2010-08-01 13:10   ` Henri Roosen
@ 2010-08-02  1:32     ` Flavio de Castro Alves Filho
  0 siblings, 0 replies; 6+ messages in thread
From: Flavio de Castro Alves Filho @ 2010-08-02  1:32 UTC (permalink / raw)
  To: Henri Roosen; +Cc: murilomarinho, xenomai

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

Hello,

I also recommend the rtdm approach. I used it here in a pc/104 and irq7 bus
and it works very well.

Best regards,

Flavio

Em 01/08/2010 10:13, "Henri Roosen" <henriroosen@domain.hid>escreveu:

If you really want to use the rt_intr_xxx interface, you might want to
pass the RT_INTR_NOENABLE mode-flag to rt_intr_create and call
rt_intr_enable after you have acknowledged your interrupt source (or
just before you wait for the interrupt) in your interrupt handler.

But as Philippe mentioned it is cleaner to use the rtdm driver approach.

Henri.


On Sun, Aug 1, 2010 at 11:36 AM, Philippe Gerum <rpm@xenomai.org> wrote:
> On Sun, 2010-08-01 at 04...

[-- Attachment #2: Type: text/html, Size: 943 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Xenomai-help] Problems with user_irq.c Native example
  2010-08-01  9:36 ` Philippe Gerum
  2010-08-01 13:10   ` Henri Roosen
@ 2010-12-23  2:11   ` Bryan Hilterbrand
  2010-12-23  9:11     ` Philippe Gerum
  1 sibling, 1 reply; 6+ messages in thread
From: Bryan Hilterbrand @ 2010-12-23  2:11 UTC (permalink / raw)
  To: Philippe Gerum; +Cc: xenomai

On Sunday, 2010-08-01, Philippe Gerum wrote:
> Also note that [userland interrupt] support may introduce serious issues
> down the road,
> like not being able to use gdb over your application; using it in new
> apps is a bad idea in the first place, because interrupt handling is
> fundamentally a kernel thing, and should remain so.
>
> Providing this interface was a mistake, it is now deprecated, and
> scheduled for removal in 3.x. The right approach is to process
> (real-time) interrupts in kernel space from a RTDM driver, waking up a
> userland thread as needed. That thread may wait for events via blocking
> ioctl()/read() requests directed at the driver, thus following the
> standard programming model.

I just discovered this thread, and I'm trying to solve a similar problem.

Philippe, can you point me to a RTDM driver example that uses an interrupt
and blocks the reader? Or is this something that I will need to figure out
myself? A good RTDM example would be a start...

I'm on an older version of Xenomai (2.3) if that makes a difference.

Thank you for any help you can give me!


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Xenomai-help] Problems with user_irq.c Native example
  2010-12-23  2:11   ` Bryan Hilterbrand
@ 2010-12-23  9:11     ` Philippe Gerum
  0 siblings, 0 replies; 6+ messages in thread
From: Philippe Gerum @ 2010-12-23  9:11 UTC (permalink / raw)
  To: Bryan Hilterbrand; +Cc: xenomai

On Wed, 2010-12-22 at 19:11 -0700, Bryan Hilterbrand wrote:
> On Sunday, 2010-08-01, Philippe Gerum wrote:
> > Also note that [userland interrupt] support may introduce serious issues
> > down the road,
> > like not being able to use gdb over your application; using it in new
> > apps is a bad idea in the first place, because interrupt handling is
> > fundamentally a kernel thing, and should remain so.
> >
> > Providing this interface was a mistake, it is now deprecated, and
> > scheduled for removal in 3.x. The right approach is to process
> > (real-time) interrupts in kernel space from a RTDM driver, waking up a
> > userland thread as needed. That thread may wait for events via blocking
> > ioctl()/read() requests directed at the driver, thus following the
> > standard programming model.
> 
> I just discovered this thread, and I'm trying to solve a similar problem.
> 
> Philippe, can you point me to a RTDM driver example that uses an interrupt
> and blocks the reader? Or is this something that I will need to figure out
> myself? A good RTDM example would be a start...
> 

The interrupt-related doc starts here:
http://www.xenomai.org/documentation/xenomai-2.3/html/api/group__rtdmirq.html


> I'm on an older version of Xenomai (2.3) if that makes a difference.
> 

Here is an example, driving a 16550 UART. You will find an interaction
between the IRQ handler and the ioctl code, via the "ioc_event" RTDM
even object. The ioctl() code blocks the caller until the event is
posted from the handler, I guess your are looking after something
similar.
http://git.xenomai.org/?p=xenomai-2.3.git;a=blob;f=ksrc/drivers/serial/16550A.c;h=59236ae7b9edfa855701acb99d82f2721e23a866;hb=ea356248b8730fe8126ade4a1f8e49d179352310

I guess you keep stuck on 2.3.x because your fixture is deployed, but
really, unless you are perfectly happy with this release, you should
consider moving to 2.5.5.2 when/if any unexplained or weird bug happens.
Older kernels that were fashionable in 2007 are still supported by the
latest 2.5.x.

> Thank you for any help you can give me!

-- 
Philippe.




^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2010-12-23  9:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-01  7:03 [Xenomai-help] Problems with user_irq.c Native example Murilo Marinho
2010-08-01  9:36 ` Philippe Gerum
2010-08-01 13:10   ` Henri Roosen
2010-08-02  1:32     ` Flavio de Castro Alves Filho
2010-12-23  2:11   ` Bryan Hilterbrand
2010-12-23  9:11     ` Philippe Gerum

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.