>I suppose it's a 26-bit (32) divide by 16-bit, but that's probably
>some serious code.

Yep!

I don't have a divide 32 by 16 but 48 by 24
http://www.piclist.com/techref/microchip/math/div/48by24ng.htm
is 108 instructions (about)

If you can scale it down a bit to 25 by 16
http://www.piclist.com/techref/microchip/math/div/24by16.htm
is only 28 instructions 608 cycles.

Division into a constant ought to be possible and more efficient. How about
a "Reciprocal" under a maximum value like an extension of
http://www.piclist.com/techref/microchip/math/div/recip32k-ng.htm
followed by a multiplication by constant
http://www.piclist.com/techref/piclist/codegen/constdivmul.htm
?

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

-----Original Message-----
From: pic microcontroller discussion list
[mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Drew Vassallo
Sent: Thursday, December 21, 2000 12:06
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: [PIC]: Challenge! (Everyone loves a...)


>maybe I'm missing something (AND I don't have a solution to offer),
>but it looks to me like the rpm is inversely related to the timer value,
>which means simply dividing by 15 won't work.  The basic equation looks
>to me like:
>
>        60 x 1,000,000         (conversions for minutes and us)
>rpm = ------------------
>      16 bit timer value
>
>Also looks like the slowest speed that can be measured with 1us ticks
>and a 16 bit number is 915 rpm... (is this adequate?)
>Again, *I* don't know how to do this is 50 words!

No, you're not missing anything.  It is not a 'divide by 15' or anything
that simple.  You're right on with the 915 rpm max.  Too bad you don't have
a solution, you seem to understand the problem :)

I suppose it's a 26-bit (32) divide by 16-bit, but that's probably some
serious code.  Too bad Nikolai doesn't have an "inverse of a multiply by a
constant" code generator :)

And yes, 915 rpm as the lowest limit is more than adequate.  A max of about
20,000 rpm is the absolute ceiling, but that's not a problem as a count of
0x0001 is over 230,000 rpm.

Using an actual time value rather than a "number of counts per XX time"
gives a MUCH improved resolutionn and lower error.  However, if anyone
offers a method that makes use of the "number of counts per XX time" that is
within 200 rpm, I'd probably take that.

--Andrew

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body