If i use if (Serial.available() == true) the code will fail at some point, usually after a few characters to read the serial,
byte x;
void setup() {
// put your setup code here, to run once:
Serial.begin(19200);
delay(250);
Serial.println("Ready!!!!");
}
void loop() {
// put your main code here, to run repeatedly:
if (Serial.available() == true) {
x = Serial.read();
Serial.print(" ");
Serial.print(x,HEX);
}
delay(1);
}
But if i use if (Serial.available()) the code will work,
byte x;
void setup() {
// put your setup code here, to run once:
Serial.begin(19200);
delay(250);
Serial.println("Ready!!!!");
}
void loop() {
// put your main code here, to run repeatedly:
if (Serial.available()) {
x = Serial.read();
Serial.print(" ");
Serial.print(x,HEX);
}
delay(1);
}
If the ide allows me use the "true" statement, why doesn't it work?
The function Serial.available() returns the number of bytes in the serial input buffer.
Neither of your programs represents a reliable way to receive data. It could be that the extra "== true" throws the timing off as you are using delay()
Look at the simple reliable examples in serial input basics which do not rely on timing.
Robin2:
What do you mean by "the code will fail" ?
The function Serial.available() returns the number of bytes in the serial input buffer.
Neither of your programs represents a reliable way to receive data. It could be that the extra "== true" throws the timing off as you are using delay()
Look at the simple reliable examples in serial input basics which do not rely on timing.
...R
Please revise your statement after
The function Serial.available() returns the number of bytes in the serial input buffer.
You sure have knack for throwing irrelevant stuff around.
I fully expect you ( and other people) will get upset about my remark, but I feel you need to be told.
BTW the original code failed because it reacted ONLY when number of characters was one and since read reads ONLY one character, hence when additional characters are received ( independently by hardware) the code cannot process them.
The issue is that majority of canned code functions return "void" as a "feedback' from executing code on hardware.
Whatever that means.
But clearly, a "void" function that told you how many characters were available to read would be . . . kinda pointless. (unless it returned the number available by reference)
Off my soapbox.
Hurrah!
or just restate that Serial.available RETURNS count of characters (in buffer)
Zero, or non-zero (in a Laurie Anderson "O! Superman" stylee)
Just my guess but if I were reading in between the lines....
I think what he meant was that the original Arduino core code authors were fairly in experienced when they originally defined the interfaces and wrote the code and didn't look to other better pre-existing API interfaces for a model. Better APIs that used return status codes vs just using void functions.
As a result many of the Arduino core routines and libraries SUCK when it comes to being able to tell when something goes wrong.
i.e. most of the functions were defined as void vs returning a status so you can't tell when things have issues or are not working.
This is rampant throughout Arduino.
Some of the Arduino core code and library APIs have been updated over time, and some of those updates have caused major chaos like the write() function.