Count frequency with ATmega16?

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

I may have a blackout right now but I can't remember how I should count the frequency from a TSL230 unit.

How should I measure the frequency I get?

/Henke

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use the input capture function of timer 1 to record the time between two rising (or falling) edges. Be sure to count overflows of the timer as well.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any code how to do this?

/Henke

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just wait till the blackout subsides?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An easier way would seem to be to just use the comparator and count how many times it toggled vs a timer (if the timer lasted 1 second then no math would be needed to find frequency in Hertz).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

An easier way would seem to be to just use the comparator and count how many times it toggled vs a timer (if the timer lasted 1 second then no math would be needed to find frequency in Hertz).

Ummm--why would that be any "easier" than letting the AVR do the counting, with no clock cycles used except every time period?

Yes, there are any number of ways to do it. Timer-as-counter is the "best" with frequency range needed up to `1MHz. [that part can be scaled-down if desired if you want to fit into, say, 16 bits for a whole second.]

[OK, I used the superlative "best". The flame gates are open. ;) ]

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is generally "better" to allow internal hardware (ie, timers, capture registers, etc) to handle things for high rate events. If some arithmetic conversion is needed at a low rate (say, once every count period), then its not much burden.

All that said, if the high rate is actually pretty low rate (say mains frequency), then everything happens so slowly that it makes little difference. Except: you have timing variability if you rely on interrupts to handle the input; that CAN effect things at the edges of the timing interval.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's a project you can look at. He has a description of what he did but I don't know if you can get the source code:

http://www.qrpkits.com/freqcount...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The counter in the link ist using the external clock to one timer.
For high frequencies using the external clock is a good solution, the only one without extra hardware. The conting method is limited to a resolution of one over gate time.

For Frequencies below about 1% (2-3% in ASM) of the processor clock it is possible to use the ICP funktion. Using only one period, the resolution gets better with lower Frequency. Using more than one period, the resolution is allways better than with the counting method. However the using the ICP function needs a littel more arithmetics and a time critical ISR at high frequencies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Using more than one period, the resolution is allways better than with the counting method.

Hmmmm--I'd have to think about that. If one were looking for max deviation from the nominal (such as monitoring mains frequency from a generator as in another recent thread), then of course ICP can process every period. [and mains is a very modest frequency so the ISR load is not great]

If one grabs the T1 counts every 1/10 or 1/100 or 1/64 or whatever seconds and enters the values into a circular buffer, every count over the entire period is accounted for. When the signals are several hundred kHz as with the given chip (without prescaling which would presumably also decrease resolution) the latest sample gives the instantaneous value and the total of all the samples gives a totally accurate result of the number of cycles over that 1 second (or similar) period.

But I have in my mind that the color detection is a somewhat static reading. I don't think the chip is really suitable for a "color scanner" or similar; it would just be too slow--the frequencies get quite low.

The actual frequency range is quite wide, right?, if you want to measure low levels--about 10Hz to 1MHz. I've done a few apps, one production and a couple "bench" testers, where I route the input signal both to ICP1 and T1. At low frequencies I set up for ICP1, and then switch to T1 when over 1kHz or so. If there are enough timers in the AVR model one could keep both running at low frequencies and only shut down the ICP when the interrupt burden is starting to overload the AVR's available CPU time.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Just wait till the blackout subsides?

Tried that and I still can't figure out how to do this ;)

/Henke

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

-- Configure timer1 to be clocked from the rising edge of T1. Generally this is control register B = 7. See the datasheet.
-- Configure timer0 or timer1 to give an interrupt every fraction of a second; maybe 1/10 or 1/16.
-- When you get the interrupt, grab the TCNT1 value then clear TCNT1. Multiply by the fraction; e.g., if every 1/16 second multiply TCNT1 by 16 into an unsigned long.
-- Display and repeat.

Once you get that going, accumulate all the values into a circular buffer that holds 1 seconds worth of values. Each second, total the values into an unsigned long. Display and repeat.

It's less than a 100 line program, plus the display code.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Will that work?

The frequency may change a lot in 1/16 seconds, can't I just check for a full cycle to happen?

/Henke

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The frequency may change a lot in 1/16 seconds

Not at 10Hz.
Quote:

can't I just check for a full cycle to happen?

Sure. When you are at 100kHz, what are you going to do with a fresh reading every 10 microseconds?

You can get a more manageable range of signals if you use the divider on the chip. Or you have to adapt to the frequency. Or manage overflows with ICP at /1 timer prescaler. Or you have to use the timer prescaler and lose some precision if you want to get all the way down to 10Hz.

I posted a full ICP program very recently. http://www.avrfreaks.net/index.p... but that was for mains frequency, looking for small deviations. You need a wide frequency range. If you divide down the frequency at the chip to make the max fit into one timer1 period, with or without a prescaler as needed, then that program will work.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Sure. When you are at 100kHz, what are you going to do with a fresh reading every 10 microseconds?

Trying to see when light changes etc, but I may have a stupid thought here but I'm new to counting frequency etc.

/Henke