Does delay() block the process/operation/output data of MPU-6050 sensor?

Hello,

I am using an MPU-6050 sensor with my Arduino UNO R3 but to enable its DMP mode, i need to give it at least 10 seconds so it can start outputting stable data, so i was wondering if introducing a delay, like, delay(10000); into the setup() function will also block the processing of data within the sensor? The sensor is connected via I2C to the Arduino UNO, but since delay() is a blocking function, won't it also block how the sensor works, or is it only for the Arduino?

Yes.

Those are different devices, the MPU runs all the time and communicates to the Uno on I2C bus.

Uno sends a request and MPU sends a response all in codes.

IIRC the library you want is standard in-your-IDE-already Wire Library: Arduino - Wire

There's a whole linked manual on the Arduino main site.

GoForSmoke:
Yes.

I'm not sure to which part of my question you're responding. So, to confirm my understanding, the delay() function won't affect the operation of the I2C device itself, but it will block any and all incoming data to the UNO from the I2C device. Correct?

The delay only applies to the arduino code. As long as the arduino is "executing" the delay, it can not execute anything else at the same time.
If i understand your question corectly, you are asking if the delay will cause your sensor to stop functioning?
I am not familiar with youe sensor but i believe the delay in the arduino code will not affect the sensors functionallity

HellasT:
The delay only applies to the arduino code. As long as the arduino is "executing" the delay, it can not execute anything else at the same time.

I understand this part, but here is my problem:

When the sensor is first initialised by the Arduino UNO, the data received via I2C is not correct for the first 10s. The sensor will take about 10 seconds before it starts transmitting correct and useful data. So, my plan is to simply not allow the Arduino to receive this inaccurate/garbage data until the sensor stabilises 10s after it is first initialised in the setup() function of the Arduino code. My approach is to add a delay() function with 10000ms but i don't know if this will work or if there is a better approach...

Or maybe a second (better?) option would be to use millis() and set the loop to 10 seconds and after that the rest of the code can be executed?

Im away from home and use my cellphone so i cant really write a suggestion code.

The way i see iy now i think you would be better off using the millis() to start receiving after 10 seconds have elapsed.

If i had my comouter i would be able to write but since i can not i am sure others can.

But yes probably the millis() is better.

On the other hand a delay is not too bad to use... why dont you actually try with a delay and see how it goes ?

HellasT:
why dont you actually try with a delay and see how it goes ?

I tried but it's hard to know for sure if it's working or not, in the background, since the data is being processed continuously and the integral just sums all the errors since the very first data is obtained from the sensor. So, i can't say for sure if this is causing the stability issues with my robot. I'm trying to eliminate this as a source of error.

If you use serial.print to debug the code and see ?

Ahh i could be more helpfull from my pc. Sorry. If you can wait for about a week. Or someone else will probably asist you faster !

The I2C only works when you send a request to it. If you are in delay then you can’t issue a command to the I2C. The sensor can not use the I2C unless the Arduino is requesting data from it.

Grumpy_Mike:
The I2C only works when you send a request to it. If you are in delay then you can’t issue a command to the I2C. The sensor can not use the I2C unless the Arduino is requesting data from it.

void setup() {
  Serial.begin(9600);

  mpu.initialize();   //initialize I2C sensor

  mpu.setDMPEnabled(true);  // turn on the DMP in the sensor

  delay(10000);  //add 10s delay BUT this should not stop the MPU from processing data on its own???
  
  //the 10s delay is to wait for the incoming sensor data to stabilise.

  packetSize = mpu.dmpGetFIFOPacketSize();  //get stabilised DMP packet size for later comparison

}

This is my attempt and i just want to know if it would work without freezing the sensor as well, since delay() freezes the MCU.

Yes that will work.

DryRun:
I understand this part, but here is my problem:

When the sensor is first initialised by the Arduino UNO, the data received via I2C is not correct for the first 10s. The sensor will take about 10 seconds before it starts transmitting correct and useful data. So, my plan is to simply not allow the Arduino to receive this inaccurate/garbage data until the sensor stabilises 10s after it is first initialised in the setup() function of the Arduino code. My approach is to add a delay() function with 10000ms but i don’t know if this will work or if there is a better approach…

Or maybe a second (better?) option would be to use millis() and set the loop to 10 seconds and after that the rest of the code can be executed?

Inside of void loop() each function or block of structure can run on condition as a continuing task.

if ( micros() - accurateStart >= accurateWait )
{
// do after time is up
accurateStart += accurateWait; // restarts on cycle even if trigger is late
{

if ( accurateWait > 0 ) // some other task sets accurateWait to run this once
{
if ( micros() - accurateStart < accurateWait )
{
// do until time is up
}
else
{
accurateWait = 0; // end the 1-shot
}
{

Using event-driven tasks works as long as none of it blocks execution.

Here are some tutorials, only use the 3rd where you must and leave it for after you know the others.

  1. Gammon Forum : Electronics : Microprocessors : How to do multiple things at once ... like cook bacon and eggs ← tasking Arduino 1-2-3
  2. Gammon Forum : Electronics : Microprocessors : How to process incoming serial data without blocking ← techniques howto — be sure to get the State Machine example.
  3. Gammon Forum : Electronics : Microprocessors : Interrupts

How it works once you have overview:
Your sketch can sense ongoing process events in time. (save the time as ‘it’ happens, in time)
Your sketch can make events to control it over time. (set up timers, things happen over time)

Event: pin state change, variable value change, timeout, Serial available, etc.

Use variables to pass values between tasks, you need less structure depth than one do-everything spaghetti knot.

So did you figure it out ?

HellasT:
So did you figure it out ?

Thank you for asking. I have settled on using the delay() function even though it is a blocking function, but it doesn’t seem to affect the sensor operation.

But to be sure about what’s happening in the sensor while the delay() is working, i think i would need to parse the sensor data output through some graphing software to check the SDA/SCL data to be 100% sure that the sensor’s Digital Motion Processor (DMP) isn’t being prevented from doing its thing while the Arduino is blocked by the delay().

You won't be getting data to parse when the Arduino is too busy doing nothing for 16000 cycles per millisecond.

Non-blocking code salvages the losses, it can do 1000's of times more than blocking code in the same time.

DryRun:
Thank you for asking. I have settled on using the delay() function even though it is a blocking function, but it doesn't seem to affect the sensor operation.

But to be sure about what's happening in the sensor while the delay() is working, i think i would need to parse the sensor data output through some graphing software to check the SDA/SCL data to be 100% sure that the sensor's Digital Motion Processor (DMP) isn't being prevented from doing its thing while the Arduino is blocked by the delay().

Im pretty sure it works fine. The fact that you are not "asking" it to send you data through the I2C bus does not mean that it will not work properly.

think i would need to parse the sensor data output through some graphing software to check the SDA/SCL data to be 100% sure that the sensor's Digital Motion Processor (DMP) isn't being prevented from doing its thing while the Arduino is blocked by the

I thought we had been through that. An I2C device only responds when you ask it to. If you don’t ask then the data that gets produced is over written by the next bit. It is like you wanting to test a match by striking them to see if they work.