Where's the Wizard ?

kfjl

Member
An ESP only sends long strings if you tell it to.

The answer to the "get" request is on the first line of the reply, find the answer and send just that. That's what the "indexOf" lines do in the first program I posted at #29.
 

hippy

Senior Member
I'm looking, but is there a convenient way on the 20x2 to prevent HSERPTR from wrapping to 0?
I think the only way to do that is to interrupt on bytes received or poll to determine how much has been accumulated and execute a HSERSETUP OFF once it gets close to its limit.
Code:
w0 = hSerPtr - ptr
If w0 >= $8000 Then
  w0 = w0 + 128
End If
SerTxd("Held in buffer = ", #w0, CR, LF )
 

hippy

Senior Member
An ESP only sends long strings if you tell it to.
Do you have details of how to configure it so it doesn't ?

I couldn't find anything in my AT command list, couldn't see where I was explicitly saying "send everything" in my software.

It's been a while but I can't imagine not having limited data or having it delivered in chunks if I had known it was possible.
 

lbenson

Senior Member
I decided it made more sense to get it working on a 28x2 (with ESP-01) before trying to cut down to the 20X2. I got it to send the intended page to the browser (from the js script on the pi), but it doesn't return to waiting for the next response.

Still pondering.
 

lbenson

Senior Member
Looking for further hints. After displaying the web page, I have the following logs, ending with "link is not valid".

This one is from the 28x2 with the serial terminal:
Code:
Ready

Power-On Message...
  <140><226><2><236><18><130>n<236><146>r<130><242>n|<236><12><140><12><142>|rl<140><226>r<146>l<140>l<18><140><12><12><12>l`<2><140><226>r<146>l<236>l<18><140><12><12><12>l`<2><140><226>r<146>l<12><142><158><0><140><12><12>ll`<2>rl<142><130>rl<140><158><226><140>b<12>l<140>br|<12><142>bp`<236>l<236>b<18>lr<140>lb<236><242>n<238><128><18>nn<226><16><2><12><2><140>l<242>p<2><12>l<12><140><12>l<140><142><140><12><140><12><12><142><30><142>l<142><14>l<128><2>n<252><0><140><158><226><140>b<12>l<236><142><28>p<12><12><2><2><140><158><226><140>b<12>l<12><140>bprlrl<CR><LF>
  ready<CR><LF>

Reset module

Version Details
  WIFIQ<21><17>5<LF>
  AT+RST<CR><CR><LF>
  <CR><LF>
  OK<CR><LF>
  WIFI DISCONNECT<CR><LF>
  <CR><LF>

. . . [Lots of junk]

 AT version:1.2.0.0(Jul  1 2016 20:04:45)<CR><LF>
  SDK version:1.5.4.1(39cb9a32)<CR><LF>
  v1.0.0<CR><LF>
  Mar 11 2018 18:27:31<CR><LF>
  OK<CR><LF>
  WIFI CONNECTED<CR><LF>

Configure as station
  AT+CWMODE=1<CR><CR><LF>
  <CR><LF>
  OK<CR><LF>

Connect to access point
Got so far...
  AT+CWJAP=MySSID","MyPW"<CR><CR><LF>
  WIFI DISCONNECT<CR><LF>
Got so far...
  AT+CWJAP="MySSID","MyPW"<CR><CR><LF>
  WIFI DISCONNECT<CR><LF>
  WIFI CONNECTED<CR><LF>
Complete packet
  AT+CWJAP="MySSID","MyPW"<CR><CR><LF>
  WIFI DISCONNECT<CR><LF>
  WIFI CONNECTED<CR><LF>
  WIFI GOT IP<CR><LF>
  <CR><LF>
  OK<CR><LF>

Connected

Connected status
  AT+CIPSTATUS<CR><CR><LF>
  STATUS:2<CR><LF>
  <CR><LF>
  OK<CR><LF>

Our IP Address
  AT+CIFSR<CR><CR><LF>
  +CIFSR:STAIP,"192.168.1.224"<CR><LF>
  +CIFSR:STAMAC,"60:01:94:11:0c:95"<CR><LF>
  <CR><LF>
  OK<CR><LF>

Allow multiple connections
  AT+CIPMUX=1<CR><CR><LF>
  <CR><LF>
  OK<CR><LF>

Start server on port 80
  AT+CIPSERVER=1,80<CR><CR><LF>
  <CR><LF>
  OK<CR><LF>

Waiting for requests...

Request has arrived
0,CONNECT<CR><LF>
<CR><LF>
+IPD,0,427:GET / HTTP/1.1<CR><LF>
Host: 192.168.1.224<CR><LF>
Connection: keep-alive<CR><LF>
Cache-Control: max-age=0<CR><LF>
Upgrade-Insecure-Requests: 1<CR><LF>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2018.11 Safari/537.36 Chrome/71.0.0.0<CR><LF>
DNT: 1<CR><LF>
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8<CR><LF>
Accept-Encoding: gzip, deflate<CR><LF>
Accept-Language: en-US,en;q=0.9<CR><LF>
<CR><LF>

Request is ...
mux=0
url=<TIMEOUT>

processURL

Indicate reply
Full packet
  AT+CIPSEND=0,234<CR><CR><LF>
  <CR><LF>
  OK<CR><LF>
  > 

Send reply - 234 bytes
Full packet
  <CR><LF>
  Recv 234 bytes<CR><LF>
  <CR><LF>
  SEND OK<CR><LF>

Close reply
  AT+CIPCLOSE=0<CR><CR><LF>
  0,CLOSED<CR><LF>
  <CR><LF>
  OK<CR><LF>
  0,CONNECT<CR><LF>
  <CR><LF>
  +IPD,0,368:GET /favicon.ico HTTP/1.1<CR><LF>
  Host: 192.168.1.224<CR><LF>
  Connection: keep-alive<CR><LF>
  User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2018.11 Safari/537.36 Chrome/71.0.0.0<CR><LF>
  DNT: 1<CR><LF>
  Accept: image/webp,image/apng,image/*,*/*;q=0.8<CR><LF>
  Referer: http://192.168.1.224/<CR><LF>
  Accept-Encoding: gzip, deflate<CR><LF>
  Accept-Language: en-US,en;q=0.9<CR><LF>
  <CR><LF>

Request has arrived
AT+CIPCLOSE=0<CR><CR><LF>
0,CLOSED<CR><LF>
<CR><LF>
OK<CR><LF>
0,CONNECT<CR><LF>
<CR><LF>
+IPD,0,368:GET /favicon.ico HTTP/1.1<CR><LF>
Host: 192.168.1.224<CR><LF>
Connection: keep-alive<CR><LF>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2018.11 Safari/537.36 Chrome/71.0.0.0<CR><LF>
DNT: 1<CR><LF>
Accept: image/webp,image/apng,image/*,*/*;q=0.8<CR><LF>
Referer: http://192.168.1.224/<CR><LF>
Accept-Encoding: gzip, deflate<CR><LF>
Accept-Language: en-US,en;q=0.9<CR><LF>
<CR><LF>

Request is ...
mux=0
url=favicon.ico

processURL

Got favicon.ico request

Close reply
  AT+CIPCLOSE=0<CR><CR><LF>
  0,CLOSED<CR><LF>
  <CR><LF>
  OK<CR><LF>

Indicate reply
Got so far...
  AT+CIPCLOSE=0<CR><CR><LF>
  0,CLOSED<CR><LF>
  <CR><LF>
  OK<CR><LF>
  AT+CIPSEND=0,234<CR><CR><LF>
  link is not valid<CR><LF>
  <CR><LF>
  ERROR<CR><LF>
Got so far...
  AT+CIPCLOSE=0<CR><CR><LF>
  0,CLOSED<CR><LF>
  <CR><LF>
  OK<CR><LF>
  AT+CIPSEND=0,234<CR><CR><LF>
  link is not valid<CR><LF>
  <CR><LF>
  ERROR<CR><LF>
Got so far...
  AT+CIPCLOSE=0<CR><CR><LF>
  0,CLOSED<CR><LF>
  <CR><LF>
  OK<CR><LF>
  AT+CIPSEND=0,234<CR><CR><LF>
  link is not valid<CR><LF>
  <CR><LF>
  ERROR<CR><LF>
This on is from the same run, with the HSERIN pin brought out to a USB/Serial module, so it shows what the ESP-01 is responding with:
Code:
ready
AT+GMR
AT version:1.2.0.0(Jul  1 2016 20:04:45)
SDK version:1.5.4.1(39cb9a32)
v1.0.0
Mar 11 2018 18:27:31
OK
WIFI CONNECTED
AT+CWMODE=1

OK
AT+CWJAP="MySSID","MyPW"
WIFI DISCONNECT
WIFI CONNECTED
WIFI GOT IP

OK
AT+CIPSTATUS
STATUS:2

OK
AT+CIFSR
+CIFSR:STAIP,"192.168.1.224"
+CIFSR:STAMAC,"60:01:94:11:0c:95"

OK
AT+CIPMUX=1

OK
AT+CIPSERVER=1,80

OK
0,CONNECT

+IPD,0,427:GET / HTTP/1.1
Host: 192.168.1.224
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2018.11 Safari/537.36 Chrome/71.0.0.0
DNT: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

AT+CIPSEND=0,234

OK
>
Recv 234 bytes

SEND OK
AT+CIPCLOSE=0
0,CLOSED

OK
0,CONNECT

+IPD,0,368:GET /favicon.ico HTTP/1.1
Host: 192.168.1.224
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2018.11 Safari/537.36 Chrome/71.0.0.0
DNT: 1
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Referer: http://192.168.1.224/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

AT+CIPCLOSE=0
0,CLOSED

OK
AT+CIPSEND=0,234
link is not valid

ERROR
 

hippy

Senior Member
Cross-posted with above - I'll reply to that below

Using a 28X2 is the pragmatic solution because the request should fit into its 1024 buffer.

As to why it doesn't return to the next 'waiting for response' I'm not sure. I haven't looked at the code since I put it together at the end of 2017. What does it show ? Looking at the code it should be something like -

Request has arrived
...packet...
Request is ...
mux=...
url=...
num=...
Indicate reply
Got so far...
...packet...
Full packet
...packet...
Send reply - ... bytes
num=...
adc=...
Got so far...
...packet...
Full packet
...packet...
Close reply
...packet...

Then back to waiting and another "request has arrived" for the next request.

In the loop after "Waiting for requests..." you could add various SERTXD to show where it's got to.
 

kfjl

Member
Do you have details of how to configure it so it doesn't ?
No, I don't. This is all much too complicated for me.

In post #39 you said the Scratchpad receive buffer is too small for a 372-byte get request. What would a get request be doing in the Scratchpad receive buffer? If you have something to send to the picaxe, you extract what you're interested in on the ESP side and just send that to the Picaxe. That's what I meant when I said "An ESP only sends long strings if you tell it to".

EDIT: I keep forgetting this is being done with AT commands so I suppose you were talking about the AT replies.
 
Last edited:

hippy

Senior Member
Rich (BB code):
Got favicon.ico request

Close reply
  AT+CIPCLOSE=0<CR><CR><LF>
  0,CLOSED<CR><LF>
  <CR><LF>
  OK<CR><LF>

Indicate reply
Got so far...
  AT+CIPCLOSE=0<CR><CR><LF>
  0,CLOSED<CR><LF>
  <CR><LF>
  OK<CR><LF>
  AT+CIPSEND=0,234<CR><CR><LF>
  link is not valid<CR><LF>
  <CR><LF>
  ERROR<CR><LF>
It all seems fine up to "Close Reply" and the packet echoed back from that, but I'm not sure how it then gets to "Indicate Reply" with that AT+CIPSEND echoed back in the packet. That's also present in your USB monitoring.
Code:
If number = 0 Then
    If Found("favicon.ico") Then
      SerTxd( CR, LF, "Got favicon.ico request", CR,LF )
      uptoPtr = savePtr
      Gosub CloseReply
      Return
    End If
  End If
After the CloseReply it should have returned out of 'ParseIpdPacket:' and be back in the outer loop looking for another "+IPD".

It feels like a 'stack overflow' type issue but that seems unlikely. Might be worth checking your source code is as above, that there is a RETURN between CloseReply and SendReply_SendLength: ...
Code:
CloseReply:
  SerTxd( CR, LF, "Close reply", CR, LF )
  HSerOut 0, ( "AT+CIPCLOSE=", mux, CR, LF )
  Gosub ReceivePacket
  Gosub ShowPacket_Indented
  Return

SendReply_SendLength:
  SerTxd( CR, LF, "Indicate reply", CR, LF )
 

hippy

Senior Member
EDIT: I keep forgetting this is being done with AT commands so I suppose you were talking about the AT replies.
Yes I believe that's the issue. In AT mode you get back the echoes and responses to AT commands. Plus, unsolicited, whatever is received from the browser, "all of it", prefixed by a "+IPD".

It sure would have been nice if the firmware had allowed a limit to be set on what +IPD returned. I imagine they were never expecting it to be used with any micro which didn't have enough memory to handle the entire +IPD.

I must admit I'd forgotten about that issue / caveat. A 20X2 is fine if the HTTP requests are coming from a Telnet client, another ESP or PC code which uses no or short headers, but not most browsers.
 

lbenson

Senior Member
Thanks. CR/LFs seem correct. I'll try backing out to your original web page, without the call to js on the pi. Maybe something is getting lost there. It was encouraging, though, that my initial page was being presented properly in the browser, with the radio buttons and text box presenting as wished.
 

hippy

Senior Member
Code:
Request is ...
mux=0
url=<TIMEOUT>
That intrigued me because I couldn't see how it would timeout while we were simply dealing with the packet we had already received.

Looking at the code TimedOut is simply when "uptoPtr = fromPtr", that is, nothing in the packet. There obviously is, but we do move fromPtr and uptoPtr while parsing the GET line so I'm guessing that, because it's just "GET / HTTP/1.1" there is indeed nothing between "/" and the "<SPACE>HTTP", the two pointers point to the same place, so it shows "<TIMEOUT>" rather than "<NOTHING>".

I guess that was a bugette in re-using "ShowPacket:". The fix should be -
Rich (BB code):
ShowPacket_Truncated:
  If fromPtr = uptoPtr Then
    SerTxd( "<NOTHING>", CR, LF )
    Return
  End If

ShowPacket:
  indent = 0
Rich (BB code):
  ; Report the request info we have
  SerTxd( CR, LF, "Request is ...", CR, LF )
  SerTxd( "mux=", mux, CR, LF)
  SerTxd( "url=" )
  Gosub ShowPacket_Truncated
 

lbenson

Senior Member
ShowPacket_Truncated
Progress, but no joy yet.

Because I have preloaded the SSID and password into the ESP, I skipped the RST and other code and went straight to "Our IP Address" with "Goto SSID_Preloaded" immediately before "MainProgram:" and "SSID_Preloaded:" immediately before "SerTxd( CR, LF, "Our IP Address", CR, LF )".

This worked; it got past "url=<NOTHING>", and presented the web page successfully, but still got tangled up in the favicon processing and ended up at "link is not valid<CR><LF>" instead of "Waiting for requests...".

Any further thoughts?
Code:
Our IP Address
  AT+CIFSR<CR><CR><LF>
  +CIFSR:STAIP,"192.168.1.224"<CR><LF>
  +CIFSR:STAMAC,"60:01:94:11:0c:95"<CR><LF>
  <CR><LF>
  OK<CR><LF>

Allow multiple connections
  AT+CIPMUX=1<CR><CR><LF>
  <CR><LF>
  OK<CR><LF>

Start server on port 80
  AT+CIPSERVER=1,80<CR><CR><LF>
  <CR><LF>
  OK<CR><LF>

Waiting for requests...

Request has arrived
0,CONNECT<CR><LF>
<CR><LF>
+IPD,0,427:GET / HTTP/1.1<CR><LF>
Host: 192.168.1.224<CR><LF>
Connection: keep-alive<CR><LF>
Cache-Control: max-age=0<CR><LF>
Upgrade-Insecure-Requests: 1<CR><LF>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2018.11 Safari/537.36 Chrome/71.0.0.0<CR><LF>
DNT: 1<CR><LF>
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8<CR><LF>
Accept-Encoding: gzip, deflate<CR><LF>
Accept-Language: en-US,en;q=0.9<CR><LF>
<CR><LF>
1,CONNECT<CR><LF>

Request is ...
mux=0
url=<NOTHING>

processURL

Indicate reply
Full packet
  AT+CIPSEND=0,234<CR><CR><LF>
  <CR><LF>
  OK<CR><LF>
  > 

Send reply - 234 bytes
Full packet
  <CR><LF>
  Recv 234 bytes<CR><LF>
  <CR><LF>
  SEND OK<CR><LF>

Close reply
  AT+CIPCLOSE=0<CR><CR><LF>
  0,CLOSED<CR><LF>
  <CR><LF>
  OK<CR><LF>
  <CR><LF>
  +IPD,1,368:GET /favicon.ico HTTP/1.1<CR><LF>
  Host: 192.168.1.224<CR><LF>
  Connection: keep-alive<CR><LF>
  User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2018.11 Safari/537.36 Chrome/71.0.0.0<CR><LF>
  DNT: 1<CR><LF>
  Accept: image/webp,image/apng,image/*,*/*;q=0.8<CR><LF>
  Referer: http://192.168.1.224/<CR><LF>
  Accept-Encoding: gzip, deflate<CR><LF>
  Accept-Language: en-US,en;q=0.9<CR><LF>
  <CR><LF>

Request has arrived
AT+CIPCLOSE=0<CR><CR><LF>
0,CLOSED<CR><LF>
<CR><LF>
OK<CR><LF>
<CR><LF>
+IPD,1,368:GET /favicon.ico HTTP/1.1<CR><LF>
Host: 192.168.1.224<CR><LF>
Connection: keep-alive<CR><LF>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2018.11 Safari/537.36 Chrome/71.0.0.0<CR><LF>
DNT: 1<CR><LF>
Accept: image/webp,image/apng,image/*,*/*;q=0.8<CR><LF>
Referer: http://192.168.1.224/<CR><LF>
Accept-Encoding: gzip, deflate<CR><LF>
Accept-Language: en-US,en;q=0.9<CR><LF>
<CR><LF>

Request is ...
mux=1
url=favicon.ico

processURL

Got favicon.ico request

Close reply
  AT+CIPCLOSE=1<CR><CR><LF>
  1,CLOSED<CR><LF>
  <CR><LF>
  OK<CR><LF>
  0,CONNECT<CR><LF>
  <CR><LF>
  +IPD,0,368:GET /favicon.ico HTTP/1.1<CR><LF>
  Host: 192.168.1.224<CR><LF>
  Connection: keep-alive<CR><LF>
  User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2018.11 Safari/537.36 Chrome/71.0.0.0<CR><LF>
  DNT: 1<CR><LF>
  Accept: image/webp,image/apng,image/*,*/*;q=0.8<CR><LF>
  Referer: http://192.168.1.224/<CR><LF>
  Accept-Encoding: gzip, deflate<CR><LF>
  Accept-Language: en-US,en;q=0.9<CR><LF>
  <CR><LF>

Indicate reply
Got so far...
  AT+CIPCLOSE=1<CR><CR><LF>
  1,CLOSED<CR><LF>
  <CR><LF>
  OK<CR><LF>
  0,CONNECT<CR><LF>
  <CR><LF>
  +IPD,0,368:GET /favicon.ico HTTP/1.1<CR><LF>
  Host: 192.168.1.224<CR><LF>
  Connection: keep-alive<CR><LF>
  User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2018.11 Safari/537.36 Chrome/71.0.0.0<CR><LF>
  DNT: 1<CR><LF>
  Accept: image/webp,image/apng,image/*,*/*;q=0.8<CR><LF>
  Referer: http://192.168.1.224/<CR><LF>
  Accept-Encoding: gzip, deflate<CR><LF>
  Accept-Language: en-US,en;q=0.9<CR><LF>
  <CR><LF>
  AT+CIPSEND=1,234<CR><CR><LF>
  link is not valid<CR><LF>
  <CR><LF>
  ERROR<CR><LF>
Got so far...
  AT+CIPCLOSE=1<CR><CR><LF>
  1,CLOSED<CR><LF>
  <CR><LF>
  OK<CR><LF>
  0,CONNECT<CR><LF>
  <CR><LF>
  +IPD,0,368:GET /favicon.ico HTTP/1.1<CR><LF>
  Host: 192.168.1.224<CR><LF>
  Connection: keep-alive<CR><LF>
  User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2018.11 Safari/537.36 Chrome/71.0.0.0<CR><LF>
  DNT: 1<CR><LF>
  Accept: image/webp,image/apng,image/*,*/*;q=0.8<CR><LF>
  Referer: http://192.168.1.224/<CR><LF>
  Accept-Encoding: gzip, deflate<CR><LF>
  Accept-Language: en-US,en;q=0.9<CR><LF>
  <CR><LF>
  AT+CIPSEND=1,234<CR><CR><LF>
  link is not valid<CR><LF>
  <CR><LF>
  ERROR<CR><LF>
Got so far...
  AT+CIPCLOSE=1<CR><CR><LF>
  1,CLOSED<CR><LF>
  <CR><LF>
  OK<CR><LF>
  0,CONNECT<CR><LF>
  <CR><LF>
  +IPD,0,368:GET /favicon.ico HTTP/1.1<CR><LF>
  Host: 192.168.1.224<CR><LF>
  Connection: keep-alive<CR><LF>
  User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2018.11 Safari/537.36 Chrome/71.0.0.0<CR><LF>
  DNT: 1<CR><LF>
  Accept: image/webp,image/apng,image/*,*/*;q=0.8<CR><LF>
  Referer: http://192.168.1.224/<CR><LF>
  Accept-Encoding: gzip, deflate<CR><LF>
  Accept-Language: en-US,en;q=0.9<CR><LF>
  <CR><LF>
  AT+CIPSEND=1,234<CR><CR><LF>
  link is not valid<CR><LF>
  <CR><LF>
  ERROR<CR><LF>
 

lbenson

Senior Member
I remembered that on another project, I was having trouble with the favicon, and I found HTML code to insert to supress it:
HSerOut 0, ( "<link rel='icon' type='image/png' href='data:image/png;base64,iVBORw0KGgo='> " )

I put that in, got no more favicon requests, and now can cycle through browser requests without (so far) getting stuck. I have a lot of tidying up to do, but hope to document this fully tomorrow.

Thanks much for your code and your assistance, hippy (and hemi).
 

hippy

Senior Member
Glad you resolved it but I think you may only be masking the issue, that there's bug which remains which may come back to bite you.

After sending the page requested we closeReply, and the returned packet for that is OK plus a +IPD request for favicon.ico

We recognise that "Requst has arrived", pull the "favicon.ico" url out of the buffer, go through "Request is ...", "ProcessURL" and reach "Got favicon.ico request". We ignore that so simply CloseReply, and the returned packet for that is again OK plus another +IPD reuest for favicon.ico.

But this time we skip "Requst has arrived", "Request is ...", "ProcessURL" and go straight to "Indicate reply".

I am not sure why that is. The only thing which seems different is that theb 'mux' for the second request is "1" rather than "0" for the first. That shouldn't matter as we only use it to direct replies and We closed "0" for the first and closed "1" for the second.

It's the being in "Indicate Reply" which is the issue because we shouldn't be replying, when we do it right throws an error because the links are both closed.

The issue is how we got straight from "CloseReply" to "Indicate Reply". That seems to be a bug which will have to be tracked down.

It would help if you could temporarily remove the favicon.ico response and replace the main processing loop with the below which will better show what program flow is -
Code:
; Handle incoming requests

  SerTxd( CR, LF, "Waiting for requests...", CR, LF )

  ; Wait for a packet
  Gosub ReceivePacket
  Do
    SerTxd("[5]")
    If TimedOut Then
      SerTxd("[6]")
      ; Wait for a packet
      Gosub ReceivePacket
      SerTxd("[7]")
    Else
      SerTxd("[8]")
      ; Handle a packet when we get it
      If Found("\n+IPD,") Then
        SerTxd( CR, LF, "Request has arrived", CR, LF )
        Gosub ShowPacket
        SerTxd("[9]")
        Gosub ParseIpdPacket
        SerTxd("[1]")
        ; There may be a request buried in the
        ; last response so we handle that as if
        ; a request or wait for another packet
        If NotFound("\n+IPD,") Then
          SerTxd("[2]")
          ; Wait for a packet
          Gosub ReceivePacket
          SerTxd("[3]")
        End If
        SerTxd("[4]")
      Else
        SerTxd( CR, LF, "Unknown request", CR, LF )
        Gosub ShowPacket
        ; Wait for a packet
        Gosub ReceivePacket
      End If
    End If
  Loop

ParseIpdPacket:
 

lbenson

Senior Member
I'll do that, thanks, but it may take me a day or so.

Meanwhile, I could use some bit variables. Can I safely redefine "fromptr=w1" so that I can use bit16-bit31? I've tried it, and no apparent harm so far.
 

hippy

Senior Member
Can I safely redefine "fromptr=w1" so that I can use bit16-bit31? I've tried it, and no apparent harm so far.
I would expect so. I recall it's only used to parse through the packet and doesn't have any 'dual use' elsewhere. And, even if it does, I don't recall there's any particular reason w1 was chosen.
 

lbenson

Senior Member
Thanks--seems to be working fine.

Another question, and maybe (near) the last one--where does the program idle most of the time? I'm thinking that it's at "Pause MS_10" in ReceivePacket_More--so that would be where I would want to put code which normally processes every 10ms or 100ms. I'm at the point now of trying to implement the ramp/fade part of my scheme (and anything else which would typically be in a main DO ... LOOP).
 

lbenson

Senior Member
Here is my solution for using a picaxe to serve a web page to browser on phone or pc or tablet.
 

hippy

Senior Member
Another question, and maybe (near) the last one--where does the program idle most of the time? I'm thinking that it's at "Pause MS_10" in ReceivePacket_More--so that would be where I would want to put code which normally processes every 10ms or 100ms.
Yes, that's the 'no packet so idle for some time' / 'do nothing' part so that's the place for a call to any routine you want to run repeatedly. That's effectively -
Rich (BB code):
Do
  something
  timeOut = timeOut - Nms
Loop Until packetHasArrived Or timeOut = 0
So it can take as long as it requires. The longer it takes the less responsive to new packets being detected, but that shouldn't be problematic.
 

Buzby

Senior Member
Well, seeing as it's lockdown, I thought I try one of the ESP-01 ESP8266 thingies I've got in a drawer.

To test it I used a USB-Serial module, and started out by checking it's AT command set.

First, see if it is talking ...
Send : AT
Reply : OK

So far, so good.

Check firmware ...
Send : AT+GMR
Reply :
AT version:1.2.0.0(Jul 1 2016 20:04:45)
SDK version:1.5.4.1(39cb9a32)
v1.0.0
Mar 11 2018 18:27:31

Well, it replied with something sensible, so I suppose that's good.

Check current UART settings, 'cos I want to change them later ...
Send : AT+UART_CUR?
Reply : ERROR

Oops !.

Check a few more configuation settings ...
Send : AT+UART_DEF?
Reply : ERROR

Send : AT+SLEEP?
Reply : +SLEEP:2

Send : AT+SYSRAM?
Reply : ERROR

Send : AT+RFVDD?
Reply : +RFVDD:65535

Send : AT+SYSADC?
Reply : ERROR

So what's going wrong here ?.

Have I got one of those Chinese slightly-compatible modules, or is my USB-Serial faulty, or is my terminal sending wrong stuff ?.

Oh how I wish my ESP had an AXE number, and a corresponding PE wizard to go with it. :(

Not a happy bunny,

Buzby
 

hippy

Senior Member
So what's going wrong here ?.
Nothing ? It simply seems to be that you are sending AT commands your ESP-01 firmware does not recognise or support.

The problem is there is no definitive "ESP-01", no singular AT firmware version. All should implement the core AT commands required for use but some firmware providers add additional functionality and additional AT commands. Even when from the same manufacturer some modules have earlier version firmware without support for commands added later.

It's a whole mish-mash of randomness with different manufacturers supplying different versions of firmware, forked form various other versions, all calling their stuff "ESP-01 AT firmware".

In theory one should be able to update any ESP-01 to the latest AT firmware but that can require configuring the programming IDE and even the source code definitions to match the hardware being used before programming, and that isn't necessarily easy.

The easiest option is to just stick with the core AT commands, and hack the code to handle slightly different modules where necessary -

https://room-15.github.io/blog/2015/03/26/esp8266-at-command-reference/
 

lbenson

Senior Member
This series has worked for me with different responses to AT+GMR:
AT+GMR
AT+RST [then power-cycle]
AT+CWMODE_DEF=1
AT+CWLAP
AT+CWJAP_DEF="mySSID","myPW"
AT+CIPSTA_DEF="192.168.1.27"
AT+UART_DEF=9600,8,1,0,0 [for 20X2 so you have time to interrupt on background hardware serial receive to prevent scratchpad overrun ]
AT+CIFSR [check IP]
AT+CIPMUX=1
AT+CIPSERVER=1,80

Working code for 20x2, 28x2, and 40x2 at https://picaxeforum.co.uk/threads/28x2-40x2-picaxe-web-server-with-esp-01-and-pi-javascript.31912/

I tried flashing a new SDK to one ESP-01, and while success was reported, I could never get it to respond to "AT" at any baud rate.

Sufficient 3V3 current can be critical, though I have had good success just plugging an esp-01 adapter into a laptop usb port.
 
Last edited:

Buzby

Senior Member
Nothing ? It simply seems to be that you are sending AT commands your ESP-01 firmware does not recognise or support.

The problem is there is no definitive "ESP-01", no singular AT firmware version. All should implement the core AT commands

It's a whole mish-mash of randomness ...
I wanted to run the 08M2 code that Charles Hampton wrote. A simple project to get me started.

Charles' code runs at 2400 baud, my ESP-thing runs at 115200. Simplest solution is to change the ESP-thing baud rate.

So I downloaded the 'ESP8266 AT Instruction Set' from espressif.com. Ver 3.0.2. Section 3 is 'Basic AT Commands', and querying for baud rate is one of them.

... In theory one should be able to update any ESP-01 to the latest AT firmware but that can require configuring the programming IDE and even the source code definitions to match the hardware being used before programming, and that isn't necessarily easy. ...
You're dead right - it's not easy !.

I found a dozen different ways, most of which expect you to be using A****** libraries, or you are already an experienced espressif development engineer.

Even the 'official' espressif tool doesn't match it's instructions, and still won't connect to my ESP-thing.

( I have managed to download ESP Basic to another 'identical' ESP-thing, and it looks very interesting. )

All this has convinced me that Rev-Ed are missing a trick here.

All I want to do is buy a module and use it as described in its manual, not jump through hoops in the dark.

Still not a happy bunny,

Buzby
 

PhilHornby

Senior Member
( I have managed to download ESP Basic to another 'identical' ESP-thing, and it looks very interesting. )
...
All I want to do is buy a module and use it as described in its manual, not jump through hoops in the dark.
You've already proved it's not that hard :)

I'm not convinced that Espressif ever considered the "AT firmware" to be "the product" ... I reckon it was just a demo of the sort of things you could do. When used with Picaxe, the ESP8266 is ideal for implementing a Web Server - with all that flash memory to store HTML. There's tons of example code out there. Granted, the ESP-01 variant is a bit lacking in IO, but that's where the Picaxe comes in.

To just use it as a serial Wifi module, is a case of the tail wagging the dog! ;)
 

