Quote:
Originally Posted by Bomberofdoom
Does the incount++ action actually happen? I mean, when you check if the "if" statment is true, does the Microprocessor increase the valuce of incount? If it doesn't work, this should be done in a for loop, but if this "if" statment counts as a loop, then OK (it's just a method of a loop i've never seen before  ). |
Bomber,
As with most things in the IFI RC, a for loop wouldn't work here. Remember that for the vast majority of things you do in the IFI RC, you do something once in one pass of the "slow loop", then wait 26.2ms for the next "slow loop" pass, and then do the next step in the sequence. What we're trying to do is measure the input signal at several different points in time, then average those measurements. If we were to use a for loop, the measurement we'd be taking would be very very close together in time on an analog input, or exactly the same if we're looking at a value from the operator interface. Averaging 8 samples of the same number obviously isn't very helpful!
So, since we want some time to pass, we just record one sample of the value during a single pass of the "slow loop" then wait until the next pass to take another one. In Alan's code, once we've built up 8 of these samples, we average them all together. Then the next time through the slow loop, we start all over again.
So to answer your question, this isn't a traditional for loop like you usually think of them. We have a timed, (nominally) infinitely repeating loop to work inside of, and this if statement lets us do something
like a for loop inside this timed loop.
Also, I think Alan meant:
if( ++incount == 8) // is this the eighth sample?
as he's using a zero-based count, so you'd want to stop when count + 1 == 8.
Also to Erik and viewers at home,
The domain of tau is obviously changeable with the #define SCL. To move to a 0..255 range, you'd state #define SCL 8. It's important to note that at that point, you can't have an equivalent of tau=1.0, which basically removes the effect of the filter. Also, fixed point math may be painful at times, but it is and always* will be stupendously faster than floating point. If our audience members are at all interested in programming embedded controllers and/or high speed DSPs in the future, it can't hurt to look into fixed point math and play around with it.
*For the foreseeable future, until FPUs are fast enough that you couldn't possibly want to do things any faster than they can be done with floating point.