Re: New buffer reading behaviour in continuous acquisition mode?

On Thu, 30 Jan 2003, Frank Mori Hess wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thursday 30 January 2003 08:14 am, Herman Bruyninckx wrote:
> >
> > So, this is my summary of our findings.
> > Comedi has "commands" and "instructions". A command programs the
> > hardware of the bord to _autonomously_ do acquisition; i.e., the
> > software can go and do other things while a command is executing,
> > interrupted from time to time by DMA or an ISR.
> > In an instruction however, the software is doing acquisition _in busy
> > waiting_. (At least in the current implementation of the NI driver where
> > is see a polling on the buffer-not-empty flag.)
>
> There are several types of insn, specified by the value of comedi_insn.insn.
> The possible values are defined in comedi.h:
>
> #define INSN_READ		( 0 | INSN_MASK_READ)
> #define INSN_WRITE		( 1 | INSN_MASK_WRITE)
> #define INSN_BITS		( 2 | INSN_MASK_READ|INSN_MASK_WRITE)
> #define INSN_CONFIG		( 3 | INSN_MASK_READ|INSN_MASK_WRITE)
> #define INSN_GTOD		( 4 | INSN_MASK_READ|INSN_MASK_SPECIAL)
> #define INSN_WAIT		( 5 | INSN_MASK_WRITE|INSN_MASK_SPECIAL)
> #define INSN_INTTRIG		( 6 | INSN_MASK_WRITE|INSN_MASK_SPECIAL)

This is okay for me, and it reasonably well documented. But the spec
says nothing about _how_ the instructions are implemented; hence, the
real-time behaviour is not explicitly known.
>
> Above you describe the behaviour of INSN_READ and INSN_WRITE.  What you want
> to be doing is using a INSN_CONFIG to modify the behaviour of commands.
>
Yes, but IMHO "modify the behaviour of commands" lead to nothing but
chaos! A common structure such as Comedi is useful, but only where it
can suggest a good common API for a whole range of DAQ cards and
applications. This INSN_CONFIG thing to make an instruction "a la carte"
is something I don't like too much...

> > And the API is indeed available to program a sequence of say 6
> > measurements in one instruction (or instruction list). But, one looses
> > the real-time determinism when doing this with instructions, and/or the
> > performance.
>
> No, I'm not suggesting you use INSN_READ, you still get the data using
> commands.

But our way of getting real-time deterministic sequences of samples
cannot be done by commands... Not with the current API, as far as I see,
because the existing description of INSN_CONFIG is (i) not suitable for
describing the behaviour we need, and (ii) it's utterly confusing to
have to use somehting with the name INSN_CONFIG to adapt a _command_,
because instructions and commands are inherently two different and
complementary ways of doing acquisitions. At least, that's what I
understand from reading the documentation and the code... Please, tell
me that I am wrong :-) (And explain where I am wrong too! :-)

Herman
-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480

Received on 2003-01-30Z18:34:02