15
\$\begingroup\$

Frankly, Why do all communication ICs(or at least many of them or most famous or popular) such as Bluetooth or WIFI or GSM or etc support AT command set? why don't they have a simple pin for D/C(Data or Command) for communications? What are the benefits of using AT command set?

The AT command set is big and would take time and memory space and it makes it difficult to communicate while you can instead use a simple D/C pin and send an integer to set registers or send data.

\$\endgroup\$
8
  • 18
    \$\begingroup\$ One word: Legacy ... They're all pretending to be Hayes compatible modems and have been since the dawn of time (or at least since the 80's, which is much the same thing). And no that's not really a good reason. \$\endgroup\$
    – brhans
    Commented Mar 23, 2015 at 17:16
  • 4
    \$\begingroup\$ Not only legacy, but a really good idea. As the old saying goes: "The wonderful thing about standards is that there are so many to choose from". I want my hardware and software to work with whatever communications module I am using without having to worry whether it speaks a different language (command set) than the one I was using before. \$\endgroup\$
    – Dwayne Reid
    Commented Mar 23, 2015 at 18:36
  • 7
    \$\begingroup\$ Obligatory XKCD here. \$\endgroup\$
    – bitsmack
    Commented Mar 23, 2015 at 21:07
  • 1
    \$\begingroup\$ In theory, you could unplug your WIFI module and replace it with one from another vendor. And because the protocol is the same, you don't even have to adjust the code. \$\endgroup\$
    – aaa
    Commented Mar 24, 2015 at 7:11
  • 1
    \$\begingroup\$ If something will be wrong with the communication/bits you won't get the right response i.e: "OK" So if you handle it accordingly, it's fairly stable. It's quite easy to debug, as the messages make sense in some way. The handling, however, is indeed a bit harder to implement. You have to check for said messages. And read them out, in a way that's not regular for a MCU. But then again, if you do this once, it will work for other AT devices. \$\endgroup\$
    – aaa
    Commented Mar 24, 2015 at 11:11

4 Answers 4

Reset to default
28
\$\begingroup\$

brhans is correct - Legacy.

In the 1980s, Hayes began making the "Smartmodem 1200". It was obsolete almost immediately and Hayes rushed out the Smartmodem 2400. In that rush, there was no time for design alterations between the modem designs. As a result, Hayes were the first to make two different speed modems that accepted the same programming commands! Any software that could get a Smartmodem 1200 to dial a telephone number could also dial a Smartmodem 2400.

At the time, every new modem required months for an updated driver to be written. When the Smartmodem 2400 came on the market, there was already a working driver for the Smartmodem 1200 so no months of waiting. Suddenly other manufacturers realised the advantage of new modems having the same command set as older modems. Within six months, vendors were offering "Hayes compatible" modems as the only choice. Which got them sued by Hayes. So everyone started calling their modems "AT Command Set compatible", but continued to use the Hayes command set.

By the mid 80s no consumer modems were made that could not use the AT command set. As a result every modem like comms system uses AT commands. There are other advantages too - as the command set is ASCII, anyone can manually type AT commands into a terminal window to control a modem. Because my own modem had a dicey RJ11 connection, I used to start every session in Procomm Plus with:

AT
OK
ATH1
[dial tone]
ATDT [phone number]

Just to make sure I got the dial tone. If I didn't, I'd go around and wiggle the wires a bit!

\$\endgroup\$
8
  • 1
    \$\begingroup\$ Good point on debugability. A pure binary protocol (such as LCD screen datastream) requires that you design hardware/firmware to even start talking to the device. AT command set allows you to test the device with zero hardware. All you need is a serial port (or these days a USB to serial converter) and a terminal emulator. \$\endgroup\$
    – slebetman
    Commented Mar 24, 2015 at 4:03
  • 1
    \$\begingroup\$ One small quibble... Winmodems preserved APPLICATION-level compatibility with AT commands, but completely broke OS-level compatibility. Pre-Winmodem, even internal modems interfaced through a bog-standard 16550A UART whose workings were well-known and transparently supported by Linux (because they looked just like normal ISA or PCI serial ports to the OS). Winmodems threw a monkey wrench into that by moving higher-level logic (Lucent) or literally everything (HSP) into the driver. Since the Winmodem's AT commandhost was virtual, they were literally paperweights under Linux. \$\endgroup\$
    – Bitbang3r
    Commented Mar 24, 2015 at 14:47
  • 1
    \$\begingroup\$ Yep, I used to manually type them too due to having a pulse dialing phone line (but all comm apps assuming everyone had touch-tone). :-) \$\endgroup\$
    – Brian Knoblauch
    Commented Mar 24, 2015 at 15:08
  • \$\begingroup\$ @slebetman: I like it when devices have options to support either binary or text-based protocols, but "AT" commands are a separate issue. In systems without auto-baud detection, there's no particular advantage to "AT" as a command prefix, and I've seen a number of systems which prefix commands with "AT" but still require the ability to send and receive characters outside the principle ASCII set and common control codes. \$\endgroup\$
    – supercat
    Commented Mar 24, 2015 at 16:38
  • 1
    \$\begingroup\$ IIRC, Linux eventually got drivers for some winmodems. In many cases, via ALSA or OSS sound drivers, because the most stripped-down softmodems were essentially sound cards connected to phone lines. IIRC, there were small latency advantages to be had from winmodems, because you didn't have your data stuck in UART buffers. Only gamers cared. Everyone else hated wasting cycles from their single-core CPU. \$\endgroup\$
    – Peter Cordes
    Commented Mar 25, 2015 at 10:33
20
\$\begingroup\$

