[Xenomai-help] Analogy vs Comedi

[Xenomai-help] Analogy vs Comedi

[Jaryn Sepesi]

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

Hi everyone!

I'm designing a real-time system based on Xenomai and NI 6259 DAQ board.
Analogy contains a driver for my card, but there is one little problem. I
have some experience using this card with normal non-RT linux + Comedi, so I
know It needs to be calibrated via tools like comedi_soft_calibrate. I
didn't find any suitable equivalent of this tool in Xenomai documentation.

My question is - Is it possible to use Comedi tools (like mentioned
comedi_soft_calibrate) together with analogy driver? And if not, can I use
comedi driver combined with Xenomai? I mean for RT applications. (Yes, I
know this is definitely not a clean approach, but still better than use
different RTOS)

Thank you very much!

BR,
Jaryn Sepesi

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

Re: [Xenomai-help] Analogy vs Comedi

[Alexis Berlemont]

Hi,

Jaryn Sepesi wrote:
> Hi everyone!
> 
> I'm designing a real-time system based on Xenomai and NI 6259 DAQ board. 
> Analogy contains a driver for my card, but there is one little problem. 
> I have some experience using this card with normal non-RT linux + 
> Comedi, so I know It needs to be calibrated via tools like 
> comedi_soft_calibrate. I didn't find any suitable equivalent of this 
> tool in Xenomai documentation.
You are right. This tool has not yet been developed.

> 
> My question is - Is it possible to use Comedi tools (like mentioned 
> comedi_soft_calibrate) together with analogy driver? 
I am afraid you can't. But this task is planned (among many others). I
am still struggling with some other tasks but I could start it quite soon.

And if not, can I
> use comedi driver combined with Xenomai? I mean for RT applications. 
> (Yes, I know this is definitely not a clean approach, but still better 
> than use different RTOS)
Your real-time task will be able to use the comedi driver. However, I
think you already have in mind that your task will leave the primary
domain. You will be in charge to make it switch back.

Anyway, a smooth transition from comedi to analogy should be easy, once
the calibration feature will be available. Thus, you will get a better
determinism for your whole application.

> 
> Thank you very much!
> 
> BR,
> Jaryn Sepesi
> 

Alexis.

> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

[Xenomai-help] Sleep in rtdm driver

[robert165]

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

Hi everyone!

I'm writing a gpio driver in RTDM. I start it with the demo "Hard real time RTDM driver skeleton v1.1" of Jan Kiszka.
If I used rtdm_task_sleep in rt_ioctrl  function,  it return that "Xenomai: assertion failed at kernel/xenomai/skins/rtdm/drvlib.c:372 (!xnpod_unblockable_p())"  when running.
It is said that rtdm_task_sleep can be called from Kernel-based task. Why I can't use it in my driver. Optionally, I can do this in user-space by periodic calling the driver, but it seems slower than in kernel space.
 
Thank you very much!
 
Best regards
 
Luo
 

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

Re: [Xenomai-help] Sleep in rtdm driver

[Jan Kiszka]

robert165 wrote:
> Hi everyone!
> 
> I'm writing a gpio driver in RTDM. I start it with the demo "Hard real time RTDM driver skeleton v1.1" of Jan Kiszka.
> If I used rtdm_task_sleep in rt_ioctrl  function,  it return that "Xenomai: assertion failed at kernel/xenomai/skins/rtdm/drvlib.c:372 (!xnpod_unblockable_p())"  when running.
> It is said that rtdm_task_sleep can be called from Kernel-based task. Why I can't use it in my driver. Optionally, I can do this in user-space by periodic calling the driver, but it seems slower than in kernel space.

The terms "kernel-based task" or "user space task" can be misleading.
This services requires a real-time task context. That can either be a
kernel-based *RT* task or a Xenomai shadow (aka *RT*) task in user space
that has invoked some driver service, and that driver can then call
rtdm_task_sleep on behalf of the user space task.

Blocking RTDM service *must not* be called by ordinary Linux kernel
threads or on behalf of ordinary (non-shadowed) Linux user space
threads. That's why the assertion failed for you.

HTH,
Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] Sleep in rtdm driver

[Philippe Gerum]

On Wed, 2010-03-17 at 22:07 +0800, robert165 wrote:
> Hi everyone!
> 
> I'm writing a gpio driver in RTDM. I start it with the demo "Hard real
> time RTDM driver skeleton v1.1" of Jan Kiszka.
> If I used rtdm_task_sleep in rt_ioctrl  function,  it return that
> "Xenomai: assertion failed at kernel/xenomai/skins/rtdm/drvlib.c:372
> (!xnpod_unblockable_p())"  when running.
> It is said that rtdm_task_sleep can be called from Kernel-based task.
> Why I can't use it in my driver. Optionally, I can do this in
> user-space by periodic calling the driver, but it seems slower than in
> kernel space.

I'm puzzled: what does "slower" mean, regarding what operation?

>  
> Thank you very much!
>  
> Best regards
>  
> Luo
>  
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 
Philippe.

Re: [Xenomai-help] Sleep in rtdm driver

[robert165]

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





在2010-03-17 23:05:33，"Jan Kiszka" jan.kiszka@siemens.com> 写道：
>robert165 wrote:
>> Hi everyone!
>> 
>> I'm writing a gpio driver in RTDM. I start it with the demo "Hard real time RTDM driver skeleton v1.1" of Jan Kiszka.
>> If I used rtdm_task_sleep in rt_ioctrl  function,  it return that "Xenomai: assertion failed at kernel/xenomai/skins/rtdm/drvlib.c:372 (!xnpod_unblockable_p())"  when running.
>> It is said that rtdm_task_sleep can be called from Kernel-based task. Why I can't use it in my driver. Optionally, I can do this in user-space by periodic calling the driver, but it seems slower than in kernel space.
>
>The terms "kernel-based task" or "user space task" can be misleading.
>This services requires a real-time task context. That can either be a
>kernel-based *RT* task or a Xenomai shadow (aka *RT*) task in user space
>that has invoked some driver service, and that driver can then call
>rtdm_task_sleep on behalf of the user space task.

Thanks for your demo, I started my code with it.
Is that means the demo_ioctrl_rt  is not a kernel based 'RT' task?  But why using rtdm_event_timewait in demo_read_rt is OK? 
Thanks for help.
>Blocking RTDM service *must not* be called by ordinary Linux kernel
>threads or on behalf of ordinary (non-shadowed) Linux user space
>threads. That's why the assertion failed for you.
>
>HTH,
>Jan
>
>-- 
>Siemens AG, Corporate Technology, CT T DE IT 1
>Corporate Competence Center Embedded Linux

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