Got no internet connection? No problem, you can code your micro:bit using the offline MakeCode Editor - it's available for Windows 10 and MacOS 10+.
This app can do everything the online editor can do, and more - it connects with the micro:bit automatically, and allows students to:
download code directly to their micro:bit without having to drag & drop
use serial logging to read information from the micro:bit in real time
still share via the normal publish functionality (once the internet comes back on)
If you have a computer lab where you have control over the apps used, this could be a good option, in order to avoid drag & drop issues.
If your students are using an iPad, they can use the Swift Playgrounds app with the micro:bit to learn how to code the micro:bit.
There are Android and iOS apps available which allow you to connect your phone or tablet to your micro:bit via Bluetooth. From experience, connecting via Bluetooth on these apps is problematic, but not impossible.
Get long cables for students (90cm+) - so they can move the micro:bit around, allowing testing of sensors, without needing to disconnect from the computer or use the battery pack
Encourage students to disconnect the battery pack when not in use, otherwise the code on the micro:bit will keep running and wear down the batteries
Buy plenty of AAA batteries or rechargeable batteries
Keep all the micro:bit components in a small box, with a list of all the components that should be there, and get students to check that all the components are there when they pack up.
Downloading code can be the most painful part of the process for students, if they have to drag and drop the code into the micro:bit every single time they want to test the code. Having the simulator helps with reducing the amount of on-device testing needed, but really, we should be encouraging students to do more on-device testing. Here's the best ways to download, in order of priority:
Update the firmware of the micro:bit and pair MakeCode with the micro:bit - this takes a bit more effort to set up, but it's worth it in the long run as it reduces download time.
Save the code directly to the micro:bit - you can do this by clicking on the Save button down the bottom middle of the MakeCode Editor
3. Download and drag-and-drop the code into the micro:bit drive, via a File Explorer
When working with external components where the main output is NOT the LED screen, it is a good idea to display something (e.g. a heart) on the LED screen so that students know they have downloaded the code correctly and they have the correct code. If this then didn't display, we could step through a process to work out what the cause of the issue is.
Debugging is the process of identifying, tracking down, and fixing a problem. It was popularised by Admiral Grace Hopper in the 1940s when she was tracking down the source of an issue with a computer, discovered that a stuck moth was causing the problem, and said that she was "debugging" the system.
When using a micro:bit, sometimes the problem can be code-based, and sometimes they can be physical, e.g. a disconnected wire, or short circuit. In the NZ Curriculum, debugging and explaining why things went wrong is part of CT PO4+.
It can sometimes be difficult to know what values a sensor is giving or an output the micro:bit is writing. Here are a couple of ways to make those values visible:
Show value when triggered
This involves displaying a value on the micro:bit screen, at a particular time, or using a trigger. In this example, the light sensor value is displayed when the A button is pressed.
2. Show values continuously
Using the Serial Write blocks, we can get a live stream of information from the micro:bit, via the USB cable. In this example we show the live data from the light sensor:
We can then view the live data by clicking the Show Console button (either Simulator when using Simulator, or Device when connected to micro:bit):
The data from the micro:bit can also be saved by clicking the download button (top right blue icon).
Note: Serial blocks can only be used when paired with the MakeCode editor via webUSB, or when using the Offline Editor.
"It doesn't work" or "It's not working" is a common phrase heard from students when coding or working with electronics. Here are some questions you can use to facilitate critical thinking:
"Why is it not working?"
"Where in your code does it stop working?" or "Which part isn't working?"
"When was it working?"
"What were you expecting it to do?" and "What did it actually do?" (expected result vs actual result)
Just like when we lose something, a good strategy can be to re-trace our steps. With debugging, and especially electronics, where we may have many components and bits of code, back-tracing is a good technique to find out where an issue first occurred.
Back-tracing means going back through the steps we took, in order to find where we went wrong. This involves checking and verifying our values or outputs at each step. This could be with the physical components, or stepping back through our code, displaying & checking values (testing) as we go.
This means starting at the beginning of our code or electronics and testing until we find the problem. An example with micro:bits might start with the following:
Does the micro:bit have power? How can I tell?
Have I downloaded the code to it?
What is the first thing that happens in my code?
Good debugging often combines both forward and back-tracing, jumping to key points and working forward or back from there.