New to the forum, but I've been working on a project with a wonderful pair of boards for a while, so I have lurked a lot. Right now, I'm looking for something that's gone, or at least not 100% clear in the documentation.
Prior to version 1 of the arduino ide, the Serial.flush() function apparently only emptied the buffer and then exited. Now, my understanding of it is it just waits for the incomming data stream to be done. This is a bit vague to me.
1: Does the current flush also empty the buffer, only now waiting for incomming data to be done comming in before it says it's done. (if not, wouldn't it be clearer to call it serial.wait?)
2: If not, what would be the quickest way to do empty said buffer while ignoring it's content.
flush waits for the transmit buffer to become empty.
To flush the input buffer, simply call "read" until it returns -1, or until "available" returns zero.
robtillaart:
you can also write your own flush for the incoming data quite easily (and adjusts its behaviour)
void myflush()
{
while (Serial.available()>0) Serial.Read();
}
but be aware that after a flush() is done there can be new bytes coming in ...
I agree writing my own flush isn't that hard. @Graynomad: Thanks.
I just have a hard time figuring out why the "flush" would more or less work like a wait and on top not even empty the buffer. (why call it flush then? not wait_empty or something)
I'm also aware more serial data may come in when I am done with the flush, but as I will then exit the interupt right after the flush, I expect the interupt would then get called again, right?
This should actually never happen, as the program I am making on the computer side isn't supposed to send data (normally) under the conditions that would cause this part of the code to get called. I'm just trying to handle errors and possible line noise here.
I just have a hard time figuring out why the "flush" would more or less work like a wait and on top not even empty the buffer.
You and everyone else except presumably the Arduino team. And to change the functionality of an existing function to something totally different is really not kosher.
why call it flush then? not wait_empty or something
Why indeed grasshopper. Arduino are not very good with their naming conventions that's for sure.
as the program I am making on the computer side isn't supposed to send data (normally)
Then you could use this code
In other words do nothing and leave any spurious bytes in the Rx buffer.
I'd rather not "do nothing" as while the code isn't "supposed" to do it, there are things that could happen where I would need the flush the buffer and ignore it's content. This includes line noise, as the function may be listening over less then perfect wires in part of my setup, as well as some idiot (namely me) making a mistake in the chatter code. Detecting those in that particular part of the code is very easy and saves processing power at the cost of a few bytes of extra firmware. Very worth it as far as I am concerned.
So if I call flush say in the Serial.event interupt, it will never return?
The serialEvent() function is NOT an interrupt handler. It is called at the end of loop(), if there is serial data to process. It is not called as soon as data arrives.
Why do you think you need a flush() function? Throwing away random amounts of unread data seems like a stupid thing to do.
there are things that could happen where I would need the flush the buffer and ignore it's content.
I was never a fan of the flush() function either in it's old or new form. It always seemed to be a solution looking for a problem and most times I've seen in used it was performing something useless or worst yet causing possible data loss. A well constructed serial protocol with clear start and end of message markers and/or check sum testing with positive ack and nak or resend requests is the solution to robust serial communications, not random flush commands performed at random times.
Because if it arrives in the conditions that will cause the flush to be called, it means something went wrong and the data is 100% certain to be invalid, either due to physical conditions (line noise) or human error. This can happen and needs to be handled gracefully. In those conditions, I want the board to both flush the data and complain, so I can do something about it upstream, depending on factors the board may not be aware of.
I guess I understood SerialEvent() wrong, but that doesn't matter much. Having it called at the end of each loop still makes my code work and actually makes a few things even simpler, so thanks for the clarification. It also means it will "handle it" again if extra data arrives after I flushed.
there are things that could happen where I would need the flush the buffer and ignore it's content.
I was never a fan of the flush() function either in it's old or new form. It always seemed to be a solution looking for a problem and most times I've seen in used it was performing something useless or worst yet causing possible data loss. A well constructed serial protocol with clear start and end of message markers and/or check sum testing with positive ack and nak or resend requests is the solution to robust serial communications, not random flush commands performed at random times.
Lefty
You are right. Doing it at "random times" is stupid. Please do not ASSUME I am being an idiot and doing it for no good reason.
it means something went wrong and the data is 100% certain to be invalid
How much of "the data" is wrong? If you can answer that 100% of the time, feel free to write your own flush() function. If not, you MUST look for the next start of packet marker to know when to stop discarding data.
there are things that could happen where I would need the flush the buffer and ignore it's content.
I was never a fan of the flush() function either in it's old or new form. It always seemed to be a solution looking for a problem and most times I've seen in used it was performing something useless or worst yet causing possible data loss. A well constructed serial protocol with clear start and end of message markers and/or check sum testing with positive ack and nak or resend requests is the solution to robust serial communications, not random flush commands performed at random times.
Lefty
You are right. Doing it at "random times" is stupid. Please do not ASSUME I am being an idiot and doing it for no good reason.
I made no such assumption, just posting my opinion that because one does not have direct control on what and when incoming serial characters arrive that flush() to me is a very 'imperfect' method to deal with serial communications. Fix it in the basic protocol agreed to by both the sender and receiver and you will have a much more efficient, reliable, and robust link. Different minds can have different opinions on the usefulness of the flush command.
it means something went wrong and the data is 100% certain to be invalid
How much of "the data" is wrong? If you answer that 100% of the time, feel free to write your own flush() function. If not, you MUST look for the next start of packet marker to know when to stop discarding data.
In the conditions that will cause it to be called, yea, 100% of the time 100% of the data is useless. The communication protocol already as clear start and end markers, as well as data validation, message tagging and the ability to complain if the data wasn't correct, so the sender will know and be able to re-send. But in working down the logical possibilities of the communication protocol I am writing, there was 1 instance where something "might" happen that I know will always be "something went very very bad and we don't want the data". In that very narrow condition, I want to just dump the data and complain. I don't want to return the "crap data" because it is likely to contain random bits and I only see downsides to sending it back in that condition.
there are things that could happen where I would need the flush the buffer and ignore it's content.
I was never a fan of the flush() function either in it's old or new form. It always seemed to be a solution looking for a problem and most times I've seen in used it was performing something useless or worst yet causing possible data loss. A well constructed serial protocol with clear start and end of message markers and/or check sum testing with positive ack and nak or resend requests is the solution to robust serial communications, not random flush commands performed at random times.
Lefty
You are right. Doing it at "random times" is stupid. Please do not ASSUME I am being an idiot and doing it for no good reason.
I made no such assumption, just posting my opinion that because one does not have direct control on what and when incoming serial characters arrive that flush() to me is a very 'imperfect' method to deal with serial communications. Fix it in the basic protocol agreed to by both the sender and receiver and you will have a much more efficient, reliable, and robust link. Different minds can have different opinions on the usefulness of the flush command.
Lefty
Well, I already have ack/nack and even data validation. But at one point in my code, there is 1 place where if the right condition is met, I know 100% something went wrong, so I have no use for any kind of information I might have gotten, as I know it's bad. So I just want to flush the entire buffer and say "this went wrong, try again"
Since the flush() function only affected data that had already arrived, but not been yet been read, how can you assume that that unread data constituted the rest of the packet AND NO OTHER DATA?
Like I said, this is error handling. If I am getting a packet of information under the very narrow condition, it means that while the system at the other end knows I am not in a condition to get information, it still tries to send it. The other end should know better then to talk to me, because I haven't finished processing the last message it sent and I haven't told it "I got the message".
This means I know the other end wasn't supposed to send me data, so I am either seeing a bug or line noise. In both cases, I don't have any valid reason to bother checking what I just got, because it can't be valid. I do, however, want someone to know what happened. So, I complain to the computer and flush the data. If action needs to be taken to have the data re-transmited, that's the computer's job, not the board's.