lbenson

Senior Member
In AT mode, do you get nothing from AT+CWLAP? That should list available APs. If it doesn't, I'd first suspect insufficient power.

(I have to use <Enter> and <Ctrl-j> after my AT commands--no doubt I could set something in puTTY to make it automatic.)
 

Buzby

Senior Member
I've been at it for the last few hours, commenting out the stuff Charles Hampton's ESP needs, but mine doesn't, and swapping the ESP-thing between PICAXE and RealTerm to set some things by hand.

Now I've got it sending stuff to ThingSpeak, which was what I expected it to be doing 10 hours ago !.

The 'tail wagging the dog' analogy is quite true. The ESP8266 is way more powerful than the 08M2 it's connected to, but it's a very cheap way of sending a few packets.

Rev-Ed have definitely missed a trick here, but now I can use these $2 devices I'm almost happy.

Cheers,

Buzby
 

kfjl

Member
In AT mode, do you get nothing from AT+CWLAP? That should list available APs. If it doesn't, I'd first suspect insufficient power.

(I have to use <Enter> and <Ctrl-j> after my AT commands--no doubt I could set something in puTTY to make it automatic.)
The ESP is sold configured as an access point and will give an error if you ask it to scan for other access points in that mode. You have to be in station mode to see available networks.

Thanks for the "Ctrl-j" tip. I gave up trying to get AT commands to work from the Picaxe terminal yesterday. I just realised I've never actually done it before!
 

lbenson

Senior Member
what I expected it to be doing 10 hours ago
What did you do to get it to work?

Were you able to flash the latest SDK? If so, can you link to the firmware and the instructions? Last time I tried the flasher reported success, but I couldn't communicate with the ESP-01.

Charles Hampton article: https://www.allaboutcircuits.com/projects/build-a-picaxe-esp-01-wi-fi-communicator/

The ESP is sold configured as an access point and will give an error if you ask it to scan for other access points in that mode. You have to be in station mode to see available networks.
Right. In post 62, I had put AT+CWMODE_DEF=1 before AT+CWLAP, but I had forgotten why.
 

hippy

Senior Member
I wanted to run the 08M2 code that Charles Hampton wrote. A simple project to get me started
The problem there is the author seems to have written their code for a specific version of a product and you are using a different version of that product.

The big picture problem is it's often not understood that all products given the same name aren't the exact same product so we end up with authors writing code which won't work with other products and users trying to use products which won't work with that software.
 

Buzby

Senior Member
The big picture problem is it's often not understood that all products given the same name aren't the exact same product so we end up with authors writing code which won't work with other products and users trying to use products which won't work with that software.
Exactly !.

That's why I think Rev-Ed have missed out.

An AXE-ESP hard-programmed with known firmware, some decent documentation, and a few examples in PE6, would make a reliable starting point for anyone wanting to get into IOT stuff. ( Rev-Ed could just re-flash generic ESP-01s, then mark them with yellow paint like they did with the Ciseco stuff. )

