First apologize if someone ask something similar to this before but I couldn't find anything similar.
I am working on a project which is basically a datalogger who write all the sensors information in a SD CARD every some 'x' controlled time.
Arduino only will send the information in case to one of the sensor values exceed the limits values or in case that an external device (via LabView via ZigBee technology) ask for it.
My main idea it was something similar to this:
switch(var)
{ case 'a': send_data(); case 'b': change_delay(); case 'c': change_limits() }
...and so on.
The point is that I am able to ask for it and it works the first time, but when I ask for more than one option sometimes doesn't work.
I think the problem probably it will be fixed if I could clear the Serial buffer every time after I use the serial port but until this moment I haven't been able to figure out how to do it.
If it's possible I would like if someone can tell me how to do it or if is not I would really appreciate some other idea to control it.
I'd suggest that you get rid of the String class. None of the stuff you are doing requires String objects. You can use more than one statement to write data to the file. And should.
I'd also suggest that you learn what Tools + Auto Format does, and use it before posting code. I can't read code that jumps all over the place.
Also I've edited the previous post with my code with the automatic format.
Now, if you could do something about all the blank lines, that would be good. Also, every for loop should have curly braces, even if it contains only one statement. It just makes it much clearer that you intend to repeat just the one statement, as opposed to looking like a mistake.
DateTime dt = Serial.read();
RTC.adjust(dt); //Adjust date-time as defined 'dt' above
You can't stuff a DateTime value in one byte. Serial.read() only reads one byte.
What does the sending code look like? There are plenty of statements that appear to be trying to read an int from the serial port. The Serial.read() function only returns one byte/character from the serial port. If those functions are correctly reading one binary byte from the serial port, the return type of the function should be int.
The biggest problem, though, is that none of those functions check to see if there is actually any data to read, before they read.
It's nice to provide code that implements OPs explicit request, but, it isn't clear that OP needs to clear the serial buffer. Actually reading all the data in the serial buffer properly is a much better idea. In my humble opinion.
The problem with (every form of) serial.clear() is that the buffer is only clear just after the inner loop is finished.
Before the next instruction is executed new bytes can arrive.
I agree, 'clearing the serial buffer(s) is usually a case of the creator of the sketch not understanding the serial protocol (or lack of same) being used or not using proper program flow structure in their sketch. It's a "I'm confused here and I need a get out jail card so I know from where to start again", kind of thing. A crutch, that probably does much more harm then the problem trying to be addressed.
I spent years dealing with serial communications. In that time I encountered two situations that warranted clearing a receive buffer...
We often worked with simple radios. The receiver was always on. The receiver picked up atmospheric noise and turned it into a continuous stream of garbage. The proper sequence to exchange data was: turn on the carrier, wait a few milliseconds, clear the receive buffer, transmit, turn off the carrier, sift through incoming data for a proper response.
Receive buffer overrun. If data continues to be stored after the ring buffer is full, valid data typically becomes corrupt. This problem is best solved by fixing the reading / parsing code or adding enough CPU time to handle the quantity of data.
Depends very much on how the internal buffer is implemented. IMHO the preferred implementation is to stop adding chars when the buffer is full.
That way the data in the buffer can contain complete packets. It is a waste to flush these before checking them (Checking is often faster than receiving).
Overwriting destroys data which is imho worse that ignoring.