Re: RTAI and Comedi: Problems with commands

> Hi everybody,
>
> I am trying to use the comedi commands using RTAI (RTAI 3.3CV, latest
> comedi/comedilib). On the RTAI CVS I have found an (old?) example
testa.c > that I used as base.
> I have debugged into the driver (I use a simple PCI NI 6024-E) and I found
> out that the data is transferred correctly via DMA to the async
> prealloc_buf.

I have used both a PCI NI 6024-E and a DAQCard NI 6024-E successfully
(read on!) ...

> It seams as the only thing that misses is the transfer from the internal
> (kernel space) memory that holds the input values (written by DMA) to the
> user space value.
>
> One strange thing that I have detected was the following:
> The function rt_comedi_alloc_cmd() sets internally the values of cmd->data
> and cmd->chanlist and returns the values in the arguments **chanlist and
> **data.
> However, when testa returns from comedi_command_test() the value of
> cmd->data has changed - it points now somewhere in a 0xexxxxxxx address
> space.
> Could this be an issue?
Exactly...

The buffer address returned by comedi_command_test() seems to be a kernel
space address and not directly usable by an lxrt userspace program.

The LXRT support for comedi _commands_ has been broken for a few years
(since 2002?) now.

At that time the comedi drivers must have been changed to no longer access
the buffer made known to them via "data" in rt_comedi_alloc_cmd().
Instead they read from/write to a transfer buffer preallocated per
subdevice at module load time or even only at the time a device is
configured.

LXRT-Comedi has never been accomodated to that change.
>
> Is there somewhere a running example available that shows working comedi
> commands with RTAI?

I had to make that stuff work for myself last year -- a little rewrite of
rtai_comedi.h and kcomedi_module.c from addons/comedi subdirectory of rtai
sources.

They can be used as drop-in replacements for the original files from RTAI
versions from at least 3.1. However they miss support for one kcomedilib
call that has been added to magma CVS meanwhile.

I have made a new version of rt_comedi_alloc_cmd -- its interface is no
longer source compatible to the old one.
Please be aware that its method to make the buffer available to lxrt user
space is at least questionable -- but it works for me.

The userspace non-rt comedilib just makes the transfer buffer available as
a mmap()able device (/dev/comediX) -- which is far better but not
supported by _kcomedilib_.

My kernel-side implementation of rt_comedi_alloc_cmd _fakes_ the
allocation of a SHM segment for the transfer buffer and provides its lxrt
name for userspace. That might be *dangerous* if the module is removed
before rt_comedi_free_cmd has been called. Just look at a dmesg trace of
this.

I'll attach my modified files to this mail together with a modified
"testa.c" example. In it you'll find a use case for
rt_comedi_mark_wait_munge(..) -- which I added to LXRT-Comedi.

My solution is by no means elegant -- better would be to modify kcomedilib
to support userspace mmap()ing /dev/comediX just like comedilib does.
Look at comedilib/demo/mmap.c of the comedilib distribution for an example
of using that support.

Since these files are derivatives of RTAI sources I offer them under the
same licenses and the same warranty disclaimer :-)

Good luck

  Andreas Leuner