bbcmicrobit / micropython Goto Github PK

View Code? Open in Web Editor NEW

594.0 594.0 286.0 17.16 MB

Port of MicroPython for the BBC micro:bit

Home Page: https://microbit-micropython.readthedocs.io

License: Other

C 88.64% C++ 9.02% Makefile 0.03% Python 2.01% JavaScript 0.07% Shell 0.08% Assembly 0.13%

microbit micropython

micropython's People

Contributors

Stargazers

Watchers

Forkers

jrmhaig markshannon llawall willingc melissa-mccoy frankcash larryhastings foobacca funkyhat dpgeorge dsmclaughlin martinohanlon inglesp hjwp tomviner nathanator nceder marcotranchino ncoghlan zitterbewegung minigirlgeek c0d3st0rm corinnewelsh paulegan andreagrandi eaglestone sanyaade-iot samhandev moreati vlee489 helenst damianburrin stephenkyle-arm ziyad2 neon22 carlosperate groklearning pddring jessingrass qatalyst tcervo c-mart reggied matt-land octaflop vivianepons asagin commandercoder rhys101 tiran bfayers avdn steveamor markbasham sigvartmh tannewt phil-cole adamchainz garym chozabu calliope-mini lolo2580 virtualabs titimoby openroberta zeth peconia techtabor shenki hickford tsukasa-au microbitvn decolnz vkollo davidsoloman stestagg sparkfun robotonics visualeditornl jagruthp doanminhdang hanshenrikjeppesen tpyboard jilljenn alfiehughes meet-microbit-project jasonrandrews perpertuallearner blue-design dailinyang uincore wizardbynight anslzo pythonrobots jimmo dsrc12 wxzed dfrobot minoruinachi strmor2

micropython's Issues

Make series of build-in images easier to use

Right now we have two series of images in microbit.Image, clock faces and arrows, and they all have names like CLOCK11, which makes it awkward to access them automatically based on a value of a varibale, or to iterate over them.

It would be nice to have some way of refering to those collections by the collection name and the number in sequence, or, in case of arrows, maybe even name of of the direction as a string.

Perhaps it would be also nice if we could refer to all the other build-in images through a string with their name.

Create a choose function

Many games that kids make require randomly choosing something from a collection. We should make this easy for them to do by implementing something akin to Python's own random.choice function.

Something like the following straw man perhaps..?

microbit.choose takes a collection and returns a randomly selected item therein (or key, in the case of a dict).

Why not choice? Because choose will sit in the microbit namespace and microbit.choose (i.e. let the microbit choose) feels more natural to read than choice (to my eyes at least). Also, choose is imperative.

dir() doesn't list instance attributes

If you run this code:

class A:
    def __init__(self):
        self.x = 3

a = A()
dir(a)

You will get:

['__qualname__', '__module__', '__init__']

while I would expect:

['__qualname__', '__module__', '__init__', 'x']

cstddef: No such file or directory

I'm trying to compile the latest master on Ubuntu, following the instructions from README, and I stumbled upon this problem:

(micropython)sheep@ghostwheel:~/x/micropython$ yt target bbc-microbit-classic-gcc-nosd
(micropython)sheep@ghostwheel:~/x/micropython$ yt up
info: get versions for bbc-microbit-classic-gcc-nosd
info: get versions for mbed-gcc
info: get versions for mbed-classic
info: get versions for ble
warning: Using head of "master" branch for "ble", not a tagged version
info: update outdated: [email protected] -> ble@master from GitHub lancaster-university/BLE_API
info: download ble@master from GitHub lancaster-university/BLE_API
info: get versions for ble-nrf51822
warning: Using head of "master" branch for "ble-nrf51822", not a tagged version
info: update outdated: [email protected] -> ble-nrf51822@master from GitHub lancaster-university/nRF51822
info: download ble-nrf51822@master from GitHub lancaster-university/nRF51822
info: get versions for microbit-dal
warning: Using head of "master" branch for "microbit-dal", not a tagged version
info: update outdated: [email protected] -> microbit-dal@master from GitHub lancaster-university/microbit-dal
info: download microbit-dal@master from GitHub lancaster-university/microbit-dal
(micropython)sheep@ghostwheel:~/x/micropython$ yt build
info: generate for target: bbc-microbit-classic-gcc-nosd 0.1.2 at /home/sheep/x/micropython/yotta_targets/bbc-microbit-classic-gcc-nosd
GCC version is: 4.9.3
-- Configuring done
-- Generating done
-- Build files have been written to: /home/sheep/x/micropython/build/bbc-microbit-classic-gcc-nosd
[6/249] Building CXX object ym/mbed-cl...mbed-classic.dir/common/BusInOut.cpp.o
FAILED: /usr/bin/arm-none-eabi-g++   -fno-exceptions -fno-unwind-tables -ffunction-sections -fdata-sections -Wall -Wextra -fno-rtti -fno-threadsafe-statics -mcpu=cortex-m0 -mthumb -D__thumb2__ -Os -g -gdwarf-3 -DNDEBUG -Igenerated/include -I/home/sheep/x/micropython -I/home/sheep/x/micropython/yotta_modules/mbed-classic -I/home/sheep/x/micropython/yotta_modules/ble -I/home/sheep/x/micropython/yotta_modules/ble-nrf51822 -I/home/sheep/x/micropython/yotta_modules/microbit-dal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/api -I/home/sheep/x/micropython/yotta_modules/mbed-classic/hal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/TARGET_NRF51_MICROBIT -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/crc16 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/scheduler -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/util -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/s130_nrf51822_1_0_0 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/s110_nrf51822_8_0_0 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/TOOLCHAIN_GCC_ARM -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/TOOLCHAIN_GCC_ARM/TARGET_MCU_NRF51_16K_S110    -DTOOLCHAIN_GCC -DTOOLCHAIN_GCC_ARM -DMBED_OPERATORS -DNRF51 -DTARGET_NORDIC -DTARGET_M0 -D__MBED__=1 -DMCU_NORDIC_16K -DTARGET_NRF51_MICROBIT -DTARGET_MCU_NORDIC_16K -DTARGET_MCU_NRF51_16K_S110  -DTARGET_NRF_LFCLK_RC -DTARGET_MCU_NORDIC_16K -D__CORTEX_M0 -DARM_MATH_CM0 -DNO_BLE -include "/home/sheep/x/micropython/build/bbc-microbit-classic-gcc-nosd/yotta_config.h" -w -MMD -MT ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/BusInOut.cpp.o -MF ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/BusInOut.cpp.o.d -o ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/BusInOut.cpp.o -c /home/sheep/x/micropython/yotta_modules/mbed-classic/common/BusInOut.cpp
In file included from /home/sheep/x/micropython/yotta_modules/mbed-classic/api/DigitalInOut.h:19:0,
                 from /home/sheep/x/micropython/yotta_modules/mbed-classic/api/BusInOut.h:19,
                 from /home/sheep/x/micropython/yotta_modules/mbed-classic/common/BusInOut.cpp:16:
