Re: Strangeness with cb_pcidas and 1602/16 board

On Fri, Aug 09, 2002 at 11:35:12AM -0400, Calin A. Culianu wrote:
> Is it at all feasible to consider keeping track of the multiplexer state
> (if at all possible) and in the case where its state hasn't changed (you
> are reading from the same channel over and over again, with the same
> gain/aref settings), not reprogramming the multiplexer.

This is done by some of the drivers, and is encouraged.  A read
instruction with insn->n == 0 should be interpreted by drivers
to set the channel/gain list only.

> However, in the case where its state needs to change, reprogramming it,
> then introducing the proper amount of delay before issuing the read
> instruction (or doing the read instruction twice if that is more of a
> guarantee that the board will give correct data).

It was decided a long time ago that this is an application-level
concern.  The main reason is because handling all the cases where
the driver could be returning inaccurate data are quite numerous,
and balancing those needs in every case with the need to be fast
proved to be difficult.

In the interest of being cheeky, I provide a bulleted list of some
of the reasons that went into the decision:

- Most devices (at the time) did not have proper settling time
  documentation.  Sure, they have "0.02% within 50 us", but does
  that mean that the driver should wait 50 us _every time_ it
  changes the channel/gain setting?
  
- What is the proper settling accuracy?  1 bit?  0.5 bit?  Should
  this be made configurable?  If it's configurable, on the driver,
  subdevice, or insn level?

- Settling times are longer when switching from low gain to high
  gain rather than from high to low, by up to a factor of 1000.

- Out-of-range performance is typically piss-poor on most boards.
  That is, if channel 0 is +15V, and you're measuring it on a
  range of [-10,10] V, and then switch to channel 1, which is 0 V,
  on a range of [-10,10] V, it may take many milliseconds for the
  multiplexer to recover.  (milliseconds!)

- I've seen 24-bit and 28-bit boards with settling times of 10's of
  ms.  I didn't want to have to make a special exception for these
  boards.

- Commands have to be tested so that convert_arg is longer than the
  longest settling time.  (Right now, you can be smart, and add a
  dummy channel.)

- Some drivers allow convert_src=TRIG_EXT.  The boards check for
  A/D converter overrun, but not settling time overrun.

- A flag would need to be added to the user/kernel API to turn off
  the settling time wait.  Note that in the current situation,
  everything is handled by insnlists, which makes the user/kernel API
  simpler.

- Anything that can be done in user space should be.  =)

- At the time when the decision was made, speed was a higher concern
  among the (vocal) user base.

- Speed is still the primary optimization, since you can work around
  accuracy issues, but not speed.

> My motivation for proposing this is that in my (possibly deranged) mind
> you want the comedi API to be kept as simple as possible.

Not really.  I add Comedilib functions when they are useful.



dave...

Received on 2002-08-09Z19:29:08