Truncated match.
PICList
Thread
'Floating point'
1996\05\25@141759
by
Doug Manzer

Hi Al, thanks for sending the source and executable for FPREP.
Since then I've been looking at an application which requires f/p
calculations including a 5th order polynomial and natural logarithms.
There are too many variables involved to use lookup tables.
I'm still searching for a way to handle the log; there may
be an easy algorithm to compute log base 2 and then multiply
by a constant to get the natural log.
Another problem is how to convert Microchip's modified IEEE f/p
format into BCD so I can display it on the LCD. Ideally I'd like
the result in engineering format so that I could use the exponent
to locate the decimal point on the LCD.
The typical 4digit LCD with all display elements turned on looks
like this: 8.8.8.8. The range of values this can display in normal
format is "0.001" to "9999".
None of the current C compilers seem to support a float data type
with a library like math.lib, nor do they have anything like
sprintf().
Originally my client wanted to use a PIC for this application but
after discussing the complexity of the math involved we decided to
use a processer for which a compiler was available with floating
point built in.
I think the PIC would be able to handle a simpler requirement such
as y = ax + b where x is an acquired value (via a/d, etc); a and b
are f/p calibration constants which may be user settable and
therefore of arbitrary value. Although I could check the user's
input for a valid range, I would still need to determine the
location of the decimal point for the displayed value y.
One thing I would try here is to multiply a & b by 1000 so that
the result Y would ends up 1000 times its actual value y. If
the smallest nonzero displayable value y = 0.001 then Y = 1; for
the largest y = 9999, Y = 9,999,000 which is expressable with 24
bits; this would require the 32bit f/p library. AN575 does have a
conversion for f/p to integer which I could then convert to BCD
fairly easily. A range check would determine where the decimal point
belonged. However, if there's an easier way to do this I'd
appreciate hearing about it  surely this must be a common
application for the PIC.
Regards, D.M.
1996\05\25@183321
by
James Musselman
Doug Manzer wrote:
>
> Hi Al, thanks for sending the source and executable for FPREP.
>
> Originally my client wanted to use a PIC for this application but
> after discussing the complexity of the math involved we decided to
> use a processer for which a compiler was available with floating
> point built in.
>
> Regards, D.M.
So what processor and compiler did you go with?
James
1996\05\25@204413
by
fastfwd

Doug Manzer <spam_OUTPICLISTTakeThisOuTMITVMA.MIT.EDU> wrote:
> I'm still searching for a way to handle the log; there may
> be an easy algorithm to compute log base 2 and then multiply
> by a constant to get the natural log.
Doug:
The constant to multiply by is, of course, the natural log of 2.
Computing log base 2 is pretty simple and welldocumented in the
literature. See Knuth, etc.
> None of the current C compilers seem to support a float data type
> with a library like math.lib
Bytecraft's compilers will soon support floatingpoint data
types, as well as 24 and 32bit integer types.
{Quote hidden}> I think the PIC would be able to handle a simpler requirement such
> as y = ax + b where x is an acquired value (via a/d, etc); a and b
> are f/p calibration constants which may be user settable and
> therefore of arbitrary value. Although I could check the user's
> input for a valid range, I would still need to determine the
> location of the decimal point for the displayed value y.
>
> One thing I would try here is to multiply a & b by 1000 so that the
> result Y would ends up 1000 times its actual value y. If the
> smallest nonzero displayable value y = 0.001 then Y = 1; for the
> largest y = 9999, Y = 9,999,000 which is expressable with 24 bits;
> this would require the 32bit f/p library. AN575 does have a
> conversion for f/p to integer which I could then convert to BCD
> fairly easily. A range check would determine where the decimal point
> belonged. However, if there's an easier way to do this I'd
> appreciate hearing about it  surely this must be a common
> application for the PIC.
If those usersettable constants are entered via the 4digit LCD
display, I would dump the floatingpoint routines completely and
do all the calculations with integer math, adjusting the decimal
point as needed. This sounds pretty much like what you're
suggesting.
Andy
Andrew Warren  .....fastfwdKILLspam@spam@ix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499
1996\05\25@205908
by
fastfwd

I just wrote:
> > [Quoting Doug Manzer:]
> > One thing I would try here is to multiply a & b by 1000 so that
> > the result Y would ends up 1000 times its actual value y. If the
> > smallest nonzero displayable value y = 0.001 then Y = 1; for the
> > largest y = 9999, Y = 9,999,000 which is expressable with 24 bits;
> > this would require the 32bit f/p library. AN575 does have a
> > conversion for f/p to integer which I could then convert to BCD
> > fairly easily. A range check would determine where the decimal
> > point belonged. However, if there's an easier way to do this I'd
> > appreciate hearing about it  surely this must be a common
> > application for the PIC.
>
> If those usersettable constants are entered via the 4digit LCD
> display, I would dump the floatingpoint routines completely and
> do all the calculations with integer math, adjusting the decimal
> point as needed. This sounds pretty much like what you're
> suggesting.
Doug:
I should have elaborated a little: I would NOT multiply "a" and "b"
by 1000 before performing the calculations; I'd simply ignore the
decimal points and treat "a" and "b" as integers in the range
[19999] ("x", of course, would remain an integer in the range
[0255]).
After performing the (now greatlysimplified) multiplication and
addition, I'd set "y"'s decimal point based on the original
decimalpoint positions of "a" and "b".
Andy
Andrew Warren  fastfwdKILLspamix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499
1996\05\28@033915
by
Doug Manzer

