Programs that never wait: millis() and states

delay() is easy to use, but it stops the whole sketch. A robot that waits cannot look. The fix is to check the clock instead of waiting. Three tools make this work: millis() timers, flags and a state machine.

#What delay() really does

During delay(1000), the Uno runs no other line of your sketch for one second. It cannot read the sensor, change a motor or print a message. Only background work, such as counting time, goes on.

For a simple job, that is fine. The First drive sketch uses delay(STRAIGHT_MS), 1200 ms, for each side of its square. That robot has no sensor and nothing else to do. Now imagine a distance sensor on it. For 1.2 seconds on each side, the robot would not look. It would hit a wall that appears in that time.

delay() also makes two jobs at once hard. Try to blink one LED every 500 ms and another every 170 ms with delay(). Every delay() holds up both LEDs. You would have to work out a combined timetable by hand. And it would break as soon as you add a third job.

Some functions wait a little by themselves. In our robot sketches, pulseIn() waits up to 25 ms for an echo. Such short waits are acceptable. The problem is a long wait at a time when the robot should be looking.

#millis(): a clock you can read

millis() returns the number of milliseconds since the board started. It counts up by itself, in the background, while your sketch runs. It returns an unsigned long: a whole number from 0 to 4,294,967,295. Keep every time value in an unsigned long variable too. An int is not enough: on the Uno it holds numbers only up to 32,767. As milliseconds, that is less than 33 seconds.

Think of cooking rice. You do not stand at the pot for 20 minutes. You note the time when you start. Then you look at the clock from time to time: have 20 minutes passed? In between, you do other things. A millis() timer works the same way.

#The timer pattern

Here is one of the two timers from the TwoTimers sketch:

unsigned long now = millis();

if (now - moduleTimer >= MODULE_MS) {
  moduleTimer = now;
  moduleOn = !moduleOn;
  digitalWrite(LED_MODULE, moduleOn);
}

• now - moduleTimer is the time since the LED last changed.
• >= MODULE_MS asks: have at least 500 ms passed?
• If yes, the sketch saves the new time in moduleTimer, flips the flag and sets the pin.
• If no, it skips the block. It does not wait. It goes on to the next job and asks again on the next pass of loop().

Use >=, not ==. The sketch may be busy with something else at exactly 500 ms, for example inside pulseIn(). With >=, the timer still fires, a little late. With ==, it can miss its moment and never fire.

#Why subtraction survives the wrap

After 4,294,967,295 ms, about 49.7 days, millis() starts again from 0. This is called a wrap, or overflow.

Unsigned numbers count like a clock face. On a 12-hour clock, from 11 o'clock to 2 o'clock is 3 hours, even though 2 is smaller than 11. Subtraction with unsigned long works the same way. It always gives the time that passed, counted forwards.

An example with real numbers:

• moduleTimer is 4,294,967,000: that is 296 ms before the wrap.
• now is 204: that is 204 ms after the wrap.
• The real time that passed is 296 + 204 = 500 ms.
• The Uno computes 204 - 4,294,967,000 in unsigned long and gets exactly 500. The timer fires on time.

The other way of writing it, now >= moduleTimer + MODULE_MS, fails here. The sum 4,294,967,000 + 500 wraps round to 204. Just after the timer was set, now is still about 4,294,967,000. That is more than 204, so the check is true immediately, on every pass, until millis() wraps.

A robot rarely runs for 49 days. But the correct pattern is no harder to write, and some devices, such as a greenhouse controller, run for months.

#Two LEDs, two timers

TwoTimers gives each LED its own timer: a variable that holds the time of the last change, and a constant interval.

loop() runs many thousands of times a second. On most passes, both checks say "not yet", and nothing happens. Sometimes one of them fires, changes its LED and saves the time. Neither timer waits for the other.

The wiring is the same as in the Blink project: the LED module's S pin on D2 and its - pin on GND.

Note where the variables live. moduleTimer, boardTimer, moduleOn and boardOn are declared at the top, outside loop(). A variable declared inside loop() is created again on every pass and forgets its value.

#Flags: remembering yes or no

moduleOn and boardOn are flags: bool variables that remember a yes-or-no fact. moduleOn = !moduleOn flips the flag: true becomes false, and false becomes true. digitalWrite(LED_MODULE, moduleOn) then sets the pin HIGH for true and LOW for false.

Flags are good for simple facts: is the LED on, has the robot started? For a robot with several modes, many flags get confusing. Nothing stops two of them from being true at once, even when that makes no sense. For modes, use a state machine.

#What you will see in the simulator

Build the desk robot of the Blink project in the simulator: the Uno and the LED module, with S on D2. Paste the TwoTimers sketch above into Code and press Upload. On the desk, the Uno runs from the laptop's USB. The LED module blinks once a second, and the L LED blinks almost three times a second. Because 500 is not a multiple of 170, the two LEDs change at different moments, and the pattern between them keeps shifting. Neither LED ever waits for the other.

#A state machine: one variable for what the robot does

The obstacle avoider has three jobs that follow each other: drive ahead, drive backwards, turn. Each job is a state. The robot is always in exactly one state.

enum class State : byte { Drive, Back, Turn };
State state = State::Drive;

enum class makes a new type with three named values. : byte stores it in one byte of RAM. The variable state holds the current state. Why not plain numbers? With an int, state = 2 would mean nothing to a reader, but state = State::Turn does. enum class is also strict: the compiler does not accept a plain number as a State. And the names stay inside State, so they cannot mix with other names in the sketch.

In loop(), switch (state) jumps to the case of the current state. Each case does two things. It sets the motors, and it checks whether it is time to change state. break ends the case.

The function enter(next) changes the state. It also saves the time in stateStart, so each state can time itself. When the next state is Drive, it sets lastPing to 0. This makes the robot measure again immediately, instead of driving on with an old distance.

Measuring is not a state. It has its own timer at the top of loop(): every 60 ms, in every state. That is why the robot keeps measuring while it drives backwards and turns.

#Draw the state diagram as a table

On paper, you can draw each state as a circle and each change as an arrow. A table holds the same information and is easier to type:

To plan your own robot, fill in such a table first, one row per state. Then write one case for each row. The "When it changes" column becomes the if, and the "Next state" column becomes the call to enter().

A new behaviour is a new row. For example, a Stop state could hold the robot still while something is closer than 10 cm, and go back to Drive when the way is clear. You add one row for Stop and one new condition in the Drive row. The rest stays the same.

Run the obstacle avoider in an arena and watch the Serial Monitor. The distances keep coming, about every 60 ms, also while the robot drives backwards and turns. With delay() in those states, the numbers would stop. The whole robot is in the Obstacle avoider project.