The Problem With delay()

     An issue that comes up over and over on Arduino forums supporting Arduinists trying to advance from beginner projects to building their own projects from what they have learned doing tutorials is the problem with delay(). The delay() function is introduced in blink, which is often the first lesson in beginner tutorials.  While the first lesson should be kept simple to keep from immediately confusing the audience, discussion of limitations of delay() are skipped for the same reason. This can lead to an intermediate micro-controller hobbyist attempting to perform some timing function in their project using delay, without ever digesting blink without delay (see also Multitasking the Arduino), leading to difficulties.

    The delay() function might as well be called do_nothing(), as when the controller reaches this instruction, it takes no further action until the specified time has elapsed. The behavior is referred to as 'blocking,' and is at the heart of the problem with delay(). The problem with delay() is that blocking behavior prevents code from being able to perform multiple tasks concurrently. 

 The following sketch illustrates the problem with delay in multiple ways.

/*
  This sketch is original work by the author of westwoodtoys.blogspot.com
  
  Permission is hereby granted, free of charge, to any person obtaining a copy
  of this software and associated documentation files.
  
  The above copyright notice and this permission notice shall be included in all
  copies or substantial portions of the Software.
*/
int leds[]={3,5,6,9,10,11};
int wait_time;
int speakerPin = 4;
void setup()
{
  for(int i=0;i<6;i++)
  {
    pinMode(leds[i],OUTPUT);
  }
  pinMode(A0,INPUT);
  pinMode(2,INPUT);
  pinMode(speakerPin,OUTPUT);
}
void play_sounds()
{
  for (int n=554; n>522; n--)
  {
    tone(speakerPin, n);
    delay(3);
  }
  tone(speakerPin, 523);
  delay(500);
  noTone(speakerPin);
  delay(500);
  for (int n=554; n>522; n--)
  {
    tone(speakerPin, n);
    delay(3);
  }
  tone(speakerPin, 523);
  delay(1500);
  noTone(speakerPin);     
}
void loop()
{
  for(int i=0;i<6;i++)
  {
    wait_time=5*analogRead(A0);
    digitalWrite(leds[i],HIGH);
    delay(wait_time);
    digitalWrite(leds[i],LOW);
    if(digitalRead(2))
    play_sounds();
  }
}

Here is a Tinkercad simulation.

The sketch takes input from a potentiometer wiper and button.  The potentiometer wiper position is used to set the time between switching from one LED illuminated to the next. The button causes the Arduino to play a tone on the buzzer that sounds a bit like a fire truck horn.  The problem with delay() is illustrated in that: 

1. While the horn sound plays, the change in LEDs is paused.
2. If the potentiometer is moved while one LED is illuminated, the change in duration for the LEDs to be illuminated is not updated until the call to delay() after illuminating the present LED is completed. That is, it would be nice if when the potentiometer is turned to a high resistance, a change in which LED is illuminated could be triggered immedately upon turning the knob to a position matching the current duration the LED has been illuminated rather than having to wait until the duration commanded at time of illumination is completed. 
3. The button only triggers the horn sound in the period between one LED turning off and the next illuminating.

Of these problems, only #1 is much of a problem while the duration the LEDs are illuminated is small, but #s 2 &3 become more pronounced when the potentiometer wiper commands a longer delay() period. 

The following sketch dodges the problem with delay() by using the lessons learned from 'blink without delay' and Multitasking the Arduino.

