El 5 de octubre de 2011 18:28, Alexis Berlemont <[email protected]>escribió:
> 2011/10/5 Fernando Herrero Carrón <[email protected]>: > > > > > > 2011/10/5 Gilles Chanteperdrix <[email protected]> > >> > >> On 10/05/2011 09:48 AM, Julien Delange wrote: > >> > On Tue, Oct 4, 2011 at 12:41 PM, Gilles Chanteperdrix > >> > <[email protected]> wrote: > >> >> Another mail in that thread seem to suggest that it could be long. > Have > >> >> you tried timing the various parts of your loop to see where the time > >> >> is > >> >> spent? > >> > > >> > No, sorry, my bad. Unfortunately, I cannot make more tests at this > >> > time because I don't have the hardware. > >> > I will do additional investigation soon, I would have access to the > >> > acquisition card soon. My intent was to know if there was an obvious > >> > error either in my code or in my kernel configuration. Apparently not, > >> > so, I will try to figure out the root causes of these issues. > >> > >> It is my understaning when reading Fernando's answer to your mail that > >> you are not using the proper interface for what you are trying to do. > >> > > > > Yes, my suggestion is to use a different interface that will definitely > > provide higher acquisition speeds. However I am wondering if using the > > "instruction" interface the delay would be over the milliseconds. I'm > > recalling some tests that I did using comedi in linux user-space, that is > > without any real-time support software. I could acquire 8 channels and > the > > board's internal timer using the instruction list technique at 120us > > (microseconds) intervals. However my board has 8 parallel ADCs (NI 6143), > so > > check if yours has parallel or serial converters. If it has to serialize > > conversions then the overall acquisition period will increase. > > > > Back to your code, are you sure about "insn_tab[i].data_size = 8;"? > Try > > data_size = 1 instead. > > > > The field data_size is supposed to hold the size of the acquisition in > bytes. > > If you have an 8bits converter, 1 is OK; but according to the driver > Julien contributed, the converter width is 16bits. > Oh, I see, thanks for pointing this out. On the code I had working with comedi I used 1 for subdevices providing "sampl_t" samples (2 bytes) and 2 for subdevices providing "lsampl_t" samples (4 bytes) (timer/counter subdevices, for instance). I really think that rationale is misleading, and find working in terms of bytes much saner! In any case, using 8 as Julien does seems to not be correct. Best regards, Fernando
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
