Is there any reason why most tutorials recommend using a baud rate of 9600baud for the USART? Since the bootloader now operates at 115200 baud, it's not like the higher rate-dependency isn't present. It would help many beginners out quite a bit if the tutorials were switched to 115.2kbaud, and the default setting on the Serial Monitor in the IDE to be 115.2kbaud. This would certainly help the people who find their loop is slow because of multiple print statements (over 1ms per character is pretty significant), and really doesn't hurt anything, as far as I can tell.
There is no specific default. Bootloader baudrate has changed over time but that has no relationship over what specific baudrate various authors used in their sketch examples. I tend to use 57600 baud in most of my projects.
The tutorials and examples are all written with 9600baud - I got the impression this was some unified decision made by the Arduino team, since it's quite consistent.
Is there any general reason to use lower baud rates (disregarding the case where you need to interface with a device that doesn't support higher rates)?
The 9600 baud is very likely an historical artifact. When the very first Arduino board was created, it was still possible to find PCs that had buggy / crappy UARTs. If I remember correctly, baud rates over 19200 were not reliable with a bad UART. To ensure Arduino users would be able to get the board working 9600 baud was the best choice.
Is there any general reason to use lower baud rates (disregarding the case where you need to interface with a device that doesn't support higher rates)?
No, not if the device can handle the rate. Keep in mind that the highest baud rate puts a burden on speed of processing receive data for the arduino. the serial receive buffer is 128 bytes in size and if ones loop sketch is too slow it's possible to drop characters if lots of data is coming in at the highest possible baud rate. So while the highest baud rate can help your sketch run faster on the transmit side, it brings a burden on processing the receive data stream at the same time. It's really application dependent, no one size fits all cases.
That makes sense, thanks. Nice to know it wasn't arbitrarily picked.
retrolefty:
No, not if the device can handle the rate. Keep in mind that the highest baud rate puts a burden on speed of processing receive data for the arduino. the serial receive buffer is 128 bytes in size and if ones loop sketch is too slow it's possible to drop characters if lots of data is coming in at the highest possible baud rate. So while the highest baud rate can help your sketch run faster on the transmit side, it brings a burden on processing the receive data stream at the same time. It's really application dependent, no one size fits all cases.
Seems to me that you can get about 1250 processor cycles in the time it takes to receive a single byte - with a 128byte buffer, it seems somewhat unlikely that the processing loop would actually drop data. Of course, it's not out of the question, I guess, if there are lots of delays in the code.
Oh, you young whippersnappers.
My first modem was 300 baud.
When I upgraded to 1200 baud, I was quite completely freaked out.
2400 wasn't much, but my first 9600 bps modem (a little cube that sat nicely on my NeXT Cube) was aMAZing.
dsacmul:
Oh, you young whippersnappers.
My first modem was 300 baud.
When I upgraded to 1200 baud, I was quite completely freaked out.
2400 wasn't much, but my first 9600 bps modem (a little cube that sat nicely on my NeXT Cube) was aMAZing.
9600 ain't slow.
Get off my lawn.
While 9600 isn't slow, per se, it is to be noted that Arduino promotes the idea of printing formatted ASCII code out from the USART - a profoundly inefficient way of sending out data: for an 8bit number, it takes, in the worst case, 3 times as long to print (best case is equal). This means that people printing debug data are often surprised by long transmit times, especially since Serial.print() is blocking.
zoomkat:
9600 may be the default com port setting in the windows os, the serial monitor, and such.
Arduino doesn't teach people how to use Hyperterminal - it's not like there's an issue where it must be used. And it's simple enough for the Arduino team to set the default baud rate on the Serial monitor to something higher, as well.
"Maybe in order to understand mankind, we have to look at the word itself: "Mankind". Basically, it's made up of two separate words - "mank" and "ind". What do these words mean ? It's a mystery, and that's why so is mankind." - Deep Thoughts by Jack Handy
Arduino doesn't teach people how to use Hyperterminal
Well we're not in 2001 anymore - Windows 7 doesn't include hyperterminal.
Many serial products run on 9600 or 19200 baud by default so it's not just the Arduino. When using newsoftserial as I recall, the connection to the computer is 19200 and to the other device, 9600. By default, my GPS, serial LCD, rMP3 etc were all at 9600 so that makes sense.
And it's simple enough for the Arduino team to set the default baud rate on the Serial monitor to something higher, as well.
Do you really think you will get them to change any decision they have previously made however poor or in this case outdated? If they didn't change the pin spacing error when they discovered it, which was very early on, do you really expect them to change anything else?
If they didn't change the pin spacing error when they discovered it, which was very early on, do you really expect them to change anything else?
Not quite the same scope of effect of the change. Changing the default serial monitor baud rate breaks nothing that can't be fixed by just selecting the desired baud rate in the serial monitor. Changing the shield connector spacing would break all prior shields manufactured by many companies and require real expense to upgrade shield boards and make all prior shield boards incompatable with an new arduino boards using newer spacing specs. It was a dump error, but prefectly understandable that they don't want to force a change for all the companies and end users that would be effected. Besides there are several hardware 'fixes' to deal with the connector spacing if one wants to.
That is exactly my point. As I understand it they discovered the flaw at the point that the very first production shields were being manufactured. There were no prior shields other than this first batch, and none produced by other companies at this point. They should have fixed it right then and there because this sort of flaw cannot be fixed in software.
Yeah I used to work with those. When the card got jammed in the feeder chute it sounded a lot like a vacuum cleaner that was trying, unsuccessfully, to suck up your rug. So you ran up, powered it off, opened the door, and started pulling the card (possibly in pieces) out of where it was stuck. Then you recreated the card from backups. It was quite funny in a way, it was like recovering one sector of a hard disk, you didn't waste time recovering the whole file. And since this happened a few times each shift, you were absolutely experts on doing backups and restores.
