[Xenomai-help] [RTDM] best strategy for periodic reading

[Xenomai-help] [RTDM] best strategy for periodic reading

[Marco Jackel]

Hello,
I'm writing a driver for a A/D converter with a multiplexer. I want to 
access it with software controlled conversion. The controller has 15 
Inputs. I've to set a few Bits to select the Channel that I want to read 
from and to start the conversion. I want to access different channel 
with a different frequency. At the moment I try to do this with 
different realtime-tasks started from the "read_rt" function 
(rtdm_task_init).
Is this the best way or is there something more elegant?

Thanks
Maggo

Re: [Xenomai-help] [RTDM] best strategy for periodic reading

[Jan Kiszka]

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

Marco Jackel wrote:
> Hello,
> I'm writing a driver for a A/D converter with a multiplexer. I want to
> access it with software controlled conversion. The controller has 15
> Inputs. I've to set a few Bits to select the Channel that I want to read
> from and to start the conversion. I want to access different channel
> with a different frequency. At the moment I try to do this with
> different realtime-tasks started from the "read_rt" function
> (rtdm_task_init).
> Is this the best way or is there something more elegant?
> 

What is the usage model of your driver? Is there an application thread
associated to each frequency or even each channel? Or is there a single
reader which gets woken up once some channel finishes the conversion? Or
does the application requests a bulk of samples from multiple channels?

Depending on that usage model, an alternative way to implement your
driver is to let the application generate the conversion clock, i.e. let
it poll the data (maybe just blocking on the conversion completion).

On the other hand, if the acquisition job currently performed in
rtdm_tasks is rather light-weight, maybe timers would help you to reduce
the overhead involved in multiple threads reading from the same device
(including locking etc.). Unfortunately, an RTDM interface for direct
timer usage has not yet been fully specified. Some preliminary patch
hangs around on my box for quite a few months now. Do you see advantages
for your scenario when using timers, i.e. executing the periodic jobs
directly in the context of the timer IRQ handler? If yes, I could try to
accelerate the finalisation of this patch.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] [RTDM] best strategy for periodic reading

[Li Yi (Adam)]

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

Hi Jan,

Quick questions:
1. What is the problem with "xntimer_init()"? The timerbench.c use it to
create timers? You are going to write a RTDM implementation?
2.  What is  general program model for Xenomai application like data
acquisition? What I am thinking is to start the RT task in user space (via
POSIX skin), and implement the read funtion in kernel space using RTDM.

Thanks,
-Yi

On 5/16/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Marco Jackel wrote:
> > Hello,
> > I'm writing a driver for a A/D converter with a multiplexer. I want to
> > access it with software controlled conversion. The controller has 15
> > Inputs. I've to set a few Bits to select the Channel that I want to read
> > from and to start the conversion. I want to access different channel
> > with a different frequency. At the moment I try to do this with
> > different realtime-tasks started from the "read_rt" function
> > (rtdm_task_init).
> > Is this the best way or is there something more elegant?
> >
>
> What is the usage model of your driver? Is there an application thread
> associated to each frequency or even each channel? Or is there a single
> reader which gets woken up once some channel finishes the conversion? Or
> does the application requests a bulk of samples from multiple channels?
>
> Depending on that usage model, an alternative way to implement your
> driver is to let the application generate the conversion clock, i.e. let
> it poll the data (maybe just blocking on the conversion completion).
>
> On the other hand, if the acquisition job currently performed in
> rtdm_tasks is rather light-weight, maybe timers would help you to reduce
> the overhead involved in multiple threads reading from the same device
> (including locking etc.). Unfortunately, an RTDM interface for direct
> timer usage has not yet been fully specified. Some preliminary patch
> hangs around on my box for quite a few months now. Do you see advantages
> for your scenario when using timers, i.e. executing the periodic jobs
> directly in the context of the timer IRQ handler? If yes, I could try to
> accelerate the finalisation of this patch.
>
> Jan
>
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>
>
>
>

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

Re: [Xenomai-help] [RTDM] best strategy for periodic reading

[Jan Kiszka]

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

Li Yi (Adam) wrote:
> Hi Jan,
> 
> Quick questions:

...long answer. ;)

> 1. What is the problem with "xntimer_init()"? The timerbench.c use it to
> create timers? You are going to write a RTDM implementation?

Not an implementation but rather a thin wrapper.

The aim of RTDM is to remain independent of the actual RT-Linux
implementation. We already have RTDM support in recent RTAI, the future
may bring ports to RTLinux/GPL (as long as this project keeps alive) and
preempt-rt. Sebastian's SJA1000 CAN driver is e.g. RTDM-based and can be
recompiled for RTAI without using tons of #ifdefs. RTnet does this even
longer.

So, by using Xenomai nucleus services directly you make your driver
harder to port. The timerbench-way is only an intermediate solution
until we have a real abstraction (see also comments in the code).

> 2.  What is  general program model for Xenomai application like data
> acquisition? What I am thinking is to start the RT task in user space (via
> POSIX skin), and implement the read funtion in kernel space using RTDM.

Unless you have specific requirements, putting the (common) hardware
interface into an RTDM driver and leaving the rest to the application is
the preferred way (it's nothing Xenomai-specific, is it?).

If a RTDM driver always has to be in kernel space is a different
question. I have some weird ideas about (widely) seamless user space
migration (and vice versa), either into the process context of an
exclusive device user (kind of library) or even shared between multiple
processes (device servers, microkernel-like, probably at similar costs).
Anyway, the goal is to keep the RTDM interfaces for both domains widely
identical, and this will require some more work (and thus time, which
I'm always lacking).

Userspace drivers are not the ultimate answer to all questions (that's
42 anyway), but they can open certain new possibilities, both
technically and legally.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[Xenomai-help] Re: [RTDM] best strategy for periodic reading

[Marco Jackel]

Hi Jan,

Jan Kiszka wrote:
  > What is the usage model of your driver? Is there an application thread
> associated to each frequency or even each channel? Or is there a single
> reader which gets woken up once some channel finishes the conversion? Or
> does the application requests a bulk of samples from multiple channels?

I want to implement this as a single reader. The only thing I've to do 
is to log the data from the different channels to one or more file(s).

> Depending on that usage model, an alternative way to implement your
> driver is to let the application generate the conversion clock, i.e. let
> it poll the data (maybe just blocking on the conversion completion).

I'll try that.

> On the other hand, if the acquisition job currently performed in
> rtdm_tasks is rather light-weight,

I think so, only a few small macros with bit-operations that set/read 
the register from the ISA-card

> maybe timers would help you to reduce
> the overhead involved in multiple threads reading from the same device
> (including locking etc.). Unfortunately, an RTDM interface for direct
> timer usage has not yet been fully specified. Some preliminary patch
> hangs around on my box for quite a few months now. Do you see advantages
> for your scenario when using timers, i.e. executing the periodic jobs
> directly in the context of the timer IRQ handler? If yes, I could try to
> accelerate the finalisation of this patch.

There are some sensors on the serial device, too, and the event-driven 
programming is a very elegant way (using xeno_16550A with 
"rt_dev_ioctl(imu_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event );". So I 
thought it would be nice to implement the driver for the ISA-card in a 
similar way.

Thanks
Maggo