These are chat archives for esp8266/Arduino

25th
Nov 2016
copercini
@copercini
Nov 25 2016 14:59
Can I change the internal EEPROM size?
because SPIFFS is very unstable with Extended Database
and EEPROM works fine
fmgomes
@fmgomes
Nov 25 2016 15:16
@me-no-dev I've replaced the WiFiClient by the HTTPClient in the example above, making the same request to the same server and I wasn't able to make it fail, no matter how fast I tried to access the server, even calling it directly in each run in the loop. I don't understand why the WiFiClient fails when I use it repeatedly and very fast
Me No Dev
@me-no-dev
Nov 25 2016 15:22
@fmgomes HTTPClient is build on top of WiFiClient, so it must be you doing something wrong
@copercini what is "Extended Database" and how often do you write to it?
copercini
@copercini
Nov 25 2016 15:25
@me-no-dev This is extended database: https://github.com/jwhiddon/EDB
I just want to have like 50 RFID tags in this internal database and read it to verify if the user is allowed
Me No Dev
@me-no-dev
Nov 25 2016 15:27
@copercini this will be as bad with EEPROM. You might want to look for an external EEPROM/FRAM chip to handle EDB
fmgomes
@fmgomes
Nov 25 2016 15:27
@me-no-dev Yes, I know that must be me doing something wrong, this is why I've tried with the HTTPClient since it is based on the same code.
Me No Dev
@me-no-dev
Nov 25 2016 15:27
@copercini there are also other ways to deal with that
fmgomes
@fmgomes
Nov 25 2016 15:27
I'll review the code once again to try to figure out the reason
Me No Dev
@me-no-dev
Nov 25 2016 15:28
@fmgomes make sure you do not try to connect to the same client while it's still connected
copercini
@copercini
Nov 25 2016 15:29
@me-no-dev what ways?
I want to write it just one time, i think it will not kill the flash storage
fmgomes
@fmgomes
Nov 25 2016 16:46
@me-no-dev When the WiFiClient object is destroyed (when the function goes out of scope), is it guaranteed that the client is disconnected?
Because the socket disconnection might be done in background and could take more time until the server sends the FIN ACK
fmgomes
@fmgomes
Nov 25 2016 17:29
That is why I'm explicitly calling client.stop(), expecting that if the implementation is synchronous, only return from the stop() method after having the connection closed.
But I didn't check the WiFiClient implementation, so this is only an expectation