Serial Monitor "Lag"

Projects Programming
1

I have been messing around with some intensive debugging with my Arduino scripts and I have noticed something odd: after running for some time, the simulated USB-HID inputs from my pro micro start to lag behind the actual trigger for the inputs. I have also noticed this when using a Python library called Pyserial, and whenever I try to read serial monitor data and print/store it, my code begins to lag badly (which is not good when you are trying to log multiple inputs in real time!). If I don't store/read the serial data, the scripts seem to run indefinitely without a hitch.

Here is the code I have been using on a Pro Micro board:

/* Tilt Control - King Dub Dub, 11/15/19

A tilt-controller script for USB-HID enabled Arduino boards with the MPU-6050 sensor.
Tilt to control the WASD controls and spacebar (I lied about the W :D).
There is an additional fail-safe that keeps any keyboard data from being printed
if pin 9 isn't grounded. Ground pin 9 with a switch/button when you want to send
keyboard inputs.

VCC to 5V
GND to GND
SCL to A5 or SCL
SDA to A4 or SDA
ADO to GND
Pin 9 to button/switch to ground

*/

#include<Wire.h>
#include<Keyboard.h>

const int MPU_addr=0x68;
int16_t AcX,AcY,AcZ,Tmp,GyX,GyY,GyZ; //sets up the accelerometer XYZ's, temperature, and gyro XYZ's
int minVal=265;
int maxVal=402;
double x,y,z;

void setup(){
  Wire.begin();
  Wire.beginTransmission(MPU_addr);
  Wire.write(0x6B);
  Wire.write(0);
  Wire.endTransmission(true);
  Serial.begin(9600);

  pinMode(9, INPUT_PULLUP); //pin 9 is a fail-safe switch
  Keyboard.begin();
}

void loop(){
  Wire.beginTransmission(MPU_addr);
  Wire.write(0x3B); Wire.endTransmission(false);
  Wire.requestFrom(MPU_addr,14,true);
  AcX=Wire.read()<<8|Wire.read();
  AcY=Wire.read()<<8|Wire.read();
  AcZ=Wire.read()<<8|Wire.read();

  int xAng = map(AcX,minVal,maxVal,-90,90);
  int yAng = map(AcY,minVal,maxVal,-90,90);
  int zAng = map(AcZ,minVal,maxVal,-90,90);

  x= RAD_TO_DEG * (atan2(-yAng, -zAng)+PI);
  y= RAD_TO_DEG * (atan2(-xAng, -zAng)+PI);
  z= RAD_TO_DEG * (atan2(-yAng, -xAng)+PI);

  Serial.print("X= "); Serial.print(x);    //print the X value
  Serial.print(" Y= "); Serial.print(y);   //print the Y value
  Serial.print(" Z= "); Serial.print(z);   //print the Z value
  Serial.print("\n");                      //prints a new line

    if ((y >=110) and (digitalRead(9) == LOW)){
      Keyboard.press('a'); //if tilted left, "press" the [a] key
    } else {
      Keyboard.release('a'); //else, stop "pressing"  the [a] key
    }
    if ((z <=345) and (z>=180) and (digitalRead(9) == LOW)){ //if tilted down:
      Keyboard.press('s');
      delay(10);
    } else {
      Keyboard.release('s');
    }
    if ((y<=70) and (digitalRead(9) == LOW)){ //if tilted right:
      Keyboard.press('d');
      delay(10);
    } else {
      Keyboard.release('d');
    }
    if ((z >= 10) and (z<=179) and (digitalRead(9) == LOW)){ //if tilted up:
      Keyboard.press(' ');
      delay(10);
    } else {
      Keyboard.release(' ');
    }
}

I have also noticed this with scripts on my UNO board, so it is not a problem with the Micro.

2 
Serial.begin(9600);

Why so slow?

3

Just out of habit, also I didn't think I needed something too fast for my debugging. Is this the entire reason? I though I would need to send a clear output command from the Arduino board, but I couldn't find any relevant posts.

4

That line causes serial communication to happen at 9600 bits per second. With a standard setup, you can easily set the baud rate to a much higher value. 9600 is commonly used, but certainly much slower than necessary. It makes sense because 9600 is the default speed setting of the Serial Monitor, and it's a very common source of confusion to beginners when they are trying to use a sketch that uses a different baud rate without realizing that they also need to change the speed in the Serial Monitor's menu. As to the origin of 9600 in the Arduino world, perhaps with the original hardware higher baud rates were not as reliable.

5

Well, not on a pro-micro (with 32u4 and direct usb.)
There, “serial.print()” will always go really fast. Fast enough that you may need to throttle them so that the display can keep up.

6

Oops, I missed that they were using the Pro Micro. Disregard my previous reply KingDubDub.

7

Oh no, pert. I love useless information like that! Could also explain why I have problems on other boards; I used a pro-micro for this code, but I have used an UNO for some other data-logging. I'll just speed up the baud-rate and see if that eliminates any more timing errors and lag and such.