ESP8266 Community Forum

I have TCP/UDP client working now. Server and "pass-through" modes are not implemented yet.

There's a CIPCREATE="TCP|UDP" command that creates a socket context with a given protocol. It has two more optional numeric arguments: local port and receive buffer size. It returns an extended result code in the following form: +CIPCREATE:<context id>,<port>,<rx buffer size>. CIPCLOSE=<context id> command should be used to recycle the context when it is no longer used.

CIPCONNECT=<context id>,"remote IP address",<remote port> will open connection to the remote socket in case of TCP protocol or just store the remote address and port in case of UDP. It returns +CIPCONNECT:<context_id> on success.
CIPDISCONNECT=<context id> closes the connection.

When data is received, an unsolicited result code is emitted to indicate that data is ready: +CIPDR:<context id>,<data size>. To read data, issue CIPRD command: CIPRD=<context id>. It will return CIPRD:<context id>,<data size> followed by an information response containing all the received data in plain text, followed by OK result code.

The only command to send data so far is CIPSENDI=<context id>,"data" (I stands for immediate), which takes context id and the data to be sent, as a string. You may use the following escape sequences in the string: \" (quote), \n (LF), \r (CR), \t (TAB), \xab (character with ASCII code 0xab).

Also take note of ATV0 command that switches the output into V0 mode, which has less CR+LF characters, and numeric return codes instead of text. It should be easier to parse automatically.

Regarding detailed error codes: it will probably be easier to add a command like IERRNO? to return the error code of the last error.

I'll add more commands and put this stuff into readme in the next few days.

I have started a wiki to document the commands and responses for my AT protocol firmware.
https://github.com/igrr/atproto/wiki/AT ... -reference

The TCP/UDP server command is almost ready, but I need a few days to figure out a better way to handle disconnect and other errors.
The espconn api that has rather quirky error handling, so it's pretty difficult to build anything reliable upon it without some dirty hacks. I would advise anyone starting their own esp8266 projects now to use lwip api directly (and link against lwip.a), and I regret going down the espconn road

Your work so far looks great, Thanks for the effort.

Using the lwip stack alone do you know if there is anything that needs to be done except using the lwip headers?
Any specific version?
Do we need to setup the timers or are they already initialized?

Guess I should probably start a new thread for this. http://www.esp8266.com/viewtopic.php?f=6&t=421

Hi,

igrr respect for all your hard work.

I will humble propose two things, that I think could be useful (consider those as wishes ) , and if you have a good mood and motivation to include in your art . Since I started to play with this module I miss information whom I received packet/data, it would be nice to enable displaying that info (IP and/or MAC and/or port) this would also help to create filter in mcu (mcu that talking to the module via rs) for unwanted packets that could be sent from other (unwanted) host.
I have already looked through at-command set for ESP and I'm pretty sure that setting up static IP address is impossible at this moment - would be nice to be able to do it .

I have question about AT+GSN this will return MAC address or some other s/n ?

Again, big thanks for your work igrr!