ITead Studio BT Shield v2.2
Pictures and links:
Here's the bluetooth shield as it looks plugged into an Arduino Uno board:
Here is a closeup of the two main chips on the shield. The CSR BC417 is the one that does the actual bluetooth work. The M29W800DB seems to be flash memory (no doubt where the bluetooth settings are stored).
The ITead Studio BT Shield v2.2 page.
Things I've learned:
The simplest thing to learn was that the datasheet is awful cryptic :-).
All the talk about it being a drop in replacement for the USB serial is mostly true, but there is no hardware reset when you are talking to the bluetooth, so uploading new sketches via bluetooth doesn't really work (at least not without funny kludgery I hope to work out someday).
The datasheet also talks about the AT command mode but doesn't make very many things clear about command mode.
The first is that you don't ever get to send commands over bluetooth. The commands always happen only via the USB serial interface, and when you change the jumpers as shown in the datasheet, an important fact is that the jumper connection shown will leave both the arduino board and the bluetooth shield talking to the serial interface. This means it is vitally important to have the arduino board running some sketch that is not using the serial connection (the Blink sample is a good one).
When I finally got it to work, I found that it constantly repeated the same output from the last command (or maybe re-ran the last command) over and over again till I hit enter to send an empty line. I don't think this hurt anything, but it was weird.
Once I finally figured out how to get into command mode, I found the baud rate setting on the board I got was 9600. That seemed awful slow, so I changed it to 115200 at which point I couldn't get anything to work anymore (sigh :-). After much poking, prodding, and hitting reset on the shield and the arduino, I finally got command mode back and used AT+ORGL to reset all the default settings (where I discovered that the default baud rate is 38400 as documented, so I don't know why it was 9600 when I received it). Anyway, once set to 38400, all communication seems to be working well. [Hey I figured out 115200 - see below].
To talk to the board from my Android phone, I used the Arduino Commander app and downloaded the modified StandardFirmata sketch from that website to use on the arduino side.
It was harder to figure out how to talk to the board from my Fedora 16 linux box, since I spent a long time trying to talk to it in the form of uploading sketches, which (as I mention above) doesn't work. Once I gave up on upload, and just tried to talk to a sketch that used the serial port, things worked fine.
To make it talk to linux, you have to (just once) run the bluetooth-wizard app and tell it to use the fixed PIN code 1234. That will let you pair the bluetooth shield, and after that, you can connect with less effort. (Of course, you also have to have a bluetooth interface - I use a little USB dongle from D-Link.)
Once paired, you can run hcitool scan and it will print a bunch of cryptic output with numbers and names, and one of the lines will have itead in the name. The numbers on that line are the address you need to connect to.
Since the board talks bluetooth serial protocol (also known as RFCOMM), the tool you use to setup the connection is (amazingly) named rfcomm. I use the command (run as root):
rfcomm bind 0 00:12:01:07:00:65 1
to connect to my board. You will have a different address, but a similar command. What that command will do is create a device named /dev/rfcomm0 which you can then open and use like a serial port to talk to the sketch running on the arduino. One way to do this might be:
minicom -D /dev/rfcomm0 -b 38400
When you are done, you can release the device and remove the /dev/rfcomm0 file with the command:
rfcomm release rfcomm0
In my current state, I now need to power off and remove the jumpers on the bluetooth shield so I can upload a new sketch over USB, power off and put the jumpers back in order to talk to the sketch via bluetooth (being sure to get them back in the right positions :-).
I did a lot of experiments with attempting to upload via bluetooth and I've pretty much concluded that I need a custom bootloader. It either needs to wait longer to give the bluetooth a chance to start working again after a reset, or I need to provide an entry point into the boot loader I can call directly to bypass the reset and just enter the bootloader logic. Anyway, for now it is pretty clear I'll be using the USB interface to upload.
I suppose I could connect the bluetooth to a different set of pins and use software serial to communicate, but I'd really rather have the full speed of the hardware UART available.
GAAH! Another pain in the patoot: There are very few pins on the arduino that can generate interrupts, and pin 2 is one of them. The BT shield, however, seems to feed the status LED signal to pin 2 (a fact not remotely hinted at in the datasheet). I can use pin 3 as input since it also can generate interrupts, but I was planning on using it for output since it can be driven by the PWM timers. Maybe I'll have to drill out the pin 2 connector from the shield or something...
Another new fact learned: Setting the baud rate via the AT commands only sets the baud rate it will use to communicate with the arduino when the switch is set to DAT. When the switch is set to CMD and you are speaking AT commands over the USB interface, it always seems to use 38400 no matter what the setting is. This led to the confusion about about baud rates. Once I deduced this, I was indeed able to get my sketch to talk to the host at 115200 baud via bluetooth by sending AT+UART=115200,0,0 in command mode to the bluetooth module and using Serial.begin(115200); in my setup() code. That gives me a communications path that is quite a bit faster than most IR pulses, so I sould have no problem keeping up. [And holding down the button on the remote, I see I no longer lose any data even in streams running as fast as I can make the remote repeat].
UPLOAD SUCCESS!!! It finally dawned on me that the problem I had when I tried to do uploads before was that I didn't have the BT module baud rate set to the value the bootloader is going to try to talk. Since I finally got 115200 baud working I tried uploading microcode over bluetooth, and it actually worked.
The procedure is to first type make clean build to get everything ready to go, then type make upload, but don't hit return. Now hold down the reset button on the arduino, and hit return to start the make upload at the same time you release the reset button. (Another reason using a Makefile is more convenient than the IDE :-). Of course you also need to change the Makefile to use /dev/rfcomm0 rather than /dev/ttyACM0.
If I can find out if the bootloader I have will reset the watchdog timer, I ought to be able to add a command to my microcode that will reset the arduino, then I could totally automate the process of doing a new upload by sending the reset command just before calling avrdude.
Bzzzt! Apparently the bootloader's default response to a watchdog is to jump immediately to my sketch and completely bypass the boot loading process. Sigh. I guess the only way I'm going to be able to make this thing able to update microcode on demand over bluetooth is to modify the bootloader. (Or add extra hardware I can use to trigger the reset pin.)