[Xenomai-help] COMEDI vs Analogy

[Xenomai-help] COMEDI vs Analogy

[Daniele Nicolodi]

Hello. Now that i have most of my data acquisition application
infrastructure mostly working it is time to get real data.

In my non-RT code I successfully use Comedi drivers and I saw some work
for make those work over RTDM. However in the latest source tree I see
only references to the newer Analogy drivers.

It looks like Analogy is the evolution of Comedi+RTDM, however it
supports a mush smaller range of devices. There is still a way to use
Comedi with RTDM or Analogy is the only way forward?

Comedi is now included into the staging kernel drivers. There is any
plan to merge the Analogy and Comedi efforts? It would be unfortunate to
end up with two independent sets of drivers and user land libraries.

Thanks. Cheers,
-- 
Daniele

Re: [Xenomai-help] COMEDI vs Analogy

[Stefan Kisdaroczi]

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

Am 09.03.2010 18:28, schrieb Daniele Nicolodi:
> Hello. Now that i have most of my data acquisition application
> infrastructure mostly working it is time to get real data.
> 
> In my non-RT code I successfully use Comedi drivers and I saw some work
> for make those work over RTDM. However in the latest source tree I see
> only references to the newer Analogy drivers.
> 
> It looks like Analogy is the evolution of Comedi+RTDM, however it
> supports a mush smaller range of devices. There is still a way to use
> Comedi with RTDM or Analogy is the only way forward?
> 
> Comedi is now included into the staging kernel drivers. There is any
> plan to merge the Analogy and Comedi efforts? It would be unfortunate to
> end up with two independent sets of drivers and user land libraries.
> 
> Thanks. Cheers,

Hi Daniele,

https://mail.gna.org/public/xenomai-core/2009-09/msg00016.html

regards, Stefan


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

Re: [Xenomai-help] COMEDI vs Analogy

[Daniele Nicolodi]

Stefan Kisdaroczi wrote:
> Hi Daniele,
> 
> https://mail.gna.org/public/xenomai-core/2009-09/msg00016.html
> 
> regards, Stefan

Thanks Stefan for the pointer. Your link contains almost everything I
want to know. I agree that Comedi design is far from perfect and I
appreciate the effort of coding something better. However Comedi was a
functional solution, Analogy looks half backed. Even few drivers ported
from Comedi do not support all the functionalities of Comedi (my
application right now uses the TRIG_WAKE_EOS command functionality, that
the documentation report as not supported). And it does not cure all the
problems of Comedi (for example channel setup and data acquisition are
still coupled in a single operation in synchronous acquisitions).

I would like to have the possibility to use (the far from perfect but
working) Comedi over RTDM while Analogy is worked out. Would it be
possible to recover the early work done to port Comedi over RTDM and put
it to some use? Given enough informations I can try to do it myself.

Thanks. Best regards,
-- 
Daniele

Re: [Xenomai-help] COMEDI vs Analogy

[Philippe Gerum]

On Wed, 2010-03-10 at 12:14 +0100, Daniele Nicolodi wrote:
> Stefan Kisdaroczi wrote:
> > Hi Daniele,
> > 
> > https://mail.gna.org/public/xenomai-core/2009-09/msg00016.html
> > 
> > regards, Stefan
> 
> Thanks Stefan for the pointer. Your link contains almost everything I
> want to know. I agree that Comedi design is far from perfect and I
> appreciate the effort of coding something better. However Comedi was a
> functional solution, Analogy looks half backed. Even few drivers ported
> from Comedi do not support all the functionalities of Comedi (my
> application right now uses the TRIG_WAKE_EOS command functionality, that
> the documentation report as not supported). And it does not cure all the
> problems of Comedi (for example channel setup and data acquisition are
> still coupled in a single operation in synchronous acquisitions).
> 
> I would like to have the possibility to use (the far from perfect but
> working) Comedi over RTDM while Analogy is worked out. Would it be
> possible to recover the early work done to port Comedi over RTDM and put
> it to some use? Given enough informations I can try to do it myself.
> 

Beats me. Why do you assume that Comedi/RTDM provides more support
compared to Analogy, since it is stated that Analogy started off from
the Comedi/RTDM code base, months ago?

The reasons why you can't put original Comedi drivers on top of Analogy
did exist with Comedi/RTDM: the internal layers and APIs have been
refactored.

If you do want to help, you may want investing your time in developing
and testing a better code base like Analogy with other people, instead
of re-opening a dead development effort all alone.

> Thanks. Best regards,


-- 
Philippe.

Re: [Xenomai-help] COMEDI vs Analogy

