AVR - Internal RC oscillator calibration alternatives

[rubidium]

This is a simple question, and I'm almost embarrassed to ask it - but I just want a second opinion: I have an application involving the ATmega328P, for which some measurements I'm making involve noting elapsed time between pairs of interrupts. In hindsight, I should have included a crystal instead of just relying on the internal 8 MHz RC oscillator, but I'll make that change in a subsequent version of the PCB. For now, I just want the few prototypes that I already have to work sensibly with the MCU just running off the internal RC.  Most of the discussion out there on AVR RC oscillator calibration centers on setting OSCCAL to  a better value than what was included in the so-called factory cal - which, to my dismay, apparently has a +/-10% tolerance for the 328P! My question is, given that I have the means to measure the RC oscillator frequency, wouldn't it be better to just make that measurement and define F_CPU to be that value in my code? Again, I only need to do this a few times in order to facilitate more detailed lab testing of my initial prototypes. I understand, of course, that the RC is both temperature and Vcc dependent, but I'll live with that for now in favor of simply improving on the lame factory cal. Next time, I'll just add the external crystal and bypass caps.

Thanks,
Jim

[WattsThat]

It all depends on what your code does. If you have no time based functions, who cares about clock frequency? If you do care, why would you want every chip to have different code?

In other words, if time matters to your code, you have two choices.

1) Adjust OSCCAL for each chip, use one program image.
2) Adjust F_CPU and have x number of chip program images.

I know which one I would choose.

[rubidium]

As I mentioned previously, at this point I only have 3 prototypes, so method 2) is not really an inconvenience and it is more direct: measure once and then set F_CPU. Setting OSCCAL is essentially a more iterative trial and error process: set, measure, set again, measure again, ... I asked the original question about simply setting F_CPU to get some feedback just in case I was missing something.

[magic]

I suppose it can be done. Of course it will do nothing about output frequencies from peripherals (PWM/SPI/...) being inexact.

[cv007]

>wouldn't it be better to just make that measurement and define F_CPU to be that value in my code?

Yes, just change F_CPU to match the board. Take a marker and mark the freq on the board, change F_CPU when compiling for each. Also assuming you are using F_CPU in all calculations dependent on cpu speed. You may want to check what the F_CPU dependent peripherals end up as (for example you may want to check baud rate error if using uart, and adjust to get an acceptable error if needed).

No different than if you had 3 different crystals, in which you would also adjust F_CPU for each.