I have been using pre UDP firmware and also just started using the latest code for the Parallax ESP module.
And The latest code doesn't send me a D reply when polling the module that has received data from the result of a CONNECT and SEND, and a REPLY by the other module.
The pre-udp firmware it works fine.
It replies with a D, and the data size.
The new firmware will ONLY show in the debug that
601352> [1601352] TCP: 5 received 123 bytes
601352> [1601352] TCP: added 123 bytes to buffer
611592> [1611592] TCP: 5 disconnected
It never sends a poll response for this event.
Can anyone confirm this?
Since you have been doing udp work, did something break the poll response output when receiving data in the latest firmware?
@iseries
I can post the command sequence I am using on both modules, but the code works on PRE udp firmware. (prior to you merging)
I haven't compiled commits between that and the latest to see if they all have the issue.
I am simply connecting to another module with the connect command, the other module connects properly, and then I send it the packet to activate the other modules handle, which does work to get the other module to reply with the proper reply packet.
The main connecting module does see it because it replies with
601352> [1601352] TCP: 5 received 123 bytes
601352> [1601352] TCP: added 123 bytes to buffer
611592> [1611592] TCP: 5 disconnected
But the other module only sent 38 bytes as the reply
But when I change the amount sent, the debug received bytes does change.
So the main connecting module is getting the reply, but never sends an event poll reply to the prop chip.
Here is the debug output from the connecting module.
As you can see it reports getting the TCP data, but never replies with a b = D:handle,size E like it should.
Remember my spin code works in pre-udp firmware prior to the latest firmware.
I have verified the bug, I downgraded my firmware first on the master connection initiator, and still the tcp data would not arrive.
So then I downgraded the slave side that sends the data, and then the comms worked again.
So the issue is in the slave code that the connection master talks to? I don't know... but
I didn't try using master connection initiator with new firmware with old slave firmware...
The latest firmware breaks the "D" poll event for tcp data?
This image shows v1.2 firmware on both the connection master its tx and rx lines, plus its debug output. Those are the parallax terminals.
The putty windows are what the master(engine) and slave(caboose) are showing on the telnet port.
You can see the "D" poll event in the debug output and also in one of the parallax terminals.
You need to change caboose.railroad.local to the proper domain name of the target wx for the CONNECT command.
And then you will need to change the address to the same proper domain name, in the send packet,
and count and also change the number of bytes more or less that changed for your target domain name.
Unless you use a domain name that uses the same amount of characters as "caboose.railroad.local"
This code is rough and some of the comments are wak or wrong, but the code works.
Let it run for a bit to loop, so it syncs.
I had discovered a problem with UDP not able to receive packets due to a port issue. This was sent as a fix but is not part of any current version available.
The version I tried which fails to send the "D" poll reply, was from a git of the latest Parallax-Esp code in github, as of yesterday.
I also found a bug where if you are in STA mode, you cannot change the modules name, i think its a malocced message in debug when saving to flash.
Not sure if that is fixed with latest code, it happens in 1.2
The documentation is not real clear here. The way the code works for me is that if an HTTP request comes in for a URL I have defined the WX module automaticly response with a "!G,5,1" response without any polling. From there I just respond to the request and all is well. The D response seems to be for web sockets or a TCP request not defined as HTTP or something.
This makes the code much simpler in that I can just wait for some data and respond to it without all that nasty POLL and check code.
Here is the sample code I used, sorry for the c code:
Also I think it would be simpler to just connect by using the telnet port and just sending a request and then just send the response back without all the HTTP header data getting in the way.
The documentation is not real clear here. The way the code works for me is that if an HTTP request comes in for a URL I have defined the WX module automaticly response with a "!G,5,1" response without any polling. From there I just respond to the request and all is well. The D response seems to be for web sockets or a TCP request not defined as HTTP or something.
I never get any "!G,5,1" reply from the wx device, ever. In either firmware version. With my spin code that works with 1.2
I don't know what you are talking about with a http request... This code is prop chip to wx to wx to prop chip and was based loosely on a c example.
It may do what you say, but I HAVE NO IDEA BECAUSE NOTHING WAS DOCUMENTED.
I don't know what the firmware CAN do, DOES, SUPPOSED TO DO, I assumed it does what v1.2 did, but the functionality has changed, and breaks what 1.2 can do.
I only know what the original 2016 32420-Parallax-Wi-Fi-Module-API-v1.0.pdf says, beyond that, its a gem in the middle of a forum post that never made the documentation. And then theres the example C programs that have functionality that was NEVER documented or even described at all, other than in a C example.
And even then I had to spy on the TX and RX lines on the wx device to see what commands are being used.
So telling me bits of how it works, or what I am doing wrong or right or how I should do it, wont work without some kinda firmware documentation.
When I use the connect command...
The wx reports the connection as a tcp connection.
I don't know what you are trying to say, but the spin code works with firmware prior to the udp changes which is v1.2.
So you are saying I need to change code that works in v1.2 to something ..."else" and when you give me c code which i can barely read.
Giving the description for functionality changes in the firmware, in the form of a C program is not going to work here.
I could just read the firmware code(eventually) if I could do that.
Are you saying the MANUAL for the WX device needs to be re-written for firmware post v1.2?
I don't see any documentation at all for anything past 1.2 .
Even the v1.0 and 1.2 versions have requirements that are not documented, for instance to even get this prop to wx to wx to prop code i had to run a c program that already did this, and then extract the commands being sent back and forth to the wx device and the prop chips.
With enough of that i was able to reconstruct the connection and data transfer using spin.
No documentation has helped me there, and shame.. Why implement functionality if no one is going to even DOCUMENT IT, or how it works.
How is anyone supposed to know how the wx device works, unless they are a C programmer?
When engineering, I had to constantly take notes during the layout and subsequent design changes and testing, etc, to help with the official documentation of the product.
If I had waited till I made it all and tested it, before making documentation and notes, I would have forgotten half of the functionality and requirements, specifications, revision changes, functionality differences, etc...
And the manual would have been a single page with most of the functionality missing for most, except for those that know hardware hacking.
I guess even the documentation for code changes in Parallax-ESP firmware v1.2 still needs to be written.
If that isn't even documented, why implement udp or more features?
Or if your goal is to cater to your own needs and other C programmers, who can read the changes themselves, then Carry on.
I don't need to know what c code works to make a feature functional.
I guess that is at least better than nothing, BUT YOU LEAVE ME TO ALMOST NOTHING.
I have to run the c code, HOPING IT ACTUALLY WORKS WITH NO BUGS, and then try to reverse engineer the data going over the TX and RX lines.
Cmon, that is a big rough as far as figuring out how new firmware works.
You give lots of c example code, and I give it a real gung-ho attempt to reverse engineer it only to have it not work, and I come back saying it dosen't work...
I tried that, and when the example code didn't work, you THEN tell me that its not implemented in the firmware yet. lol
Why even give me example code then?
That is damn confusing.
So having more c code as an example, not knowing if its implemented in the firmware, or if it has bugs, etc..
You are all over the map here.
I don't know if I am coming or going!
Why not just write some documentation?
At that point I should just be hired to do the documentation if I am reverse engineering it, since no one else is doing it.
But since I cannot read the firmware I will be missing most of the functionality and probably have no info on requirements and syntax.
I need to know the exact commands, the options of them, and their requirements, that are implemented in the firmware.
If no one is going to document that, then parallax should just stop selling the WX devices.
I am sorry, but it is very frustrating to not have documentation and then have someone tell me to do something differently because of firmware undocumented functionality changes, ... and then give me an example in c code.
The very language the firmware is written in. Anyone see the irony?
My frustration is understandable here, most would agree.
Yes I get this is all free, open source, and no one is paid to help or contribute.
But guys, at least document code functionality and any functionality changes in a clear way.
Heck, edit the original api pdf and ADD or change what what done in code, and call the file unofficial api documentation.
A good example of undocumented requirements in v1.2 is this bit of code.
ser.rxflush
waitcnt(1_000_000 + cnt) 'wait 1/16 second.
ser.char(254) 'Begin marker
waitcnt(1_000_000 + cnt) 'wait 1/16 second.
ser.str(string("SEND:")) 'Retrieve the path associated with a connection handle or listener id.
waitcnt(1_000_000 + cnt) 'wait 1/16 second.
ser.char(ClientListener) 'An active connection handle; returned by POLL
waitcnt(1_000_000 + cnt) 'wait 1/16 second.
ser.str(string(",")) 'Tell the module how many bytes? (or is this digits?) the send is.
waitcnt(1_000_000 + cnt) 'wait 1/16 second.
ser.str(string("92")) 'Tell the module how many bytes? (or is this digits?) the send is.
'ser.str(string("87")) 'Tell the module how many bytes? (or is this digits?) the send is.
waitcnt(1_000_000 + cnt) 'wait 1/16 second.
ser.char(13) 'End marker
waitcnt(1_000_000 + cnt) 'Wait for 1/16 s Let buffer fill.
ser.str(string("GET /hostess HTTP/1.1")) '21 21 Twinkies.
ser.char(13) '\r 1 22
ser.char(10) '\n 1 23
ser.str(string("Host: caboose.railroad.local")) '28 51 Change this to match your hostname.domain.local you will need to count the total bytes with the new address. Above
ser.char(13) '\r 1 52
ser.char(10) '\n 1 53
ser.str(string("Connection: keep-alive")) '22 75
ser.char(13) '\r 1 76
ser.char(10) '\n 1 77
ser.str(string("Accept: */*")) '11 88
ser.char(13) '\r 1 89
ser.char(10) '\n 1 90
ser.char(13) '\r 1 91
ser.char(10) '\n 1 92
Example: The SEND command and subsequent packet.
There is absolutely NO information on this packet that must be sent to activate my /hostess listener on my caboose.railroad.local wx device.
Or info on what options you have for that packet. It uses GET.. why? what else can be put there if anything? SET? it uses HOST: any other options?
And it uses Connection: keep-alive. what if any does this even do? what are its options?
It uses Accept: / what does that mean? what are its options?
Why is all that required? what its the syntax of that packet? etc.
The same can be said for the code that runs on the caboose.railroad.local wx device.
Its packet to reply with data, that data packet has a specific syntax, but not documented at all anywhere.
the incoming packet from caboose.railroad.local has lots of info added to the data by the wx firmware that is sent.
Which then needs to be filtered out. Why?
Again totally absent documentation on it all.
HTTP/1.1 200 OK
Server: esp8266-httpd/0.4
Connection: close
Content-Length: 38
This header is included with the packet of data sent from the caboose.
You may understand it fine, but I don't at all, don't know why its included, no idea what added it, and don't even know what options I can change if any, and even how.
Like its it possible to have the connection: keep-alive like the first packet?
Is this functionality non-functionality?
Why does the server say esp8266 when its in fact caboose.railroad.local that was the data sender?
We all know the esp is the middle man.
And this functionality is included with v1.2 The code boat left while the documentation boat is still at dock.
Apparently the idea is, no one contributes if they also must document.
So either functionality gets kinda implemented, but no documentation (no real way to debug test it if you arent a c programmer)
Or nothing extra gets implemented because .... who wants to document.... u already did the code work. Its just not fair to document it and work more.
Code galore.
Documentation absent.
At that point we are all vogons. It really is the new standard with all this open source stuff.
It took me forever to even figure out the syntax and code to make that non-documented connection work, and you now say do it a different way?
Just shoot me now. I need documentation, this is ridiculous.
I will need to figure out that and other fixes, reverse them if I want them ( very unlikely), so i can add them to v1.2 if this 'D' data poll message missing cannot be fixed in the latest version.
I already use the telnet connection for debug output so i don't want to use that.
Also I don't even know how to tell the telnet connection to connect to another wx telnet. Is it just simply using port 23 in the connect command?
Then what I send data using SEND on the master, and RECV on the slave side?
Does the api talk about doing telnet links? I didn't see it.
This stuff is not intuitive for most, i get that it is for those who know web/telnet/ports/udp/tcp and c.
I feel like the api just kinda leaves me grasping in the dark here still even with all of its documentation.
It really should have example programs or sudo code.
Multiple code examples are common in official parallax documentation.
The wx API has 0 code examples.
Pardon my French, but I can't write SPIN code and fall back on C as I know it works. The UDP issues are not your problem.
I have command responses turned on which can be found in the manual on page 8: cmd-events = YES. This causes the connection to send a response without polling for it which is easier to do in my option.
I will turn this off and see if I can reproduce your error.
From your code, it looks like you know how to use Putty. The WX module when it starts up it builds a Telnet, Port 25, connection automatically so that it can ack as a terminal with the serial interface of Propeller. You can use this interface if you want by opening a connection to the WiFi module using the Telnet port. This is a direct serial interface that whatever is sent or received is just that.
From your code, it looks like you want to be able to pass some data between Propellers using the WiFi module. There are many ways to do that and HTTP is one of them. All I'm saying is that HTTP has some overhead that you need to deal with.
Pardon my French, but I can't write SPIN code and fall back on C as I know it works. The UDP issues are not your problem.
pseudo code would work with all the required commands and syntax for the wx module.
And the various "overhead requirements" examples.
I have command responses turned on which can be found in the manual on page 8: cmd-events = YES. This causes the connection to send a response without polling for it which is easier to do in my option.
That might make your data recieved 'G' message show up perhaps, I will try that, but yes, odd that it removes 'D' poll when OFF.
I will turn this off and see if I can reproduce your error.
This might explain how the bug showed up with this new feature.
From your code, it looks like you know how to use Putty. The WX module when it starts up it builds a Telnet, Port 25, connection automatically so that it can ack as a terminal with the serial interface of Propeller. You can use this interface if you want by opening a connection to the WiFi module using the Telnet port. This is a direct serial interface that whatever is sent or received is just that.
Those are the kind of things that should be in the API or even in the forums in small posts, I am trying to add example programs for various situations in spin, similar to some that already exist in C.
From your code, it looks like you want to be able to pass some data between Propellers using the WiFi module. There are many ways to do that and HTTP is one of them. All I'm saying is that HTTP has some overhead that you need to deal with.
That information would be very helpful in the api also under the connection function, some descriptions on how to set up various connections.
From what I understand so far, my method to connect the two modules in the above code is http? (i don't know it was based on c code below)
And that overhead is the packet requirements? I say again, how would anyone know that? Other than by reading the c code?
In the learn folder from simple ide, Learn\Examples\Network\WiFi\Prop to Prop via WX (Client).side and Prop to Prop via WX (Host).side
I have no idea what kind of link this code is doing, is it http?
No idea why it needs the address twice, once in the connect and once in the packet. Again, nothing in the api or even the c code comments.
Perhaps we need to start another thread and try to build sudo code that are examples of things people want to do without hiding some of the data.
HTTP is it's own language and hence if you don't use that language you don't know what goes on in the background. The browser you use is hiding things from you.
So are you saying that packet is http information, and for some reason the debug message calls the data tcp, i guess http data is tcp or udp..
I guess i should have known, since it connects on port 80 and the listener uses HTTP. Hehe, I wrote the entire spin program and didn't realize the packet has http "code?"
So then the http standard has this info in it?
ser.str(string("GET /hostess HTTP/1.1")) '21 21 Twinkies.
ser.char(13) '\r 1 22
ser.char(10) '\n 1 23
ser.str(string("Host: caboose.railroad.local")) '28 51 Change this to match your hostname.domain.local you will need to count the total bytes with the new address. Above
ser.char(13) '\r 1 52
ser.char(10) '\n 1 53
ser.str(string("Connection: keep-alive")) '22 75
ser.char(13) '\r 1 76
ser.char(10) '\n 1 77
ser.str(string("Accept: */*")) '11 88
A hint in the c code or the manual on how to use the http listener?
I get that I don't know enough, but not knowing if the above packet was something related to the esp firmware was the problem, I did not know the below information, until now. https://developer.mozilla.org/en-US/docs/Web/HTTP/Session
No description of this packet ever labeled it "A HTTP session client request."
You can even code a html page and not know this. Most of it is hidden, but doesn't need to be the case for the api or even c code comments.
I will be changing my code example to actually say that in the code comments. That this packet of information follows the standard for a "HTTP session client request"
And I might even add some of the various options that can be used,
Http headers... response status codes, request methods... etc... even include a link to that url. but copying some of those little bits is easy and helps a new user alot.
I knew about status codes, but not the other stuff, and never knew the anatomy of a http client request, never needed to, until now.
Back to the 'D' missing poll response.
I will give my code and the above client/host c code a test and see if they get stuck at never receiving the 'D' poll response in the latest firmware, from my initial investigations, that was the case.
I would like to continue using the 'D' poll method since its synchronous and my spin code is also.
Having a 'G' pop up at data reception event asynchronously, would present unpredictable results due to the rx buffer getting data when unexpected?
So far my testing has found the 'D' poll event goes missing in latest firmware.
I will try to run the client/host c code to see if it also fails to operate.
Since you like C, that should make testing this easy for you.
These are the two C programs to run on the host wx prop chip, and the client wx prop chip.
The spin program I posted above earlier does basically the same thing.
I found the issue with the "D" code. In the original code it would only receive the first packet of data from a HTTP request and not look for more data to arrive.
The way TCP data works is that it will send a packet of data but not all the data has to be sent at one time. The network can break up packets of data and send them as multiple pieces of data. To assume that all the data arrives is a poor assumption that in most cases is correct.
That's why there is a length field in HTTP request that tells the receiving side how much data should be coming and that if that is not what is received it should wait for more data to arrive.
There was a flag labeled as TXFULL which really meant TXDATA had arrived and was not being set so the "D" poll would not work.
In the code I wrote I would just do a receive against the request and wait up to a some amount of time for all the data to arrive and not poll for it since the receive function is none blocking and a timer could be easily set.
This bug was found when doing a HTTP request against a Weather service that sent packets of data back and some of the data was lost.
To fix this is simple but needs to be tested before being approve for use.
A receive after the last poll returned all the data no issues
Mike
Yea looks better, I didn't do a receive if I didn't get a 'D' because I didn't know how much data was to be received.. (actually i do, but i programmed it to get the size off the poll 'D' reply)
I have been testing it for a bit now and things I found.
This compile I am testing is from iseries Parallax-Esp repo.
The 'D' message works properly now, I will continue to test it.
When in STA mode, you cannot change the module name. (not sure if this is new)
Change it then save to flash, then reload from flash, and it is back to what it was before you changed it.
A hard reset will happen if you RELOAD (F5) the debug log page. (this is new)
236137> Conn req from 192.168.1.2:49717, using pool slot 0
236138> URL = /log.html
236139> Heatshrink compressed file; decode parms = b4
236761> Conn req from 192.168.1.2:49720, using pool slot 1
236763> URL = /console.js
236764> Heatshrink compressed file; decode parms = b4
236767> Conn req from 192.168.1.2:49721, using pool slot 2
236771> URL = /ui.js
236773> Heatshrink compressed file; decode parms = b4
236777> E:M 1584
236778> E:M 1584
236780> E:M 1584
236781> E:M 1584
236783> E:M 1584
236785> E:M 1584
236786> E:M 1584
236788> E:M 1584
236789> Httpd: queuing 142 byte buffer
236954> Pool slot 0 is done. Closing.
236954> Pool slot 0: socket closed.
238582> Pool slot 1 is done. Closing.
238583> Pool slot 1: socket closed.
246641> Pool slot 2: socket closed.
246644> Conn req from 192.168.1.2:49738, using pool slot 0
246645> URL = /ui.js
246646> Heatshrink compressed file; decode parms = b4
249796> Pool slot 0 is done. Closing.
249797> Pool slot 0: socket closed.
249910> Conn req from 192.168.1.2:49741, using pool slot 0
249911> URL = /log/text?start=0
249911> GET args = start=0
249915> Pool slot 0 is done. Closing.
249916> Pool slot 0: socket closed.
259063> Conn req from 192.168.1.2:49750, using pool slot 0
259065> URL = /log.html
259066> Heatshrink compressed file; decode parms = b4
259689> Conn req from 192.168.1.2:49753, using pool slot 1
259689> Conn req from 192.168.1.2:49754, using pool slot 2
259692> URL = /console.js
259694> Heatshrink compressed file; decode parms = b4
259699> URL = /ui.js
259700> Heatshrink compressed file; decode parms = b4
259704> E:M 2096
259707> Conn req from 192.168.1.2:49755, using pool slot 3
259711> E:M 2056
259713> URL = /logo.png
259715> Fatal exception 29(StoreProhibitedCause):
259719> epc1=0x4000df64, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
ÿ
ets Jan 8 2013,rst cause:1, boot mode:(3,6)
load 0x40100000, len 2592, room 16
tail 0
chksum 0xf3
load 0x3ffe8000, len 764, room 8
tail 4
chksum 0x92
load 0x3ffe82fc, len 676, room 4
tail 0
chksum 0x22
csum 0x22
2nd boot version : 1.7(5d6f877)
SPI Speed : 40MHz
SPI Mode : QIO
SPI Flash Size & Map: 32Mbit(512KB+512KB)
jump to run user1 @ 1000
Flash config restore ok
116> Reset Pin: 13
116> RX Pullup: 0
122> DISCOVER: initialized
122> Version v1.5 (2021-03-22 03:10:14 0-gb4e6028)
122> Using pin 13 for reset
123> 4MB flash: base 00100000, size 3145728
128> Flash filesystem mounted!
131> Httpd init
132>
133> Ready
135> mode : sta(xx:xx:xx:xx:xx:xx)
138> add if0
261> scandone
264> state: 0 -> 2 (b0)
269> state: 2 -> 3 (0)
273> state: 3 -> 5 (10)
273> add 0
273> aid 4
273> cnt
289>
289> connected with WyePhi, channel 5
290> dhcp client start...
1085> ip:192.168.1.13,mask:255.255.255.0,gw:192.168.1.1
2069> Conn req from 192.168.1.2:49756, using pool slot 0
2071> URL = /logo.png
3889> Pool slot 0 is done. Closing.
3889> Pool slot 0: socket closed.
9959> Conn req from 192.168.1.2:49759, using pool slot 0
9961> URL = /ui.js
9962> Heatshrink compressed file; decode parms = b4
10273> pm open,type:2 0
12964> Pool slot 0 is done. Closing.
12964> Pool slot 0: socket closed.
14496> Conn req from 192.168.1.2:49761, using pool slot 0
14498> URL = /log.html
14498> Heatshrink compressed file; decode parms = b4
15299> Conn req from 192.168.1.2:49762, using pool slot 1
15300> Conn req from 192.168.1.2:49763, using pool slot 2
15301> Conn req from 192.168.1.2:49764, using pool slot 3
15308> URL = /console.js
15310> Heatshrink compressed file; decode parms = b4
15315> URL = /ui.js
15316> Heatshrink compressed file; decode parms = b4
15320> E:M 2096
15322> E:M 1584
15324> E:M 1584
15325> E:M 1584
15327> E:M 1584
15328> E:M 1584
15330> E:M 1584
15331> E:M 1584
15333> E:M 1584
15334> Httpd: queuing 142 byte buffer
15338> E:M 2056
15340> URL = /logo.png
15342> Fatal exception 29(StoreProhibitedCause):
15346> epc1=0x4000df64, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
ÿ
ets Jan 8 2013,rst cause:1, boot mode:(3,6)
load 0x40100000, len 2592, room 16
tail 0
chksum 0xf3
load 0x3ffe8000, len 764, room 8
tail 4
chksum 0x92
load 0x3ffe82fc, len 676, room 4
tail 0
chksum 0x22
csum 0x22
2nd boot version : 1.7(5d6f877)
SPI Speed : 40MHz
SPI Mode : QIO
SPI Flash Size & Map: 32Mbit(512KB+512KB)
jump to run user1 @ 1000
Flash config restore ok
118> Reset Pin: 13
118> RX Pullup: 0
124> DISCOVER: initialized
124> Version v1.5 (2021-03-22 03:10:14 0-gb4e6028)
125> Using pin 13 for reset
126> 4MB flash: base 00100000, size 3145728
130> Flash filesystem mounted!
133> Httpd init
135>
136> Ready
137> mode : sta(xx:xx:xx:xx:xx:xx)
140> add if0
263> scandone
266> state: 0 -> 2 (b0)
271> state: 2 -> 3 (0)
275> state: 3 -> 5 (10)
275> add 0
275> aid 4
275> cnt
288>
288> connected with WeiPhi, channel 5
288> dhcp client start...
1087> ip:192.168.1.13,mask:255.255.255.0,gw:192.168.1.1
2043> Conn req from 192.168.1.2:49765, using pool slot 0
2044> Conn req from 192.168.1.2:49766, using pool slot 1
2046> URL = /logo.png
2049> URL = /ui.js
2050> Heatshrink compressed file; decode parms = b4
3883> Pool slot 1 is done. Closing.
3884> Pool slot 1: socket closed.
5103> Pool slot 0 is done. Closing.
5104> Pool slot 0: socket closed.
7700> Conn req from 192.168.1.2:49768, using pool slot 0
7701> URL = /log.html
7702> Heatshrink compressed file; decode parms = b4
8326> Pool slot 0 is done. Closing.
8327> Pool slot 0: socket closed.
8486> Conn req from 192.168.1.2:49769, using pool slot 0
8488> URL = /log/text?start=0
8488> GET args = start=0
8492> Pool slot 0 is done. Closing.
8493> Pool slot 0: socket closed.
10275> pm open,type:2 0
A EM error will occur as usual when accessing the network page. (this is not new)
18866> Conn req from 192.168.1.2:49566, using pool slot 0
18868> URL = /wifi/wifi.html
18869> Heatshrink compressed file; decode parms = b4
19141> Conn req from 192.168.1.2:49567, using pool slot 1
19142> Conn req from 192.168.1.2:49568, using pool slot 2
19144> URL = /wifi/style.css
19147> Heatshrink compressed file; decode parms = b4
19152> URL = /wifi/140medley.min.js
19155> Heatshrink compressed file; decode parms = b4
19159> E:M 2096
19160> E:M 1584
19162> E:M 1584
19163> E:M 1584
19165> E:M 1584
19167> E:M 1584
19168> E:M 1584
19170> E:M 1584
19171> E:M 1584
19173> Httpd: queuing 142 byte buffer
19657> Pool slot 1 is done. Closing.
19658> Pool slot 1: socket closed.
21498> Pool slot 0 is done. Closing.
21499> Pool slot 0: socket closed.
29130> Pool slot 2: socket closed.
29135> Conn req from 192.168.1.2:49570, using pool slot 0
29136> URL = /wifi/140medley.min.js
29137> Heatshrink compressed file; decode parms = b4
29558> Pool slot 0 is done. Closing.
29558> Pool slot 0: socket closed.
29565> Conn req from 192.168.1.2:49571, using pool slot 0
29567> URL = /wx/setting?name=wifi-ssid
29567> GET args = name=wifi-ssid
I did not try lowering the 4096 to 1024, as talked about before, iseries still has 4096 set.
During my flashing of modules, i have been trying out 2M size and 4M size, with no big difference in either case. (except for file space?)
I have tried using 40m for the flash speed with the newer flash espflash.py tool, since its what is used for the old espflash tool that is included in with the parallax-esp repo. Not sure what difference this makes, it might explain why sometimes when I flash-all, it doesn't take, or will remember previous settings.
Going to use 40m for now.
I am still testing, but i seem to have issues with this new firmware where connections are getting dropped, or listeners are or something. After a while my webpages will totally stop responding and so will my telnet debug connections. I am going to work on this to see if my code can be changed or if I can ID what is going on.
Correct, you can not change the module name in STA mode only in AP mode.
The unit should not reboot anymore as the issue with this was found. The HTTP server would allocate memory that was not available and did not check that it got back a valid amount of memory. It would then use that bad memory causing a reboot to occur. I put in several check in the code that should prevent that from happening. Running the unit at 4096 will cause an issue with this as there is not enough memory left to run multiple request.
I ran the unit yesterday with 1024 and did not see any reboots. I will test more and see if I may have missed a memory allocation issue.
Oops, I just not see the issue you are having. Your compiles are incomplete in that you do not have the HTTP fixes that are also needed and they are not apart of the latest release.
@iseries said:
Latest ota file with all the fixes in it.
Mike
I can't use OTA files because I customize my html pages, and I like to code the module name.
I also like to include the proper tag, 1.5beta or something, easier for debugging and swapping between firmware versions.
I do not know if the bug I found that resets the wx module when running out of sscp connections comes from that or not, I know that v1.2 does not do this.
It seems when I issue a CLOSE command for any given HANDLE, they take a long time to close.
This is when the hard reset of the wx module happens, when it runs out of connections while taking a long time to close them, when it officially closes one (the "T",handle, 0) AFTER running out, it crashes.
I can try that ota file to see if it also generates the exact same hard reset.
But without being able to compile the fix myself, i cannot use it.
Without a repo to copy and compile from, its very hard to test these fixes for bugs.
Is there a reason why the parallax repo isn't getting these fixes anymore?
The day the parallax-esp repo committed those udp changes, was the day it became a beta(alpha) repo?
I mean, the latest parallax-esp repo is kinda experimental anyway, it has broken 'D' code introduced with one of the UDP changes, right now as the latest compile, so why not push fixes, or get them up in someones repo?
Comments
Is this a compile bug?
When the folder I git "Parallax-ESP " into has spaces, it fails build.
So if I put Parallax-ESP into \Proto Stuff\Parallax-ESP
And then make it.
I get a make error.
But if I remove the space in the folder name between \ProtoStuff\
It compiles fine.
I have been using pre UDP firmware and also just started using the latest code for the Parallax ESP module.
And The latest code doesn't send me a D reply when polling the module that has received data from the result of a CONNECT and SEND, and a REPLY by the other module.
The pre-udp firmware it works fine.
It replies with a D, and the data size.
The new firmware will ONLY show in the debug that
It never sends a poll response for this event.
Can anyone confirm this?
Since you have been doing udp work, did something break the poll response output when receiving data in the latest firmware?
@iseries
I can post the command sequence I am using on both modules, but the code works on PRE udp firmware. (prior to you merging)
I haven't compiled commits between that and the latest to see if they all have the issue.
I am simply connecting to another module with the connect command, the other module connects properly, and then I send it the packet to activate the other modules handle, which does work to get the other module to reply with the proper reply packet.
The main connecting module does see it because it replies with
But the other module only sent 38 bytes as the reply
But when I change the amount sent, the debug received bytes does change.
So the main connecting module is getting the reply, but never sends an event poll reply to the prop chip.
Here is the debug output from the connecting module.
As you can see it reports getting the TCP data, but never replies with a
b = D:handle,size Elike it should.Remember my spin code works in pre-udp firmware prior to the latest firmware.
I am not good with c, but i can see where the debug outputs the message it recieved the data...
https://github.com/parallaxinc/Parallax-ESP/blob/e0c7a81958684d1f30ae5d6aedf67e0a14a1d8ac/parallax/sscp-tcp.c
sscp_log("TCP: %d received %d bytes", c->hdr.handle, len);and
sscp_log("TCP: added %d bytes to buffer", len);So this code is running...
static void ICACHE_FLASH_ATTR tcp_recv_cb(void *arg, char *data, unsigned short len) { int i; struct espconn *conn = (struct espconn *)arg; sscp_connection *c = (sscp_connection *)conn->reverse; sscp_log("TCP: %d received %d bytes", c->hdr.handle, len); if (!(c->flags & CONNECTION_RXFULL)) { i = c->rxCount; if ((len + i)> SSCP_RX_BUFFER_MAX) len = SSCP_RX_BUFFER_MAX - i; os_memcpy(c->rxBuffer + i, data, len); c->rxCount = i + len; c->rxIndex = 0; if (c->rxCount >= SSCP_RX_BUFFER_MAX) c->flags |= CONNECTION_RXFULL; sscp_log("TCP: added %d bytes to buffer", len); if (flashConfig.sscp_events) send_data_event(c, '!'); } }Then it invokes
send_data_event(c, '!');Which LOOKs like it should be working...
static void ICACHE_FLASH_ATTR send_data_event(sscp_connection *connection, int prefix) { sscp_sendResponse("D,%d,%d", connection->hdr.handle, connection->rxCount); }It has the
"D,%d,%d", connection->hdr.handle, connection->rxCountSo somehow
if (flashConfig.sscp_events) send_data_event(c, '!');is not running, or running properly.
I have verified the bug, I downgraded my firmware first on the master connection initiator, and still the tcp data would not arrive.
So then I downgraded the slave side that sends the data, and then the comms worked again.
So the issue is in the slave code that the connection master talks to? I don't know... but
I didn't try using master connection initiator with new firmware with old slave firmware...
So the v1.2 firmware works properly.
https://forums.parallax.com/discussion/comment/1505874/#Comment_1505874
The latest firmware breaks the "D" poll event for tcp data?
This image shows v1.2 firmware on both the connection master its tx and rx lines, plus its debug output. Those are the parallax terminals.
The putty windows are what the master(engine) and slave(caboose) are showing on the telnet port.
You can see the "D" poll event in the debug output and also in one of the parallax terminals.
Here is a prop to wx to wx to prop communiction code example.
I can only get this code to work with ParallaxESP v1.2 firmware.
https://forums.parallax.com/discussion/comment/1505874/#Comment_1505874
You need to change caboose.railroad.local to the proper domain name of the target wx for the CONNECT command.
And then you will need to change the address to the same proper domain name, in the send packet,
and count and also change the number of bytes more or less that changed for your target domain name.
Unless you use a domain name that uses the same amount of characters as "caboose.railroad.local"
This code is rough and some of the comments are wak or wrong, but the code works.
Let it run for a bit to loop, so it syncs.
I had discovered a problem with UDP not able to receive packets due to a port issue. This was sent as a fix but is not part of any current version available.
Where did you get the version you are running?
Let me test this and see what the issue is.
Mike
The version I tried which fails to send the "D" poll reply, was from a git of the latest Parallax-Esp code in github, as of yesterday.
I also found a bug where if you are in STA mode, you cannot change the modules name, i think its a malocced message in debug when saving to flash.
Not sure if that is fixed with latest code, it happens in 1.2
@"Clock Loop" ,
I'm not good with SPIN but it looks like you are setting up a propeller as a host listening for a HTTP request on /hostess.
The client Propeller is sending a request to the host for /hostess getting in response the X and Y Axis values.
I will try and set this up.
Mike
Fairly sure I included that fix from iseries in the version currently shipping from Parallax.
That version is currently in my github
https://github.com/VonSzarvas/Parallax-ESP
@VonSzarvas ,
I see it as a open pull request, so I don't think all the fixes are in there.
Mike
@"Clock Loop" ,
The documentation is not real clear here. The way the code works for me is that if an HTTP request comes in for a URL I have defined the WX module automaticly response with a "!G,5,1" response without any polling. From there I just respond to the request and all is well. The D response seems to be for web sockets or a TCP request not defined as HTTP or something.
This makes the code much simpler in that I can just wait for some data and respond to it without all that nasty POLL and check code.
Here is the sample code I used, sorry for the c code:
#include <stdbool.h> #include <stdint.h> #include "simpletools.h" #include "fdserial.h" void test_print(char *, int); #define RX 14 #define TX 13 fdserial *fd; int i, j, h; char Buffer[256]; int main() { //simpleterm_close(); fd = fdserial_open(RX,TX,FDSERIAL_MODE_NONE, 115200); printi("Test\n"); dprint(fd, "%cLISTEN:HTTP,/hostess\r", 0xfe); pause(1000); i = fdserial_rxCount(fd); printi("(%d)", i); for (j=0;j<i;j++) { Buffer[j] = fdserial_rxChar(fd); } Buffer[j] = 0; printi(Buffer); while (1) { i = fdserial_rxCount(fd); for (j=0;j<i;j++) { Buffer[j] = fdserial_rxChar(fd); } Buffer[j] = 0; printi(Buffer); if (Buffer[2] == 'G') { h = Buffer[4] - '0'; printi("Sending Response(%d)\n", i); sprintf(Buffer, "\r\nXaxis>%d\r\nYaxis>%d\r\n", 1234, 5678); i = strlen(Buffer); dprint(fd, "%cREPLY:%d,200,%d,%d\r", 0xfe, h, i, i); dprint(fd, Buffer); } pause(1000); //dprint(fd, "%cPOLL\r", 0xfe); } } void test_print(char *data, int size) { for(int n = 0; n < size; n++) { if(data[n] <= 128 && data[n] >= ' ') { dprint(fd, "%c", data[n]); } else if(data[n] == 0) { dprint(fd, "[%x]", data[n]); break; } else if(data[n] == '\n') { dprint(fd, "%c", '\n'); } else { dprint(fd, "[%x]", data[n]); } } }Also I think it would be simpler to just connect by using the telnet port and just sending a request and then just send the response back without all the HTTP header data getting in the way.
Mike
I never get any "!G,5,1" reply from the wx device, ever. In either firmware version. With my spin code that works with 1.2
I don't know what you are talking about with a http request... This code is prop chip to wx to wx to prop chip and was based loosely on a c example.
It may do what you say, but I HAVE NO IDEA BECAUSE NOTHING WAS DOCUMENTED.
I don't know what the firmware CAN do, DOES, SUPPOSED TO DO, I assumed it does what v1.2 did, but the functionality has changed, and breaks what 1.2 can do.
I only know what the original 2016 32420-Parallax-Wi-Fi-Module-API-v1.0.pdf says, beyond that, its a gem in the middle of a forum post that never made the documentation. And then theres the example C programs that have functionality that was NEVER documented or even described at all, other than in a C example.
And even then I had to spy on the TX and RX lines on the wx device to see what commands are being used.
So telling me bits of how it works, or what I am doing wrong or right or how I should do it, wont work without some kinda firmware documentation.
When I use the connect command...
The wx reports the connection as a tcp connection.
I don't know what you are trying to say, but the spin code works with firmware prior to the udp changes which is v1.2.
So you are saying I need to change code that works in v1.2 to something ..."else" and when you give me c code which i can barely read.
Giving the description for functionality changes in the firmware, in the form of a C program is not going to work here.
I could just read the firmware code(eventually) if I could do that.
Are you saying the MANUAL for the WX device needs to be re-written for firmware post v1.2?
I don't see any documentation at all for anything past 1.2 .
Even the v1.0 and 1.2 versions have requirements that are not documented, for instance to even get this prop to wx to wx to prop code i had to run a c program that already did this, and then extract the commands being sent back and forth to the wx device and the prop chips.
With enough of that i was able to reconstruct the connection and data transfer using spin.
No documentation has helped me there, and shame.. Why implement functionality if no one is going to even DOCUMENT IT, or how it works.
How is anyone supposed to know how the wx device works, unless they are a C programmer?
When engineering, I had to constantly take notes during the layout and subsequent design changes and testing, etc, to help with the official documentation of the product.
If I had waited till I made it all and tested it, before making documentation and notes, I would have forgotten half of the functionality and requirements, specifications, revision changes, functionality differences, etc...
And the manual would have been a single page with most of the functionality missing for most, except for those that know hardware hacking.
I guess even the documentation for code changes in Parallax-ESP firmware v1.2 still needs to be written.
If that isn't even documented, why implement udp or more features?
Or if your goal is to cater to your own needs and other C programmers, who can read the changes themselves, then Carry on.
I don't need to know what c code works to make a feature functional.
I guess that is at least better than nothing, BUT YOU LEAVE ME TO ALMOST NOTHING.
I have to run the c code, HOPING IT ACTUALLY WORKS WITH NO BUGS, and then try to reverse engineer the data going over the TX and RX lines.
Cmon, that is a big rough as far as figuring out how new firmware works.
You give lots of c example code, and I give it a real gung-ho attempt to reverse engineer it only to have it not work, and I come back saying it dosen't work...
I tried that, and when the example code didn't work, you THEN tell me that its not implemented in the firmware yet. lol
Why even give me example code then?
That is damn confusing.
So having more c code as an example, not knowing if its implemented in the firmware, or if it has bugs, etc..
You are all over the map here.
I don't know if I am coming or going!
Why not just write some documentation?
At that point I should just be hired to do the documentation if I am reverse engineering it, since no one else is doing it.
But since I cannot read the firmware I will be missing most of the functionality and probably have no info on requirements and syntax.
I need to know the exact commands, the options of them, and their requirements, that are implemented in the firmware.
If no one is going to document that, then parallax should just stop selling the WX devices.
I am sorry, but it is very frustrating to not have documentation and then have someone tell me to do something differently because of firmware undocumented functionality changes, ... and then give me an example in c code.
The very language the firmware is written in. Anyone see the irony?
My frustration is understandable here, most would agree.
Yes I get this is all free, open source, and no one is paid to help or contribute.
But guys, at least document code functionality and any functionality changes in a clear way.
Heck, edit the original api pdf and ADD or change what what done in code, and call the file unofficial api documentation.
Post it here~! anywhere! PLEASE!
A good example of undocumented requirements in v1.2 is this bit of code.
ser.rxflush waitcnt(1_000_000 + cnt) 'wait 1/16 second. ser.char(254) 'Begin marker waitcnt(1_000_000 + cnt) 'wait 1/16 second. ser.str(string("SEND:")) 'Retrieve the path associated with a connection handle or listener id. waitcnt(1_000_000 + cnt) 'wait 1/16 second. ser.char(ClientListener) 'An active connection handle; returned by POLL waitcnt(1_000_000 + cnt) 'wait 1/16 second. ser.str(string(",")) 'Tell the module how many bytes? (or is this digits?) the send is. waitcnt(1_000_000 + cnt) 'wait 1/16 second. ser.str(string("92")) 'Tell the module how many bytes? (or is this digits?) the send is. 'ser.str(string("87")) 'Tell the module how many bytes? (or is this digits?) the send is. waitcnt(1_000_000 + cnt) 'wait 1/16 second. ser.char(13) 'End marker waitcnt(1_000_000 + cnt) 'Wait for 1/16 s Let buffer fill. ser.str(string("GET /hostess HTTP/1.1")) '21 21 Twinkies. ser.char(13) '\r 1 22 ser.char(10) '\n 1 23 ser.str(string("Host: caboose.railroad.local")) '28 51 Change this to match your hostname.domain.local you will need to count the total bytes with the new address. Above ser.char(13) '\r 1 52 ser.char(10) '\n 1 53 ser.str(string("Connection: keep-alive")) '22 75 ser.char(13) '\r 1 76 ser.char(10) '\n 1 77 ser.str(string("Accept: */*")) '11 88 ser.char(13) '\r 1 89 ser.char(10) '\n 1 90 ser.char(13) '\r 1 91 ser.char(10) '\n 1 92Example: The SEND command and subsequent packet.
There is absolutely NO information on this packet that must be sent to activate my /hostess listener on my caboose.railroad.local wx device.
Or info on what options you have for that packet. It uses GET.. why? what else can be put there if anything? SET? it uses HOST: any other options?
And it uses Connection: keep-alive. what if any does this even do? what are its options?
It uses Accept: / what does that mean? what are its options?
Why is all that required? what its the syntax of that packet? etc.
The same can be said for the code that runs on the caboose.railroad.local wx device.
Its packet to reply with data, that data packet has a specific syntax, but not documented at all anywhere.
the incoming packet from caboose.railroad.local has lots of info added to the data by the wx firmware that is sent.
Which then needs to be filtered out. Why?
Again totally absent documentation on it all.
This header is included with the packet of data sent from the caboose.
You may understand it fine, but I don't at all, don't know why its included, no idea what added it, and don't even know what options I can change if any, and even how.
Like its it possible to have the connection: keep-alive like the first packet?
Is this functionality non-functionality?
Why does the server say esp8266 when its in fact caboose.railroad.local that was the data sender?
We all know the esp is the middle man.
And this functionality is included with v1.2 The code boat left while the documentation boat is still at dock.
Apparently the idea is, no one contributes if they also must document.
So either functionality gets kinda implemented, but no documentation (no real way to debug test it if you arent a c programmer)
Or nothing extra gets implemented because .... who wants to document.... u already did the code work. Its just not fair to document it and work more.
Code galore.
Documentation absent.
At that point we are all vogons. It really is the new standard with all this open source stuff.
It took me forever to even figure out the syntax and code to make that non-documented connection work, and you now say do it a different way?
Just shoot me now. I need documentation, this is ridiculous.
I will need to figure out that and other fixes, reverse them if I want them ( very unlikely), so i can add them to v1.2 if this 'D' data poll message missing cannot be fixed in the latest version.
I already use the telnet connection for debug output so i don't want to use that.
Also I don't even know how to tell the telnet connection to connect to another wx telnet. Is it just simply using port 23 in the connect command?
Then what I send data using SEND on the master, and RECV on the slave side?
Does the api talk about doing telnet links? I didn't see it.
This stuff is not intuitive for most, i get that it is for those who know web/telnet/ports/udp/tcp and c.
I feel like the api just kinda leaves me grasping in the dark here still even with all of its documentation.
It really should have example programs or sudo code.
Multiple code examples are common in official parallax documentation.
The wx API has 0 code examples.
@"Clock Loop" ,
Pardon my French, but I can't write SPIN code and fall back on C as I know it works. The UDP issues are not your problem.
I have command responses turned on which can be found in the manual on page 8: cmd-events = YES. This causes the connection to send a response without polling for it which is easier to do in my option.
I will turn this off and see if I can reproduce your error.
From your code, it looks like you know how to use Putty. The WX module when it starts up it builds a Telnet, Port 25, connection automatically so that it can ack as a terminal with the serial interface of Propeller. You can use this interface if you want by opening a connection to the WiFi module using the Telnet port. This is a direct serial interface that whatever is sent or received is just that.
From your code, it looks like you want to be able to pass some data between Propellers using the WiFi module. There are many ways to do that and HTTP is one of them. All I'm saying is that HTTP has some overhead that you need to deal with.
Mike
pseudo code would work with all the required commands and syntax for the wx module.
And the various "overhead requirements" examples.
That might make your data recieved 'G' message show up perhaps, I will try that, but yes, odd that it removes 'D' poll when OFF.
This might explain how the bug showed up with this new feature.
Those are the kind of things that should be in the API or even in the forums in small posts, I am trying to add example programs for various situations in spin, similar to some that already exist in C.
That information would be very helpful in the api also under the connection function, some descriptions on how to set up various connections.
From what I understand so far, my method to connect the two modules in the above code is http? (i don't know it was based on c code below)
And that overhead is the packet requirements? I say again, how would anyone know that? Other than by reading the c code?
In the learn folder from simple ide, Learn\Examples\Network\WiFi\Prop to Prop via WX (Client).side and Prop to Prop via WX (Host).side
https://github.com/parallaxinc/Simple-Libraries/tree/master/Learn/Examples/Network/WiFi
The API is missing most of the information that these C files use in their c code to do many of these things that the programs do.
Example:
https://github.com/parallaxinc/Simple-Libraries/blob/master/Learn/Examples/Network/WiFi/Prop to Prop via WX (Client).c
I have no idea what kind of link this code is doing, is it http?
No idea why it needs the address twice, once in the connect and once in the packet. Again, nothing in the api or even the c code comments.
The Host also injects some kind of http information? into the data stream that arrives in the client prop receive buffer.
You must look at the data stream to see it.
https://github.com/parallaxinc/Simple-Libraries/blob/master/Learn/Examples/Network/WiFi/Prop to Prop via WX (Host).
@"Clock Loop" ,
Perhaps we need to start another thread and try to build sudo code that are examples of things people want to do without hiding some of the data.
HTTP is it's own language and hence if you don't use that language you don't know what goes on in the background. The browser you use is hiding things from you.
Mike
So are you saying that packet is http information, and for some reason the debug message calls the data tcp, i guess http data is tcp or udp..
I guess i should have known, since it connects on port 80 and the listener uses HTTP. Hehe, I wrote the entire spin program and didn't realize the packet has http "code?"
So then the http standard has this info in it?
ser.str(string("GET /hostess HTTP/1.1")) '21 21 Twinkies. ser.char(13) '\r 1 22 ser.char(10) '\n 1 23 ser.str(string("Host: caboose.railroad.local")) '28 51 Change this to match your hostname.domain.local you will need to count the total bytes with the new address. Above ser.char(13) '\r 1 52 ser.char(10) '\n 1 53 ser.str(string("Connection: keep-alive")) '22 75 ser.char(13) '\r 1 76 ser.char(10) '\n 1 77 ser.str(string("Accept: */*")) '11 88A hint in the c code or the manual on how to use the http listener?
I get that I don't know enough, but not knowing if the above packet was something related to the esp firmware was the problem, I did not know the below information, until now.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Session
Upon first seeing my posts about this information...
A simple reply to this page would have been GREAT. https://developer.mozilla.org/en-US/docs/Web/HTTP/Session
No description of this packet ever labeled it "A HTTP session client request."
You can even code a html page and not know this. Most of it is hidden, but doesn't need to be the case for the api or even c code comments.
I will be changing my code example to actually say that in the code comments. That this packet of information follows the standard for a "HTTP session client request"
And I might even add some of the various options that can be used,
Http headers... response status codes, request methods... etc... even include a link to that url. but copying some of those little bits is easy and helps a new user alot.
I knew about status codes, but not the other stuff, and never knew the anatomy of a http client request, never needed to, until now.
Back to the 'D' missing poll response.
I will give my code and the above client/host c code a test and see if they get stuck at never receiving the 'D' poll response in the latest firmware, from my initial investigations, that was the case.
I would like to continue using the 'D' poll method since its synchronous and my spin code is also.
Having a 'G' pop up at data reception event asynchronously, would present unpredictable results due to the rx buffer getting data when unexpected?
So far my testing has found the 'D' poll event goes missing in latest firmware.
I will try to run the client/host c code to see if it also fails to operate.
Since you like C, that should make testing this easy for you.
These are the two C programs to run on the host wx prop chip, and the client wx prop chip.
The spin program I posted above earlier does basically the same thing.
https://github.com/parallaxinc/Simple-Libraries/blob/master/Learn/Examples/Network/WiFi/Prop to Prop via WX (Client).c
https://github.com/parallaxinc/Simple-Libraries/blob/master/Learn/Examples/Network/WiFi/Prop to Prop via WX (Host)
I successfully use v1.2 firmware with these programs.
@"Clock Loop" ,
I found the issue with the "D" code. In the original code it would only receive the first packet of data from a HTTP request and not look for more data to arrive.
The way TCP data works is that it will send a packet of data but not all the data has to be sent at one time. The network can break up packets of data and send them as multiple pieces of data. To assume that all the data arrives is a poor assumption that in most cases is correct.
That's why there is a length field in HTTP request that tells the receiving side how much data should be coming and that if that is not what is received it should wait for more data to arrive.
There was a flag labeled as TXFULL which really meant TXDATA had arrived and was not being set so the "D" poll would not work.
In the code I wrote I would just do a receive against the request and wait up to a some amount of time for all the data to arrive and not poll for it since the receive function is none blocking and a timer could be easily set.
This bug was found when doing a HTTP request against a Weather service that sent packets of data back and some of the data was lost.
To fix this is simple but needs to be tested before being approve for use.
Mike
@"Clock Loop" ,
Before the fix this is what I got doing an HTTP request against a site:
A receive after the last poll returned all the data no issues
After the fix this is what I got doing an HTTP request against a site:
A receive after the last poll returned all the data no issues
Mike
@"Clock Loop" ,
With command events enabled with or without the fix this is what I get:
A receive returns all 887 bytes of data.
Mike
Yea looks better, I didn't do a receive if I didn't get a 'D' because I didn't know how much data was to be received.. (actually i do, but i programmed it to get the size off the poll 'D' reply)
Anyway I can test it?
I can do direct firmware edits find specific things, like the default name for the wx device can be changed in the c code,
https://forums.parallax.com/discussion/comment/1453063/#Comment_1453063
I just don't know what most of it is doing.
I 'make' attempts to read the make code also, and its pretty confusing.
EDIT: oh, you have it on your github! I give it a test! Thank you!
https://github.com/iseries1/Parallax-ESP/commits/master
I have been testing it for a bit now and things I found.
This compile I am testing is from iseries Parallax-Esp repo.
The 'D' message works properly now, I will continue to test it.
When in STA mode, you cannot change the module name. (not sure if this is new)
Change it then save to flash, then reload from flash, and it is back to what it was before you changed it.
A hard reset will happen if you RELOAD (F5) the debug log page. (this is new)
I did not try lowering the 4096 to 1024, as talked about before, iseries still has 4096 set.
During my flashing of modules, i have been trying out 2M size and 4M size, with no big difference in either case. (except for file space?)
I have tried using 40m for the flash speed with the newer flash espflash.py tool, since its what is used for the old espflash tool that is included in with the parallax-esp repo. Not sure what difference this makes, it might explain why sometimes when I flash-all, it doesn't take, or will remember previous settings.
Going to use 40m for now.
I am still testing, but i seem to have issues with this new firmware where connections are getting dropped, or listeners are or something. After a while my webpages will totally stop responding and so will my telnet debug connections. I am going to work on this to see if my code can be changed or if I can ID what is going on.
@"Clock Loop" ,
Correct, you can not change the module name in STA mode only in AP mode.
The unit should not reboot anymore as the issue with this was found. The HTTP server would allocate memory that was not available and did not check that it got back a valid amount of memory. It would then use that bad memory causing a reboot to occur. I put in several check in the code that should prevent that from happening. Running the unit at 4096 will cause an issue with this as there is not enough memory left to run multiple request.
I ran the unit yesterday with 1024 and did not see any reboots. I will test more and see if I may have missed a memory allocation issue.
Oops, I just not see the issue you are having. Your compiles are incomplete in that you do not have the HTTP fixes that are also needed and they are not apart of the latest release.
Mike
Latest ota file with all the fixes in it.
Mike
I can't use OTA files because I customize my html pages, and I like to code the module name.
I also like to include the proper tag, 1.5beta or something, easier for debugging and swapping between firmware versions.
I do not know if the bug I found that resets the wx module when running out of sscp connections comes from that or not, I know that v1.2 does not do this.
It seems when I issue a CLOSE command for any given HANDLE, they take a long time to close.
This is when the hard reset of the wx module happens, when it runs out of connections while taking a long time to close them, when it officially closes one (the "T",handle, 0) AFTER running out, it crashes.
I can try that ota file to see if it also generates the exact same hard reset.
But without being able to compile the fix myself, i cannot use it.
Without a repo to copy and compile from, its very hard to test these fixes for bugs.
Is there a reason why the parallax repo isn't getting these fixes anymore?
The day the parallax-esp repo committed those udp changes, was the day it became a beta(alpha) repo?
I mean, the latest parallax-esp repo is kinda experimental anyway, it has broken 'D' code introduced with one of the UDP changes, right now as the latest compile, so why not push fixes, or get them up in someones repo?
And also has the overflow issue still? (4096 not 1024?)
#define SSCP_RX_BUFFER_MAX 4096https://github.com/parallaxinc/Parallax-ESP/blob/master/parallax/sscp.h
I added that fix to the code, but it still has other issues related to the sscp connection reset.
Those who want a stable base can compile the 1.2 tag, or download the v1.2 firmware/ota from my esp8266 thread.
Good to know!, thanks.
Thats another reason I hardcode the name, and need a repo to compile!