Best way to count pulses...

[rntilden]

I need to count pulses coming from an optical sensor (TSL230R) with a Mod5270. What's the best way to go about this? The maximum frequency is on the order of 10Khz (could be scaled less). I need to read out the count occasionally, so an accumulated count time of a second or two would be fine. Anybody do something like this? For a tachometer project perhaps?

Thanks!

[yevgenit]

Method 1 (counting the pulses): apply the pulse source to the count input of any General Purpose Timer. You will need to arrange atomic operation "read-then-zero" during rare polling the timer - without missing the pulses.
Method 2 (counting duration of the pulse): apply the pulse source to the enable input of any General Purpose Timer, and apply the system clock to the count input of this General Purpose Timer. Arrange the interrupt by event of write to the capture register. This method is very accurate with low frequency of the pulses.
Method 3 (counting pulses without hardware timer): apply the pulse source to the external interrupt input. This method is good enough for low frequency of the pulses.
All the methods need care of the overflow event.

(Some synxax is fixed).

[Ridgeglider]

If all you need to do is COUNT pulses (as opposed to TIMING them) you would consider Yevgeni's Method 3 an just increment a count variable with an interrupt triggered off one of the EPORT inputs. If this ISR is the only thing writing the variable, and assuming it is an atomic 32 bit variable, other code can easily read it at any time to know the count. To reset the count, disable the IRQ, set the count to 0 and re-enable. There is an example that will get you close at http://www.netburner.com/downloads/mod5 ... rrupts.zip. That example sends a semaphore for each IRQ, but it would be easy to modify the ISR to increment a count instead. Note that The EPORT inputs (as well as the timer inputs) have a limited choice of pins; sometimes pin availability or alternate usage determines your approach. As Yevgeni notes, the EPORT / IRQ method would have higher overhead than a dedicated hardware timer in count mode.

Of course if you just have a count (collected this way or via Yevgeni's Method 1), you care when you read it and reset it; you are therefore likely to wind up with an additional periodic timer interrupt anyway to systematically read the count (variable or register) at a known interval, say exactly 1x/sec. It may therefore be easier to simply use Yevgeni's method 2 to measure the duration (ie period) of each pulse. If you go that route, consider how stable the frequency input you are measuring is. Do you really want to know every pulse's period, or would you prefer to average it over a longer time? Naturally this route makes you consider: how long can I wait for an answer? It's always a balance... And like Yevgeni said: watch out for overflows!

Just some things to think about!

[yevgenit]

Ridgeglider,

thanks for the significant notes about hardware and real-time software considerations on the frequency and count measurement.

[lgitlitz]

I would definitely use method 1 for a 10KHz signal that you only need a pulse count. You should use a DMA timer with a one of the timer inputs set to be the clock. No need for an atomic reset since the time is large enough to know when an overflow occurs even if you go many hours between checks... you get over 100 hours till overflow at 10KHz. Just keep track of the last read pulse count and you will have to handle the overflow every few days:

Code: Select all

read_count = sim.timer[x].tcn;
if (current_count > read_count)
   current_count = ( read_count + ( 0xFFFFFFFF - current_count ) );
else
   current_count = read_count;

A 10KHz interrupt would really bog down the CPU, this would probably be close to full CPU time if the task stack is in SDRAM instead of SRAM.

[rntilden]

Thanks for all the help! I ended up using one of the DMA counters and a delay loop. I read out the counter, zero the counter, and wait 10 seconds before repeating. I'll probably refine the delay loop part with an n second counter that generates an interrupt to read and zero, but for now I have it working.

[pbreed]

Why zero the counter?
When you zero you could loose a pulse, the counter is 32 bits, so just remember the last value and calculate the difference.

That way you can't loose any pulses.

Paul