attachInterrupt() + LCD = weird characters

Projects Programming
1

I'm trying to grasp the basics of the interrupt feature.

The idea::
I want to display a time counter on the LCD that represents the time between interrupts.
I have two buttons, A and B. I attach an interrupt to A.
When the program first runs, it counts starting at 0 until I press button A (interrupt). Pressing button A prints a message ("registered an interrupt") on the LCD. The message stays there until I press button B.
After I press B, I am back in loop() counting starting from 0 again, and so on.

The problem::
When I press button B to go back to the code, after the 2nd or 3rd time around, I get very weird symbols printing on the LCD. These never clear out. I have to re-upload the program to start over in order to get normal looking text.

An picture of just one instance of weird output(different every time):

1409×780 237 KB

far I have this code:

#include <LiquidCrystal.h>

LiquidCrystal lcd(12, 11, 10, 7, 6, 5, 4);

int A = 2;
int B = 8;
int backLight = 13;

//-----------------------------------------------------------------
void setup() {
  pinMode (backLight, OUTPUT);
  digitalWrite(backLight, HIGH);

  pinMode (A, INPUT);
  pinMode (B, INPUT);

  attachInterrupt(digitalPinToInterrupt(A), interrupt, RISING);

  lcd.begin (16, 2); //initiate 16x2
}//end setup()


//-----------------------------------------------------------------
void loop()
{
   lcd.setCursor(0, 0);
  lcd.print("I been waiting");
  lcd.setCursor(0, 1);
  lcd.print("for ");
  lcd.print(millis() / 1000);   //display current program run time - all accumulated lapse times;
  lcd.print(" seconds");
}//end loop()


void interrupt()
{
  
      lcd.clear();
    lcd.setCursor(2, 0);
    lcd.print("Press button");
    lcd.setCursor(2, 1);
    lcd.print("B to resume");

    
     while (!digitalRead(B))
    {
      //wait for user to continue with button B
    } 
    
     lcd.clear();
}

I know the timer isn't correctly resetting to 0, I'm more focused on finding out why I can't get normal output.
If I leave loop() empty, the LCD transitions from a blank screen to the interrupt's text without a problem

2

Interrupts are supposed to be fast. There is nothing fast about your interrupt handler.

If you want to time how long between two interrupts, you do NOT do that by spinning your wheels in an interrupt handler. Frankly, I don't think you need interrupts at all.

3

I have a working version of this program without using interrupts, but an interrupt makes much more sense.

Why does an interrupt need to be fast?

I just want it to, maybe, set the 'timer' to 0 and wait for a signal (B) to leave the interrupt

4

filflops:
Why does an interrupt need to be fast?

I just want it to, maybe, set the 'timer' to 0 and wait for a signal (B) to leave the interrupt

because during an ISR, a lot doesn't happen like the advancing of millis() for example.

use the interrupt to set a flag and respond to that flag in the loop() function

untested:

#include <LiquidCrystal.h>

LiquidCrystal lcd(12, 11, 10, 7, 6, 5, 4);

int A = 2;
int B = 8;
int backLight = 13;
volatile bool interruptFlag = false;

void setup() 
{
  pinMode (backLight, OUTPUT);
  digitalWrite(backLight, HIGH);
  pinMode (A, INPUT);
  pinMode (B, INPUT);
  attachInterrupt(digitalPinToInterrupt(A), interrupt, RISING);
  lcd.begin (16, 2); 
}

void loop()
{
  static unsigned long mytimer = 0;
  if (millis() - myTimer >= 1000UL;
  {
    lcd.setCursor(0, 0);
    lcd.print("I been waiting");
    lcd.setCursor(0, 1);
    lcd.print("for ");
    lcd.print(millis() / 1000);   //display current program run time - all accumulated lapse times;
    lcd.print(" seconds");
    myTimer += 1000UL;
  }
  if (interruptFlag)
  {
    lcd.clear();
    lcd.setCursor(2, 0);
    lcd.print("Press button");
    lcd.setCursor(2, 1);
    lcd.print("B to resume");
    while (!digitalRead(B))
    {
      //wait here
    }
    lcd.clear();
    interruptFlag = false;
  }
}

void interrupt()
{
  interruptFlag = true;
}
5

Aside from that, you CAN'T write to a device like an LCD, Serial, etc. both in the foreground task and the interrupt handler. That is pretty much guaranteed to cause problems.

Regards,
Ray L.