I'm using the PSoC1 as essentially a multi-channel frequency counter using 16-bit counters to count frequencies from 10kHz to 100kHz. Hardware-wise, the Enables of the counters are tied to Vcc, and the clock/count input is tied to the frequency to be counted to allow direct pulse counting. There is some calculation involved using the starting counter value, the ending counter value, and the number of times the counter has rolled over between samples. The problem arises from input frequencies greater than the counter period. On occasions where the counters rollover twice between samples, the second rollover is failing to be accounted for, leaving the final frequency count a full counter period less than its actual frequency.
I think my problem arises from the fact that I'm running the frequencies to be counted into the clocks of the counters. I believe this limits the interrupt response time, causing the missed TC count increment. I simply need confirmation if this is the case.
Depends on what you are doing in ISR, Global clock settings, consider posting your
project so we can take a look at it.
Could also be not declaring global variables used in ISR as volatile.
Consider posting your project, makes life easier to troubleshoot.
Thanks for the response, Dana. My main problem was lack of resources, so I ended up circumventing the problem using a few dynamic reconfigurations to get the extra 8 bits I needed in each counter, eliminating the need for counting rollovers. And it was much less painless of a learning process than I had initially imagined.
Excellent way to solve the problem. One of the strengths of PSOC 1/3/4/5LP is
the dynamic reconfig, although its being de-emphasized in 3/4/5LP families.
Biggest caution in using it is pay attention to the fine print foot notes of other effects
register changes have.
As an aside I did some freq cntr work on PSOC 1 and used a timer to provide the gate,
tied that in HW to counter enables. And to a buffer to gen an interrupt at end of gate period.
That was done to avoid latency and eliminate uncertainty due to ISR servicing. That being
said my counters were big enough (you do not have the luxury of) to never overflow, so
my challenges less than yours.
Here is some ref material that may be of interest -
What ISRs do you have in addition to the counter related ISR ? Also consider internal clock
accuracy specs, unless you are running on external xtal, its quite significant in timing inaccuracy.
Additionally any blocking functions you use can impact this. Thats why non ISR approach,
and external xtal, will get the best results.
Thanks for being on top of this thread. I learned that that system had been previously programmed at 5v. With all components running on 3.3v, things were breaking down. So I've flashed a new system and now my counts are actually above the input frequencies. There is some roughly 200mV noise on these incoming frequencies, but I don't think that this should have any impact on clocking or counting when riding on a 3.3v square wave. Reading the counter datasheet doesnt provide any clues on the clocking of the counters either.
Are you on an xtal for main clock or internal PSOC clock ? What freq are
you running for COU clock ?
Its not the clock in I am concerned with, its the time base you use to
interpret the counts in the counter. Thats the one with the greatest impact
on chip to chip accuracy.
You're correct. I was using the internal 32kHz clock for my timer module, so my sampling times were not quite 1Hz, just a bit under that. I used VC3 as a 1MHz timebase instead, got much more precise timing, and the overcounting resolved itself. thanks!