Hi, I am trying to use my xbees to send messages to my arduino with xbee shield and xbee and the other xbee (router) connected on xbee explorer using usb and hyper terminal. I wrote this sketch below and I can type stuff and it appears (just using the TX to my lcd) but I can't clear it. I tried using the flush command but it won't work? any advice? Also is there another way to get the serial data besides the serial buffer and directly plugging into the rx and tx data lines, Like could I store all incoming serial data in a variable?
void setup() {
Serial.begin(9600); //initialize serial
}
void loop() {
while(Serial.available()){ //is there anything to read?
char getData = Serial.read(); //if yes, read it
Serial.print(getData);
if (getData) {
Serial.flush(getData);
}
}
}
Why do you think you need to "clear the buffer"? Reading the data in the buffer makes a hell of a lot more sense. Don't send data to the Arduino that you don't want it to have to read.
PaulS:
Why do you think you need to "clear the buffer"? Reading the data in the buffer makes a hell of a lot more sense. Don't send data to the Arduino that you don't want it to have to read.
Well, not sure what OP means by "trying to clear LCD", but there are sensors that just self triggers on a timer and spit out data to the serial port and fill up the buffer. Sometimes I clear it too, before I wait for a complete data point. I have Maxbotix serial sonic rangers that will do this if they are in the free-running mode.
steinie44:
If data, then read it, but don't save or print it.
I tried that approach in the past and it didn't seem to work. The instance was trying to use a carriage return byte as a data packet delimiter while getting rid of the associated line feed byte. Seemed like just reading the byte didn't remove it from the serial input buffer.
Seemed like just reading the byte didn't remove it from the serial input buffer.
It does. The read() method really should have been called pop().
You'd need to post some code that illustrates the problem.
That's when you have the capability to push. The Stream class is two FIFO with ring buffers each, not some stack with one LIFO buffer. That's logic mixup Paul.
How do you supposed data gets into the serial buffer?
The Serial receive code is designed for only the main program to remove data from the buffer, and only the interrupt routine to add data to the buffer. If you add code in the non-interrupt context which modifies the "head" index, which today is only written by the interrupt context, you'd disturb the careful design which avoids extra overhead of disabling interrupts while manipulating the buffer, and head and tail index.
Certainly it's possible to put data back into the input buffer, but not a simple addition. As soon as you write to the head index from the main program, or to the tail index in interrupt context, the entire design needs to be carefully analyzed and/or guarded by interrupt disable. In a best case scenario, such a seemingly simple feature would cost quite a bit of extra code/overhead. In a worst case scenario, such a chance could easily introduce difficult-to-troubleshoot bugs to the serial code.
The Serial receive code is designed for only the main program to remove data from the buffer, and only the interrupt routine to add data to the buffer. If you add code in the non-interrupt context which modifies the "head" index, which today is only written by the interrupt context, you'd disturb the careful design which avoids extra overhead of disabling interrupts while manipulating the buffer, and head and tail index.
Certainly it's possible to put data back into the input buffer, but not a simple addition. As soon as you write to the head index from the main program, or to the tail index in interrupt context, the entire design needs to be carefully analyzed and/or guarded by interrupt disable.
The point was that the serial interrupt pushes data into the incoming buffer, and Serial.read() pops it out. Had the Serial.read() method been called Serial.pop(), it would have been clear that the function removes data from the buffer. There seems to be a lot of confusion, among newbies (and some not so new people) as to exactly what Serial.read() does.
zoomkat:
The instance was trying to use a carriage return byte as a data packet delimiter while getting rid of the associated line feed byte. Seemed like just reading the byte didn't remove it from the serial input buffer.
I don't remember the author, but I've seen code posted that looked as if it was intended to interpret cr, nl sequences as a terminator which was coded in such a way that it would only work when they arrived in a particular order, and the assumed order did not match the DOS convention. This sort of bug might give similar symptoms to what you saw.
My preferred approach in that situation is to treat either cr or nl as a terminator, but also discard empty messages, so that any contiguous sequence of cr and nl would act as a valid terminator.
I think it's extraordinarily unlikely that the HardwareSerial class is leaving a received byte in the buffer after it has been read.
Paul, I wasn't trying to argue academic but push/pop are terms for operating on one end of a list, while the other end is fixed. And read reads head end while new data come in the tail end via interrupt. Different structures, different terms, get it?
The point was that the serial interrupt pushes data into the incoming buffer, and Serial.read() pops it out. Had the Serial.read() method been called Serial.pop(), it would have been clear that the function removes data from the buffer.
Well, that would confuse the hell out of me, because "push" and "pop" are operations that I associate with a last-in-first-out "stack" data structure (just like the push and pop assembly instructions on AVR.) That isn't at all how the serial buffer works! (yeah, I've noticed that some C++ and Java standard "containers" implement push/pop for non-FIFO access. What an awful idea!)
Clearing the serial input buffer is a fairly flawed idea. You don't/can't know how much data is still "in transit" somewhere in the communications path. It's much better to read the data and look for particular data patterns that will tell you exactly where you are.
When I open Serial Monitor there is sometimes garbage that I take to be serial buffer data at the PC end.
It would be nice if Serial Monitor cleared that at the PC end.