0

I use Arduino Uno. I get garbage in Serial Monitor or HyperTerminal right after I connect to the port. Here is an example code:

void setup() {
  // initialize serial:
  Serial.begin(57600);


}

void loop() {

    Serial.println("Test");
}

An example screenshot of the output. When port is re-connected the first received data is not Test:

enter image description here

So my problem is when the port is initialised the first data received is garbage. Is there a way to prevent this happening? Is that something to do with bootloader baud rate? I tried other baud rates and get same issue and I really want to use 57600 or 115200 baud rate.

6
  • I mean during Serial.begin(57600); I get garbage values. How can I skip this?
    – ty_1917
    Jan 9, 2020 at 13:51
  • @jsotola I re-articulated the problem. Please see the edit.
    – ty_1917
    Jan 9, 2020 at 21:22
  • If I comment out I get nothing. By "When port is re-connected" means clicking "call" in HyperTerminal or openning Arduino serial monitor. First data is always garbage.
    – ty_1917
    Jan 9, 2020 at 21:30
  • In HyperTerminal there is Disconnect and Call buttons which closes and initiates the port. Similar to Arduino's serial monitor. I couldnt find a fix.
    – ty_1917
    Jan 9, 2020 at 21:33
  • this may be an XY problem ... why are random characters a problem?
    – jsotola
    Jan 9, 2020 at 22:38

2 Answers 2

1

Your use of the terminology in your edited post and comments is problematic because you are not being clear enough. For example:

"I mean during Serial.begin(57600); I get garbage values. How can I skip this? " and "If I comment out I get nothing".

"By "When port is re-connected" means clicking "call" in HyperTerminal or openning Arduino serial monitor. First data is always garbage". There are others."

"An example screenshot of the output. When port is re-connected the first received data is not Test:" - But, the first received data you are showing is, in fact, the word Test.

There are others.

I will try to help by answering your main question which seems to be "How to prevent the garbage data" and note that I have not included "when the serial port is initialized".

Firstly, when I use my Uno and V 1.8.13 of the IDE, and I compile and run your sample program, I get the usual output showing progress of the compilation and upload to the board, and that text ends with "avrdude done. Thank you." At this point, the program is running and println is doing its thing.

When I open the serial monitor (by clicking on the box in the upper right corner of the full IDE screen - baud rate=57600, no line ending), I get corrupt characters at first. This always happens and I believe that is what you are seeing.

This happens because when you open the serial monitor, the UNO is being reset, but it is not the complete reset that is done when you upload code and begin execution. To be a bit simplistic, when you open the serial monitor, your program is running and the reset from opening the serial monitor is not the clean start that is done when you compile, upload and begin to execute the program.

Use either of these programs to test out what I am getting at.

void setup() {
  // initialize serial:
  Serial.begin(57600);
}

void loop() {
    delay(10000);
    while(1){
    Serial.println("Test");
    }
}

or

void setup() {
  // initialize serial:
  Serial.begin(57600);
  delay(10000);
}

void loop() {
  Serial.println("Test");
}

Go through your steps with either of these modified versions and open the serial monitor during the 10 second delay (unclick autoscroll to make it easier to see) and you will not get any corruption.

If, however, you compile/load/execute the program and then start opening and closing the serial monitor, you will start to see corruption in subsequent opens of the serial monitor - again because the reset when you open the serial monitor is not the clean reset that is done when you compile/load/execute.

Why doesn't everybody complain like crazy about the problem that you are experiencing? I think because folks learns to work with/around the way the UNO works. Your code just sends out serial data, so it is a prominent illustration of the issue, but it is not an insurmountable issue.

You can go deep into the serial monitor code and learn all about what is going on and come up with an elegant and likely tedious solution - I'm not sure, but I don't doubt that some have done this and it may even involve some hardware manipulation of serial control lines.

Alternatively, you can write the program to allow time to complete the serial monitor opening before you start sending out the data. You can even clean out any residual data (as long as you know what you are doing) if you anticipate multiple opening and closings.

Hope it helps.

0
-1

There are probably a number of reasons that might contribute to the problem that you are observing:

  1. You are trying to send the string "Text" within the main loop without any delay between println calls. So the microprocessor is running at full speed and trying to send the string "Text" much faster than the baud rate can accommodate. The serial interface has a finite I/O buffer, which is probably filling very fast and overwriting old values in the middle of serial transmission. Hence potentially garbage characters.

  2. Even when HyperTerminal is not running, the PC and Arduino are exchanging serial messages. So when you start HyperTerminal at some arbitrary time, the data in the serial buffer might not correspond cleanly to the start or end of a transmission.

As an alternative, you may want Arduino wait for a serial command from the PC before starting to send the serial data. For example, when using the Serial Monitor, you may send a key press to Arduino, which would then start sending data so that no data is lost while there is no body listening on the PC side or while a terminal program is not running.

Finally, flushing the serial buffers on either side of the serial connection might help you clear partial serial messages.

2
  • 1
    Reason 1 is not valid: Serial.println() does not overwrite bytes that have not yet been sent. It instead switches to blocking mode, where it waits for the interface to make enough room in the buffer for the new message. Jan 10, 2020 at 20:41
  • The Serial object blocks when the UART buffer is full, so no data gets overwritten in the UART buffer.
    – JRobert
    Jan 10, 2020 at 20:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.