Searching \ for '[PIC]:Maths Problem' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/math/index.htm?key=math
Search entire site for: 'Maths Problem'.

Exact match. Not showing close matches.
'[PIC]:Maths Problem'
2001\01\19@120246 by

Many thanks to the two Tony's for your replies. Whilst the answers may not
have directly helped solve the problem, they have certainly broadened my
understanding of maths on the PIC. But it was the final comment in Tony
Nixon's post that got me thinking, break the problem down into a manageable
chunk.

So my train of thought went, if the distance is a fixed value (60 yards),
what would be the speed in MPH if it only took 1 second to travel this
distance. Answer, 122.75 mph. Now all I have to do is divide whatever time I
get into this figure to convert it into MPH. Thus 122.75 / 12.63 seconds
would be 9.718 mph.

Route a)

122.75 = 7A (msb) & 4B (lsb) / 12.63 = 0C (msb) & 3F (lsb) = 00 09 (msb) .
0C 14 (lsb) or 9.3092.

Route b)

12275 = 2F (msb) & F3 (lsb) / 1263 = 04 (msb) & EF (lsb) = 00 09 (msb) . 03
83 (lsb) or 9.908.

Question:

Would I be right in thinking that route b) is the more correct way to do it
and the error is due to the maths capability of the math routine?

I have got a routine to convert 16 or 24 bit to BCD and that works fine. But
what I need is a routine to convert BCD to 16 bit, does anyone know the
location of such a routine or, how best to go about this.

TIA,

Philip Martin.

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

It seems that the code library
also needs such a routine...

Any takers?

---
James Newton (PICList Admin #3)
jamesnewtonpiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}
All,

It seems to me I saw something like this in either the "PIC'n up the
Pace" book or "Easy PIC'n" book by David Benson.  It accepts a 5
digit decimal number and convert it to 16 bit binary.  You could use
this or modify it to suit.  I'm sure David would be happy if you
used it, as that is what his book was written for.  Check it out.

Regards,

Jim

On Fri, 19 January 2001, James Newton wrote:

{Quote hidden}

> {Original Message removed}
Hi,

Philip Martin wrote:

>I have got a routine to convert 16 or 24 bit to BCD and that works
fine. But
>what I need is a routine to convert BCD to 16 bit, does anyone know the
>location of such a routine or, how best to go about this.

Well there is a very easy way ( albeit fairly slow :) ) ( I'm using
it as I get digit by digit entered on keyboard ( and user input
tend to be slow if compared to pic-speed :) ) Anyway here goes:
In the case of a 24 bit variable 'allocate' 3 bytes of data
clear them. Add the left mostdigit, multiply by 10 add the next
digit etc. etc. *very* easy albeit slow as said.
24bit*10 can be generated by the code generator.
There are faster way to do this but sofar I haven't had the need for
such an routine.

/Tony

Tony Kübek, Flintab AB
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: tony.kubekflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

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

Multiplying by 10 in binary can be quite fast and simple:

10 = 8+2 = 2^3 + 2

Multiplication by a power of two can be accomplished by shifting, so in C

result = input*10;

can be written

result = input<<3 + input<<1;

or, more efficiently on some machines (such as PIC's):

result = ((input<<2)+input)<<1;

For 16 bits in assembler:

cblock  0x20
input:2 ;little-endian, i.e. least significant byte first
result:2
endc

Multiply_by_10:
movfw   input                   ;result = input
movwf   result
movfw   input+1
movwf   result+2

clrc                            ;result = result<<2
rlf     result,f
rlf     result+1,f
clrc
rlf     result,f
rlf     result+1,f

movfw   input                   ;result += input
skpnc
incf    result+1,f              ;carry
movfw   input+1

clrc                            ;result <<=1;
rlf     result,f
rlf     result+1,f
return

> {Original Message removed}
Hi,
I forgot to reply to your question Philip :)
anyway here goes:

Philip Martin wrote:
<snip>

>get into this figure to convert it into MPH. Thus 122.75 / 12.63
seconds
>would be 9.718 mph.

<snip>

