Combination Lock

Everything you have built so far runs on its own and ignores you. This band changes that. By the end, your board will wait for you, notice what you do, remember it, and decide what to do about it.

Four new ideas do all the work:

• Reading a pin instead of writing to it.
• Deciding, with if and else.
• Remembering, by keeping a value in a name between one round and the next.
• Storing a list of things in one name, which is called an array.

You also get a new tool: the serial monitor. It lets you see numbers from inside your program while it is running. Once you have it, most problems in this course become findable instead of mysterious.

What you need

• Your board, USB cable and breadboard
• Four push buttons, the small square kind with four legs
• Two LEDs, ideally one green and one red
• Two resistors of 220 ohms
• An active buzzer, the kind with a solid black cover on the bottom
• About sixteen jumper wires

No resistors are needed for the buttons. You will find out why in Part 4, and it is one of the more useful things you will learn this band.

By the end you will be able to

• Say which legs of a push button are joined to which, and why that matters
• Explain what a floating pin is and why it lies to you
• Use the serial monitor to see what your program is really doing
• Write if and else to make the board choose
• Make the board remember something between one round and the next
• Count one press as one press, instead of forty
• Keep a list of numbers in one name

Find a door. Any door will do. This takes five minutes and it will save you an hour of confusion later.

Pick the right door. You want one that swings easily: on a hard floor, not dragging on a carpet, and not one that pulls itself shut. Test it by pushing it gently. If it swings freely, use it.

That is the whole idea of the next few parts, and it is the thing most beginners get wrong.

A pin on the Arduino that has nothing holding it is like the ordinary door. It is not at 1 and it is not at 0. It drifts, and it moves when anything happens nearby. You cannot trust what it tells you.

A pin with a spring on it is different. It always sits at one value unless something is actively pushing it to the other. And that is exactly what you are going to switch on.

Keep hold of the spring door. When you meet the word INPUT_PULLUP in Part 4, it means: put a spring on this pin.

Take one of the small square buttons out of your kit and look at it. It has four legs, not two.

That surprises people. A button has one job, so why four legs?

The answer is that the four legs are really two pairs, and the pairs are already joined together inside.

So the button is not a device with four separate connections. It is a device with two connections, each of which has been given two legs so that it sits firmly in a board.

When you press it, a metal disc inside is pushed down and touches both sides at once. That closes the circuit. Let go and a small spring lifts the disc away, and the circuit is broken again.

Until now, the only way your program could tell you anything was by switching a light on. That is a very small window. From here on you get a much bigger one.

The serial monitor is a window in the Arduino IDE that shows text and numbers sent by the board, while the board is running. Your program can say things to you.

Three lines make it work

You can send a number, or you can send words by putting them in double quotation marks: Serial.println("hello");

Wire one button and try it

This is the simplest circuit in the whole course. There is no resistor at all.

You have just seen something that feels backwards. Not pressed gives 1. Pressed gives 0.

Most people expect the opposite, and it is worth understanding properly rather than just memorising, because it comes back in every band from here on.

First, see the problem for yourself

In your sketch, find this line:

pinMode(buttonPin, INPUT_PULLUP);

Change it to this, and upload again:

pinMode(buttonPin, INPUT);

That jumping is a floating pin. It is your ordinary door from Part 1, swinging in the draught.

What INPUT_PULLUP actually switches on

Inside the chip there is a resistor connected to 5 volts. Normally it is disconnected. Writing INPUT_PULLUP connects it to your pin.

Now trace what happens:

• Button not pressed. The only thing touching the pin is that resistor, which is joined to 5 volts. So the pin sits at 5 volts. The board reports HIGH, which is 1.
• Button pressed. Now the pin also has a direct path to GND through the button. A direct path wins easily against a resistor. The pin drops to 0 volts. The board reports LOW, which is 0.

So the reading is not backwards at all. It is telling you the truth about the voltage. The spring holds the door shut, and pressing the button pulls it open.

int buttonPin = 2;
int ledPin = 8;

void setup() {
  pinMode(buttonPin, INPUT_PULLUP);
  pinMode(ledPin, OUTPUT);
}

void loop() {
  if (digitalRead(buttonPin) == LOW) {
    digitalWrite(ledPin, HIGH);
  } else {
    digitalWrite(ledPin, LOW);
  }
}

Your button is already wired from Part 3. You only need to add one light.

This is how a program makes a choice. Here is the shape:

if (something is true) {
  do these lines
} else {
  do these other lines instead
}

Break it into pieces:

• if is the word that starts a choice.
• The round brackets hold the question. The question must have an answer of yes or no. Nothing else.
• The first pair of curly brackets holds what to do if the answer is yes.
• else means "otherwise".
• The second pair of curly brackets holds what to do if the answer is no.

The else part is optional. Leave it out and, when the answer is no, nothing happens and the program carries on below.

Asking the question

You can also chain choices together with else if, which means "otherwise, if this other thing is true". The board tries each one from the top and stops at the first one that is true.

So far your button only works while you hold it. A real switch is not like that. You press once and the light stays on. Press again and it goes off. That needs memory.

Here is the idea. Keep a name outside loop, at the top of the sketch. Names declared up there survive from one round of loop to the next. Names declared inside loop are thrown away and made fresh every round.

The name we want holds only yes or no, so it uses a new type: bool.

Try it, and watch it fail

Upload b3_03_toggle_buggy.ino. It is meant to switch the light on with one press and off with the next.

bool lightIsOn = false;

void loop() {
  if (digitalRead(buttonPin) == LOW) {

    if (lightIsOn == true) {
      lightIsOn = false;
    } else {
      lightIsOn = true;
    }

  }
  ...
}

Read it carefully. The logic looks completely right. If it is on, turn it off. Otherwise turn it on.

Do not fix it yet. First work out why, in Part 9. Write down your best guess now.

If your guess involves the number you learned in Part 6, you are already close.

Two separate things are going wrong. They are often confused with each other, so we will take them one at a time.

Problem one: the loop is far faster than your finger

Your loop runs around a hundred thousand times a second. Your finger holds the button down for maybe a fifth of a second, even when you press quickly.

So the board does not see one press. It sees roughly twenty thousand rounds in a row where the button is down, and it flips the light on every single one of them.

The fix is called edge detection. Instead of asking "is the button down?", ask "has the button just gone down?" That only happens once per press, no matter how long you hold it.

To ask that, the board must remember what the button was doing last time round, and compare:

int reading = digitalRead(buttonPin);

if (reading == LOW && lastReading == HIGH) {
  // it was up, and now it is down. This is the moment of the press.
}

lastReading = reading;

Read those three parts:

1. Take a fresh reading.
2. Act only if it is down and it was up last time. That is the exact instant it changed.
3. Remember this reading, so that next round it becomes "last time".

That last line is easy to leave out and the code will not complain. If you forget it, lastReading never changes and nothing works.

Problem two: the button itself is not clean

Here is a small experiment. You need a metal coin and a hard surface: a table, a tiled floor, or a plate.

Hold the coin flat, about 20 cm above the surface, and simply let go. Do not throw it. Now listen carefully.

You let it go once. But it landed several times. Metal hitting a hard surface always does this: it bounces, touching and lifting off again a few times before it settles. And the metal inside a push button does exactly the same thing.

This is called bounce. In those few thousandths of a second, edge detection sees several separate presses, because as far as the pin is concerned there really were several.

The fix is called debouncing, and the simplest version is almost rude in how easy it is. Once you have accepted a press, wait a moment before looking again:

delay(50);

Fifty thousandths of a second is much longer than the bounce and far shorter than a human can press twice. By the time the board looks again, the metal has settled.

Now fix it

Your lock needs four buttons. Writing out four sets of everything would be long and easy to get wrong. An array solves it.

An array is one name that holds a whole list of values, side by side.

int buttonPins[4] = {2, 3, 4, 5};

Piece by piece:

• int says these are whole numbers.
• buttonPins is the name.
• [4] says there are four of them.
• {2, 3, 4, 5} are the four values, in order.

Getting one value out

You use square brackets and a position number:

buttonPins[0]   is 2
buttonPins[1]   is 3
buttonPins[2]   is 4
buttonPins[3]   is 5

Why arrays and for loops belong together

You met for in Band 2 for counting brightness. Here is what it is really for. Instead of this:

pinMode(2, INPUT_PULLUP);
pinMode(3, INPUT_PULLUP);
pinMode(4, INPUT_PULLUP);
pinMode(5, INPUT_PULLUP);

you write this:

for (int i = 0; i < 4; i = i + 1) {
  pinMode(buttonPins[i], INPUT_PULLUP);
}

The counter i takes the values 0, 1, 2, 3 in turn, and each time round, buttonPins[i] means a different pin.

Four lines became three, which does not sound like much. But go to eight buttons and the first version becomes eight lines while the second one stays exactly as it is. You change one number.

Notice the test is i < 4, not i <= 4. With four things, the positions are 0, 1, 2 and 3, so you must stop before 4. Using <= here is one of the most common bugs in all of programming.

Everything from this band comes together now. Four buttons, two lights, one buzzer.

Build it in three stages and test after each one. Do not wire all of it and hope. If you build the whole thing and it does not work, you have seven things to check instead of two.

The pin plan

Reading the lock sketch

It is longer than anything you have read so far, but there is nothing in it you have not met. Here is the map. Open the file and find each piece.

a. Follow the code by hand

Take the edge detection from b3_04. Fill in this table by hand, for a press that lasts three rounds. Do not run it.

b. Break it on purpose

In b3_04, change this line:

if (reading == LOW && lastReading == HIGH) {

to this:

if (reading == LOW || lastReading == HIGH) {

One character changed: && became ||. Upload it. Predict what will happen before you press anything, then find out.

c. Put the lines back in order

These four lines from the edge detection have been shuffled:

lastReading = reading;
int reading = digitalRead(buttonPin);
}
if (reading == LOW && lastReading == HIGH) {

Put them back in a working order. Then say in one sentence what breaks if lastReading = reading; is moved to the top instead of the bottom.

d. Explain one line

In b3_05, there is a line near the end of the check:

pressCount = 0;

Why is it there, and what exactly would go wrong without it?

Work on a copy of b3_05_lock_worked.ino. Use File then Save As first.

Bronze

Change the secret to four presses of your own choosing. Then make the code check for a five press secret instead of four. Count how many places you had to change the number 4, and write that number down.

Silver

Make the buzzer beep at a different length for each button, so you could tell which button was pressed with your eyes shut.

Gold

Add a reset: holding button 1 down for two seconds clears whatever has been entered so far and starts again, without counting as a wrong try. You will need to remember when the press started, which means storing a time.

The test that matters most in this band

Hand it to somebody and say only: "this is a lock, the secret is one three three two." Then say nothing else, and watch.

Watch their hands, not their face. Do they press too fast? Do they hold too long? Do they know whether a press was heard? Write down every moment they hesitated.

Hesitation is the finding. It means your device did not tell them something it should have.

Show your work

Post a video of a correct entry and a wrong entry, your build log, and the list of hesitations you saw. Then look at one other person's sketch and find one place where a press might be counted twice.

Code you have not seen. Answer from reading only.

int buttonPin = 4;
int ledPin = 7;
int count = 0;
int lastReading = HIGH;

void setup() {
  pinMode(buttonPin, INPUT_PULLUP);
  pinMode(ledPin, OUTPUT);
  Serial.begin(9600);
}

void loop() {
  int reading = digitalRead(buttonPin);

  if (reading == LOW && lastReading == HIGH) {
    count = count + 1;
    Serial.println(count);
  }

  lastReading = reading;

  if (count >= 3) {
    digitalWrite(ledPin, HIGH);
  }
}

1. What does this do, in one sentence?
2. The button is wired with INPUT_PULLUP. What does digitalRead give when nobody is touching it?
3. Once the light comes on, can anything ever turn it off? Explain.
4. There is no delay for debouncing. What will you actually see in the serial monitor when you press once?
5. Somebody deletes the line lastReading = reading;. Describe exactly what happens then.
6. Somebody changes if (reading == LOW ...) to if (reading = LOW ...), with one equals sign. It still compiles. What will the program do?

Work down this list in order.

Your board can listen now. It can decide. It can remember. And you have a window into it, so when it does something odd you can ask it what it thinks is happening instead of guessing.

You also met a fault that no error message will ever find for you: code that is perfectly correct English and completely wrong. That is most of real programming.

Before you move on, make sure you have

• Your lock, working, with a video of a right and a wrong entry
• Your list of hesitations, from the person who tested it or from watching your own video back
• Your completed table from Part 12a
• Your number from Bronze
• The sentence "not pressed is 1, pressed is 0" in your glossary
• Your build log for this band
• Five or six correct answers in Part 15, including question 6

Next is Band 4: Night Guard. Your buttons only ever say yes or no. Next you meet sensors, which give you a number between 0 and 1023, and you find out that the number means nothing until you decide what it means.