next topic »

[on:]

What will Serial.flush() do in the release version of 1.0?

The old Serial.flush() did this:

Flushes the buffer of incoming serial data. That is, any call to Serial.read() or Serial.available() will return only data received after all the most recent call to Serial.flush().

Serial.flush() in 1.0 beta waits for the output buffer to be empty.

Code:

void HardwareSerial::flush()
{
  while (_tx_buffer->head != _tx_buffer->tail)
    ;
}

What is the replacement for the old flush()?

[Reply #1 on:]

That seems pretty strange, how would it ever return if no chars are received? And if chars are received you'd have to wait for the buffer to fill.

That can't be right.

The old flush did this

 _rx_buffer->head = _rx_buffer->tail;

______
Rob

[Reply #2 on:]

Serial now has a output buffer and is interrupt driven.  flush() now waits for the output buffer to empty.

Needless to say this was a surprise since flush() previously set the input buffer empty.

Hope 1.0 doesn't have too many more like this.

It certainly is a challenge to make a library work with both 0022 and 1.0 beta. 

[Reply #3 on:]

flush() now waits for the output buffer to empty.

That's ludicrous, interrupts or no interrupts something called "flush" should do just that, and I see no reason it shouldn't.

I can see a good reason for a function that waits until the buffer is empty, but it should not be called "flush" especially when it overloads an old function with the same name but totally different functionality.

______
Rob

[Reply #4 on:]

I'm still waiting to see an application where using a flush() is a useful and proper operation. I have seen it misused a lot, one beginner around here was doing a flush() before each and every character read he performed. It's seems to be one of those functions that sounds powerful and useful, but so often misapplied and misunderstood.

And if I did every find a use for flush(), I would want it to either wait for the transmitting buffer to complete sending any characters I had sent out before flushing anything. While I have difficulty seeing the usefulness of flushing the receive buffer, I can't ever imagine wanting to flush output characters that I had sent before they actually leave the chip. 

[Reply #5 on:]

I recall using a flush() once for baudrate detection, before my Arduino period started ..

I entered AAAAAAAAAAAAAAAA until the application detected it. "arduinized" code was something like this:

Code:

long baudRates[] = { 1200,2400,9600, ..., -1}  // -1 is a sentinel

long setBaudRate()
{
  for (int i=0; baudRates[i] != -1; i++)
  {
    long br = baudRates[i];
    Serial.begin(br);
    Serial.flush();    // remove junk from buffer
    while (!Serial.Available());
    c = Serial.Read();
    if (c== 'A') return br;
}

There are other methods to detect baudrate by checking edges; these are especially usefull to detect non standard baudrates, or deviating clocks.


Furthermore flush() can make sense after a soft reset in application,


what to think about a parameterized flush() ???

Code:

void flush (uint8_t n=MAXBUF)
{
  if (n > available()  ) _rx_buffer->head = _rx_buffer->tail;
  else while (n-- > 0 && available()) read();      // can be done in one formula no doubt
}

[Reply #6 on:]

My preference is for descriptive method names...
clearRecieveBuffer()
waitForSendBufferToEmpty()

Flush is something one does with a toilet.

[Reply #7 on:]

 retrolefty,

I have used Serial.flush() in two ways.  

One - part of a soft reset to restart a program after an error.

Two - to throw away unwanted output, such as firmware version, from a GPS module when I initialize it.

I am replacing Serial.flush() with

Code:

 while (Serial.read() >= 0);

I don't like the name flush().  I used in in the I/O streams part of SdFat since it is part of the C++ standard.  you can force buffers to be written like this:

Code:

outstream << mydata << moredata  << flush;

Arduino 022 uses it to discard input in Serial and to force an output buffer to be written in SD.h.

[Reply #8 on:]

My preference is for descriptive method names...
clearRecieveBuffer()
waitForSendBufferToEmpty()

Definitely better

[Reply #9 on:]

I guess none of this should have been a surprise to me.  The Arduino team made these changes after careful consideration.

http://code.google.com/p/arduino/wiki/Arduino1