user10236: I have a Yun that accepts commands via the bridge (note the below code is part of a very simple virtual keyboard that accepts commands then runs Keyboard.println on them:
#include <stdlib.h>
#include <string.h>
HardwareSerial *port;

void setup() {
  port = &Serial1;
  port->begin(9600);
}

void loop() {
  if (port->available()) {
    String cmd = port->readString();

    if(cmd.length() > 1){
      String instruction = cmd;
      int arg_comma_index = 0;
      arg_comma_index = instruction.indexOf(",");
      String func = instruction.substring(0, arg_comma_index);
      String args = instruction.substring(arg_comma_index + 1, instruction.length() + 1 );

      Keyboard.begin();
      Keyboard.println(args);
      Keyboard.end();
    }
    port->read(); // Try to throw away whatever's left to prevent looping (which is still happening).
  }
}

If I send it a short string:  

The first time, immediately after starting the sketch, it works.
The second time, it works but loops anywhere from 1-5 times.
The third time, it loops more times still.
If I leave the device running (even if not operating it), the number of times it loops goes up when I finally do send it an instruction. I'm seeing 20-75 loops after less than 15 minutes of uptime.

Clearly the loops where no instruction is being received are still building up something here. I've tried:

Restarting the port each void loop().
Flushing the port at the top and/or bottom of each void loop().
Setting cmd = "" at the end of each void loop().
Checking peek(), available(), and readString() - after I send it one instruction, they return the same values every single time they loop.


user4143: It's quite simple to empty the serial buffer - you just read all the data that is in the buffer and throw it away:
while (port->available()) {
    port->read();
}


user10794: I wouldn't be using readString myself. In fact I wouldn't be using the String class at all. readString keeps reading until it times out (by default after one second), so it may read more - or less even - than you want. It will also introduce a one-second delay while it sits around waiting for that second to elapse.
You are much better off doing a non-blocking loop, and then processing data when you get a known delimiter, like a newline or comma, or whatever you designate as "ending the stream". Example code that uses a newline delimiter:
// how much serial data we expect before a newline
const unsigned int MAX_INPUT = 50;

void setup ()
  {
  Serial.begin (115200);
  } // end of setup

// here to process incoming serial data after a terminator received
void process_data (const char * data)
  {
  // for now just display it
  // (but you could compare it to some value, convert to an integer, etc.)
  Serial.println (data);
  }  // end of process_data

void processIncomingByte (const byte inByte)
  {
  static char input_line [MAX_INPUT];
  static unsigned int input_pos = 0;

  switch (inByte)
    {

    case '\n':   // end of text
      input_line [input_pos] = 0;  // terminating null byte

      // terminator reached! process input_line here ...
      process_data (input_line);

      // reset buffer for next time
      input_pos = 0;  
      break;

    case '\r':   // discard carriage return
      break;

    default:
      // keep adding if not full ... allow for terminating null byte
      if (input_pos < (MAX_INPUT - 1))
        input_line [input_pos++] = inByte;
      break;

    }  // end of switch

  } // end of processIncomingByte  

void loop()
  {
  // if serial data available, process it
  while (Serial.available () > 0)
    processIncomingByte (Serial.read ());

  // do other stuff here like testing digital input (button presses) ...

  }  // end of loop

In my example code you would do whatever-it-is you want in process_data which is called once an entire line arrives. Then you don't need to discard incoming data (empty the serial buffer), which seems to me to be a bad idea anyway.

10236: 

<p>I have a Yun that accepts commands via the bridge (note the below code is part of a very simple virtual keyboard that accepts commands then runs <code>Keyboard.println</code> on them:</p>

<pre class="lang-C++ prettyprint-override"><code>#include &lt;stdlib.h&gt;
#include &lt;string.h&gt;
HardwareSerial *port;

void setup() {
  port = &amp;Serial1;
  port-&gt;begin(9600);
}

void loop() {
  if (port-&gt;available()) {
    String cmd = port-&gt;readString();

    if(cmd.length() &gt; 1){
      String instruction = cmd;
      int arg_comma_index = 0;
      arg_comma_index = instruction.indexOf(",");
      String func = instruction.substring(0, arg_comma_index);
      String args = instruction.substring(arg_comma_index + 1, instruction.length() + 1 );

      Keyboard.begin();
      Keyboard.println(args);
      Keyboard.end();
    }
    port-&gt;read(); // Try to throw away whatever's left to prevent looping (which is still happening).
  }
}
</code></pre>

<p>If I send it a short string:  </p>

<ul>
<li>The first time, immediately after starting the sketch, it works.</li>
<li>The second time, it works but loops anywhere from 1-5 times.</li>
<li>The third time, it loops more times still.</li>
<li>If I leave the device running (even if not operating it), the number of times it loops goes up <em>when</em> I finally do send it an instruction. I'm seeing 20-75 loops after less than 15 minutes of uptime.</li>
</ul>

<p>Clearly the loops where no instruction is being received are still building up something here. I've tried:</p>

<ul>
<li>Restarting the port each <code>void loop()</code>.</li>
<li>Flushing the port at the top and/or bottom of each <code>void loop()</code>.</li>
<li>Setting <code>cmd = ""</code> at the end of each <code>void loop()</code>.</li>
<li>Checking <code>peek()</code>, <code>available()</code>, and <code>readString()</code> - after I send it one instruction, they return the same values every single time they loop.</li>
</ul>
 4143: <p>It's quite simple to empty the serial buffer - you just read all the data that is in the buffer and throw it away:</p>

<pre><code>while (port-&gt;available()) {
    port-&gt;read();
}
</code></pre>
 10794: 

<p>I wouldn't be using readString myself. In fact I wouldn't be using the String class at all. <code>readString</code> keeps reading until it times out (by default after one second), so it may read more - or less even - than you want. It will also introduce a one-second delay while it sits around waiting for that second to elapse.</p>

<p>You are much better off doing a non-blocking loop, and then processing data when you get a known delimiter, like a newline or comma, or whatever you designate as "ending the stream". Example code that uses a newline delimiter:</p>

<pre class="lang-C++ prettyprint-override"><code>// how much serial data we expect before a newline
const unsigned int MAX_INPUT = 50;

void setup ()
  {
  Serial.begin (115200);
  } // end of setup

// here to process incoming serial data after a terminator received
void process_data (const char * data)
  {
  // for now just display it
  // (but you could compare it to some value, convert to an integer, etc.)
  Serial.println (data);
  }  // end of process_data

void processIncomingByte (const byte inByte)
  {
  static char input_line [MAX_INPUT];
  static unsigned int input_pos = 0;

  switch (inByte)
    {

    case '\n':   // end of text
      input_line [input_pos] = 0;  // terminating null byte

      // terminator reached! process input_line here ...
      process_data (input_line);

      // reset buffer for next time
      input_pos = 0;  
      break;

    case '\r':   // discard carriage return
      break;

    default:
      // keep adding if not full ... allow for terminating null byte
      if (input_pos &lt; (MAX_INPUT - 1))
        input_line [input_pos++] = inByte;
      break;

    }  // end of switch

  } // end of processIncomingByte  

void loop()
  {
  // if serial data available, process it
  while (Serial.available () &gt; 0)
    processIncomingByte (Serial.read ());

  // do other stuff here like testing digital input (button presses) ...

  }  // end of loop
</code></pre>

<p>In my example code you would do whatever-it-is you want in <code>process_data</code> which is called once an entire line arrives. Then you don't need to discard incoming data (empty the serial buffer), which seems to me to be a bad idea anyway.</p>
