interrupt servicing problems

Jan Kiszka jan.kiszka at
Thu Jul 27 15:45:19 CEST 2006

Geraads/Wiermans/Aerts wrote:
> On do, 2006-07-27 at 14:12 +0200, Jan Kiszka wrote:
>> Geraads/Wiermans/Aerts wrote:
>>> On do, 2006-07-27 at 11:51 +0200, Jan Kiszka wrote: 
>>>> Geraads/Wiermans/Aerts wrote:
>>>>> We have problems getting a isr handler going, we did use some basic code
>>>>> from "rtai-3.3/addons/drivers/serial" a starting writing a new driver
>>>>> for our needs.
>>>> I recommend to check the RTDM interface for this (addons/rtdm): better
>>>> defined semantics (my believe :)), support for defining clean
>>>> driver/application interfaces, better portability (architecture-wise and
>>>> RT-extension-wise).
>>>> For a usage example you may have a look this new benchmark (not yet
>>>> adopted by RTAI, AFAIK):
>>>> Pick out the parts that relate to serial port + RTDM-IRQ (not the I-pipe
>>>> domain stuff).
>>> A lot of code for the small thing we want to do, we just want a
>>> transmitter empty interrupt from the serialport (uart) and service it. 
>>> You think using this code and stripping it down will do the job?
>> Ok, I see the issue (it's just that the example is known to work). What
>> about this:
>> int irq_handler(rtdm_irq_t *irq_handle)
>> {
>> 	/* handle IRQ, somehow */
>> 	return RTDM_IRQ_HANDLED;
>> }
> can't find RTDM_IRQ_HANDLED? 

Replace it with RTDM_IRQ_ENABLE in RTAI 3.3/3.3-cv (RTDM API revision #3).

Upcoming RTAI 3.4 will have RTDM_IRQ_HANDLED/RTDM_IRQ_NONE (API rev.
#4). We changed this in order to get closer to the Linux IRQ return code
style and to avoid misinterpretations (RTDM_IRQ_ENABLE !=


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : 

More information about the Rtai mailing list