Tachometer lcd help [16f877]

[Fletcher]

I have a fan which pulses twice per revolution feeding into the interrupt pin of a 16f877. I work out the rpm using timer1 to count between each pulse. Is it possible to display the real rpm on an lcd display using that method? Or do i have to count pulses?

 

[Nigel Goodwin]

I have a fan which pulses twice per revolution feeding into the interrupt pin of a 16f877. I work out the rpm using timer1 to count between each pulse. Is it possible to display the real rpm on an lcd display using that method? Or do i have to count pulses?

Perfectly possible, the two are exactly proportional to each other - it's a simple maths operation.

 

[eblc1388]

Is it possible to display the real rpm on an lcd display using that method? Or do i have to count pulses?

You will find that the timing will varies between pulses and so your calculated rpm value will have different values between pulses. You have a super fast response this way and it is best for very slow speed rotation.

Alternatively, counting pulses within a fixed time interval gives a more accurate result for fast fan rotation.

It all depends on your objective.

 

[Fletcher]

Ok, sounds promising. I may need some help though.

Currently i have a hex value like #1A7C, converted to decimal - 6780, divide by 0.4us = 16950, divided by 100000 = 0.01695 seconds, inverted = 58.99 * 60 = 3539rpm

Im not sure how to handle small numbers using assembly code.

 

[Nigel Goodwin]

Yes, there's a point where one becomes 'better' than the other, but for rotating mechanical objects (such as a fan) time period measurement is generally far preferable - pulse counting is far too slow!.

For example, if you want 1Hz resolution then it takes 1 second per reading, or for 0.1Hz resolution it takes 10 seconds per reading. Using time period measurement only takes the time of a single pulse, no matter what the resolution.

For an example, if a device is rotating at 6000 rpm, then pulse counting per second will be 1% accurate, if the same device rotates at 600 rpm, the accuracy drops to only 10%.

If you check the (VERY old) MicroChip frequency counter application, it auto-switches between the two, using the best whatever the incoming frequency.

 

[Pommie]

Ok, sounds promising. I may need some help though.

Currently i have a hex value like #1A7C, converted to decimal - 6780, divide by 0.4us = 16950, divided by 100000 = 0.01695 seconds, inverted = 58.99 * 60 = 3539rpm

Im not sure how to handle small numbers using assembly code.

I think you need to play with big numbers.

Your calculations end up as 24,000,000/Count = RPM.

So, you'll end up with a 32bit/16bit division. In the above case that would be 0x16E3600/0x1A7C.

Have a look at **broken link removed** for 32 by 16 divide routines.

Mike.
edit wrong number.

 

[Nigel Goodwin]

Ok, sounds promising. I may need some help though.

Currently i have a hex value like #1A7C, converted to decimal - 6780, divide by 0.4us = 16950, divided by 100000 = 0.01695 seconds, inverted = 58.99 * 60 = 3539rpm

Im not sure how to handle small numbers using assembly code.

I agree with Pommie, don't use small numbers, use BIG numbers - scale the values so they remain integers - floating point maths is inaccurate and VERY, VERY slow!.

I've never been very impressed with the MicroChip maths routines, but there are 32 bit maths routines available on the EPE website.