- Thu Nov 13, 2014 2:55 am
#2532
Hey, thanks for trying!
cpct wrote:One question regarding AT+CIPRD. When I perform this command, I get some additional newlines (in Putty).
It looks like a correct output if you have V1 set (this is the default output formatting option).
Let me break down this exchange for you:
This is the echo of the command that you have sent. If you terminate your lines with <cr><lf>, that final <lf> is not echoed back, sorry. And the V.250 Rec. says that you should end lines with <cr>. By the way, you can turn off echo by sending ATE0<cr>.
This is an extended format result code. With V1, you get this extra <cr><lf> before the result code. If you switch to V0 (by sending ATV0), you will get the same response without leading <cr><lf> sequence.
Code: Select all<cr><lf>
This is a test<cr or lf>
<cr><lf>
Next goes the information response. Same as the result code, there's an extra leading <cr><lf> sequence for V1 mode. The <cr or lf> after "This is a test" comes from you hitting enter in netcat. Frankly I don't know what netcat sends when you hit enter. But it's one of them, not both, given the response is 15 bytes.
Basic result code that terminates the information response. Same thing applies: extra leading <cr><lf> in V1 mode.
So I think the newlines are generated by the firmware, it's not a putty issue. And it seems to be in line with what the standard says.
If you write some code that interacts with the module over serial, I suggest you send "ATE0<cr>ATV0<cr>" first to turn off echo and switch to V0 formatting. This will allow you to simplify lexer's state machine (if you are using one).
Regarding the server: TCP mode is in a somewhat useable state, it might be worth trying. You use it as follows (sorry didn't have time to update commands manual on github):
Code: Select allAT+CIPLISTEN="TCP",12345
+CIPLISTEN=6,12345
This will create a TCP server listening on port 12345. The reply contains context id for the server (6) and the port. You will need context id when you close the server.
When the server gets an incomming connection, you get the following unsolicited result code:
The first parameter is the context id of the client connection (you use it when you send and receive data to that client), the second one is the IP address of the client.
By the way, there's a limit of 5 client connections total, whether they are incoming (someone connects to your server) or outgoing (you connect to another server).
Now you work with this connection the same way, i.e. you send using +CIPSENDI, you get +CIPDR when the data is ready, and retrieve the data using +CIPRD. Supply context id given to you by +CIPACCEPT.
Don't forget to recycle the connection when it is no longer used (i.e. after +CIPDISCONNECT or +CIPRECONNECT) using +CIPCLOSE
There are a few bugs to fix (the buffer size is currently hard-coded for the incoming connections, and some issues with disconnect handling), but all the big stuff is in place.
Nice job! Hopefully server mode is not too much work 
