Seeing AT commandes described as the "way that humans and machines can interact with a cellular modem" made me feel old because they didn't just say "remember AT commands from manually driving your Hayes 9600baud dial up modem?"
I remember when the Hayes command set started to become the standard, because for a while you could get on a group chat on a BBS and press +++ATH to make the outbound modems hang everyone up. I think there was an AT command to remap that pattern, but it wasn't adopted by all the BBS software right away.
Edit: To clarify, before then you would have something like a 300 baud modem that didn't have an out-of-band command set, so you would dial the number on your phone and flick a switch on the modem to make it connect and everything would be sent to the other side verbatim. The "+++" is the escape sequence you send to a Hayes modem to break it into command mode, the "AT" is the prefix for the command (attention?), and "H" means "hang up". IIRC, puritans would say "ATH0" because the "0" represents some particular state to hang up to, but it's the same as "ATH".
The DC Hayes Micromodem II for the Apple ][ had its own weird command codes using control characters, with ^A at the "attention" command.
IN#3 (Apple ][ command to hook input from slot #3)
^A ^F (modem command to set full duplex)
^A ^Q (modem command to pulse dial the following number)
^A ^Z (modem command to hang up)
Later on once the Hayes AT command set took over and BBSs became popular in the 80's, there was a flat $25/month subscription service called "PC Pursuit" that had banks of modems in different cities connected by a network, which you could dial up locally, then connect over the network to another modem, and dial out to a local BBS system. It was a subsidiary of Telenet, which spun off from BBN, and later was a subsidiary of U.S. Sprint.
There was a fun game you could play called "PC Roulette", in which you first connected to a remote modem with the PCP command, then issued the command "A/" directly to the modem, to redial the last number somebody else dialed on that modem!
9600? Try 1200 baud! Of course, this guarantees that someone will chime in talking about starting off with a 300 baud modem that worked like they showed in WarGames.
Back in the 70s, I dialed a number on my parent’s rotary phone. When the remote computer answered, I would shove the handset into the earmuffs on the acoustic coupler[1].
It usually worked. I don’t remember if the baud rate was 300 or 110.
you configure modems still the same way. you still have modems in IoT devices. what changed are the capabilities, esp. the power states. these trackers can sleep most of the time, only wake up periodically, so they can survive on battery for several years.
most sensors are connected via I2C to the CPU. some weird ones via SPI.
most GPS sensors are different, they connect mostly via UART. so you can connect to them directly, bypassing the CPU.
MT3333? Yea that's an improvement over the UART interface where it just sends out the data no matter if the other side is listening or sleeping. With the SPI interface you get an interrupt and can read the data at your own pace.
But I2C would do too if they would offer a proper register interface as opposed to always expecting you to parse those verbose NMEA messages.
Oh and only generating an interrupt if the fix is valid would be nice! But they just shoehorned the SPI interface onto it, exposing exactly the same data as they would over UART.
So if you have to wake up, parse the message and only then will you find out if you have a valid fix or can go back to sleep and try again.
Afaik they dropped the SPI mode in the newer chips though.
Serial ports are still ubiquitous in embedded electronics. Crack open any non-trivial device and you will probably find a serial port, sometimes along with JTAG or SWD, on an unpopulated connector or on test pads, spitting out debug logs.
And it makes sense from an engineering standpoint. Equipment for interfacing to a serial port, even in 2022, is widely available (you can get a basic TTL-level dongle for the price of a coffee) and pretty much every microcontroller/SoC has at least one hardware UART. If you want to see what your code prints to stdout while it's running on real hardware you could either implement a fancy redirection layer that sends logs over whatever interface your device has (and hope there are no bugs in it) or just use the built-in UART, wire it up to an off-the-shelf dongle and call it a day.
UARTs are super important still, nothing old or obsolete about that tech. It's simply still useful, and a sensible way of doing serial communication in a simple way.
The Pirate is awesome, and was rather magical when it first appeared (I bought mine in 2010), but nowadays I would just use a USB/UART adapter [1]. They're cheap as ... something cheap on Amazon, and simpler since they're special-purpose.
Wide spread. Its very easy to work with. UART aka Serial TTL or just RX/TX is native to almost all chips.
There is no standard protocol though, so unless its a modem (AT commands) or you have a manual you will likely have a hard time communicating with it.
If you want to see what is going over the wire get a logic analyzer. Typically ~$30. Connects to USB and comes with software to decode the messages. Its read only so to speak.