As it is, every PICAXE user who wants to do IOT has to either work it out themselves, or choose a different platform.

Anyway, I've got my ESP-thingy talking WiFi through my router to ThingSpeak. Now I want to remove the router and ThingSpeak, and send data from one ESP-thingy to another ESP-thingy.

Time to trawl the Net !.

Cheers,

Buzby
 

kfjl

Member
What did you do to get it to work?

Were you able to flash the latest SDK? If so, can you link to the firmware and the instructions? Last time I tried the flasher reported success, but I couldn't communicate with the ESP-01.
Mornin',

I just uploaded the latest firmware with no trouble, using esptool.py. I suppose you're using that ugly and unwieldy (Windows look and feel) graphical interface.
Here's the command I used that might help you fill in the files to load and where to load them. With the full file paths you'll probably have more to write than I did! EDIT: I think I'm too biased against Microsoft to have noticed the buttons with the three dots...

esptool.py --chip esp8266 --port /dev/ttyUSB0 --baud 115200 write_flash 0x00000 boot_v1.7.bin 0x01000 user1.1024.new.2.bin 0xfc000 esp_init_data_default_v08.bin 0x7e000 blank.bin 0xfe000 blank.bin

The usefull bits are after "write_flash".
 
Last edited:

lbenson

Senior Member
Thanks--I did yesterday manage to upload the firmware using old ugly and unwieldy after building a new flashing circuit. The one I was using reported success, but apparently didn't actually do the flashing. So now I have a 20M2 on a PCB sending TCP messages to a local TCP listener, using Charles Hampton's code (modified because I initialized the ESP-01 with as many settings as possible).
 

