Here we can all chat about fixing the AT+ command structure and the associated responses.

User avatar
By Squonk
#1925
picstart1 wrote:As to the GPS sentences having a specific name ....many names are trademarked (copyrighted) in the US and require a legal recognition when used on a forum. US citizens have to follow US law no matter where the forum is located. Sure it is a finicky explanation and you were right to name the name but people could be theoretically sued for saying "double click" without permission since a large software company located in Redmond owns the idea.

Come on, I am sure you clicked on a link to reach this page, so you may already infringe some stupid patents :roll:

NMEA stands for "National Marine Electronics Association" and is a public association name, so cannot be copyrighted or trademarked as such, although their logo may have a trademark.

NMEA0183 is the last version of their previous NMEA0180 and NMEA0182 standards that are cited all over the Internet, including on Wikipedia, so they won't send you the dogs for citing a standard reference in an obscure forum.

Be careful, I filed a patent on "breathing" :mrgreen:
User avatar
By picstart1
#1927 Squonk,
Comme j'ai dit c'etait pas le plus fort explanation a ma part parceque la chance je vais me trouver a l'autre cote de la loie n'est pas si grand.
Anyway I agree with you there is nothing wrong with AT commands if implemented correctly.
I'm frustrated with the "busy now.... " and if new firmware addresses this and a hardware reset initializes the esp8266 to a predictable state
things will be manageable. I have the SDK and some boards that bring most of the esp8266 pins out are on the way so I'll look into
making the esp8266 MCU do all the work and eliminate the MCU interface.
Merci Thanks et bon weekend
User avatar
By Squonk
#1932 Yes, now that an official SDK is available and if you are already familiar with MCU programming, working directly on the ESP8266 without external MCU is the way to go, unless you have extremely time-critical tasks to perform that require precise latency, like servo control, for example.
User avatar
By alonewolfx2
#2154 hi iggr. what is the send_command command? and how can i send CIPSTART command in user main for autonomus operation ? can you help me?
i tried at_setupCmdCipserver(16, "=1,9876"); and its working.
i tried at_setupCmdCipmux(15, "=1"); and its working.
at_exeCmdGmr(); and its working. but
i tried at_setupCmdCipstart(12,"=3,\"TCP\",\"www.mbokurt.com\",80"); and uart going crazy and esp restart and again again again :)
what am i suppose to do?



igrr wrote:
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.