analogRead() take 30µs, 60µs, 90µs or 120µs randomly in bare example

Hi,

i've some trouble with the analogRead() on my Nano BLE 33:

unsigned int s0act  = 0;
unsigned long microTest = 0;

void setup() {
  pinMode(14, INPUT);
  Serial.begin(115200);
}

void loop() {
    microTest = micros();
    s0act  = analogRead(14);
    Serial.println(micros()-microTest);
}

The microseconds between the analogRead() is approx. 30, 60, 90 or 120µs... But this is completely random and i don't understand this. It should usually take 30µs!

Btw: I recognized this problem by reading all registers of an MPU6050 IMU, too. Sometimes, the reading take 1ms longer.

So what is the problem with this BLE 33 board? There is so much trouble... :frowning:

Thanks,
Klaus

Unbenannt.JPG

Unbenannt.JPG

Put a delay(1000) at the end of loop(). Your code might become blocking if you print too much in too little time.

I'm not familiar with the Nano BLE, so above might not be applicable, but it's worth a try.

Thanks, i put a delay(100) at the end of the loop . This is not solving the problem, but it exposes the problem a bit more. There is still a duration of 30µs (normal) and 60µs - but this time with a pattern - see appendix: There is a chart with the 100ms delay. And one chart without a delay (like in the beginning of this thread).

So there is a pattern, which appears every 25s. This is very strange!

remarkable update: I've deleted the analogRead(), replaced it with a simple integer allocation and added a delay(1)

unsigned int s0act  = 0;
unsigned long microTest = 0;

void setup() {
  pinMode(14, INPUT);
  Serial.begin(115200);
}

void loop() {
    microTest = micros();
    s0act  = 1234;
    Serial.println(micros()-microTest);
    delay(1);
}

And a 25 second pattern appeared again :o

If I had to guess, there's one of the other features on the BLE interrupting. Maybe you can turn bluetooth off?

The Nano 33 BLE runs ARM mbed os, a real-time operating system. It's possible that some other periodic task is interrupting your main loop. I would hope that there are not too many of such tasks running in such a simple program, though. If it's not a second task, it could be timer interrupts or interrupts from the USB stack, for example.

Another cause may be the micros() function itself. You'd have to look at its implementation, but it might have a lower resolution than on some other Arduino boards. Instead of printing the result of micros(), try pulsing an output pin and look at the period on an oscilloscope.

Pieter

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.