eclipse-archived
implement proper out-of-AT command handling
Currently we rely on a rather workaround in order to handle non-AT conform responses from the modem. The responses from a modem can usually be categorized into three groups:
- Purely AT - Meaning only ASCII characters and following the general AT formatting.
- Mixed AT & binary - The response may start off as clean AT but some parameter may contain binary data which is not conformal to the AT standard. This typically applies to vendor specific data-service features like on-chip UDP, TCP or HTTP stacks.
- Purely binary - Usually declared by the
CONNECTresponse. In this mode no AT commands are interpreted. Can be used to directly link the serial interface with some data-stream (like a socket, PPP-context, or even a phone call).
Category 1 is fully supported and should not cause any issues in the future. Category 2 is how we currently handle HTTP data. It is supported via the workaround, but thinking further we may run into trouble with other modem vendors/AT interfaces. Category 3 only makes sense for mux'ed interfaces. (ref: 3GPP TS 27.010). This may be neat to have in the future. It gets rid of the need for payload-escaping and should generally be lower latency/higher throughput. However, a lot of code needs to be written to support this feature (parsers, virtual channel handlers, bootstrapping code).
To properly fix cat. 2 responses we need an architectural change in the way we handle modem responses. Currently parsing the response and interpreting it are temporally disconnected. Meaning the interpretation is deferred onto a later point in time, possibly after the data already went fully through the parsing stage. This disconnect prevents us from intervening the parsing stage and telling it "hey, what follows now isn't actually AT, so don't bother...".
Proposal A: Remove the temporal disconnect. Make the parsing ad-hoc, as needed by the interpreter. Probably a bigger change, but would be the most reliable.
Proposal B: Make it possible to register a "exit-AT-condition". Such a condition could be the command string of the response. Once the exit-condition is encountered in the response-stream, we switch to an alternative parser. Once done with the out-of-AT contents we return to the default parser. Less work, but also less reliable.
@bierkandt-bosch input needed on timeline planning. I don't think this task is essential for the ICD, but must be handled eventually. Adding support for other modem vendors may be blocked by this issue.