I'm uncomfortable with being negative about it, but am I right in understanding the only display is led lights?
A long time ago I was a kid with an interest in computers and I remember what it was like and it's hard to imagine this actually being interesting to kids.
It sort of feels like it's trying so hard not to compete with other technology that it's become kind of pointless. It really should have been able to plug into a display.
I'd love to be enthused because the initiative is an awesome one but a box with lights feel like it might be missing the inspiration factor.
It would have been good if they had some sort of Lego-like ability to connect them to each other or something to encourage kids to hook them up in series and make them communicate. Heck maybe with Legos permission it should have been Lego connector compatible so it could be clipped into Lego structures.
Feels like this little device is a bit of a missed opportunity.
I just heard an interview on BBC news about this with a teenager. He said:
"You can interact with the code that you've written as opposed to just seeing it on the screen, just seeing lines of code. You actually know what it does in real life ... as opposed to something like this, just seeing it running on the screen or on TV or something"
I can sort of follow that logic. Devices like screens are so normalised now that they're considered part of the fabric of reality. Of course you could do something on a computer but it's a thing only on a computer.
I remember making things happen for the first time on a BBC Micro as a child and being incredibly excited about that. Not least because seeing things on a screen was still at least a little bit novel.
Ironically, I think that VDUs (that's what they were called at the time!) have come so far that the contemporary manifestation of novel is technologically* regressive. But so much more engaging.
EDIT: Also it's small and cheap and everyone can have one without having to contend for / carry around keyboards and screens.
EDIT 2: I thought I'd transcribe what was actually said:
"You can create animations but you can also set it up with your phone so you can press a button on the microbit it can take a picture or change to the next song and the fact that everybody else is getting it, it's not just one person, everyone's going to be learning at the same time so more people will be interested in it"
Ross:
"It's got a compass, an accelerometer. You can interact with the code that you've written as opposed to just seeing it on the screen, just seeing lines of code. You actually know what it does in real life you and you can take it round with you and wear it like this. So it's a lot more interesting a lot easier to play around with and you can see the effects of the code pretty quickly with something like this. As opposed to something like this, just seeing it running on the screen or on TV or something"
* in terms of IO, not in terms of it having an ARM chip
I agree; SMD LEDs are cheap, but it's not as if a little graphic LCD would've been hugely more expensive while providing a lot more interesting possibilities:
The word "Arduino", an interface that doesn't involve hand-soldering to a high-pitch Kapton ribbon, level shifters, neat features like RGB backlights and onboard input devices...
I'm sure an idea like this would have blown the budget but if the components were separate and could be clicked together then that would have been very interesting and novel and not competed with Raspberry pi.
How cool would it be to pool the bits with your friends and click together each component and make the components talk and do things? Battery module, accelerometer module, led light module, button module, compass module, cpu module, usb module. Want more buttons or led lights, let the kids in the school ground share and swap bits - kids love swapping.
The key would have been to come up with an open standard for module connection, seed it with some initial cheap and simple modules and let kids hook em up and third parties design more modules with different functions, all incredibly single purpose but able to talk on a common bus and share a power module.
Each school kid could get one random module, not much use on its own but when pooled with other kids they could build together. There's even http://littlebits.cc/accessories/brick-adapter
We've been working with the BBC to design the micro:bit and have begun to create loads of resources for families and teachers here; http://twsu.co/microbit.
We'll have much more in the coming months. Hope it's useful!
From TFA: "Although supplies will initially be limited to the schoolchildren qualifying for a free Micro Bit in late October, the BBC has confirmed that the computers will go on sale to others in the UK and overseas before the end of the year."
Pi is a small, full featured computer to run Linux, this is a nice self-contained computer for experimenting. What I really like about the micro:bit is that it has lots of cool stuff built in (accelerometer, compass, display, couple of buttons, wireless connectivity). It's a nice little package and I can instantly think of little projects you could do on it to experiment with children.
You can use crocodile clips or banana plugs to connect it into experiments without worrying so much about frying it. I wouldn't suggest trying that with the Pi - it has 5V pins right next to I/Os that are killed by connecting 5V. Last I heard, the general consensus amongst users seemed to be that the best way to get I/O on a Pi for educational purposes was to hook up an Arduino or compatible and use that.
I should think it'd be safe enough just to use a 40-pin breadboard breakout and a ribbon cable with a few of the pins (i.e. all the 5V out ones) not populated. That seems like it should provide all the necessary safety (because the 5V pins aren't broken out onto the breadboard, and the J8 pins are covered by the IDC connector), and be a lot cheaper and more transparent than an Arduino besides.
It's less trivial than you might think, because the Pi GPIO connector is unkeyed and someone will inevitably plug it in backwards (or worse, one row of pins over in some direction).
It's trivial enough in my usage, which involves a breadboard and a Pi that are dedicated to one another and never disconnected. I'm not sure why that isn't a feasible option for educational use; instead of issuing a naked Pi, or a Pi and an Arduino, just issue a Pi+breadboard pair, already connected together.
If you're especially worried about mishaps, and don't mind modifying hardware in ways that aren't easily reversible, you could even use adhesive to permanently fix the IDC connectors in place.
If, conversely, you don't want to permanently connect all the parts to one another, you could also clip J8 pins 2 and 4 (5VDC) and 39 (one of several ground pins), and key the Pi-side IDC connector by stuffing the matching holes with a dab of quick-set epoxy. That by itself will suffice to protect against inadvertent 5V -> GPIO shorts; if you further use a breakout cable with keyed IDC connectors (e.g. [1]), and a breadboard breakout with a shrouded, keyed header (like an old-style IDE connector), then you end up with an entirely safe system.
And, taking that last idea further, you can get the same safety benefits at minimum hardware modifications (and no irreversible mods to the Pi) if you use:
- a ribbon with keyed connectors;
- a breakout with a keyed, shrouded header, and pins 2 and 4 removed;
- and a keyed shroud, such as [2] with the shipped pins removed, press-fitted to the Pi's J8 header.
On the one hand, the keyed shrouds prevent fumble fingers from inadvertently misplugging the IDC connectors on either side; on the other, the absence of pins 2 and 4 on the breakout prevents inadvertent overvolting of GPIO pins.
(And all you need is a bit of protoboard and some solder to make the breakout, using the pins removed from [2] as the breadboard-side pins of the breakout. In fact, if you have students old enough to be trusted with soldering irons, this is not only parsimonious of materials but an excellent teaching opportunity in its own right!)
Granted, none of these solutions is entirely ideal. The point isn't to provide a one-size-fits-all; instead, I'm trying to demonstrate that there are plenty of ways to solve this problem, many of which are less expensive and more user-transparent than pairing an Arduino with each Pi.
Integration. RPI is nice, but it has a bunch of things that are off spec for the purpose (Pretty decent 3D graphics, but really painful to do GPU work on http://petewarden.com/2014/08/07/how-to-optimize-raspberry-p... and GPU programming is a bit advanced for 11 year olds anyways), and lacking things that allow a diverse book of "labs" to be done in class. Having built in sensors and outputs is critical. If a school had to outfit their computer labs (to the extent they still even have them) with extra HDMI screens for every work station it would really drive up the price of the program, and limit the ability.
This isn't supposed to be powerful, it is supposed to be an integrated tool that allows reasonably fun labs and learning sections for a diverse group of kids. You could arguably do the same with shields and arduino, but then you lose the form factor.
Consistency perhaps, a good educational tool's lifetime can be measured in decades if the teaching resources that support it are rich and well produced, so control over the base device would enable the investment into said resources.
Which I thought was the raison d'etre of the Raspberry Pi Foundation's existence (i.e. building educational resources around the Raspberry Pi), and why they have been mostly keeping to the same spec and form factor; they have frequently said that they weren't interested in competing in the arms race of Raspberry Pi clones so would have an infrequent hardware refresh interval.
This BBC + commercial partner effort seems like duplication to me, although the hardware itself may be cheaper/simpler and therefore have slightly different goals.
To me, this seems more akin to the Arduino - a small, cheap board that you can program easily from your computer so that it provides immediate feedback, such as blinking.
The Raspberry Pi is more like an experimentation platform for learning linux as well as programming on the actual device. It can blink LEDs as well of course over GPIO but my impression is that this is a bit more complicated and requires extra hardware.
I think both have their merits and they can even be used in conjunction, like using the Raspberry Pi to program the micro:bit.
> It can blink LEDs as well of course over GPIO but my impression is that this is a bit more complicated and requires extra hardware
Not really; all you need is an LED and some way of connecting it to pins on the J8 header. On the software side, working with GPIO (at least in Raspbian) is as easy as I've ever seen any implementation make it; with a couple of commands, you can expose an arbitrary set of GPIO pins as sysfs virtual files. From there, you can drive them with any scripting language, including shell, or even directly at the CLI with "echo" and "cat".
This is what makes the Pi such an excellent platform for prototyping hardware to be implemented later on a smaller, more fit-for-purpose MCU: the "time to first blinkenlight" is extremely short, and iteration from there to standalone finished device can be quite granular.
To pick a handy example off my breadboard, here's how you might take a four-digit seven-segment LED display (like a digital clock display), salvaged from a dead NordicTrack treadmill, through that process:
1. Identify LED display pins through experiment
-- The display turns out to be a rather typical common-cathode 4-digit display, with a partial 5th "digit" controlling the colon and decimals).
2. Wire up the LED display to the Pi's J8 header, so that it can be driven by GPIOs
-- My breadboard [1] has a Pi bolted to it and interfaced via a homemade breakout, but you really don't have to get that fancy; a pack of female-to-female jumpers [2] will amply suffice.
3. Expose the connected GPIOs via sysfs [3]
-- Once done, you can control them via shell scripts if you want, and many do.
4. Hack up a quick prototype in a scripting language, using the sysfs interface to control the connected device
-- In this project's case, I found that, since the LED is common-cathode and has to be scanned in order to show different values on each digit, Perl + sysfs was too slow for proper flicker-free display.
5. Translate the prototype script into a proof-of-concept C program using a native library rather than the sysfs interface to drive the GPIOs
-- I use Mike McCauley's lbcm2835 [4]; there are other options, which probably work just as well, but I found this one to best combine light weight (i.e. WiringPi wants to install binaries in my $PATH by default, and I don't want that) and comprehensive exposure of the chip's features.
6. Translate the C proof of concept into an equivalent implementation running on a microcontroller
-- When I get around to that step, I'll be doing it on an MSP430, via the TI Launchpad which you can see below the Pi in the breadboard photo. Once I have a reliable clock driver running on the MCU, it'll be time for the next step:
7. Modify the MCU firmware so that, instead of generating a clock display, it listens for commands via I2C and renders the received values on the LCD display
-- The BCM2835 can do I2C in hardware, and the Pi exposes it on J8. That'll make this task a lot easier; instead of having to bit-bang I2C on GPIO pins, I can use the hardware functionality (exposed by lbcm2835) and concentrate on the MCU-side client implementation.
-- This'll also free up a lot of GPIO pins on my Pi!
8. Move the finished design from breadboard to PCB
-- I'll probably just solder this up on protoboard instead of having a proper PCB made, because one step remains:
9. Write MSP430 firmware that uses Mecrimus-B [5] to expose a USB device interface for receiving commands from a USB host, and acts as an I2C master to drive the LED display
-- The MSP doesn't have a lot of firmware space, and Mecrimus-B takes up quite a bit of it; also, it's written in assembly, not C. Instead of trying to intertwine the LED display driver with the USB stack, it'll be easier just to run the USB stack on on MSP and the LED driver on another, interfaced via I2C, and MSP430s are cheap enough at ~$2.50/ea that using two instead of one doesn't drive the BOM up significantly for a one-off project.
As you can see, the Pi's hardware, and the library support available for it, results in a reasonably smooth effort-and-difficulty gradient throughout the process. More to the point, almost every step produces an immediately usable artifact, which is great for a self-paced teaching project, both to maintain motivation and to allow for auto-titration to level of interest.
If I'm reading the Micro:Bit right, it provides something similar, but with an even shorter "time to first blinkenlight" -- instead of needing a basic understanding of the Unix shell and the nous to wire up an LED, you just plug the Micro:Bit (and its onboard LED matrix) into a computer, load up the web IDE, and you're off and scampering.
If you don't have any computer, the pi is great. If you do, its a pain and there's lots between you, your computer you already have working perfectly well, and doing something constructive with the pi.
The PS3 at least functions as a DVD player and its remote control is bluetooth. I don't know how feasible that would be to reverse engineer, but theoretically possible...
Looks like the prior iteration would be lots easier to connect outside sensors/devices to it. The released board has some funky edge connector on it. I'm guessing there will be a huge secondary market of people selling addon's that use the connector.
I'm a Python Software Foundation (PSF) fellow working with the BBC on this. MicroPython (http://micropython.org) works on the device. Microsoft also have a TouchDevelop based offering.
The exact MCU on it is not mentioned, but I really hope it's something more open with full documentation available (i.e. not Broadcom.) AVRs are certainly quite open, but with ARM SoCs there's both; probably more closed than open.
Nordic Semi nRF51822, you can see it on the promotional materials. If I remember correctly the Bluetooth Low Energy stack is a binary blob and associated registers aren't documented but everything else is and you can in theory program it with an open source toolchain.
Edit: actually, it looks like even the radio registers may be (somewhat) documented, with enough detail that someone's written a half-completed open source BLE stack for it. This is the most open BLE chip I think I've seen.
The BBC is laying off 1,000 staff and was handed a further £650milion in budget cuts yesterday. Much as I love this project, I think it should be halted.
To be fair, as someone who has worked at the BBC, the amount of waste going on there, in terms of time, people and resources, is astronomical. 1000 people laid off, as sad as it may be, is not surprising at all.
While the BBC instigated the project, other organisations - including the chip designer ARM, Barclays Bank, Samsung, Microsoft and Lancaster University - are also providing expertise and funds to bring the scheme to fruition.
From a Wired article[0]:
We wanted this to be cheap enough to give away," Baker adds. "It's our partners that are funding this, but the funding level is because this is a very low-cost venture. We've gone for that sweet spot of 'what's the minimum we can put on there that gave the maximum benefit for the kids?'"
A long time ago I was a kid with an interest in computers and I remember what it was like and it's hard to imagine this actually being interesting to kids.
It sort of feels like it's trying so hard not to compete with other technology that it's become kind of pointless. It really should have been able to plug into a display.
I'd love to be enthused because the initiative is an awesome one but a box with lights feel like it might be missing the inspiration factor.
It would have been good if they had some sort of Lego-like ability to connect them to each other or something to encourage kids to hook them up in series and make them communicate. Heck maybe with Legos permission it should have been Lego connector compatible so it could be clipped into Lego structures.
Feels like this little device is a bit of a missed opportunity.