Decimal point representation

Thread Starter

harry99932

Joined Dec 30, 2010
38
Hi guys,
Wonder if anyone can help me ive been working on my assembly routines for mid range pics but im getting a bit stuck with representing and working with decimal points, i,e multiply by 6.345 the only way i can think of getting around it is by shifting the multiplied number left of the decimal point enough places to bring the multiplier into whole numbers i.e to make 6.345 into 6345 then shift the result back down again.
I cant find a great amount of basic info on this, is this a reasonable way to go about the task or not?

Thanks a lot,
Harry
 

MrChips

Joined Oct 2, 2009
30,711
Yes. I do this all the time.

But why multiply by 100 or 1000, why not 256?

There are many tricks you can pull. You can limit yourself at the most to integer multiplication and not have to do divisions. Keep in mind that it is a simple task to divide or multiply by 256 or 65536.

For example, if you want to multiply by 12.34, then multiply by 3159 instead and then divide by 256.
Or, if you want to divide by 12.34, then multiply by 5311 and divide by 65536.

I can also show you easy ways to do N-point averaging. The list goes on and on... maybe I should write a chapter on integer arithmetic tricks...
 
Last edited:

MrChips

Joined Oct 2, 2009
30,711
Why not just use C and floating point numbers ?
Because it is slow and takes a lot of memory. Have you ever tried calculating dewpoint with 2K of memory space?
Besides, if you want to learn the most out of MCUs and programming, use assembler.
 
Last edited:

Thread Starter

harry99932

Joined Dec 30, 2010
38
brilliant thankyou mr chips im still getting my head around these sort of tricks maths isnt a huge strong point of mine and throwing what a pic can and cant do into the mix makes life a bit more interesting! from a quick look im guessing dividing a 16 bit number by 256 leaves the most significant byte as the result?

Nigel- because im a glutton for punishment and c is for girls:D
 

MrChips

Joined Oct 2, 2009
30,711
You are correct. Dividing by 256 means the hi-byte is the result.
Of course, I am leaving out a few details so that you can learn by yourself.
For example, make sure that you have enough room for the maximum number. 16-bit positive integers max is 65535.
If you want to do rounding, just add half of the divisor before dividing. For example, before using the hi-byte, add 128 to the 16-bit result. In other words, if the lo-byte is negative, add 1 to the hi-byte when dividing by 256. (Just some the things to think about.)

Of course the MCU model can make a big difference. I am a big fan of HC11 which makes 16-bit and 32-bit arithmetic fairly easy. Let's see the PIC do that!
 

Thread Starter

harry99932

Joined Dec 30, 2010
38
oooh youve just given me a mathematical epipheny!! no more skirting around the problems using opamps to do the maths:D thank you very much and you definatley should do a article on the matter!
 

ErnieM

Joined Apr 24, 2011
8,377
oooh youve just given me a mathematical epipheny!! no more skirting around the problems using opamps to do the maths:D thank you very much and you definatley should do a article on the matter!
Bingo! Assuming you are using the amp as gain between sensor and an A2D you want to drive that input with the largest signal you can expect. That gives you the best resolution.

"Largest" signal also means leaving a little headroom for something unexpected, component tolerances, and other yuckie stuff you don't foresee.

Inside the micro you are free to use any scaling that makes the math as simple as possible. If you have an 8 or 10 or even 12 bit conversion value it makes little sense to go to floating point math unless you have an oodle of room to drop it in, but that is rare.

Even in a 32 bit PIC (128K ROM, 32K RAM) I am using I do most of the calculations using simple integer values.
 
Top