[PATCH] gatchat: export gatchat at_chat_finish_command

[Denis Kenzior]

Hi Giacinto,

added the function g_at_chat_finish_command, in order to be able to
interrupt a pending command.
The function is useful in special cases, for example to implement
a custom g_at_chat_set_wakeup_command. This command will never
return if the device does not answer, and therefore it is unsuitable
to probe configurations.

I don't think this is a good idea. In general the caller has no clue
what command he is actually finishing since there may be other commands
being queued.

You might want to provide more context as to what you're actually trying
to accomplish. It might be easier to just use g_at_chat_cancel and a
g_timeout_add_seconds combination for this...

Regards,
-Denis

[Denis Kenzior]

Hi Giacinto,

I need to probe with 'AT' once per second the modem and the
application port, one after the other.
It needs to be repeated a few times, because the device might be
booting up, but it could also be that the device is not responding
(because, for example, mapped on the RS232).

Ugh. Doesn't your firmware provide some sort of ready notification?

But anyway, you can still accomplish this with
g_at_chat_send/g_timeout_add/g_at_chat_cancel...

Another use could be to abort a long-running command (eg: SMS sending,
which can take up to 3 minutes), to allow the application to do
something else, eg: emergency call.

This is why they invented the multiplexer. Also note that we don't
implement actual AT command abortions. So it depends on the behavior of
your AT command interpreter whether this works as you think.

I'm not taking this patch as things stand right now.

Regards,
-Denis

[Denis Kenzior]

Hi Giacinto,

Hi Denis,

Post by Denis Kenzior
Hi Giacinto,

I need to probe with 'AT' once per second the modem and the
application port, one after the other.
It needs to be repeated a few times, because the device might be
booting up, but it could also be that the device is not responding
(because, for example, mapped on the RS232).

Ugh. Doesn't your firmware provide some sort of ready notification?

yes, but what if the modem has already booted up?

But then your query AT command will succeed no?

See how plugins/mbm.c does this with EMRDY for example. If your modem
is completely unresponsive for a certain amount of time then you might
need to send AT\r or something directly via GAtIO/GIOChannel bypassing
GAtChat.

Post by Denis Kenzior
But anyway, you can still accomplish this with
g_at_chat_send/g_timeout_add/g_at_chat_cancel...

I have tried but it doesn't abort the current 'AT' waiting for an answer.

As I said, we don't support AT command aborts. You can't simply start
writing the next AT command to the serial port. There are special rules
for this with weird timings. See V.250 for details. Also many AT
command interpreter implementations simply don't support this at all or
support aborts for a limited subset of commands.

You're doing something extremely specific, so you can either try and
abuse the g_at_chat_set_wakeup_command (which was added specifically for
one extremely insane modem) or do this manually via GAtIO / GIOChannel.

Post by Denis Kenzior

Another use could be to abort a long-running command (eg: SMS sending,
which can take up to 3 minutes), to allow the application to do
something else, eg: emergency call.

This is why they invented the multiplexer. Also note that we don't
implement actual AT command abortions. So it depends on the behavior of
your AT command interpreter whether this works as you think.
I'm not taking this patch as things stand right now.

I don't have a way out without this. Any suggestions?

Implement proper AT command abort logic per V.250? Or work around some
other way.

Regards,
-Denis

[Denis Kenzior]

Hi Giacinto,

there are strict requirements for starting emergency calls, especially
ERA/GLONASS and panEuropean eCall.

I'm not though. I'm just saying that exposing at_finish_command is not
actually doing what you want in this particular case anyway. If you
don't have enough AT ports that you need to cancel ongoing SMS, etc,
then you need to implement proper AT command abortion.

Perhaps it should be given in the driver to each manufacturer the
possibility to do it, but some support from the core would be good.

The core has no concept of cancelation, it is assumed that any proper
modem would provide 5-6 independent interpreters or supports a fully
async protocol. Then any interpreters that can block for a long time
are independent of the others. E.g. ATD, AT+COPS, and a few other
commands can block the port for a fairly long amount of time, depending
on the firmware implementation.

I'm open to the idea of adding core support for cancelation of these
commands. ATD is a particularly common case, but so is available
operator scanning via COPS, etc. But this enters into extremely
complicated and vendor dependent behavior territory.

via GAtIO / GIOChannel I can do it, even if suspect quite some effort
for something that is already available.

I've already had this conversation with someone from Gemalto or one of
your customers. I don't see a reason why you can't use
g_at_chat_set_wakeup_command for this. With perhaps an extension to
GAtChat API to reset/cancel the wakeup behavior once you don't need it.

Regards,
-Denis

[Denis Kenzior]

Hi Giacinto,

some chipsets have a single interpreter, even if accessible from
multiple ports, but they allow aborting.
Gemalto modules abort long-running commands simply sending any
character on the line while waiting for a response,
the module returns ERROR, and the flow can be resumed properly.
I don't need this patch for that, I can just use directly GAtIO / GIOChannel.

So if you're going through the trouble of implementing command abortion,
then just implement it in GAtChat directly.

Post by Denis Kenzior
I've already had this conversation with someone from Gemalto or one of
your customers. I don't see a reason why you can't use
g_at_chat_set_wakeup_command for this. With perhaps an extension to
GAtChat API to reset/cancel the wakeup behavior once you don't need it.

g_at_chat_set_wakeup_command is blocking (I think), and it would be

Nothing in GAtChat is blocking. Or well, what is your definition of
blocking here?

perfect because of that, only would need to add a timeout/number of
attempts, and a return value (success/timed out).

That would work..

But it seems complicated to do this because it is integrated in the
big state machine of GAtChat.

But all the work is already done for you, so might as well just use this
legacy feature if it gets you there...

I prefer to go for GAtIO / GIOChannel instead.
By the way, g_at_chat_set_wakeup_command takes 2 timeouts (the first
one for the period of the wakeup AT command), but the second never
seems to expire, so I don't know if it is already fit.

It expires, you might not be triggering it though. The inactivity timer
is used to keep track of how long ago a command was sent to the AT port.
So it is updated with every command sent. The particular device that
this was needed for would shutdown the AT port after a period of
inactivity, e.g. 5 seconds or so. So if no AT commands were sent for 5
seconds, it needed to be woken up. It usually ate the first 2-3 'AT\r'
commands sent to it.

The wakeup_timeout parameter specifies how long to wait for the 'AT\r'
response before giving up and attempting again.

Regards,
-Denis