- From: Calin A. Culianu <calin_at_ajvar.org>
- Date: Fri, 9 Aug 2002 11:35:12 -0400 (EDT)
> Yes, the multiplexer is not changed until you call comedi_data_read() and > there is no settling delay between setting the multiplexer and starting the > conversion. comedi_data_read_hint() can be called to set the multiplexer > before you do your usleep, or comedi_data_read_delayed() will delay for the > specified amount between setting the multiplexer and doing a conversion. > 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> -Calin
Received on 2002-08-09Z14:35:12