- From: Calin A. Culianu <calin_at_ajvar.org>
- Date: Mon, 12 Aug 2002 11:35:03 -0400 (EDT)
On Fri, 9 Aug 2002, David Schleef wrote: > > It was decided a long time ago that this is an application-level > concern. The main reason is because handling all the cases where Oh. Well I missed that discussion.. but in principle I am glad we all agree that it would be great to see this type of thing solved in the drivers... even if it is not gracefully possible to do it... > In the interest of being cheeky, I provide a bulleted list of some > of the reasons that went into the decision: Not cheeky at all! I appreciate the thoroughness of the following explanation. It helped me grasp how complex the problem of settling times really is... > > - 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? > Yeah this seems hit or miss and still error prone. The driver writer would have to test a lot of cases and use some measuring equipment to make sure he was waiting long enough but not too long, and that he wasn't waiting at all if he didn't need to. Some driver authors could get really thorough with this while some may not choose to be as thorough. In the end, you end up with a situation where you have all this settling infrastructure in place and still not all of your drivers are 100% accurate with respect to having settled long enough... > - 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. > Eek. :( > - 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!) > Wow that sucks. I never realized multiplexers are so quirky! I naively figured they all have a relatively short settling time that covered even the most extreme cases.. :( Still though, this could still be handled intelligently. You would either turn off settling waits altogether, then you don't have any slowdown at all, or you would turn them on, and wait as long as you need to. I still make the argument that slow data is better than bad data (in some cases)! As long as you can tell the driver what you prefer... it's not so bad to occasionally prefer one over the other. However, I do appreciate the difficulty of the problem of solving settling times, and do respect the decision to ignore them in the driver and let the application decide what it needs to do. > - 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. > Well you wouldn't need to be breaking the binary structs that the kernel expects from userland. With one approach, you could just add another instruction called INSN_SETTLING_LEVEL or something whose data field could be the 'settling accuracy level'. In fact, to be compatible with older versions of comedilib, you could default the INSN_SETTLING_LEVEL on all subdevices of all drivers to '0' which could mean "settling time wait is off in all cases"... that way old code would still work exactly the same with no unexpected delays, and new code would have the option of leveraging the intelligence of the driver in auto-settling when it needs to. > - Anything that can be done in user space should be. =) > Yes, that's true.. except for poor anachronistic RT programmers still stuck in the kernel, like me. :( > - At the time when the decision was made, speed was a higher concern > among the (vocal) user base. > Hehe... too bad I wasn't there for those debates. It would have been fun to argue with the best of 'em. :) This is application/problem-specific and user-specific... You can theoretically please both crowds if you wanted to, but I am beginning to grasp how pleasing the correctness people like me is a losing battle, as you have just made me appreciate how complicated the sitation is with settling times. :/ > - Speed is still the primary optimization, since you can work around > accuracy issues, but not speed. > I argue that you could in principle have both. At the cost of making the drivers more complex to maintain due to extra logic for settling levels, you could possibly have user-configurable settling levels, as mentioned above. You could default all drivers to 'no settling time' as is the case right now, and if a comedi user wanted to sacrifice some speed in favor of accuracy, s/he would bump up the settling level accuracy a few notches, depending on how accurate s/he wanted to be. This way you have the best of both worlds... Dave, I never realized that the settling accuracy issues are so complicated. That being said, I still have to reiterate how I really would like to, as an application writer, be able to magically rely on the driver for things like settling times, which is board-specific information and should (ideally) not be statically built into any application. But then again, who am I? I think you guys have done great work on Comedi thus far, and my wishes are simply in the spirit of wanting to make comedi as perfect as possible... However, here's my problem: Right now, if I were working on some generic data-acquisition and control tool for Linux, and I wanted to use comedi, and I wanted my app to be able to sample data as correctly as possible -- I would have to maintain a separate database of settling times for each board, for each situation. I would have to make sure that my list of boards is up-to-date with respect to comedi. I would have to, in essence, do some of the work the driver would be doing ideally. :( That being said, at least for right now, I would be nice to be able to ask the driver "how long should I wait?". However, the answer to that question is difficult to answer, since you are telling me that it depends heavily on the situation and on the board. Oh well.. thanks for the insights, Dave... -Calin
Received on 2002-08-12Z14:35:03