Hacker News new | past | comments | ask | show | jobs | submit login
BBC Micro:bit computer now available to all for £13 (engadget.com)
112 points by neverminder on May 31, 2016 | hide | past | favorite | 42 comments



So it has leds.

Is this enough to get kids interested in computers and programming? I have the feeling that they would need something where the distance between what they can do as users and as developers is much smaller. Otherwise they still may not see it as "the same thing". The iPad will still be an opaque thing they use to consume content.

I'm coming from growing up in the 80s with a ZX Spectrum. The distance between users and developers was so much smaller - you turned on the Spectrum and landed on a BASIC interpreter. A device that "has leds" and you need to program using some IDE outside of the device fails to convey the idea that "using" and "programming" are not separate things, but different points of a continuous spectrum (pun not intended).

I'm all for demystifying programming and computers for kids. There's this false belief that kids nowadays are "so good with tech" because they're 4 and they an use an iPad, but makes kids no better at tech than using a remote control makes them good at cinematography.

Maybe what we need is more like the Spectrum Next? http://www.specnext.com

EDIT: This may be closer to what I have in mind: http://uk.kano.me/products/kano-kit


> fails to convey the idea that "using" and "programming" are not separate things

Bravo. It just makes no sense: in 1980 you could have a tiny device you could program on that device itself. In 2016, you have to use a PC with an IDE, without which it is just a brick. Where is the progress?

An interactive programming language on that phone or tablet is better.

On the other hand, this separation between using and programming is good for teaching embedded development; but the focus of that should be the surrounding tinkering: we program the device, and it fits into some context where it does something on its own as part of something else. The program isn't the whole project, and the device isn't the whole system.

It doesn't have to be either/or; an embedded device can be interactively programmable somehow.

As far as hooking up to a PC goes, there should be a dumb serial interface, which is just a way to have a better keyboard and bigger screen: but all the interaction going on within the device rather than "build image, upload, flash, reboot".


I agree with you. For a kid, this is not a computer. It is a bit of green plastic thing that blinks. You even need a "real" computer to get it do something on it.

Maybe, we can load this thing up with something that will boot up into Basic, Logo, or Pascal. All the kid have to do is connect a monitor and keyboard to it.

I grew up using an Atari 800 with a cassette tape drive connected to my TV. I switched it on and have fun coding.


> Maybe what we need is more like the Spectrum Next? http://www.specnext.com

Yet another site that shows crap all without JS enabled...

Anyways, the Ello M2 recently popped up on my RSS reader.

https://www.crowdsupply.com/knivd/ello-2m

It seems very much in tune with the early micros.


you turned on the Spectrum and landed on a BASIC interpreter. A device that "has leds" and you need to program using some IDE outside of the device

I think (not 100% sure though, but also see other comments and https://github.com/ntoll/microrepl) it can run micropython so that means you turn it on, run something to connect to it on the client and it drops you to a REPL. Not exactly the same principle as with the ZX but pretty close.


"While the BBC micro:bit has Bluetooth Low Energy (BLE) hardware it only has 16k of RAM. The BLE stack alone takes up 12k RAM which means there’s not enough room to (currently) run MicroPython.

Future versions of the device may come with 32k RAM which would be sufficient. However, until such time it’s highly unlikely MicroPython will support BLE." [1]

That's a shame. I mean, I know it can be accessed by programming the hardware directly, but for most of the kids receiving these that puts BLE out of reach, when remote sensor, remote control & mesh network type capabilities would have opened up another whole class of projects that these could have been used for.

Would another 16K of memory really have pushed the price out of range, or was this more a question of the hardware design being finalised before the software stack?

[1] http://microbit-micropython.readthedocs.io/en/latest/ble.htm...


respectfully, that's missing the point.

The beauty of the BBC Micro is the stark hardware specification -- the limits are the point. That scarcity leads to different usage, different behavior, different learning patterns.

If one wants to go poking around with modern languages, multi-tier applications, color-coding IDEs, etc. there is no shortage of modern computers available.

But instead, if one wishes to learn the fundamentals of computing, and the joys of working around the limits to extract the most performance possible, I would argue the BBC Micro is a superior choice to modern systems inherently due to the low spec.

It was a mere 40 years ago that 16kbyte of RAM was a luxury item.

IIRC, Wozniak wrote Applesoft Basic interpreter in 2k for the Apple ][ ROMs. He lost the source, re-wrote it, and saved a few bytes.

Learning assembly was a necessity for the purpose of speed and efficiency (which are often inseparable). Understanding what's happening at a low level -- all the way down to the metal -- is key. Single thread. No real OS. Flat memory model, all addressable (anyone remember the fun of self-rewriting code? or direct-memory mapped graphics or I/O ?)

I've rambled enough. Hopefully I've made a point.


> respectfully, that's missing the point.

On the contrary, it seems you have missed my point, or at least, nothing that follows that statement directly contradicts it.

Speaking of which, you state that the BBC micro:bit (the BBC Micro was a very different computer) is good for education, which I would certainly hope, since that's what it was designed for. However suggesting that teaching assembly language to 11 year olds is a good way to encourage them to explore and engage with the platform is missing the point (of the micro:bit).


High Level language statements can be easily translated to ARM assembly language(http://www.toves.org/books/arm/), easier than x86 in my opinion. 11/12 year olds should have no problem understanding it, after they've played around with the provided options for programming the micro bit. (https://www.microbit.co.uk/create-code)


scoot, I offer my apologies. You are correct -- I read too much into what you said (limitations on bluetooth due to RAM scarcity), and took off on a tangent.


I remember small machines. A PDP11 got hung and the manager called me. I thought a bit, talked him through the debugger and got him to put in a jump to avoid a check. Hit RUN and back in business! We don't do things like that anymore.


I agree that the BBC Micro would be a great learning computer. The gap between a hobby program and commercial software is small - you don't get the training wheels feeling as with some other environments. Unfortunately the Micro:bit is not self hosting and not at all a suitable replacement for the BBC Micro, in my opinion.


That would increase the price significantly since they would need to move to nordicsemis new M4 devices. And yes, 16K RAM is pretty huge by segment standards.

Your best chance is if someone can optimize the BLE stack to use less RAM. After all, people have written ipv6 stacks that need a fraction of that.


The nrf51 is available with 32K RAM, but only in combination with 256K of flash, designated with the AC suffix (AA: 16K/256K, AB:16K/128K, AC:32K/256K). The 32K chip has been shipping on Adafruit's boards for a while, and is now even shipping on some of the generic Chinese dev boards and modules, so I assume it's widely available.

I imagine the main reason for going with the cheaper chip is that micropython was a pretty late entry to the list of supported coding environments, and the hardware was probably already pretty settled before the port started. Also BLE+4K of ram is probably usable in the other official (compiled) languages, and micropython does otherwise work aside from something that's a fairly advanced feature. So it would have been a tough sell increasing the cost of every board when most students and lesson plans will never use BLE and there are other languages available if they do want it/need it.


Why does the fact it can't run micropython and BLE at the same time put BLE out of reach?


The point is you want to be able to program on the board rather than having it be useless without attaching it to a PC. For that you need both IO and an onboard compiler or interpreter.

MicroPython is right out; it would almost fit Lua, but as it is it looks like your only option for independent development would be Forth.


You can flash it over Bluetooth?


No. The point is being able to do development live without needing to upload a new image every time you want to try something new.


Nice comparison with Raspberry Pi 3 here:

http://www.trustedreviews.com/opinions/raspberry-pi-2-vs-bbc...

Their conclusion:

> As you can see, there really is no comparison between these two devices. If the Raspberry Pi 3 is a 'my first proper computer,' then the BBC Micro Bit teaches the raw building blocks of coding at the heart of it. It's even more fundamental.

> The Raspberry Pi 3 is a much more advanced and practically useful device, but if you or your kid is starting at the very beginning of your programming journey, the BBC Micro Bit looks hard to beat.


Now that the Raspberry Pi 3 has built-in Bluetooth the micro:bit is a really nice compliment to it for projects that want to use the LED matrix display, remote sensors, or the provided accelerometer/compass.

We definitely see the two platforms working hand in hand nicely for some interesting projects!

We're one of the launch re-sellers who are offering pre-order with shipping in late June: https://shop.pimoroni.com/products/microbit


Fair number of commenters here justifiably laments over Micro:bit not resembling a "real" computers despite matching and exceeding specs of ZX-Spectum and other late 70s - early 80s microcomputers. Fair enough, good point.

But consider this: we have quite a lot of those "not quite computers" a.k.a. microcontrollers around us nowadays - there is one in a washing machine, several in a car, complete with a network to talk to each other [1], etc... Many are to be found in quite unexpected places: inside an SD card [2], in every PC keyboard, in a bluetooth headset, inside your phone's touchscreen controller [3], or same phone's wifi/bluetooth chip, etc..

Would it maybe be a good thing to expose kids (and adults alike) to a general idea of having deeply embedded turing-complete devices, together with giving some hands-on experience with them?

[1] https://en.wikipedia.org/wiki/CAN_bus

[2] http://www.bunniestudios.com/blog/?p=3554

[3] http://www.atmel.com/products/touchsolutions/touchscreens/


This is staggeringly good news. My partner and I were bemoaning just a couple of months ago that kids weren't being taught enough coding in schools. We have a 15 year old family member coming to spend two weeks work experience at my software company next month and he has never written a single line of code. Given how in to computers this kid is, I feel somebody somewhere has let him down.

In the face of this problem the BBC and a bunch of commercial partners have effectively donated one million BBC micro:bits to every year 7 student in England and Wales. This means that there are now one million kids in the UK aged 11+ who at the very least understand that programming is a thing and with any luck have experimented with it.

My kid is only two but regardless I'm going to buy one of these now they're commercially available and see if I can get him to engage with it and me as we program it to do various things.

Again, this is a huge step forward for teaching kids to code...great news :) I'd love to hear if any other countries have launched similar strategies to get their children to understand programming.


Not a bad price compared to other nRF51 boards, but I wish they'd included a coin cell holder.

Btw the best way to program these (if you want to do it the 'real' way) is using Yotta.

http://yottadocs.mbed.com/tutorial/tutorial.html

You can get started really quickly:

1. Install yotta

2. Start->Run Yotta

3. mkdir mything

4. cd mything

5. yt init

6. Paste some code in source/main.cpp

7. yt target bbc-microbit-gcc

8. yt install ble

9. yt build

Then find a file called mything-combined.hex in the build directory and copy it to the mBed USB drive.

It's all very command-line based and Yotta is Python/CMake-based which is quite slow and very IDE-unfriendly. But it does work well.


I disagree. Getting started really really quickly would be

  1. sudo apt-get install gcc-arm-none-eabi
  2. make
Instead, we have this extreme tool-bloat where a tiny tiny executable is produced using python, python-setup, cmake, libffi, libssl, clang, pip and finally yotta in addition to GCC and binutils (which is really all you should need).

Can someone please explain to me this new trend of in-house tools and tool-bloat?


Ok now how do you change targets to a different board (e.g. nRF51-DK), and have the LEDs and USB serial still work with no changes?

How do you install the BLE dependencies?

How do you use apt-get on Windows?

I agree it could be easier and also agree that Python and CMake are the wrong tools for the job, but frankly apt and make would be worse.

At least they seem to have designed the module description system fairly nicely so it could potentially be rewritten with a better architecture in future.


What you mention is a board/library issue not a tool issue. But looking at how the AVR community has solved this, it is certainty solvable at "apt-get level".

Also, apt-get works just fine on Windows 10 nowadays :)

