Exact match. Not showing close matches.
PICList
Thread
'[PIC] Floating point, fixed point'
2011\03\12@061154
by
IVP
Hi all,
can I have recommendations please for floating point and fixed point
assembly routines for 16F or 18F
I've found AN660 (floating) and AN617 (fixed), both written in 1997
by Frank Testa at Microchip but not yet tried them. Partly because
 MC have a habit of leaving buggy stuff on their site
 there might be something better
 I've never used floating or fixed and probably wouldn't know good
from bad anyway
http://ww1.microchip.com/downloads/en/AppNotes/00617.pdf
http://ww1.microchip.com/downloads/en/AppNotes/00660.pdf
Project requires * and / plus trig functions in the range 0.0000 to
180.0000, which I think fixed point would be sufficient for
TIA
Jo
2011\03\12@063735
by
cdb
2011\03\12@064129
by
cdb
2011\03\12@070952
by
Michael Watterson
On 12/03/2011 11:10, IVP wrote:
> Project requires * and / plus trig functions in the range 0.0000 to
> 180.0000, which I think fixed point would be sufficient for
>
Use fixed point, never floating.
Try to substitute multiplies with reciprocal and avoid divides
Use look up tables for Trig.
You can even use Log tables with interpolation if you really need some FP
If that isn't sufficient and you really need floating point, then you ought to consider a CPU that goes MUCH faster and has C or other decent FP library and even a FP coprocessor.
You can of course do real FP on PIC16 or PIC18 but RAM penalty is high and speed very slow.
24 bits fixed point using 8bit whole numbers and 16 bit fraction, with 32bit intermediate for multiplcations (16 bit whole number + 16 bit fraction).
correction of dp position only needed after multiply or divide.
you can even process the whole and fraction separately with 16 bit integer math and 32 bit multiply result and then handle over flow of fraction by correction of whole number and underflow of whole number by correction of fraction.
Look at BCD arithmetic routines pretending it's 16 bits per "digit" rather than 4 bits per digit to see how "carry" works.
2011\03\12@072133
by
Walter Banks

IVP wrote:
{Quote hidden}> Hi all,
>
> can I have recommendations please for floating point and fixed point
> assembly routines for 16F or 18F
>
> I've found AN660 (floating) and AN617 (fixed), both written in 1997
> by Frank Testa at Microchip but not yet tried them. Partly because
>
>  MC have a habit of leaving buggy stuff on their site
>  there might be something better
>  I've never used floating or fixed and probably wouldn't know good
> from bad anyway
>
>
http://ww1.microchip.com/downloads/en/AppNotes/00617.pdf
>
>
http://ww1.microchip.com/downloads/en/AppNotes/00660.pdf
>
> Project requires * and / plus trig functions in the range 0.0000 to
> 180.0000, which I think fixed point would be sufficient for
Fixed and floating point take roughly the same number of execution
cycles for the same number of bits but fixed point gives more
precision and floating point gives larger dynamic range. Or
24 bit fixed point with similar precision to 32bit floating point will
be significantly smaller and faster.
Depending on application trig functions can often be simplified to
acceptable accuracy with greatly reduced code size and cycle
count. It is also worth considering what notation is used to
represent angle, degrees, radians or 256 counts to represent
22.5, 45,90,180, or 360 degrees etc
Regards,
w..

Walter Banks
Byte Craft Limited
http://www.bytecraft.com
2011\03\12@104634
by
Olin Lathrop
part 1 2270 bytes contenttype:text/plain; charset="iso88591" (decoded quotedprintable)
IVP wrote:
> can I have recommendations please for floating point and fixed point
> assembly routines for 16F or 18F
There are 32 bit fixed point and 24 bit floating point routines included in
my PIC development environment. See http://www.embedinc.com/pic/dload.htm.
Look in the SOURCE > PIC directory after software installation.
The 24 bit floating point source files all have "fp24" in their name
somewhere. The description of the floating point format is in
FP24FLT.INS.ASPIC, and I have also attached it. This floating point format
is handy for most things a PIC will do. It only has 16 bits of precision,
but that's plenty when values come in as 12 bit A/D readings and go out as
10 bit PWM duty cycle values. The routines also don't bother with all the
NaN stuff, which is a silly waste of cycles in a small embeddd system
dealing with real world data. The arithmetic routines saturate as necessary
but otherwise keep on going.
The 32 bit fixed point routines don't have consistent naming conventions.
There are names like ADDA, SUBA, MULU, DIVU, and probably a few others.
Look around.
All of this code assumes my PIC development environment, of course. It
would be a good idea to start using it in general, although there will be a
bit of a learning curve to get started. All these routines rely on my
general register model, usually REG0REG12 on a PIC 16 and REG0REG15 on a
PIC 18. The first 4 registers are also grouped together and called REGA,
then REGB and REGC, for most of the wide data math routines.
> Project requires * and / plus trig functions in the range 0.0000 to
> 180.0000, which I think fixed point would be sufficient for
I haven't implemented trig yet for 8 bit PICs as it hasn't come up in that
form yet. However, I'd do that with a lookup table where a full circle is
represented as a power of 2. The lookup table contains one quadrant of a
sine. The high bit of the angle then specifies whether to negate the
result, and the next lower bit which direction to index into the table. The
table would have 2**N intervals, so the next N lower angle bits identify the
first table entry and the remaining lower angle bits the interpolation
fraction.
part 2 2488 bytes contenttype:text/plain; name="fp24.txt"
(decoded base64)
; 24 bit floating point format:
;
; 24 bits are used to describe a floating point value using 1 sign bit
; 7 exponent bits, and 16 mantissa bits as follows:
;
;  byte 2  byte 1  byte 0 
;       
; 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
; 
;    
;  S EXP  MANT 
;    
; 
;
; S  Sign bit. 0 for positive or zero value, 1 for negative value.
;
; EXP  Exponent. The overall floating point value is the mantissa
; value times 2 ** (EXP  64) when EXP is in the range from 1 to 127.
; The special EXP value of 0 is only used when the overall floating
; point value is 0.0.
;
; MANT  Mantissa. Except for the special case when the overall
; floating point value is 0, the mantissa represents a fixed point
; value such that 1 <= mantissa < 2. This means the integer part of
; the mantissa is always 1. Since this integer part is always the
; same, it is not stored. The MANT field contains the 16 most
; significant fraction bits of the mantissa value. Therefore
; MANT = (mantissa  1) * 65536. An overall floating point value of
; 0.0 is indicated by EXP = 0. In that case MANT is reserved, and
; should be 0.
;
; Consider the following examples:
;
; 0.0 > 000000h
;
; S = 0 (positive or zero)
; EXP = 0 (special case for 0.0)
; MANT = 0 (special case for 0.0)
;
; 1.0 > 400000h
;
; S = 0 (positive or zero)
; exponent = 0, EXP = 64 > 40h
; mantissa = 1.0, MANT = 0
;
; 3.141593 > C19220h
;
; S = 1 (negative)
; exponent = 1, EXP = 65 > 41h
; mantissa = 1.570797, MANT = 37,408 > 9220h
;
; Unless otherwise specified, overflow and underflow values are silently
; clipped to the maximum magnitude (7FFFFF for positive, FFFFFF for negative)
; and zero, respectively.
part 3 181 bytes contenttype:text/plain; name="ATT00001.txt"
(decoded base64)

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
2011\03\12@111134
by
Olin Lathrop
Michael Watterson wrote:
> Use fixed point, never floating.
This is bad advice. Use whatever is most appropriate and don't get caught
up in other people's silly superstitions.
> You can even use Log tables with interpolation if you really need
> some FP
Log tables are rather cumbersome. That's a long way to go just to avoid
floating point, especially for religious reasons.
> If that isn't sufficient and you really need floating point, then you
> ought to consider a CPU that goes MUCH faster and has C or other
> decent FP library and even a FP coprocessor.
Again, use what's appropriate. If a cheap PIC can do the calculations fast
enough, then spending more on a floating point processor is a waste.
I have done several PIC 16 projects using floating point. FP is often a
good choice for PID control calculations since the dynamic range of values
can be quite wide or unpredictable. Fixed point values would have to be too
wide to handle the wide dynamic range with enough meaningful bits left over..
In one case I did two nested PID control loops using floating point on a
16F877. Sure, the individual FP operations were much slower than they would
have been with dedicated FP hardware, but they were fast enough. The loop
time was 8ms (125 Hz), which worked just fine. The inner loop controlled
the position of a motor, and the outer loop controlled the speed of a
gasoline engine that the motor was adjusting the throttle of.
There are plenty of real world problems where a small PIC's ability to do
floating point computation is fast enough.
> You can of course do real FP on PIC16 or PIC18 but RAM penalty is high
> and speed very slow.
FP usually takes less RAM than the same calculations done in fixed point.
Since the dynamic range is usually poorly known, extra bits have to be left
around to guarantee minimum precision accross the range. Floating point
stores only the significant bits with some bookkeeping overhead. In the
double nested PID control case I cited above, there wouldn't have been
enough RAM to use 32 bit fixed point instead of 24 bit floating point. And,
the 32 bit fixed point wouldn't have guaranteed the necessary precision
accross the possible range of values. Floating point computation code is
also easier to write since you don't have to keep worrying about minimum and
maximum representable values and keeping track of where the binary point is
in every number. One way to think of floating point is fixed point with
runtime point tracking.
Floating point has its place. Avoiding it "just because" is silly
superstition.
> 24 bits fixed point using 8bit whole numbers and 16 bit fraction, with
> 32bit intermediate for multiplcations (16 bit whole number + 16 bit
> fraction).
is ...? Can I buy you a verb or two?
> correction of dp position only needed after multiply or divide.
Again not true. Adds (subtracts are really adds with a little extra
bookkeeping) require normalization before the addition, which explicitly
means the point has to be moved around. Also a add can overflow to require
a one bit shift to renormalize after the add. Adds with negative numbers
can result in values down to zero magnitude, so can cause major shifting of
the result with respsect to either input value.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 7429014. Gold level PIC consultants since 2000
2011\03\12@114436
by
Michael Watterson
On 12/03/2011 16:11, Olin Lathrop wrote:
> Michael Watterson wrote:
>> > Use fixed point, never floating.
> This is bad advice. Use whatever is most appropriate and don't get caught
> up in other people's silly superstitions.
>
You're taking the advice out of context. Well tested C libraries and more appropriate cheap CPUs are available. PIC16/18 are not a natural choice for FP application.
Even on x86 before Pentium era, it was good practice to check if you "really" needed FP, as not all 486 had FPU and 386 rarely.
Rounding issues can be more easily understood with fixed point.
Of course if it's appropriate to use FP, then do. Often on microcontroller there is no need, you have given good examples yourself in the past
2011\03\12@114712
by
Michael Watterson
On 12/03/2011 16:11, Olin Lathrop wrote:
> Again not true. Adds (subtracts are really adds with a little extra
> bookkeeping) require normalization before the addition, which explicitly
> means the point has to be moved around.
it's quite possible do fixed point library with only adjustment on mult/div, and add/subtract doesn't care where the point is.
2011\03\12@114752
by
Oli Glaser
On 12/03/2011 16:11, Olin Lathrop wrote:
> I have done several PIC 16 projects using floating point. FP is often a
> good choice for PID control calculations since the dynamic range of values
> can be quite wide or unpredictable. Fixed point values would have to be too
> wide to handle the wide dynamic range with enough meaningful bits left over.
Yes, I have just finished a project using a 16F690 with PID control of a heating element which used floating point. No problems regarding speed, with various other stuff (one wire, LCD, buttons etc) going on, works fine.
2011\03\12@114838
by
Michael Watterson
On 12/03/2011 15:46, Olin Lathrop wrote:
> I haven't implemented trig yet for 8 bit PICs as it hasn't come up in that
> form yet. However, I'd do that with a lookup table where a full circle is
> represented as a power of 2. The lookup table contains one quadrant of a
> sine. The high bit of the angle then specifies whether to negate the
> result, and the next lower bit which direction to index into the table.
At least we agree on that. Really we agree on all the other aspects, you just like to nitpic
2011\03\12@115504
by
Olin Lathrop
Michael Watterson wrote:
>> Again not true. Adds (subtracts are really adds with a little extra
>> bookkeeping) require normalization before the addition, which
>> explicitly means the point has to be moved around.
>
> it's quite possible do fixed point library with only adjustment on
> mult/div, and add/subtract doesn't care where the point is.
Right, but we were talking about floating point.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 7429014. Gold level PIC consultants since 2000
2011\03\12@115938
by
Michael Watterson
On 12/03/2011 16:47, Oli Glaser wrote:
> Yes, I have just finished a project using a 16F690 with PID control of a
> heating element which used floating point. No problems regarding speed,
> with various other stuff (one wire, LCD, buttons etc) going on, works fine.
PID heating is a good example as the system response time is very slow. In the early 1980s Westinghouse had PID controllers with 8085, 8051 and Z80..
But DSP at 12kHz or Graphics panel on PIC or such some form of Fixed point alternatives to Floating point are usually far better. FPGAs usually use Fixed point for all DSP.
it depends what the Floating point is for and how much how fast is needed
2011\03\12@121216
by
Oli Glaser
On 12/03/2011 16:59, Michael Watterson wrote:
> On 12/03/2011 16:47, Oli Glaser wrote:
>> Yes, I have just finished a project using a 16F690 with PID control of a
>> heating element which used floating point. No problems regarding speed,
>> with various other stuff (one wire, LCD, buttons etc) going on, works fine.
> PID heating is a good example as the system response time is very slow.
> In the early 1980s Westinghouse had PID controllers with 8085, 8051 and Z80.
>
> But DSP at 12kHz or Graphics panel on PIC or such some form of Fixed
> point alternatives to Floating point are usually far better. FPGAs
> usually use Fixed point for all DSP.
>
> it depends what the Floating point is for and how much how fast is needed..
Yes, this was my reason for giving an example, as I thought the "never use floating point" could give the wrong impression to people.
2011\03\12@121808
by
Olin Lathrop
Michael Watterson wrote:
> it depends what the Floating point is for and how much how fast is
> needed.
Exactly. That's very different from your original statement of "never",
though.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 7429014. Gold level PIC consultants since 2000
2011\03\12@140955
by
Isaac Marino Bavaresco
Em 12/3/2011 13:46, Michael Watterson escreveu:
> On 12/03/2011 16:11, Olin Lathrop wrote:
>> Again not true. Adds (subtracts are really adds with a little extra
>> bookkeeping) require normalization before the addition, which explicitly
>> means the point has to be moved around.
> it's quite possible do fixed point library with only adjustment on
> mult/div, and add/subtract doesn't care where the point is.
As long as the points are at the same position for both parcels.
For multiplication, the points can be at different positions before the
multiplication, and you only need a shift afterwards to put the point
where you want it.
For addition, you must ensure that both points are at the same position
before the operation, using a shift.
Isaac
2011\03\13@172157
by
IVP
Thanks al
More... (looser matching)
 Last day of these posts
 In 2011
, 2012 only
 Today
 New search...