[Daniele Nicolodi]

Philippe Gerum wrote:

>> I would like to have the possibility to use (the far from perfect but
>> working) Comedi over RTDM while Analogy is worked out. Would it be
>> possible to recover the early work done to port Comedi over RTDM and put
>> it to some use? Given enough informations I can try to do it myself.
> 
> Beats me. Why do you assume that Comedi/RTDM provides more support
> compared to Analogy, since it is stated that Analogy started off from
> the Comedi/RTDM code base, months ago?

Sorry for my misunderstanding. I simply thought that, since Comedi works
with RTAI and Xenomai offers similar interfaces, a Comedi port to
Xenomai was quite straight forward. It must not be so.

> If you do want to help, you may want investing your time in developing
> and testing a better code base like Analogy with other people, instead
> of re-opening a dead development effort all alone.

Unfortunately I do not have so much time to invest into this activity.
I'll simply check if the PREEMP_RT patch gives me low enough latencies,
otherwise I'll switch to use Comedi on top of RTAI (sadly, because I
prefer Xenomai and its posix api).

Thanks. Cheers,
-- 
Daniele

Re: [Xenomai-help] COMEDI vs Analogy

[Daniele Nicolodi]

Philippe Gerum wrote:
> If you do want to help, you may want investing your time in developing
> and testing a better code base like Analogy with other people, instead
> of re-opening a dead development effort all alone.

Let's try to have a more constructive approach. What is required  to
support the TRIG_WAKE_EOS command functionality in the ni pcimio driver
in Analogy?

Cheers,
-- 
Daniele

Re: [Xenomai-help] COMEDI vs Analogy

[Gilles Chanteperdrix]

Daniele Nicolodi wrote:
> Philippe Gerum wrote:
> 
>>> I would like to have the possibility to use (the far from perfect but
>>> working) Comedi over RTDM while Analogy is worked out. Would it be
>>> possible to recover the early work done to port Comedi over RTDM and put
>>> it to some use? Given enough informations I can try to do it myself.
>> Beats me. Why do you assume that Comedi/RTDM provides more support
>> compared to Analogy, since it is stated that Analogy started off from
>> the Comedi/RTDM code base, months ago?
> 
> Sorry for my misunderstanding. I simply thought that, since Comedi works
> with RTAI and Xenomai offers similar interfaces, a Comedi port to
> Xenomai was quite straight forward. It must not be so.
> 
>> If you do want to help, you may want investing your time in developing
>> and testing a better code base like Analogy with other people, instead
>> of re-opening a dead development effort all alone.
> 
> Unfortunately I do not have so much time to invest into this activity.
> I'll simply check if the PREEMP_RT patch gives me low enough latencies,
> otherwise I'll switch to use Comedi on top of RTAI (sadly, because I
> prefer Xenomai and its posix api).

You have read the mail, but apparently missed two points: Comedy is soon
to be no longer portable on RTAI. Out-of-tree Comedy will soon be
unmaintained, and Linux in-tree Comedy will no longer have the wrappers
which made it portable over RTAI.

So, Comedy over RTAI is a dead-end.

The second point is that Xenomai defined a skin for writing drivers:
RTDM, and Comedy obviously predates that skin, so the only acceptable
way of porting Comedy over Xenomai would be to port Comedy over RTDM,
which exactly is what Alex started, and resulted in Analogy.

So, there is no other choice than Analogy, for using Comedy over Xenomai.

-- 
					    Gilles.

Re: [Xenomai-help] COMEDI vs Analogy

[Daniele Nicolodi]

Gilles Chanteperdrix wrote:

> You have read the mail, but apparently missed two points: Comedy is soon
> to be no longer portable on RTAI. Out-of-tree Comedy will soon be
> unmaintained, and Linux in-tree Comedy will no longer have the wrappers
> which made it portable over RTAI.
> 
> So, Comedy over RTAI is a dead-end.

I understood this. But Comedi over RTAI works today (haven't tried that
myself, but I have seen some projects using this combination). It will
not work tomorrow, but I need a solution yesterday :-)

> The second point is that Xenomai defined a skin for writing drivers:
> RTDM, and Comedy obviously predates that skin, so the only acceptable
> way of porting Comedy over Xenomai would be to port Comedy over RTDM,
> which exactly is what Alex started, and resulted in Analogy.
> 
> So, there is no other choice than Analogy, for using Comedy over Xenomai.

I understood this too. But to me it was looking like there has been a
functional Comedi port to RTDM in the past, and that Analogy is more an
effort to clean up the Comedi implementation. I misunderstood this
second part.