edit: For the record, there is nothing wrong with a new tool system. But adding layers of layers of complexity and dependencies to something simple just because you couldn't care to learn to do things the standard way only creates problems for you and your users.


There's also the web-based mbed IDE that is arguably simpler for a lot of people than all that command-line stuff. Looks like microbit is supported as a platform. https://developer.mbed.org/platforms/Microbit/


Until you need to debug the toolchain, or change something other than the app source code, then you're digging through a chain of:

Make > Yotta > Cmake > Ninja > GCC

I've been through this fun, and it's just not worth the fun.

On a related note, The micropython stack for the microbit is currently:

Bare metal > mBed HAL > microbit-dal > micropython_hal > micropython

so three hardware abstraction layers! and this is on a device with only 16k RAM. Now Damien did a great job on getting micropython ported so quickly, but there /must/ be a better long-term solution to the mBed/yotta approach.


> but I wish they'd included a coin cell holder.

I've seen a few reports online* mentioning this was specifically removed. Given the target market (11 year olds, many of whom are likely to have younger siblings) exposed coin cell batteries are a potential risk the BBC had to consider and chose to avoid. I do wonder what the cost of a basic plastic case would be.

* http://www.theregister.co.uk/2015/07/07/bbc_microbit_final_s...


I prepared this vagrant script to easily get it up and running in a virtual machine with just a single command and then accessing it through ssh: https://github.com/carlosperate/microbit-dev-env Hopefully other people might find it useful.


I've recently become a fan of the Adafruit Circuit Playground (https://www.adafruit.com/product/3000) they are about the same cost, have more LED and inputs (temp, sound tilt, touch) No bluetooth, but uses USB. Has a connection for a lipo battery connection. I think when the :bit was planned it would have been cool, but with the other stuff around for close to that price I think it's a miss.



Its worth looking at the website https://www.microbit.co.uk/create-code to see how it can be coded. You can choose Python and JavaScript, looks like when you download it downloads a binary which you run.

This is very different to what we're used to. For tiny programs it is great, anything non-trivial might be difficult to debug.


Espruino works nicely on these as micro python can't do Bluetooth on it.


I'm not familiar with Espruino (love the form-factor of the pico though!), but this page [1] only mentions BLE in the context of programming the device. Are you sure it has a driver / library to support the micro:bit BLE?

[1] http://www.espruino.com/MicroBit


Yes you can but it's early days so I'm sure there's more that needs work - http://www.espruino.com/Reference#NRF

Someone had to ask [further](http://forum.espruino.com/conversations/284474/#comment12898...)


Is there any normal way to code for those or are they bound to those microsoft editors like presented on their website? Maybe even arduino compatible?

I would hate to spend money and yet another windows exclusive gadget.


They're not microsoft editors, they're web editors. But you can also use micropython, try https://github.com/ntoll/mu

Gives you a REPL, but you lose Bluetooth


Available for £13 when you order 90. So you pay more than £1000!


Available for £13 when you order 1! https://shop.pimoroni.com/products/microbit


Full vendor list:

Preordering has started.

'For delivery in July'

CPC Farnell for bulk (school etc.) orders: http://cpc.farnell.com/bbc-microbit

Other stockists:

Kitronik: https://kitronik.co.uk/microbitpreorder

Pimoroni: https://shop.pimoroni.com/products/microbit

The Pi Hut: https://thepihut.com/collections/microbit

Technology Will Save Us: https://www.techwillsaveus.com/shop/microbit/

Sciencescope: https://sciencescope.uk/product/bbc-microbit


They're currently available on eBay for ridiculous prices.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: