Counting pulses

Hi everybody,

Well, I´m trying to build a digital speedometer for my car and I'm facing some problems I can not fix by myself.

I need to count incoming pulses for 1 second (sent by a Hall sensor), calculate the speed and show it in the LCD.

The problem is : I´m a hobbyst and I don´t know how to do that without loosing pulses.
I was using the COUNT method but it was not good.


Some guys told me that I should use TMR0 or TMR1 to do that.
But... I have no idea how to do that.
I'm using a 16F628
Could someone post a code showing how to count pulses within 1 second and show the results using INT/TMR0 or TMR1 ?

Thanks you.

regards

Sérgio Pinheiro

That's not going to help you. A one second window is not good for a speedo. Too many changes happen in 1 second and your display will be way out date from what's really happening.

It reminds me of the official 'post-mortem' of the Chernobyl accident I once came across at the back of a dusty Library shelf... where the main monitoring computer for the reactor took some 11 minutes to read all the sensors, calculate and display the result for the operators... which means the reactor status as currently displayed was that from 11 minutes earlier...

What they should have done is what I'm recommending for you - Reduce your count to 1/4 or 1/10th of a second and compensate your math accordingly. You'll get a much better feel for what's happening 'real-time' and the increased error is relatively insignificant.

Melanie

Personally I would probably use the extrernal interrupt pin. PortB.0 on a 16F87X.

Then write an asm interrupt routine to count it. Create some loop to diplay it and that's about it. I would probably scale it though to give you a interrupt for every pulse. All depends on how many RPM you need to count.

If you look at the "Lap Timer" discussion, I posted some code that you could use for it. Instead on using the external oscillator, use your sensor.

Hi everybody,

thank you all for the answers !

I have here more two doubts :

1) Melanie :

Is the Chernobyl's story true ? Eleven minutes ?
If I reduce the time to 1/10th of a second I'll be able to use the COUNT function without loosing pulses ? Is this method safe ?
I have been thinking about that for some time, and I´m afraid of loosing pulses while doing another things and at the end of the journey the total distance travelled could have a big error due to the pulses missed.

2) Mikep :

The method envolving the ASM is secure ?
Do you know if there are an ASM code available in PicList, for example ? Is it easy to implement ?
I don't know how to do that in ASM (yet), but could that be mixed with PBP ?

Regards.

Sérgio Pinheiro

PS. Thanks for your patience.

For a riviting non-fiction account... I would recommend... "The Truth about Chernobyl" by Grigori Medvedev. You can pick it up for a couple of dollars. He is one of the engineers who built the place and one of the subsequent investigators. I'll guarantee that once the action starts happening - you can't put it down. This is THE one... all other books about Chernobyl pale in comparison (the one written by Piers Paul Read is especially only good for land-fill).

The only way is tight code. Say your Sensor measures one count per tyre rotation and your tyre is 65cm diameter. At 200km/hour your Ferrari will give you approximately one count per 36mS. Providing your count accumulation, math, saving and LCD display output can be done from start to finish in less than that time, you won't lose any counts. It is achieveable.

The problem you have is that the PIC can only do one thing at a time. If you really don't want to miss counts and your skill at coding is, let us say, "less than optimum", I would recommend two PICs with your sensor connected to both. One can give you continuous display, the other is continuously counting only. At the end of your journey the counting only PIC (which need only be a baby like a 12F) can on request transfer the total count to the other for display.

If you attempt to tinker with PBP's method of interrupts by inserting your own assembler code to guarantee you don't lose counts, you will almost certainly upset and corrupt the operation of routines like LCDOut.

Melanie

For the interrupt routine, like I said, just take a look at the code I posted in the laptimer discussion. Adding ASM to PBP is very easy.

If you are worried about the LCD routines, than I would simply use a serial LCD.

If you go here, http://www.hvwtech.com/pages/product...=5&SubCatID=18 and take a look at the serial interface LCD kit.

I use this in a few projects to save on pins and it works very well.

You can also use a LED display with a MAX7219. Takes only 3 pins and is only a simple a quick serial out.

The nice part about the interrupt is that you will not miss any pulses. And you can even have it so that the time it takes to complete a cycle is not fixed. So if for some reason it does take a bit longer to complete a cycle you just change the math a bit.

By the way, I'm not saying Melanie's approach is not the way to go. There are simply many ways to skin a cat.

Do you have any numbers of how many revolutions you can expect in a minute. Lowest? Highest?

Hi people,

thank you again for the answers.

Melanie, thanks for your advice about using another PIC. Actually I have some 12F available here and I´ll try to do what you suggested.
well... I really would like to have a sport car, but I have a small Opel Corsa.... (150 Km/h max speed). Here in Brazil the max Speed allowed in the highways (some of them) are 120 Km/h and the fines related to speeding are rally expensive (US$200,00) !

Mike, my car´s hall sensor will give me 8 pulses for each turn and my wheel is 14" . If my math is right it will give me almost 300 pulses/s at maximum.


Regards

Sérgio Pinheiro

mikep

While agree that you should not worry about interrupts in general, using any routine that has timing in it i.e. Serial will get messed up. LCD routines though do not from my experience suffer.

Concidering the requirements he has you could happly implement a counter based on direct interrupts when he gets a pulse or using a counter to do the counting for you. One thing you do need though is a time base to work to. No good saying you have received 100 pulces if you do not know over what period you collected them.

I decided this would make a good project so am currently writting an artical how to count pulces over a preset period, all in the back ground via an interrupt routine. Just read the result when required. Should be operate from 4hz to about 26,000 hz (or a bit more). I will let you know when it's done.

Tim

Hi Tim,

the article you´re writing will be perfect for my application.

Would you post this article in this Forum ?

For the time being, I will try to implement Melaine suggstion (use a 12F just to count).

Thank you !

Regards

Sérgio Pinheiro

I see your point. So basically you need to disable interrupts before outputting on the serial port.

Which if all he wants is speed that would be ok. since you simply are comparing the number of counts over a specific period of time. However for distance it could make a slight difference.

My question is why serial? If the aim is to connect to a display and interrupts will not interfere with it, I would go with direct connection.

The software is very simple only a few lines. What has surprised me is what a pain working with TMR0 is! I always use tmr1 on 1:1 16 bit easy to reload and get the count you require, TMR0 by comparison is 8 bit which ever way you go you have to have a load of interrupts. Still the in reality the CPU spends most of it's time doing nothing but delay's why not make it do some work for a change.

Re were I will post it.

I find that posts to forums get lost after a few days and all your hard works gone into the archives. So I worked with another user (good man) and we with help (from Lester) set up a user site. It's there for posterity then.

Hi Tim,

could you share the site´s URL ?

regards

Sérgio

http://users.picbasic.org/

Don't worry about it being for another compiler most of the stuff will work with only a little conversion.

Apart from PPRINT that is! O and the games to

Tim