two 16 MHz Arduinos run same code at different speed?

I have this same code shown below running on two different 5V 16MHz Arduinos, connected to two different Windows XP boxes. I expect them to run at the same rate, but they don't. Based on the scope looking at the serial port TX pin, the original Arduino Duemilanove has a loop time of 1.62 msec, and an equivalent board (a breadboard with ATmega328P and 16 MHz crystal) runs about 20% faster, with a loop time of 1.23 msec. Same code, both compiled with Arduino 0022, although the faster one was a fresh install just today and the slower one was from an older installation of the Arduino IDE. Is there a new version of something underneath, eg. avr-g++ that generates faster code?

const int analogInPin = A0;  // Analog input AIN0: pin 23 on the Atmel ATmega328P in DIP-28 package

int sensorValue = 0;        // analog value read from the input pin (10-bit ADC: 0..1023)

void setup() {
  // initialize serial communications module in CPU and set data rate
  Serial.begin(115200); 
}

void loop() {
  // read the analog in value:
  sensorValue = analogRead(analogInPin);            

  // send out sensor value to serial port
  Serial.println(sensorValue);      

  // wait some number of microseconds
  delayMicroseconds(1000);                     
}

If your breadboard version using the same FTDI USB serial convertor chip as your arduino board?

Lefty

  1. Is the binary sketch size reported when compiling the same for the two?
  2. Are the leads on the crystal and load capacitors short?
  3. Do the load capacitors match the crystal? Load capacitance as specified on the crystal's datasheet is not the value for the load capacitors.
  4. Run the Blink sketch, does the LED keep in sync with the second hand on a clock or watch? If there's a 20% error in the clock speed, it will get out of sync quickly. Alternatively, just run Blink on both.

Do they both set up Serial at 115200?

Are they reading the same thing through identical sensors? analogRead can take a significant period compared to most other code. For all I know, the time may vary by how long an RC pair takes to fill.

Oh no, there's more than that, there's -always- more than that!

The ADC converts an analog input voltage to a 10-bit digital value through successive approximation.

So it gets done when it gets done?

A normal conversion takes 13 ADC clock cycles. The first conversion after the ADC is switched
on (ADEN in ADCSRA is set) takes 25 ADC clock cycles in order to initialize the analog circuitry.
When the bandgap reference voltage is used as input to the ADC, it will take a certain time for
the voltage to stabilize. If not stabilized, the first value read after the first conversion may be
wrong.
The actual sample-and-hold takes place 1.5 ADC clock cycles after the start of a normal conversion
and 13.5 ADC clock cycles after the start of an first conversion. When a conversion is
complete, the result is written to the ADC Data Registers, and ADIF is set. In Single Conversion
mode, ADSC is cleared simultaneously. The software may then set ADSC again, and a new
conversion will be initiated on the first rising ADC clock edge.

Possibly how you wire your sensors up and the sensors themselves will factor in?

How many measurements have you made?

What has

What happens if you swap the boards (change their PC).

Keep in mind the serial is not a guaranteed delivery method. It is possible one PC is accepting bytes sooner than the other.

For what it's worth, I have two 328Ps sitting on a breadboard, same exact configuration, same exact parts, running the same exact code. Each have a "heartbeat" LED that flashes every ~2500ms. Over time they get out of sync. An EE engineer told me that one will never get two identical resonators, they're always off by a few hundrenths of MHz. Considering the stuff I'm doing isn't atomic clock critical, it doesn't bother me. I think if I incorporate an RTC, I'll get better time and syncing, but as I said, t'is not important here. For others it might though. :slight_smile:

You can run Timer/Counter2 with a watch crystal asynchronous of the CPU clock. What clock does millis() use?

9.5 Low Frequency Crystal Oscillator
The Low-frequency Crystal Oscillator is optimized for use with a 32.768kHz watch crystal.

Below it says the system clock needs to be 4x the T/C oscillator but in later text it say more than 4x.

9.10 Timer/Counter Oscillator
ATmega48A/PA/88A/PA/168A/PA/328/P uses the same crystal oscillator for Low-frequency
Oscillator and Timer/Counter Oscillator. See ”Low Frequency Crystal Oscillator” on page 33 for
details on the oscillator and crystal requirements.
ATmega48A/PA/88A/PA/168A/PA/328/P share the Timer/Counter Oscillator Pins (TOSC1 and
TOSC2) with XTAL1 and XTAL2. When using the Timer/Counter Oscillator, the system clock
needs to be four times the oscillator frequency. Due to this and the pin sharing, the Timer/Counter
Oscillator can only be used when the Calibrated Internal RC Oscillator is selected as system
clock source.
Applying an external clock source to TOSC1 can be done if EXTCLK in the ASSR Register is
written to logic one. See ”Asynchronous Operation of Timer/Counter2” on page 157 for further
description on selecting external clock as input instead of a 32.768kHz watch crystal.

18.9 Asynchronous Operation of Timer/Counter2
When Timer/Counter2 operates asynchronously, some considerations must be taken.
• Warning: When switching between asynchronous and synchronous clocking of
Timer/Counter2, the Timer Registers TCNT2, OCR2x, and TCCR2x might be corrupted. A safe
procedure for switching clock source is:
a. Disable the Timer/Counter2 interrupts by clearing OCIE2x and TOIE2.
b. Select clock source by setting AS2 as appropriate.
c. Write new values to TCNT2, OCR2x, and TCCR2x.
d. To switch to asynchronous operation: Wait for TCN2xUB, OCR2xUB, and TCR2xUB.
e. Clear the Timer/Counter2 Interrupt Flags.
f. Enable interrupts, if needed.
• The CPU main clock frequency must be more than four times the Oscillator frequency.

There are caveats about how long after reset or wake-up before the system is stable in ANY mode.

• When the asynchronous operation is selected, the 32.768kHz Oscillator for Timer/Counter2 is
always running, except in Power-down and Standby modes. After a Power-up Reset or wakeup
from Power-down or Standby mode, the user should be aware of the fact that this Oscillator
might take as long as one second to stabilize. The user is advised to wait for at least one
second before using Timer/Counter2 after power-up or wake-up from Power-down or Standby
mode. The contents of all Timer/Counter2 Registers must be considered lost after a wake-up
from Power-down or Standby mode due to unstable clock signal upon start-up, no matter
whether the Oscillator is in use or a clock signal is applied to the TOSC1 pin.

• Description of wake up from Power-save or ADC Noise Reduction mode when the timer is
clocked asynchronously: When the interrupt condition is met, the wake up process is started
on the following cycle of the timer clock, that is, the timer is always advanced by at least one
before the processor can read the counter value. After wake-up, the MCU is halted for four
cycles, it executes the interrupt routine, and resumes execution from the instruction following
SLEEP.

• Reading of the TCNT2 Register shortly after wake-up from Power-save may give an incorrect
result. Since TCNT2 is clocked on the asynchronous TOSC clock, reading TCNT2 must be
done through a register synchronized to the internal I/O clock domain. Synchronization takes
place for every rising TOSC1 edge. When waking up from Power-save mode, and the I/O clock
(clkI/O) again becomes active, TCNT2 will read as the previous value (before entering sleep)
until the next rising TOSC1 edge. The phase of the TOSC clock after waking up from Powersave
mode is essentially unpredictable, as it depends on the wake-up time. The recommended
procedure for reading TCNT2 is thus as follows:
a. Write any value to either of the registers OCR2x or TCCR2x.
b. Wait for the corresponding Update Busy Flag to be cleared.
c. Read TCNT2.

During asynchronous operation, the synchronization of the Interrupt Flags for the asynchronous
timer takes 3 processor cycles plus one timer cycle. The timer is therefore advanced by at least
one before the processor can read the timer value causing the setting of the Interrupt Flag. The
Output Compare pin is changed on the timer clock and is not synchronized to the processor
clock.

Question is, does that last part which I highlighted apply only to Wake Up or as it might be read, all the time when running C/T2 asynchronous? It makes sense to me that it's not just after wake up.

Arduinos will never be 100% in sync. I investigate this here: Crystal Deviations | Blinkenlight and here Crystal Deviations 2 | Blinkenlight. However deviations of ~20% would be more than surprising. So I would suspect something else. You state that they are connected to two different windows boxes. What happens if you exchange the Arduinos? In doubt I would suspect the Windows boxes and the USB Bus.

I think I found out the reason, or at least a reason. They were measuring different voltages, and so the serial port was sending a different number of characters (printing 52 is faster then printing 645, for example...)

You can now verify the reason: look at the timing without any such prints.
Why you should verify this: otherwise you will never really know :wink: