Teacher guide: micro:bit Foundations

The idea in plain words

A micro:bit program is blocks that run in order, from top to bottom. Where you put a block decides when it runs:

• on start runs its blocks once, when the micro:bit switches on. The last picture stays on the screen.
• forever runs its blocks again and again. That is a loop, and it turns a few pictures into an animation.
• Event blocks such as on button A pressed or on shake wait, and run their blocks every time that thing happens.

The simulator (the picture of a micro:bit beside the blocks) runs the program straight away, so no real micro:bit is needed.

Why programmers use them

Almost every device works this way. A pedestrian crossing loops through its lights, and a doorbell waits for a press. Knowing which blocks run once, which repeat and which wait is the first step to making a device do what you want.

An everyday picture, and where it breaks

on start is a morning announcement: it is read out once. forever is a looping playlist. An event block is a doorbell: it does nothing until someone presses it, and then rings every single time.

Where it breaks: a doorbell checked only during the morning announcement would never ring. That is the most common bug: checking a button in on start, which looks once and never again.

Try it yourself (5 minutes)

1. In Pictures in order, put two show icon blocks in on start and watch: the second picture stays.
2. In Again and again, drag both into forever. The pictures now repeat.
3. In Wait for a press, add on button A pressed (from Input) with a picture inside. Click A in the simulator.

Questions students ask

• "Why did it only play once?" The blocks are in on start. Move them into forever.
• "Why does nothing happen when I press A?" The picture is not inside an on button A pressed block.
• "How do I press A and B together in the simulator?" Click the A+B button under the micro:bit.
• "Can I put it on a real micro:bit?" Yes: press Download and drag the file onto the micro:bit.

How it connects

Every later unit builds on these three holders: a button changes a variable, forever checks a sensor and decides, and in the next course radio adds a new event, on radio received.

The idea in plain words

A variable is a named box that holds a value, such as count. Two blocks change what is in the box:

• set count to 0 puts a new value in (the old one is thrown away).
• change count by 1 adds to whatever is already there.

A sensor measures the world and hands the program a number: light level (0 dark to 255 bright), temperature (degrees Celsius), acceleration (tilt: below 0 one way, above 0 the other). A sensor is like a variable that the world keeps changing. The program only sees a new value when it reads the sensor again.

Why programmers use them

Every device that counts or measures needs both: a step counter keeps a variable and changes it on each shake; a thermostat reads a temperature sensor again and again. Programs are mostly about keeping track of numbers like these.

An everyday picture, and where it breaks

A variable is a tally on a whiteboard. Change by 1 adds a stroke; set to 0 wipes the board. A sensor is the thermometer on the wall: it keeps changing whether or not anyone looks.

Where it breaks: wiping the board inside forever happens many times a second, so the tally is always 0. And looking at the thermometer once (in on start) tells you the temperature at the start, not now.

Try it yourself (5 minutes)

1. In the Count with a variable lesson, run the counter and press A a few times.
2. Move set count to 0 into forever and press A again: it stays at 0.
3. In the Sensors lesson, drag the light slider and watch the number follow it.

Questions students ask

• "Why does my count stay at 0?" The set block is in forever. Move it into on start.
• "Why does the number take so long to show?" Numbers above 9 scroll across the screen.
• "Where is the slider?" It appears in the simulator once the program uses that sensor.
• "Is the temperature real?" On a real micro:bit, yes, though it reads a little warm because the chip heats up.

How it connects

The Decide unit asks questions about these numbers (if light level < 50), and the challenge keeps a best score in a variable.

The idea in plain words

An if block asks a yes-or-no question (a condition), such as light level < 50. When the answer is yes (true), it runs the blocks inside. When it is no (false), it skips them and does nothing.

else adds an "otherwise": exactly one of the two parts runs. else if adds more questions. The micro:bit asks them from the top, runs the first true one and skips the rest. else runs only when none are true.

Comparisons are in Logic: < less than, > greater than, ≤ and ≥ with "or equal to".

Why programmers use them

Decisions are what make a device respond: street lights switch on in the dark, a fridge beeps when it is too warm, a phone rotates its screen when tilted. Each one is a sensor number and a question.

An everyday picture, and where it breaks

A security guard at a door with a list of questions, asked in order: "Are you staff? Go in. Otherwise, are you a visitor? Sign in. Otherwise, wait here." The first yes decides what happens, and nobody is asked the later questions.

Where it breaks: if the first question is too wide ("Are you a person?"), everyone goes in and the later questions never get asked. That is why the order of else if matters: ask the narrow question first.

Try it yourself (5 minutes)

1. In the If lesson, run the night light. Drag the light down, then back up: the lights stay on.
2. Add a second if: light level ≥ 50, with clear screen inside. Try again.
3. In If and else, rebuild the night light with one if … else.
4. In The first true question wins, tilt the micro:bit a little and a lot. A small tilt shows the else picture.

Questions students ask

• "Why don't the lights go off?" An if does nothing when its question is false. Something else has to turn them off: a second if, or else.
• "Which way round are < and >?" Read it aloud: "light level less than 50". The small end points at the smaller number.
• "Why does my else if never run?" An earlier question is also true for those values. Ask the narrower one first.

How it connects

The Pocket pet challenge turns its hunger number into a face with if … else if … else. In the next course, decisions check which radio message arrived and whether a press came too early.

The idea in plain words

A list (MakeCode calls it an array, in Advanced › Arrays) holds many values in order under one name, such as answers. Each item has a place (an index) counted from 0, so a list of 3 uses places 0, 1 and 2. get value at takes out the item at a place.

pick random (in Math) gives a whole number between two numbers, a new one each time. length of array counts the items. To pick an item at random: get value at (pick random 0 to length − 1). Using the length means the list can grow without changing anything else.

Why programmers use them

Lists keep many related values together (a playlist, a menu, a class roll), so one block can work with any of them: the item at a place a button chose, or the item at a random place.

An everyday picture, and where it breaks

A list is a row of numbered lockers, starting at locker 0. Picking at random is drawing a locker number from a hat.

Where it breaks: people count from 1, so locker 3 in a row of 3 does not exist. And a hat that still holds only the numbers 0 to 2 never picks the two lockers added later: a fixed range on a list that grew.

Try it yourself (5 minutes)

1. In the Lists lesson, press A: place 1 is the second word, No.
2. Change get value at 1 to 3 on a three-item list: nothing shows.
3. In Pick from a list, shake the magic 8-ball a few times. Add an answer and shake again: it comes up, because the range uses the length.

Questions students ask

• "Why does it start at 0?" It counts how far from the start an item is: the first is 0 steps away.
• "Why does one item never come up?" The random range misses its place. Pick from 0 to length − 1.
• "Can it repeat?" Yes. pick random has no memory of the last pick.

How it connects

The Pocket pet picks a trick at random from a list. In the next course, a list both micro:bits share becomes a code for radio messages.

The idea in plain words

The challenge builds a pocket pet: a pet that lives on the micro:bit. It uses every lesson in the course and adds nothing new.

• forever with a pause makes a variable, hunger, go up by itself as time passes.
• on button A pressed feeds it: hunger goes down, with an if so it never goes below 0.
• if … else if … else turns the number into a face: happy, tired or sad.
• on shake picks a trick from a list with pick random 0 to length − 1.

It is built in three milestones with less help each time: most of the steps, then an outline, then a goal only. Pocket pet marks the course Challenge complete.

Why programmers use it

Real programs are combinations: state (variables), time (loops), events, decisions and data (lists) working together. A pet makes the combination visible, and students can test it by looking after it.

An everyday picture, and where it breaks

A pet is a fuel gauge with a face: time drains it, you top it up, and the face shows how full it is.

Where it breaks: a gauge that never drains by itself is not a pet. In code, that is a change block outside forever: hunger never moves unless someone presses a button.

Try it yourself (5 minutes)

1. In Pocket pet, run the first program and wait 10 seconds: hunger counts up by itself.
2. Swap the number for faces with if … else if … else, and press A to feed it.
3. Add a trick of your own to the list and shake.

Questions students ask

• "Why does hunger never change?" The change block is not inside forever.
• "Why is my pet always sad?" Check the order of the questions: < 3 first, then < 6.
• "Why does hunger go below 0?" Only take 1 away if hunger > 0.

How it connects

The next course, micro:bit: talk and play, names jobs as functions, connects micro:bits by radio and measures time, ending with a reaction game and a radio duel.

Make a plant monitor for a windowsill: it reads the light and the temperature, and its face tells you whether the plant is happy, too dark or too hot. What counts as too dark or too hot is up to you (look up what your plant likes).

Milestones:

• The face changes with the light level, decided by if and else.
• A third face for too hot, in one if … else if … else, with the questions in an order that works.
• A button shows how many times it has checked, counted in a variable.

The common gap is question order: a wide question asked first ("light level < 200") hides the narrower ones after it. Ask "which face shows when it is dark and hot at the same time, and is that the one you want?".

let checks = 0
basic.forever(function () {
    if (input.lightLevel() < 40) {
        basic.showIcon(IconNames.Asleep)
    } else if (input.temperature() > 30) {
        basic.showIcon(IconNames.Sad)
    } else {
        basic.showIcon(IconNames.Happy)
    }
    checks += 1
    basic.pause(1000)
})
input.onButtonPressed(Button.A, function () {
    basic.showNumber(checks)
})

Make a micro:bit that answers questions: shake it and it picks an answer from a list (a Magic 8-ball, a dinner chooser, a "who goes first" picker, a dice for a board game). The answers are yours.

Milestones:

• Shaking it shows an answer picked at random from my list.
• My list has at least five answers, and every one can come up.
• Someone else used it for a real question.

"Every one can come up" is the list-length check in disguise: a random place from 0 to the length minus 1. Students who type a fixed number there miss the last answer when the list grows.

let answers = ["YES", "NO", "MAYBE", "ASK AGAIN", "DEFINITELY"]
input.onGesture(Gesture.Shake, function () {
    basic.showString(answers[randint(0, answers.length - 1)])
})