Button to Display

Overview

Today students learn the micro:bit input/output basics by programming button presses to trigger LED messages. Students also practice adding simple feedback with sound as an optional extension, while connecting their program behavior to clear “if/then” logic and test results.

Learning intentions

• Students will be able to describe how micro:bit inputs (buttons) cause outputs (LED and optional sound).
• Students will be able to write and test a program that shows different LED messages for Button A and Button B.
• Students will be able to debug by identifying which part of the input/output behavior is not working as expected.

Success criteria

• I can make the micro:bit show a specific LED message when I press Button A.
• I can make the micro:bit show a different LED message when I press Button B.
• I can explain my program as clear input → process → output steps.
• I can test and fix at least one problem in my program (or explain why it already works).

Curriculum links

• Mathematics/Number System: use fraction division to interpret and compute results in word contexts (useful for sharing equal “beats/seconds” timing ideas during testing) aligned to CCSS.MATH.CONTENT.6.NS.A.1.
• Number sense for real-world contexts (helpful for interpreting offsets or positions if students mention “above/below zero” ideas when testing feedback intensity) aligned to CCSS.MATH.CONTENT.6.NS.C.5.
• Coordinate/ordered pair thinking for optional “message positions” ideas (e.g., where pixels appear) aligned to CCSS.MATH.CONTENT.6.NS.C.6b.

Lesson structure (45 minutes)

1. 0–5 min · Hook & goal. Teacher shows a micro:bit demo: pressing Button A shows “A”, pressing Button B shows “B”. Students turn-and-talk: “What is the input? What is the output? What changes between A and B?”

2. 5–12 min · Mini-lesson: input/output logic. Teacher models a simple flow: Input (Button A pressed) → Output (LED text) using if/then language, then repeats for Button B. Students complete a quick sentence frame on paper: “When ___ happens, the micro:bit shows ___.”

3. 12–20 min · Guided building: Button A message. Teacher gives a short step-by-step sequence for students to create a program that displays one LED message for Button A (including a “hold” vs “press” test note). Students follow the steps, download/flash, and do two tests: press once and press repeatedly.

4. 20–28 min · Guided building: Button B message. Teacher highlights where the second rule should be added (separate condition for Button B) and points out common errors (wrong button, overwriting logic, message not appearing). Students add Button B behavior and test again, recording results: “Expected vs. what happened.”

5. 28–35 min · Pair-debug & improve. Teacher circulates with a debugging checklist: Is the correct button referenced? Is the LED block correct? Is the message long enough to be readable? Students in pairs use a “Fix-it first, then explain” routine: one person points to the block that must change, the other verifies by testing after changes.

6. 35–41 min · Share-out: explain the program. Teacher selects 2–3 students to describe their input/output in 30 seconds using: “When I press…, the output is…” Students listen for clarity and compare their approaches.

7. 41–45 min · Exit ticket. Teacher collects quick written answers:

• “One input I used was ___.”
• “One output I used was ___.”
• “One way I tested was ___.” Students submit before leaving.

Resources

• micro:bit devices (1 per student or shared pairs)
• computer with micro:bit programming environment installed (block-based)
• USB cables for flashing
• printed coding checklist (Input rule → LED output; test steps)
• mini LED message cards: “A”, “B”, “HELLO”, or class-chosen short words
• student debug log sheet (Expected / Actual / Fix / Retest)
• optional small speaker/buzzer module or built-in sound blocks access (for extension)

Assessment

• Formative checks during the guided build: teacher observes whether Button A triggers the correct LED message.
• Pair-debug accountability: students must record at least one expected/actual result and one fix.
• Exit ticket: confirms students can identify input and output and describe one testing method.

Differentiation

• Support: provide sentence starters (“When Button A is pressed, the micro:bit will…”), and a reference “starter program” that already includes both buttons with blank message slots.
• Support for debugging: offer a three-question checklist students must use before asking for help (button? output block? test method?).
• Extension (optional sound effects, if time and access allow): students add a short sound cue when a button is pressed, choosing a different sound for A vs B; they must also ensure the LED message still displays.
• EAL/SEN: allow students to draw their input/output mapping (two boxes labeled A and B with arrows to their messages) instead of only writing sentences; pair students strategically for peer support.

Extension (optional)

• Add sound effects for Button presses: one tone for A, a different tone for B; ensure the program still runs reliably with rapid pressing.