Searching \ for ' Maths Problem' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/method/math.htm?key=math
Search entire site for: 'Maths Problem'.

No exact or substring matches. trying for part
PICList Thread
'[PIC]: Hi-Tech C maths problem?'
2000\11\17@064035 by JP.BROWN

flavicon
face
Hi Folks!, I am trying to use picclite to do a little maths on my pic i/o

I am using       #include <math.h>

then in main     float a, b=2, c=2; // simple test
                a=pow(b,c);        //

This compiles no trouble but when it links it produces lots of errors
similar to this:-

::Cant find 0x5B words(0x5B withtotal) for psect text0 in segment CODE

I am using a 16F84 and the default linker settings.

Anybody got any ideas what could be wrong?.
Is anyone successfully using maths functions on the 16F84?

Ta John

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2000\11\17@110608 by JP.BROWN

flavicon
face
Thanks for that Andy, yes I tried compiling with some different maths
functions, the log(x) function uses 599 words and the sqrt(x) function
uses 573 words, I will have to think of something else, If I use any maths
functions using the 16F84 I won't have much room left for my program!.

On Fri, 17 Nov 2000, Andy Jancura wrote:

{Quote hidden}

         -----  John P. Brown      .....J.P.BrownKILLspamspam@spam@bradford.ac.uk ----
          \            --- Witty remark goes here ---         /
           --------------------------------------------------

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2000\11\17@111229 by Scott Dattalo

face
flavicon
face
On Fri, 17 Nov 2000, JP.BROWN wrote:

> Thanks for that Andy, yes I tried compiling with some different maths
> functions, the log(x) function uses 599 words and the sqrt(x) function
> uses 573 words, I will have to think of something else, If I use any maths
> functions using the 16F84 I won't have much room left for my program!.

Well, you could use integer arithmetic instead of floating. What's the
application?

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu


2000\11\17@113304 by JP.BROWN

flavicon
face
Hi Scott, the application will be producing a linear o/p from a variety of
sensors such LDRs etc. I am considering using a lookup table to do the
job.

----- John

On Fri, 17 Nov 2000, Scott Dattalo wrote:

> On Fri, 17 Nov 2000, JP.BROWN wrote:
>
> > Thanks for that Andy, yes I tried compiling with some different maths
> > functions, the log(x) function uses 599 words and the sqrt(x) function
> > uses 573 words, I will have to think of something else, If I use any maths
> > functions using the 16F84 I won't have much room left for my program!.
>
> Well, you could use integer arithmetic instead of floating. What's the
> application?

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu


2000\11\18@103538 by Nikolai Golovchenko

flavicon
face
J.P. Brown wrote:
> Thanks for that Andy, yes I tried compiling with some different maths
> functions, the log(x) function uses 599 words and the sqrt(x) function
> uses 573 words, I will have to think of something else, If I use any maths
> functions using the 16F84 I won't have much room left for my program!.

This is way too much even for floating point!

I know for sure sqrt(x) takes 87 instructions for 24 bit
float using PIC16 instruction set. You can easily include
that in assembly as a C function, only conversion between
Microchip and IEEE floating point representation would be
required (it's just three instructions either way). The
routine (and conversion) is at http://www.piclist.com BTW, it was
debugged recently.

And log(x) might take around 200 instructions if implemented
using the CORDIC method. If you can tolerate ~0.05% error it
can be even smaller and faster with a 16 entries table. For
example, take a look at "[PIC]: [MATH] x^y routine
implementation" thread in September.

Good luck,
Nikolai

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads



'[PICLIST] Maths Problem'
2001\01\18@183430 by Philip Martin
flavicon
face
Hi to all,

Must admit I haven't been on the list for about 18 months now, but therein
lies the problem. That is, I get to do some programming of PIC's when there
is a need and for the last 18 months there's been plenty else to occupy my
time.

Anyhow to my problem.

I have built a couple of timing units (race type clocks) using 16c64's, with
some nice big 5" LED displays and all is (was) working very well. Then some
bright spark comes along and says 'well on that one it would be nice to
convert the display into the average speed' (in MPH).

The distance travelled is easy cos its a fixed distance in Yards, but the
time ends up as a value in four bytes i.e. 20h = 2, 21h = 6, 22h = 4, 23h =
7, therefore time = 26.47 seconds. This I now shift into two bytes to output
to BCD to 7 segment decoders, thus port b outputs the 2 & 6 and port c
outputs the 4 & 7.

For the maths, I know that if I take a distance of say 60 yards and divide
that by 1760 and then multiply it by 1000 it will give me a nice fixed value
of 34 (D). But then I need to take my timing and divide that by 3600 (or 3.6
thus ignoring the need to then multiply by 1000) to create a value that will
then be divided into the D value. This will give me the resultant average
speed in MPH.

I've looked at the list FAQ's and Microchips AN's for maths routines but! Is
this 16 or 32 bit maths, and how do I cope with the decimal places? Is this
even possible in a PIC?

Any help or guidance would be most appreciated as I seem to have gone brain
dead on this one.

TIA,

Philip Martin.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\01\18@194653 by Tony Nixon

flavicon
picon face
Philip Martin wrote:
> For the maths, I know that if I take a distance of say 60 yards and divide
> that by 1760 and then multiply it by 1000 it will give me a nice fixed value
> of 34 (D). But then I need to take my timing and divide that by 3600 (or 3.6
> thus ignoring the need to then multiply by 1000) to create a value that will
> then be divided into the D value. This will give me the resultant average
> speed in MPH.
>
> I've looked at the list FAQ's and Microchips AN's for maths routines but! Is
> this 16 or 32 bit maths, and how do I cope with the decimal places? Is this
> even possible in a PIC?
>
> Any help or guidance would be most appreciated as I seem to have gone brain
> dead on this one.


This may help you understand, or seeing as how I'm not a math wizard, it
may confuse you more ;-)


