The lack of decent floating point support seems to be a major
shortcoming with the PIC programming tools. Last year I posted a
query on this listserver, which resulted in an email reply from
Microchip. (My answer is reprinted below, although they weren't able
to help me at the time).
I expect that the PIC is (or could be) often used to control an LCD
with a readout of acquired analog measurements. The raw values read
would be translated into user units by some algorithm(s) involving at
least the 4 basic math functions and possible some transcendental
functions as well, such as log, sine, square root, etc.
App note AN575 seems to cover the basic math functions (although I've
seen at least one posting questioning their accuracy, and I noticed a
problem with an early version of the library with multiplication in
certain numeric ranges). However at the moment there seems to be no
support for the transcendental functions.
I have an older version of the CCS C compiler which I like using
(except for this problem) -- does anyone know if their latest version
supports the FLOAT data type and math.h? Also I read here that the
Avocet C compiler supports f/p; anyone have any experience with that?
In the meantime I've been searching for ways to handle f/p on my own;
one interesting (although older) reference from 1974 is _Floating
Point Computation_ by Pat Sterbenz of the IBM Systems Research
Institute. It doesn't give algorithms, but does cover a number of
issues to be considered such as rounding, bias, common mistakes
leading to loss of precision, etc.
A more immediately useful book is _Scientific Analysis on the Pocket
Calculator_ by Jon Smith (Software Research Corporation); John Wiley
& Sons, 1975. Back then scientific calculators were pricey, and the
book includes procedures for the 4-function calculator.
The author covers a number of methods arranged such as series
expansion chosen for rapid convergence and arranged for convenience
on a caluculator in nested form:
For optimizing the polynomial approach the book covers Chebyshev
polynomials which have useful properties for this application
including minimizing both error and computation steps.
Does anyone know of a similar reference that could be optimized for
the PIC? I don't expect to do floating point on a 16C57, but the
14-bit core family at least should have the computing resources. If
the full-blown C function printf() is unfeasible at least there
should be ecvt(), fcvt() and gcvt() or equivalents.
Regards, Doug Manzer
Copy of email sent to Microchip:
My own immediate needs are these:
1. Some way to convert a binary f/p number (in your modified IEEE
format) to readable message text for display on an LCD in floating
point decimal. The typical use would be to acquire an a/d reading,
processes it through some mathematical functions and then write
the result to an LCD with layout like this (with all elements
turned on): 18.104.22.168.
Doing this with fixed point math is only feasible where the ranges
of values are known in advance. However, my client at the moment
expects to plug in various instruments into a base unit; the
formulas and calibration constants for each sensor are arbitrary.
For instance, the calculation for temperature involves a 3rd order
polynomial; humidity requires a 5th order polynomial and a natural
log calculation. Lookup tables would be difficult as there are at
least 4 variables involved.
It would be ideal to have some function such as printf() or
sprintf(), or even some of the primitives for these functions.
Obviously there's not enough room in the PIC's code space for the
Short of that, I think many developers working with floating point
could use a function to convert a binary floating point number
into decimal floating point with a format such as a BCD string plus
a signed exponent, ie. a form of engineering notation. The
exponent would be used to locate the decimal point somewhere in
the LCD string.
I started out with this on my own, taking the approach that for
example 111.111 binary = 4 + 2 + 1 + 0.5 + 0.25 + 0.125. My
algorithm would start at the decimal point and calculate (or look
up) each power of two expressed as a BCD string and add it to a
running total if the bit was 1 in that position. (I would have to
do this in each direction if the number straddled the decimal
However, I don't know if this is the most efficient method, and
would appreciate your ideas on this.
2. Natural logarithm as well as other common transcendental
functions such as sin() etc. It's been a while since I worked with
evaluating a power series numerically, and none of the books at
local libraries are much help.
Unfortunately, both of the prominent C compilers for the PIC (CCS
and Bytecraft's MPC) don't support a float data type or offer
anything like math.lib. They're also lacking a way to format
output such as sprintf().
3. Some way to convert the user's keyboard input into a f/p
quantity. Typically this would be done on a host computer such as
an IBM-PC running a utility written in Borland C; the user would
enter calibration constants as a decimal floating point string.
The "old" AN575 contained a C program for converting a decimal
string into the modified f/p format but the new AN575 is missing
this program. Someone at Microchip told me that it wasn't updated
for some reason --- is it safe to use the logic from that orignal
>supports the FLOAT data type and math.h? Also I read here that the
>Avocet C compiler supports f/p; anyone have any experience with that?
I thought the Avocet compiler was still in beta.
FWIW, there are lots of C compilers for the 8051 family that will do floats
just fine. Maybe a PIC is the wrong chip because the software support
isn't as refined just yet.
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
Hardware & Software for Industry & R/C Hobbies
"Go fast, turn right, and keep the wet side down!"
I have been watching various floating point threads for a while. 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.
I did a acoustic bearing indicator, for instance, which did a four quadrant
arctangent, but instead of operating in radians and converting, I did it with
an integer Chebyshev polynomial which produced the answer in integer tenths
of a degree. Then displayed the number with a standard binary integer to
decimal routine. Hardwired the decimal point. This was done with 12 bit
arithmetic (3600<4096) leaving lots of CYA room if I needed. For instance,
I could improve to hundredths of a degree using 16 bit arithmetic
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.
(No criticism of Mr. Manzer here, by the way -- he was accurately describing
Even problems which require a small difference between two large numbers can
often be restated to eliminate such pathological behavior.
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). Part of being a good engineer is
choosing the right tools for the task. The PIC is a good tool, but not the
> The lack of decent floating point support seems to be a major
> shortcoming with the PIC programming tools. Last year I posted a
> query on this listserver, which resulted in an email reply from
> Microchip. (My answer is reprinted below, although they weren't able
>t o help me at the time).
> I expect that the PIC is (or could be) often used to control an LCD
> with a readout of acquired analog measurements. The raw values read
> would be translated into user units by some algorithm(s) involving at
> least the 4 basic math functions and possible some transcendental
> functions as well, such as log, sine, square root, etc.
> App note AN575 seems to cover the basic math functions (although I've
> seen at least one posting questioning their accuracy, and I noticed a
> problem with an early version of the library with multiplication in
> certain numeric ranges). However at the moment there seems to be no
> support for the transcendental functions.
As someone who have also gone through these same headaches before...
let me give you a small word of advice. Forget about using Pics for
this application. Its not worth the effort you will have to put into
it to get it working. Rather use the Atmel 89C2051 microcontroller
with a C compiler like Keil or Archimedes. That gives you decent
floating point capability and sprintf statements etc. And they are
not that much slower or more expensive than PIC microcontrollers.
> I have an older version of the CCS C compiler which I like using
> (except for this problem) -- does anyone know if their latest
> version supports the FLOAT data type and math.h? Also I read here
> that the Avocet C compiler supports f/p; anyone have any experience
> with that?
I recently upgraded to the more recent Windows version of the CCS
compiler which integrates the older PCB and PCM compilers. I found there is
not much difference between this and the older DOS version, and it
definetely does not yet support floating point artithmetic. I also
read about the Avocet compiler and its ability to support FPA, and
quickly dowloaded the beta version. However, to my dissapointment
they had no examples showing the use of FPA and I also could not see
any reference to it in the accomponied documentation. Maybe I just
overlooked something, but I certainly did not see it.... Any
Here is a random number generator written in C. It is the
same one used in the statistics package S-plus and since that is a
commercial package it must be good right? I use it too and have never
found anything wrong with it, I think it
is a form of nonlinear
congruential generator though I am not an expert by any means.
/*** Global state variables ***/
unsigned long Randcval, Randtval;
/*** I made these numbers up, they are not really magic. ***/
#define RAND_MAGIC1 0x00005867L
#define RAND_MAGIC2 0x76220000L
> Hi Yo'all
> I am looking at using the PIC16C63 for a project in which I need a
> repeatable random number generator.
> Does anyone know of a random number generator in the maths routines
> available for the PIC?
> I don't have a clue how to write one as have always had one in higher
> level languages on PC's.
> Geoff Jenkins
In message <Pine.SUN.3.96.970401132650.24690A-100000@tlaloc>, Matt
Calder <.....calderKILLspam@spam@STAT.COLOSTATE.EDU> writes
> Here is a random number generator written in C. It is the
>same one used in the statistics package S-plus and since that is a
>commercial package it must be good right? I use it too and have never
>found anything wrong with it, I think it
>is a form of nonlinear
>congruential generator though I am not an expert by any means.
I'd be very careful about using a random number generator that hadn't
been properly tested. Just because it is used commercially doesn't mean
that it is any good! Have a look at Knuth, The Art of Computer
Programming, for good random number generator algorithms.
A good example of where problems can arise is in cryptography, where
what appears to be a good cryptographic technique (like PGP) which uses
a poor random number generator can make it easy to crack the encryption.
I guess my sarcasm didn't get through, ASCII is such a
low bandwidth medium (I refuse to engage in smileys and such).
Anyhow, the pedigree on this particular RNG is documented in
Modern Applied Statistics with Splus
W.N. Venables & B.D. Ripley
It is claimed to have a period of 6.6 * 10^14, no word
on serial correlation. No doubt Knuth is a good reference
though a bit weighty for finding algorithms, another good
reference is the Numerical Recipes in C/Pascal/Fortran series.
> > Here is a random number generator written in C. It is the
> >same one used in the statistics package S-plus and since that is a
> >commercial package it must be good right? I use it too and have never
> I'd be very careful about using a random number generator that hadn't
> been properly tested. Just because it is used commercially doesn't mean
> that it is any good! Have a look at Knuth, The Art of Computer
> Programming, for good random number generator algorithms.