PS: I'm sorry if some of my email sounded a bit harsh, but I'm a little
bit frustrated by the situation. I'm new to this kind of applications,
I'm a physicist more than a programmer. Xenomai works great, Comedi has
some rough edges, but finally I made it to work as I need. It is
disappointing to find out that those two do not work together and that I
have to rethink my application.

Thanks for the clarifications. Cheers,
-- 
Daniele

Re: [Xenomai-help] COMEDI vs Analogy

[Daniele Nicolodi]

Daniele Nicolodi wrote:
> Philippe Gerum wrote:
>> If you do want to help, you may want investing your time in developing
>> and testing a better code base like Analogy with other people, instead
>> of re-opening a dead development effort all alone.
> 
> Let's try to have a more constructive approach. What is required  to
> support the TRIG_WAKE_EOS command functionality in the ni pcimio driver
> in Analogy?

Well. After playing a bit with Analogy, it looks like TRIG_WAKE_EOS is
not unsupported (as is stated in the documentation). It works!

I'm using a NI 6251 PCI ADC. I have verified that TRIG_WAKE_EOS works as
expected up to a sampling frequency of 800-1000 Hz, sampling 8 channels
at time. If I use an higher sampling rate, my acquisition loops
receives, at each iteration, more data than the data corresponding at
one scan, but always in multiples of one scan.

I guess this is due to the fact that the reading process is not able to
keep peace with the ADC board. It is however strange that I'm unable to
go to higher sampling rates. I'm able to have, easily, periodic tasks
running up to more than 10 kHz. There is a way to improve the performance?

I tried to directly mmap the acqusition buffer, instead of doing copies
through reads, but it turned out that there are no Analogy drivers that
support mmap acces to the data buffer (not in xenomai 2.5.1 sources at
least). Can I somehow help in implementing this missing feature?

Thanks. Cheers,
-- 
Daniele

Re: [Xenomai-help] COMEDI vs Analogy

[Alexis Berlemont]

Hi,

Daniele Nicolodi wrote:
> Daniele Nicolodi wrote:
>> Philippe Gerum wrote:
>>> If you do want to help, you may want investing your time in developing
>>> and testing a better code base like Analogy with other people, instead
>>> of re-opening a dead development effort all alone.
>> Let's try to have a more constructive approach. What is required  to
>> support the TRIG_WAKE_EOS command functionality in the ni pcimio driver
>> in Analogy?
> 
> Well. After playing a bit with Analogy, it looks like TRIG_WAKE_EOS is
> not unsupported (as is stated in the documentation). It works!
> 
> I'm using a NI 6251 PCI ADC. I have verified that TRIG_WAKE_EOS works as
> expected up to a sampling frequency of 800-1000 Hz, sampling 8 channels
> at time. If I use an higher sampling rate, my acquisition loops
> receives, at each iteration, more data than the data corresponding at
> one scan, but always in multiples of one scan.
> 
> I guess this is due to the fact that the reading process is not able to
> keep peace with the ADC board. It is however strange that I'm unable to
> go to higher sampling rates. I'm able to have, easily, periodic tasks
> running up to more than 10 kHz. There is a way to improve the performance?
> 
> I tried to directly mmap the acqusition buffer, instead of doing copies
> through reads, but it turned out that there are no Analogy drivers that
> support mmap acces to the data buffer (not in xenomai 2.5.1 sources at
> least). Can I somehow help in implementing this missing feature?
> 
The mmap features is only enabled in the test drivers (fake and loop).
The reason is that I did not have enough time to test it on the driver
NI PCIMIO.

