[Xenomai-help] Problems with level triggered Interrupts on ARM

[Stephan Adler <stephan.adler@domain.hid>]

Dear list!

I have a problem in understanding how Xenomai handles level triggered 
Interrupts.

I am using an ARM AT91RM9200 with the native Xenomai (2.4.2) skin.

I try to implement the handling of a network protocol on that platform. 
Therefore a network controller is used which is directly connected to 
the Arm.
This network controller has one level-trigerred interrupt line. The line 
is used to signal when a packet has arrived in the controller. There are 
two types of messages - a control-type and a data-type. The interrupt is 
shared for both packet types.

When a packet arrives the interrupt line is pulled to a low-level until 
the Arm reads a certain register depending on the packet-type. A problem 
occurs when - while handling a data-message - a control-message is 
received by the controller. The interrupt line will stay down after the 
data-packet is handled until I handle the control-message also.

Well - as I am using a level triggered interrupt I'd expect Xenomai to 
jump over the rt_intr_wait() instruction until the level of the 
interrupt rises again. But that actually doesn't happen. Indeed Xenomai 
just counts the interrupt whenever an new edge of the interrupt signal 
occurs.

I searched this list for an explanation of that behavior and found these 
two messages:

https://mail.gna.org/public/xenomai-help/2006-06/msg00078.html
https://mail.gna.org/public/xenomai-help/2008-05/msg00263.html

When I understand both posts correctly, I assume the following behavior 
of the Arm vs. Xenomai:

- the ARM sends an hardware interrupt to Xenomai each an etch occurs in 
the signal. This should be interpreted as an "interrupt start" and 
"interrupt end" event for a level triggered interrupt.

- Xenomai does not interpret both events this way, but just counts each 
event as single interrupt event. - When the "interrupt end" event does 
not occur an the level stays low, Xenomai will step over rt_intr_wait() 
for one time - and not again - although the level triggered interrupt is 
still active.

My question is now wether I understood this behavior correctly - or 
wether I am doing something wrong. I could work around that problem by 
myself by just counting the interrupts - but that would not be very 
satisfying.

I also read that there might be some way to work around that issue by 
using rt_intr_enable() - if this is the case - how to do so?

Thanks a lot
Stephan Adler

-- 
Stephan Adler

imc Meßsysteme GmbH