Teacher guide: micro:bit: talk and play

The idea in plain words

A function (in Advanced › Functions) is a named job: some blocks with a name. Making it does not run it; a call block runs it, once per call. One copy serves every call, so changing the function changes every place that calls it. Copied blocks have to be changed one by one.

From this course on, students also see the Python view of their programs. The big idea: every event block is a function, handed to the micro:bit to call when the event happens.

Why programmers use them

Functions name a job once, so it can be used everywhere and fixed in one place. In a two-player game, the same "go" signal shown in two places must stay the same, or the race is unfair.

An everyday picture, and where it breaks

A function is a recipe card: "make the sauce (see card 12)". The recipe is written once and followed whenever a dish needs it.

Where it breaks: writing a recipe card does not cook anything until someone follows it, just as making a function does not run it until it is called.

Try it yourself (5 minutes)

1. In Name a job, press A and count the flashes: one for each call.
2. Delete the calls in A and press A: nothing happens, though the function is still there.
3. Press Python at the top of the editor and find def.

Questions students ask

• "Why doesn't my function do anything?" Nothing calls it. Add a call block.
• "Where is the call block?" It appears under Functions once the function has been made.
• "Do I have to write the Python?" No: it is there to read, so the step to text code later is smaller.
• "Can a function take a number?" Yes (a parameter). That comes in Secret messages.

How it connects

on radio received is one more event block, so one more function the micro:bit calls. The Radio duel uses a function so both players see the same signal.

The idea in plain words

Micro:bits can send short messages to each other by radio (blocks in Radio).

• radio set group picks a channel (0 to 255). Only micro:bits in the same group hear each other.
• send number sends to every other micro:bit in the group. A micro:bit never receives its own message.
• on radio received is an event: it runs each time a message arrives, and receivedNumber holds what came, so one receiver can do something different for each message.

A number can stand for anything, as long as both sides agree. The neatest way is a list both micro:bits share: send the place number, and the receiver looks up the word. That agreement is a code.

In the simulator, a second micro:bit appears as soon as a program uses radio. Both run the same program.

Why programmers use them

Wireless doorbells, car keys, game controllers and smart lights all send tiny messages that mean something agreed in advance. The skill is designing the code: what each message means, and what each side does when it arrives.

An everyday picture, and where it breaks

Radio groups are walkie-talkie channels: everyone on channel 7 hears everyone else on channel 7. A shared list is a codebook: "1 means yes, 2 means no".

Where it breaks: two pairs on the same channel hear each other's messages, and two people with different codebooks misread every message. Both happen in real classrooms.

Try it yourself (5 minutes)

1. In the Send and receive lesson, press A on one simulated micro:bit: the heart shows on the other.
2. In Which message?, press A and then B on one micro:bit: the other shows a different picture for each.
3. In A shared code, press A to choose a word and B to send it.
4. With real micro:bits, set two to different groups and try again: nothing arrives.

Questions students ask

• "Why does nothing arrive?" Check both are in the same group, and press on one while watching the other.
• "Why didn't my own micro:bit show it?" A micro:bit does not receive its own messages.
• "Can it send words?" Yes, with send string, but a number from a shared list is shorter.
• "Why do we hear other groups' messages?" They chose the same group number. Pick a different one.

How it connects

The Radio duel uses a code of four messages (get ready, go, I pressed first, I won) to keep two players' micro:bits in step.

The idea in plain words

running time (in Input › more) is the number of milliseconds since the micro:bit switched on. 1000 ms is one second. It never restarts at a press, so timing is a subtraction: store running time in a variable at the start (start), then later running time − start is how long it took.

A variable can also hold true or false (in Logic). It remembers one yes-or-no fact about what is happening now, such as waiting: is the heart showing? Each event either sets it or asks about it with if, and it must be set back, or it keeps saying true.

Why programmers use them

Stopwatches, lap timers and game scores all subtract two times. True/false variables are everywhere a device must remember a state: a door is locked, a lift is moving, a round has started.

An everyday picture, and where it breaks

running time is the clock on the wall: nobody restarts it to time something; you read it twice and subtract. A true/false variable is a flag held up while something is happening.

Where it breaks: reading the wall clock once tells you the time, not how long something took. And a flag that is never lowered says "yes" for ever, so every later press counts.

Try it yourself (5 minutes)

1. In Time between, press A, count to three, press B: close to 3000.
2. In True or false, press B, then A before the heart: the first version still gives a time.
3. Add waiting and press early again: a cross.

Questions students ask

• "Why is my time 15000?" start was never set, or was set at the wrong moment.
• "Why is it negative?" The subtraction is the wrong way round: running time − start.
• "Why does every press show a cross?" waiting is never set to true.

How it connects

The Reaction timer challenge is built from exactly these two ideas plus a random wait. The Radio duel adds radio, so two players race.

The idea in plain words

The challenge builds a reaction game: press B, wait a random time, then press A as fast as you can when the heart appears. It adds nothing new; every part was taught in the course:

• running time (Time between): store it when the heart appears (start); at the press, running time − start is the reaction time.
• true/false (True or false): a variable such as waiting is true only while the heart is showing, so an early press can be caught.

The Radio duel turns it into a two-player race: both micro:bits run the same program and agree a code (0 get ready, 1 go, 2 I pressed first, 3 I won). Each lesson is built in three milestones with less help each time: the steps, then a goal, then goals only.

Reaction timer and Radio duel mark the course Challenge complete. Two optional lessons go further for students who want more: Fake-outs and levels (decoys, a list of targets, lives) and Tournament (a scoreboard list and rounds that start themselves).

Why programmers use it

Real programs are combinations: state (variables), events, decisions, data (lists) and named jobs (functions) working together. A game makes the combination visible, and students can test it by playing.

An everyday picture, and where it breaks

A reaction timer is a starting pistol and a stopwatch: the pistol fires at an unpredictable moment, the stopwatch starts, and stops when you move.

Where it breaks: a stopwatch that starts when you press go (not when the pistol fires) times the wrong thing. In code, that is setting start at the wrong moment, which makes every time huge.

Try it yourself (5 minutes)

1. In the Reaction timer, press B, wait for the heart, then press A. Good times are 200 to 400 ms.
2. Press A before the heart: without waiting it still shows a number. That is the cheat Milestone 2 fixes.
3. In the Radio duel, press B on one simulated micro:bit and race yourself with A on either.

Questions students ask

• "Why is my time 15000?" start was never set, or was set before the wait. Set it straight after the heart.
• "Why does every press show a cross?" waiting is never set to true. Set it after the heart appears.
• "Why do both players win?" Check racing before counting a press, and set it to false straight away.
• "Is the simulator fair?" Close enough for practice; real micro:bits make the duel far more exciting.

How it connects

Robotics challenges comes next: the same ideas (events, sensors, decisions, functions, radio) driving a two-wheeled robot, first in the robot simulator, then on a real robot.

Make buzzers for a class quiz: each team has a micro:bit, the first team to press its button wins the turn, and every other buzzer knows it lost. A quizmaster micro:bit can reset the round.

Milestones:

• Pressing a buzzer sends its team's number by radio.
• Only the first press counts: later presses are ignored until the round is reset.
• Every buzzer shows who won, and a reset starts a new round.

Needs two or more micro:bits on the same radio group (or two simulators in the editor). The "only the first press" milestone is a true or false variable, as in the Reaction lesson; pairs who skip it get two winners.

let team = 1
let open = true
radio.setGroup(7)
input.onButtonPressed(Button.A, function () {
    if (open) {
        open = false
        radio.sendNumber(team)
        basic.showString("WIN")
    }
})
radio.onReceivedNumber(function (receivedNumber) {
    if (receivedNumber == 0) {
        open = true
        basic.clearScreen()
    } else if (open) {
        open = false
        basic.showNumber(receivedNumber)
    }
})

Make a small game for one or two players that is not one from the lessons: catch a falling dot, keep a balance, a memory game, a race. It keeps score, gets harder, and has a way to win or lose.

Milestones:

• It runs, and the player does something with buttons, tilt or shake.
• It keeps a score and shows it at the end.
• It gets harder or ends, checked with if.
• Someone else played it and I changed one thing because of what they did.

Ask for a one-sentence pitch before coding. A function for "new round" or "show score" keeps forever short; students who skip functions usually end up with a forever block too long to read.

let score = 0
let x = 2
let dotX = 0
let dotY = 0
function newDot() {
    dotX = randint(0, 4)
    dotY = 0
}
input.onButtonPressed(Button.A, function () {
    if (x > 0) {
        x = x - 1
    }
})
input.onButtonPressed(Button.B, function () {
    if (x < 4) {
        x = x + 1
    }
})
newDot()
basic.forever(function () {
    basic.clearScreen()
    led.plot(dotX, dotY)
    led.plot(x, 4)
    basic.pause(400 - score * 20)
    dotY = dotY + 1
    if (dotY == 4) {
        if (dotX == x) {
            score = score + 1
            newDot()
        } else {
            basic.showString("SCORE")
            basic.showNumber(score)
            score = 0
            newDot()
        }
    }
})