Bluetooth support: not enough RAM for it, though in principle its chip/transceiver could support it!
Supported editors:
MicroPython web editor and compiler:
Everything in this section is tested on the Micro Bit v1 from Micro Bit v1 unless otherwise noted.
Microbit simulator using some Microsoft framework.
TODO the Python code from there does not seem to run on the microbit via uflash, because it is not MicroPython. asks how to compile locally and suggests it is possible. Seems to require Yotta, so presumably compiles?
Presumably this is because Microsoft ported their MakeCode thing to the MicroBit, and the Micro Bit foundation accepted them.
E.g. there toggling a LED:
led.toggle(0, 0)
but the code that works locally is a completely differently named API set_pixel:
microbit.display.set_pixel(0, 0, )
Microsoft going all in on adopt extend extinguish from an early age!
When plugged into Ubuntu 22.04 via the USB Micro-B the Micro Bit mounts as:
for username ciro.
Loading the program is done by simply copying a .hex binary into the image e.g. with:
cp ~/Downloads/microbit_program.hex /media/$USER/MICROBIT/
The file name does not matter, only the .hex extension.
The back power light flashes while upload is happening.
Flashing takes about 10-15 seconds for the 1.8 MB scroll display hello world from
from microbit import *
display.scroll("Hello, World!")
and the program starts executing immediately after flash ends.
You can restart the program by clicking the reset button near the USB. When you push down the program dies, and it restarts as soon as you release the button.
To use a prebuilt firmware, you can just use uflash, tested on Ubuntu 22.04:
git clone
cd micropython
git checkout 7fc33d13b31a915cbe90dc5d515c6337b5fa1660
uflash examples/
What that does is:
  • convert the MicroPython code to bytecode
  • join it up with a prebuilt firmware that ships with uflash which contains the MicroPython interpreter
  • flashes that
To build your own firmware see:
TODO didn't manage from source Ubuntu 22.04, their setup bitrotted way too fast... it's shameful even. Until I gave up and went for the magic Docker of +, and it bloody worked:
git clone
cd micropython
git checkout 7fc33d13b31a915cbe90dc5d515c6337b5fa1660
docker pull
docker run -v $(pwd):/home --rm yt target bbc-microbit-classic-gcc-nosd@
docker run -v $(pwd):/home --rm make all

# Build one.
tools/ build/firmware.hex examples/ -o build/counter.hex
cp build/counter.hex "/media/$USER/MICROBIT/"

# Build all.
for f in examples/*; do b="$(basename "$f")"; echo $b; tools/ build/firmware.hex "$f" -o "build/${}.hex"; done
The pre-Docker attempts:
sudo add-apt-repository -y ppa:team-gcc-arm-embedded
sudo apt update
sudo apt install gcc-arm-embedded
sudo apt install cmake ninja-build srecord libssl-dev

# Rust required for some Yotta component, OMG.
sudo snap install rustup
rustup default 1.64.0

python3 -m pip install yotta
The line:
sudo add-apt-repository -y ppa:team-gcc-arm-embedded
E: The repository ' jammy Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
and then the update/sudo apt-get install gcc-arm-embedded fails, bibliography:
Attempting to install Yotta:
sudo -H pip3 install yotta
python3 -m pip install --user yotta
was failing with:
Exception: Version mismatch: this is the 'cffi' package version 1.15.1, located in '/tmp/pip-build-env-dinhie_9/overlay/local/lib/python3.10/dist-packages/cffi/'.  When we import the top-level '_cffi_backend' extension module, we get version 1.15.0, located in '/usr/lib/python3/dist-packages/'.  The two versions should be equal; check your installation.
python3 -m pip install --user cffi==1.15.1
did not help. Bibliography:
From a clean virtualenv, it appears to move further, and then fails at:
Building wheel for cmsis-pack-manager (pyproject.toml) ... error
error: [Errno 2] No such file or directory: 'cargo'
So we install Rust and try again, OMG:
sudo snap install rustup
rustup default stable
which at the time of writing was rustc 1.64.0, and then OMG, it worked!! We have the yt command.
However, it is still broken, e.g.:
git clone
cd microbit-samples
git checkout 285f9acfb54fce2381339164b6fe5c1a7ebd39d5
cp source/examples/invaders/* source
yt clean
yt build
blows up:
annot import name 'soft_unicode' from 'markupsafe'
Official support is abysmal, very focused on MicroPython and their graphical UI.
The setup impossible to achieve as it requires setting up the Yotta, just like the impossible to setup Compile MicroPython code for Micro Bit locally on Ubuntu 22.04 with your own firmware setup.
So we just use +
docker pull
git clone
cd microbit-samples
git checkout 285f9acfb54fce2381339164b6fe5c1a7ebd39d5

# Select a sample, builds one at a time. The default one is the hello world.
cp source/examples/hello-world/* source

# Build and flash.
docker run -v $(pwd):/home --rm yotta build
cp build/bbc-microbit-classic-gcc/source/microbit-samples-combined.hex "/media/$USER/MICROBIT/"
.hex file size for the hello world was 447 kB, much better than the MicroPython hello world downloaded from the website which was about 1.8 MB!
If you try it again for a second time from a clean tree, it fails with:
warning: github rate limit for anonymous requests exceeded: you must log in
presumably because after Yotta died it started using GitHub as a registry... sad. When will people learn. Apparently we were at 5000 API calls per hour. But if you don't clean the tree, you will be just fine.
Identification: The easiest thing is perhaps the GPIO notches.
Pinout overview: Basically 0, 1, and 2 are the truly generic ones. They can also serve as ADCs.
In the 2010's/2020's, many people got excited about getting children in to electronics with cheap devboards, notably with Raspberry Pi and Arduino.
While there is some potential in that, Ciro Santilli always felt that this is very difficult to do, while also keeping his sacred principle of backward design in mind.
The reason for this is that "everyone" already has much more powerful computers at hand: their laptops/desktops and even mobile phones as of the 2020s. Except perhaps if you are thing specifically about poor countries.
Therefore, the advantage using such devboards for doing something that could useful must come from either:
  • their low cost. This would be an important consideration if you were to mass produce your product, but that is not going to be the case for learners, at least initially.
  • their portability, and closely linked their ability to act as sensors
  • their ability to act as actuators, which is often missing from regular computers
  • them having hardware accelerators that are not normally present in regular computers, e.g. FPGAs or AI accelerators. And then the demo project must demonstrate that the project is able to do something significantly faster/cheaper on the devboard than on a desktop computer.
Many devborads require a 5V power supply.
This is common on wall transformers and USB, but not in batteries.
For battery power you need a transformer.
Video 1. Raspberry Pi Battery Power by ExplainingComputers (2021) Source.