RPi Pico: delay() has poor accuracy

[harryjph]

Take the following code on a Raspberry Pi Pico:

#include <Arduino.h>

void setup() {
    pinMode(16, OUTPUT);
    Serial.begin(115200);
}

void delayMeasure() {
    auto startU = micros();
    auto startM = millis();
    delay(1000);
    char buf[64];
    sprintf(buf, "m: %d\tu: %d\r\n", millis() - startM, micros() - startU);
    Serial.print(buf);
}

void loop() {
    digitalWrite(16, HIGH);
    delayMeasure();
    digitalWrite(16, LOW);
    delayMeasure();
}

You get the following serial output:

m: 960	u: 959933
m: 960	u: 959931
m: 960	u: 959931
m: 960	u: 959932
m: 960	u: 959930
m: 960	u: 959932

And the following can be observed on pin 16:

This shows that the micros()/millis() readings are accurate, and that the problem lies with the delay function, not with the timing.

It seems that asking for a delay of 1000 produces a delay of 960. I also checked delay(500), which produces a delay of 480ms. So it seems to be a linear inaccuracy.

I have tried this with core versions 2.1.0 and 2.2.0.

[fjansson]

I've seen the same behavior - delay is too short, while micros() and millis() are accurate.

Long-shot guess: The first post in this pull request ARMmbed/mbed-os#14488 lists the Pico's system clock as 120 MHz. But the frequency is actually 125 MHz (seen by querying the clock frequency using the Pico SDK). If the delay function is written assuming 120 MHz, it would produce too short delays by exactly the observed ratio.

[facchinm]

@fjansson you are WONDERFULLY right! Thank you so much for spotting this! I'm preparing the patch and it will be included in the next core release.