- From: Frank Mori Hess <fmhess_at_users.sourceforge.net>
- Date: Fri, 9 Aug 2002 12:48:03 -0600
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 09 August 2002 09:35, Calin A. Culianu wrote: > Hmm... how about the following: > > 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. > > 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). > > My motivation for proposing this is that in my (possibly deranged) mind > you want the comedi API to be kept as simple as possible. You don't want > special cases in the application for when it needs to call > comedi_data_read() versus comedi_data_read_delayed(). You want > comedi_data_read() to _always_ return a pure, unaffected, clean, > undistored, verbatim signal from the board as it is on the wire coming > into the board... even if in some cases it takes it a few extra > microseconds to accomplish this.. at least it accomplishes this > _correctly_. > > <rant> > > Forgive the cheekiness of the following, but in my opinion the whole > business with the comedi_data_read_delayed() and read_hint() stuff that I > see in comedi cvs now is really bad from a design standpoint. The API is > being increased in size (these functions have just been added) to > compensate for some basic driver inadequacies.. Instead of adding these > functions, and confusing your application programmers, and making the > whole comedi API bigger for no good reason, why not fix the drivers? > > Currently, calling comedi_data_read() returns correct values _most_ of the > time for _most_ drivers and _most_ situations, but not for _100%_ of the > drivers nor _100%_ of the situations.... is this what we want? > > > I understand, however, that this might involve rewriting a bunch of > drivers so they keep track of _if_ they need to internally do a > read_hint-equivalent before a rinsn.... but I am asking you guys if you > think that at least in principle this effort would be worth it..? Why > expand the API to compensate for driver quirks? Makes no sense to me.. > > </rant> Actually, I agree, at least for read insn from user-space. It probably wouldn't be appropriate for kcomedilib with all the RT expectations. It would not require much modification of drivers, except adding a field that lets a driver specify the settling times it needs. The core module could keep track of what the last range was and if it has changed. Dave, what do you think? - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9VA5l5vihyNWuA4URAsXdAKCixky8rbx08trmMy/ftmoCz7M9WACgziTZ gcQKOurjGA6nc53Slji8pkw= =IBRC -----END PGP SIGNATURE-----
Received on 2002-08-09Z17:48:03