2. About the Firmware¶
2.1. Modules¶
The GiggleBot MicroPython firmware comes with the following modules:
gigglebot- contains an API to interface with the actual GiggleBot: think motors, line sensor, light sensors, LEDs, servos, etc.gb_diag- still an API to interface with the GiggleBot, but slightly more advanced and useful for debugging purposes.distance_sensor- add-on sensor library for the Distance Sensor.thp- add-on sensor library for the Temperature Humidity Pressure Sensor.lightcolor- add-on sensor library for the Light and Color Sensor.
Each new release comes with the following artifacts:
- A customized BBC micro:bit firmware that includes all the above modules in it - and we are calling it the GiggleBot firmware.
- The minified modules. These modules were minified to take less space on the BBC micro:bit.
- The pre-compiled modules (bytecodes) that no longer need to be compiled when they get imported on the BBC micro:bit.
- And the modules in their natural state.
2.2. Firmware¶
This customized firmware that includes the modules listed in this documentation also includes a handful of features meant to make use of the available RAM on the BBC micro:bit in a more efficient manner.
The vanilla firmware that comes with the Mu Editor is not really a good choice to use with external libraries because you cannot load precompiled modules and then just import them. And loading most of the bigger libraries on the microbit doesn’t work either, because the board has such limited RAM resources.
So we have come up with a custom firmware that allows the import of precompiled python modules (to byte-code aka .mpy files). These .mpy modules can be treated
like regular .py modules and copied in exactly the same manner over your microbit’s filesystem, but they cannot be opened and edited in any way; it’s not like it’s necessary anyway.
This has the advantage of skipping the precompiling phase on the microbit that could leave it without RAM resources during or after this process.
Still, precompiling modules still uses RAM to load them when they get imported, so the best bet is to just incorporate them into the firmware - a process called freezing. And this is what we have done with our firmware. Freezing the modules leads to a small usage of RAM, which is critical to the microbit, given its limited resources.
Here’s a table showing what kind of modules the GiggleBot firmware (which is just a custom MicroPython version for the micro:bit) accepts vs the regular firmware:
| GiggleBot Firmware | Regular Micropython For The Microbit | |
|---|---|---|
regular .py modules |
yes | yes |
precompiled .mpy modules |
yes | no |
| freezed gigglebot modules | yes | no |
And here’s what kind of modules can be used on the BBC microbit hardware:
| Module | Load .py module |
Load .mpy module |
As freezed module |
|---|---|---|---|
gigglebot |
yes | yes | yes |
gb_diag |
yes | yes | yes |
distance_sensor |
no | no | yes |
thp |
no | yes | yes |
lightcolor |
no | yes | yes |
Note
Be advised that loading .py modules directly to the microbit uses most of the RAM that’s available to the board,
so not much is left to the user to code. That’s why it’s better to go with .mpy or freezed modules (meaning our custom firmware) and only go with
the regular .py when burning the custom GiggleBot MicroPython firmware to the microbit is not possible.