| > 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. [1] http://i.imgur.com/SFTdBMt.jpg
[2] http://amzn.to/1S65zoU
[3] http://www.auctoris.co.uk/2012/07/19/gpio-with-sysfs-on-a-ra...
[4] http://www.airspayce.com/mikem/bcm2835/
[5] http://mecrisp.sourceforge.net/mecrimus-b.htm |
