ESP8266 Weather Reporter - problem solved!
OK! I tried a different NodeMCU board (I have 2), and it behaved exactly the same i.e. random memory-based exceptions. I use the ESPExceptionDecoder to see where it was crashing out - always in a Print::write function.
What could it be? Looking closely at the nicked code, it used a String object to collect data from the web response one character at a time, before turning the whole thing into an array to pass to the JSON parser. Hmm. Previous experience with C++ has made me very very suspicious of C++ object data types, and the wanton use of memory in the handling of function calls. Basically, there's masses of malloc/free or equivalents on every call, copying parameters etc. And it doesn't all get freed...
Anyway, switched my buffer to a char [] array of a fixed size, and put a limit on the number of characters put into it. Easy! Let's face it, there aren't unlimited resources on the chip, only 40k left of stack, so best to set some limits. It's now failed, but after 1447 iterations, which is a distinct improvement on 9! And it's just the SerialMonitor that's stopped I think - there's no exception dump or whatever.
Here's the original vs. my code extracts:
Original:
String result;
WiFiClient client;
...
while (client.connected() || client.available())
{ //connected or data available
char c = client.read();
result = result + c; //gets byte from ethernet buffer
}
Mine:
#define readBufSize 1000
char result[readBufSize];
int bufIndex = 0;
while (client.connected() && client.available() && bufIndex < (readBufSize-1))
result[bufIndex++] = client.read();
}
result[bufIndex] = 0;
I also modified the while test - seems to me you'd have to have all of those things be true, so it's definitely a big pile of ANDs, not ORs. And it works.
I did write some test code to remind myself how char, char*, char[] and so on work. This was pretty useful!
What could it be? Looking closely at the nicked code, it used a String object to collect data from the web response one character at a time, before turning the whole thing into an array to pass to the JSON parser. Hmm. Previous experience with C++ has made me very very suspicious of C++ object data types, and the wanton use of memory in the handling of function calls. Basically, there's masses of malloc/free or equivalents on every call, copying parameters etc. And it doesn't all get freed...
Anyway, switched my buffer to a char [] array of a fixed size, and put a limit on the number of characters put into it. Easy! Let's face it, there aren't unlimited resources on the chip, only 40k left of stack, so best to set some limits. It's now failed, but after 1447 iterations, which is a distinct improvement on 9! And it's just the SerialMonitor that's stopped I think - there's no exception dump or whatever.
Here's the original vs. my code extracts:
Original:
String result;
WiFiClient client;
...
while (client.connected() || client.available())
{ //connected or data available
char c = client.read();
result = result + c; //gets byte from ethernet buffer
}
Mine:
#define readBufSize 1000
char result[readBufSize];
int bufIndex = 0;
while (client.connected() && client.available() && bufIndex < (readBufSize-1))
result[bufIndex++] = client.read();
}
result[bufIndex] = 0;
I also modified the while test - seems to me you'd have to have all of those things be true, so it's definitely a big pile of ANDs, not ORs. And it works.
I did write some test code to remind myself how char, char*, char[] and so on work. This was pretty useful!
Have you looked at the ArduinoJson JsonHttpClient example?
ReplyDeletehttps://github.com/bblanchon/ArduinoJson/blob/master/examples/JsonHttpClient/JsonHttpClient.ino
Haha!! No... I probably should. I basically took the code and fixed it, rather than re-engineering it from scratch.
DeleteThe only significant point is that he uses jsonBuffer.parseobject(ethernetClient) i.e. the actual comms object. I have tried that but it didn't work, even though it was also preceded by a skipResponseHeaders() equivalent. Maybe I changed multiple things at the same time, but I looked in the library for the function polymorphs and couldn't see one that worked with the various parent classes of WiFiClient, which I'm using necessarily.
Delete