Need some fixed point math help,

[iso9001]

I need to read in a 16bit number from ADC and then modify it by a certain percentage. I searched but found no examples of anyone doing this, (I know, I know, keep reading)

I read that Floating point is slow and fixed point is better, but I just can't see how to do fixed point with the data I have since I need to send it over spi as the modified number when finished

ex:

[Guest]

I'de like to know how to do this also.

I am was working on somthing like this awhile back. I used floating point but I had 100ms between samples so I really could do whatever I wanted. Did feel a little guilty using floating point

[Ttelmah]

Normally, when working with integers like this, you keep the integer scaled. So (for instance), you might multiply the incoming number by 100, and then only divide it back at the end of whatever operations you want. For the simple scaling here, provided you are only multiplying, then staying with a float, is probably the best solution. A float multiplication, on a 40MHz PIC18, only takes typically 36uSec (remember these chips have a hardware 8*8 multiplier, which makes a big difference). There will be some overhead, converting back from float to integer, but the total from using int arithmetic is not likely to be much better. Where things improve a lot, is on things like division, where a float divide easily takes 4* the time of an int16 divide, and things like sin, where the time shoots up.
I'd suggest that the fastest solution, would be:

[rberek]

You can also do a multiplication by 1.204 as a shift and add operation. It will not be exact but you can get it within 21 parts per million if you are using a 16-bit x value.

x * 1.204 is approximately equal to

x + x/8 + x/16 + x/64 + x/2048 + x/4096 + x/8192

or

x + x>>3 + x>>4 + x>>6 + x>>11 + x>>12 + x>>13

Actually this gives you x*1.203979 which should be close enough for most people.

I don't know how this works as far as speed goes, but I offer it as an alternative.
_________________
The difference between genius and stupidity is that genius has its limits...

[Ttelmah]

I suspect it'll be slower on the 18 chips, but might be better on the 16 chips (because of the lack of the hardware multiplier). You'd probably be better to shift a temporary store, otherwise there is a lot of 'repeat shifting' going on. Certainly in many cases, an approach like this is well worth considering.

Best Wishes

[iso9001]

Freakin sweet! I like both.

I feel rather dumb for forgeting to * 1.204 and not *.204+x. Don't know what I was thinking.

I know the 18F has the hardware multiply, but going off of CCS's chart in the help file it looks like my mulitply will take ~360 instructions like Ttelmah said. I need to do this twice in a row for two different numbers so I almost thinking 360x2 is near the time limit I have.

I really like the shifting. That seems to me like it would be less then ~350, but I have no idea yet.

I'll need to look closer at how you figured out the shift pattern. I don't get it but I only glanced at it for a second.

Wanted to say thanks, I'll try a bunch of different ways out and time them all

Ttelmah: Shift a temporary store ??

[rberek]

Its just binary math.

When you do an integer binary multiplication, like 56x11, you'd do

[Mark]

If your percentage is fixed at 20.4% then multiplying by 209 and dividing by 1024 will give you 20.41%. The divide by 1024 will be fast since its a binary number. If you can live with 20.3% then you could just multiply by 52 and truncate the last byte.

[Holy Ghost]

Wow, Nice to see that Mark has made a "comeback" to the forum.. Cheers..

[Mark]

I've been quite busy (and still am) at work and started shifting towards ARM7's which accounts for my lack of participation