Testing internal RC oscillator frequency

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

Hi,

I am running some application on my ATmega16 on 8 MHz internal RC oscillator.

Just to be sure that the clock frequency is right I wrote a test program to toggle an LED at 1 Hz or once every second as shown below:

#include 

int main (void) {
	
	OSCCAL = 0xBF;	//Internal RC oscilator running @ 8 MHz

	//set PORTA as output
	DDRA = 0xFF;
	
	TCCR1B |= (1 << CS12);
	while(1) {
		if(TCNT1 >= 31250) {
			PORTA ^= _BV(4);	//Toggle LED @ 1 Hz or once every second
			TCNT1 = 0;	// Reset timer
		}
	}
	return 0;
}

The LED turns ON and OFF every second. I just want to know if this is the right way to test the internal RC oscillator frequency for the clock or is there any other way to do this.

In my AVR studio i set the internal RC ocillator frequency settings as shown in the attached files. Is this correct? I read the value of the calibrated frequency for 8 MHz and then set that value in my main code as OSCCAL = 0xBF;

Is this correct?

Thanks,
Sumair

Attachment(s): 

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

Quote:

Is this correct?

What you are doing looks correct to me. You might also want to explore CTC timer interrupts with OCR1A=31249 as this will likely give you an even more accurate "tick" (well as accurate as the internal RC can ever be) because there is no delay between the register being compared to the target value and it then being reset to 0. In your own code there will be a few opcodes between the test and the reset:

      if(TCNT1 >= 31250) { 
         PORTA ^= _BV(4);   //Toggle LED @ 1 Hz or once every second 
         TCNT1 = 0;   // Reset timer 

While you can use LED flashing and the sweep second hand on your stopwatch to try and profile the timing of the AVR your best bet is to find an oscilloscope or frequency meter and measure the timing of a toggled pin more accurately as the error (after using the factory calibration byte 0xBF) is likely no more than a few percent and you won't really be able to pick this up with a flash of an LED

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

Hi Clawson,

Thanks for your reply. I have ordered for my Zeroplus logic analyzer (LAP-C 16032)and am waiting for its shipment. Once i get it i'll use it to measure the signal on the toggle pin. Until then I thought i'll resort to this method to verify my internal RC oscillator frequency. I'll try out the CTC timer interrupt method too.

Thanks,
Sumair

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

You can also use input capture with a second micro with crystal system clock to measure the test unit's CTC signal.

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

If you really want to know the accuracy right now, I'd suggest using the age old measurement trick of averaging over multiple flashes. Assuming a constant offset in the RC frequency (which I think is a reasonable assumption if the system has been running for a while (steady-state), so there's no internal temperature changes, and no external temperature or voltage changes during the test), you want to measure the time it takes for it to flash a lot of times - 100 would be decent, 1000 would be good (but takes a _lot_ of time). Then just divide the time by the number of flashes, and you've got far better accuracy than you'll ever achieve with hand-timing just one flash.

One could argue that hand-timing will suffer from some intrinsic errors due to reaction times. But over a lot of samples it'll average itself out, and it should be approximately the same time at the start and the end, thus mostly eliminating itself.

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

ssyed_mcu wrote:
Hi,

I am running some application on my ATmega16 on 8 MHz internal RC oscillator.

The LED turns ON and OFF every second. I just want to know if this is the right way to test the internal RC oscillator frequency for the clock or is there any other way to do this.


If you are using the UART, that checks your oscillator. If you haven't got it right, the serial bit rate is wrong, and communication fails.

If you have another calibrated device with a variable frequency UART that you can use to connect, for example another ATmget16, then you can use the serial connection to calibrate, and then export the OSCCAL value.