Overview

Software running on a new V2 micro:bit uses CODAL (micro:bit V1 uses the DAL) and as a result no longer includes the Arm Mbed platform. 


The whole microbit-DAL API is implemented in CODAL as a compatibility layer so the same code can compile and run on any micro:bit, irrespective of hardware version.


Extensions that do not compile for V2 will still be available for V1 boards but will be disabled in V2 builds. Users will see an error on the micro:bit V2 display (927).


If your extension is unable to support the V2 device, you can add a flag to pxt.json. Users will see a 927 error when downloaded to a V2 device :

"disablesVariants": ["mbcodal"]


To ease the transition away from mbed, we have also implemented the most common mbed classes in the compat layers of CODAL. These should work in most use cases, but there may be a few edge cases where the behaviour is not identical.


Please file an issue on micro:bit CODAL if  you encounter problems. 

Extensions are encouraged to move to the DAL/CODAL model, using the uBit object to ensure compatibility with all hardware.


All extensions should target the common microbit-dal API, we will not approve new extensions that use the mbed compatibility layer.


The Mbed classes implemented are DigitalIn, DigitalOut, InterruptIn, Timer, Ticker, Timeout, PwmOut

Problems with compilation break down into roughly three categories:


1. Use of Mbed APIs that are in the compatibility layer, but no inclusion of mbed.h

The following Mbed classes are implemented in the compatibility layer:
PwmOut, InterruptIn, DigitalIn, DigitalOut, Ticker, Timer

If you rely on any of these classes you now need to explicitly include mbed.h (whereas previousy microbit.h or pxt.h would implicitly include that). For many extensions, just including mbed.h will resolve outstanding compilation failures.

2. Use of Mbed APIs that are not included in the compatibility layer, or microbit-dal APIs that need different constructors

If you use any other part of mbed than those listed above, the quickest option is to move to the CODAL APIs right away, either using #ifdef mbcodal to make V2 specific code, or using the microbit-dal API that is common to V1 and V2.

There are some parts of the compatibility layer that we are considering extending to; but these are still WIP - if your extension requires these and this will also resolve any future issues, please get in touch.

  • MicroBitI2C / NRF52I2C
  • MicroBitSerial
  • MicroBitFont

3. Use of the mbed Bluetooth APIs

 The extension approval process now requires extensions to not use Mbed.