Code slowed down and/or crashed

Hi!
I have one Arduino Uno (receiver) and one Arduino Nano (Transmitter) that are speaking with eachother over a 433MHz connection (one way).
However now it seems the code is crashing, and I don't know why ( the transmitter end). The crash is in the setup function (see image). I tried commenting out the closest piece of code with no difference.

Also I'm having trouble on the reciever end aswell. The reciever, with the same code as now, was able to recieve data before ( and probably still is) but it seems that it's slowed down somehow. When I had the value of millis() printed ever 1000ms I noticed that it was roughly 3-5s (varying) for each 1000ms.

I don't get any errors at all on either of the codes, and don't know what to do...

Heres my code: Dropbox - Public - Simplify your life

Heres my code

That's not where it belongs. Use the Additional Options link to attach your code.

Sorry, I havent noticed those options before.

DataReciever.ino (1.24 KB)

FlightController.ino (1.44 KB)

Okay, problem one (crashing) solved.

Very embarrasing: Due to the close proximity of 5V and RST on the Nano, I accidently connected 5V on the sensor to RST causing it to reset on power up.

The other problem still stands though.

When I had the value of millis() printed ever 1000ms I noticed that it was roughly 3-5s (varying) for each 1000ms.

Printed on the transmitter or the receiver? Printed where in the code?

It seems I attached the wrong code, and can’t find that copy.

But I’m still having the same problem, now with a different sketch using an LCD. I update the LCD every 500ms, but it’s updating about every 2-3 seconds, and when it does it’s slow. Usually I don’t notice the updating, except to the change in characters, but now it’s writing each character so slow it takes between 1-2 seconds to write the entire screen! (It’s a LCD screen from ebay 2x16 characters). This happens on both USB and battery power.

Could this be something wrong with the arduino? I have been using this same screen before without having problems with it, I had this “slow down” problem before I added the screen.

DataReciever.ino (2.7 KB)

You've got different bits of code updating different bits of the screen. Which of these parts is lagging?

Most of the updates seem to be prompted by serial input. Are you sure that the serial data is being sent when you expect? Are you sure that all the sent data is being received?

You're using the String class in various places for formatting. I suggest you stop doing that.

Are you sure that the serial data is being sent when you expect? Are you sure that all the sent data is being received?

Well it’s not the updating of the numbers that is slow, but the writing of the to the screen. It’s like you can se each character being added to the screen, as if someone was typing them on a keyboard. The part that is visibly lagging is:

if (refresh < millis()){
    lcd.clear();
    lcd.setCursor(0,0);
    lcd.print("Mx:" + String(maxAltitude));
    lcd.setCursor(8,0);
    lcd.print("Alt:" + String(currentAltitude));
    lcd.setCursor(0,1);
    lcd.print("Top speed: " + String(topSpeed));
    refresh = millis() + 500;
  }

From what I can see, the screen goes blank instantly when clear() is called, but the characters on the screen does not appear right away, more like one by one over 2-3 seconds.
Also, the entire code seems to be slowed, because I want the screen to update every 500ms, but if I check it with my watch it’s more like once every 2-3 seconds.
In a previous version (which is seem to have overwritten) I had this code instead of the LCD:

if ( millis() > lastMsg){
    digitalWrite(redLed, LOW);
    Serial.println(millis());
    lastMsg = millis() + 500;
  }

This part printed something along the lines of (2, 504, 1008, 1504, etc…) but the times were not printed each half second, but ever 2-3 seconds.

You’re using the String class in various places for formatting. I suggest you stop doing that.

The problem was there in previous versions before I used String, but I will take the advice and remove those part anyway.

(deleted)

Kalveo:
The problem was there in previous versions before I used String, but I will take the advice and remove those part anyway.

I have not downloaded your sketch file but this snippet (off the top of my head) may prove useful to you.

//a simple screen buffer
char lcdLine0[16] = "                ";  //a string of 16 spaces
char lcdLine1[16] = "                ";  //a string of 16 spaces

//decouples result updates, which are fast
void updateScreenBuffer(void) {
  sprintf(lcdLine0, "MX:%03u Alt:%03u ", maxAltitude, currentAltitude);
  sprintf(lcdLine1, "Top Speed:  %03u ", topSpeed);
}
  
//from the display device, which is slow
void displayScreenBuffer(void) {
  lcd.SetCursor(0, 0);
  lcd.print(lcdLine0);
  lcd.SetCursor(0, 1);
  lcd.print(lcdLine1);
}

Then when you come to fault finding

uint32_t profileDuration = 0;
uint32_t profileStart = microseconds();
displayScreenBuffer();
profileDuration = microseconds() - profileStart;    //decouple the result from the display

Serial.print("lcdUpdate =");
Serial.println(profileDuration);

And yes, a faulty or incorrectly wired LCD could cause the lethargic behaviour you are seeing.