Google Coder currently changes the password of the "pi" user account to the one you enter in the web interface. If you find yourself unable to SSH or otherwise log into your Pi after following this guide, then use the password you specified for Coder and change it back with "passwd" at the command prompt.
To disable this password change, please do this in the coder/coder-base directory before running Coder:
echo "" > sudo_scripts/setpipass
If you want to set up Coder on a non-Pi linux system, you will also need to do the above. Coder doesn't appear to use the Pi account for anything, but sets it presumably for convinience in full SD-card based installs.
And now, on with the show:
You've probably heard of Google Coder, it's being pitched as a simple way to make web stuff on the Raspberry Pi. And it is! The side-by-side code and preview is great, and the clean, simple web-based IDE keeps out of your way and lets you get down to learning.
Getting Coder up and running on the Pi can be very simple, but you have to swap to a different SD card or sacrifice your existing installation to use Google's image. That's a bit of a pain if you're just interested in giving it a try, or want to test the water before you start re-imaging an SD card!
Fortunately, the quick and easy way is not the only way. Coder is just a NodeJS application, and you can get it from GitHub here: https://github.com/googlecreativelab/coder and have it up and running on your Pi or your desktop in a few minutes!
The part of Coder you're interested in is coder-base. Here you will find server.js which you can run with Node.
Running on your desktop
To get it running on your desktop PC you'll need to download NodeJS and install it. I'll be working on a Mac, so you'll have to fire up "Terminal" ( search for it in Spotlight ) to continue once you've got NodeJS installed.
First up, let's get the GitHub repository. If you've got Git set up on your system you can just:
The last step will take some time. Once npm has done its thing you need to edit config.js in your editor of choice. On the Pi you'll want to leave the IP setting as-is, but change those ports if you don't want them to conflict with an existing web server or service on your Pi. I changed mine to 8151 and 8150 respectively.
You'll see a message about generating a 2048 bit RSA private key. Be patient.
Once it's done, open up Chrome and enter: https://:8151/
Once again, I recommend this kit from Phenoptix which, if you're in the UK, will cost you £5 and not a penny more. It's what I built my Pico PiDuino with, and it's what inspired this series of tutorials in the first place!
What's covered in this article
This article will cover installing Gordon Henderson's modified AVRdude, which you'll need to flash compiled programs to your Pico PiDuino. If you're feeling brave or using a Beaglebone Black then you can also compile a modified AVRdude from source which includes a Linux SPI programming mode, and a customisable reset pin ( https://github.com/kcuzner/avrdude ).
I will also cover talking to your Pi over Serial, using jump-leads to the Pi's TX/RX. Gordon has a great little setup script to get Serial up and running, and a config file for Minicom, too. I'll also tell you how to set up your /dev/ttyAMA0 to accept echoed strings and transmit them to your PiDuino- this is easy to use in many situations, and means you don't need to worry about a Python or Ruby library just yet (I'll cover using those in a future article).
Once communication is set up, we'll look at using Arduino-mk and the Arduino IDE. I'll be focussing on writing, flashing and compiling code from the command-line using makefiles because the Arduino IDE can be a little sluggish on the Pi, and even more so if you're running headless and trying to use X forwarding. Don't worry, it's easier than it sounds.
A word on vi/vim, the text editor
I tend to use vim to edit files. Most other guides refer you to nano, but I don't use it. To install vim ( VI iMproved ) use: sudo apt-get install vim
Once installed, you can use vim to edit text files, but you'll have to get your head around the Arcane commands used in the editor first.
To go into insert mode, press "i" - you can now type content into your file. There are other ways to go into insert mode, with varying effects, for example "o" will insert a new line.
Also useful to know is that hitting "u" will undo.
If any of these commands result in text appearing in your file, you need to exit edit mode and try again.
To exit insert mode, press "esc"
To save and quit, type ":wq" ( write and quit ) when you're not in edit mode
To quit without saving, type ":q"
The first step is to install AVRdude. AVRdude is the application which will talk to your ATmega and flash your compiled programs to it. I touched upon this in my previous article, so skip ahead if you need to.
Once done, cross your fingers and verify connectivity with:
avrdude -p m328p -c gpio
Assuming everything is good, and you get a positive response from avrdude which should look something like the below, we can move on to programming.
Programming your Pico PiDuino
Now we're getting to the fun part; making your Pico PiDuino do something meaningful. If you've got 4 LEDs connected as described in my first article this means putting together a simple program to turn them on and off via Serial using the QWER and ASDF keys on your keyboard. It sounds dull, and in the grand scheme of things it is quite dull, but the basics of toggling outputs on your Microcontroller, and responding to Serial commands will help you build more interesting Pico PiDuino projects and work with more exciting hardware.
First thing's first, you need the Arduino IDE and the command-line Arduino Makefile helper installed on your Pi:
sudo apt-get install arduino arduino-mk
Next, make yourself a directory to work in:
mkdir ~/piduino cd ~/piduino
And create a makefile by saving the following into file entitled "Makefile"
ARDUINO_DIR = /usr/share/arduino BOARD_TAG = uno ARDUINO_PORT = /dev/ttyAMA0 ARDUINO_LIBS = include /usr/share/arduino/Arduino.mk
Now you're going to need something to compile. Although we're working from the command-line, we're still working with the same language you would use in the Arduino IDE; so all the tutorials are applicable. Remember, however, that we don't have an LED connected to Pin 13, but 7, 8, 9 and 10, so adjust any examples you use accordingly.
I've put together this simple variation on Blink which turns on each LED in sequence, and then turns them all off at once. If you're new to Arduino, the below code will introduce you to a few basic concepts. If you're not, just skip to the code!
The "#define LED_RED 7" allows you to define an unchanging value, which you can reference later. This is useful for assigning friendly names to obscure things like Pin assignments. So we create one constant for each pin.
The "void setup()" function is run when the ATmega first starts up, and is used for setup. "void loop()" is run as fast as the ATmega can run it, and it's where we put things that need to happen repeatedly.
pinMode sets the mode of a pin, pins can be either outputs or inputs- we want OUTPUTs to drive the LEDs and so they're all set as such.
digitalWrite writes a digital value ( either 1, or 0 a.k.a. HIGH or LOW ) to a pin. 1/HIGH means an LED will turn on, and 0/LOW means it will turn off.
delay does just that, delaying the ATmega for a given number of milliseconds.
Save this as “blink.ino” ( or wget http://pi.gadgetoid.com/piduino/blink.ino ) in your piduino folder alongside the Makefile. To compile it, you simply type “make” and wait… and wait. Compiling on the Pi takes a while, even for the simplest of Sketches; I'll have to look into omitting some of the unnecessary libraries.
The result of your flash should look something like this:
Making the ATmega blink a few LEDs is a good learning example, but it's not really useful and doesn't exploit the fact that a 3.3v powered PiDuino can talk directly to your Raspberry Pi over serial. Let's whip up a more complicated example that accepts single-character commands over serial and acts upon them. I'll do the first command - on with q and off with a - and you can try and finish off the code with the rest. Amend your blink.ino file to:
And then “make clean && make” to recompile your sketch before using your flash.sh to flash, or running “avrdude -p m328p -c gpio -e -U flash:w:build-cli/Arduino.hex”
Talking to your Pico PiDuino over serial
Once you’ve got this sketch uploaded, you should notice the Red LED blinking rapidly. I put this “Heartbeat” into the code so you could tell it had flashed successfully. Once the ATmega recieves a command the Heartbeat will stop and you should be able to toggle the LED manually with “q” for on and “a” for off.
You can do this either with Minicom or by echoing these letters to /dev/ttyAMA0 after some setup.
Which should turn the Red LED on and then off again 4 times.
I've had success programming a Pico PiDuino with the BeagleBone Black, although the setup is a little trickier, it requires Ubuntu for starters, and the pinout is a little confusing due to the Bone's many, many GPIO pins. Still, I have a guide in the works for Beaglebone Black users, so stay tuned!
I have a couple of ideas in mind for the next article in the series. Let me know via Twitter @gadgetoid which you prefer. Either committing the Pico PiDuino to perfboard, or getting some more exciting components connected.
There's little doubt that you've at least heard of Arduino if you're interested in hacking around with hardware on the Raspberry Pi.
Arduino have brought a whole variety of Atmel-based boards to the market, coupled with the easy to use Arduino IDE, in an effort to let hardware hackers, hobbyists and professional prototypers easily get up and running with Microprocessor development. Unfortunately, the official Arduino boards can be a little pricy if you're just wanting to dip your toes into the Arduino/Microprocess programming water.
The good news is that all you really need is an Atmel ATmega processor, a handful of components and a Raspberry Pi. You can pick all this up ( apart from the Pi ) for little over a fiver.
I should probably start with a disclaimer; the Arduino-compatible we're going to build in this tutorial is absolutely, totally, irresponsibly barebones. In a proper breadboard Arduino build you should have a host of capacitors to decouple your power supply, and probably at least some protection circuitry between it and your Pi. If you're at all concerned about blowing up your Pi, read no further!
Introducing the Pico PiDuino
This is the first in a series of guides detailing how to build and program an ATmega 328-based Arduino-compatible microcontroller using only your Raspberry Pi.
First, I'll will walk you through obtaining the parts and assembling what I will refer to henceforth as the Pico PiDuino.
The next guide in this series will teach you how to program it, and then talk to it over serial from the Pi.
The Pico PiDuino is a barebones Arduino-compatible, that means it works with the Arduino IDE and uses the Arduino bootloader. It's designed specifically to be connected to, and powered by the Pi - but you can program it with a USB-to-Serial breakout or power it standalone with a handful of batteries or even, with the right components, a mains adaptor.
Why learn to program an ATmega/Arduino?
Because of their flexibility and robustness, being able to program a microcontroller is a useful and rewarding skill to have, and it's fortunate that it's possible to leverage your Pi to get started quickly and cheaply with a trusty ATmega 328.
Learning to program an ATmega, or Arduino, will allow you to build much more specialist control systems which use less power, are much less complex, less prone to failure and more robust than the Pi. These are great for things that the Pi isn't necessary for.
Once you've grasped the basics and have a project in mind, you can even move on to playing with some of the brilliant official Arduino boards and all the programming skills you pick up will translate right over.
If you're wanting to produce your own product for sale, you can build your own hardware around an Arduino-compatible ATmega, program your software in the IDE and ship a finished design supporting an ATmega 328p or similar microprocessor.
It's a fun challenge for a weekend.
The bill of materials
If you're still with me, then I'm going to assume you've got a reckless and irresponsible streak and want to hook an ATmega directly to your Pi and get started as fast and cheap as possible. Enough introduction; Let's get started!
You will need:
One ATmega 328p Microproccessor, in a 28-pin, breadboard-friendly package
One 16Mhz Crystal Oscillator
4 LEDs, it doesn't matter what colour but Red, Orange, Yellow and Green look nice together
4 resistors for your LEDs, about 220 Ohm or higher
8 female-to-male jump wires for connecting your Pi to the Breadboard Arduino-compatible
4 male-to-male jump wires for wiring up the Breadboard Arduino-compatible ( or 3 jump wires and a 0Ohm resistor )
And to build it on: One 170 point breadboard, the really, really tiny one
To avoid confusion, I recommend using Red and Black wires for your Live and Ground connections and picking 8 other distinct colours, if you can, for the other connections. Connecting leads in the wrong place can have "undesired" results. To be extra-safe you should always shut down your Pi before connecting jump leads, but I'll let you in on a secret; I don't!
The best way to get most of the parts you need is the fantastically good value "Bare Bones" £5 Arduino Kit from Phenoptix. In fact that's the very kit I'm working with. It also comes with a host of protective capacitors, a reset switch and some other components for a stand-alone Arduino that you wont need for this tutorial. If you don't have jump wires then you can also pick up a pack of M/F jump wires, far more than you'll need! If you go for this kit, you'll also need to dig up 3 more LEDs ( or 4 of any type ) and 3 or 4 resistors to go with them.
Putting it together
What we're effectively building is an even more minimal version of the "Shrimp" variety of Arduino-compatible, with 4 LEDs for you to experiment with. We won't be using capacitors on the crystal (unless you feel you need to), or the reset capacitor or pull-up resistor; it's quicker and easier to omit these until you need to use your mini Arduino for something other than tinkering. In my experience, my Pi didn't agree with having a pull-up resistor on the reset line and trashed its SD card twice; this hasn't happened since I removed it. It could be coincidence, but I'm not taking any chances.
We'll be aligning the ATmega to the left of the breadboard and using the space at the other end to squeeze in the LEDs.
Orientate your Breadboard so that the number 1 ( numbers should be visible faintly on the edge ) is at the bottom left
Place your ATmega with the little notch facing left, and aligned against the left edge of the Breadboard
Make sure the ATmega pins line up with the holes on the breadboard, and push it firmly in with even pressure.
Locate column 9 and 10 on the bottom edge ( with the notch facing left ), and bridge them with the Crystal Oscillator. If you can't see numbers, count the holes.
Grab one male to male jump wire, preferably a red one, and bridge column 7 on the bottom edge to column 9 on the top edge
Grab another male to male jump wire, preferably a black one, and bridge column 8 on the bottom edge to column 7 on the top edge
Grab the next jump wire, or an 0 Ohm resistor, and connect the lower column 17 to the upper one, creating a mini Ground rail for your LEDs
Grab your last jump wire and bridge the top of column 17 to the top of column 7 to ground your LEDs Ground rail
You now have a working ATmega on a breadboard. Yes, it's that simple to get started! If you're confident getting it hooked up you can now visit my Pico Piduino assembly micro-site and click "Connection Overlay" to see where things should connect.
Cross reference this with my Piout Microsite to see which pins on the Pi are the ones you need to connect it to.
To verify that your ATmega is set up correctly and can be programmed, you need to set up the programming connections which are as follows:
Connect Reset on your Pico PiDuino to GPIO 8 on the Pi
Finally, connect the end of column 7 on your Pico PiDuino to your Pi 3.3v Pin, I recommend using pin 17 and the end of column 8 to the Ground on your Pi. I use pin 25 at the bottom right. This should keep all your connections in one tidy block.
Testing your Pico PiDuino
First you'll need to install Gordon's modified Avrdude on Raspbian, that means doing the following:
If you haven't already jumped the gun, you'll notice that I didn't connect the LEDs above. It helps to do things in phases, and once we've got a working ATmega up and running it makes sense to test it.
The LEDs are cleverly clustered around the Arduino digital pins 7, 8, 9 and 10. These are good for a number of reasons:
They're right at the end of the ATmega
They're in sequence
They don't conflict with any of the programming functionality
Most normal Arduino builds assume pin 13 is an LED, so if you use any demos from the Arduino website, or for any other Arduino-compatible devices make sure you update the LED pin to 7, 8, 9 or 10.
Connect the LEDs and resistors as follows:
Put the long leg of the Red LED into column 13 at the very bottom, and the short leg into column 15
Put the long leg of the Orange LED into column 14 right up against the ATmega, and the short leg into column 16
Put the long leg of the Yellow LED into column 14 on the top half of the breadboard, again right up against the ATmega, and the short leg into column 16
Put the long leg of the Green LED into column 13 at the very top of the breadboard, and the short leg into column 15
By now you should have 4 LEDs connected in two pairs, with two rows gap between them. Place a resistor in each of these 4 rows, bridging the short leg of each LED to the Ground rail.
We're done. Make sure everything is connected properly and fire up avrdude for one last test:
avrdude -p m328p -c gpio
Successful? Well, I'm afraid this article is getting a little long and I'll have to end here. Stay tuned for the next in the series when we will learn how to program your ATmega-powered Pico PiDuino from the command-line.
One of the first things that excited me about the Arduino Due was the possibility of VGA output with nothing more than a few resistors, a VGA connector and a bundle of wires. Arduino Forum member Stimmer has produced a brilliantly fast and low level VGA library that gives 8-bit colour at 320x240 pixels. Plenty of output for basic games, graphics demos and other visual tinkering. You can get this library here: http://stimmer.github.io/DueVGA/
VGA is fairly simple in the hardware department, requiring an array of 10 resistors which form two pairs of 3 ( 3 bits red, and 3 bits green ) and one pair of two ( 2 bits blue ) plus two for the horizontal and vertical sync signals. I found that the hardest part of building out an adaptor was finding the right resistor values, but a little trial and error on a breadboard and a seeming inability to discern between red and orange finally lead me to a working prototype.
The next step was translating that prototype to perfboard. I used a small piece of 3-hole breadboard from Clas Ohlson. I used Fireworks to manually sketch out my design beforehand and compress it down to a cozy 11 tracks wide.
10 of these tracks were broken into sets of 3 holes, and the 11th was continuous and used to join the ground on the Arduino Due to the ground on the VGA connector.
I stood the resistors upright to save room, and managed to pack them into a perfect row of 10 with some spaghetti wiring joining them together. The downside of this design is that it overlaps a number of unused inputs on the Arduino Due. Fortunately I was able to tuck the wires for my MegaDrive controller port underneath my PCB and make use of these otherwise lost and forgotten inputs, so everything ended up very neat and tidy.
Once set up and running, and after remembering to trim the leads off the resistors so they didn't intefere with each other, the picture was perfect. This is the first thing I've ever committed to perfboard, and I'm more than happy with the result.
After setting up DueVGA and assembling my adaptor, the next step was to do something interesting with my new-found VGA-output functionality. Many DueVGA users, including Stimmer, had concerned themselves with drawing fractal patterns which, although cool, didn't really interest me. I decided to ressurect some old tricks I used with Monochrome graphic LCDs on the ATMega328 and create a bitmap converter.
The 8-bit output of DueVGA uses a number between 0 and 255 to represent a colour. The first three bits of this number represent Red, the second three Green and the last two Blue. In practise the bias toward Red and Green doesn't result in poor image reproduction, but having only a handful of possible blue values is an odd concept to grasp.
My challenge was to map these 256 colours to their equivilent RGB/HEX colour codes and produce a palette file which allowed PNGs to be exported from Fireworks into a format suitable for crunching down for the Due.
To do this I started with the 256 colour pallete from Wikipedia: http://en.wikipedia.org/wiki/File:256colour.png. This gave me a list of all possible colour values which the DueVGA could theoretically produce. Some amount of muddling was required to figure out which colour on this palette corresponded to which colour index on DueVGA. If you look at my Due VGA Colour Table you'll see why. Rather than the colours running sequentially from left to right and looping underneath, the palette was separated into blocks of 32 colours with the value of Blue running from left to right and the value of Green running from top to bottom. Each block of 32 colours represented an increase in the value of Red- so this resulted in 8 (Red) blocks of 4 (Blue) by 8 (Green) colour.
To avoid tripping over colours in future, I used a Ruby script to produce my Due VGA Colour Table. This shows the 8-bit hex notation for each colour from 0x00 to 0xFF and makes it easy to pluck a colour out if you need to use it directly in your code. On mouseover, it also shows the binary value and the 24-bit hex colour you're probably more likely to recognise from desktop graphics applications. If you're putting together some bitmap graphics for your DueVGA project then you can use these colours in your graphics package of choice.
Alternatively, if your graphics package supports .act colour palettes then you can load up this 8bit-truecolor-palette.act file. This is excellent for compressing and dithering more complex images for display on the Arduino VGA, and I've had pretty stunning results with a range of photos.
The final step in converting a bitmap is to take your exported, palettized PNG file and, with the help of Ruby and the Chunky PNG ( which is free from the dependency hell of Image Magick ), crunch it into a "static unsigned char" array of 8-bit colour values. For this you can use Convert.rb from my Arduino DueVGA Tools repo on GitHub.
Indexed Palettes And Byte Packing
If you're not using the full 256 colour palette for your image, I've also added index-palette support into Convert.rb which will give you a palette of 15 colours with the 16th reserved for transparency. This allows twice as many pixels to be packed into the same number of bytes, halving the size of your data. If you can get to grips with Convert.rb you'll also find it stores 3 bytes of metadata in each image containing the Width, Height and Frame Count. I use these values in my code to animate 16-colour sprites and by not hard-coding these values I can use a generic function for various different sizes of sprite. See DueVGABitmap.ino for an example of this in action!
Another little trinket in my DueVGA Tools library is my HSV ( Hue, Saturation, Value ) colour to 8-bit colour convertion function. Stimmer may implement this directly in the DueVGA library. It provides a very clean and simple way of transitioning between colours ( by just incrementing the Hue value ) and is a mostly integer-implemented spin on the standard HSV-to-RGB functions you may have encountered before in Arduino LED lighting projects.
Where the DueVGA HSV to RGB differs is in the weighting of the final colour values and their packing into a single byte representing a colour that DueVGA can display.
Continuing on from the PiGlow, I got my hands on another piece of Pimoroni goodness; the PiBow Timber.
I picked up a plastic PiBow for my first Pi months and months ago. It has remained my favourite and, in fact, only Pi case since that day. Many Pi cases have come since, but none have matched the elegance and ruggedness of the ingeniously engineered PiBow.
The multi-layered design of the PiBow is, when put together, extremely strong and rigid, although the individual layers on their own can be a little fragile. 9 layers in total make up the case, a transparent top and bottom with etched icons for the SD card, HDMI, power and other ports, plus 7 wood or plastic layers making up the body.
Both the Timber and plastic PiBow cases use 4 nylon bolts. The nuts for these are a little small and fiddley, but you'll find spares in the packet and will get a little laser-cut tool for tightening them.
That is until the PiBow Timber. And the only reason it's as good as a PiBow is because it is a PiBow.
The Timber takes the tried and tested PiBow template and applies it to the classic medium of wood. Spruce in this case. The grain and texture of the thin, laser-cut, spruce layers which make up an assembled PiBow Timber lend it an utterly different look and feel to the plastic PiBow. It feels like a traditional piece of computing hardware, or an old Ferguson TV, and looks fantastic as a result.
While I don't want to sound weird. The PiBow Timber also smells utterly fantastic. It's rather like oak smoked salmon, or some other expensive smoked delecacy, and in a very, very good way too. Suffice to say, I have become quite addicted to huffing the rich, smokey aroma of the PiBow Timber... okay, I just got weird.
Although such escapades seem to nausate @pimoroni I'm also a huge fan of combining the PiBow Timber with the classic PiBow rainbow. The 7 layers of the Pi make for an aesthetically pleasing split between two colours, so I decided to mix the Timber with the Rainbow and ended up with a pair of colourful yet understated cases that, once again, evoke those retro computing feelings that, as someone who didn't even live through that era, I shouldn't even be feeling.
The blend leaves one PiBow with Pink, Orange, Green and Purple layers separated by 3 wooden layers, and another with Blue, Yellow and Red separated by 4 wooden layers. I'm more a fan of the Pink, Orange, Green and Purple combo and will almost certainly be keeping my PiBow assembled this way for a distinctive look.
A week or so ago I discovered the Pimoroni PiGlow via Twitter. Not so long after, it arrived in the post and I excitedly set about discovering its ins-and-outs.
First up, the PiGlow is small. Really small. It shouldn't come as much of a surprise, since in the photos its clearly narrower than the GPIO header. The diminuative size of the PiGlow counts in its favour, letting it fit snugly inside a PiBow case.
The PiGlow neatly circumvents the current expense and supply problems with RGB LEDs, its 18 LEDs are discrete colours, fanning out from a central point in 3 spokes of white, blue, green, yellow orange and red triplets. Because the PiGlow has Red, Blue and Green LEDs it's capable of producing a whole range of colours when combined with a suitable diffuser. I decided to repurpose a table-top, spherical glass lamp, which we'd been wanting to put an RGB LED bulb in for quite some time. If you want to achieve similar results, it's the FADO mouth blown glass lamp from Ikea it's a perfect enclosure for an RGB lighting project, and fits a Pi easily. It also costs only £12.
After experimenting with Django and becoming frustrated with its arcane approach to routing, I switched to Flask which is a little closer to Ruby's Sinatra and much easier to get to grips with.
To build the front-end for the PiGlow lamp, and ensure it would work at least in desktop browsers and the iPhone/iPad, I opted for my current favourite combo of jQuery and RaphaelJS. RaphaelJS is an SVG library which makes dynamically generating interactive graphics easy.
In this instance I used RaphaelJS to generate the colour wheel, which I limited to between 20 and 36 colours. In my current version of the remote code, which can be found on GitHub, I have a tap-to-select colour wheel. But I've already completed a drop-in replacement which will provide fluid, drag-and-drop fading between all the available colours.
My remote code is still very rough around the edges, but it's extremely satisfying to use and the PiGlow was a much better investment than an expensive RGB LED bulb. I plan to use the Orange and Yellow LEDs to provide a warmth adjustment to the overall light. Also, with all the LEDs driven to their full brightness the PiGlow seems to provide a pretty good approximation of white light and thus works as a very functional lamp in addition to a novelty RGB one.
Having had a couple of run-ins with CNC machines myself, albeit only one of them involving harm to me, I'm inherently aware of the dangers involved when operating large, complicated collections of semi-autonomous machinery. Granted, the time I accidentally picked up a lumb of searing hot machined aluminium couldn't have been solved by an emergency stop button!
What can be stopped, however, are unfortunate incidents involving either the machine damaging itself, I once sent the tool of a CNC milling machine through the block of aluminium I was machining, or to people/clothing.
Before launching into this brief review of the Arduino Due, it's important to note that this beefy complement to the ATMega based Arduino boards is absolutely not Arduino's answer to the Raspberry Pi. It may feature an ARM-based processor, but still adopts the bare-metal programming of its siblings meaning it's a very different beast. The Due is an extremely low power, low resource, experimentation/rapid development board designed to demonstrate a basic hardware template that you can adapt and evolve to suit your needs and eventually build into a finished, shipping product.
The Due gives you a chance to get hands-on with its 32-bit, 84Mhz ARM-Cortex A3 processor; the SAM3X8E. It doesn't do much to abstract away the complexity of its hardware, making getting down and dirty with registers much easier, and doesn't give you any operating system to deal with. That means no linux. There's nothing stopping you from writing one or using an existing RTOS like ChibiOS, FreeRTOS or NilRTOS. Don't get these confused with the likes of Linux, though, an Operating System on an Arduino is extremely barebones and designed specifically for realtime hardware control.
That's not to say the Due doesn't have some overlap in functionality with the Pi, but in reality this overlap is small. The Due boasts digital inputs/outputs, analogue inputs, PWM outputs and, for the first time ever on an Arduino, a DAC driving a pair of real analogue outputs; providing variable output voltage rather than simply relying on Pulse-Width Modulation. Flexibility is the name of the game, and the Due has it in droves.
When it was announced back in October 2012, the Due met with controversy due to its lower IO voltage, the same 3.3v as the Pi, which makes it incompatible with some existing designs, tutorials and expansion boards ( also known as Shields ). Months since it's launch, many Arduino libraries will not work on, or even compile for, the radically different microprocessor but this shouldn't put you off- the vibrant Arduino community will eventually work wonders with the Due, and being a part of that is both challenging and rewarding.
Despite a slow start brought on by its complete paradigm shift in the processor department, the Due is gaining traction. As more people pick it up and explore what it's capable of the community support gets better and better. Since getting my hands on the Due I have played with some great existing libraries, most notably Arduino Due VGA (http://stimmer.github.io/DueVGA/), and slapped up some code of my own to read a MegaDrive Controller. I had fun, I experienced the raw power of the Due first hand, and I'm excited to see just how much further I can push it.
After attending the local Norwich Ruby user group meeting and enjoying some healthy discussion about hosting-on-Heroku and the Amazon Elastic Beanstalk, I was inspired by the phrase "turn down the dynos." Since TechWeek Europe are still calling for your office gadget ideas I thought I could throw together another hair-brained scheme and see if they bite.
A "Dyno" in the context of Heroku is a single web worker process. More of these mean your web application can handle more traffic. But they also mean it's going to cost more. When it comes to "Worker Dynos", which are back-end worker processes which handle processing jobs that aren't related directly to a client request, you might often want to scale these up in order to get a job done quickly, and then back down when you're done to avoid prohibitive ongoing costs.
Heroku has a command-line tool, and a command-line tool can be scripted. It also has a public API, although that's severely rate-limited. So the sensible choice is to create a physical control panel, from a Pi or Arduino, a collection of linear potentiometers and some bargraph LEDs, and hook it up to a computer with a basic interface script to the cli binary.
This would be a great little project for a hackday collaboration. I envision between 4 and 10 pots, or "dials" if you will, each with one or two bargraph LEDs. APIs would be tapped into to show both the current number of running dynos, and the "saturation" ( or amount of web traffic/load divided by the amount of dynos, or something useful like that ) so that you can see at a glance when something should be dialled up or down.
Obviously this has little practical use, except in the case of worker Dynos where you might need to remember to scale them back down after a period of time. We could slap in a 7-segment display and an alarm buzzer for that.
RS Online have pretty much all the components required, although finding them is an excercise in futility if you don't know exactly what you're looking for:
5x7 Dot Matrix display. I would envision 10 or so of these creating a single "master" display that can show a scrolling 10 character message in a format that's clear and distance viewable. 7 segment displays can be made to display text, but it's not exactly particularly readable! - http://uk.rs-online.com/web/p/led-displays/2473141/
This is a nice little project that I'm confident has a half-decent chance of being completed and well documented. Not only will it teach the people putting it together ( hopefully more than just me ) about interfacing various components with a computer, but it will also prompt an exploration of Heroku and of various statistics monitoring APIs. In the long term it could be expanded to a complete status control panel... it might actually be genuinely useful.
It's also easy to prototype, we can string together some components and software on a table to see how things might work. At a basic level I envision the Arduino handling all the direct driving of at least the analogue components, although there are a plethora of Raspberry Pi boards out there which would do just as well. The Arduino would then communicate with the Pi over logic-level-shifted serial, or USB serial and the Pi would be responsible for digesting the various analogue control commands into Heroku CLI actions.
For status information, a Ruby script could easily tap into the various available traffic, log and status APIs and light up LEDs, bargraphs or even LCD displays with information on the current status of various sites. Perhaps a more flexible way would be to emunerate all available applications on Heroku via the cli and use a handful of knobs, bargraphs and 7 segment displays or 5x7 dot matrix displays which can each be switched between sites on the fly. This way you could control all of your applications from one control panel.
In the course of developing my Serial TFT Python driver library for the Hobbytronics Serial TFT board. I conducted a suite of "load" tests which I used to determine just how fast I could draw text, pixels, lines, boxes, filled boxes, circles and filled circles. The results are pretty good for a serial connection, but naturally the combination of serial communication and an Arduino display driver slow things down to the point where extensive, full-screen animation isn't viable.
For basic UI display, clocks, tweets and other information readout, however, the Serial TFT is a great way to add a very quick, easy and simple to drive display for your Pi. It's not a Pi-only product, however. Where it excels is in taking the load away from a lesser controller, such as another Arduino, and letting you add a TFT screen to a project without sapping a good half your microcontroller memory for a display buffer.