Jan Kiszka wrote:
> Johan Borkhuis wrote:
>
>> Hello,
>>
>> I am trying to use semaphores inside my driver. It is a driver that can
>> be used as standard Linux driver and RTDM driver.
>>
>> However, when I use rt_sem_p or rtdm_sem_timeddown in my read_nrt
>>
>
> Calling those blocking RT services over a non-RT RTDM handler is a
> strong indication that you are doing something fundamentally wrong.
>
> (BTW, for consistency reasons, you shouldn't use native API services in
> RTDM drivers. Technically, this can be OK, but it is at least very unclean.)
>
This is true, but as the RTDM sem's did not work for me I moved to the
rt_sem, which also did not work for the same reason.
>> function I get a -1 return value, indicating EPERM. When I look at the
>> thread state I see a value of 0x00400080, which indicates a standard
>> Linux thread. The rtdm-context is 0x00000001.
>> The userspace thread has a thread state of 00300380.
>>
>> What am I doing wrong here? How can I get a semaphore or other sync
>> mechanism to work inside my RTDM driver?
>>
>
> RT resources are for RT threads in _primary_ mode. Why do you want to
> pend on those resources while the threads are in secondary ("nrt") more?
>
The main problem is is that part of the driver (especially the interrupt
handler) is running in primary mode. The application itself is running
partly in secondary mode. I need some mechanism to have the application
waiting for a signal from the interrupt handler.
Do I need to implement this using rtdm_nrtsig, or are there other ways
to send signals from primary to secondary mode?
Kind regards,
Johan Borkhuis
--
Johan Borkhuis Dutch Space BV
email: [EMAIL PROTECTED] Newtonweg 1
phone: 071-5245788 Leiden
fax: 071-5245499 The Netherlands
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