Buzby

Senior Member
Thanks--I did yesterday manage to upload the firmware using old ugly and unwieldy ...
If you've managed to update your ESP with a fairly compatible firmware, connect it to a WiFi router, then execute AT+CIUPDATE

The ESP will update itself automagically to the official AT firmware from the Espressif website.

I've done this, and now my ESPs seem to support all the commands in the manual.

Cheers,

Buzby
 

lbenson

Senior Member
Thanks for the suggestion. With a ESP8285 with AT version 1.1.0.0, SDK version:1.5.4, I get "ERROR". I've thus far been unable to update an ESP8285 with any later AT firmware.

I can reliably update ESP-01s to AT version: 1.3.0.0, SDK version: 2.0.0, but not thus far to anything subsequent. I also get "ERROR" with that AT version trying AT+CIUPDATE. It looked like it was working, but then this:
Code:
WIFI CONNECTED
WIFI GOT IP

OK
AT+CIFSR
+CIFSR:STAIP,"192.168.2.211"
+CIFSR:STAMAC,"18:fe:34:f9:40:17"

OK
AT+CIUPDATE
+CIPUPDATE:1
+CIPUPDATE:2
+CIPUPDATE:3
+CIPUPDATE:3
+CIPUPDATE:4

ERROR
Power cycling gives me "ready", then "WIFI CONNECTED", then "WIFI GOT IP", but "AT+GMR" shows the same SDK v2.
Do you know from what version you were able successfully to update?

