If you write a micro:bit editor, we should start by saying thanks! The breadth of the micro:bit ecosystem is one of its greatest strengths and having a range of editors that fill different niches is brilliant.
Secondly, please sign up to our ‘Device and DAL’ mailing list. This list will be used to give notifications about hardware revisions, or key low-level software changes as early as possible. Although we don’t anticipate anything soon, it is clear from this revision that such a list is useful.
Please note that we do as much development as possible in the open, so if you’d like to be part of these processes you can join the relevant projects on GitHub:
- Micro:bit Educational Foundation on GitHub
- MakeCode for micro:bit (pxt-microbit)
Your tools are some of the most direct ways that users experience the micro:bit. We’ve done all we can to try and minimise the amount of work you will need to do in order to seamlessly support the new revision of the micro:bit and the old version in a single program.
If you’re using the microbit DAL/Runtime
We’ve published a new DAL release v2.1.0 that creates a MicroBitCompass or MicroBitAccelerometer object based on whatever hardware is present on the board. If you use the DAL as your abstraction layer, you only need to rebuild against the latest version.
There are some minor changes to the way we create the MicroBitCompass and MicroBitAccelerometer objects in order to accommodate the dynamic driver initialisation, and while the API will remain the same, the constructors will not.
If you’re using the MicroBit class (lancaster-university/microbit) then by moving to the latest version, you’ll inherit the changes automatically.
If you’re using the microbit-dal directly then you should make a change similar to the one made in the MicroBit class that uses the AutoDetect factory methods. The following commit on the microbit repository serves as a good reference:
If you’re using MicroPython
Based on the current work in microbit-dal we've also worked with Damien George, the author of MicroPython, to build the change into the v1.0 release of MicroPython for the micro:bit. The Python API has not changed, so Python scripts do not need to be updated.
If you ensure you use the latest release of the MicroPython binary from GitHub with your editor, then you will be able to support both revisions of the micro:bit device.
As part of the v1.0 MicroPython release there is a bit more info stored at the end of the hex file in a memory area called the UICR (more info can be found in the MicroPython documentation). If you are injecting the user Python code into the hex file like the Python Editor does, then this commit should be a good reference on how to implement these changes on your own editor. In essence, the last few lines of the injectable hex file used to look like this:
:020000040003F7 ::::::::::::::::::::::::::::::::::::::::::: :0400000500019C0951 :00000001FF
And now there are three additional lines before the user code is injected:
:020000040003F7 ::::::::::::::::::::::::::::::::::::::::::: :020000041000EA :1010C0007CB0EE17FFFFFFFF0A0000000000E10008 :0C10D000FFFFFFFF6D0E0300000000009A :0400000500019C0951 :00000001FF
If you’re using the micro:bit profile over BLE
Some editors for the BBC micro:bit use the standard BLE profile. We will publish a new binary that implements this profile once the updates are complete, and the MakeCode Bluetooth package will also include all updates for the revised hardware, so hexes using the Bluetooth profile created in MakeCode can be upgraded this way too.
If you’re using BitIO
BitIO works by first flashing the micro:bit with a pre-built hex file based on MicroPython. There will be an updated release of BitIO to use the latest version of MicroPython with support for the new motion sensors. The only thing you will need to do is update your project to use this version of BitIO when it is released.
If you’re using something else
We aren’t aware of other editors not using these components that also support the sensors directly - the micro:bit Arduino port uses additional libraries for the sensors that are not included in the Arduino core for micro:bit. If you do have a different software stack we strongly advise you consider working on top of the microbit-dal to ensure that you can resolve issues like this in the future. Please get in touch with us with any questions about this.
Identifying which micro:bits you can support
If you write an editor that doesn’t have an online update mechanism, or is only periodically updated, we recommend that you explicitly list (not necessarily visibly to the users) the micro:bit board IDs that you support. This way, you can tell users that you don’t recognise the version of the micro:bit they have if they try to flash a newer version than the editor was written for. For example, if we had this feature in existence before v1.5 (board ID 9901), when your editor encountered a v1.5 micro:bit, it could expressly warn the user about the incompatibility. As it stands, the user will just see a program that doesn’t work properly, which we think detracts more from the micro:bit experience than a clear failure message.
In order to facilitate this, we are introducing the following system:
|micro:bit version ||Board ID |
|v1.3 ||9900 |
|v1.5 ||9901 |
You can read the board ID as the first four characters of the device’s USB serial number.
In the case of editors that use MicroPython, we also propose the following approach:
- If an unknown micro:bit version is detected, but that micro:bit already contains MicroPython at a newer version than the one the editor knows about use the serial port to flash just the python script to the filesystem
This gives a teacher or facilitator who is unable to update their editors (for example due to IT restrictions), but who CAN update the base hex file on the micro:bit, the chance to quickly fix the problem while updating the editor in the background.