Searching \ for 'Floating point' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=floating+point
Search entire site for: 'Floating point'.

Truncated match.
'Floating point'
1996\05\25@141759 by

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 4-digit 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 non-zero 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 32-bit 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.
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
Doug Manzer <PICLISTMITVMA.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 well-documented 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 floating-point data
types, as well as 24- and 32-bit integer types.

{Quote hidden}

If those user-settable constants are entered via the 4-digit LCD
display, I would dump the floating-point 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 - fastfwdix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499
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 non-zero 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 32-bit 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 user-settable constants are entered via the 4-digit LCD
>     display, I would dump the floating-point 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
[1-9999] ("x", of course, would remain an integer in the range
[0-255]).

After performing the (now greatly-simplified) multiplication and
addition, I'd set "y"'s decimal point based on the original
decimal-point positions of "a" and "b".

-Andy

Andrew Warren - fastfwdix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499
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
plug-in 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 16-bit 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.

> 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 mega-volumes)
and performance will be vastly better than the V25.

Clyde

--
Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: +61 7 3300 5011
clydehitech.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 infohitech.com.au
At 11:48 PM 5/27/96, Doug Manzer wrote:
>I believe the PIC's have the computing power for the application,
>especially the 16-bit 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.

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
wscimagic-net.net

Or you might know me as
Dr. Craig Hollabaugh
Analog Microelectronics, Georgia Institute of Technology

or

Dr. Craig Hollabaugh
Aerospace Department, University of Texas, Austin
hollacfdlab.ae.utexas.edu

'Floating point'
1997\04\04@152905 by
Michael Mullen <MEMullenAOL.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.

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 user-replaceable sensors are plugged into a base unit;
each sensor having a 40-byte 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 12-bit 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
higher-end PIC's so the problem with with the tools. Since this IS
a PIC forum I was hoping to find a PIC-based 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

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 floating-point number to a string.

Syntax    #include <stdlib.h>
char *fcvt(double VALUE,int NDIG,int*DEC,int *SIGN) ;

Remarks   fcvt converts VALUE to null-terminated 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.

-----------------------------------------------------

An ascii string with sign and exponent information could be used to
derive the message string for the readout, typically a 7-segment
display with format 8.8.8.8 or an LCD.

Regards, Doug Manzer

ps. thanks to everyone who emailed help and suggestions; I will
Don McClaren wrote:
>
> ...however, the author doesn't include an ln() function in his
> math library.

Check out

http://www.interstice.com/~sdattalo/technical/software/pic/piclog.html

for a fast 8-bit logarithm program. However, it's a fixed point
implementation not a floating point one.

However, if you want to write a floating point version then you
might want to check out:

http://www.interstice.com/~sdattalo/technical/theory/logs.html

Scott
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}

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...