On Monday, September 26, 2016 at 1:31:46 AM UTC-7, frank wrote:
> Hul Tytus <ht@panix.com> wrote:
> > 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?
> 
> 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).

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.

On 25/09/16 10:51, frank wrote:
> 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.

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.

Hul Tytus <ht@panix.com> wrote:
> 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?

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.

Frank

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?

Hul

frank <frank@invalid.net> wrote:
> 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
> counter.
> 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

> Frank

On 9/25/2016 11:35 AM, frank wrote:
> Don Y <blockedofcourse@foo.invalid> wrote:
>>
>> I think you will find that the datasheet gives you no guarantees on the
>> *value* of the data read!  (read carefully  :> )
>
> 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.

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).

> 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 :)

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.

>>> 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.
>>
>> 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)
>
> 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.

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
values)

On 9/25/2016 2:35 PM, frank wrote:
> Don Y <blockedofcourse@foo.invalid> wrote:
>>
>> I think you will find that the datasheet gives you no guarantees on the
>> *value* of the data read!  (read carefully  :> )
>
> 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 :)

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.

>>> 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.
>>
>> 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)
>
> 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.

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

Don Y <blockedofcourse@foo.invalid> wrote:
> 
> I think you will find that the datasheet gives you no guarantees on the
> *value* of the data read!  (read carefully  :> )

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 :)

>>
>> 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.
> 
> 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)

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.

Thannks
Frank

On 9/25/2016 4:41 AM, frank wrote:
> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 9/25/2016 1:51 AM, frank wrote:
>>> 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
>>
>> A processor is a synchronous system; it does everything wrt its internal
>> clock -- reading/writing memory, I/O's, etc.
>
> typically  yes.
>
>> 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.
>
> 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).

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?]

>> 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.
>
> 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.

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)

Don Y <blockedofcourse@foo.invalid> wrote:
> On 9/25/2016 1:51 AM, frank wrote:
>> 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
> 
> A processor is a synchronous system; it does everything wrt its internal
> clock -- reading/writing memory, I/O's, etc.

typically  yes.

> 
> 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.

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).
>
 
> 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.

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.

Frank