Does the Serial buffer always get emptied after a Serial.read()?
I am expecting a response byte, before I drop into a loop
I am using Serial1.available() code example cut & paste from the reference section
I am reading this byte with Serial1.read()
I am printing this Byte to the screen
LIKE I said exactly as the Serial.available()
Now, when I read in the 8 subsequent bytes I am waiting for I actually get the response byte and then 7 new Bytes (as expected)
Am I really expected to use flush() in this scenario?
Thanks
The .flush() function has not had anything to do with the input buffer for years. These days it waits until the last OUTPUT character has left the hardware. It only flushes the output buffer.
Thank all for the replies - yeah unfortunately that's what I presumed!!!!
As a cheeky follow up - I'm also having strange results with the Serial.available() command. It doesn't seem to always detect a byte in the buffer. In the examples given in the reference section Serial.available() is used in a for loop. So on face value, to me, this is a 'polling' command - Am I right? Or does it do anything 'fancy' behind the scenes eg using interrupts?
By way of an explanation the only reliable way I have found to detect my required response byte is to include a Serial.read() in Do while loop, which I find odd.
Docara:
Thank all for the replies - yeah unfortunately that's what I presumed!!!!
As a cheeky follow up - I'm also having strange results with the Serial.available() command. It doesn't seem to always detect a byte in the buffer. In the examples given in the reference section Serial.available() is used in a for loop. So on face value, to me, this is a 'polling' command - Am I right? Or does it do anything 'fancy' behind the scenes eg using interrupts?
By way of an explanation the only reliable way I have found to detect my required response byte is to include a Serial.read() in Do while loop, which I find odd. The cheeky part is asking about something like this, without displaying your code. Of course nobody can guess what you're doing...
Serial.available() always detects a byte in the buffer. The Serial input is interrupt driven, it does not need to be polled. You are doing something wrong.
Will do however I've just been burned and lost my original code. I didn't realise the "Save when verifying and upload" option was set in preferences and have been troubleshooting the code which over wrote the original version - so I have to rewrite (and remember) my code.
Also, I've just dropped a breadboard jumper wire on my buffer chip and ...well I need to do some soldering!!!!!!
Serial1.available() is in an 'if' loop which is, on face value, continually checking if data is in the receive buffer before proceeding - is it not?
Here is the code given from the Arduino Reference what's the difference?
void setup() {
Serial.begin(9600);
Serial1.begin(9600);
}
void loop() {
// read from port 0, send to port 1:
if (Serial.available()) {
int inByte = Serial.read();
Serial1.print(inByte, DEC);
}
// read from port 1, send to port 0:
if (Serial1.available()) {
int inByte = Serial1.read();
Serial.print(inByte, DEC);
}
}
I have cut and pasted the example code into a new sketch as is and nothing, Serial.available() does not work no matter where I put it. However it does work on a genuine UNO in both Setup() or Loop()
TheMemberFormerlyKnownAsAWOL there's nothing wrong putting code in Setup() if you want it to run once
I am not using a genuine Mega - I am using a Mega Pro from RoboDyn. I wonder if the chip is genuine - any thoughts?
But I am still at a loss why Serial.available() doesn't work for me on the Mega.
I light the inbuilt LED with a serial Byte is available.
I keep the same code on the screen in my sketch and change the board from 'Uno' to Mega2560 (with 2560 processor with same Com) and the code doesn't work.
