[Joe Johnson]

A slightly related issue to this one is to avoid all the if tests to decide if a result is positive or negative before dividing.

This used to be a real coding headache before this year's if then else, but it can still be a cause for ugly code if you have to test 3 or 4 or more expressions to see if they are positive or negative before using them.

This is a pretty ugly work around but it can be the least ugly option at times.

The idea is to shift right until you have the "sign bit" then subract this twice this number from one. The result is 1 if the expression was positive and -1 if the expression is negative.

It looks like this:

PwmArm = 127 + (1 - (ArmPot - ArmDesired >> 15 << 1)) * (ABS (ArmPot - ArmDesired) * ARM_GAIN)

If there are a lot of tests that you have to do to see if this quantity is positive and this other quantity is negative and yet anther quantity is positive then you end up with 8 SLIGHTLY different expressions for PwmArm which can drive you nuts. It is very difficult to get all the signs correct in 8 different expressions.

For what it is worth.

Joe J.

P.S. For those who want to do "swerve" (a.k.a. crab steering), this method is very very useful -- the adjustment to gas and steering angle are complicated enough without having to debug spagetti code.