Go Down

Topic: Arduino-1.0 Serial.flush() (Read 4 times) previous topic - next topic

sleahey

Soooo,

Serial.flush()

As detailed in the Arduino 1.0 release notes;
* Serial transmission is now asynchronous - that is, calls to
  Serial.print(), etc. add data to an outgoing buffer which is transmitted
  in the background. Also, the Serial.flush() command has been repurposed
  to wait for outgoing data to be transmitted, rather than dropping
  received incoming data.


This seems really dumb. If one were to make a new function, IT SHOULD HAVE A DIFFERENT NAME! why sacrifice this existing function, to add another one? It's basically ridiculous this change got passed.

It would be of no consequence to have this new function called something like Serial.WaitForTx();


It's simple to resolve this with the standard API calls but here is a slow and dirty method, and frankly unreliable because you can get stuck here!

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

Or, for those of you a little more enthusiastic, you can modify the Arduino source back to how it used to be!
Open
\arduino-1.0\hardware\arduino\cores\arduino

Add this to HardwareSerial.h within the class definition
virtual void Iflush(void);

Add this to function to HardwareSerial.cpp in the body
void HardwareSerial::Iflush()
{
  _rx_buffer->head = _rx_buffer->tail;
}

Save files and recompile - you can now use Iflush in place of what used to be flush.
Tested and working fine.

PaulS

I partially agree that re-purposing Serial.flush() was a bad idea. But, it was frequently misused.

I also disagree with this:
Quote
and frankly unreliable because you can get stuck here!

How? If there is serial data to read, it is read and discarded. If there is no serial data, there is nothing to do, so the while loop doesn't get executed. How can you possibly get stuck? Neither Serial.available() or Serial.read() are blocking functions.


sleahey

Quote
If there is no serial data, there is nothing to do, so the while loop doesn't get executed. How can you possibly get stuck? Neither Serial.available() or Serial.read() are blocking functions.


Noted. You are right. But that bit of code is still a crummy solution.

PaulS

Quote
But that bit of code is still a crummy solution.

Not an ideal solution, perhaps. but I don't think it's all that bad.

First, the buffer size if only 128 bytes. It wouldn't take that long to read and discard the entire buffer.

Second, there are very few legitimate uses of the flush function. Throwing away random amounts of unread data is hardly ever a good idea. At least with that code, you could compare the character read to some start- or end-of-packet marker, and stop throwing the characters away when you got back in sync, after encountering a bad packet.

sleahey

Quote
First, the buffer size if only 128 bytes. It wouldn't take that long to read and discard the entire buffer.

It's just poor design to let it be done this way. Ultimately, it's these kind of compromises that will make Arduino get even slower than it already is.
Don't get me wrong, I <3 Arduino. :smiley-mr-green: :smiley-mr-green: :smiley-mr-green:

Quote
Second, there are very few legitimate uses of the flush function.

At a user sketch level its totally valid. If you have a particularly verbose module, it can be constant spewing stuff into the serial port. If you are only interested in query-response, then you would want to be able to flush the serial buffer.

Go Up