Embedded C program - Detecting pulses from another chip when RPM is low but skips some of the pulses

MrChips

Joined Oct 2, 2009
19,269
What do you wish in the thread title? A moderator can edit the title for you.
 

MrChips

Joined Oct 2, 2009
19,269
Generally speaking, events are lost when the MCU is not fast enough to keep up with multiple events in rapid succession.
This is a common problem when the code uses polling techniques. If this is the case, there are ways to improve the performance of the system.

One way is to use interrupts.

Another way is to allow the hardware to do the counting. Many MCUs have internal timer modules that can be incremented directly from external clock pulses. Counting rates higher than 1 million events per second are not unusual.
 

Thread Starter

anon1

Joined Jan 25, 2018
13
Generally speaking, events are lost when the MCU is not fast enough to keep up with multiple events in rapid succession.
This is a common problem when the code uses polling techniques. If this is the case, there are ways to improve the performance of the system.

One way is to use interrupts.

Another way is to allow the hardware to do the counting. Many MCUs have internal timer modules that can be incremented directly from external clock pulses. Counting rates higher than 1 million events per second are not unusual.
After a slight modification of my code, it seems that it's no longer skipping any incoming pulses, but if a pot reading of 0 corresponds to 1ms and a reading of 255 corresponds to 5ms, shouldn't that range stay the same even at a different RPM?

If the overflow time (the time it would take to count up from 0 to 65536) is 1.6 seconds, surely it should remain the same regardless of the RPM? The RPM changes the rate at which the high part of the sync pulses come in, but why would that cause the timer counter to change how fast it would count from 65500 to 65536 - if that value corresponds to 1ms at 100 RPM, should it not correspond to 1ms at 6000 RPM? Whether the timer is referring to an internal or external clock, why might a change in RPMs cause it to have changed, thus causing the overflow time to seemingly change, and count slower or faster? I'm not looking for any definite answers, just trying to understand what might be happening in the background that I'm not realising.

The value that is written into the timer0 is calculated and stored as a variable that is always less than 65536 and that in turn depends on the pot reading (which is in turn converted via the ADC).

I've been advised to avoid interrupts for now.
 
Top