ESP8266 Community Forum

- Thu Nov 13, 2014 7:40 am #2546 I tried to send AT+CWMODE=1<cr> (and <cr><lf>) at 9600 as well as several other baud rates, but this doesn't seem to happen on my module.
Are you able to reproduce this consistently?
Can you grab the bootloader dump using another serial port? Would be helpful to know whether this is a wdt reset or an exception (if so, what were the registers).

- Thu Nov 13, 2014 8:54 am #2549 I've tried with CoolTerm
AT + CWMODE = 1 (CR + LF) -> Reset
AT + CWMODE = 1 (CR) -> OK
with Putty:
AT + CWMODE = 1 (CR + LF) -> OK
AT + CWMODE = 1 (CR) -> OK
It is probably due to the CoolTerm

regards Allex

- Thu Nov 13, 2014 4:37 pm #2574

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:

Code: Select all+CIPACCEPT="0","192.169.0.120"


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.

Hi igrr !
I've played a bit with the server implementation. Seems to work well and easy to play with ! Thanks for all your efforts !!!

I found two small glitches that you are maybe already aware :
1 - connections are doing timeout after few seconds (this is probably the same timeout settings than the original AT example, but in your atproto, I didn't found a command to change the timeout value)
2 - if I shutdown the server using AT+CIPCLOSE=6, but then I try to connect a new client, connection will be accomplish instead of been refused and after first crlf from this client a wdt-reset will occur.

- Fri Nov 14, 2014 6:24 pm #2657

Hi igrr !
I've played a bit with the server implementation. Seems to work well and easy to play with ! Thanks for all your efforts !!!

Yep, kicking pretty good

I found two small glitches that you are maybe already aware :
1 - connections are doing timeout after few seconds (this is probably the same timeout settings than the original AT example, but in your atproto, I didn't found a command to change the timeout value)

I prefer cleaner approach: open connection ,send data, close connection, fast no need to worry about timeouts , as for me I think I will *almost* never go over ~1440 bytes ine one go (about that much data can hold one eth packet with TCP/IP headers)...

2 - if I shutdown the server using AT+CIPCLOSE=6, but then I try to connect a new client, connection will be accomplish instead of been refused and after first crlf from this client a wdt-reset will occur.

Yes, this happens, I have created issue at github .