ESP8266 Community Forum

- Tue Oct 21, 2014 3:02 pm #1816 I have had these chips for a few weeks and there are still unresolved issues.

The primary response to the esp8266 receiving a command is to echo it. This is moderately useful since I have used it to validate that the esp8266 received the command.
There are no issues with this since I'm using a PIC mcu at 64Mhz and validating via UART isr the asynchronous command echo at 115200 baud.
Many command echos are followed by a simple OK and again this is not challenging. For others several characters of information are sent before the OK
Other commands EX AT+CIPSTATUS return a variable response after the command echo like STATUS:3
Issues
My isr captures the value in the above case 3 and it turns out this is a pleasant value to get and probably means connected.
4 probably means there is a bad connection issue
1 or 2 are still a mystery.
If anyone has a good documentation of these STATUS values it would help.

Then there is the dreaded busy ...
So far clearing busy .... requires a reset. I do a hardware reset and sometimes it clears it sometimes it doesn't, same with AT+RST
The people readable AT+ commands are fine enough but for autonomous systems all the responses need to be addressed to prevent the esp8266 glitching the MCU code.
The people readable AT+ approach has logical structure but lacks the rigiidity of GPS sentences with their well defined start and end and a check sum.
Parsing the unstructured AT+ is already several hundred lines of c code and I haven't covered every possible response since every response is not so far documented.
I'm using a programatic command line for the autonomous WIFI client
printf(WIFI_PUTC,"\t3AT+CIPSEND=\aESP8266\f"); ...This places chars into the UART tx and scripts the logic for the ESP8266 response
esc sequences \tx starts the sentence and asserts a 3 second for a response \a starts chars to be uploaded (ESP8266) and \f terminates the sentence
a command echo is always validated but if \v ex \vOK is present then the response is validated as well.
One thing to note is the ESP8266 mostly shows CR+LF delimiters but the ESP8266 can react to the CR and interpret the LF as data to upload. Best to just use CR and for get the LF.
Both are there for human readabilty and only one is logically necessary.
Second thing the AT+SEND=n wait for > then upload is restrictive in the value of n ascii values '1'..'9' are the only ones accepted.... no more than 9 chars tops.
Again making this a two step handshake ( request n chars then wait for > and send n chars seems programmatically unwise by the ESP8266 design team.

- Thu Oct 23, 2014 10:59 am #1861 This human readable AT interface is problematical when trying to make autonomous ( take human input out of the process).
The dreaded busy now.... response is an example ..it appears to require a necessary hardware restart but I'm uncertain as to whether it is sufficient.
If this interface is ever reworked IMHO the esp8266 needs a ready to accept further commands indicator ...I'd go for AT+ (or just AT) to which the user would respond by completing the specific command they have in mind. Any typo would get a message eg INVALID followed by AT+ to accept a corrected command. A valid AT+command would be processed the response could be OK wrapped with LF CR but the final state of the esp8266 ( ready for another command) would always be indicated by AT+. The LF CR that currently acts as a termination delimiter is inelegant in that LF CR can appear mid stream of a multi-line response. Sure if you know for certain the exact number of CR LF's a command will illicit you get something to work but it is messy and inelegant.
If at power up and after completion of every command by the esp8266 it responded with AT+ it would act as a necessary and sufficient indicator of the esp8266's willingness to process another command. An internal watchdog within the esp8266 would reset the esp8266 should the esp8266 not arrive (within the watchdog period) at a state in which it could issue AT+.
Further the commands do have dependencies command y won't work well unless command x or several commands x are issued first. There are probably just a handful of these dependencies so IMHO an ERROR n response is needed to localize the incorrect precondition and immediately followed by AT+ to accept another command.
Asynchronous communications are problematical in that both sides of the line can be masters ( chirp anytime they choose). In rs232 this is often managed by DTR RTS or XON XOFF but I'm unsure as to if the esp8266 has addressed this. On the autonomous MCU side chirping by the esp8266 can be addressed with an isr feeding a ring buffer but it requires a FSM to acquire context for the response ( varied responses to a single command)...on the esp8266 I suspect bytes arriving unexpectedly just go into a bit bucket and are ignored or glitch the esp8266.
The +IPD x is acceptable since x being the number of chars to accept provides a definite termination of the stream.
Anyway the esp8266 is impressive both to price and footprint but underwhelming in the implementation of the AT type interface

- Thu Oct 23, 2014 4:08 pm #1870 Check @igrr efforts to provide a more standard AT command set in this thread:
viewtopic.php?f=14&t=201

- Fri Oct 24, 2014 1:51 am #1886 The issue isn't parsing ATcommands the AT stuff is a bit lexigraphical but very doable. The issue IMHO are the esp8266 responses. The esp8266 lacks a necessary and sufficient delimiter to indicate the esp is prepared to accept the next command. Since the interface is asynchronous the MCU accepting esp8266 chars doesn't easily know when the last char has arrived ( the exception is the +IPD n char stream). nor when or if the esp8266 is ready for another command. Since the internal state of the esp8266 is uncertain as to whether a new command will be accepted if commands are sent they have a probability of generating the dreaded (busy now... ) response. This makes the MCU heavily dependent on timers ( delays) to control the feeding of commands.
The esp terminal like human readable and human interaction timescale interface is unpleasant for automation. Many expect the internet of things will be mostly autonomous and probably only few expect esp8266 commands to be typed by hand though it does make for a quick out of the gate human interface for initial curiosity and testing of commands.