Added Bluetooth support to SDK

[samolds]

Added a beginBluetooth function to the serial utility to do initial configuration for the BlueSMiRF bluetooth module. Also added documentation in the form of a wiki and usage to the README

[mattrasband]

Does this happen on each boot? Seems like this is the implication here when I would expect that once it's set, it is likely persisted.

[samolds]

Yeah, this allows for the user to change the baudrate of the bluetooth device just through the Arduino sketch. The "U,xxxx,N" AT command doesn't persist the baudrate. It defaults to a baudrate of 115200 on boot.

[mattrasband]

I'm just surprised the module doesn't persist that, anything else I've played with that I can recall saves that between boots. Weird

[samolds]

There is a set baudrate command that persists. But this is the best way I found that still allows the user to switch the baudrate in a similar fashion to Serial.begin(xxxx); from the Arduino's setup() function.

[mattrasband]

Understood. However, if I recall correctly if the user is on softwareserial, that often has issues at higher baud rates. Have you seen any issues with this when over software serial? I mostly just wonder if we should provide a sensible default (ship them with 9600 baud) that works with both and let them use the overloaded begin if they have changed it themselves.

[bencpeters]

you should be able to do _soft_serial->print("$$$"), correct?

[samolds]

This was something I forgot to change. This was how it was done in an example pass through sketch, and I just never updated it.

[bencpeters]

I'm a little wary about assuming that we'll reset the bluetooth baud rate with AT commands on every single arduino boot when we've got a bluetooth sketch. I'm actually leaning toward moving this functionality into its own function (e.g. updateBluetoothRate).

This needs to be tested rigorously on software serial on Uno too --> make sure we can set 57600 and then back to 9600 with no hiccups.

[bencpeters]

do we need to manually exit AT command mode? I assume there's a timeout, but it'd be good to make sure we're not in command mode after the change.

[samolds]

The "U,xxxx,N" AT command sets the baud rate and the immediately transitions out of command mode.

[bencpeters]

this is actually causing a buffer overrun. Remember, in C, strings are null-terminated, so every string has an implicit '\0' after the visible characters. strcpy copies every character in the source string over, including that terminating character, so your calls to strcpy below are writing 9 characters, not 8. That means they're setting the memory address &baudCmd + 9 = '\0';, which may not mess with anything immediately, but is not good/predictable.

Given that we know that there's another (at present unused) cmd option for 115200 baud which would have another character to it, I'd probably make this a char [10]; just in case we add the command in the future and whoever does that forgets to check the buffer length. An extra byte allocated on the stack for this function call isn't a big deal.

[samolds]

Ah geeze - I forgot about the '\0\'. Thanks.

According to the bluetooth documentation the AT command to change the baud rate will never be more than 8 characters. The command to change the baudrate to 1200 is U,1200,N, and to change it to 115200 is U,115K,N. So baudCmd[9] should work for any baud rate.