On 09/10/2007 09:08 AM, Krzysztof Helt wrote:
Rene wrote:
Which seems to be saying that we should be waiting for only 5 cycles at that point. With the slowest (!) possible sampling rate of 5.5125 kHz that would mean 907 us, or sligtly under 1 ms.
It does not matter. If you have to wait for the start of the auto-calibration then for the end of auto-calibration you may as well wait for the end of the auto-calibration only (unless you want to follow the auto-calibration to the very single clock pulse ;-). The delay here is simple to assure that auto-calibration started (and probably is already under way). It may be longer then the start but it should not be longer than whole auto-calibration.
I simply tried to do as long msleep as possible to allow other tasks using CPU and decrease number of waiting loop iterations.
Well, no, sorry, but I consider that to be completely breaking the logic of the code. One line after this bit, we're doing the "wait for calibration to finish" loop (and already schedule ourselves away while doing so, for 250ms no less) meaning that at this point we should only wait long enough to be guaranteed that the ACI bit reflects reality -- those 5 cycles.
Your: wait unconditionally until calibration _nearly_ done, then go wait for it for 250 ms to be really done.
Mine: wait unconditionally until calibration has started, then go wait for it for 250 ms to finish.
Really -- please just do the 1 ms delay for ad1848 and either no delay or the same 1 ms for cs4231 if you want to keep them in sync (and the comment explaining why it's 1 ms). I don't particularly care about mdelay versus msleep here (although a mere 1 ms fits mdelay better) but your setup is pointlessly obscuring the code-flow.
Rene.