How do i make the Delay for the separate pins independent ?

Projects Programming
1

i want to Write 1 +number to set led blink to something and then be able to write 2 + number to set buzzer.
and that kinda works except that the delay in the loops affect each other they are in serial. how can i make the blink and buzzer move independantly?

const int led = 13;
const int buzzer = 3;

int tid;
int lyd;

void setup(){
  pinMode(led, OUTPUT);
  pinMode(buzzer, OUTPUT);
  Serial.begin(9600);
}

void loop(){
  
   if (Serial.available()> 0) {
     int valg = Serial.parseInt();
     valg = constrain(valg, 1, 2);
     if(valg == 1){
       tid = Serial.parseInt();
       //Serial.println(tid);
     }
     if(valg == 2){
     lyd = Serial.parseInt();
     //Serial.println(lyd);
     }

     }
   
   if(tid > 0){
   digitalWrite(led, 0);
     delay(tid);
   digitalWrite(led, 1);
     delay(tid);
     Serial.print("Tid ");
     Serial.println(tid);
   }
   if(lyd > 0){
   digitalWrite(buzzer, 0);
     delay(lyd);
   digitalWrite(buzzer, 1);
     delay(lyd);
     Serial.print("Lyd ");
     Serial.println(lyd);
   } 
}
2

how can i make the blink and buzzer move independantly?

delay() is a blocking function. NOTHING happens while delay() is doing its thing. So, don't use delay.

Look at the blink without delay example, and use that as a guideline for how to rewrite (NOT modify) your existing program.

3

There's the blink without delay example in the IDE, but you'll need to do this int valg = Serial.parseInt(); explicitly.

4

but you'll need to do this ... explicitly.

Hmmm. That was a little too subtle for me.

5

parseInt blocks and has a timeout, which could bugger-up your flashing/buzzing.

6

AWOL:
parseInt blocks and has a timeout, which could bugger-up your flashing/buzzing.

Of course. I get it now. I'm off to have some tea and wake up.

7

More full/complete explanation of blocking and how to get past it, with code:

More of that showing ways to read in text including numbers without blocking:

8

except for the Serial read, should i change these to something else ?

long tid;
long lyd;

Full new code without the serial remake, i need to read some more on that before implementing.

const int led = 13;
const int buzzer = 3;

long tid;
long lyd;

unsigned long cledmillis = millis();
unsigned long cbuzzermillis = millis();
  
void setup(){
  pinMode(led, OUTPUT);
  pinMode(buzzer, OUTPUT);
  Serial.begin(9600);
  cledmillis = millis();
  cbuzzermillis = millis();
}
void toggleled(){
  if(digitalRead (led) == LOW)
  digitalWrite(led, HIGH);
  else
  digitalWrite(led, LOW);
  
  cledmillis = millis();
  
}
void togglebuzzer(){
  if(digitalRead(buzzer) == LOW)
  digitalWrite(buzzer, HIGH);
  else
  digitalWrite(buzzer, LOW);
  
  cbuzzermillis = millis();
  
}

void loop(){
  
   if (Serial.available()> 0) {
     int valg = Serial.parseInt();
     valg = constrain(valg, 1, 2);
     if(valg == 1){
       tid = Serial.parseInt();
       //Serial.println(tid);
     }
     if(valg == 2){
       lyd = Serial.parseInt();
     //Serial.println(lyd);
     }

     }
     if((millis() - cledmillis) >= tid)
     toggleled ();
     
     if((millis() - cbuzzermillis) >= lyd)
     togglebuzzer ();
    
}
9

Serial.parseInt makes the controller wait until it has read a whole entry. Nothing else, including your leds blinking on time, happens then.

Granted that since you check for available first then that time is short to you or me, to Arduino there's time to do a few things between each and every serial character arriving.

It's a case of mind over matter. If you don't mind then it don't matter. However if you ever do mind and it does matter then knowing what blocking is and how to write code that doesn't block will really come in handy. Just in practice you should have different base codes which you can easily add to, especially if the base code is state machine friendly.

What is taught in PC code classes starts with the top-down/start-to-finish-by-steps approach that most people never get past. Controllers can do that begin-middle-end thing and loop to do it over and over but it gets klunky when used to respond to uncontrolled real world events. You then need a different approach that allows multiple tasks to run together on one processor. That sounds like a heck of a trick, don't it?

You can only run 1 instruction at a time on the processor. But you can cut your tasks into small fast running pieces and run a piece of one task in one go-round of loop() and a piece of another task in the next. Some tasks will be so short they only have one piece; like something that checks a pin, sees if the state has changed and sets a flag (and maybe saves the time) for another task to see. Often the short ones need to run often for the whole project to be smoothly responsive. By having your basic checklist run as a series of operations interleaved with what other inputs and outputs you want, you can make your checklist real time responsive which is great when you want to add a pause button, for instance.

Those 2 links I gave to the Nick Gammon blogs will get you started in a very good and definite way. It's all typed up, checked and ready better than what you'll get in most forum threads, honest! I point to the highway, not back streets and windy lanes.