I read ATDT -- thought "Oh, the Hayes command to dial - wonder what it means now." Great story. Good memories.
In fact, one of the earliest iPhone jailbreak exploits relied on a vulnerability in the AT command interpreter inside the baseband.
Why can't I just type !GSTATUS instead of AT!GSTATUS?
at!gstatus?
!GSTATUS:
Current Time: 555877 Temperature: 29
Modem Mitigate Level: 0 ModemProc Mitigate Level: 0
Reset Counter: 14 Mode: ONLINE
System mode: LTE PS state: Attached
[...]
I don't know how much low level serial protocol programming you have done, but in my experience, there is possibility of random line noise, and such. This is why generally these low level protocols have both PREFIX and POSTFIX for commands.
In the case of Hayes commands for modems, the prefix is AT, and the postfix is carriage return and line feed.
Tons!
The AT prefix, as such, does nothing whatsoever for error detection or recovery. If we add an AT prefix to an N-character command, the possibility of corruption in the N-character command part is exactly the same as before. Now, the AT also has to be correctly received, too.
An example of a textual protocol whose framing actually means something is the Mobitex MASC: http://www.mobitex.com/resources/masc/MASC_Guide.pdf
MASC frames have a checksum and length field in addition to the framing (frames start with ^ and end with a CR). MASC also dictates the use of 7 bits with even parity; so parity checking is possible by both endpoints. Still, that leading is a fluff feature that contributes nothing; the protocol could work fine with frames just being sequences of non-CR characters terminated by CR.
Modems usually have a solid connection to the host, often a short one; it's the actual end-to-end traffic that is susceptible to corruption; not so much the local commands between the host and modem. These modern LTE modem is often integrated onto the same chip as the host processor which is sending it the AT commands.
I did not claim it does any such thing.
In historical contexts, and even in some modern contexts, the data stream may include random noise data.
If we did not have a state machine looking for "AT" before beginning command processing, then we would potentially process some of this line noise as a command, which could potentially be bad.
Unless you have error detection / correction, etc, I don't think the AT would add anything else to the equation :-?
Now what do you do? Well, you check the first byte and see if it's a valid first byte for a command. There are hundreds of them, so basically every uppercase ASCII character should do.
In the happy path, you get a byte stream like "DT 1234\r\n".
Sometimes, the data stream has noise in it, so you get bytes like "%$DT 1234\r\n".
There are no commands that start with "%" or "$" so you can just drop it.
However, in the unhappy path, you might get bytes like "CMDT 1234\r\n".
CM is a valid command! But "DT 1234" are not valid arguments.
If only there was a way to get the ATtention of the parser before parsing commands...
(More or less; there is the obvious ambiguity of something on the remote end also responding to AT with OK.)
This useful AT just doesn't have to be a prefix of every other command.
AT
OK # I have the attention of the modem)
DT5553535 # dial this number now that I have your attention)
DIALING
CONNECT