if (Serial.available() == true); fails, is this a bug?

Just wondering if this is a bug?

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?

Serial.available() returns a number. It could be 0, it could be 1, it could be 20.

Testing for "== true" is comparing the result to 1.

This is not appropriate.

Change:

  if (Serial.available() == true) {

to:

  if (Serial.available()) {

If the ide allows me use the "true" statement, why doesn't it work?

The IDE will let you do a lot of things. They won't all "work". eg.

if (Serial.available ())
  exit (1);

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

Here's another example:

for (byte i = 0; i < 1000; i++)
    Serial.println (i);

That won't be exiting that loop any time soon. Try it and see. However the IDE "let" you do it.

hotshotharry:
Just wondering if this is a bug?

If i use if (Serial.available() == true) the code will fail at some point, usually after a few characters to read the serial,

available() returns the number of characters available, not a boolean.

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.

Nice brain teaser anyway, enjoyed the post.

Vaclav:
You sure have knack for throwing irrelevant stuff around.

I wish I was the only one.

...R

Please note that thread title itself is yet another explanation of "fail"

the original code failed because it reacted ONLY when number of characters was one

This was explained in reply #1.
Do try to keep up.

You sure have knack

Needs more article.
Definite or indefinite.

That's why it's not such a bad idea to use:

if (Serial.available() > 0) {

even though it has exactly the same effect as

if (Serial.available() ) {

Technically it is the C language or the compiler rather than the IDE.

if ((Serial.available()) == true ) {

bperrybap:
Technically it is the C language or the compiler rather than the IDE.

The IDE let you type it in, Bill. :stuck_out_tongue:

AWOL:

if ((Serial.available()) == true ) {

That won't convert it into a boolean.

if (((Serial.available() > 0) == true) == true ) {
if ((((Serial.available() > 0) == true) == true) == true ) {

I could go on for a while ...

..or just restate that Serial.available RETURNS count of characters (in buffer) ...

The issue is that majority of canned code functions return "void" as a "feedback' from executing code on hardware.

That leads to bad coding habits - operating hardware blindfolded - and common posts "it does not work".

Off my soapbox.

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)

AWOL:
Whatever that means.

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.

the original Arduino core code authors were fairly in experienced

I really can't believe that.

They just tried to insulate inexperienced users from conditions they were unlikely to . . . experience.