Skip to content
This repository has been archived by the owner on Jan 14, 2022. It is now read-only.

Incorrect AT command line handling #16

Open
hlovdal opened this issue Feb 22, 2017 · 1 comment
Open

Incorrect AT command line handling #16

hlovdal opened this issue Feb 22, 2017 · 1 comment

Comments

@hlovdal
Copy link

hlovdal commented Feb 22, 2017

The AT description page states that

AT instruction ends with “\r\n”

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)

@briantw
Copy link

briantw commented Aug 22, 2020

It's a mess.

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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants