[latexpage]The Microchip MCP9808 is a high precision temperature sensor with an I2C interface – making it easy to interface with microcontroller or embedded Linux electronics. The chip has a very small form-factor: available as either an 8-pin DFN package – or an 8-pin MSOP package. For hobbiest purposes DFN is almost impossible to use due to the complexity of having to reflow solder under the contacts; and MSOP is quite challenging (though it can be done with care). If you want something easy to use with a breadboard however, the good folks at Adafruit can come to the rescue – as they sell the device pre-soldered to a SIP breakout board. (Also available from Makersify in the UK).
Adafruit have done a great job with these libraries and most users will be delighted that “it just works”; but I want to explore how it all works: how to actually communicate with chip directly – using I2C. This guide written from the point of view of an Arduino; but you should be able to follow along from any other device if you’re reasonably familiar with I2C and low-level coding.
Xbee modules provide a very simple way to add a wireless capability to communications on Arduino. Essentially they let you work in exactly the same way as a direct serial connection between two boards – albeit wirelessly.
It’s possible to connect Xbee’s without a shield – but given the fact that they don’t have the (standard) breadboard 0.1″ pin-pitch, this requires a special breakout board, or some custom hardware. If you’re using an Arduino, I think the shields are definitely the best way to go (and they’re pretty inexpensive).
There are a number of different types of XBee – the most notable distinction is between the original, “series 1” devices (directly using the 802.15.4 wireless protocol) and the “series 2”, ZNet 2.5 (or ZB) modules: which add an additional communications layer over the base-standard. Series 1 and series 2 devices are incompatible with each other (and cannot communicate with each other) – but they are pin compatible with each other: so for point-to-point applications, it’s possible to swap out S1 devices with S2 devices (providing you exchange both ends of the communication).
This time, we’re going to explore how to do the same thing programmatically. I’m going to walk you through developing a C library to control the GPIO – but exactly the same principles could be used in any other language.
Why C? Well, mostly because I like C. But proficiency in C is useful if you’re going to be working with embedded systems, and microcontrollers; so it’s a good language to use. I’m also picking C because there are a lot of tutorials & libraries using Python – and few (if any) working with C. None of which is to say that Python isn’t a great language (and if you don’t know it – then I highly recommend learning it too).
The Raspberry Pi (in case you’ve been living under a rock for the last six-months) is a cheap ($25) ARM Linux computer, primarily designed to be used to help teach kids to learn programming & computer science.
It’s also makes a pretty nice alternative to something like a BeagleBone, if you’re looking to play with some embedded computing technology. Whilst it’s less powerful than BeagleBone (and has less GPIO connectivity), Raspberry Pi does have a few advantages. It’s cheap, and it has an HDMI output – meaning that you can interact with it directly, without the need to ssh in from another computer.
The whole ethos of the Raspberry Pi foundation is to make the device as easy to use as possible: to encourage children (and adults!) to play with it, and learn to program. As with Arduino though, this user-friendly layer doesn’t mean that you can’t get your hands a little dirty and see what’s going on underneath.
The MintyBoost is an open-source, small form-factor, USB charger which runs on AA batteries – and lets you charge your mobile phone, tablet or other USB device, without the need for mains power or a computer. It was designed by one of the leading proponents of the open-source hardware movement, LadyAda – aka MIT Engineering graduate: Limor Fried
BeagleBone is a small, low(ish) cost, open-source Linux computer on a board – using an ARM Cortex-A8 processor running at 720 MHz, with 256 MB of RAM. Unlike an Arduino – this is a fully-fledged computer. This makes it extremely powerful – and makes it a nice device to play with, to learn about embedded Linux.
This added power and sophistication does come at a cost though: this is not (or at least not currently) a tool for complete beginners in the way that an Arduino can be. This is a Linux computer – so if you want to use it to it’s full potential, then you’d better know your way around the Linux command-line.
It runs Ångström Linux – which is a flavour of Linux specifically produced for embedded devices. It’s used as the embedded OS on a number of commercial products. Whilst this is great because it means that there are a large number of people working on keeping Ångström really up-to-date; it’s also a challenge for the hobbyist – because it is very strongly focussed on the embedded device community.
BeagleBone itself is quite a new product (it only came out a few months ago) – so although there’s quite a community around it’s big-brother (the BeagleBoard) some of the documentation for the BeagleBone is a bit patchy.
The first instruction in the getting started manual is to update the software on the board to the latest version of Ångström Linux. This posed quite a challenge, even for me – and I’ve quite a few years of Linux experience (and I’m a some-time sysadin): so it’s definitely not something for someone completely new to the command-line.
If you’re struggling with this – I do have a couple of tips, however. The instructions on the various web pages aren’t really all that well written – unless you’re already familiar with the process. Telling novice users to “Learn to use ‘dd‘ and ‘gzip‘ “ or “know which /dev/sdX or /dev/diskX is your SD card through use of ‘dmesg‘” isn’t very helpful. If you’re already familiar with these tools then this instruction adds nothing – and if you’re not: then the provided links aren’t really going to help…
The first thing that I’d recommend is that you do the update using another Linux computer. Whilst Mac OS X is just a pretty front-end for UNIX, and therefore everything should be just as easy under OS X – it didn’t really turn out to be quite that simple. I could only find the latest version of Ångström in an img.xz archive, and out-of-the-box OS X doesn’t have any tools to let you work with that format: and although adding a suitable command-line tool is quite trivial it’s one extra step that you (almost certainly) wouldn’t have to make with a Linux box.
More of a problem is the way that OS X mounts the SD card. Despite spending several hours digging about, I couldn’t actually find the device representing the SD card. Because the download is (essentially) a disk image – you need to point the archive tools at the low-level device rather than it’s mount-point in the file-system.
Anyway, the long and the short of it is that if you download the image file on a Linux system, and then run the following incantation (obviously replacing the filename with the name of the image file you just downloaded) – it’ll probably work just fine. The only caveat on that is if you have more than one physical drive on your computer – in which case you may need to change the /dev/sdb to something else).
Note the addition of the --verbose flag to the command. This is going to take quite a while (~20 minutes) to run – so it’s nice to be able to see that something is indeed happening!
Once you’re up and running the latest version of Ångström, then what?
That said, Bonescript & Cloud9 do let you very easily run some classic blink light code (the hardware / embedded equivalent of “Hello World!”)
This blinks one of the user LEDs on the board itself – and will blink an external LED driven from pin 3 on header 8 (the bottom header, if you have the board facing up, and have the ethernet port on the right).
As I say, not particularly useful – but at least it shows that everything is working!
The real power of BeagleBone is using it to control hardware from Python or C code: and coupling it with the device’s on-board web server.
So look out for a follow-up post, looking at some more interesting things to do with a BeagleBone, in the near future (just as soon as I’ve worked it all out myself!)… 🙂