Servo 'smoothing'

[Bomberofdoom]

Originally Posted by Alan Anderson

// DISCLAIMER: THIS CODE IS UNTESTED

// declare some variables at the beginning of the code
char incount = 0; // this will count the input values being accumulated
int accumulator = 0; // this will accumulate input values
char smooth = 128; // this will hold the smoothed input value

// ....

// do this each time a new OI value is available
  accumulator += (int)potval; // replace 'potval' as appropriate, e.g. p1_aux
  if( incount++ == 8 ) // is this the eighth sample?
  {
    smooth = accumulator << 3; // a quick and sneaky way to divide by 8
    incount = 0; // set to count another eight samples
    accumulator = 0; // reset accumulator
  }

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 ).

[Kevin Sevcik]

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.

[dgitz]

Put your signal line on an o-scope and you can look at the jitter there. I would try then putting a low-pass filter on it to reduce some of the noise. my 2 cents.

[DonRotolo]

Originally Posted by Kevin Sevcik

Averaging 8 samples of the same number obviously isn't very helpful!

But it does make for an easier calculation !!

[Bomberofdoom]

Kevin,

What I meant was does the processor really increment incount by putting that line inside an if statment.

But I presume it does, since eveyone is saying the code is correct.

[rwood359]

Originally Posted by Bomberofdoom

Kevin,

What I meant was does the processor really increment incount by putting that line inside an if statment.

But I presume it does, since eveyone is saying the code is correct.

The table at:
http://www.difranco.net/cop2220/op-prec.htm (see Note 2)
shows the precedence of operators.
In the IF statement, the compare will be evaluated, then incount will be incremented.

[EricVanWyk]

Originally Posted by Kevin Sevcik

Bomber,

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.

I don't want to belabor the point too heavily, but that future is currently in boxes on its way to the beta test teams. I'm going to follow with a lot of boring technical blah blah blah, but the conclusion is pretty simple to follow:

DON'T OVER OPTIMIZE

A fixed point multiply takes two or three clock cycles to execute.
A single precision floating point multiply takes three clock cycles to execute.
A double precision floating point multiply takes four clock cycles to execute.

In addition to the "execute" phase, each instruction must also go through fetch, decode/dispatch, and complete, which adds three more clock cycles.

Simply put, the difference between single fixed or floating instructions just don't matter any more. What will matter is how many instructions. By converting to fixed point math (and adding the shift instructions), you actually slowed down the filter.

To make things even more interesting, the processor is capable of dispatching up to 2 instructions per clock, but only if they are different types of instructions: You can dispatch a fixed point and a floating point instruction simultaneously, but you can't do the same with two fixed point instructions.

This means that you are *much* better off allowing a compiler to order your instructions. Write what you mean, and trust in the compiler.


- Eric (with a C)

PS:
Eliminating divides are almost worth your time.
Fixed point divides take 20 cycles to execute.
Floating point divides take 18 (single precision) or 33 (double precision) cycles to execute. For reference sake, a double precision divide on the cRIO takes about the same amount of time as an 8 bit fixed point instruction on the PIC. However, it will also be executing fixed point math while the FPU is working on the divide.

[Kevin Sevcik]

Originally Posted by EricVanWyk

I don't want to belabor the point too heavily, but that future is currently in boxes on its way to the beta test teams. I'm going to follow with a lot of boring technical blah blah blah, but the conclusion is pretty simple to follow.

Eric (sorry about the k),

To be brief, I wasn't maintaining that fixed point math is faster or would make more sense for most operations on the cRIO. NI's processor selection obviously makes that untrue. Two points remain, however:

1. At some point, we'll hopefully be given access to the FPGA behind the RIO in cRIO. Floating point math is more or less untenable on this FPGA. If a team wants to do fast filtering, averaging, oversampling, etc. with no extra processor load, fixed-point on the FPGA is the way to go. Many interesting applications on the FPGA are going to require some sort of fixed point math, really.

2. Fixed point math is loads faster on processors designed with it in mind and such processors consume less power to do the same amount of work as a floating point processor. I was attempting to point this out so everyone reading the thread didn't simply consign fixed-point to the dustbin of history. There's a reason the big DSP makers are still designing and making new fixed-point DSPs, after all.