next topic »

[on:]

Hi,

I tried to switch my Duemilanove for a Uno and I have been experiencing serial communication issues.

I am using OS X 10.6.
I bought my Arduino Uno from Sparkfun.
The Arduino is connected by USB directly to the computer.
I am using the Arduino IDE 0021.

Here is the sample code:

Code:

void setup() {
  Serial.begin(57600);
}

void loop() {
  while ( Serial.available( ) > 0 ) {
    byte serialByte = Serial.read();
    Serial.print(serialByte);
  }
}

When the baud is set to 57600 the Arduino Uno returns gibberish. For example, if I send the bytes 240 1 247, the Arduino Uno returns 248 224 and nothing else!

If I set the baud to 115200, the Arduino Uno returns the proper values.

Anybody else experiencing this?

[Reply #1 on:]

What are you using to communicate with your Arduino? Are you using the built-in serial monitor? Whatever you are using, you must make sure to set its baud rate to match whatever you give to Serial.begin(). It sounds like you are changing the baud rate in your sketch but not in the serial monitor.

--
The Quick Shield: breakout all 28 pins to quick-connect terminals

[Reply #2 on:]

I tested with the serial monitor, Pure Data and Processing. I also switched boards with the same code. The Duemilanove runs the code fine, the Arduino Uno does not.

Here are some more strange results (when using Arduino's serial monitor set to the proper baud rate) with the Arduino Uno and the same code:

When I type "a" (send)
I receive "a"

When I type "ab" (send)
I receive "ab"

When I type "abc" (send)
I receive "abì"

When I type "abcdefg" (send)
I receive "ab,V–"

If I switch the baud to 115200 in the code AND in the serial monitor, all the messages sent are identical to the ones received. There definitely is a problem with 57600.

[Reply #3 on:]

I am seeing the same thing.

Similar setup: OSX 10.6, Uno, 0020 (instead of 0021).  At 57600 there tends to be garbage with 2 or more characters.  No issues at 115200.

[Reply #4 on:]

That is interesting. It does have all the hallmarks of a not-quite-right-baudrate issue though. I don't suppose you have an oscilloscope that you can connect to the RXD serial line (digital pin D0) to accurately measure the bit width? It should be 17.36 microseconds.

--
The Gadget Shield: accelerometer, RGB LED, IR transmit/receive, light sensor, potentiometers, pushbuttons

[Reply #5 on:]

I see the same problem.  I can get it to work better by commenting out the fancy code in HardwareSerial.cpp that tries to get "better" bitrates by using U2X mode...

(interestingly, the other direction seems to work fine.  I don't see any errors in the byte stream sent TO my mac...)

[Reply #6 on:]

I wrote a sketch to dump the UART config.  It is using u2x mode for 57600, and it DOES seem to have correct values for the bit rate generator...

Hmm.  Now that the Uno has an ATmega chip for the USB/Serial converter, is THAT firmware (LUFA) using the same algorithm for picking bitrates as the arduino firmware?  This sort of thing could be explained if the 8u is picking a divisor/setting with +n% error, while the 328 is picking a divisor with -m% error...  Having them MATCH is more important than actually being close to the specified bit rate...

Code:

void setup()
{
  Serial.begin(57600);
  Serial.print("UCSR0A: ");
  Serial.println(UCSR0A, BIN);
  Serial.print("UCSR0B: ");
  Serial.println(UCSR0B, BIN);
  Serial.print("UCSR0C: ");
  Serial.println(UCSR0C, BIN);
  Serial.print("UBRR0H:L: ");
  Serial.print(UBRR0H, HEX);
  Serial.print(UBRR0L, HEX);


}

void loop()
{
  byte newstatus = 0;
  int c = Serial.read();
  while (c > 0) {
    if (UCSR0A & 0x3C) {
      Serial.print("Error: ");
      Serial.println(UCSR0A, HEX);
    }
    newstatus = 1;
    Serial.print(c, HEX);
    Serial.print(" ");
    if (c == '\r') {
      Serial.println();
    }
    delay(1);
    c = Serial.read();
  }
  if (newstatus) {
    Serial.println();
    Serial.print("UCSR0A: ");
    Serial.println(UCSR0A, BIN);
    Serial.print("UCSR0B: ");
    Serial.println(UCSR0B, BIN);
    Serial.print("UCSR0C: ");
    Serial.println(UCSR0C, BIN);
    Serial.print("UBRR0H:L: ");
    Serial.print(UBRR0H, HEX);
    Serial.println(UBRR0L, HEX);
  }
}

[Reply #7 on:]

In fact, it looks like the 8u firmware has special case code for 57600 that DOES configure its uart "opposite" the way the 328 is configured.  I can't tell whether that is a bug, or something that was done specifically to address 57600bps issues with an earlier Arduino; there's a comment there about being compatible with the 57600bps bootloader on 328, but... the 328 bootloader doesn't RUN at 57600 any more.  And if it is talking about the current Arduino code, it looks like the tests are backward (it picks u2x for everything except 57600 !?)

[Reply #8 on:]

Should a bug report be filed? If so, where?

[Reply #9 on:]

I have submitted
  http://code.google.com/p/arduino/issues/detail?id=394

[Reply #10 on:]

Does it work better if you use Serial.begin(57599) or other numbers around 57600? This should trick the 328 and 8u2 into using the same parameters.

I am not having any problems with 57600 baud myself but I had a similar issue with 300 baud. I had to use Serial.begin(298) to get that speed to work.

I am using an Arduino Uno on Ubuntu 10.10 64 bit and Windows XP. An older (FTDI) Arduino Mega works fine at 300 baud on both systems.

[Reply #11 on:]

Does it work better if you use Serial.begin(57599) or other numbers around 57600?

Good idea!  Serial.begin(57850) seems to improve things...

Code:

For baud=057770, nonu2x_baud = 058823, u2x_baud = 057142 Use U2x, divisor = 34
For baud=057780, nonu2x_baud = 058823, u2x_baud = 057142 Use U2x, divisor = 34
For baud=057790, nonu2x_baud = 058823, u2x_baud = 057142 Use U2x, divisor = 34
For baud=057800, nonu2x_baud = 058823, u2x_baud = 057142 Use U2x, divisor = 34
For baud=057810, nonu2x_baud = 058823, u2x_baud = 057142 Use U2x, divisor = 34
For baud=057820, nonu2x_baud = 058823, u2x_baud = 057142 Use U2x, divisor = 34
For baud=057830, nonu2x_baud = 058823, u2x_baud = 057142 normal, divisor = 16
For baud=057840, nonu2x_baud = 058823, u2x_baud = 057142 normal, divisor = 16
For baud=057850, nonu2x_baud = 058823, u2x_baud = 057142 normal, divisor = 16
For baud=057860, nonu2x_baud = 058823, u2x_baud = 057142 normal, divisor = 16
For baud=057870, nonu2x_baud = 058823, u2x_baud = 057142 normal, divisor = 16

[Reply #12 on:]

This same issue happened when using Teensy to communicate with '328 based Arduino clones.  I wrote about it here:

http://dorkbotpdx.org/blog/paul/teensy_as_benito_at_57600_baud

The original Arudino bootloader never tried to use the 2X mode, so it communicated at 58824 baud, not 57600.  That's +2.124% error, which is just barely within 8 bit serial tolerance.  In other words, all those Duemilanove boards were just barely working when in bootloader mode.

Dean probably tested the 8u2 firmware for Uno with a Duemilanove running the original bootloader at 58824 baud, instead of optiboot.  Just as I encountered, if you use the "best" baud rate in 2X mode, which is 57143 (-0.794% error), then you can't communicate with the original Arduino bootloader.

[Reply #13 on:]

What about just using this for the baud rate calculation (for Serial.begin())?

Code:

 bool use_u2x = true;

#if F_CPU == 16000000UL
  // hardcoded exception for compatibility with the bootloader shipped
  // with the Duemilanove and previous boards and the firmware on the 8U2
  // on the Uno and Mega 2560.
  if (baud == 57600) {
    use_u2x = false;
  }
#endif

[Reply #14 on:]

What about just using this for the baud rate calculation (for Serial.begin())?

What does that do to communications between 56kbaud peripherals that are working correctly and the ATmega?

Breaking the core to work around a broken bootloader is a bad idea.

-j