Introduction

Since getting a “modern” mobile phone (a Blackberry Pearl 3G 9105), I realised I was walking around with a configurable interface. That is, a little keyboard, and a display which could, with software, be both output or input (in a sense- I could draw a linear potentiometer, which I would control via the keyboard).
But also, it has comms- WiFi, 3G, and Bluetooth. The latter is particularly of interest to me, because it doesn’t involve any infrastructure, and adaptors to go from Bluetooth to serial are easy to get, and easy to use.
So the combination means being able to remotely (up to around 10-15m) control some microcontroller based device, from a custom, tailored interface that fits in my hand, and is self-powered.

Bluetooth

As I usually do, I went with what was cheapest:
JY-MCU Arduino Bluetooth Wireless Serial Port Module
The base modules with all the actual radio stuff on it are 3.3v, so this package provides the voltage regulator and level translation such that we can plug it directly into an Arduino board running at 5v. For many other microcontrollers, such as the Texas Instruments MSP430 family, or the ST Microelectronics ARM chips, we can dispense with that, save a couple of quid and get it without the power adaptor board:
Wireless Bluetooth Transceiver Module Serial Module HC-06
Connect up power, ground, and wire the Tx pin to the Arduino pin 0 (the Arduino’s Rx), and Rx to pin 1 (the Arduino’s Tx).
It starts up in pairing mode, looking for incoming connections. You will need to tell your phone to pair with
it, providing a PIN, which is 1234 for the modules I have. You only need to do this once. Annoyingly, it uses more current when attempting to pair, compared with connected mode. I believe Bluetooth v4 is much better in this regard.
My initial project was controlling these super useful SPI LED boards, converting keypad presses on my phone, to displaying the number on the 7 segment displays. A decent enough proof of concept, but not directly useful.

Arduino Uno

When the Arduino Uno was announced, one of the most notable changes was to drop the FTDI usb-to-serial chip, and replace it with another Atmel microcontroller- initially the ATmega8U2 (now ATmega16U2). It was said that this could be reprogrammed to act like a different class of USB device, not just the default usb to serial.
But no-one seemed to know how at the time, and I forgot about it.
When I finally decided to add to my Arduino collection, I selected a Uno, which by now was in revision 3. Around the same time I was looking to remotely control presentations for the classroom, and put the bluetooth work to good use.
Since I don’t have administrator privileges on the computers at college, it seemed that to emulate a keyboard would be best, avoiding a need to add drivers, or install any other software interface. It should be, to use an outdated expression, plug ‘n’ play.
I went looking for documentation, and found a great post by Michael Mitchell – Arduino USB HID Keyboard. I was nearly able to follow the instructions verbatim, except that he seems to have an earlier revision Uno, which lacks the pulldown resistor on the reset pin, and uses the ATmega8U2.
Visting the page he links to shows a rev 1 board, and the solder pads don’t exist on the back of the current rev 3, which is also decked out in the different paint job. If you have an R2 or R3 like mine, you can ignore this bit and leave your soldering iron alone, as they are ready-to-go.
Note that, unless you use some alternate method of loading sketches or otherwise-sourced hex files onto your Arduino (such as via the ICSP header), by reprogramming the ATmega16U2, you will no longer be able to upload via USB- at least, until you program it as a USB to serial adaptor again.
How can you program the ATmega16U2 chip anyway? Surely all hex files sent over USB are passed onto the main board chip, the ATmega328P? Normally yes, but resetting the ATmega16U2 puts it into DFM mode, where it will now flash itself. We do that by briefly shorting the reset
pin to ground on the ICSP header next to the ATmega16U2 whilst it is connected to the computer. Now it is waiting for our instructions.
Problem is, the recommended programmer under Linux or OSX is dfu-programmer, and it doesn’t yet know about our ATmega16U2. So we’ll need to patch it. You will need the source code, and to make sure you have the lib-usb dev package installed, as well as a working build environment.
This applies to version 0.5.4, if it is later than that, try it first. If you definitely reset the ATmega16u2 as per the instructions above, and dfu-programmer still reports:

dfu-programmer: no device present.

then you will need this patch. Additionally, I found that the Makefile had issues on my system (Kubuntu 12.04), solved with another patch. After unpacking the source, run

./configure

go into the dfu-programmer-0.5.4/src directory before running
n

patch < atmega16u2.patch

go back up a level, and run make as usual. You don’t have to install it of course, it will happily run from the src/ directory.
Once you’ve done that, you can follow the rest of Michael’s great instructions. Don’t forget to upload the sketch before you reflash the 16U2…once it is a pretend keyboard, it can’t pass on sketches to the main microcontroller.
Getting a cheap usbasp (plus 10-to-6 pin adaptor) will allow you to upload sketches without having to constantly reflash the ATmega16U2, and allowed me to rescue an Arduino Diecimila with a dead FTDI chip.
Part two I will show my simple serial-to-keyboard sketch, and the software I wrote for my phone.

Patches

makefile
atmega16u2