Digital Analog pin code not working without print statement

[mrstepbro]

Screenshot 2024-12-26 204604|442x500
The code in the screenshot only works with the serial print statement that outputs the value the A5 pin reads back every iteration of the loop (I have it commented out on the screenshot), without it nothing shows up on the serial monitor, and the if statements never get read, with it my serial monitor is rapidly blasted with unwanted information, but the code runs. Why would this be? How can a serial print statement make or break my code? Is there any way I can fix it without having the print statement?

Thanks in advance for the assistance!

[mrstepbro]

unsigned long split1 = 0;  //time when beam is broken
unsigned long split2 = 0;  //time when beam is broken again
int LapTimeSeconds;        //Seconds of time
int RemainingTime;         //remaining time that is smaller than seconds
int analog_read_value = 0; 

void setup() {
  Serial.begin(9600);  //bandwith
  pinMode(A5, INPUT);   //set pin 2 to input
}

void loop() {
  analog_read_value = analogRead(A5);
  //Serial.println(analog_read_value); 
  //checks for the beam to be broken then puts it as either split 1 or split 2  
  if (analog_read_value > 1) 
  {
    if (split1 == 0) 
    {
      split1 = millis();
    } 
    else if(split1 > 0 && millis() - split1 > 5000)
    {
      split2 = millis();
    }
  }

  //checks if both splits have been read
  if (split1 != 0 && split2 != 0) {
    //calculating lap splits and converting them to seconds.
    LapTimeSeconds = (split2 - split1) / 1000;
    RemainingTime = ((split2 - split1) % 1000);

    //printing out lap values.
    Serial.print("Lap Time: ");
    Serial.print(LapTimeSeconds);
    Serial.print(".");
    Serial.println(RemainingTime);

    //resetting split1 and split2 so the if statements work.
    split1 = 0;
    split2 = 0;
  }
}

Here is a comment version of the code so you can copy paste it, in case anyone wants to try it for themselves.

[alto777]

I can't your code just now, but one thing that printing at 9600 baud will do as a side effect is introduce a short delay in processing.

Just as an experiment, try replacing that commented out print with

   delay(15);

Alternatively, try bumping up the baud rate to not-your-grandfathers, like 500000, and see if the sketch fails even with the printing.

Say what happens.

a7

[mrstepbro]

@alto777 Thank you so much for the help! The 15 ms delay helped and made the code work! The baud change didn't. If you wouldn't mind, can you explain why that delay made the code work?

[alto777]

@mrstepbro

f you wouldn't mind, can you explain why that delay made the code work?

I'd love to, but just now I have had too much of one thing and not enough of another.

This thing has come by before, it can be a real mystery hence I learned the trick to test the theory.

L8R

a7

[alto777]

Your sketch has problems that go beyond any that might have been lessened by the insertion of a delay at the point where you formerly were printing for a few milliseconds.

I am in transit now.

Where is the signal on A5 coming from? Also, if you are just comparing to 1, it seems like this could be a digitally read signal. I'm not just curious - the nature of the signal will inform the code for handling it.

But, without knowing more...

You need to react not to the fact that the signal is present, rather to the fact the the signal changed from absent to present.

This is generally called "state change detection" or "edge detection".

Here are two threads that may help; there's an example on offer in the IDE which has a competent article that accompanies it.

Storing Button State

I have written a simple piece of code to turn a white LED on if the button is pressed. I would like the button state to be remembered so the LED doesn't turn off till the button is pressed again. For some reason, this doesn't work and I'm not sure where I've gone wrong: int whiteledPin = 8; int buttonPin = 4; int lastState = digitalRead(4); void setup() { Serial.begin(9600); pinMode(buttonPin, INPUT_PULLUP); pinMode(whiteledPin, OUTPUT); } void loop() { int currState = digitalRead(bu…

and this rehashes it. It is always good to get multiple perspectives.

Making a LED switch but it's a bit more complex

I think the state change detection as typically presented is harder to understand, or at least it is easier once a few things get learnt. After the check for a change in the input, if there is one we can deduce that a pressed button must just have become pressed, and similarly an unpressed button must just have been released. But we use the state as proxy for those events. Properly, from a logic point of view, but confusing. Borrowing from some code I saw that handled multiple inputs and reca…

The other issue that can come up in signal handling, particularly buttons, is the unfortunate reality that for a brief time around any transition between HIGH and LOW, there will be appearances of the opposite value.

This is referred to as "contact bounce", and button/switch debouncing, or signal de-glitching is a hole thing in itself.

A cheap trick to avoid the issue is to have one delay call as the last line of code in your loop. 20 milliseconds slows the loop down so much that the contact bounce is never seen.

void loop() {


// whatever


  delay(20);  // poor man's debounce
}

If you can afford to throttle the loop in this manner, it is an easy miracle worked.

When you can't afford that luxury, there are many ways to debounce a pushbutton, look forward to learning about that.

HTH

a7