You're talking only about the downsides of the command set. Consider the upsides:

  1. By using the AT command set, your communication device can immediately be put on any IP network via the OS's PPP implementation. The alternative is that in addition to designing a custom protocol interface, you have to write your own network device driver for every OS you want to support before that OS can use your device to join the Internet.

  2. Any competent engineer is going to know this protocol already. Take it from one whose day job requires him to understand and implement dozens of nonstandard serial protocols: one well-engineered common protocol is better.

  3. While it is true that the AT protocol is fairly complex and takes more memory to implement than a task-specific purpose-built protocol, it is also the case that someone who chooses to implement this protocol gets to avoid spending a bunch of time reinventing a perfectly good wheel. He's got decades of design expertise to draw from. He knows it will work before he commits development time to it. Good protocol design is surprisingly difficult.

    (One of these days, I'm going to publish my magnum opus, "Your Protocol Sucks," in the hopes of preventing the perpetration of more terrible half-considered one-off protocols.)

\$\endgroup\$
9
  • 1
    \$\begingroup\$ While I agree with the sentiment; "well-engineered"? Three words: the ATS command... \$\endgroup\$
    – user
    Commented Mar 24, 2015 at 10:59
  • \$\begingroup\$ The majority of devices I've seen that use so-called "AT" commands have nothing in common among their command sets aside from the first two characters. If a WiFi module could accept "ATDT192,168,254,5W1234" as a command to open a TCP connection to port 1234 at 192.168.254.5, then software expecting a modem could use the module just fine, but I've yet to see one do anything like that. \$\endgroup\$
    – supercat
    Commented Mar 24, 2015 at 15:09
  • \$\begingroup\$ @supercat: That's because a WiFi modem is more akin to an Ethernet card, as can be seen from the relevant standards (IEEE802 series) and the use of MAC addresses. And while the question talks about "communication IC's" I don't think coomon Ethernet IC's use the AT command set. \$\endgroup\$
    – MSalters
    Commented Mar 24, 2015 at 16:24
  • \$\begingroup\$ @MSalters: In many scenarios, the primary usage for a WiFi module will be to establish one TCP connection at a time; Hayes emulation could work beautifully for that. I've seen a FOSSIL driver that would allow DOS-based terminal programs to be used as a telnet clients by having them "dial" numbers like those above, and I would think that same approach would work beautifully with WiFi modules. In any case, my point is that if a product used a string like the above to establish a TCP connection, such usage would have significant compatibility/familiarity benefits, but... \$\endgroup\$
    – supercat
    Commented Mar 24, 2015 at 16:32
  • \$\begingroup\$ ...I suspect that the majority of devices these days that use commands starting with "AT" do so simply because their creators saw many other devices starting all their commands with "AT" and followed suit without any idea why those other devices would do so. \$\endgroup\$
    – supercat
    Commented Mar 24, 2015 at 16:33
14
\$\begingroup\$

I'll expand on the other side of the question ... why not just add another signalling line to the interface?

That can only be asked by someone who didn't live through all the permutations of signalling lines on a genuine 25-pin RS232 interface. In addition to TXD, RXD and Gnd, there were several other pairs of signals already, RTS/CTS (Ready to Send, Clear To Send) DSR/DTR (Data Set Ready, Data Terminal Ready) and a hardware Hangup pin. And others. And no clear universal agreement between manufacturers exactly what did what function - why did you need two sets of hardware handshaking signals in the first place? And software XON/XOFF protocol on top of that) (And why did Diablo printers insist - uniquely as far as I know - on handshaking on pin 11?)

Some equipment required a full interface. Some were happy with TXD/RXD/Gnd. Some could be fooled into working by shorting pins 4 and 6 (thus looping back their own RTS to CTS). And some that should have been DCE were DTE or vice-versa and would only talk to anything else via a "null modem" cable with each pair of connections swapped.

Then to simplify all this, the IBM PC introduced a new 9-pin interface for RS232. Meaning all your existing collection of cables were obsolete and you had to start again...

All of which made life difficult even without considering that both ends may have been set to different baud rates...

This supported an entire industry built up around RS232 breakout boxes, cables and test/debugging tools.

Adding another signal, in this context, probably wasn't going to fly...

\$\endgroup\$
9
\$\begingroup\$

The first Hayes modem to use "AT" commands chose "A" as the first character of its command prefix because it needed to support multiple baud rates, and the "A" on the line looks like: -------_-_____-x---------- which has a 5:1 ratio between the longest and shortest 'low' times (the "x" may be high or low depending upon parity settings). No rate slower than 1200 baud can manage a "short" time of 833us or less, and no rate faster than 2400 can manage a "long" time of 4.16ms or longer, so a modem can safely assume that if it sees something that looks like a 1200-baud "A", it is (and likewise with 300 baud, etc.). The "T" has the opposite parity from the "A", so if the second character looks like a "T", the modem can look at the upper bit on that and the "A" and distinguish among 7-E-1, 7-O-1, 7-N-1, and 8-N-1.

Devices or drivers which use "AT" commands which work similarly or analogously to the Hayes modem commands (e.g. accepting ATDTW192,168,254,123W4567 as a command to connect to port 4567 of 192.168.254.123) do so for compatibility with software that expects to talk to an old-style modem or compatible device. There are many devices, however, which use commands starting with "AT" on the theory that "AT command set" seems to be a useful marketing buzzword, even though the devices aren't capable of automatic baud-rate detection and have commands unlike anything on any other device. The use of "AT" as a command prefix in such contexts adds no compatibility value and serves no useful purpose; designers do it because they've seen other designers do it, even though none of the designers in question have any idea why.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.