Getting going with Gadgeteer

Being by way of an introduction.

For many years, I’ve amused myself by building electronic devices. By far the most entertaining for me have been those which interact with the real world. I like stuff which moves things, senses things and generally behaves as if it had some magic in it. Since the advent of cheap microcontrollers, most of these projects have involved more programming and less electronics. I’ve had a lot of fun with PIC processors, which are dirt cheap. I particularly love the PICAXE, which is a pre-programmed PIC for which you can write code in a language similar to BASIC rather than diving into assembler. My other favourite is the Propeller. It’s an amazing chip with 8 cores, programmable in a higher-level language called SPIN. I’ve also dabbled with various embedded processors from Texas Instruments (if you like gadgets, check out the eZ430 chronos) and STMicroelectronics (try the unbelievably cheap STM8S-Discovery kit). There is also Arduino , of course (I’m glossing over that, because I’ve never actually used one).

All of these are capable devices in their own niches, and if you program them down to assembly language level, you can get quite a lot of performance out of them. I don’t want to program in assembler very much. It’s painful. Fortunately, there are other options.

PICs (or PICAXEs, at least) can be programmed in PICBASIC, which is quick and easy. the development environment is nicely integrated – you edit code, press a button and it’s downloaded on to the chip and running. The downside is that the performance isn’t sparkling. A typical PICAXE device runs at 16MHz and has 512 bytes (yes bytes) of RAM. You can’t put very complex programs on it. It’s great as a controller for simple tasks, but it’s never going to, say, read messages from a serial connection, decode them and send them out over a TCP link.

Many other microcontrollers can be programmed in C (or sometimes C++). This gives a good balance of programming ease with performance. The problem I’ve always found with these is that the tools are kind of clunky. It’s usually a question of using several different tools from different sources (editor, compiler, assembler, loader…) and making them work together in sequence. It’s doable, of course, but it feels like more effort than is necessary – especially when you are used to a nice consistent IDE like Visual Studio. There’s also usually a limitation on what you can do for free. The C compiler manufacturers want you to buy their products, so when they offer a free version, it is often limited to compiling code of a certain size. I’m in favour of paying for software (especially if it’s other people buying mine) so this is perfectly reasonable, but I can’t personally (or spousally) justify spending the price of a commercial C compiler just to program a single microcontroller for a hobby project.

The Propeller can be programmed in SPIN, a language not entirely unlike BASIC, which is geared up to work with multiple processing cores. With a Propeller clocked at 80MHz containing eight cores running code, SPIN is quite fast enough for reasonably complex tasks. I’ve had it monitoring multiple serial feeds and digital inputs while simultaneously driving a VGA display from software. The propeller IDE is nice, if a little quirky, and provides for easy deployment onto the chip.

Even SPIN is relatively low level compared to languages like C#, however. I spend so much of my time writing software in the .NET framework using C#, I’d like to be able to do the same on a microcontroller I could use in my hardware projects. That’s where the .NET Micro Framework (MF) comes in. It’s a stripped-down version of the .NET framework designed to run on embedded processors with limited memory and processing power. That’s ‘limited’ compared to a PC, incidentally, but still substantially more than many microcontrollers offer. You won’t be running MF on a PIC any time soon (if you do, please tell me). The original development work for MF was done by Microsoft, but it’s now open-source so you can modify it if you want. The great thing about as far as I’m concerned is that I can use the same IDE (Visual Studio) and language (C#) to program hardware that I use to write PC software. It’s so simple to do, it almost feels like cheating.

The MF has been around a few years now, and was held back a bit in its early days by the limited hardware platforms available to it (and, let’s be honest, by the cost). This has changed of late, and there are now several choices of platform, including one based on Arduino. I’m going to ignore most of these, however, to concentrate on a kind of meta-platform called Gadgeteer .


Gadgeteer is both simple and clever. The big idea is to provide a standardised set of hardware interfaces between devices, all using the same connectors. A typical .Net MF processor board has a load of identical sockets on it, into which a range of devices can be plugged. As long as the devices (sensors, motors, and so on) conform to one of the standard interfaces and provide appropriate software drivers, you can just plug them in and go. It’s not quite as simple as that, of course. Although the sockets all conform to the same shape and size, the electrical connections within perform various different features – so each socket has one or more letters on it, and each device’s connector also has a letter. As long as you plug an ‘X’ device into an ‘X’ socket, it will work. Each device has a MF driver which exposes one or more objects with properties and methods, so you can write C# code which makes it unfeasibly easy to interact with hardware.

Hardware is half the story. The other half is the development environment, which in this case means Visual Studio. Putting together hardware components using Visual Studio is a bit like designing windows forms. You simply drag them from the toolbox onto the design surface, and draw wires between them (or let Visual Studio do it for you). The code to create the associated objects is automatically generated behind the scenes. The requisite driver libraries are automatically referenced. This leaves you to create your application by subscribing to events published by the hardware devices and manipulate their properties. It’s hard to explain just how easy this is. I’ll try, in my next post.

Leave a Reply

Your email address will not be published. Required fields are marked *