Has anyone successfully updated the AT firmware on an ESP8285? Searching the web has thus far given me nothing.
 

lbenson

Senior Member
I again tried to flash the latest firmware, SDK v3.03. Success is reported, but when I close the flashing software, power cycle and connect with puTTY, I get gobbledegook when I power cycle, and no response to typing.

Does anyone see anything evidently wrong with this?
Flash Firmware SDK3.03.jpg
(By the way, I'm successfully doing TCP sends to my local TCP listener with the SDK v2 firmware with PICAXE 20M2 with ESP-01, and with ESP8285 and SKD 1.54, using a program based on the Charles Hampton Instructable.)
 

Buzby

Senior Member
My ugly & unweildy is V3.8.5, and shows this when I run it :

23866

This gets me to the state where I can use auto-update, AT+CIUPDATE.

My automagically flashed ESPs then show :

AT+GMR
AT version:1.6.2.0(Apr 13 2018 11:10:59)
SDK version:2.2.1(6ab97e9)
compile time:Jun 7 2018 19:34:26
Bin version(Wroom 02):1.6.2
OK

I've now got no problem connecting AT mode ESP to router, and have got simple ESP to ESP working, but need to do more work on it.

Cheers,

Buzby
 
Last edited:

kfjl

Member
I again tried to flash the latest firmware, SDK v3.03. Success is reported, but when I close the flashing software, power cycle and connect with puTTY, I get gobbledegook when I power cycle, and no response to typing.

Does anyone see anything evidently wrong with this?
View attachment 23865
(By the way, I'm successfully doing TCP sends to my local TCP listener with the SDK v2 firmware with PICAXE 20M2 with ESP-01, and with ESP8285 and SKD 1.54, using a program based on the Charles Hampton Instructable.)
At 0X1000 you're trying to upload a file that probably doesn't exist yet. Use the one in Buzby's ugly and unweildy or my esptool command line. That's why I posted it.

Buzby:

Why do you update your firmware with windaube and then again with the AT command? Why update at all? What do you think you get that's better than what you had? AT+GMR gives me the same reply as you without the AT update.
 

Buzby

Senior Member
Why do you update your firmware with windaube and then again with the AT command? Why update at all? What do you think you get that's better than what you had? AT+GMR gives me the same reply as you without the AT update.
My 'raw' ESPs from Amazon, or wherever I got them, I forget, show :

AT+GMR
AT version:1.2.0.0(Jul 1 2016 20:04:45)
SDK version:1.5.4.1(39cb9a32)
v1.0.0
Mar 11 2018 18:27:31

After a 'ugly & unweildy' update, my ESPs say :

AT+GMR
AT version:1.4.0.0(May 5 2017 16:10:59)
SDK version:2.1.0(116b762)
compile time:May 5 2017 16:37:48

I have absolutely no idea why these numbers don't seem to match anything on the 'ugly & unweildy' page, even though this is what is now supposed to be in the little bug.

Finally, after a wireless CIUPDATE, they say :

AT+GMR
AT version:1.6.2.0(Apr 13 2018 11:10:59)
SDK version:2.2.1(6ab97e9)
compile time:Jun 7 2018 19:34:26
Bin version(Wroom 02):1.6.2

Now, it may be that your ESP-01s are not the same as my ESP-01s.

This would not happen if we had yellow dots on them !.

Cheers,

Buzby
 

kfjl

Member
So,

"Ugly and unweildy" is a bit behind the times. This is what I get using esptool.py:

AT+GMR
AT version:1.6.2.0(Apr 13 2018 11:10:59)
SDK version:2.2.1(6ab97e9)
compile time:Jun 7 2018 19:34:26
Bin version(Wroom 02):1.6.2
OK

The same as you but without CIUPDATE.

I think we have the same ESPs.

Charles Hampton probably had a 512K version which is why the addresses he first gives don't work now. He must have followed the datasheet chiselled on the underside of the Rosetta stone next to the code for Windows 11.
 

Buzby

Senior Member
So, we now have the same FW in our ESPs ?

Well, not quite.

I bought five of them.

Three are now flashed to 1.6.2.0, all respond nicely to AT commands,

one doesn't work at all, it's just a brick,

and the fifth is programmed with ESPbasic, and I'm lovin' it !.

Cheers,

Buzby
 
Top