Why I like the micro:bit



  • Greetings!

    I thought this would be an excellent forum for talking about why I am excited about the micro:bit.

    Let me begin by saying that I’ve worked on, or with, a little bit of just about everything - ranging from a Radio-Shack pocket computer all the way to huge mainframe systems. I’ve bought a number of the newer “maker space” items - the Arduino, Raspberry Pi, (I have at least one of each series Pi), with my latest acquisition being the micro:bit.

    Out of all of these, I find the micro:bit the most interesting and exciting. Here’s why:

    • It’s cute.
      It’s a wee bit of a board that isn’t intimidating. Other systems, like the Pi, can overwhelm and scare off the un-initiated. In contrast, the micro:bit fits in the palm of your hand, and you are encouraged to slip it into your pocket and go play without worrying about breaking it.

    • It’s complete.
      Unlike most other solutions, it can do a wide variety of things without connecting anything to it but a battery. Other systems, like the Pi, essentially require the presence of a keyboard, mouse, and monitor to be even remotely useful. Of course, the Pi can run headless, but you have to start with it connected at least two or three times first.

      In contrast, the micro:bit has (most) all of it’s I/O requirements built in. It runs “headless” by design. If a group of kids what to have fun with a micro:bit, all that’s required is the micro:bit itself, a small battery pack with two AAA cells in it, and - if they want to mess around with programming - a tablet with an OTG port and cable. All of this can be slipped into a backpack and taken to the park.

      I would hesitate to run many of the other systems with less than a 6v gell-cell and a 5v regulator if not plugged in. Taking a mouse, keyboard, and monitor to the park to mess around with your buddies isn’t an appealing idea either

    • It’s fun.
      By design it attracts attention. My two granddaughters, 10 and 8, look at my Arduino and Raspberry Pi with suspicion. In contrast, they were attracted to the micro:bit like metal filings to a magnet. Once they saw it do a few things, they wanted to know how they could make it do things too. When my oldest granddaughter programmed something simple on it, she was eager to run around and show it to everybody!

    • It’s simple.
      If I want to try something, working with the micro:bit is quick-and-easy. You don’t even need the micro:bit to do many things. (I discovered that there are certain Cyrillic letters that absolutely cannot be displayed with a 5x5 LED matrix simply by using the simulator built into the Microsoft MakeCode web development platform.)

    • it’s inexpensive.
      Even if you do manage to break it, replacements won’t break the bank. Even in Rubles, it’s just a bit more than $12 US to buy on-line. The inexpensiveness of the micro:bit encourages people to play with it without being intimidated by the potential cost of replacement if they accidentally step on it.

    • It’s fun.
      Yes, I said that before, but that is one of the main attractions of the micro:bit. It’s more like a fun game to play than a computer. I may be an old geezer, but I find myself attracted to it as much as my granddaughters do.

    What say ye?

    Jim “JR”


  • CoderDojo Foundation

    Hey Jim :)
    That’s a fairly long description, but I agree for most of it !
    We use micro:bit at our Dojo, but haven’t been able to make a use case of the Radio functions. The main reason is that we rarely have 2 kids on microbit at the same time. Would you have a recommendation for a scenario making use of those functionalities ?
    Cheers,
    G.



  • @Guillaume-Feliciano

    What parts do you disagree with, and why?



  • @Guillaume-Feliciano said in Why I like the micro:bit:

    We use micro:bit at our Dojo, but haven’t been able to make a use case of the Radio functions. The main reason is that we rarely have 2 kids on micro:bit at the same time.

    Why? Not enough kids or not enough micro:bits?

    Would you have a recommendation for a scenario making use of those functionalities?

    Assuming the scenario is not enough kids working on radio related projects, (as opposed to not enough micro:bits), have you considered switching to low-power Bluetooth? With this you need one person with a micro:bit and someone with a smartphone or a tablet, (or even a pair of headphones!). I remember seeing a “hacking your headphones” project somewhere. . . .

    Another option is to create a radio-related project, and encourage participants to bring micro:bits to participate in it. A project like this has more aspects than a cat has hair, and - handled properly - could be a real learning experience for everyone.

    I have seen several projects where one micro:bit controls the behavior of another via radio.

    One example of a project like this would be a group of micro:bits acting like “intelligent home controllers” where one micro:bit is the “master” and other micro:bits can turn on or off small fans, lights, etc.

    i.e. The micro:bit that is the “light” controller micro:bit can turn on or off it’s 5x5 array, and set it to various brightness levels based on a received command. Another can be used to run a small motor (with a suitable controller), as a fan, at varying speeds, etc. etc. etc.

    You could use the radio to develop a game that ties more than one micro:bit together to play.

    i.e. You could design and create a “Kill the Death Star” game based on Star Wars.

    Players: (each player is one person with one micro:bit)

    • A single steady dot is a "Tie-Fighter"
      At least one player should be a “Tie-Fighter”
    • A blinking dot is an Imperial Fighter that defends the Death Star.
      (I forgot what you call those things)
      At east one player should be an Imperial Fighter
    • A group of four dots is the Death Star
      One player becomes the Death Star

    Object of the game:

    • Tie-Fighter(s)
      Collide your Tie-Fighter with the Death Star to destroy it and/or collide with Imperial Fighters to destroy them
    • Imperial Fighter(s)
      Collide with Tie-Fighters to destroy them.
    • Death Star:
      Avoid collision with anything.

    Rules:

    1. Colliding a Tie-Fighter with an Imperial Fighter destroys the Imperial Fighter.
    2. Colliding an Imperial Fighter with a Tie-Fighter destroys the Tie-Fighter.
    3. Collisions between any two of the same kind of fighter destroys both.
    4. Colliding a Tie-Fighter with the Death Star destroys ALL Imperial forces and wins the game.
    5. Destroying all Tie-Fighters, (by whatever process), wins the game for the Empire.
    6. Each player moves his piece by tilting his micro:bit.

    Part of the fun for this - even for people who don’t have micro:bits - will be designing the data-structures that define the game. Obviously all the micro:bits will have to radio their state information to all the other micro:bits.

    Issues that need to be solved:

    • How big will the game grid be? (assuming it’s larger than 5x5)
    • How many micro:bits can play? (start with two, but it can grow to be more)
    • How are they going to communicate? (Using the micro:bit’s broadcast radio feature is a good idea)
    • How are they going to communicate status?
      One option would be a data-structure sent from one micro:bit to all the others identifying:
      • Who is sending
      • Who should be receiving
      • What information is being sent.
      • A potential data structure could have a single byte indicating who is sending it. A second byte indicates who should receive it, and one or more payload bytes with information. The sending and receiving bytes can be bit-mapped addresses with one bit for one of eight possible players.

    And so on.

    Obviously this is a non-trivial project that will take more than 15 minutes to complete, but it’s a great example of a project the entire Dojo can chew on - and if completed - is a shoe-in for a Coolest Projects award!

    A logical extension would be to expand this to a project on the Pi with PyGame, Ethernet packet exchange, and a graphical display with animated sprites.

    I can discuss more off-line if you wish.

    Jim “JR”


  • CoderDojo Foundation

    Heresy, you switched Tie-fighter and X-wings! :p
    Hey Jim !
    Mostly I disagree on:

    • it’s complete: as an example, I ran out of memory while compiling a snake. It may be hardware-wise covering a large scope, but the software behind still need some work. The runtime error are horrific on such a display. An emulator that, well, respect the hardware specification would be nice.
    • it’s simple: It is for us, no doubt. The blocky interface definitely helps. But I still have to explain what’s a grid is. This kind of display is certainly entertaining, but is more about “emulating” a grid than a “position-based” display ( think laptop display in scratch, you can use the x/y referential, or just drag it). I think the main issue is because we see a “similar” interface to Scratch (blockly-like), we’re tempted to think the kid’s adaptation will be straightforward : it’s not, it’s a piece of hardware :)

    Back to networking : yes, it’s a lack of kids on the same hardware at a time : we’re a small Dojo, probably by choice at that point !
    I like your Star Wars project, but I doubt I’ll get that many kids engaged. Some are way more software enthusiast than hardware, and that’s fine by me.
    My previous experiences with bluetooth was the nightmare of managing profiles, but in all fairness, that was low-level (in C, 5 years ago). My next step if I have the will would be to look into using App Inventor to see if they can interconnect easily, but I’d need to steal one of those microbits from the Dojos for an evening, which I haven’t done so far. If it works, that’d be probably nice to do some remote controlling, or a physical score counter for an app as an example :)

    PS : sorry for the late answer, went into a spiral of work before cleaning my tabs this morning



  • @Guillaume-Feliciano

    Regarding the grid-like nature of the display: Maybe I am mistaken but I believe there are Python and C/C++ calls to the display that accept coordinates with (0,0) being the upper left-hand corner.

    I’m actually sniffing around in the C/C++ side of things right now, (that is, when my right-shoulder isn’t screaming at me). I saw a demo that is a “oscilloscope-like” display of a triangular wave that rapidly scrolls across the screen. It scrolls, stops, scrolls, stops, and so on. I want to modify the demo so that it scrolls continuously - but the mechanics of the display’s bit-map is driving me insane! And I would love to find someone who could help me understand the list of ordered pairs that comprises the display bitmap in C(++).

    As far as memory limitations are concerned, a 16k system is old news for me. The GE-4020 mainframe I programmed back at Virginia Tech in 1975 was a 16k machine. The [censored!!] beast programmed in octal of all things, and I rapidly learned to despise octal, bit-packed, instruction codes. (Think PDP-8’s instruction set - a devil-spawned beast if there ever was one!)

    My next “major” system was an Atari 8-bit system with 16k. That is until I hardware-hacked a 64k upgrade.

    Back in the early 80’s, I had the task of upgrading a disk of test software for an aircraft’s fuel gauge that ran on the IBM PC in BASIC, and I had exactly one 512 byte sector left on the disk. I programmed the modification in assembler and it worked out to a minuscule 29 bytes - and fit the one single sector I had left on that disk.

    The micro:bit is unique in this crowd in that the program space is in a 256k flash region, and the 16k of RAM is the global heap.

    However, I do agree that an empty JavaScript project that has 560k of overhead, (in Intel hex), is a bit much. One of the reasons I want to look at Python/C/C++ is to be able to include only what I need for a particular project - not the entire Encyclopedia Britannica every time I compile and load.

    As far as emulators are concerned, I don’t feel I have the right to complain. Emulators are particularly nasty beasts to write, especially when the underlying hardware abstraction layer - they call it something else - is a moving target. They’re a real pain to write even when the hardware/firmware have been stable for decades.

    The thing I like about the “blocky” interface is that it lets non-coder individuals do things that make sense visually, and see immediate, (hopefully successful), results. If they have any interest/talent at all, they’ll finally get to projects where the “blocky” interface doesn’t meet their needs anymore. This is when you flip them over to a more advanced environment.


Log in to reply
 

Looks like your connection to CoderDojo Forum was lost, please wait while we try to reconnect.