If you want to test it you just have to add a flag in the AI subdevice
descriptor (on the driver side, you just add the mmap

subd->flags |= A4L_SUBD_MMAP;

The NI PCIMIO driver contains so many functionalities that it takes me a
lot of time to test only a part of them. By the way, let's start a topic
I will develop in other mails. That may clarify a little bit the situation.

I went on holidays with two requests in mind:
- Stefan Schaal would like to use cmd_write on the NI digital subdevice;
- Cristian Axenie would like to get an API to configure the NI counting
subdevice.

I spent all my free time on them (when my wife and my daughter were
asleep) and I am still unable to provide them any suitable solution. And
do you know why ? I had a look at all the comedi drivers which
implements asynchronous digital transfers and counting features: each
one uses a different way.

The most striking examples were in the configuration of the counting
stuff. At least four comedi drivers manage gpct: the NI ones, s526,
me4000 and vmk80xx. Each one has defined its one configuration
instruction, in other words, its one interface. That means for me that a
user application must be specific to a driver to work properly (in some
cases, you must even give the registers values).

Such a situation is, for me, not acceptable. Any acquisition user
application should work with any acquisition driver and especially
because of the acquisition framework.

Starting from here, it is really difficult for me to find out what
interface I should implement so as to satisfy all of them.

One more thing: my job is related in no way with acquisition stuff. I
spent quite a lot of time in documentation reading (DAQ-STC, etc.) to be
sure I miss nothing. So, if you have experience to share, I am really
interested.

So to sum-up, that was just a few lines to explain why analogy is still
work in progress in many cases and why comedi still provides far more
features. I take great care in the API enrichment because I cannot
afford any API breakage in the near future.

With these practical anecdotes, I intend to make understand the main
reasons of the divergences between comedi and analogy. The divergence in
terms of implementation and API is real and I think it will continue.
However, I hope Analogy will soon match comedi in terms of features and
drivers, maybe with your help.

> Thanks. Cheers,

Alexis.

Re: [Xenomai-help] COMEDI vs Analogy

[Daniele Nicolodi]

Alexis Berlemont wrote:
> Hi,
> 
> Daniele Nicolodi wrote:
>> Daniele Nicolodi wrote:
>>> Philippe Gerum wrote:
>>>> If you do want to help, you may want investing your time in developing
>>>> and testing a better code base like Analogy with other people, instead
>>>> of re-opening a dead development effort all alone.
>>> Let's try to have a more constructive approach. What is required  to
>>> support the TRIG_WAKE_EOS command functionality in the ni pcimio driver
>>> in Analogy?
>> Well. After playing a bit with Analogy, it looks like TRIG_WAKE_EOS is
>> not unsupported (as is stated in the documentation). It works!
>>
>> I'm using a NI 6251 PCI ADC. I have verified that TRIG_WAKE_EOS works as
>> expected up to a sampling frequency of 800-1000 Hz, sampling 8 channels
>> at time. If I use an higher sampling rate, my acquisition loops
>> receives, at each iteration, more data than the data corresponding at
>> one scan, but always in multiples of one scan.
>>
>> I guess this is due to the fact that the reading process is not able to
>> keep peace with the ADC board. It is however strange that I'm unable to
>> go to higher sampling rates. I'm able to have, easily, periodic tasks
>> running up to more than 10 kHz. There is a way to improve the performance?
>>
>> I tried to directly mmap the acqusition buffer, instead of doing copies
>> through reads, but it turned out that there are no Analogy drivers that
>> support mmap acces to the data buffer (not in xenomai 2.5.1 sources at
>> least). Can I somehow help in implementing this missing feature?
>>
> The mmap features is only enabled in the test drivers (fake and loop).
> The reason is that I did not have enough time to test it on the driver
> NI PCIMIO.
> 
> If you want to test it you just have to add a flag in the AI subdevice
> descriptor (on the driver side, you just add the mmap
> 
> subd->flags |= A4L_SUBD_MMAP;
> 
> The NI PCIMIO driver contains so many functionalities that it takes me a
> lot of time to test only a part of them. By the way, let's start a topic
> I will develop in other mails. That may clarify a little bit the situation.
> 
> I went on holidays with two requests in mind:
> - Stefan Schaal would like to use cmd_write on the NI digital subdevice;
> - Cristian Axenie would like to get an API to configure the NI counting
> subdevice.
> 
> I spent all my free time on them (when my wife and my daughter were
> asleep) and I am still unable to provide them any suitable solution. And
> do you know why ? I had a look at all the comedi drivers which
> implements asynchronous digital transfers and counting features: each
> one uses a different way.
> 
> The most striking examples were in the configuration of the counting
> stuff. At least four comedi drivers manage gpct: the NI ones, s526,
> me4000 and vmk80xx. Each one has defined its one configuration
> instruction, in other words, its one interface. That means for me that a
> user application must be specific to a driver to work properly (in some
> cases, you must even give the registers values).
> 
> Such a situation is, for me, not acceptable. Any acquisition user
> application should work with any acquisition driver and especially
> because of the acquisition framework.
> 
> Starting from here, it is really difficult for me to find out what
> interface I should implement so as to satisfy all of them.
> 
> One more thing: my job is related in no way with acquisition stuff. I
> spent quite a lot of time in documentation reading (DAQ-STC, etc.) to be
> sure I miss nothing. So, if you have experience to share, I am really
> interested.

May I ask where your interest in data acquisition software arises from?
It may be difficult to understand the problems in data acquisition
software development if you never have to write one.

Cheers,
-- 
Daniele