Mixing Int8 and float in CCS C math

[rovtech]

Doing math in CCS C
Y = mX + B
where Y and X are 8 bit integers (max 255), B is a constant 35, and m is a fraction 0.374
X and B get promoted in the expression to float for the evaluation, and the result is demoted by assignment to integer in Y. X remains int8 after the expression is evaluated.
Since mX + B can never exceed 255 then Y, X, and B can all be int8.
Am I correct? I don't want to have to test this on a PIC with a display.
Can I write the expression so B does not get promoted to float?

[temtronic]

hmm, my first idea is to just code using 'scaled integers'.....

m becomes 374 instead of .374. Y,X and B have to be scaled as well....

this eliminates floats AND decreases the 'time of calculation by 10-15x.
,it'll also reduce code space a LOT as well.

others will reply that do this daily.
PICs don't play well with 'floats'.

Jay

[PCM programmer]

[rovtech]

Thank you, I use MPLAB 8.92
I read the link but see a problem. My clock is 32kHz so this may not work.
I wasn't looking for another project but appreciate learning about it and will try it when I have time.
For now I like Y = (374 * X)/1000 +35 and can try it but that product can be as high as 95,370 (374 * 255) so can X still be Int8?
I thought there may be a way using casting to do this.

What about what I originally asked? Are my assumptions correct?
Since the PIC16F1509 is dedicated to running 4 PWM at 50 Hz it has lots of memory and time. It gets an I2C update about once a second.

[PCM programmer]

0.374 x 255 = 95.37 and then add 35 to that and you get 130.7.
So yes, as long as m is always 0.374 and B is 35, you can use int8
variables for X, Y, and B.

[Ttelmah]

and, in answer to:

"Can I write the expression so B does not get promoted to float?".
Yes:

Y = (int8)(m*X) + B;

Will evaluate m*x as float, then convert this to int8, and add the result to
B. So with the example of X=255, you get:

255*.374 = 95.37 -> gives 95 as an int.
95+35 = 130.

However it is also worth realising that the error between 0.374 and 0.375
is less than one in this. So you could use:

[rovtech]

Thank you all, these are exactly the ideas I was hoping for but easier than I anticipated.
The problem of slow clock I am using got me re-thinking where to do the math. Briefly, my submersible ROV has a slave PIC in the surface control console that reads switches, pots, and a Joystick. It passes the results to the Master PIC that sends, down 300ft of tether, to a Master PIC in the ROV which sends to various slaves including one that controls the servos. The climb/dive byte from the Joystick is X in the equation but also goes to my side thruster rotate control PIC that uses a motor and feedback pot so I cannot change X in the console. I could do the math in the ROV master PIC before it passes the data to the slave servo PIC. I don't want to mess with the Master PIC and slow it down. Just thinking aloud.
The math changes 0 to 5v from the Joystick to be 800 to 1800 uS pulses out of the PWM of the PIC at 50 Hz. Either variable is Int8 so it does not matter where the math is done except for speed and efficiency. It might be simpler to send an extra separate byte from the surface.
I will try PCM Programmers suggestion of using the UART1 feature of MPLAB in my Console slave PIC to confirm the math. It will be a very useful debug tool for me.
Updating from using delays to PWM is turning out to be unpleasant. However adding 2 more servos to rotate the camera and a sonar transducer dictate the change.

I also see that .375 = 3/8 so I can use
Y = ((3/8) * X) + B which Ttelmah used, but why that way?
Using X/4 in place of t in your equation gives Y=X/4 + (X/4)(1/2) + B
So 2X/8 + X/8 = 3/8 X why not use this?

However the m is the slope of a line and can easily be different for different ranges of servo travel. I must use float. I like Ttelmah's
Y = (int8)(m*X) + B;
I wonder if my 32kHz PIC can handle this. This would be the easiest solution.

[Ttelmah]

Key is that if you do *3, this has to use the generic integer multiply.
Now /2, /4 & /8 in integer can all be optimised to a simple rotation.
So generating /4 and /2 each only use a couple of instructions. 3/8,
will use tens of instructions.
You could optimise it as X+=(X*2), then X/=8, which would be quite
efficient.

[rovtech]

To get a PWM frequency of 50 Hz compatible with RC servos I had to use 31.25 kHz and a PR2 of 156. I measured the time for a loop of While (1) without the math, with the math, and with the math and cast as Ttelmah described. Slope m wound up at 0.14 so the exercise was well worth the effort.
Since 31.25 KHz froze my I2C communications I used 2 MHz and setup_timer_2(T2_DIV_BY_64,156,1) to retain the PRW 50 Hz and measured the times again.

31.25 kHz
No math = 3.6 mS
mX+B = 133 mS
Int8)(mX)+b = 110 mS

2 MHz
No math = 16 uS
mX+B = 1.7 mS
Int8)(mX)+b = 1.6 mS

My Rudder, Elevator, and Camera Tilt are working beautifully.
Thanks for the help.
Peter

[alan]

Just my 2c worth. Been using Horner method very sucessfully in floating point multiplication and division and works like a dream.

See TI app note