These are chat archives for esp8266/Arduino

17th
Aug 2018
diraniyoussef
@diraniyoussef
Aug 17 2018 06:33
@me-no-dev I have bad news!
I just tested the code by writing to EEPROM outside of onData, but I had this

ets Jan 8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v614f7c32
~ld

I expected this though since by tracing the code in Serial.println(...) it used to crash before reaching the EEPROM writing line of code
like about the beginning of onData
I'm beginning to think it's maybe related to onData itself
BTW I use a java code on Linux pc as the server, so I send data using a PrintWriter java object
Me No Dev
@me-no-dev
Aug 17 2018 07:09
onData is used in all kinds of applications ;) definitelly not onData fault :)
diraniyoussef
@diraniyoussef
Aug 17 2018 07:10
quite sure
BTW sometimes I get Error number is -13
it is failure to connect
I guess
so if the internet connection is bad, or say there is some sort of extra restrictions on the server's gateway (which I am just assuming), could that ruin onData?
i.e. can I measure the timeout of incoming data?
do you have an example somewhere?
diraniyoussef
@diraniyoussef
Aug 17 2018 07:17
Maybe I can extend the timeout of data received or so
or maybe flush the buffer used by onData
I'm just guessing
All these I don't know how to do
And that Error number 13 is interesting... it happens from time to time, but only a little.
I'm speaking to myself :)
Ulrich Rosenbaum
@jsdungeon
Aug 17 2018 07:22
;-)
diraniyoussef
@diraniyoussef
Aug 17 2018 07:24
Do you think letting the execution code flowing again on onConnect and onData for the same AsyncClient is a bad idea?\
I mean without deleting it
Me No Dev
@me-no-dev
Aug 17 2018 07:44
i did not get the question?
diraniyoussef
@diraniyoussef
Aug 17 2018 07:47
like executing onData([]( void * arg, AsyncClient * c, void * data, size_t len ) again every 4 minutes
for the same AsyncClient object
Me No Dev
@me-no-dev
Aug 17 2018 09:26
how? this is a callback, not something you should trigger
diraniyoussef
@diraniyoussef
Aug 17 2018 11:29
nvm
diraniyoussef
@diraniyoussef
Aug 17 2018 11:50
I will try to make my questions more into the problem...
Thanks a lot anyway
I will be so glad to inform you tomorrow that everything worked fine and to tell you the reason!
I feel I'm close
Me No Dev
@me-no-dev
Aug 17 2018 12:08
good luck :)
Stavros Korokithakis
@skorokithakis
Aug 17 2018 12:27
hello
i have an esp8266 running off of 3.7V batteries
is it possible that i've damaged it? it's running pretty hot now, even when connected to 3.3V power
it's running MicroPython, if that changes anything
tobozo
@tobozo
Aug 17 2018 12:35
3.7 batteries can go up to 4.1v when fully charged, better wire this to the 5v pin
Stavros Korokithakis
@skorokithakis
Aug 17 2018 12:43
Sorry, I was mistaken
It was up to the 5V pin
So I guess I didn't damage it
But I don't know why it's so hot either...
Me No Dev
@me-no-dev
Aug 17 2018 12:47
maybe your firmware is keeping the CPU and radio busy?
Stavros Korokithakis
@skorokithakis
Aug 17 2018 12:49
Yes, it probably is
It's waiting for a connection to be accepted, I don't know why that wouldn't yield for a while
diraniyoussef
@diraniyoussef
Aug 17 2018 13:49
@me-no-dev @jsdungeon I feel it's my day, it has been for 2 hours now and it's still working as a charm.
That's what I did: I removed all the heavy processing outside onData (including sending a message using "write" method), I also omitted sending another message in onConnect (BTW onConnect was another probable place of exception thrown or wdt reset, not sure)
And what can be a reason, is some variables that were changing in onConnect, and also being read or changed (not sure) in the original sketch execution flow
Me No Dev
@me-no-dev
Aug 17 2018 13:51
good!
diraniyoussef
@diraniyoussef
Aug 17 2018 13:51
So I handed all this to the normal flow
using flags
so onData and onConnect are light now
and happy
den har
@denman0000_gitlab
Aug 17 2018 21:34
Hi all .. anybody here with a Fluke Multimeter and an esp 12F ? need to confirm something
den har
@denman0000_gitlab
Aug 17 2018 21:49
nevermind