I have been having a play with my Yun and seem to be having an issue with the HttpClient sketch which once running seems to crach after about 3 cycles (sometimes 4 or 5). Basically this seem to happen even when running on my laptop:- windoz7 and main system:Xp connecting to the Yun via USB and monitoring the Yun via the IDE serial monitor (and third party 'Clear terminal' port monitoring softwear).
I have not modified the sketch in any way. It runs, for about 3 cycles, pauses, and then prints the same rubbish, again and again.
Is there a server limit on the file http://arduino.cc/asciilogo.txt ? I'd hate to do a fault finding exercise only to find there is a limit..
I'm also having some problems with USB uploading and the board dropping in and out of the USB system, but I'm going to do more research before deciding that is a problem, but I'll mention it here incase this is relivent.
Oh, yes the Yun is linked to the PC via USB, but it is connected to the internet wireless.
Also a strange one, turn on PC, for 20min. Plug in YUN and leave for 20min (the sketch should be running). start IDE and open serial monitor, skech runs for about 5 cycles and crashes. Close serial monitor leave 10 min and reopen, jiberishs on the monitor repeated every 5 sec. reclose monitor and reopen... repeating jibberish...
Even more tests. I have tried using Cat5 connection only and disabled my wire router and it still crashes. Now its being an unreliable pain in the arse to reactivate the wi-fi.
Any thoughts...
Has anone else manange to let the sketch run for 5 min or more?
replace your copy of Bridge.cpp (located at IDE_FOLDER/libraries/Bridge/src) and replace it with this one
Download one of the nightly builds of the IDE from http://arduino.cc/en/Main/Software. These are built every day with the latest code available on github
Sorry it took so long to get back to you tonight, I had an Arduino robotics session at Google Campus London tonight, it felt really cool to be the only geek with a shiny new Yun... Got a few nods.... (Ok bragg over, back to play)
Right before I did any alterations I made sure the Yun was performing as expected, loading on the HttpClient sketch, watching it crash, and load up a blink test sketch to rest the Yun. Load up the HttpClient and watch it crash. All very much as expected and repeated it a few times to ensure things were repeatable...
Downloaded the bridge.ccp and inserted it into the scr directory for the bridge library, after renaming the old one' OLD_bridge.Xpp' for good measure. Resarted the IDE and loaded the HttpClient. Sat and watched for a moments or two.. and it just ran. went and got some biscuits and juice.. it was still running.... So I swapped back to the original Bridge.cpp file, cleared out the old HttpClient sketch with a blink sketch. restart the IDE and load up the HttpClient, and it crashed in the same old way... Swap back the new, restart the IDE and reload the HttpClient sketch, and its running away as I type this. So that must be 10min or so....I'm a slow typist and lousy speller.
That for me pretty much bags it as a defective bridge.cpp file.
I did read though the topic #188955, but they didn't seem to reply with any level of success, failure or even if they had given up. So my question was also to the bigger world who are reading in. Hopefully I have given you enough information to be of use. But clearly it is off assistance if others who might have had an issue tried this and found it was a fix as well. After all there could be a lot of people looking to use the Yun, So I guess all the feedback you can get helps
Problem not solved: I found the same issue with the old Bridge.cpp... It would cycle aprox 52 times before hanging on the client.get
I replaced the Bridge.cpp with the new version linked on this forum ... Now it works longer but hangs at aprox 132 cycles each time.
I sure hope this can get resolved ASAP!
This issue may make the board useless for my intended project but I have great hope that a solution is pending.
Update:
I have just tested several more times - the new Bridge.cpp will often go past the pervious 52 cycles... Howver I found now that it will hang on 28 and more or less just as before.
My test is running a cycle with a delay(10000) and fetching a one character page.
// This is a simplified version of the script (stripped of any string parsing, pointers or array issues)
// This program failed/hung a number of times (the last fail was at cycle 126)
// I am using the Bridge.cpp that was linked here in the forum
// Arduino IDE 1.5.5
#include <Bridge.h>
#include <HttpClient.h>
int count;
int command;
int duration;
int zero;
HttpClient client;
void setup() {
Bridge.begin();
Serial.begin(9600);
}
void loop() {
Serial.print(count);
Serial.print(" Fetching posts ");
client.get("http://..../posts.php");
Serial.println("| Posts received");
// NOTES:
// This script failed after 126 cycles - after printing the serial output above (fetch and receive)
// Other times it fails before the serial output "Posts received"
// To simply the script - I am not parsing strings
// I simply parseInt (below) - which works great (as long the programs gets to that point)
// The content on the posts.php is changed dynamically
// In this last fail - posts.php was left blank through the full 0 - 125 cycles
// The second call to client.get simply calls a php script to clear text files stored in posts.php
// My hosting provider will not render .txt files
// If two int are saved on the posts.php the program will retreive both in the variables below, followed by a trailing nill (0)
while (client.available()) {
command = client.parseInt();
duration = client.parseInt();
zero = client.parseInt();
Serial.println(command);
Serial.println(duration);
}
Serial.flush();
client.get("http://..../clearposts.php");
count++;
delay(10000);
}
GinVan:
// This is a simplified version of the script (stripped of any string parsing, pointers or array issues)
// This program failed/hung a number of times (the last fail was at cycle 126)
// I am using the Bridge.cpp that was linked here in the forum
// Arduino IDE 1.5.5
Considering that the 1.5.5 IDE was just released in early December (release notes from Nov.28), I am not sure if it is a good idea to replace the bridge.cpp file with one from a post in October or even earlier...
hmmm I don't know what to say... this time it ran for 995 cycles - still going.
I am not sure if there was a long delay on any of the cycles... I did not sit to watch.
Perhaps that could be the issue? I should have put a timer on the reads...
This is the fuller code to respond to page content and flash the led ... it stalled at 31 cycles ... and has not resumed after waiting 30 minutes.
I am new to programming in C ... is there any issues that would cause my code to fail randomly...?
The code ran for 18 cycles receiving blank content (as I was not yet updating the page with content) then stalled 14 cycles after receiving actual content of two integer numbers (plus the trailimg null/0).
#include <Bridge.h>
#include <HttpClient.h>
int count;
int command;
int duration;
int zero;
HttpClient client;
void setup() {
pinMode(13, OUTPUT);
digitalWrite(13, LOW);
Bridge.begin();
Serial.begin(9600);
}
void loop() {
Serial.print(count);
Serial.print(" Fetching posts ");
client.get("http://....../posts.php");
Serial.println("| Posts received");
while (client.available()) {
command = client.parseInt();
duration = client.parseInt();
zero = client.parseInt();
Serial.println(command);
Serial.println(duration);
checkcommand(command);
}
Serial.flush();
client.get("http://....../clearposts.php");
count++;
delay(10000);
}
int checkcommand(int rc) {
switch (rc) {
case 0:
break;
case 1:
break;
case 2:
break;
case 3:
flash(duration);
break;
case 4:
break;
case 5:
break;
return rc;
}
}
int flash(int x) {
Serial.print("Flash LED - number of times: ");
Serial.println(x);
for (int lp = 0; lp < x; lp++) {
Serial.println(lp);
digitalWrite(13, HIGH);
delay(300);
digitalWrite(13, LOW);
delay(300);
}
return x;
}
Considering that the 1.5.5 IDE was just released in early December (release notes from Nov.28), I am not sure if it is a good idea to replace the bridge.cpp file with one from a post in October or even earlier...
Good point Ralf... first day on the forum and in such a hopeful rush to solve the problem I was not observing dates. Just now I downloaded the NIGHTLY ... which I am guessing contains both the latest IDE and Bridge.cpp
The yun stalled again at 39 cycles of the above code.
Considering that the 1.5.5 IDE was just released in early December (release notes from Nov.28), I am not sure if it is a good idea to replace the bridge.cpp file with one from a post in October or even earlier...
Good point Ralf... first day on the forum and in such a hopeful rush to solve the problem I was not observing dates. Just now I downloaded the NIGHTLY ... which I am guessing contains both the latest IDE and Bridge.cpp
The yun stalled again at 39 cycles of the above code.
I will have access to my Yun system again this weekend, I will give it a try and see what happens to me...
As for posting code, it would be a good idea if you get used to surrounding it by code "(#") tags, that makes it easier to read and to copy...
As for posting code, it would be a good idea if you get used to surrounding it by code "(#") tags, that makes it easier to read and to copy...
Thanks Ralf for the tip... I edited my posts with code tags. (Good features on this forum - lots of helpful systems to learn about).
Also... In my eagerness (and apparent frustration - and lack of sleep while trying to resolve the http client issue ) I posted a rather wordy response on another thread that seemed to be related. The changes to the files mentioned as a solution there (though I am not 100% clear if they are actually specifically related to this issue) did not solve the http client issue:
Hi Frederico... thanks for the reply and for also trying to help.
In my previous posts I provided two code examples. The first version has more comments in the code with details regarding how the code seems to hang.
My code is printing serial output: a count, a marker before client.get and a marker "Fetching posts" showing that the code is has moved past the client get "Posts received". I am updating page "posts.php" with content dynamically - either with blank content or two integers separated by a space such as "1 20" (1[space]20). I have noticed that a trailing zero "0" is also received which I assume is the end of file marker "null".
I am running the code with a delay(10000) between client.get fetches.
The serial monitor displays output such as:
69 Fetching posts | Posts received
70 Fetching posts | Posts received
71 Fetching posts
The display after a number of cycles will not move past "Fetching posts" such as the example above stalled at 71.
I am expecting the code to run continuously without fail so that I can receive and parse content when it is provided.
Also is there something I need to do to update code within my yun? I edited some files that you mentioned on a previous thread. There is a link above in my previous post. Please advise me on how I can get this yun to operate... receiving content from the web continuously, without fail.
I was reading through your posts and just thought of one experiment that might be worth trying.
Have you tried to run your Yun on a different network?
Internal switches have been known to be poor quality, and if you are going via your service providers internet you have no idea what they are using.. Poor switchers can cause all sorts of problems. It is rare, but could be a simple experiment to try just to be sure.
That's exactly what we need to make it better and better 