Group Actions
Engagement
  • Author Author: Workshopshed
  • Date Created: Date Created
  • Views 9376 views
  • Likes 4 likes
  • Comments 15 comments
Related
Recommended

A non blocking delay

Workshopshed

The "hello world" of the Arduino is the blink sketch. This demonstrates that your board is working by blinking an LED, typically the on-board LED attached to pin13 but it has a problem.

The code uses the "delay" function which waits the desired number of milliseconds before continuing with the next line of the code.

 

int led = 13;

void setup() {                
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);     
}

void loop() {
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
  //Code here runs once every 2 seconds
}

 

The problem with the delay function is that nothing else happens whilst the delay is running. This is not only wasteful of the limited processing power of the microcontroller but it also makes any other routines you are using potentially unresponsive. There are several approaches to this problem such as using interrupts. The approach I selected to use a class which implement the non blocking delay.

This delay is implemented with a variable and two function, the first sets the delay and the second checks if the delay has finished.

 

Here's how it is used:

#include "Delay.h"

int led = 13;
int ledstate = HIGH;
NonBlockDelay d;

void setup() {                
  pinMode(led, OUTPUT);  
}

// the loop routine runs over and over again forever:
void loop() {
  if (d.Timeout()) {
    digitalWrite(led, ledstate);
    ledstate = ledstate == LOW ? HIGH : LOW; //toggle state
    d.Delay(1000);
  } 
  //Code here runs frequently
}

 

Delay.h

#if defined(ARDUINO) && ARDUINO >= 100
#include <Arduino.h>
#else
#include <WProgram.h>
#endif
class NonBlockDelay {
    unsigned long iTimeout;
  public:
    void Delay (unsigned long);
    bool Timeout (void);
    unsigned long Time(void);
};

 

Delay.cpp

#include "Delay.h"
void NonBlockDelay::Delay (unsigned long t)
{
  iTimeout = millis() + t;
  return;
};
bool NonBlockDelay::Timeout (void)
{
  return (iTimeout < millis());
}
unsigned long NonBlockDelay::Time(void)
 {
   return iTimeout;
 }

 

My reason for wrapping the delay in a class is so that I can use it for twice for each of the steppers in my clock project and so my loop will end up as a series of non blocking calls.

 

void loop() {
     CheckInput();
     ReadClock();
     CalcHandPositions();
     SetStepperPositions();
     StepMotors();
}

Parents

  • What about simply using the Millis() timer.

    The example BlinkWithoutDelay (stupid name IMO) shows how to do it.

     

    Use an unsigned long variable declaration and always subtract the lower number from the larger and the rollover works fine.

    An example of its use as a debounce on a button

     

      // Button handling variables
  boolean ButtonState = HIGH;           // records the Button State
  unsigned long LastButtonCheck = 0;    // Time the Buttons were last checked.
  unsigned long ButtonPressTime = 0;    // Time the last button was pressed.
  int ButtonCount = 0;                  // Button counter

    if (millis() - LastButtonCheck > 5)                    // Reads button state every 5mS and then updates button counts
      {       
        ButtonState = digitalRead(Pushbutton);
        LastButtonCheck = millis(); 

        if (ButtonState == LOW)
        {
          ButtonCount ++;                                     // Increment the Count by 1
          if (ButtonCount > 5)                               // the button should be LOW for 5x5mS = 25mS
          {
            // Button has been pressed for longer than 25mS so its valid
            ButtonPressTime = millis();                       // set the Button press timer
            ButtonCount = 0;
            ProcessButton();                                  // Do something with the valid button press
          }
        }
        else                                                  // Button is HIGH
        {
          ButtonCount =0;                                     // Reset the counter as the button has been released
        }
      }

     

     

    mark

     

    edit ... change the 100mS to 25mS in the comment on line 11

  • in reply to mcb1

    Personally, I prefer hardware debouncing, as for the delay being made simpler / more resource friendly, I agree, a simple variable would have sufficed.

     

    I would have implemented this class as a set of 3 define statements, which would eliminate the overhead the object is bringing in:

     

    #define DELAY_DECLARE(name) volatile unsigned long delay_variable_##name
#define DELAY_SET(name, time) delay_variable_##name = millis() + time
#define DELAY_DONE(name) (delay_variable_##name <= millis())

DELAY_DECLARE(test);
DELAY_SET(test, 1000);

while (!DELAY_DONE(name))
{
    // do whatever
}

     

    Edit: I never used an arduino, but if you don't need that millis() thing anywhere else, you could repurpose the timer that is generating that count and use CTC mode instead. Then you just have to check if the compare match flag is set and reset the counter and the flag when that happens. Doing this will make it even more efficient as it will save the CPU time that is wasted incrementing that millis() counter.

     

    Edit 2: I had a mistake in there, it should have been less or equal, not greater or equal for the DELAY_DONE macro. It's fixed now.

  • in reply to jadew

    >why not simply use Millis() - It is there in the code, it's just abstracted by a class.

     

    I do like the simplicity of the define approach and you raise an interesting point about the use of the volatile keywork which is something I missed, also CTC Mode is something new to me.

     

    For this example can I put the 3 lines into a .h file to include in every project that needs it or does the compiler not work like that? Is re-use a "simple" case of copy and paste?

     

    The reason for using classes was for re-use and abstraction

         as mentioned the idea is to use this for two different motors (which I also plan to control using classes)

         also if I needed longer timing I might switch from using millis() to using the RTC I've attached to my clock.

     

    I did use C/C++ many years ago but I've come back to it recently after a lot of PHP and C# development so my development approach is the build, test, refactor with clarity of code and maintenance being key. I've not applied this to microcontrollors before so don't know how that will work as a strategy.  I've also not got into unit testing on this platform but that's something I'd like to look at.

     

    So far the code I've compiled has come nowhere near the limits of the Arduino Micro I'm using so agressive resource or performance tuning has not been an issue (yet).

Comment
  • in reply to jadew

    >why not simply use Millis() - It is there in the code, it's just abstracted by a class.

     

    I do like the simplicity of the define approach and you raise an interesting point about the use of the volatile keywork which is something I missed, also CTC Mode is something new to me.

     

    For this example can I put the 3 lines into a .h file to include in every project that needs it or does the compiler not work like that? Is re-use a "simple" case of copy and paste?

     

    The reason for using classes was for re-use and abstraction

         as mentioned the idea is to use this for two different motors (which I also plan to control using classes)

         also if I needed longer timing I might switch from using millis() to using the RTC I've attached to my clock.

     

    I did use C/C++ many years ago but I've come back to it recently after a lot of PHP and C# development so my development approach is the build, test, refactor with clarity of code and maintenance being key. I've not applied this to microcontrollors before so don't know how that will work as a strategy.  I've also not got into unit testing on this platform but that's something I'd like to look at.

     

    So far the code I've compiled has come nowhere near the limits of the Arduino Micro I'm using so agressive resource or performance tuning has not been an issue (yet).

Children