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 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 this new version of the DAL.
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 our 1.0 release of MicroPython for the micro:bit. The Python API will not change, so Python scripts will not need to be updated.
If you ensure you use the final v1.0 release of the MicroPython binary from GitHub with your editor, then you will not need to make any additional changes in order to support both revisions of the micro:bit device.
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. After the official release of MicroPython v1.0, which will include support for the motion sensors on the revised micro:bit, there will be an updated release of BitIO. If you update your project to use this version of BitIO then you will need to make no further changes to your code.
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|
You can read the board ID as the first four characters of the device’s USB serial number.
We have also added a new field to the DETAILS.txt file on the v1.5 micro:bit that includes a board URL.
We will guarantee that this URL will take the user to a page about the latest revision, and if you append your editor as a query parameter (?editor=<you>&editor_version=<your version>) and you have provided us with details, we can take the user directly to a section of that page that allows them to find an updated editor.
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.