> One snag I've come across is that I want to run this during the
> disconnection logic, but I need to issue AT commands to verify that AT
> mode has been re-entered before marking the port as disconnected.
> mm_port_serial_at_command() however will not permit a command to be
> issued on a port when its port has its "connected" member var set to true.
> Possible solutions:
> . Add a more general purpose version of mm_port_serial_at_command which
> doesn't check the connected status (and change mm_port_serial_at_command
> to just carry out the "connected" state check, and then call the general
> purpose function if "not connected").
> . Temporarily mark the port as disconnected before calling
> mm_port_serial_at_command, but somehow lock it to prevent signal quality
> checks etc. from running (or otherwise disable these checks when a
> single-port modem is connected?).
> Any other suggestions?
It depends on how you're going to do it, but if you implement a
mm_port_serial_force_disconnect() method or something similar, which
takes care of all the logic you're preparing, you could just ignore
internally the fact that the port is flagged as connected, although
that involves some logic in MMPortSerial as well...
Maybe using an enum instead of a boolean for that state flag? E.g.
MM_PORT_STATE_COMMAND /* default */
MM_PORT_STATE_DATA /* when connected and in data mode */
Then you could set the port state as UNKNOWN as soon as you want to
start doing the disconnection logic; and also only allow unrelated
commands when in CONTROL mode.
> p.s. Incidentally, AT-command mode is independent of there being an
> active connection associated with the port (i.e. from the modem's
> perspective, it's possible to have the port "connected", but also in AT
> command mode), so maybe "connected" isn't the best name, and
> "in_at_command_mode" would be better? Probably that change isn't needed
> for the disconnection robustness changes however...
Yeah, maybe "DATA" and "COMMAND" as above?
ModemManager-devel mailing list