- Fri Oct 24, 2014 2:59 am
#1891
picstart1 wrote: 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.