Change baud rates?

PaulS: No, for two reasons. The first is the == in the middle line. That is the comparison operator, not the assignment operator.

Heh. Right you are! Oops! When I implemented it I actually did use the assignment operator, but I'm glad that you caught that!

PaulS: Certainly not using an int which can't hold 1,000,000.

Never would have caught that! I always forget about that little issue. Thanks!

PaulS: You'd look at your watch (millis()) and note what time you started waiting. Then, you'd periodically check to see if you had waited long enough.

I guess that that makes sense. That way it directly translates into something relatable. Thanks!

As for the last part, it took me a little bit of thinking, but I'm pretty sure that I understand what you are suggesting. I could use a function like this, right?

String getStatus()
{
  
  boolean done = false;
  String motorStatus;
  
  while(!done)
  {

    while(Serial.available() && !done)
    {
      char nextChar = Serial.read();
    
      if(nextChar != '\r' && nextChar != ' ')
      {motorStatus += nextChar;}
      else{done = true;}
    }

  }
  
  Serial.flush();
  motorStatus.trim();
  return motorStatus;
  
}

I know that I am back to doing blocking, but because of my application I don't really see any advantage of doing it without blocking. I can't do anything else until I have this complete message. Am I missing something?

To help explain, here is basically what I am doing:

  1. Check loop start time. (millis()).
  2. Send the command to the motor to get its position.
  3. Store the last sent location.
  4. Get the motors response from serial. -This is needed to calculate desired position-
  5. Calculate desired motor location.
  6. Wait for the loop to approach its end. (Done to provide a near constant loop time, which is important for control.)
  7. If the new location is different enough from the old location, go to it.

Thank you for all of your help!

Also, Nick! I'm pretty sure that I have the serial issue resolved. I think I really was just overloading the motor. Now that I have a rate limit on the loop I am able to run it at 19200 baud on software serial without issues. Once I get a few more bugs worked out and work on implementing the changes that Paul has suggest I'll try it at 38400 baud on the hardware serial port again. Thank you!

      if(nextChar != '\r' && nextChar != ' ')
      {motorStatus += nextChar;}
      else{done = true;}

I think that using positive logic reads better:

    if(nextChar == '\r' || nextChar == ' ')
    {
       done = true;
    }
    else
    {
       motorStatus += nextChar;
    }
  Serial.flush();

Why? Prior to 1.0, this dumps random amounts of unread data, which really doesn't seem like a good idea. After 1.0, it blocks until the buffered outgoing data has been send, which hardly seems like a necessary thing to do.

I know that I am back to doing blocking, but because of my application I don't really see any advantage of doing it without blocking. I can't do anything else until I have this complete message. Am I missing something?

Not until you add a new requirement that blocking doesn't let you support.

There are no real advantages to blocking. You don't really get to deal with the results sooner.

Good suggestions! Thanks!

As for the serial.flush(), I thought that it was used to empty the serial receive buffer, which I would like to do to avoid any unwanted characters that I don't know about. But it's not a big deal. I'll get rid of it. I guess that if it is a problem when I test it, I can just do a serial.read() until !serial.available() to clear it out. But if that is what it does, I don't see myself having to do that.

Repurposing the flush() method was not a good idea. A new function should have been added, blockUntilSendComplete() or something.

Of course, the flush() method should also have been named throwAwayRandomAmountsOfUnreadData(). I think that that would have greatly reduced the number of people that think it does something useful. Throwing away random amounts of unread data is rarely a good idea.