ESP8266 Community Forum

- Fri Oct 24, 2014 2:00 am #1887 Yeah, in my firmware i try to have most commands return immediate result codes, and issue URC's when something happens later.
I.e. when you do AT+CIPCONNECT, you get OK immediately. Then when connection is actually established you get an unsolicited result code like +CIPSTATUS:3.
This way it's easier to implement an FSM at the host side, as you get clear feedback that state transition has actually happened.

- Fri Oct 24, 2014 2:14 am #1888 OK it is a comfort to see someone else see the unpleasant short comings of the esp8266 interface. Now IMHO the issue isn't just immediacy ( like getting a guaranteed fast OK) it is the lack of a a unique and both necessary and sufficient token ( delimiter) to indicate the preparedness of the esp8266 to accept the next command. OK is fine if it is never used in any other context than to indicate another command is acceptable. IMHO an AT or AT+ prompt issued by the esp8266 is more obvious and does little violence to the current interface.. in fact it would save typing AT every time. The AT lacks uniqueness unless the esp8266 echo of a command is suppressed since it will have the token AT in the echo but AT CR+LF would work and the MCU or human would send
the +...... chars to complete the command.

- Fri Oct 24, 2014 2:59 am #1891

it is the lack of a a unique and both necessary and sufficient token ( delimiter) to indicate the preparedness of the esp8266 to accept the next command. OK is fine if it is never used in any other context than to indicate another command is acceptable.

Well, I agree that a unique and an unambiguous indicator of some state transition is a welcome feature in an asynchronous protocol. But for a number of reasons, that's not how the AT protocol is designed. You don't have to expect a unique token from every command. For each command the modem will issue a different response (some are just "OK", some are more complex), and it's up to the DTE software to expect proper reply from the DCE. For instance, you may have the following pseudocode for setting echo off:

Code: Select allsend_command("E0")
if (accept_basic_result_code(RC_OK))
    change_state(EVENT_ECHO_OFF)
else if (accept_basic_result_code(RC_ERROR))
    change_state(EVENT_UNEXPECTED_ERROR)
else
    fail()


This was easy, right? Now for a more complex command, like "+CWLAP" command from the esp firmware, you would have the following pseudocode:

Code: Select allsend_command("+CWLAP")
if (!accept_information_response_header())
{
    if(accept_basic_result_code(RC_ERROR)
        change_state(EVENT_SOMETHING_STRANGE_HAPPENED_TO_THE_MODULE)
    else
        fail()
}
while (!accept_basic_result_code(RC_OK))
{
   access_point_data = accept_information_response_line()
   /// do smth with access_point_data
}
change_state(EVENT_GOT_ACCESS_POINTS_LIST)


So when you have basic "accept_stuff" and "expect_stuff" commands implemented, it's not that hard to handle AT protocol.
And then you can take a look at the chat program. It is easy to implement, and it may be sufficient for some use cases with ESP, given a more standard-behaving firmware is available.

- Fri Oct 24, 2014 11:11 am #1913 OK I accept the features of AT commands in that is the best it is ever going to get with the esp8266. With AT the DTE has to have the lexigraphic capability of retrieving context from every response. Since the responses are varied and sometimes multiline it has the issue that mathematical completeness can't easily be established or maybe never established. The esp8266 could chirp something unexpected and if the documentation is impaired then the unexpected becomes highly probable. These devices I expect will be left unattended for extended periods in which case the failsafe concept of a watchdog becomes an integral feature instead of just failsafe. For a high speed interface this is not good.Often the number of fail safe watchdog restarts is used as an indicator of pending hardware failure. Using the watchdog to offset a lack of certainty in the communication puts an end to this.
The current AT approach does violence to the features that it actually serves...One one side there could be TCP/IP which has windowed flow control to avoid either party overrunning the other. The other side of the esp8266 the AT side is almost the wild west of orderly flow control. Either the esp8266 or the MCU could potentially overrun each other. Even 40 years ago in the days of mechanical 100 baud teletype, rs232 had flow control.
Without mathematical completeness in the communication flow any mission critical use of the esp8266 is unwise.
Maybe AT should be abandoned in favor of a high speed interface SPI with an established master slave relationship.
I have the esp8266 turning led's on and off but turning a pool pump on or off or a lawn sprinkler is unwise without completeness in the communication protocol.
Even a light switch is unwise since people can get hurt if the esp8266 glitches itself or the mcu and leaves someone in the dark.
Phillips has a $60 IoT LED light device ....wonder how they are handling the communications? .. I'd wager they don't use AT commands.