>Route b)
>
>12275 = 2F (msb) & F3 (lsb) / 1263 = 04 (msb) & EF (lsb) = 00 09 (msb)
. 03
>83 (lsb) or 9.908.
>
>Question:
>
>Would I be right in thinking that route b) is the more correct way to
do it
>and the error is due to the maths capability of the math routine?

Well not really, you start with the value 12.275 which has as many digit
as you need
then you divide it, this way you are ( alomost ) bound to 'loose'
digits(accuracy).

If you instead convert it to 8.16 format you will have this:
122 = 0x7A
275 * 65.534 = 18021.85 = 0x4666
all togehter:
0x7A4666
Divide by 12.63 will generate:
0x09AE6B
to convert to 'fixed 4 digit after decimal point''
Multiply by 10000 / 256*256 = 0.152588 ( rounded )
will generate:
0x017A2D which is 96813 in decimal with 4 digits after dp we get
9.6813 mph which is closer than your original formulas.

I'm sorry for the bad example to the maths pro's on the list but I'm in
a hurry :)

/Tony

Tony Kübek, Flintab AB
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: tony.kubekflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

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

Philip Martin wrote:
>
> Many thanks to the two Tony's for your replies. Whilst the answers may not
> have directly helped solve the problem, they have certainly broadened my
> understanding of maths on the PIC. But it was the final comment in Tony
> Nixon's post that got me thinking, break the problem down into a manageable
> chunk.
>
> So my train of thought went, if the distance is a fixed value (60 yards),
> what would be the speed in MPH if it only took 1 second to travel this
> distance. Answer, 122.75 mph. Now all I have to do is divide whatever time I
> get into this figure to convert it into MPH. Thus 122.75 / 12.63 seconds
> would be 9.718 mph.

I feel a bit confused here, as I'm not sure what you are measuring here.

Is it a standing start over 60 yards? If so then your final MPH value
could be way out if the vehicle is accelerating the length of the track.

What you seem to be assuming is a constant speed over 60 yards.

I would have thought in your example, that the time taken and final
speed is all that matters.

--
Best regards

Tony

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

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

Hi Tony,

All I am interested in is obtaining the average speed over the distance.
Thus, from a standing start the time taken to cover the distance will (I
think) be representative of the speed including the acceleration time.

Whilst I'm here, brain hurt time!

I understand what you and the other Tony were saying about how to handle the
numbers. Interestingly, following the 16.8 (or 24.8) formula I make 122.75
into 2FF3 (12275) the same as multiplying it by 100 to 12275!

If I may, I will carry on and see if my logic makes sense to you (or anyone
else).

If I a have a number of 2FF3 (12275) and I divide it by 04EF (1263), what
the (a division) program code does is to subtract 04EF from 2FF3 and so long
as it will subtract from the number it adds 1 to the higher byte registers.
Now having reduced the number 2FF3 by 04EF it carries on doing this until it
cant anymore. The reduced number remaining is the number found in the lower
byte registers, i.e. 00 09 03 8C. 038C being 908, the number left over if
you multiply 1263 by 9 and the subtract it from 12275 (on a calculator).

I have tried this on several sets of divisions and it seems to work every
time.

Therefore so far the PIC division is concerned, it provides the number of
whole subtractions it can make, plus the remainder left over, that is
undividable, rather than the true division.

To gain the decimal places you can then multiply the remainder by 3E8 (1000)
and divide it by the original divider to get the first three decimal places.

Does this make sense, or have I got completely the wrong end of the stick?

Regards,

Philip Martin.

{Original Message removed}
Philip Martin wrote:
>
> Hi Tony,
>
> All I am interested in is obtaining the average speed over the distance.
> Thus, from a standing start the time taken to cover the distance will (I
> think) be representative of the speed including the acceleration time.

If you do a standing start and assume constant acceleration upto the end
point, the average speed will be half the final speed.

Example

Secs        MPH
0           0
1           10
2           20
3           30
4           40
5           50
6           60
7           70
8           80
9           90
10          100

Add then all up and divide by 11 = 50 MPH

That's assuming constant acceleration. Real life will be totally
different.

Example (sort of logarithmic)

Secs       MPH
0          0
1          10
2          25
3          45
4          65
5          75
6          83
7          90
8          95
9          98
10          100

Add then all up and divide by 11 = 62 MPH

As you can see the total time and final speed are the same, but the
average is diferent.

I would imagine you would need to take speed readings at set points
along the track to find a true average.

> Therefore so far the PIC division is concerned, it provides the number of
> whole subtractions it can make, plus the remainder left over, that is
> undividable, rather than the true division.
>
> To gain the decimal places you can then multiply the remainder by 3E8 (1000)
> and divide it by the original divider to get the first three decimal places.
>
> Does this make sense, or have I got completely the wrong end of the stick?

Sounds reasonable.

--
Best regards

Tony

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

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

Hi,

Philip Martin wrote:
<snip>
>Therefore so far the PIC division is concerned, it provides the number
of
>whole subtractions it can make, plus the remainder left over, that is
>undividable, rather than the true division.

Well not really pic-related but binary math's related :)
But true nethertheless.

>To gain the decimal places you can then multiply the remainder by 3E8
(1000)
>and divide it by the original divider to get the first three decimal
places.

Well yes.

>Does this make sense, or have I got completely the wrong end of the
stick?

Yes it makes sense. And the stick is probably pointing at the correct
direction.
( i.e the pointy end *away* from you :) )

/Tony

Tony Kübek, Flintab AB
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: tony.kubekflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:

> If you do a standing start and assume constant acceleration upto the end
> point, the average speed will be half the final speed.
>
> ...
>
> I would imagine you would need to take speed readings at set points
> along the track to find a true average.

Total distance divided by total time will always yield the average speed.
This is more reliable and easier than trying to average several

*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:

Olin Lathrop wrote:

> Total distance divided by total time will always yield the average speed.
> This is more reliable and easier than trying to average several
> instantaneous speed readings.

OK.

Now perhaps to find a simple solution to the problem...

Click crack click - (knuckles craking)

Assuming average speed = total distance / total time

Result able to be displayed in 00.00 MPH

Track distance = 60 yards

From previous discussion we can scale HEX integer values to produce real
value results.

60
Basic Formula = ------------
Time (S)

Therefore, according to previous formulas supplied, if Time = 1 second,
the final speed would be 122.72 MPH and the average would be 60.00 MPH.

Instead of using multiplication and division which could be 3 or 4
bytes, depending on accuracy, use addition instead.

Setup a loop at 100uS = 10,000 loops / second to give good accuracy.

Therefore after 10,000 loops using addition, the final result must be
60.

10,000 in HEX = 2710h
60 in HEX = 3Ch

Find a value for addition...

3C
------  is not going to work, so scale upwards
2710

3C 00 00 00
-----------   = 01 89 37
2710

Use 18937h for multibyte addition on each 100uS loop starting form 00 00
00 00.

On termination of run, the result will be in 4 bytes, assuming speed
does not exceed 255 MPH.

Eg

Test lasted 1 second

18937h
X      2710h  =  10,000 100uS loops
--------------
3BFFF470h
--------------

Use 3Bh for units and FF for decimal.

3B = 59 dec

FF = 255 X 100  = 99 dec
---------
256

Result = 59.99 MPH

--
Best regards

Tony

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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:

>                     60
> Basic Formula = ------------
>                   Time (S)
>
> Therefore, according to previous formulas supplied, if Time = 1 second,
> the final speed would be 122.72 MPH and the average would be 60.00 MPH.
>
>
> Instead of using multiplication and division which could be 3 or 4
> bytes, depending on accuracy, use addition instead.

Huh?  I didn't try following the rest of your description because of too
much hand waving, but it's hard to imagine how this last statement could be
true.

*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinembedinc.com, http://www.embedinc.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

Olin Lathrop wrote:

> Huh?  I didn't try following the rest of your description because of too
> much hand waving, but it's hard to imagine how this last statement could be
> true.

Yeah you are right Olin. I really had my head where the sun don't shine
on that one.

I was thinking of another application where I use that technique to
calculate advance delays in an ignition system.

--
Best regards

Tony

mICro's
http://www.picnpoke.com
salespicnpoke.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

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