/home/sheep/x/micropython/yotta_modules/mbed-classic/api/platform.h:25:19: fatal error: cstddef: No such file or directory
 #include <cstddef>
                   ^
compilation terminated.
[6/249] Building CXX object ym/mbed-cl...s/mbed-classic.dir/common/BusOut.cpp.o
FAILED: /usr/bin/arm-none-eabi-g++   -fno-exceptions -fno-unwind-tables -ffunction-sections -fdata-sections -Wall -Wextra -fno-rtti -fno-threadsafe-statics -mcpu=cortex-m0 -mthumb -D__thumb2__ -Os -g -gdwarf-3 -DNDEBUG -Igenerated/include -I/home/sheep/x/micropython -I/home/sheep/x/micropython/yotta_modules/mbed-classic -I/home/sheep/x/micropython/yotta_modules/ble -I/home/sheep/x/micropython/yotta_modules/ble-nrf51822 -I/home/sheep/x/micropython/yotta_modules/microbit-dal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/api -I/home/sheep/x/micropython/yotta_modules/mbed-classic/hal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/TARGET_NRF51_MICROBIT -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/crc16 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/scheduler -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/util -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/s130_nrf51822_1_0_0 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/s110_nrf51822_8_0_0 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/TOOLCHAIN_GCC_ARM -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/TOOLCHAIN_GCC_ARM/TARGET_MCU_NRF51_16K_S110    -DTOOLCHAIN_GCC -DTOOLCHAIN_GCC_ARM -DMBED_OPERATORS -DNRF51 -DTARGET_NORDIC -DTARGET_M0 -D__MBED__=1 -DMCU_NORDIC_16K -DTARGET_NRF51_MICROBIT -DTARGET_MCU_NORDIC_16K -DTARGET_MCU_NRF51_16K_S110  -DTARGET_NRF_LFCLK_RC -DTARGET_MCU_NORDIC_16K -D__CORTEX_M0 -DARM_MATH_CM0 -DNO_BLE -include "/home/sheep/x/micropython/build/bbc-microbit-classic-gcc-nosd/yotta_config.h" -w -MMD -MT ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/BusOut.cpp.o -MF ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/BusOut.cpp.o.d -o ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/BusOut.cpp.o -c /home/sheep/x/micropython/yotta_modules/mbed-classic/common/BusOut.cpp
In file included from /home/sheep/x/micropython/yotta_modules/mbed-classic/api/DigitalOut.h:19:0,
                 from /home/sheep/x/micropython/yotta_modules/mbed-classic/api/BusOut.h:19,
                 from /home/sheep/x/micropython/yotta_modules/mbed-classic/common/BusOut.cpp:16:
/home/sheep/x/micropython/yotta_modules/mbed-classic/api/platform.h:25:19: fatal error: cstddef: No such file or directory
 #include <cstddef>
                   ^
compilation terminated.
[6/249] Building CXX object ym/mbed-cl...lassic.dir/common/FileSystemLike.cpp.o
FAILED: /usr/bin/arm-none-eabi-g++   -fno-exceptions -fno-unwind-tables -ffunction-sections -fdata-sections -Wall -Wextra -fno-rtti -fno-threadsafe-statics -mcpu=cortex-m0 -mthumb -D__thumb2__ -Os -g -gdwarf-3 -DNDEBUG -Igenerated/include -I/home/sheep/x/micropython -I/home/sheep/x/micropython/yotta_modules/mbed-classic -I/home/sheep/x/micropython/yotta_modules/ble -I/home/sheep/x/micropython/yotta_modules/ble-nrf51822 -I/home/sheep/x/micropython/yotta_modules/microbit-dal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/api -I/home/sheep/x/micropython/yotta_modules/mbed-classic/hal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/TARGET_NRF51_MICROBIT -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/crc16 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/scheduler -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/util -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/s130_nrf51822_1_0_0 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/s110_nrf51822_8_0_0 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/TOOLCHAIN_GCC_ARM -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/TOOLCHAIN_GCC_ARM/TARGET_MCU_NRF51_16K_S110    -DTOOLCHAIN_GCC -DTOOLCHAIN_GCC_ARM -DMBED_OPERATORS -DNRF51 -DTARGET_NORDIC -DTARGET_M0 -D__MBED__=1 -DMCU_NORDIC_16K -DTARGET_NRF51_MICROBIT -DTARGET_MCU_NORDIC_16K -DTARGET_MCU_NRF51_16K_S110  -DTARGET_NRF_LFCLK_RC -DTARGET_MCU_NORDIC_16K -D__CORTEX_M0 -DARM_MATH_CM0 -DNO_BLE -include "/home/sheep/x/micropython/build/bbc-microbit-classic-gcc-nosd/yotta_config.h" -w -MMD -MT ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/FileSystemLike.cpp.o -MF ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/FileSystemLike.cpp.o.d -o ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/FileSystemLike.cpp.o -c /home/sheep/x/micropython/yotta_modules/mbed-classic/common/FileSystemLike.cpp
In file included from /home/sheep/x/micropython/yotta_modules/mbed-classic/api/FileSystemLike.h:19:0,
                 from /home/sheep/x/micropython/yotta_modules/mbed-classic/common/FileSystemLike.cpp:16:
/home/sheep/x/micropython/yotta_modules/mbed-classic/api/platform.h:25:19: fatal error: cstddef: No such file or directory
 #include <cstddef>
                   ^
compilation terminated.
[6/249] Building CXX object ym/mbed-cl...assic.dir/common/LocalFileSystem.cpp.o
FAILED: /usr/bin/arm-none-eabi-g++   -fno-exceptions -fno-unwind-tables -ffunction-sections -fdata-sections -Wall -Wextra -fno-rtti -fno-threadsafe-statics -mcpu=cortex-m0 -mthumb -D__thumb2__ -Os -g -gdwarf-3 -DNDEBUG -Igenerated/include -I/home/sheep/x/micropython -I/home/sheep/x/micropython/yotta_modules/mbed-classic -I/home/sheep/x/micropython/yotta_modules/ble -I/home/sheep/x/micropython/yotta_modules/ble-nrf51822 -I/home/sheep/x/micropython/yotta_modules/microbit-dal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/api -I/home/sheep/x/micropython/yotta_modules/mbed-classic/hal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/TARGET_NRF51_MICROBIT -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/crc16 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/scheduler -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/util -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/s130_nrf51822_1_0_0 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/s110_nrf51822_8_0_0 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/TOOLCHAIN_GCC_ARM -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/TOOLCHAIN_GCC_ARM/TARGET_MCU_NRF51_16K_S110    -DTOOLCHAIN_GCC -DTOOLCHAIN_GCC_ARM -DMBED_OPERATORS -DNRF51 -DTARGET_NORDIC -DTARGET_M0 -D__MBED__=1 -DMCU_NORDIC_16K -DTARGET_NRF51_MICROBIT -DTARGET_MCU_NORDIC_16K -DTARGET_MCU_NRF51_16K_S110  -DTARGET_NRF_LFCLK_RC -DTARGET_MCU_NORDIC_16K -D__CORTEX_M0 -DARM_MATH_CM0 -DNO_BLE -include "/home/sheep/x/micropython/build/bbc-microbit-classic-gcc-nosd/yotta_config.h" -w -MMD -MT ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/LocalFileSystem.cpp.o -MF ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/LocalFileSystem.cpp.o.d -o ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/LocalFileSystem.cpp.o -c /home/sheep/x/micropython/yotta_modules/mbed-classic/common/LocalFileSystem.cpp
In file included from /home/sheep/x/micropython/yotta_modules/mbed-classic/api/LocalFileSystem.h:19:0,
                 from /home/sheep/x/micropython/yotta_modules/mbed-classic/common/LocalFileSystem.cpp:16:
/home/sheep/x/micropython/yotta_modules/mbed-classic/api/platform.h:25:19: fatal error: cstddef: No such file or directory
 #include <cstddef>
                   ^
compilation terminated.
[6/249] Building CXX object ym/mbed-cl...ed-classic.dir/common/SerialBase.cpp.o
FAILED: /usr/bin/arm-none-eabi-g++   -fno-exceptions -fno-unwind-tables -ffunction-sections -fdata-sections -Wall -Wextra -fno-rtti -fno-threadsafe-statics -mcpu=cortex-m0 -mthumb -D__thumb2__ -Os -g -gdwarf-3 -DNDEBUG -Igenerated/include -I/home/sheep/x/micropython -I/home/sheep/x/micropython/yotta_modules/mbed-classic -I/home/sheep/x/micropython/yotta_modules/ble -I/home/sheep/x/micropython/yotta_modules/ble-nrf51822 -I/home/sheep/x/micropython/yotta_modules/microbit-dal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/api -I/home/sheep/x/micropython/yotta_modules/mbed-classic/hal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/TARGET_NRF51_MICROBIT -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/crc16 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/scheduler -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/util -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/s130_nrf51822_1_0_0 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/s110_nrf51822_8_0_0 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/TOOLCHAIN_GCC_ARM -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/TOOLCHAIN_GCC_ARM/TARGET_MCU_NRF51_16K_S110    -DTOOLCHAIN_GCC -DTOOLCHAIN_GCC_ARM -DMBED_OPERATORS -DNRF51 -DTARGET_NORDIC -DTARGET_M0 -D__MBED__=1 -DMCU_NORDIC_16K -DTARGET_NRF51_MICROBIT -DTARGET_MCU_NORDIC_16K -DTARGET_MCU_NRF51_16K_S110  -DTARGET_NRF_LFCLK_RC -DTARGET_MCU_NORDIC_16K -D__CORTEX_M0 -DARM_MATH_CM0 -DNO_BLE -include "/home/sheep/x/micropython/build/bbc-microbit-classic-gcc-nosd/yotta_config.h" -w -MMD -MT ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/SerialBase.cpp.o -MF ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/SerialBase.cpp.o.d -o ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/SerialBase.cpp.o -c /home/sheep/x/micropython/yotta_modules/mbed-classic/common/SerialBase.cpp
In file included from /home/sheep/x/micropython/yotta_modules/mbed-classic/api/SerialBase.h:19:0,
                 from /home/sheep/x/micropython/yotta_modules/mbed-classic/common/SerialBase.cpp:16:
/home/sheep/x/micropython/yotta_modules/mbed-classic/api/platform.h:25:19: fatal error: cstddef: No such file or directory
 #include <cstddef>
                   ^
compilation terminated.
[6/249] Building CXX object ym/mbed-cl...iles/mbed-classic.dir/common/SPI.cpp.o
FAILED: /usr/bin/arm-none-eabi-g++   -fno-exceptions -fno-unwind-tables -ffunction-sections -fdata-sections -Wall -Wextra -fno-rtti -fno-threadsafe-statics -mcpu=cortex-m0 -mthumb -D__thumb2__ -Os -g -gdwarf-3 -DNDEBUG -Igenerated/include -I/home/sheep/x/micropython -I/home/sheep/x/micropython/yotta_modules/mbed-classic -I/home/sheep/x/micropython/yotta_modules/ble -I/home/sheep/x/micropython/yotta_modules/ble-nrf51822 -I/home/sheep/x/micropython/yotta_modules/microbit-dal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/api -I/home/sheep/x/micropython/yotta_modules/mbed-classic/hal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/TARGET_NRF51_MICROBIT -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/crc16 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/scheduler -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/util -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/s130_nrf51822_1_0_0 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/s110_nrf51822_8_0_0 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822 -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/TOOLCHAIN_GCC_ARM -I/home/sheep/x/micropython/yotta_modules/mbed-classic/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/TOOLCHAIN_GCC_ARM/TARGET_MCU_NRF51_16K_S110    -DTOOLCHAIN_GCC -DTOOLCHAIN_GCC_ARM -DMBED_OPERATORS -DNRF51 -DTARGET_NORDIC -DTARGET_M0 -D__MBED__=1 -DMCU_NORDIC_16K -DTARGET_NRF51_MICROBIT -DTARGET_MCU_NORDIC_16K -DTARGET_MCU_NRF51_16K_S110  -DTARGET_NRF_LFCLK_RC -DTARGET_MCU_NORDIC_16K -D__CORTEX_M0 -DARM_MATH_CM0 -DNO_BLE -include "/home/sheep/x/micropython/build/bbc-microbit-classic-gcc-nosd/yotta_config.h" -w -MMD -MT ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/SPI.cpp.o -MF ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/SPI.cpp.o.d -o ym/mbed-classic/existing/CMakeFiles/mbed-classic.dir/common/SPI.cpp.o -c /home/sheep/x/micropython/yotta_modules/mbed-classic/common/SPI.cpp
In file included from /home/sheep/x/micropython/yotta_modules/mbed-classic/api/SPI.h:19:0,
                 from /home/sheep/x/micropython/yotta_modules/mbed-classic/common/SPI.cpp:16:
/home/sheep/x/micropython/yotta_modules/mbed-classic/api/platform.h:25:19: fatal error: cstddef: No such file or directory
 #include <cstddef>
                   ^
compilation terminated.
ninja: build stopped: subcommand failed.
error: command ['ninja'] failed

Inconsistent behavior of PWM

The PWM output from microbit behaves really strangely. I recorded a video to show it:
https://www.youtube.com/watch?v=bG1xZdq2iX8

(The servo is a continuous-rotation servo, which rotates one way when the signal is below 1500µs, and the other way when it's above.)

I don't have a logic analyzer or an osciloscope to actually see what is happening with the signal, but I'm quite sure this is not right.

Right after setting the PWM period to 20 (which should correspond to 50Hz, which is what the servo expects) and doing write_analog(120), the servo starts to rotate, however, the direction is wrong. Repeating write_analog() has no effect. Now, if I set the period again, to the same value, and call write_analog(120) again, the servo stops, does several hiccups and starts rotating correct way. Repeated write_analog(120) sometimes result in the servo reversing its direction...

Document and implement a simple microbit.game api

Based upon the excellent work started here:

https://bitbucket.org/larry/microbit_game

Documentation branch started with this file:

https://github.com/bbcmicrobit/micropython/blob/game-api-docs/docs/game_api.rst

import love no longer works

To recreate, in the REPL type, import love and the same incorrect random pattern appears and freezes the device. I guess this is because Image has changed. :-/

Add a music module

It should be possible to make sweet music using MicroPython on the micro:bit.

To this end there should be a music namespace containing the simplest yet most helpful functions needed to make this work.

Furthermore, we'll need to define an easy-to-understand DSL for kids and teachers to use for specifying notes.

Finally, it would be wonderful if such interactions could be optionally allowed to run in the background (in a similar way to the display.animate method).

Create a built in tutorial

TL;DR the world's simplest tutorial and perhaps a good place to start for teachers. These should be as simple as possible. For example:

>>> import tutorial
Welcome to the built in tutorial!

There are 6 lessons:

0 - How to use MicroPython
1 - Using the display
2 - Buttons
3 - Moving the micr:obit
4 - Input/Output
5 - Advanced stuff

tutorial.show(0) displays the first lesson.
tutorial.list() displays this message again.
>>> tutorial(0)
How to use MicroPython

... some text no wider than 79 characters or longer than 20 lines ...

There should be a secret lesson 6 (top secret cool stuff) that is only referenced at the end of lesson 5. ;-)

How to use MicroPython - a simple introduction to the REPL, Python and the micro:bit.
Using the display - scrolling text and showing images.
Buttons - waiting for input and reacting as a result.
Moving the micro:bit - using the compass and accelerometer
Input/Output - plugging things in via the pins
Advanced stuff - animations and making sounds
Top secret cool stuff - all about the Easter eggs and where to find out more

More built-in musical fragments

Musical cues that can be used in games and other applications:

Add doxygen developer docs

As I was walking through the code base, I created a Doxyfile to use with doxygen for creating documentation overviews of the code and its structure. I thought others might find it helpful or we may wish to add to the documentation.

microbit.display.print() easy to confuse with build-in print()

Maybe I'm paranoid, but we are setting the kids up for mistakes here.

First of all, we are introducing a function that is named the same as a build-in global function in Python. That means that whenever a teacher or a book mentions "print", there will be some confusion as to which print is meant, especially in spoken communication.

Second, we have two functions with the same name, but completely different parameters and functions. Python's print only accepts strings, and not images, and doesn't have a "delay" parameter. The display.print draws images and doesn't accept any of standard Python parameters for print. This seems like a small deal, but if you litter the language and libraries with such small inconsistencies, you get PHP -- that is, a language that takes considerable effort to learn and use properly, but is easy to use improperly.

I'm not sure what can actually be done at this point, it may be too late.

Optimise use of DAL to handle large uPy stack

uPy uses a lot of stack due to the VM, exception handlers and Python state. A typical Python function call takes about 240 bytes. So a 4-deep call will be about 1k on the stack. The DAL fiber scheduling needs to swap the stack to the heap, and this will cause out-of-memory errors because the heap is only 2k big and half of it is already used by other things.

We need to optimise the use of the DAL so that the stack of the uPy fiber is never swapped.

Document the correct way to callibrate the compass

Apparently, the correct way to calibrate the compass is to turn it flat on the spot (without tilting it otherwise that will add inaccuracies). We should document this in an obvious place.

Math module not available

I know that the microbit is limited in memory and excluding the math module probably lets shave off quite a bit of it, but I wonder if it's not too much. In particular, I think the basic trigonometry functions (sin, cos, tan, asin, acos, atan, atan2) and the square root function (sqrt) would be particularly useful. Yes, I know you can use the pow() or ** operator with fractional arguments, but still...

Is there any chance to have at least a part of the math module enabled?

Include package list for Fedora?

I think that Fedora (should you wish to play the "documenting multiple distros" game) has the appropriate GCC available in it's repos as arm-none-eabi-gcc-cs and arm-none-eabi-gcc-cs-c++ meaning that the packages required for can be installed via:

$ sudo dnf install cmake ninja-build srecord arm-none-eabi-gcc-cs arm-none-eabi-gcc-cs

In addition, the python3-cryptography and python3-cffi packages are needed to allow the pip3 install yotta to complete without any native code compilation steps. (Yotta GitHub checkouts appears to fail on Python 3 on my machine but that's a separate issue.)

I can't fully test this locally since a) I'm not NDA-blessed meaning that I can't clone the DAL and b) although being in Cambridge I'm probably minutes away from the nearest micro:bit, I don't have one to hand :). Otherwise, I'd have opened a PR for the README.

Add Bluetooth Low Energy (BLE) capabilities to MicroPython

Because the BLE stack takes up too much RAM for MicroPython to be able to compile scripts to byte code Damien has a plan:

If the script requires BLE when the device restarts immediately after flashing it will compile the Python script to byte code (without BLE on) and store the result in flash.
It will then restart the device and execute the byte code with BLE on.
The REPL will not be available in this mode.

Create built in image effects.

Pass in a single image and get back a list of images to animate a referenced effect:

sparkle - active pixels in the original image are dimmed / brightened in a random fashion.
throb - the throbbing effect seen when you import love
Wipe effects - the image fades in from the specified direction, until all the pixels are fully on:
- wipe_left
- wipe_right
- wipe_up
- wipe_down
radar - a circular motion is created using the active pixels and a rotating "bar" of bright pixels that gradually dim to darkness.
Fade in/out - the whole image fades in / out to / from dark to bright:
- fade_in
- fade_out

Perhaps these functions could live under microbit.display.fx..? E.g.

>>> twinkle_happy = display.fx.sparkle(Image.HAPPY)
>>> twinkle_happy
[ ... a shortish list of Image objects ... ] 
>>> display.animate(twinkle_happy, 50)

Add capability to handle Image objects to the display.print function (as it is in the DAL).

It should be possible to do something like the following:

>>> img = Image(Image.HAPPY)
>>> display.print(img)

This would bring our print method in line with that in the DAL.

More descriptive error messages

It may not be possible to do anything about this, however I feel like the following could be confusing for an eleven year old.

To an eleven year old, the following might seem like a sensible thing to do:

>>> import microbit.display
...or
>>> from microbit.display import animate

The same thing would happen if they did this, which would also seem like a sensible thing to do to an eleven year old:

>>> from microbit.io import P0

However, when they do this, they get the following error message, which doesn't actually describe what's going on:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: no module named 'microbit'

I think that in general we may be able to do something about more helpful error messages, however we obviously don't want to deviate too far from what cpython or micropython would say under the same circumstances.

Rationalise the display API.

Currently, to show an image, series of images or a string we have the following:

display.show(string, delay=400) # prints the string to the display one character at a time
display.show(image, delay=400) # shows the image on the screen.
display.scroll(string, delay=400) # scrolls a string across the display (more exciting than display.print)
display.animate(image, delay, stride, start, wait=True, loop=False)
display.animate(iterable, delay, wait=True, loop=False)

There is some overlap between these and it is not always obvious which to use. The current interface is also inconsistent. display.show() doesn't take keyword arguments, but display.animate does, even though both take delay. display.show("X", 500) shows "X" forever. display.show("XX", 500) shows "X" for a second.

I propose to the following API:
Keep only display.show() and display.scroll().

display.show(image, delay=0, wait=True, loop=False, clear=False)
display.show(iterable, delay=400, wait=True, loop=False, clear=False)
display.scroll(string, delay=400)

The new version of display.show() should operate as animate does now and would take an iterable of images and/or single characters and display them sequentially. The single image variant would differ only in the default value for delay. Since strings are already sequences of single characters, we don't need to treat them specially.

display.show will take all the optional arguments that animate does now. The compulsory delay argument of animate would become optional and a sensible default provided. display.show will also gain a new optional parameter clear which would default to False and determine whether the display should be cleared at the end of the iteration.

display.scroll() would continue to work as it does now, creating a special iterator that is passed to display.show(): display.scroll = lambda txt: display.show(scroller(txt)).

This API change would entail some loss of functionality as display.animate(image, delay, stride, start, ...) will be gone. I don't see this as a problem as it can be easily reimplemented using display.show and Image.crop. In fact, it might make a nice example to do just that.

Help text is longer than 25 lines

We want the help text to be minimal and fit on a small terminal screen (eg 25 lines).

We can shorten the current help text and provide pointers to further places to look for help.

One way of doing this is allow the user to type help('some_topic') and then it prints specific help for that topic. The main help would tell you what topics are available. This is how CPython works.

Eg we could have help('modules') to list available modules (same as CPython). And help('demo') to list some quick demo scripts.

Consider some form of event handling execution model

The excution model for uPy on the microbit is currently a single thread executing with full control. There are idle and system "threads" behind the scenes, but these are used to update low-level things like the display and are not exposed to the Python API (except as background animations).

TD has event handlers for things like button presses, and there have been requests for such things in uPy. Eg:

def click_handler():
    print("you clicked the button!")
button_a.onclick(click_handler)

A "click" is defined as a short press down and release of the button. It's not easy to write a polling loop to detect a click event, and even more difficult to do other things while checking for such a click (basically you need to write your own cooperative scheduler).

There are a few ways I can think to make the above code work. They vary significantly in complexity and use.

Simple events
Queue events in the background and expose them using simple methods. Eg: button_a.was_clicked() -- this will check to see if the button was clicked since the last time this function was called. If it was then it returns True and resets the event state. Otherwise it returns False. In this case there are no event handlers, it's really just polling (but polling for button events, not simple button status).

Explicit event handler
Allow event handlers to be registered but force the user to periodically execute an "event check and handle" function. Eg:

def click_handler():
    print("you clicked the button!")
button_a.onclick(click_handler)

while True:
    microbit.event_handler() # check for pending events and execute the handlers if needed
    # do other stuff

This is cooperative "multitasking". It makes the user aware that they need to do something special to get the event handlers to run, and gives control to the user when such callbacks are executed.

Interrupt-like handler
Allow event handlers to be registered and execute them like an interrupt (or Linux signal): when the event fires a short time later the main thread is paused and execution is passed to the relevant event handler. Only when the event handler is finished does execution return to the main thread. (The event handler would execute on the same stack as the main thread and no task switching is needed.)

This leads to less problems with data locking and deadlocks, but does expose a degree of preemptive issues to the kids. Eg an event handler can modify a list that you are currently iterating through.

Technically this scheme would be implemented by the VM periodically checking for pending events and pausing the current bytecode when an event comes up. That means event handling can't preempt a C/C++ function, but I think that's a good thing (keeps things simpler) and don't think it'll be a problem since all C/C++ functions eventually return (except panic!).

Full monty
Have actual threads that execute concurrently. This is way too complex (for the kids, and for us to implement), and I don't think we even need the power/flexibility that this offers.

Please raise your opinion on this very interesting topic!

Add lots of built-in images

We already have a built-in heart image (actually 2 images for animation) accessed via microbit.Image.HEART. @ntoll suggests to add more (and I agree!), such as:

They come as read-only strings, eg:

print(Image.HAPPY)
'0,1,0,1,0\n0,0,0,0,0\n1,0,0,0,1\n0,1,1,1,0\n0,0,0,0,0'

to be used as:

img = Image(Image.HAPPY)
display.scroll(img)

The reason you need to create the image from the string is because the built-in images need to be stored in flash, and so can't be pre-created MicroBitImage objects (otherwise lots of RAM would be wasted on potentially unused images). One way around this (ie to precreate actual image objects instead of strings) is to make a MicroBitConstantImage object that can't be changed. Then one can simply do:

display.scroll(Image.HAPPY)

Implement I2C

I2C exists in the DAL, it just needs uPy bindings.

Kalman filter

The micro:bit has both a compass and an accelerometer build-in, and they can be both used to asses the orientation of the board in space. However, the output of those devices is usually pretty noisy and difficult to use directly.

I wonder if it would make sense to include an implementation of the Kalman filter (https://en.wikipedia.org/wiki/Kalman_filter) in there, so that the two noisy inputs could be integrated into a more useful signal.

Sure, this could be done by the user, however, Kalman filter is quite hard to understand (especially for 11 year old children) and difficult to tune (there are a couple of papers on the subject, but they all admit using trial-and-error in the end). Including an already implemented and tuned filter could be a great help, and could increase the usefulness of those inputs greatly.

It's a rhombus not a diamond please can the name be changed.

What does Image.slice do?

I can guess, but it returns a type of SlicedImage which can't be displayed, has no methods and appears to be otherwise useless for kids. :-/

I'm guessing this is something that may need to be hidden from kids given that it'd cause confusion? Advice most welcome!

(Context: I'm documenting the undocumented things for the help builtin function. I've had a lot of fun playing with the other methods.)

music.pitch needs to be non-blocking

See here:

https://github.com/bbcmicrobit/micropython/blob/master/source/microbit/microbitmusic.cpp#L344

error: could not locate github component "lancaster-university/microbit-dal"

Running yt up (using Python 2.7 on Linux Mint 17.2) I now get the error:

error: could not locate github component "lancaster-university/microbit-dal", either the name is misspelt, you do not have access to it, or it does not exist

Looking at the lancaster-university page on github I can't see anything similar.

Garbage in the console history after soft restart

execute some commands in the REPL
press ctrl+D to restart the REPL
press the up arrow several times to see garbage

Mangled REPL text when copy-pasting

When copy-pasting commands into the REPL over the USB serial, I get the characters echoed back in wrong order. For instance, copy-pasting those three lines, a line at a time:

import microbit
microbit.pin0.set_analog_period(20)
microbit.pin0.write_analog(20)

results in this output:

>>> ootort microbit
>>> rricro0bit.pin0.set_analog_period(20)
>>> rric_l2it.pin0.write_analog(20)

I'm using screen /dev/ttyACM0 115200 on latest Ubuntu.

Consider allowing microbit.sleep to take a float

microbit.sleep currently only accepts an integer, since the underlying DAL only accepts an integer argument.

Maybe it makes sense to allow a float and implicitly truncate it to an int?

@ntoll what is your opinion?

Decide on the global structure of the uPy API

We currently have microbit as a single top-level module that contains all DAL bindings. Eg: microbit.display, microbit.accelerometer, microbit.io.

You can do from microbit import * to have all these second-level names in your current namespace.

Do we want instead to have display, accelerometer, etc as a top-level module? Then you'd need to import each one separately.

One thing to keep it mind is that we would like to have microbit scripts be able to run unmodified on a PC, by providing a microbit.py module for the PC. If we have a separate module for each component then that's a lot of scripts, and also possibility to have a clash with existing modules (eg the io module).

Add hard_reset function?

In some cases it's useful to be able to do a hard-reset in software (eg to get a completely fresh device). The MCU may support this, and we could expose it via microbit.hard_reset().

Create Image and I2C built-in help.

When a child calls the help() function on any of the objects in the Image and i2c related aspects of the API, they get to read something short, informative and written for a reading age of 11.

Serial port communication is fragile

The UART implementation is always "ready" and thus will loose characters if it cannot keep up.
This can be illustrated by changing the default mode of uBit.display to DISPLAY_MODE_GREYSCALE
https://github.com/lancaster-university/microbit-dal/blob/master/source/MicroBitDisplay.cpp#L44
The command python tools/pyboard.py /dev/ttyACM0 examples/simple_slalom.py will then fail with seemingly random syntax errors.

@dpgeorge I can have a go at fixing this, but I suspect you might do a better job of it.
I'd be happy to review any resulting PR.

Allow display.animate to take a list of images

display.animate can currently take a single image (can have a large width > 5) and it does animation by scrolling that image across the display using a given step (step is usually 5 to show a sequence of images). (Animate and scroll are very similar. The difference is that scroll scrolls the image all the way off the display, while animate stops so the last frame is still visible (I think...).)

I think it would be nice to also allow animation using a Python list of images. This is much more flexible and powerful than having to create a single big image for an animation. It allows to compose an animation out of individual images. Eg:

animation = [Image.HEART_SMALL, Image.HEART_BIG, Image.HEART_SMALL]
display.animate(animation, delay=250, async=True, repeat=True)

Then we can provide single (5x5) built-in images and users can compose arbitrary animations very easily. Without this feature we'd need to provide (lots of) built-in animation sequences (long images), and users would have to make their own big images by pasting together lots of smaller ones. This would be terrible from a flash/RAM point of view.

If we go with the above (allow to pass a list of images to display.animate) then do we also keep the original behaviour of passing a single long image with a stride? If so then it's overloading the function a bit (but not too badly) and overloading often leads to confusing bugs.

Add was_pressed(), get_presses() and reset() methods to buttons.

Put simply, pull request #53 needs to be fixed / merged.

Add SPI?

The device supports SPI but it's not in the DAL.

Add gesture functions

We should add a simple API for accelerometer gestures, such as: shake, falling, logo_up, logo_down, facing_up, facing_down.

All of them just require sampling the accelerometer over about 1 second and looking at the data to see if the gesture occurred. That can be done asynchronously and transparent to the user, and just
accessed using simple functions.

We can make a gesture module, or have it as an object as part of the microbit module. Ie:

import gesture
print(gesture.falling())
# or
import microbit
print(microbit.gesture.falling())

There are some subtleties with the API: logo_up, logo_down, facing_up and facing_down are all "continuous" events (like a button being held down) so when you call one of these function it can return True/False if that gesture is currently occurring.

But you might miss a shake or a fall and want methods like fell and shook (or did_fall, did_shake) which return True if the device fell/shook since the last call to these functions, and then return False until the device has the gesture again. So they are not simple "read only" gestures, they are read&modify.

Is it enough to have falling and shaking and just make sure your code doesn't miss them, or do we also want did_fall and did_shake?

Investigate the situation of pull-up resistors for the I²C and SPI protocols

We don't yet know if there will be external pull-up resistors required for using the I²C and SPI protocols.
Once that information becomes available, we should update the documentation to include it.

Add temperature function?

The MCU has a temperature sensor and so does the compass. We can easily expose either or both of these as a function like microbit.temperature(). They need calibrating (they have good relative accuracy but bad absolute values) so we might also need microbit.calibrate_temperature(degrees).

Consider a simple, wired microbit-to-microbit comms protocol

It would be nice if microbits could communicate with each other. Of course there is Bluetooth, but we don't have that feature (yet...) and even if we did it would still be good to have a wired comms option. One could easily use pins to read and write high or low (ie a single bit) but it would be nice to have a way of sending and receiving arbitrary bytes.

At the physical layer it could be:

I2C, needs 3 wires: GND, SCL, SDA
UART, needs 3 wires: GND, TX, RX (or 2 if you just want one-way comms)
One-wire protocol (or a variant thereof, implemented in software), needs 2 wires: GND, SIGNAL

I would opt for one-wire, since it uses the least wires and we can use P0 and GND for it (I2C and UART require using one of the smaller pins, I think, which are difficult to access without an edge connector socket, or a soldering iron).

At the software layer (API) it could be:

comms.any() # returnns True if any waiting bytes
comms.read() # returns all waiting bytes
comms.write(buf) # sends given bytes

This is a simple as it gets. One-wire would even support multiple microbits connected to the same signal line, but without addressing it would be simple broadcast (ie everyone in a room yelling).

API documentation

We need ReadTheDocs documentation for all the aspects of the API to the same quality as that for the music namespace found here:

https://github.com/bbcmicrobit/micropython/blob/master/docs/music_api.rst

Ensure random() is truely random

There is an issue with the DAL implementation of random(). We should supply an up-stream patch to fix this.

install instructions - yotta

Following instructions in the readme.
I needed to change the line
pip3 install yotta
to
sudo pip3 install yotta
to get past permission to create directories under python3.4/dist-packages.
After change I was able to install yotta on ubuntu14.04LTS

"TypeError: Unicode-objects must be encoded before hashing" when running: yt up

I'm working through the instructions to compile MicroPython for the micro:bit, when I run yt up I get the following:

info: get versions for bbc-microbit-classic-gcc-nosd
info: get versions for mbed-gcc
info: get versions for mbed-classic
info: get versions for ble
Traceback (most recent call last):
File "/usr/local/bin/yt", line 4, in
yotta.main()
File "/usr/local/lib/python3.5/site-packages/yotta/main.py", line 239, in main
status = args.command(args, following_args)
File "/usr/local/lib/python3.5/site-packages/yotta/update.py", line 28, in execCommand
updateDeps(args)
File "/usr/local/lib/python3.5/site-packages/yotta/update.py", line 58, in updateDeps
test = update_test_deps
File "/usr/local/lib/python3.5/site-packages/yotta/lib/component.py", line 554, in satisfyDependenciesRecursive
test = test
File "/usr/local/lib/python3.5/site-packages/yotta/lib/component.py", line 349, in __getDependenciesRecursiveWithProvider
test = test
File "/usr/local/lib/python3.5/site-packages/yotta/lib/component.py", line 253, in __getDependenciesWithProvider
return (OrderedDict([((d and d.getName()) or specs[i].name, d) for i, d in enumerate(dependencies)]), errors)
File "/usr/local/lib/python3.5/site-packages/yotta/lib/component.py", line 253, in
return (OrderedDict([((d and d.getName()) or specs[i].name, d) for i, d in enumerate(dependencies)]), errors)
File "/usr/local/lib/python3.5/site-packages/yotta/lib/component.py", line 231, in satisfyDep
self.getName()
File "/usr/local/lib/python3.5/site-packages/yotta/lib/component.py", line 540, in provider
r = access.satisfyVersionByInstalling(dspec.name, dspec.version_req, self.modulesPath())
File "/usr/local/lib/python3.5/site-packages/yotta/lib/access.py", line 294, in satisfyVersionByInstalling
v = latestSuitableVersion(name, version_required, _registryNamespaceForType(type))
File "/usr/local/lib/python3.5/site-packages/yotta/lib/access.py", line 145, in latestSuitableVersion
remote_component.availableTags(),
File "/usr/local/lib/python3.5/site-packages/yotta/lib/github_access.py", line 249, in availableTags
) for t in self._getTags()
File "/usr/local/lib/python3.5/site-packages/yotta/lib/github_access.py", line 249, in
) for t in self._getTags()
File "/usr/local/lib/python3.5/site-packages/yotta/lib/github_access.py", line 163, in _createCacheKey
h.update('this is the _createCacheKey seed')
TypeError: Unicode-objects must be encoded before hashing

I'm running Linux Mint 17.2 with Python 3.5.

Image string micro-language is hard to read

Right now, when we create a new image by passing in a string, we use rows of digits, separated by newlines, and whitespace is treated the same as digit 0. This leads to code that looks like this:

image = Image("9   9\n 9 9 \n  9  \n 9 9 \n9   9")
image = Image("""\
9   9
 9 9
  9
 9 9
9   9""")

If we modified that micro-language a little, we could improve the situation. First, ignore empty lines an whitespace:

image = Image("""
    90009
    09090
    00900
    09090
    90009
""")

Maybe treat "." or some similar charcter as "0" too:

image = Image("""
    9...9
    .9.9.
    ..9..
    .9.9.
    9...9
""")

Second, treat ":" (or some miliar punctuation character) as newline:

image = Image("90009:09090:00900:09090:90009")

Finally, maybe allow lists of strings instead?

image = Image([
    "90009",
    "09090",
    "00900",
    "09090",
    "90009",
])
image = Image(["90009", "09090", "00900", "09090", "90009"])

Allow persistent storage in flash

It should be possible to use flash based persistent storage to squirrel away "stuff" between resets. Perhaps a very simple key/value store that looks like a dictionary to the end user would suffice?