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.
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.
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.
