micro:bit Missing Features

[Turgut Guneysu]

Hi John,

Any plans to implement any of these std features of micro:bit:

1. INPUT - 11 gesture detection and their C-Blocks
2. INPUT - Compass calibration and readout
3. LED - toggle LED x/y
4. LED - read on/off status of a LED position x/y
5. LED - Adjust brightness of LED position x/y
6. LED - enable LED panel on/off - since some pins share LED position control pins, this is needed to use breakout boards and pins
7. ADVANCED - Arrays or Lists
8. TEXT - Basic operations
9. GAME - Sprite concept (designating LED x/y or groups as sprite)
10. IMAGE - Ability to save 5x5 LED matrix as image and assign to a var
11. PINS / MATH - map function (VAL from LOW/HIGH to LOW/HIGH)
12. EVENTS - raising and responding to them..
    I know with the WHEN block it is possible to come close. But I am not sure if an always running WHEN block is the same as interrupt driven EVENT block ?

I know it is a long list, but I am trying to assess which environment (microBlocks or MakeCode) is better to code certain programs.

TG

‌

[John Maloney]

Thank you for this list, which I’m guessing it is a list of MakeCode features that MicroBlocks doesn’t (yet) support.

Features 7 and 8 are biggies and we’ve been working hard on them. I’m happy to say that text and list handling will be in the next release. Fixed size lists are already supported as advanced blocks; just select “show advanced blocks” from the MicroBlocks gear menu to see the “List” category. The list/string blocks will probably remain “advanced” for a little while longer since they may change as we gain experience with them.

Feature 6 may already work if you simply clear the display. I’ll check the code to make sure the LED row/column lines are not used when the display is off and the light sensor is not in use. (The light sensor uses the display as an input device.) In any case, I agree that some way to use all those pins is needed. If it already works, then it should be documented. If not, we should make it work.

Some uses cases for feature 1 may be addressed by the motion library, such as creating a step counter. You can also write a loop that detects free-fall, although it might be nice to have a block.

We may address feature 2 with a library at some point, but it’s low on the priority list right now. The compass sounds like a great feature, but in my experience it’s not a very reliable sensor, and it can be confused by large metal objects nearby. (That can be used a feature, of course. For example, I’ve heard of people using it to detect the presence or absence of a car in a parking space.) It also needs to be calibrated. Have you had good experience using it in MakeCode? Do you know of cool projects that use the compass?

We don’t have plans to implement feature 5 (adjust brightness of LED position x/y) at the moment. I’ve tried it in MakeCode and it doesn’t seem as useful as one would expect.

Features 3, 4, 9, and 10 could all be implemented as an extended LED display library. Or perhaps two libraries, one of stateful x-y plotting and one for game sprites. Have you found these features useful in MakeCode? I’d be interested in pointers to cool projects that use them.

Feature 11 is definitely useful for advanced users, but I wonder how easy it is for younger students? Perhaps it could be added as one of the “advanced math” blocks.

Feature 12 is an interesting design question. The current “when” hat is problematic because it’s easy to forget to start it, so I’m considering dropping that block in favor of an old idea from Scratch, a “forever if” block.

I don’t think there’s actually much difference in behavior between the current MicroBlocks “when” hat (which polls its condition every 10 msecs) and the MakeCode “event” mechanism, which in most cases is also polling the condition, even though the user model suggests it is driven by hardware interrupts. There might be one or two cases where they actually are using hardware interrupts, such as detecting free fall events. I’d need to look at the Lancaster DAL source code again to see which events are real interrupts and how often they are polling for the other conditions.

Re: I know it is a long list, but I am trying to assess which environment (microBlocks or MakeCode) is better to code certain programs.

A big consideration for educators, as you know, is the fact that MicroBlocks is “live”, making it faster to make changes and do experiments. This “tinkerability” makes developing code more fun and can lead to deeper student engatement and better results because it encourages ongoing testing and refinement. Liveness may make MicroBlocks a better choice even if it has fewer features.

Of course, there are some activities where MakeCode is the only option right now (e.g. using the compass feature). At our summer micro:bit Pathfinders Institute class for teachers, we encouraged the teachers to get comfortable with both MicroBlocks and MakeCode (as you already are) so they could use whichever was a better fit for a given activity.

As MicroBlocks evolves, it will be able to do more of things that currently require MakeCode. Furthermore, MicroBlocks can already do some things that MakeCode cannot. For example, it’s easy to create IoT “Things” in MicroBlocks, then make them controllable by a browser anywhere on the internet via the free, open-source Mozilla IoT Gateway software running on an Raspberry Pi.

[Turgut Guneysu]

Hi John,

Thanks a lot for your detailed response. Appreciate the fact that you took time to write this detailed potential dev. plan.

Here are my replies to some of them:

… just select “show advanced blocks” from the MicroBlocks gear menu to see the “List” category.

I did not notice this. And was pleasantly surprised. I am putting it to good use in my next coding project.

Feature 6 may already work if you simply clear the display. I’ll check the code to make sure the LED row/column lines are not used when the display is off and the light sensor is not in use. (The light sensor uses the display as an input device.) In any case, I agree that some way to use all those pins is needed. If it already works, then it should be documented. If not, we should make it work.

I did a quick test and found out the following, with an interesting side effect. CLEAR DISPLAY does not turn off the LED panel. LED panel row/column use is controlled by the following pins;
ROWs: 26, 27, 28 - ON means ROW is active, an ANALOG value means BRI level

COLs; 3, 4, 6, 7, 9, 10, 23, 24, 25 - OFF means corresponding COLS are active

What turns off the LED panel is setting Pins 26, 27, 28 to OFF.

While testing these, I also found out that if one uses ANALOG PIN commands for the ROW pins, then one gains the ability to set the BRIGHTNESS of the LEDs. Which LEDs are affected is controlled by the COL pins.

Here is a quick test pgm. Set BRI var and press reset to activate.

GP Scripts
script 50 50 {
whenStarted
local 'R-bri' 256
comment 'Activates the 3 ROWs'
analogWriteOp 26 R-bri
analogWriteOp 27 R-bri
analogWriteOp 28 R-bri
comment 'Activates corresponding LED rows'
digitalWriteOp 3 false
digitalWriteOp 4 false
digitalWriteOp 6 false
digitalWriteOp 7 false
digitalWriteOp 9 false
digitalWriteOp 10 false
digitalWriteOp 23 false
digitalWriteOp 24 false
digitalWriteOp 25 false
}

‌

Some uses cases for feature 1 ….. although it might be nice to have a block.

These GESTURES are important because the limited interaction model of the micro:bit is enhanced when one uses these to implement simple controls for the programs. 3 types of button press only go so far !

We may address feature 2 with a library at some point, but it’s low on the priority list right now. The compass sounds like a great feature, but in my experience it’s not a very reliable sensor, and it can be confused by large metal objects nearby. …..Have you had good experience using it in MakeCode? Do you know of cool projects that use the compass?

I agree with your COMPASS assessment: not very reliable. I was very surprised to find a lot of kits where micro:bit is placed vertically and totally makes the compass unreliable. As far as being affected by metal, micro:bit is usually in very close proximity to the motors in a robot project. I found these affect it significantly. Given these, the only reasonable use for it is standalone micro:bit in horizontal placement !!! Very limited indeed. I tried using it via the MAP function to limit the values to the four cardinal points and sometimes with eight points as additional in-between values; which was successful to a certain degree. However my attempts to steer a robotic car using compass was not successful at all.

We don’t have plans to implement feature 5 (adjust brightness of LED position x/y) at the moment. I’ve tried it in MakeCode and it doesn’t seem as useful as one would expect.

I am sorry to read your take on this. Again given the limited interaction with micro:bit and the limits of the LED display, this feature to is important to use in games. It can easily be used to show multiple hits on a sprite etc. However, since I have documented this feature in my above comment on LED panel, there seems to be a limited work-around, albeit cumbersome.

Features 3, 4, 9, and 10 could all be implemented as an extended LED display library. Or perhaps two libraries, one of stateful x-y plotting and one for game sprites. Have you found these features useful in MakeCode? I’d be interested in pointers to cool projects that use them.

these LED features are useful in the context of game programming. However, MakeCode only allows individual LED points as sprites, not multiples. And there is no ability to assign PROPERTIES to sprites ala SNAP! I did use this in the MakeCode version of the BREAKOUT game I wrote, and it definitely makes the coding easier. But there are workarounds. Sorry about pointers to cool projects.

Feature 11 is definitely useful for advanced users, but I wonder how easy it is for younger students? Perhaps it could be added as one of the “advanced math” blocks.

It maybe that the math concept of MAPping might be considered advanced. However, simple use in any program where acquired values need to be changed to another set of acceptable / needed values is very common and useful without the background math involved. It also comes in handy in any interaction of devices with different specs. I use it to translate compass values to cardinal directions, lists of numbers to indexed text descriptions, and Arduino, ESP8266, and ESP32 interactions with each other and micro;bit.

Feature 12 is an interesting design question. The current “when” hat is problematic because it’s easy to forget to start it, so I’m considering dropping that block in favor of an old idea from Scratch, a “forever if” block.

I don’t think there’s actually much difference in behavior between the current MicroBlocks “when” hat (which polls its condition every 10 msecs) and the MakeCode “event” mechanism, which in most cases is also polling the condition, even though the user model suggests it is driven by hardware interrupts. There might be one or two cases where they actually are using hardware interrupts, such as detecting free fall events. I’d need to look at the Lancaster DAL source code again to see which events are real interrupts and how often they are polling for the other conditions.

MakeCode also has a RUN IN BACKGROUND activity commands, however I do not know how these differ from the event driven and polled ones.

…

Here is my take on differences between dev environments like microBlocks, Scratch, Snap!, MakeCode, MindPlus etc.

When the environment is coding focused and not HW control bound (SNAP!, Scratch) then implementation differences are one of choice and more acceptable, specially if the philosophy behind is providing basic blocks and letting users dev the missing features and learn in the process.

However, when the IDE is mainly for interaction with a specific HW, then the missing support for features becomes a crucial decision point for the various platforms. As such, I find Scratch 3.0 attempt to interface to micro;bit totally inadequate. It is understandable that developing for all the HW features is a long and hard process, but selecting the platform of choice purely is a function of its current and future dev plans. I don’t mean this in a negative way.

I totally support the SNAP! and microBlocks future plans and developments. IoT focused way forward is also a big differentiator.

Thank you all (you, Jens, Bernard, Brian, and Joan, et al) for making these environments available for us users.

‌

[Turgut Guneysu]

Forgot to attach this diagram explaining PINs:

‌