This is a heads up for those attempting to use this library and possibly other similar libraries, including the Ethernet library.
Don't bother trying to use Google Chrome with this library because it just DOES NOT work.
You get illogical and unpredictable errors when you try and intercept the http requests in your code.
E.G.
You type 10.0.0.79/walarms.htp in the chrome address bar and it seems to ignore the bit after the / and just sends a default HTTP request. However if you click on a hyperlink in your html, pointing to 'walarms.htp', then it sends the proper HTTP request.
Sometimes chrome sends a totally blank HTTP request, particularly when you try and edit the chrome address bar or it has been timing out.
Sometimes chrome times out or just sits their with a blank page forever even though your arduino has intercepted the HTTP request and is in the process of sending the file. Other times chrome loads the page.
If you submit a form and then edit the chrome address bar to remove all the form data and press enter then chrome ignores you and tries to send the form data again or it send incomplete for data.
I don't have any of these problems if I use Firefox for example - same sort of thing I suppose as 'Kies Air' only working with Chrome but not Firefox
I have not yet tested the library/my code with iexplorer or Safari.
As far as the timeout errors go it looks as though the problem is that the WifiESP library is not allowing enough time for form data to be collated by the web browser and sent when the for data is long.
I switched back to firefox and was also getting a timeout error with one of my forms where the form data is longer than with the rest of my forms. None of the other irritating Chrome errors occur when using firefox with my forms however.
In libraries/WiFiESP/Utility/EspDrv.cpp
I changed the following define to be way longer than necessary.
I also had to change a few int type parameters to int32_t in a few functions to avoid overflow compile warnings.
/*--------------------------------------------------------------------
This file is part of the Arduino WiFiEsp library.
The Arduino WiFiEsp library is free software: you can redistribute it
and/or modify it under the terms of the GNU General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.
The Arduino WiFiEsp library is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with The Arduino WiFiEsp library. If not, see
<http://www.gnu.org/licenses/>.
--------------------------------------------------------------------*/
#include <Arduino.h>
#include <avr/pgmspace.h>
#include "utility/EspDrv.h"
#include "utility/debug.h"
#define NUMESPTAGS 5
#define TIMEOUT500 16000
#define TIMEOUT1000 16000
====> #define TIMEOUT2000 160000L <====
It appears to have eliminated the browser/Serial monitor timeout error and I can see my long form data arrive in Serial monitor as expected.
Another issue that I have discovered with Arduino and HTML forms is that 200-300 characters of form data seems to be the limit before you start running into unpredictable memory errors.
It depends on the size of the call stack and local function variables etc I suppose.
So it pays to keep the number of inputs on a form to an absolute minimum and limit the size of the field names as far as possible.
Using a mega and with global variables in my sketch occupying 5,734 bytes of of 8,192 bytes I am a little surprised that more than 300 bytes of form data can't be stored in a String object.
It must mean that the total amount of heap space available for String objects is quite small, even on a mega.
Although I am intending to replace the all my String objects with a PString inspired string class.
One of Your problem is using the String object in the first place... the more your code uses it, the closer to bad Heap Fragmentation you get and then you run out of usable memory.
read this and then you'll no longer use that class
J-M-L:
One of Your problem is using the String object in the first place... the more your code uses it, the closer to bad Heap Fragmentation you get and then you run out of usable memory.
read this and then you'll no longer use that class
I understand and I am in the process of creating a replacement for it that does not use the heap but implements the same functionality as String.
Trying to come up with a system that allows me the convenience of doing this sort of thing 'String(123)' but such that the char data is put in a char strBuff[15] or strBuff[100] type of thing rather than a strBuff = new (...) type of thing.
But am I likely to run into the same sort of problem if I start creating a 350 byte long char buffer on the stack? Or is there significantly more memory available for the stack than there is for the heap?
Dynamically allocating blocks of memory and deallocating them is what fragments the heap and making it possibly harder and harder for the memory management system to find a block of the suitable size for you.
Allocating on the stack gets cleaned up when your function exit.
so the problem with fragmenting the heap is that you might have still plenty of memory unused in the heap but because they are made with small blocks, if you want a bigger block it's allocated on top of the heap and at one point it will come collide with the stack.
