You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is the bool operator for the class.
If you look in the header you will see it has not been defined.
In creating an example, I also noticed that the example that comes with SoftwareSerial is also
not a good example since it is also using HardwareSerial
Go look at the SoftSerialExample code that comes with either 1.0.6 or 1.6.0 IDE.
(This bool issue and example issue exists in both)
In that SoftSErialExample.ino sketch you will see this code in setup:
void setup()
{
// Open serial communications and wait for port to open:
Serial.begin(57600);
while (!Serial) {
; // wait for serial port to connect. Needed for Leonardo only
}
That line boolean check is using the bool operator from HardwareSerial.
if you change that to mySerial to use the local SoftwareSerial object you will
see the problem of the missing bool operator.
Using the boolean operator on a SoftwareSerial object will not compile since
the bool operator in SoftwareSerial is not implemented.
It seems to be a poor example for SoftwareSerial to use the HardwareSerial class.
The example should not need to wait on the USB interface to demonstrate
the software serial in this sketch since it is only using SoftwareSerial which doesn't
need any USB support.
For sure, you shouldn't have to use and drag in all the HardwareSerial code to use SoftwareSerial.
This also brings up a somewhat unrelated item, and this is that there
is no way to determine if a HardwareSerial or SoftwareSerial object has
been properly initialized.
The constructor cannot return a status to return whether the constructor
used proper parameters. The real problem is that begin() is a void.
begin() really needs to return a status.
It should return 0 if the begin() worked and the class is initialized and ready to use, or some non zero
error status value indicating the error status.
As a result, the sketch cannot tell if the begin() failed.
The only reason that I said that this other issue is related to the missing bool operator is
because the bool operator could look to see if begin() succeed and return 0 if it didn't
rather than always returning true the way it does in HardwareSerial.
Doing this would cause code that is waiting for the interface to be ready tol hang
which is very non optimal but without correcting begin() to return a status, the only
other way for a sketch to detect the begin() failed is that all its serial output is either
garbage or dropped on the floor.
This is what happens when say an invalid pin # is used in softwareSerial or invalid/unsupported
baud rates were chosen.
The real solution is to change begin() to return a non zero status when the begin() fails.
However, that discussion is outside the scope of this SoftwareSerial bool issue.
However, we need to discuss more about what user expects from the bool operator (return true if the object exists or return true if the begin() phase ended correctly).
I would say that the bool operator means that the object exists and the API is ready so returning
true for this type of object seems appropriate.
I think overloading the return value of the bool operator with internal status of begin() or the
constructor state seems to be complicated and is likely to be confusing to people
since it really can't indicate what the problem really is.
That and any code that spins on the status of the bool operator waiting for the interface to be "ready"
will simply hang and not know that it is due to a bad constructor or begin() call.
To handle initialization issues, my preference would be handle it properly and
to eventually change the begin() functions to return a status indicating what failed.
i.e. begin() or constructor parameter issues etc..
This issue should probably be marked closed and then create a new issue (feature request)
that asks for begin() API calls to return status values to indicate when things didn't properly
initialize.
Further discussion could continue in the new feature request issue as to how to communicate
constructor and begin() issues to the sketch code.
Activity
ffissore commentedon Feb 27, 2015
Can you share a small sketch we can use to test the fix?
bperrybap commentedon Feb 27, 2015
It is the bool operator for the class.
If you look in the header you will see it has not been defined.
In creating an example, I also noticed that the example that comes with SoftwareSerial is also
not a good example since it is also using HardwareSerial
Go look at the SoftSerialExample code that comes with either 1.0.6 or 1.6.0 IDE.
(This bool issue and example issue exists in both)
In that SoftSErialExample.ino sketch you will see this code in setup:
That line boolean check is using the bool operator from HardwareSerial.
if you change that to mySerial to use the local SoftwareSerial object you will
see the problem of the missing bool operator.
Using the boolean operator on a SoftwareSerial object will not compile since
the bool operator in SoftwareSerial is not implemented.
It seems to be a poor example for SoftwareSerial to use the HardwareSerial class.
The example should not need to wait on the USB interface to demonstrate
the software serial in this sketch since it is only using SoftwareSerial which doesn't
need any USB support.
For sure, you shouldn't have to use and drag in all the HardwareSerial code to use SoftwareSerial.
This also brings up a somewhat unrelated item, and this is that there
is no way to determine if a HardwareSerial or SoftwareSerial object has
been properly initialized.
The constructor cannot return a status to return whether the constructor
used proper parameters. The real problem is that begin() is a void.
begin() really needs to return a status.
It should return 0 if the begin() worked and the class is initialized and ready to use, or some non zero
error status value indicating the error status.
As a result, the sketch cannot tell if the begin() failed.
The only reason that I said that this other issue is related to the missing bool operator is
because the bool operator could look to see if begin() succeed and return 0 if it didn't
rather than always returning true the way it does in HardwareSerial.
Doing this would cause code that is waiting for the interface to be ready tol hang
which is very non optimal but without correcting begin() to return a status, the only
other way for a sketch to detect the begin() failed is that all its serial output is either
garbage or dropped on the floor.
This is what happens when say an invalid pin # is used in softwareSerial or invalid/unsupported
baud rates were chosen.
The real solution is to change begin() to return a non zero status when the begin() fails.
However, that discussion is outside the scope of this SoftwareSerial bool issue.
facchinm commentedon Mar 6, 2015
Main issue (API inconsistency) fixed in b95533f
However, we need to discuss more about what user expects from the bool operator (return true if the object exists or return true if the begin() phase ended correctly).
Thus not marking as closed
bperrybap commentedon Mar 6, 2015
I would say that the bool operator means that the object exists and the API is ready so returning
true for this type of object seems appropriate.
I think overloading the return value of the bool operator with internal status of begin() or the
constructor state seems to be complicated and is likely to be confusing to people
since it really can't indicate what the problem really is.
That and any code that spins on the status of the bool operator waiting for the interface to be "ready"
will simply hang and not know that it is due to a bad constructor or begin() call.
To handle initialization issues, my preference would be handle it properly and
to eventually change the begin() functions to return a status indicating what failed.
i.e. begin() or constructor parameter issues etc..
This issue should probably be marked closed and then create a new issue (feature request)
that asks for begin() API calls to return status values to indicate when things didn't properly
initialize.
Further discussion could continue in the new feature request issue as to how to communicate
constructor and begin() issues to the sketch code.
facchinm commentedon Mar 6, 2015
👍 Marking as closed and waiting for the feature request