At 3:32 PM 5/25/96 0700, James Musselman wrote:
>Doug Manzer wrote:
>> Originally my client wanted to use a PIC for this application but
>> after discussing the complexity of the math involved we decided to
>> use a processer for which a compiler was available with floating
>> point built in.
>So what processor and compiler did you go with?
We haven't decided; the NEC V25 looks interesting, especially
as it's available off the shelf on a controller board from
various vendors. A big advantage is that it's PC compatible
and we can use Borland C for programming. The firmware would
also be reasonably portable if we had to change vendors.
There's also a family of RISC controllers put out by Hitachi that
we're considering. A version of the Gnu C compiler is available
for them but I'm not sure how well it supports floating point.
Product availability may be another questionable issue.
Both of these alternatives are in a higher price range than is
(theoretically) necessary. However the client is willing to accept
the extra component cost in exchange for faster development as
time to market is critical. Although I could perhaps use the PIC
with CCS C, dropping into assembler and including some of the f/p
routines from AN575  assuming I could find an algorithm for
ln(x)  this is more awkward and time consuming than using a
compiler with math.lib and the float data type built in. In fact
it turns out that future versions of the product may use
plugin components requiring all sorts of math functions
including sin(x), etc.
I believe the PIC's have the computing power for the application,
especially the 16bit core family which should be able handle all
this math quite easily. The problem is insufficient programming tool
support. I suppose that will improve with time. For instance there
are compilers already available for the HC11 with f/p math. I don't
know exactly how the 17Cxx stacks up against the HC11 but I presume
it's at least as powerful if not more so.
Regards, D.M.
1996\05\28@051859
by
Clyde SmithStubbs

dmanzer@wimsey.com (Doug Manzer) wrote:
> At 3:32 PM 5/25/96 0700, James Musselman wrote:
> >Doug Manzer wrote:
> >> Originally my client wanted to use a PIC for this application but
> >> after discussing the complexity of the math involved we decided to
> >> use a processer for which a compiler was available with floating
> >> point built in.
>
> >So what processor and compiler did you go with?
>
> We haven't decided; the NEC V25 looks interesting, especially
Here's a suggestion; the Philips XA chip is *very* fast, cheap as
chips, and has good development support  including 32 and 64 bit
IEEE floating point, with full maths library. Availability will be
much better than Hitachi (they prefer customers who buy megavolumes)
and performance will be vastly better than the V25.
Clyde

Clyde SmithStubbs  HITECH Software,  Voice: +61 7 3300 5011
.....clydeKILLspam.....hitech.com.au  P.O. Box 103, Alderley,  Fax: +61 7 3300 5246
http://www.hitech.com.au  QLD, 4051, AUSTRALIA.  BBS: +61 7 3300 5235

For info on the World's best C cross compilers for embedded systems, point
your WWW browser at http://www.hitech.com.au, or email EraseMEinfospam_OUTTakeThisOuThitech.com.au
1996\05\28@120055
by
Wireless Scientific

At 11:48 PM 5/27/96, Doug Manzer wrote:
>I believe the PIC's have the computing power for the application,
>especially the 16bit core family which should be able handle all
>this math quite easily. The problem is insufficient programming tool
>support. I suppose that will improve with time. For instance there
>are compilers already available for the HC11 with f/p math. I don't
>know exactly how the 17Cxx stacks up against the HC11 but I presume
>it's at least as powerful if not more so.
This is the kind of line you need to give to your Microchip rep. Nothing
gets the ball rolling like hearing lines like "I love your stuff but I'm
forced to HC11 because of compiler support" or "the other micro's compilers
decrease time to market". Microchip has the money to fund compiler
companies to add FP math. They just need to hear it from developers that
they're losing sales because it.
I'd suggest forwarded this last thread to your local Microchip rep.
craig
________________________________________________________
Dr. Craig Hollabaugh
Wireless Scientific, Inc.
1890 South 14th Street
Building 100, Suite 105
Amelia Island, FL 32034
904 261 6977
904 261 2129 fax
wscispam_OUTmagicnet.net
Or you might know me as
Dr. Craig Hollabaugh
Analog Microelectronics, Georgia Institute of Technology
@spam@hollaKILLspammonique.adgrp.gatech.edu
or
Dr. Craig Hollabaugh
Aerospace Department, University of Texas, Austin
KILLspamhollaKILLspamcfdlab.ae.utexas.edu
'Floating point'
1997\04\04@152905
by
Don McClaren

Michael Mullen <RemoveMEMEMullenTakeThisOuTAOL.COM> wrote:
> Having some experience with precision instruments with floating point
> displays, I point out that I have never, in fact, found it necessary
> to actually do the calculations in floating point. I usually scale
> until I can do a fixed point operation, or operate with a scale
> factor.
Thanks for your reply to my query, Michael. My original posting
described a situation where fixed point calculations were not
suitable because the translation equations (and therefore the numeric
ranges) weren't known in advance. I'm working on a project at the
moment where userreplaceable sensors are plugged into a base unit;
each sensor having a 40byte EEPROM (Dallas 24A30) containing the
sensor name (ie, LCD text string) and calibration constants, etc. The
main controller is not a PIC, but only because of the lack of
floating point support in the programming tools.
> In contrast, the constants given in Doug Manzer's tangent calculation
> are 9 decimal digits. If this were used to measure angles in a
> navigation system, one could measure one's longitude anywhere on the
> earth to to a precision of less than 2 inches. For most problems,
> this level of precision is overkill.
Agreed, although some guard digits are necessary. A 12bit a/d
converter will return a result in the range 0 to 4095, ie. 4 decimal
digits so perhaps 5 or 6 digit precision would be reasonable in
calculations.
> I don't mean to be dogmatic; there _ARE_ valid reasons for FP and
> high precision operations. However, I would suggest strongly that, if
> you really need such things, you might consider a more powerful
> processor (or, more accurately, one with more powerful tools).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is my whole point; there are compilers with the float data type
for the HC11, which has roughly the same computing power as the
higherend PIC's so the problem with with the tools. Since this IS
a PIC forum I was hoping to find a PICbased solution.
I can see three main phases in a f/p computation:
1.a Convert the acquired value (typically binary integer) to f/p in
whatever radix is used internally
1.b It may also be necessary to accept input in decimal format from
the user (eg. for calibration constants) which need to be translated
into f/p format.
2. Perform the f/p operations
3. Convert the result to readable form in decimal format
AND575 in Microchip's _Embedded Control Handbook_ provides only
partial solutions for these operations.
Phase 1.a at least is covered with an integer to float conversion.
Relevant to Phase 1.b, it includes a floating point to binary
conversion algorithm for which the first step is...
z = ln A / ln 2
...however, the author doesn't include an ln() function in his
math library.
For Phase 2, AN575 covers only the 4 basic math functions with
no mention of transcendental functions.
Phase 3 is also awkward, as the library functions produce results in
Microchip's modified IEEE754 format. There is a float to integer
conversion, but only with a limited range. I would like to see an
equivalent to Borland's fcvt(), described in their _C++ Library
Reference_ as follows (with capitals in place of italics):

Function Converts a floatingpoint number to a string.
Syntax #include <stdlib.h>
char *fcvt(double VALUE,int NDIG,int*DEC,int *SIGN) ;
Remarks fcvt converts VALUE to nullterminated string digits,
starting with the leftmost significant digit, with NDIG
digits to the right of the decimal point. fcvt then returns
a pointer to the string. The position of the decimal point
relative to the beginning of the string is stored indirectly
through DEC (a negative value for DEC means to the left of
the returned digits). There is no decimal point in the string
itself. If the sign of value is negative, the word pointed
to by SIGN is nonzero; othersie, it is 0.
The correct digit has been rounded for the number of digits
to the right of the decimal point specified by NDIG.
Ret val The return value of fcvt points to static data whose content
is overwritten by each call to fcvt and ecvt.
See also ecvt, gcvt, sprintf

An ascii string with sign and exponent information could be used to
derive the message string for the readout, typically a 7segment
display with format 8.8.8.8 or an LCD.
Regards, Doug Manzer
ps. thanks to everyone who emailed help and suggestions; I will
reply shortly.
1997\04\04@163658
by
sdattalo
1997\04\04@172137
by
taking

Don,
You can still do this with a intelligent version of fixed point..
Just use say ten bytes before and ten after the decimal point.. (or more
or less for either side, whatever the max possible range is plus some
for loss.) Then just have the fixed mult skip all zero bytes and the
routine won't take very much longer than a dedicated routine for a set
number of signifigant bytes. Since your sensors have the constants with
them the input is easy to put into the right place, and the fixed point
output is easy to sift through from MS byte to LS byte and set the scale
by where the numbers start poping up..
Alan
{Quote hidden}>
> Thanks for your reply to my query, Michael. My original posting
> described a situation where fixed point calculations were not
> suitable because the translation equations (and therefore the numeric
> ranges) weren't known in advance. I'm working on a project at the
> moment where userreplaceable sensors are plugged into a base unit;
> each sensor having a 40byte EEPROM (Dallas 24A30) containing the
> sensor name (ie, LCD text string) and calibration constants, etc. The
> main controller is not a PIC, but only because of the lack of
> floating point support in the programming tools.
>
More... (looser matching)
 Last day of these posts
 In 1997
, 1998 only
 Today
 New search...