[PATCH] gatchat: export gatchat at_chat_finish_command

[PATCH] gatchat: export gatchat at_chat_finish_command

[Giacinto Cifelli]

[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

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.
---
 gatchat/gatchat.c | 4 ++++
 gatchat/gatchat.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/gatchat/gatchat.c b/gatchat/gatchat.c
index 3f290ac2..edb55efe 100644
--- a/gatchat/gatchat.c
+++ b/gatchat/gatchat.c
@@ -465,6 +465,10 @@ static void at_chat_finish_command(struct at_chat *p, gboolean ok, char *final)
 	at_command_destroy(cmd);
 }
 
+void g_at_chat_finish_command(GAtChat *chat) {
+	at_chat_finish_command(chat->parent, FALSE, NULL);
+}
+
 static struct terminator_info terminator_table[] = {
 	{ "OK", -1, TRUE },
 	{ "ERROR", -1, FALSE },
diff --git a/gatchat/gatchat.h b/gatchat/gatchat.h
index 7290b34f..36fa87f0 100644
--- a/gatchat/gatchat.h
+++ b/gatchat/gatchat.h
@@ -167,6 +167,8 @@ void g_at_chat_add_terminator(GAtChat *chat, char *terminator,
 void g_at_chat_blacklist_terminator(GAtChat *chat,
 						GAtChatTerminator terminator);
 
+void g_at_chat_finish_command(GAtChat *chat);
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.17.1

Re: [PATCH] gatchat: export gatchat at_chat_finish_command

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

Hi Giacinto,

On 10/20/2018 05:26 AM, Giacinto Cifelli wrote:
> 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

Re: [PATCH] gatchat: export gatchat at_chat_finish_command

[Giacinto Cifelli]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

Hi Denis,

On Sat, Oct 20, 2018 at 6:04 PM Denis Kenzior <denkenz@gmail.com> wrote:
>
> Hi Giacinto,
>
> On 10/20/2018 05:26 AM, Giacinto Cifelli wrote:
> > 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...

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).

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.

>
> Regards,
> -Denis

Regards,
Giacinto

Re: [PATCH] gatchat: export gatchat at_chat_finish_command

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

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

Re: [PATCH] gatchat: export gatchat at_chat_finish_command

[Giacinto Cifelli]

[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]

Hi Denis,

On Sat, Oct 20, 2018 at 6:23 PM Denis Kenzior <denkenz@gmail.com> wrote:
>
> 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 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.

>
> >
> > 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?

>
> Regards,
> -Denis

Regards,
Giacinto

Re: [PATCH] gatchat: export gatchat at_chat_finish_command

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

Hi Giacinto,

On 10/20/2018 11:28 AM, Giacinto Cifelli wrote:
> Hi Denis,
> 
> On Sat, Oct 20, 2018 at 6:23 PM Denis Kenzior <denkenz@gmail.com> wrote:
>>
>> 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.

> 
>>
>> 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.

> 
>>
>>>
>>> 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

Re: [PATCH] gatchat: export gatchat at_chat_finish_command

[Giacinto Cifelli]

[-- Attachment #1: Type: text/plain, Size: 2506 bytes --]

Hi Denis,

On Sat, Oct 20, 2018 at 6:40 PM Denis Kenzior <denkenz@gmail.com> wrote:
>
> Hi Giacinto,
>
> On 10/20/2018 11:28 AM, Giacinto Cifelli wrote:
> > Hi Denis,
> >
> > On Sat, Oct 20, 2018 at 6:23 PM Denis Kenzior <denkenz@gmail.com> wrote:
> >>
> >> 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.
>
> >
> >>
> >> 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.

Gemalto supports for a limited subset of commands, it is right, and it
is not standardized.

But it is not a reason to close the door entirely:
there are strict requirements for starting emergency calls, especially
ERA/GLONASS and panEuropean eCall.

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.

I will come back to this in a few months when I need to focus just on
eCall. But it is good that we started talking about it.

>
> 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.

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

>
> Regards,
> -Denis

Regards,
Giacinto

Re: [PATCH] gatchat: export gatchat at_chat_finish_command

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

Hi Giacinto,

> But it is not a reason to close the door entirely:
> 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

Re: [PATCH] gatchat: export gatchat at_chat_finish_command

[Giacinto Cifelli]

[-- Attachment #1: Type: text/plain, Size: 2752 bytes --]

Hi Denis,

On Sat, Oct 20, 2018 at 7:20 PM Denis Kenzior <denkenz@gmail.com> wrote:
>
> Hi Giacinto,
>
> > But it is not a reason to close the door entirely:
> > 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.
>

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.

> >
> > 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 cancellation, 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.

g_at_chat_set_wakeup_command is blocking (I think), and it would be
perfect because of that, only would need to add a timeout/number of
attempts, and a return value (success/timed out).
But it seems complicated to do this because it is integrated in the
big state machine of GAtChat.
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.

>
> Regards,
> -Denis

Regards,
Giacinto

Re: [PATCH] gatchat: export gatchat at_chat_finish_command

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]

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.

>> 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

Re: [PATCH] gatchat: export gatchat at_chat_finish_command

[Giacinto Cifelli]

[-- Attachment #1: Type: text/plain, Size: 2849 bytes --]

Hi Denis,

On Sat, Oct 20, 2018 at 9:22 PM Denis Kenzior <denkenz@gmail.com> wrote:
>
> 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.

ok, when I will come to cancel commands I will do it.

>
> >> 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?

yes, my mistake, not blocking.

>
> > 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.

after all, with GIOChannel I have made a nice little solution, also quite clean.
I expected more trouble.

> >
> > 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.

Yes, I have seen that later. This makes the feature quite suitable for
the serial modem, that in sleep mode listen to the serial port only
every N seconds.

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

Could you have a look at the [v8 x/x] lte series? It should be ok now.

Thank you,
Regards,
Giacinto