AVR w/ asynchronous counter?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi all,
I'd like to make a very simple frequency counter (should be single chip  
ideally), let's say to max 25 MHz more or less, 6 digits resolution.
A PIC microcontroller, using an internal counter with asynchronous  
external clock is one possible solution.  
However, I would greatly prefer to use an AVR microcontroller here
as I already have lots of code and experience with them.
On the selector guide of the atmel site, there isn't a way to filter
for asyncrhonous (to the main clock) counter input and the majority
of the AVRs I have seen have only a synchronous option for the external
clock to the timers, and that's not suitable for an easy job as a frequency
Does anyone know if atmel ever made a similar thing on any 8 bit AVR?
I'd avoid reading all possible datasheets to search for it.
Thanks in advance


Re: AVR w/ asynchronous counter?
On 9/25/2016 1:51 AM, frank wrote:
Quoted text here. Click to load it

A processor is a synchronous system; it does everything wrt its internal
clock -- reading/writing memory, I/O's, etc.

Typically, "asynchronous" clock inputs (e.g., for counter/timers)
are synchronized with the internal processor clock before feeding
a multistage (bit) counter that is updated synchronously with that
CPU clock.

This allows that SINGLE input to undergo the synchronization necessary to
interface to the processor's synchronous system.  Otherwise, the many bits
of the counter changing as a result of that *asynchronous* clock (count)
input would have to be synchronized to the CPU's clock -- along with each
other (so the CPU doesn't see bit X changing while bit Y hasn't ALSO
been seen as having changed)

For this reason, there are usually upper limits on the "count/clock"
input frequency -- expressed relative to the processor's clock frequency
(to accommodate the synchronizer in the front end of the counter/timer)

[You can design for an asynchronous counter but it is harder and
usually not necessary in most applications -- esp given the relatively
high clock frequencies of modern processors]

Consider, instead, adding a divider upstream of the counter/timer input
so you're actually counting f/N in some interval P.  Then, scale the
result accordingly.  For more precision in your reading, increase P
and/or decrease N -- subject to the limitations imposed by the processor's
data sheet.

Re: AVR w/ asynchronous counter?
Quoted text here. Click to load it

typically  yes.

Quoted text here. Click to load it

not on most PICs, asynchronous is really not synchronized with the main CPU  
clock. So a simple 16F84 running with a slow (<= 10MHz clock) can easily
count frequencies up to 40-50 MHz using the async option and a neat trick
to read the internal prescaler which isn't directly readable (making it count  
with an internal pin, after the end of the counting gate to make it overflow).
Quoted text here. Click to load it
Quoted text here. Click to load it

yes this is an option, but I need to add too many components. I'll
go for a PIC or more likely I'll implement all into a small cpld.


Re: AVR w/ asynchronous counter?
On 9/25/2016 4:41 AM, frank wrote:
Quoted text here. Click to load it

I think you will find that the datasheet gives you no guarantees on the
*value* of the data read!  (read carefully  :> )

Being a big fan of frequency-based converters (V-to-f, I-to-f, etc.) and
processing in the frequency domain, in general, I have a particular
fondness for counter/timers (and lament the death of the bloated 9513).
We used one in a data acquisition system and wondered why we lost "so
many LSb's" of accuracy (contrasted to known references).

[The whole point of the frequency-based converters was to trade time
for INCREASED accuracy and precision; silly if that approach ends up
LOSING precision by the introduction of uncertainties]

It took a fair bit of investment in a test rig (so we could emit
a precise number of pulses in a precisely defined window of time
to compare with what the code was telling us) but we decided
that the implied precision was illusory; there as no "special magic"
in the device's handling of the different clock domains -- the magic
lay in the assumption of how the device would be "applied".

We ended up having to rely on the internal prescaler with followup
(internal) synchronizer -- essentially negating the value of operating
at the higher frequencies (desired to reduce the integration time).

When you're done, hook your device to a known, constant frequency source.
Then, explain why the numbers jump around:  "Pick one: it has as good
a chance as any of being 'correct'"  :>

[To subvert any filtering you are doing in software, try changing
the input frequency and observe the results.  Then, imagine *it*
changing independently of your actions:  How confident are you of
the observed results?]

Quoted text here. Click to load it

Turn on the internal prescaler and the synchronizer.  Or, use the
timer as a BIG prescaler (i.e., NEVER read its actual value) and
just look at the synchronous "carry out"/overflow (i.e., use it to
measure the *period* of a very large number of input clocks)

Re: AVR w/ asynchronous counter?
Quoted text here. Click to load it

