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

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.
2001\01\19@143109
by
jamesnewton
2001\01\19@144536
by
James Paul
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}
2001\01\19@172234
by
o88591?Q?K=FCbek_Tony?=

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 picspeed :) ) 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
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
Email: tony.kubekKILLspamflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2001\01\19@174655
by
Don Hyde
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 ;littleendian, 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
addwf result,f
skpnc
incf result+1,f ;carry
movfw input+1
addwf result+1,f
clrc ;result <<=1;
rlf result,f
rlf result+1,f
return
> {Original Message removed}
2001\01\19@175316
by
o88591?Q?K=FCbek_Tony?=

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
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
Email: .....tony.kubekKILLspam.....flintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2001\01\21@173617
by
Tony Nixon

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
EraseMEsalesspam_OUTTakeThisOuTpicnpoke.com

http://www.piclist.com hint: To leave the PICList
piclistunsubscriberequestspam_OUTmitvma.mit.edu
2001\01\21@201554
by
Philip Martin

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}
2001\01\21@205203
by
Tony Nixon

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
@spam@salesKILLspampicnpoke.com

http://www.piclist.com hint: To leave the PICList
KILLspampiclistunsubscriberequestKILLspammitvma.mit.edu
2001\01\22@055713
by
o88591?Q?K=FCbek_Tony?=

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 picrelated 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
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
Email: RemoveMEtony.kubekTakeThisOuTflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: >uP ONLY! [EE]:,[OT]: >Other [BUY]:,[AD]: >Ads
2001\01\22@090513
by
Olin Lathrop
> 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
instantaneous speed readings.
*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 7723129, spamBeGoneolinspamBeGoneembedinc.com, http://www.embedinc.com

http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: >uP ONLY! [EE]:,[OT]: >Other [BUY]:,[AD]: >Ads
2001\01\22@195120
by
Tony Nixon

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
TakeThisOuTsalesEraseMEspam_OUTpicnpoke.com

http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: >uP ONLY! [EE]:,[OT]: >Other [BUY]:,[AD]: >Ads
2001\01\23@093133
by
Olin Lathrop
> 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) 7723129, RemoveMEolinTakeThisOuTembedinc.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
2001\01\23@171529
by
Tony Nixon
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
salesEraseME.....picnpoke.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...