I'm experimenting a lot with BBC micro:bit recently. It is designed as education tool for kids. According to the microbit.org's intention it can be programmed in Block editor, JavaScript and Python.
Since it arrived to the market the maker community and commercial companies put big effort into it, so today it can be used in large amount of environment.
The original programming tools are good for learning, but not really targeted for professional MCU environment. If somebody want to learn something like this, must step forward. This has many aspects why. Here I'd like to show, that:
- The micro:bit hardware not the limiting factor in first place
- You can achieve much more speed from the MCU with those environments
About the board itself:
The micro:bit's core is a 16MHz ARM Cortex-M0 based bluetooth capable Nordic Semiconductor MCU. It is the same what used in commercial devices. The board itself also contains a second processor, an NXP Kinetis device. This second processor is responsible for the communication with the PC where we programming the main MCU from.
This second MCU is our ticket to the professional programming environments.
If you used micro:bit block editor before, you know if you connect the micro:bit to your PC, you will see a drive and you can drop your compiled code there. This drive emulator is handled by the NXP processor.
But this does more than that. It is acting as a debug probe also. It allows single stepping, register reading, etc. in the Nordic MCU, allowing the user the efficient debugging procedures with an developer environment it allows that.
Even you can choose between two different debug probe. The micro:bit arriving with DAPLink (CMSIS-DAP) probe, but it can be changed to Segger J-Link probe if your environment need this.
Now about the speed. I used a small test to show what can we achieve in various environments. The test does nothing else just switch an I/O pin of the device alternating 0 and 1 as fast as possible.
I used three environments for demonstration:
- Block editor/Javascript - The original environment
- Arduino - The first choice tool of Makers, Hobbiest around the globe
- Segger Embedded Studio - One of the heavy professional tools (I choose this as it was the fastest to setup and started to work on the first touch)
The first try - It is written originally in JavaScript instead of Block editor as the Block editor unfortunately has no XOR function. It show what is happening if we alternate our output in the "forever" block:
How this look like in the Block editor:
I connected the output to an oscilloscope to measure the output frequency and see the waveform:
20.8Hz - Ouch it hurts. This means that our code in the forever block is called around 40 times in a second. This is extremely slow. I guess it is the result of the task scheduling of the operating system beneath us.
Let's do another test with this environment. But this time using our loop for switching the output. This is written in the Block editor as it has nothing can't be achieved there:
Just to see, it is here in JavaScript:
And the result:
84.7kHz - much better, but still, it needs 189 clock cycles to run this loop (calculated from the 16MHz clock)
Now go a bit further. The Arduino environment can be used for the micro:bit based on this:
https://learn.adafruit.com/use-micro-bit-with-arduino/install-board-and-blink
First I tried the same, using the environment's loop:
The result from the oscilloscope:
214kHz, much better. It is around 75 clock cycles.
Check the same with own loop:
Bit better but not substantially:
272kHz - 59 clock cycles
And finally the Segger Embedded Studio - as you can see, here the CPU initialization tasks are also in your control:
And the result:
943kHz - 17 clock cycles. If you want to achieve better result, you must go down into assembly level, what I not intend to do now.
From the things above, you can see a little slice of the picture.