/*
  This sketch is original work by the author of westwoodtoys.blogspot.com
  
  Permission is hereby granted, free of charge, to any person obtaining a copy
  of this software and associated documentation files.
  
  The above copyright notice and this permission notice shall be included in all
  copies or substantial portions of the Software.
*/
int leds[]={3,5,6,9,10,11};
int wait_time = 5*1028;
int speakerPin = 4;
//timers added to replace delay function calls
unsigned long this_loop_time;
unsigned long leds_timer;
unsigned long buzzer_timer;
//New variable to make button into a state machine
bool button_pressed = 0;
//New variables to make the buzzer into a state machine 
//(keep track of what stage of the sound effect is needed)
int buzzer_counter = 0;
//(keep track of the tone, this replaces 'n' in the for-loop
//in the play_sounds() function the version using delay())
int buzzer_tone=554;
//make array of buzzer durations
int buzzer_duration[]={3,500,500,3,1500};
//new variable to keep track of LED to illuminate
//(this is replacing the for-loop increment 'i')
int leds_counter = 0;
void setup()
{
  for(int i=0;i<6;i++)
  {
    pinMode(leds[i],OUTPUT);
  }
  pinMode(A0,INPUT);
  pinMode(2,INPUT);
  pinMode(speakerPin,OUTPUT);
  //set the timer so that the first LED lights immediately on startup
  leds_timer = millis()-wait_time;
}
void loop()
{
  this_loop_time=millis();
  wait_time=5*analogRead(A0);
  if(this_loop_time-leds_timer>wait_time)
  {
  //this implementation of digitalWrite() is a little tricky:
    //The modulo operator acts like if/else to turn LEDs on
    //or off, using not to get the opposite value.
    //The counter goes to 12, twice the number of LEDs
    //and integer division is leveraged to write to the correct
    //LED for even and subsequent odd counter values
    digitalWrite(leds[leds_counter/2],!(leds_counter%2));
    if(leds_counter%2==0)
      //only resetting the timer when lights go on, otherwise
      //would have equal duration of off time
      leds_timer=this_loop_time;
    //increment and reset counter when >=12
    leds_counter=(leds_counter+1)%12;
  }
  if(digitalRead(2)&&button_pressed==0)
  {
    //the buttton_pressed state variable serves to debounce
    //and keep from registering multiple button presses,
    //which would interrupt the sound playing
    button_pressed=1;
    buzzer_timer=this_loop_time;
  }
  //coding the truck horn sound requires a timer, a counter
  //and an array of tone durations. Writing this code is 
  //quite a bit more involved than the sequential approach
  //used in the version using delay()
  if(button_pressed)
  {
  switch(buzzer_counter)
    {
      case 0:
      {
        tone(speakerPin, buzzer_tone);
        if(this_loop_time-buzzer_timer>buzzer_duration[buzzer_counter])
        {
          buzzer_tone--;
          buzzer_timer=this_loop_time;
        }
      if(buzzer_tone==523)
          buzzer_counter++;
        break;
      }
      case 1:
      {
        tone(speakerPin, buzzer_tone);
        if(this_loop_time-buzzer_timer>buzzer_duration[buzzer_counter])
        {
          buzzer_counter++;
          buzzer_timer=this_loop_time;
        }
        break;
      }
      case 2:
      {
        noTone(speakerPin);
        buzzer_tone=554;
        if(this_loop_time-buzzer_timer>buzzer_duration[buzzer_counter])
        {
          buzzer_counter++;
          buzzer_timer=this_loop_time;
        }
        break;
      }
      case 3:
      {  
        tone(speakerPin, buzzer_tone);
        if(this_loop_time-buzzer_timer>buzzer_duration[buzzer_counter])
        {
          buzzer_tone--;
          buzzer_timer=this_loop_time;
        }
      if(buzzer_tone==523)
          buzzer_counter++;
        break;
      }    
      case 4:
      {
        tone(speakerPin, buzzer_tone);
        if(this_loop_time-buzzer_timer>buzzer_duration[buzzer_counter])
        {
          buzzer_counter++;
          noTone(speakerPin);
        }
        break;
      }
      default:
      {
        buzzer_counter=0;
        buzzer_tone=554;
        button_pressed=0;
      }
    }
  }    
}

Here is a Tinkercad simulation of this one.

It is probably immediately obvious that this sketch is much longer than the one using delay.  Unfortunately, dodging the problem with delay() is done at cost of increased complexity.  However, when running this sketch, one would see that the three problems are now entirely resolved.  That is:

1. LED illumination continues to change while playing the horn sound
2. Changes in potentiometer wiper position are updated immediately
3. The button will trigger the horn sound upon being depressed, irrespective of the state of the LEDs.

There are a few things to recognize in the difference between the two sketches.  For one, the function controlling the horn sound has been moved into the main loop. This isn't strictly necessary, but makes for easier coding. For another thing, the timing of the LEDs changing does appear to be affected somewhat by the playing of the horn sound.  This is likely because of the increase in loop time when processing the horn sound.  When not playing, a big 'if' condition is bypassed. Finally, if a reader is not familiar with state machines, then surely this code will be hard to parse.

The neophyte will find use of the modulo operator valuable in making state machines work, as demonstrated repeatedly in the code above. If the function of state machines is tricky for the reader, a suggestion for an example project to get a better understanding is to add a counter to 'blink without delay' similar to the use of leds_counter in the sketch above.  It could be used to make the LED blink a variable number of times between a single longer off interval. I call this "for looping without for looping", and this is a fairly crucial concept to understand when moving beyond beginner level micro-controller projects.