Yun wifi connectivity issues

You can try the hourly build version of the Arduino IDE. It has some fixes that improve the network discovery.

:D :D HOURLY BUILD WORKED !!!!!!!!!!!!! :D

THANK YOU ;D ;D MY YUN IS WORKING GREAT and uploading sketches over wi-fi

I was half Correct

i made 2 YouTube videos so you could see if i'm missing something, or if this would benefit the correction process.

https://www.youtube.com/watch?v=KSTtAM3J9xc

here is the second one

https://www.youtube.com/watch?v=tuqHEHvIA_Y

markgrecowork: ::::SNIP::::

https://www.youtube.com/watch?v=KSTtAM3J9xc

here is the second one

https://www.youtube.com/watch?v=tuqHEHvIA_Y

@markgrecowork,

Great work!! I looked at both videos. I did not hear everything clearly, but I believe you used ConsoleAsciiTable.ino and WifiStatus.ino in both videos.

First, welcome to the Linux/Unix world of programming. You'll find more freedom with what you do, once you understand a few basics.

Next, what you hit is a documentation failure. This is a common problem that needs to be clarified in the examples.

In the code, you will find two similar lines. In the setup of ConsoleAsciiTable.ino you will find:

  while (!Console) {
    ; // wait for Console port to connect.
  }

In the setup of [u]WifiStatus.ino[/u] you will find:

  while (!Serial);     // do nothing until the serial monitor is opened

In the first sketch (ConsoleAsciiTable.ino), it is waiting for the Console to open. And as I look at the code I see a bug. A bug written into the example.

However, somehow, the c++ object is written such that it is equivalent to Console.available() and in the second sketch Serial.avilable(). This should be corrected, but it works.

As such, Console waits for the wifi console to open (which you open under the menu as Tools->Serial Monitor). The same goes for Serial.

To be clear, what is happening is in the first sketch, the (wifi) Serial Monitor waits at that spot until the (wifi) Serial Monitor is open. And since you are don't see the wifi connection under Tools->Port, then there is no way to see anything with the sketch - ConsoleAsciiText.

The same goes for the following sketches.

  • ConsoleAsciiText
  • ConsolePixel
  • ConsoleRead

Like I said the documentation is lacking here. If this is not clear, please ask more questions.

Jesse

jessemonroy650: In the first sketch (ConsoleAsciiTable.ino), it is waiting for the Console to open. And as I look at the code I see a bug. A bug written into the example.

However, somehow, the c++ object is written such that it is equivalent to Console.available() and in the second sketch Serial.avilable(). This should be corrected, but it works.

No, it is not equivalent. Both sketches are checking whether the port is connected. The .available() functions check whether the port has data in the receive buffer waiting to to be processed, which is not the same concept.

The classes have a definition for operator bool() which is called when there is an explicit or implicit conversion from the stream class to a bool value. This type conversion operator is implicitly called before the not (!) operator in the while statement is performed. This is how the syntax of doing a while not of the serial/console object is syntactically allowed, and how it determines if a connection has been made.

ShapeShifter:
No, it is not equivalent. Both sketches are checking whether the port is connected. The .available() functions check whether the port has data in the receive buffer waiting to to be processed, which is not the same concept.

The classes have a definition for operator bool() which is called when there is an explicit or implicit conversion
::::SNIP:::

@ShapeShifter,
Thanks for the clarification. As I think I stated, I don’t use this much. I knew I should have left this one for you. :wink:

On the point, using a Constructor as a boolean is bad form. Has anyone at Arduino talked about fixing this?

TIA
Jesse

jessemonroy650: On the point, using a Constructor as a boolean is bad form. Has anyone at Arduino talked about fixing this?

It's not a constructor, the statement is simply using the name of the stream object, and casting the object type to a boolean. The constructor had been called long before the setup() function was ever called. You can tell it's not a constructor call two ways: there is no parentheses after the object name, and the Serial name is not a class name (the actual class name is HardwareSerial.) So it's simply referencing the previously instantiated class instance.

It looks like what they were going for was a similar concept to where you can check whether a pointer to an object is valid or not (is it NULL or not?) However, since the Serial and Console objects are actual object instances and not pointers, they used the bool() operator as a shortcut. If you think of a scenario where you have pointer to an object that is NULL before it is connected, and non-NULL when it has been connected, and that is what they are trying to simulate, the syntax makes more sense.

While it's not how I would've done it, I don't think what they are doing is really that bad. But the intent would certainly be more apparent if they had used a function named connected() instead of the cryptic bool cast operator. It also would probably have created less confusion like this thread, as the intent of the loop would be much clearer. That model of testing whether the serial port has been connected has been around so long, I think it would be an uphill battle to try and change it now.

ShapeShifter: It's not a constructor, the statement is simply using the name of the stream object, and casting the object type ::::SNIP::::

@ShapeShifter, I'm sure we agree in principal, but not words. The object is clearly labelled a constructor. An while the Object does not have parentheses, technically it is NOT a constructor, but an object. I think working with multiple different languages makes me irritated when I see this. It is not just sloppy, but confusing - as you have stated.

On fixing it, I disagree. I think getting a clear label on it will go along way. Crytic overloading is what gives C & C++ a bad name. Then again, the authors have stated this C++-like. FWIW: if you ever want to see a language develop well take a look at Javascript. When I started with it in 95 it was a joke. Today the evolution makes it practical and useful.

Respectfully Jesse

jessemonroy650: The object is clearly labelled a constructor.

Where? I don't see that in the examples.

THIS PAGE lists all of the classes and many of the functions. For several of them (Bridge, Process, and Console) it lists a link for "constructor" but following that link you get a class overview, just like you do for those classes that don't show the word "constructor" on the overview link. I feel that is incorrect, but then again the whole documentation is somewhat lacking: without analyzing the limited examples, it's tough to get a feel for what the classes and methods really do.

If there's somewhere where you're finding the while (!Console); construct labeled as a constructor, I'm just not seeing it.

Crytic overloading is what gives C & C++ a bad name.

It is what it is. I think you will have an uphill battle changing the use of the class bool() operator, but I don't think you have the slightest chance of reforming C++ to match your views; you're destined to be forever irritated by it. ;) :neutral_face: