I love that the skills I learned in the 80s are still relevant today. Interacting with serial ports. AT commands. This stuff hasn't changed much.
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".
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)
https://en.wikipedia.org/wiki/Hayes_Microcomputer_Products#E...
https://www.computerhistory.org/collections/catalog/10264598...
https://www.ebay.com/itm/393165436881
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.
http://www.bbsdocumentary.com/library/CONCEPTS/SERVICES/PCPU...
https://bbs.fandom.com/wiki/PC_Pursuit
https://blog.tmcnet.com/blog/tom-keating/voip/pc-pursuit---t...
https://en.wikipedia.org/wiki/Telenet#PC_Pursuit
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!
It usually worked. I don’t remember if the baud rate was 300 or 110.
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.
ftfy
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.
Being able to communicate with arbitrary electronics using the $30 Bus Pirate device seems like a very fair price.
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.
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.
[1]: https://www.amazon.com/s?k=usb+uart&crid=1JQRTOTBVDDCW&spref...