When do you use the Arduino’s Serial.flush()?

In the Arduino library, the Serial object has a method called “flush().”  Often users go throwing it into programs without fully understanding what it does. It doesn’t help that it’s functionality changed when version 1.0 of the Arduino IDE was released.

Does Serial.flush() affect the Transmit Buffer or the Receive Buffer and when do you need to use it?

What does Serial.flush() do?

From the Arduino reference for Serial.flush (found on this page):

Waits for the transmission of outgoing serial data to complete.

The key to that statement is “outgoing”.   Serial.flush() doesn’t empty the “incoming” buffer as many people think.  It pauses your program while the transmit buffer is flushed.

Serial.print() / Transmits Are Interrupt Based

Something you may not realize is that when you issue a Serial.print(), that function returns almost immediately.  Instead of waiting until the string has been transmitted, print() sets up a buffer for the string, and then is transmitted via interrupts one character at a time.  This method allows your program to keep running, with the transmitting happening in the background.

A simple way to see this behavior is to send long sentences and time them,  like in the next section.

The difference between flush() and no flush()

Borrowing code from the millis() as a stopwatch example, we can see the difference between using flush() or not using flush() when sending data over Serial.

The Code Without a Flush

void setup() {
  // Give some time to open serial monitor after programming

  // Store the current time (start the clock)
  unsigned long millisNoFlushStart = millis();
  // Transmit some psuedo-random text
  Serial.println(F("How long will it take to transmit the following:"));
  // Store the current time (stop the clock)
  unsigned long millisNoFlushStop = millis();
  Serial.print(F("Without flush, Serial.println()s return control in: "));
  Serial.print( millisNoFlushStop - millisNoFlushStart);
  Serial.println(F(" milliseconds."));
void loop() {}


So this code is “done” in 20 milliseconds.  This sounds pretty good, right?  Okay, let’s look what happens if you call Serial.flush() before counting the time.

The Code WITH a Serial.flush()

void setup() {
  // Give some time to open serial monitor after programming

  // Store the current time (start the clock)
  unsigned long millisWithFlushStart = millis();
  // Transmit the same psuedo-random text as before
  Serial.println(F("How long will it take to transmit the following:"));
  // This time, let TX buffer flush before "stopping" the clock
  // Store the current time (stop the clock)
  unsigned long millisWithFlushStop = millis();

  // Print results for flushed calls
  Serial.print(F("WITH flush, Serial.println()s return control in: "));
  Serial.print( millisWithFlushStop - millisWithFlushStart);
  Serial.println(F(" milliseconds."));

void loop() {


Just by adding a Serial.flush() line, now the same code takes almost 90 milliseconds to complete!  That’s 4.5 times longer.  This difference in time may not be an issue or a problem.  However, it is a behavior to understand.  If you want your code to wait for a serial string to be finished sending, you need to make use of Serial.flush().

How do you clear the incoming Serial buffer?

Since the flush() method only clears the transmit buffer, how do you empty the receive (or incoming) buffer?  This code will do it, which you can put into a function like “flushReceive()” or something equally amusing.



For most programs, the transmit buffer is a good thing.  It’ll keep your Arduino from getting tied up waiting for Serial transfers to finish.  However, if you have critical timing mixed in with Serial.print()s, you need to keep in mind that your timing might change.  That’s where the Serial.flush() comes into play.  It gives you a chance to wait until all Serial.print()ing is done.

Long comments, URLs, and code tend to get flagged for spam moderation. No need to resubmit.

ALL comments submitted with fake or throw-away services are deleted, regardless of content.

Don't be a dweeb.

Leave a comment

47 thoughts on “When do you use the Arduino’s Serial.flush()?

  1. I have a very interesting problem for you i wonder if you might like put some light on the subject I’m using a HC05 blue-tooth module using the software serial calls on an Arduino UNO and I have found something quite strange with this Ive written the application for my mobile in android and a simple application for the Arduino It works fine connects at 9600 baud and uses default settings for stop bits etc

    I am simply turning on and off an led via the ports of the Arduino on receiving correct commands via bluetooth TX and RX

    Here is the problem Its a very perplexing but interesting problem and suggest that there is either a bug in the hardware itself or the initial serial routines haven’t been set properly

    I can obviously use both hardware ports and a virtual software port at the same time also works but there is a big huge question mark over this

    The only time the software or hardware serial port will respond to the blue tooth module is if I send a character doesn’t matter what character to the hardware port first There after this all works A ok responds to bluet-tooth data transfers and activates the LED

    What could I be doing wrong do you think

    Ive got past the problem , however Im not saying to much about the solution because in my mind I shouldn’t have to do this but i have to use additional components to solve the problem I just would like to know what you think about this and why the atmel 323p or arduino uno does this

  2. Very useful. I had problems when sending dsta over serial Bluetooth hc06. Sometimes string arrives splitted. Will try this. Thanks.

  3. Hi,
    I found this article very useful in trying to debug the serial communication to create a constant transfer per second. Unfortunately, it still creates a periodic burst of different transfers. Using the very basic code:

    void setup () {Serial.begin(9600); }
    void main () { Serial.println(“00000”); }

    sends most of the data thru at 137 lines per second. About 6% of the time (not an insignificant number when trying to collect specifically timed data) the data transmits at 141 or 142 sets of “00000” per second, which is 35 characters more per second.

    I added Serial.flush(); after the println, hoping that would make things stable, but now it seems that every 25 seconds there is a drop in the transfer down to 133 lines (sets of “00000”) per second.

    I’m using a python script to read the serial and write to a file, so i’m at a loss to understand if it is the python script or the Arduino serial.

    Considering the problem went from excess data without the flush to “missing” data with the flush, it would seem that the Arduino would be the likely cause.

    Any suggestions?

    • The Arduino is a real-time system and is not likely the issue of the bursting, on its own. The issue is either a) your Arduino code or b) something on the PC side (the driver, the OS, the language’s stack, etc… way more things to go “wrong.”).

      Serial.flush() changing the behavior suggests whatever else the rest of your Arduino code is doing, isn’t allowing the Serial’s transmit buffer to “stay full.” I’d look closer at what the rest of your code is doing and make sure it isn’t either blocking events filling the transmit buffer OR that it isn’t filling so quickly that the ISR sending serial characters is pausing.

      Running 9600 baud with “carefully timed data” seems strange to me. I’d be running 56700 or 115200.

      • Thanks for the detailed reply.

        The intent of the experiment was to determine if Arduino serial communication could be used, reliably, to collect timed sample data vs buying an expensive DAQ system. The 2 line code above is the complete code. I made sure to strip everything else out just to monitor the data streaming.

        9600 was used to get a baseline, and if 9600 has timing issues then it follows that any higher bitrate also has timing issues to varying degrees.

        Other suggested solutions to the timing problem were to add a timestamp to the serial output to mark when the data was taken, using millis() for example, vs when the data was received in the data file, trying to eliminate any bottlenecks. That solution works pretty well up to a point, until the length of runtime makes millis() a very long number (greater than 3 hours, for example) and then the overhead of sending time along with the data slows things down a bit.

        Ultimately, the fact that getting from the Arduino to an external data file has variable time steps eliminates it from heavy duty data collection work for me.

        thanks for you answer though.

        • You misunderstand my comment about going faster than 9600. It isn’t a “timing issue.” It’s math. You may be putting more data into the buffer than 9600 can transmit. When the transmit buffer is full, Serial.print() will pause until the entire string passed to it can be placed into the transmit buffer. While I would expect that to mean your Arduino continue to stream without interruption, it could give unpredictable results depending on what the rest of your code does. So in that case either fill the buffer slower or transmit the data faster. Or secret option #3, don’t send ASCII data use Serial.write() and send binary data instead.

          All that said, the Arduino isn’t going to be the issue. PC operating systems seem to buffer Serial Data / Virtual COM Ports, making them difficult to use for a real-time application without timestamps.

          To get around your sending millis() as a timestamp you have two options: 1) Pad the string so the amount of data sent is always the same (like with sprintf()) or 2) Use Grey Code and only send difference between stamps (that’s how logic analyzers usually stamp their data.)

  4. Thanks. This is really informative. I am using an Arduino Uno with a HC-06 to send the times at which a simple switch is pressed to my PC. Works fine except there are delays in receiving the data sometimes lasting 10 ore more seconds and then it starts flowing again. The data will be received fine with no delay between switch change and data arriving at the PC but then data will stop halfway through a data string, seemingly frozen for 3-12 seconds, and then in a burst the rest of the data comes through?

    The problem does not occur when I send data over the USB port – only for Bluetooth.

    Does the HC-06 have a buffer? Is there anyway to force it to continue to transmit?

    • It could be the PC’s Bluetooth driver is buffering it, could be a bluetooth connectivity issue, or it could be the module itself. I have no experience with them, so I have no idea.

  5. The Code for clearing the Input Buffer is wrong as a lot of copies in the Net. Arduino is way faster than the data arrives. So Serial.available() could be < 1 before all data is there and the while loop is finished before.
    I wonder why such a fail is widespreaded in the net.

    • No, the code for clearing the buffer is 100% correct. Your understanding of when to use it is wrong (which limits the fail to a single person.). How do you know when “all the data is there”? Unless your byte-level protocol has a method for identifying when a transmission is complete, you will never know when “all the data is there.” Clearing the input buffer does just that, empties whatever data is in the buffer at the time the while-loop runs.

      • But that is not that what most users want. If I broadcast some Data and all Clients but one should discard the data then this code won’t work. It has absolutely no use then. When should I use your code? The same wrong assumption is the while (available > 0) { read }. If there is no data and it will be, than the loop will end before all data ist there. My solution for this is to send the first Byte with the number of all next bytes. The only way for me not to send the data as a char string and to spare bytes which are used for comma separation.

        • Serial in Arduino projects is usually a peer to peer communication. You’re over complicating a simple request people have. While you probably make valid points for your corner case, they don’t apply here.

  6. I think the “how do you clear the output buffer” at the end needs to be “how do you clear the input buffer”.

  7. Hi,

    When using HC-05 and a bluetooth App to transmit a string like “hello” to an Arduino, I get the reading as * 12|99|99|hello#

    Any reason why I am getting those initial values before the string hello? How is this extra values getting into the buffer?

    The code is

    while (Serial.available()) {

    char inChar = Serial.read();

    inputString += inChar;


    Serial.println (inputString);

      • I always liked the expression;

        “Standards are wonderful, there are so many to choose from.”

        If you’re doing a straight serial read, then you’re also reading the header and trying to print meaningless (to us) data.

        If you expect the header data to be stripped off by the H/W, make sure you have compatible devices or do it yourself in S/W. There’s ACL, SCO, LMP, HCI, SDP, SMP and a whole bunch of other TLAs that packetize the data you’re transmitting that, under normal circumstances, we never see. If you examine the ISO/OSI stack, serial.read deals with the physical and data link layers while bluetooth rides up a couple of layers higher.

    • Hi, please move inputString=””; before while(….). InputString needs to be initialized in order your += expression to work. Otherwise the system is picking up some garbage for the initial value of the inputString.

  8. How big is the buffer? If you are not connected to a serial device and the code is pumping out text into the buffer what happens if you never connect back up?

    • Serial UARTs are asynchronous. The transmitting side does not wait for the receiving side to acknowledge a bit or byte has been received. I don’t remember the size of the buffer, but it is probably on the order of 64 or 128 bytes. However, the time it takes to empty that buffer will be constant only limited by the baud rate used.