Is there a thing like "serial build up"?

I'm using an ESP-01 as a websocket server and it's communicating with an Arduino Nano. It's using software serial. So my client device(phone/web interface) connects and it sends a series of commands like a button being held down.

The software serial is a mess at 115200 baud rate so I just went with single characters/integers and checking/trimming... so I'll send something like this to the ESP: "F, F, F, F, F" at some fixed interval for forward.

While I have checks eg. "last command in progress", the issue is even after my client disconnects/no longer receiving commands, the motion keeps going for a bit(several seconds) then it stops... So I'm thinking maybe the serial input gets built up? I don't know if that even makes sense, or is it just my code is bad? Say I sent 10 F's and it only processed 3 F's so far and client disconnects...

I'm using while (ESPserial.available()) to get my serial data.

The motions are executed in a matter of seconds eg. 3 seconds at worst, the commands update in 40ms intervals so I don't think it's a slow response issue.

Any thoughts?

Edit:

I think I got it... the .read() (not flush) and I had to use the ESPserial.read() call. That behaves better now, seems if I give it more time to respond it's more accurate to stop eg. half a second vs. less than a tenth.

ynoloopy:
the motion keeps going for a bit(several seconds) then it stops...

Your description of the problem is not at all clear and is not helped by the fact that you did not post the program.

Incoming serial data is stored in a buffer of 64 bytes - but without seeing your code it is impossible to know how you are taking the data from the buffer.

Maybe have a look at Serial Input Basics - simple reliable non-blocking ways to receive data.

...R

To answer the question I think you are asking if you don’t empty the serial buffer as fast or faster than data is coming in then it will fill up and you will lose data.

PerryBebbington:
then it will fill up and you will lose data.

I have no idea which of us has interpreted the question correctly but I got the impression the OP was "suffering" from the opposite problem - perhaps by assuming that every read() clears the incoming data and then being surprised that further read()s can retrieve data even though he knows that the sender has stopped. Of course a read() only removes one byte from the Serial Input Buffer and the sender may have sent additional data before it stopped sending.

...R

Thanks for your responses/interest.

Yeah sorry I wasn't thinking this would become a programming question hence I posted it here. For further context here is some snippets of the code, you can also see the full repo if you're interested(it's not really a lot, but can give a better "overall picture").

So on the Nano side, the main loop() I have this:

while (ESPserial.available()) {
    // build string - used to want "Forward" but now just "F" due to software serial being unreliable
    char c = ESPserial.read();
    commandStr += c;
    appendCounter += 1;

    Serial.println(commandStr); // watching monitor not sure if this has any affect

    if (appendCounter > 1) {
      commandStr = "";
      appendCounter = 0;
    } else {
      if (commandStr.indexOf("F") > -1 && !motionInProgress) { // example command match
        // do command
        matchFound = true;
      }

      // reset call
      commandStr = "";
      appendCounter = 0;
      commandMatch = false;
    }

All of the motions use this base function that gets the array of servos to move and start/end positions.

Then in the base motion function I have an attempt to break Serial inputs since a motion takes like 3 seconds to complete and my client is sending commands every half second. I was hoping to interrupt a motion in progress at some point but need more planning on how to handle the active servo positions/gracefully change trajectory.

ESPserial.read(); // I think means it'll clear the buffer

The client socket side just sends a command every half second as mentioned by interval for now but it would actually be bound to a GUI eg. D-Pad or events(it turns out steering a slow robot like an rc car is not fun).

ESP code snippet that sends client command eg. "F" to Nano.

Edit:

yeah and looking at the main loop() code for the Nano how it uses read() maybe it doesn't make sense to expect it to empty buffer. I was reading around and thought I was going to use flush but then some people said to use read() that's why I'm here.

ynoloopy:
For further context here is some snippets of the code,

It would be more useful (and I reckon will get you to a solution more quickly) if you carefully consider Replies #1, #2 nd #3 and respond to the points they have raised. That way we will get a better idea of how you are thinking about the problem and, who knows, you might even stumble on a solution yourself. And this comment is valid (maybe even more valid) even if the earlier Replies show that we have misunderstood your problem.

...R

Yeah I get your point, it does take time to "get on the same page"/pick up the context-intent.

I am reading through that serial basics link you posted(and made ha).

64 bytes... how you are taking the data from the buffer.

I am using the while loop serial available method to pull single chars/build up a string.

...if you don't empty the serial buffer as fast or faster than data is coming in then it will fill up and you will lose data

Yeah this is some low-level territory stuff here, what is the character "F" as in terms of bytes... I'm literally just pulling a single character at this point, initially I was trying to do full words but as mentioned the software serial at my baud rate is really messy(random characters).

...perhaps by assuming that every read() clears the incoming data and then being surprised that further read()s can retrieve data even though he knows that the sender has stopped. Of course a read() only removes one byte from the Serial Input Buffer and the sender may have sent additional data before it stopped sending.

Yeah I think this describes exactly what's happening. Because even my attempts to stop backed up commands that are not processed yet in the shared base motion function, it still only removed one... so if I sent 5 commands, it processed one and cleared another one, I'd still have 3 to go, I think is what's happening.

So I'll figure out how to empty the buffer if that's possible and just read for one character. I may have to think through more with timing/response times... this is not really detrimental as I mentioned the robot is very slow so it's not like I have to stop it from breaking itself, granted it's also "dumb" currently so has no feedback/spatial awareness.

There is a piece of code in Serial Input Basics for clearing the serial input buffer.

A character such as 'F' takes up one byte of space in the buffer.

...R

Yeah it's very thorough thanks for making that.

This is probably good at this point/have my answer.

Edit:

while (Serial.available() > 0) {
    Serial.read();
}

Oh yeah that's interesting, I've seen that before but only now get what it's doing... it's still consuming the data... it just dumping it/not doing anything... vs. "magically" just clearing data. So you'd write a wrapper and call it wherever to clear the buffer.