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

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- 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 --]