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

Technical Support
Staff 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

Technical Support
Staff 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

Technical Support
Staff 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

Technical Support
Staff 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

Technical Support
Staff 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

Technical Support
Staff 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

Technical Support
Staff 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

Technical Support
Staff 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

Technical Support
Staff 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.
 
Top