of course one has to pay attention when reading such asynchronous  
registers: basicly you read it twice comparing the high byte to
see if it's stable, otherwise read it all again.
There're compromises everywhere, but it was just perfect for what
I needed to do.
I just need the 100 Hz precision over a 1-25 MHz range, it's not
rocket science :)

Quoted text here. Click to load it

well this is a good idea too. I'll make some experiments on a couple
of different circuits, the ones that gives correct results with the
less components, wins.


Re: AVR w/ asynchronous counter?
On 9/25/2016 2:35 PM, frank wrote:
Quoted text here. Click to load it

Yes, the trick with a freq counter is getting the value from the  
counter.  You either have to sync reading the counter with the input  
clock or you have to halt the counter to read it or you use a very  
complex means of reading the counter to get an error free reading, but  
with a CPU this takes time and distorts the measurement.

I do freq counters in FPGAs where I have total control over the logic of  
the freq counter.  A low end CPLD could do this job easily.

Quoted text here. Click to load it

The trouble is this method only works well for faster clocks.  In  
essence you are swapping the role of the time base and the clock being  
measured.  It rather takes a long time to measure a slower clock this way.

Using a counter synchronous to the CPU clock will work for measured  
clock rates up to half the CPU clock rate.  If you don't need faster  
measured rates, this will work fine.  If you need to measure faster  
clocks you must have an async counter unless you use a prescaler.


Rick C

Re: AVR w/ asynchronous counter?
On Sun, 25 Sep 2016 14:57:11 -0400, rickman wrote:

Quoted text here. Click to load it

This, if you can make it work together with everything else.

Re: AVR w/ asynchronous counter?
On 9/25/2016 11:35 AM, frank wrote:
Quoted text here. Click to load it

So, you're not seeing 16 bits of count.  Instead, you're seeing *certain*
16 bit values.

If the input clock is higher than the processor's clock, you KNOW the
low byte has been changing *during* the read of the low byte (not
even concerned with the value of the high byte at this point).

Quoted text here. Click to load it

At 1MHz, 100Hz is 1:10000 (~14b).  At 25MHz, it's 1:250000 (~18b).
Said another way, your 100Hz is a "read jitter" of 4 microseconds.

Quoted text here. Click to load it

A smarter way (if the input is reasonably static in the frequency domain)
is to autorange the measurement; take a peek at it, then tweak the
configuration of the front end to give you more data per unit time.
I.e., reduce the prescale factor for lower frequency inputs so you
can get more "counts" in less (elapsed) time.

This allows you to keep your "update interval" more constant
(you don't want to have to force the user to "wait longer" to
see low frequency values to the same precision as high frequency

Re: AVR w/ asynchronous counter?
If memory serves, Atmel does have a counter with an asychronous input on  
one/some of the avr devices. I'd check the 44/88/168/328 family first,  
then the new avr's, avrx?


Quoted text here. Click to load it

Re: AVR w/ asynchronous counter?
Quoted text here. Click to load it

asynchronous on the AVR world means you can clock one of the counter with a  
separate oscillator or crystal, but it means also it must always be a few
times slower than the main cpu clock. And, if you use the external oscillator
for the counter, you must use an internal cpu clock, since both clocks would
use the same pins (either one or the other).

I'm definitely going to a different soultion.


Re: AVR w/ asynchronous counter?
On Monday, September 26, 2016 at 1:31:46 AM UTC-7, frank wrote:
Quoted text here. Click to load it

If you distrust the builtin counter because it loses pulses, consider using
a 74HC193 as prescaler, with some GPIO pins to get those LSB bits back.  
At the appointed gate time,  gate the UP clock pin off, read the count most-significant bits
from your internal counter, and pulse the DOWN clock into the '193 until the BORROW
tells you that the prescaler's four bits are now empty.
It takes two GPIO pins, three if you let your gate source be synchronous to
the AVR.   As a minor benefit, the timer can capture clocks faster than the AVR.

tells you it's empty.

Re: AVR w/ asynchronous counter?
On 25/09/16 10:51, frank wrote:
Quoted text here. Click to load it

Don't just guess about the frequency here - find out what you actually
need.  Also consider duty cycle (minimum high and low times).  25 MHz is
near the boundary of what is possible with many types of microcontroller
- you might find that reducing that to 20 MHz or 15 MHz gives you a much
wider selection.  A couple of T-flipflops before the microcontroller
will reduce the frequency to a much more friendly level, and clean up
the signal and its duty cycle.

For AVRs, you might find the ATxmega E series can handle this - the
custom logic may be able to give you the flip-flops.  (I haven't used
the part myself, and don't know the details.).  But still, an external
flip-flop chip would let you use the smallest and cheapest
microcontroller around.

Site Timeline