> I really wonder why modem manufacturers feel the need to encapsulate everything so much.
The alternative would be using an RTOS of some sort, implementing a full network stack (with > 100Mb throughput) and a USB device, as the bare minimum. Then you also have I2S audio, GNSS, etc.
It probably makes more sense using an entire OS at some point.
BTW, this is typical Qualcomm, that makes the chipsets for these modems.
I've been playing with the ESP32's a lot more recently (which go the RTOS route), and in reading the code for network stacks for these devices, it did occur to me how simple they were in terms of features. I wouldn't say that one needs the entirety of the Linux kernel to be able to implement all of those things, but it does build off of a more well used stack and reuses a lot of well-tested components.
So from this perspective, it's honestly more secure probably, too, as opposed to trusting a hardware company to hire embedded software engineers to reinvent an entire stack from scratch. The latter of which are in rare supply and we all know that reinventing things is a process that often leads to vulnerabilities.
Locking down the communication to just AT commands then makes sense for similar reasons.
LTE et al is wayyyyy more complicated than WiFI/BlueTooth for what it's worth. I can get the idea that process boundaries help the large heterogeneous teams needed to ship a full featured LTE modem, similar to how microservices help large heterogenous teams ship code at FAANGs. It's infrastructure for dealing with human inadequacies rather than a technical requirement.
Why not offload all that to the driver running on the main application processor? The risk of having a second, black-box running Linux is that it’ll get outdated and/or compromised and used as a persistence mechanism for malware.
Because you can also use the modem coupled with a low-end MCU, communicating through a serial port. This configuration is more common than one might think (I was personally involved in many of projects with that configuration).
Most of these can probably receive updates from the host OS if it's really needed, but I think what it boils down to is that the manufacturers just don't care, unfortunately.
The alternative would be using an RTOS of some sort, implementing a full network stack (with > 100Mb throughput) and a USB device, as the bare minimum. Then you also have I2S audio, GNSS, etc.
It probably makes more sense using an entire OS at some point.
BTW, this is typical Qualcomm, that makes the chipsets for these modems.