wifi non blocking begin()

[keever50]

A very small addition where the WiFiClass begin() functions have been copied without the blocking part.
These new functions are begin_noblock.

The normal begin function blocks the microcontroller until wifi is connected. This can freeze code or trigger a watchdog.
Now using begin_noblock, the user can check for .connected themselfs.

I hope this helps!
Let me know if there are any feedback or problems

[keever50]

Ill fix the checks!

[keever50]

Passed the checks and changed the function name to beginNoBlock() like arduino style.

[earlephilhower]

I am OK with this addition, but can we do it in a way w/o lots of cut-n-paste? Maybe have the ::begin and ::beginNoBlock just call a private ::beginInternal function which takes, as a parameter, whether or not it should block? That way when changes come in there's only 1 spot to do the edits (i.e. we have done mods to WiFi for the ESP32-based wifi chips already).

[keever50]

I agree! Will do that tomorrow. Good to know you are ok with this addition

[keever50]

Added the _beginInternal to handle the normal begin. I had to modify the return values of this private in between step. Normally it returns WL_IDLE_STATUS on error, which is zero. It is the only possible error. Now it returns 1 on error, 0 on success.
But the public begin should behave as before for compatibility.

[keever50]

I didn't actually say it here, but it's so far I know ready. Anything left to change?

[earlephilhower]

Let me run it locally first, but give me a day or two, please.

[JAndrassy]

sorry, why not just use 0 timeout?

[keever50]

sorry, why not just use 0 timeout?

From my view, timeout==bad, so having a timeout out of the equation makes sense to me personally.

What if the timeout gets implemented somewhere else in the library where it is wanted? Maybe 0 timeout will conflict? A noblock function also leaves this question out of the equation.

I guess it depends on how one looks at it.

Let me know what you think

(Also, I didn't want to sound pushy on previous message. No worries, was making sure things are alright)

[earlephilhower]

Minor tweaks, but OTW LGTM.

[earlephilhower]

Actually, now that I'm back home and checking this out, it seems this is changing all the return values from the wl_definitions into bool which is not appropriate and will break things. I'll see if I can undo the changes in the GH editor...

undo

[keever50]

I replied before and exactly on the same time when you were posting your message. Yep, I got a little confused with the error logic as well. Seems like the SDK kinda tends to prefer my previous way of handling errors. Return int as error, because there are more errors than successes. But Arduino really likes bools... I am not entirely sure what is the right method at the moment.

[earlephilhower]

OK, on further re-read I see it (the public methods) does still return wl_definition values. Mybad! The internal version can return whatever we want, it's only the interface to user code that needs to be preserved.