You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 14, 2022. It is now read-only.
however this is not correct AT command behaviour. The ITU V.250 specification (previously V.25ter), which is the official specification for AT commands, specifies the following with regards to the AT command line syntax:
5.2.1 Command line general format
A command line is made up of three elements: the prefix, the body, and the termination character.
...
The termination character may be selected by a user option (parameter S3), the default being CR
Notice that the command line is terminated by a single character, being \r for all practical purposes.
Could you fix the code to behave like a proper modem and support proper command line termination?
Still accepting (incorrect) line termination with "\r\n"is both possible and common for modems, so this fix should not imply breaking changes for any existing clients/code.
Hm, looking into the source code I see some other issues as well.
case at_statRecving: //push receive data to cmd line
...
else if(pCmdLine >= &at_cmdLine[at_cmdLenMax - 1])
{
at_state = at_statIdle;
}
pCmdLine++;
break;
Here you abort processing if the given command line input is too long and there is principally nothing wrong with that, however not giving out an ERROR final result code for this is totally unacceptable. How is the client sending the AT command line supposed to understand that the command line was too long and that it was not processed?
Also the termination is too early, it should continue to "parse" (e.g. ignoring) the command line up till, including the terminating character. The current code will falsely trigger parsing at in cats in the example below as an AT command.
AT+QUESTION="...some 100+ character beginning ... do you like cats?"\r
The V.250 specification is crystal clear on how the proper behaviour should be:
5.5 Issuing commands
...
If the maximum number of characters that the DCE can accept in the body is exceeded, an ERROR
result code shall be generated after the command line is terminated.
(DCE = modem, Data Circuit-terminating Equipment)
The text was updated successfully, but these errors were encountered:
AT\n works as it's supposed to. AT\r doesn't work at all. AT+GMR\n returns an ERROR, but AT+GMR\r also does nothing. Use both CR and LF, in any order, and it works: AT+GMR followed by either \r\n or \n\r returns the version number, just that one has a \r\n\r in the response, while the other has \r\r\n.
I thought it was just I having trouble reaching some sort of consistency in my code, but now having looked at their code, I realise it's all a big mess and you have to work around it. There are newer versions of the OS, but this is the last version that will work on my ESP-03 with a mere 4 Mb (512 KB) flash.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The AT description page states that
however this is not correct AT command behaviour. The ITU V.250 specification (previously V.25ter), which is the official specification for AT commands, specifies the following with regards to the AT command line syntax:
Notice that the command line is terminated by a single character, being
\r
for all practical purposes.Could you fix the code to behave like a proper modem and support proper command line termination?
Still accepting (incorrect) line termination with
"\r\n"
is both possible and common for modems, so this fix should not imply breaking changes for any existing clients/code.Hm, looking into the source code I see some other issues as well.
Here you abort processing if the given command line input is too long and there is principally nothing wrong with that, however not giving out an ERROR final result code for this is totally unacceptable. How is the client sending the AT command line supposed to understand that the command line was too long and that it was not processed?
Also the termination is too early, it should continue to "parse" (e.g. ignoring) the command line up till, including the terminating character. The current code will falsely trigger parsing
at
in cats in the example below as an AT command.AT+QUESTION="...some 100+ character beginning ... do you like cats?"\r
The V.250 specification is crystal clear on how the proper behaviour should be:
(DCE = modem, Data Circuit-terminating Equipment)
The text was updated successfully, but these errors were encountered: