Polling vs. Delay

Many of the Arduino example programs will use the delay(n); statement to achieve blinking LED’s. Given that we want to not only capture what button was pressed 1st, but also the buttons after this, the “delay” approach will not work for us. Wonder if the 1st button was pressed and we were in a loop to drive the LED with a 500 ms (1/2 second) delay. 1/2 second is a LONG time and there might have been two or even three buttons pressed during the “delay” time and we would have no way of knowing about it! Several things could happen, when we read the buttons, all three are pressed, or perhaps one is pressed because the other button was pressed and released already! This would make the players very unhappy with our game.

So, we cannot use the “delay” function. Instead we will program the “void loop()” logic in a “polling” method. Basically this means we will try to miniminze any delays in our code and keep looping over and over again checking the status of the buttons. We will also see if it’s time for us to change the status of a LED or buttton. In a timing of the pooling loop in V1.1 we measured the average time spend in the loop to be about 0.1ms or 100 microseconds. That seems to be a pretty quick loop, and minimizes the chance of multiple button presses happening within a single loop.

But, if the loop is just checking to see if a LED needs to be turned off or on, what tells us what we are supposed to do on any given loop?

LED State Machine and Profiles

To manage the buttons and LED’s we create a “State Sequence Array.” Within the array we define a Profile. An example of a profile is “Blink the lights quickly,” or “Turn on the light.” For each profile there is a sequence of states (or step). For example in the int LED_SEQ[] array, we define a profile for blinking the lights quickly. That profile consists of the following state definitions:

HIGH,   250,  1,  /* Profile 2 (2nd place) begin, step 0 - "Blink Quickly" */
 LOW,   250,  0,  /* Profile 2, step 1 */
   0,     0,  0,
   0,     0,  0,
   0,     0,  0,
   0,     0,  0,
   0,     0,  0,
   0,     0,  0,  /* Profile 2 end, step 7 */

So a profile consits of state definitions that have 3 values. The first value is one of three choices, HIGH, LOW, or -1.

• HIGH - when going into this state, drive the output (to the LED or BUTTON) to HIGH.
• LOW - when going into this state, drive the output to LOW.
• -1 - when going into this state, don’t make any change to the output.

The second value is the length of time (in milliseconds) that that state should be in effect before moving to the next state. So Profile 2 in the code fragment above, says to maintain state 1 for 250ms (or 1/4 second) and to also maintain state 2 for 250ms.

The third value is the “next step” or state. In profile 2 step 0, the next step is step 1. The next step after step 1 is step 0. So, you can see that this sequence of states or steps is in a loop. step 0 to step 1 to step 0 and so on.

Defining a “State Sequence Array” lets us easily change the behavior of the buttons and lights by just changing the “program” in the Stage Sequence Array rather than changing C code. For example we experimented with the lights behaving in this way:

• First place - blink one time and wait 1 second.
• Second place - blink two times and wait 1 second.
• Third place - blink three times and wait 1 second.
• Fourth place - blink four times and wait 1 second.

In testing this method with a few people they liked a “on solid,” “blink fast,” “blink slowly,” and “off” as the indication of 1st to 4th place respectively.

Note that we made those changes in the light behavior by ONLY changing the profiles in LED_SEQ[] array and we didn’t have to change the C program at all!

So now that we see how the state (or steps) are defined, how do we keep track of what state the different colored LEDs are in?

Button State Machine and Profiles

The process for manipulating the button behavior is exactly the same as described for the LEDs above. The Button state variable” containing the “profiles” and “steps” or “sequences” is the int BTN_SEQ[] array.

Similarily, the current profle and step for each color is maintained in the long lBSS[] array.

The discussion for the LEDs then applies to the buttons with substitution of the above button variables.

Overall program flow

The various variables are declared, and the variable names for the Arduino I/O pin assignments are declared. See the appendix, the code, or the schematic for the Arduino pins used.

The polling loop then consists of the general steps below:

• Check for button presss, and record the order.
• Manage the Button Sequence State for each color button.
• Manage the LED Sequence State for each color LED
• Check for the Reset button (and then reset the Button/LED Sequence State array to Profile 0, or “off”)
  • Check for any special Reset Button conditions (i.e. held for > TEST_MODE milliseconds, then go into a profile for “Lights Test” mode.

The special case handling of the buttons to independently manage both lights and sound with only one signal line is described in more detail in the section on Button Modifications.

See the appendix for the complete program listing.