- Sun Oct 19, 2014 4:28 pm
#1774
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.
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.
) , 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. 
