On Aug 6, 2:08 pm, Joerg <notthisjoerg...@removethispacbell.net>
wrote:
>
> Sure I know but it would be rather wasteful to block a MCU for pretty
> much any other task that way. Typically in an application like this your
> MCU needs to also calculate the RPM value, maybe do red range alerting,
> package it nicely in a format some display understands and then send it
> out via a link to an HD44780 chip. Or directly to glass.
>
> Using a timer would be the smart thing to do.

That depends entirely on the application.  If this is an embedded
device that only has to relay the information to some other location
or just drive an LED display and you need to save *cost* or even
*power* a chip without a timer will be cheaper and still be able to
perform the function.

The OP gave no indicate of needing to drive an HD44780 chip or even
redlining!  I did read something about using it on a bicycle!!!  How
many RPM will your bike do before it blows a rod?

Rick

On Thu, 7 Aug 2008 08:19:17 -0700 (PDT), rickman <g...@gmail.com>
wrote:

>On Aug 6, 2:08 pm, Joerg <notthisjoerg...@removethispacbell.net>
>wrote:
>>
>> Sure I know but it would be rather wasteful to block a MCU for pretty
>> much any other task that way. Typically in an application like this your
>> MCU needs to also calculate the RPM value, maybe do red range alerting,
>> package it nicely in a format some display understands and then send it
>> out via a link to an HD44780 chip. Or directly to glass.
>>
>> Using a timer would be the smart thing to do.
>
>That depends entirely on the application.  If this is an embedded
>device that only has to relay the information to some other location
>or just drive an LED display and you need to save *cost* or even
>*power* a chip without a timer will be cheaper and still be able to
>perform the function.
>
>The OP gave no indicate of needing to drive an HD44780 chip or even
>redlining!  I did read something about using it on a bicycle!!!  How
>many RPM will your bike do before it blows a rod?
>
>Rick

Sometimes you have to do ugly things like write isochronous code and
deal with memory banking or 4-bit processors in order to make the
product affordable. Not every application can afford those expensive
boutique microcontrollers with every peripheral known to man, you
know. ;-) 
Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
s...@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

N1 wrote:
> I'm working on a data acquisition system for byke/car engine.
> I'm trying to figure out which would be the best way to count RPM and 
> I've thought to two different ways:
> 1- using an interrupt routine attached to a digital input to count, say, 
> 10 revolution and then look how much time passed between the first and 
> the tenth to figure out ho many would they be in a minute.
> 2- using an IC to transform frequency to voltage and then read it from an 
> analog input.
> 
> I think that solution 2 is better and cleaner but I'd like to keep 
> everything on the same board. On the other side I don't know if the 
> solution 1 would be accurate enough.
> 
> Max value would be 18000rpm that is 600hz for a 4 cylinder, 4 stroke 
> engine...pretty low for most MCU. It'd be ok to have a resolution of 
> 100rpm (3HZ). 

Taking another angle on this:
As the OP says "data acquisition system",
and when logging, it is always a good idea to not lose precision.

So, you could simply decide a timer LSB (eg 10us?), and then store
a timestamp for every spark. (or, time since last spark),
or lower 16 bits of timer (almost the same thing), and that's
a simple 16 bit capture operation.

Serial flash memory is cheap for large storages, and this would
allow your PC processing to do whatever it needed, on averaging, trends,
etc
-jg

rickman wrote:
> On Aug 6, 2:08 pm, Joerg <notthisjoerg...@removethispacbell.net>
> wrote:
>> Sure I know but it would be rather wasteful to block a MCU for pretty
>> much any other task that way. Typically in an application like this your
>> MCU needs to also calculate the RPM value, maybe do red range alerting,
>> package it nicely in a format some display understands and then send it
>> out via a link to an HD44780 chip. Or directly to glass.
>>
>> Using a timer would be the smart thing to do.
> 
> That depends entirely on the application.  If this is an embedded
> device that only has to relay the information to some other location
> or just drive an LED display and you need to save *cost* or even
> *power* a chip without a timer will be cheaper and still be able to
> perform the function.
> 
> The OP gave no indicate of needing to drive an HD44780 chip or even
> redlining!  I did read something about using it on a bicycle!!!  How
> many RPM will your bike do before it blows a rod?
> 

An RPM meter on a bicycle? Now that would be something. I blew many rods 
on my bicycle when I was young ;-)

Even on a car the pulse distance measurement is really the only 
practical way. But yeah, we'd need more info here. I just worked on a 
truck RPM meter (for the really big road machines out there) and even 
there a 600msec update rate won't fly.

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.