3.6 in decimal = 3 units + 6 tenths of that unit.

In hexadecimal, ala PIC world, the units are either bytes/words or
larger.

3 fits in a byte nicely, but 0.6 does not.


In decimal terms, 0.6 = 6 / 10

In byte terms, 0.6 is saying 6 tenths of a byte

Mathematically this would be...

6 X 256
-------   = 153.6  or 99h
 10


Thus we can represent 3.6 decimal as 03.99 in hexadecimal.

The PIC will not understand 03.99 in hex so the whole value must be made
to fit into bytes or words.

In this case multiply the entire value by 256.

03.99h X FFh = 0399h

High Byte = 03h
Low Byte = 99h

Now you have a value to work with inside the PIC and you can operate on
it any way you like. You also know that the least significant byte of
any result is the value after the decimal point.

It would be easy to do a BCD conversion on 03h, then a decimal place,
then BCD 99h

The display would then read 3.15 (ignoring the last digit 153)



Ahh, but this is wrong, it should read 3.6

The reason is the value after the decimal place is actually a fraction
of a byte value.

To convert back to a decimal value, transpose the above formula

99h X 10dec
------------
   256

Or simpler, just do 99h X 10dec and use the high byte of the word
result.


The result however will be 5, not 6 as we would have liked.

The reason is that the 'real' value 153.6 from above was truncated to
153 (99h). Thus there is a small error.

The result above is in the low nibble of the high word.


You can reduce the error slightly by using a larger conversion number.

99h X 100dec

The result in this case will be 3Bh or 60dec in the high word.


We know this is a fraction with 1/10ths and 1/100ths so we can display
it as such.


Now after BCD conversion your display will read 3.60




Also, as you are working with constant values, why not divide them down
into simpler terms.

Eg

3600         18
----    =    --
1000         5


Much easier to work with.


Try to work out the total math on paper and solve for the final value.
Then see if the formula can be simplified, and use that in your code.



--
Best regards

Tony

mICro's
http://www.picnpoke.com
salesspamspam_OUTpicnpoke.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


'[PIC]:Re: Maths Problem'
2001\01\19@092520 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Well as Tony Nixon suggested an fixed format is the way to go here.
I would suggest an 16.8 or if range is enough 8.8.
It's then very easy to scale this by using Nicolai's code generator.
For example for 16.8 (binary) to 6.2 ( fixed point with 2 digits after
decimalpoint ) you need to scale something like this:

16.8 / 256 is the integer part, but we also want 2 digit from the
decimal
part and hence we add * 100 and gets:

16.8 * 100 / 256 = 16.8 * 0.390625

Enter this in the code generator ( i.e constant 0.390625 )
input size 24 bits. And all the code you need will be generated.
Example ( using your value here ):

26.47 ( decimal ) would be in 16.8 format:
Integer-part -> 26 = top two bytes = 0x001A in hexadecimal.
Decimal part -> 47 * 2.56 = 120.32 ( this code could also be generated
by above code generator ), we cut the decimal part and have 120 left
which is
0x78 in hex.
We now have the original value in 16.8 format as:
0x001A78 ( which btw is 6776 decimal if treated as 24 bit value )
Run this though the code generated above ( 0x001A78 * 0.390625 )
and you will have:
0x000A56 or 0x000A57 ( depending how you handle rounding )
which is 2646 or 2647 in decimal. Now as we have decided to have an
'fixed' point with two decimals you already know where to set the
decimal
point. take the 24 bit value run it through the 24->ascii routine found
on the
piclist site, place the decimal point two digits from the last and there
you go.


/Tony







Tony Kübek, Flintab AB            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: @spam@tony.kubekKILLspamspamflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


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