I've got an uno R3 with an ITEAD v2.2 bluetooth shield. I can get my android phone to talk to it perfectly with the ArduinoCommander app, and turn the LED on pin 13 on and off, so I'm pretty sure bluetooth is working, but I've been trying to get my fedora 16 linux box to be able to upload sketches to it via bluetooth, and I'm having no luck at all. I hate having to fiddle jumpers or unplug the shield so I can upload via USB, but I haven't discovered whatever magic trick it takes to get the arduino IDE to be willing to talk to /dev/rfcomm0. I can get (for example) the minicom app to open /dev/rfcomm0, and it seems to believe it is connected to something, but I have no idea how to do any kind of interaction with minicom to confirm it is actually talking. Any hints out there for bluetooth on linux?
More experiments: If I load the AnalogReadSerial sketch via USB, plug the bluetooth shield back in, I can connect to /dev/rfcomm0 with minicom on linux and see it writing 1's and 0's to the serial output, so bluetooth serial is working, I just can't get the arduino 1.0 software to use it to do uploads.
If I manually set serial.port=/dev/rfcomm0 in the preferences.txt file, it tells me serial port "/dev/rfcomm0" not found. If I make a symlink from /dev/rfcomm0 to /dev/ttyS4 I get the error that the serial port is already in use.
Do I have to tweak more settings I don't know about? Should I tell it I have an Arduino BT board rather than a UNO R3?
Claghorn:
Should I tell it I have an Arduino BT board rather than a UNO R3?
Well, I tried that, and at least I get different errors. Now I see:
avrdude: stk500_getsync(): not in sync: resp=0x30
Once you have the code compiled, you can use avrdude by hand and select any serial port you want.
You still would have to think about how to implement the auto-reset with the wireless thingy. Otherwise no upload.
madworm:
You still would have to think about how to implement the auto-reset with the wireless thingy. Otherwise no upload.
I have read other messages about hitting the reset switch by hand just before the upload, but when I try it, I usually get the same sync error with a different hex code printed - maybe getting the timing right is too hard for my reflexes :-). I guess I'll just continue to fiddle the jumpers when I want to upload and keep using USB for now.
My eventual "production" sketch will be reading commands and sending info to my host computer. Maybe there is some way I'd be able to send it a command to say "Hey! Jump to the bootloader so I can update you"?
You can do it with the watchdog timer, but that needs very careful thinking and a probably a modified bootloader as well.
The main problem is that after a watchdog reset the associated timeout is set to 16ms, which is unavoidable. Therefore the watchdog must be turned off ASAP ( = in the bootloader ), or you'll end up in an endless reset loop.
madworm:
Once you have the code compiled, you can use avrdude by hand and select any serial port you want.You still would have to think about how to implement the auto-reset with the wireless thingy. Otherwise no upload.
I figured out how to get things to work from a plan makefile so I could get control of the different steps, and I can successfully upload over USB and /dev/ttyACM0 using my makefile and a echo command to write the reset command to /dev/ttyACM0 just before running avrdude. That even works correctly.
Unfortunately, when I try swapping /dev/rfcomm0 for /dev/ttyACM0, I get this error:
echo CRESET > /dev/rfcomm0
/zooty/arduino/arduino-1.0/hardware/tools/avrdude
-C/zooty/arduino/arduino-1.0/hardware/tools/avrdude.conf -q -q -patmega328p
-carduino -P/dev/rfcomm0 -D -Uflash:w:proto1.cpp.hex:i
avrdude: ser_open(): can't set attributes for device "/dev/rfcomm0": Inappropriate ioctl for device
ioctl("TIOCMGET"): Bad file descriptor
But I have no problem opening /dev/rfcomm0 in minicom and talking to the arduino from the terminal, so what kind of ioctl is avrdude trying to use (and where is the source for avrdude to be found).
From when I was fiddling with some of the innards of avrdude myself, I think it may be the settting/unsetting of some control signals (like RTS / DTR).
OR: what port-speed does the rf-link allow. Maybe the avrdude defaults are not acceptable. Try specifying them explicitly.
My continuing experiments are making me believe that the reset is clobbering the /dev/rfcomm0 device, and by the time the bluetooth is back up and running, the bootloader has decided to go ahead and jump to my sketch. I may just give up on the idea of ever updating via bluetooth. Perhaps if there was a way to make the bootloader delay longer looking for avrdude to talk to it I could get it to work. Or maybe come up with some way to jump directly into the loader code instead of resetting the device so rfcomm0 stays up the whole time...