Go Down

Topic: WiFi Library Inefficiencies? (Read 490 times) previous topic - next topic

ddod

Can anyone explain this behavior I am seeing?  Using the WiFi library I am seeing the following.

Code example 1 (where client is an instance if WiFiClient):
Code: [Select]

client.print("Some text: ");
client.print(someInt);
client.println(" some more text");


Code example 2
Code: [Select]
String var = "Some text: " + String(someInt)+ " some more text");
client.println(var);


The first example works very efficiently across the wire and all of the text gets concatenated and sent in a single packet (or two).  However the second code example runs very poorly.  I have some code that is a little more complex than the above example and when written in the style of the first example makes it to the server in 2 packets.  However when written in the style of the second, it sends it in about 6 to 7 packets with a 2 second delay between many of the packets.  And in addition, some of the packets only contained one or two characters of text.  Its very odd to me.  I was hoping to use the second style to create the body of a post (JSON) and make it easy to calculate the content length.  But it was so bad I had to go back to other style.

Any ideas about what is going on here?

PaulS

Is the issue with the String class? Try a char array, and sprintf() to create a string, instead.

PeterH


Is the issue with the String class? Try a char array, and sprintf() to create a string, instead.


That code fragment does look very similar to the test case that demonstrates the String bug, and the symptoms are also very similar.
I only provide help via the forum - please do not contact me for private consultancy.

ddod


PeterH


What's the String bug?


The String class uses dynamic memory allocation to provide the internal buffers which store the string content. The underlying memory management library has a bug which can  cause memory corruption. The bug can be exposed by quite simple patterns of allocating and deallocating String objects, and sample code demonstrating this looks rather similar to what you're doing here. Since it's hard (IMO) to predict which uses of String will expose the bug and which ones won't, I suggest that you should avoid using String completely, at least until the bug has been fixed in some future release of Arduino. String is provided as a helper class but the things that can be done using String can be done using plain old c-strings instead, usually without much extra complexity.
I only provide help via the forum - please do not contact me for private consultancy.

ddod

Thanks for all the replies.  I did end up not using the String library.  It was way too unpredictable for me.  Thanks again.

Go Up