- From: David Schleef <ds_at_schleef.org>
- Date: Wed, 2 Oct 2002 14:27:23 -0700
On Wed, Oct 02, 2002 at 05:02:13PM -0400, Calin A. Culianu wrote: > > I understand what you are saying... but I am still a bit confused. Then > what do they mean by 5us A/D conversion time? Is that time used by other > parts of the board to populate voltage values into registers and whatnot? > So the real bottleneck is not the A/D converter itself, but talking to the > board's hardware, etc? 5 us is the time that the A/D converter is "busy", also the latency between when the analog signal is latched (sampled and held) and when the digital signal is output. If you're not changing channels, the amount of time that the A/D converter is busy is, of course, the main limitation. This is a hard limitation -- the A/D converter will just not work any faster. The multiplexer, since it's an analog curcuit, will simply be inaccurate if you run it faster than spec. It may be simpler to think about it in terms of external triggering. The board must latch on to the analog signal (on the correct channel) within a few nanoseconds of getting the external trigger. This means that the mux must already be settled on the correct channel. This is most easily done by switching the mux to the next channel as soon as the A/D converter latches. > Also, I remember a while back we were talking about some sort of mux > settling time infrastructure within comedi (so that comedilib and > kcomedilib application programmers have a way of determining how long to > wait for their muxes -- without having to maintain board-specific > information in their application). I forget where we left off on that... I think we agreed that a worst case 1 LSB mux settling time should be added to the subdinfo structure. In fact, the subdinfo structure (in CVS) has a "settling_time_0" field. None of the drivers use it. =) dave...
Received on 2002-10-02Z20:27:23