gatchat: export gatchat at_chat_finish_command
PATCH 1/1 gatchat: export gatchat at_chat_finish_command
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(+)
gatchat/gatchat.c +4 -0
@@ -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 },
gatchat/gatchat.h +2 -0
@@ -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
Signature · 1 line
2.17.1
Hi Giacinto,
Quoted 6 lines · Giacinto Cifelli
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 customg_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
Hi Denis,
Quoted 11 lines · Denis Kenzior
Hi Giacinto,
Quoted 6 lines · Giacinto Cifelli
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 customg_at_chat_set_wakeup_command. This command will never return if the device does not answer, and therefore it is unsuitable to probe configurations.
Quoted 7 lines
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_canceland ag_timeout_add_secondscombination 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.
Quoted 3 lines
Regards,
-Denis
Regards,
Giacinto
Hi Giacinto,
Quoted 5 lines
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...
Quoted 4 lines
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
Hi Denis,
Quoted 10 lines · Denis Kenzior
Hi Giacinto,
Quoted 5 lines
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?
Quoted 3 lines
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.
Quoted 11 lines
Quoted 5 lines
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?
Quoted 3 lines
Regards,
-Denis
Regards,
Giacinto
Hi Giacinto,
Quoted 12 lines · Giacinto Cifelli
Hi Denis,
Quoted 9 lines · Denis Kenzior
Hi Giacinto,
Quoted 5 lines
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).
Quoted 3 lines
Quoted 1 line
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.
Quoted 6 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
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.
Quoted 8 lines
Quoted 5 lines
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
Hi Denis,
Quoted 32 lines · Denis Kenzior
Hi Giacinto,
Quoted 12 lines · Giacinto Cifelli
Hi Denis,
Quoted 9 lines · Denis Kenzior
Hi Giacinto,
Quoted 5 lines
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).Quoted 3 lines
Quoted 1 line
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.cdoes 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.Quoted 5 lines
Quoted 4 lines
But anyway, you can still accomplish this with
g_at_chat_send/g_timeout_add/g_at_chat_cancel...
Quoted 7 lines
Quoted 1 line
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.
Quoted 4 lines
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.
Quoted 3 lines
Regards,
-Denis
Regards,
Giacinto
Hi Giacinto,
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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
Hi Denis,
Quoted 12 lines · Denis Kenzior
Hi Giacinto,
Quoted 3 lines
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_commandis 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.
Quoted 16 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 3 lines
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_commandfor 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.
Quoted 3 lines
Regards,
-Denis
Regards,
Giacinto
Hi Giacinto,
Quoted 6 lines
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.
Quoted 6 lines
Quoted 4 lines
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_commandfor 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_commandis blocking (I think), and it would be
Nothing in GAtChat is blocking. Or well, what is your definition of blocking here?
Quoted 2 lines
perfect because of that, only would need to add a timeout/number of attempts, and a return value (success/timed out).
That would work..
Quoted 2 lines
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...
Quoted 5 lines
I prefer to go for GAtIO / GIOChannel instead.
By the way,
g_at_chat_set_wakeup_commandtakes 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
Hi Denis,
Quoted 10 lines · Denis Kenzior
Hi Giacinto,
Quoted 6 lines
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.
Quoted 2 lines
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.
Quoted 10 lines
Quoted 7 lines
Quoted 5 lines
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_commandfor 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_commandis blocking (I think), and it would beNothing in GAtChat is blocking. Or well, what is your definition of blocking here?
yes, my mistake, not blocking.
Quoted 4 lines
Quoted 3 lines
perfect because of that, only would need to add a timeout/number of attempts, and a return value (success/timed out).
Quoted 9 lines
That would work..
Quoted 2 lines
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...
Quoted 1 line
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.
Quoted 5 lines
Quoted 4 lines
By the way,
g_at_chat_set_wakeup_commandtakes 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.
Quoted 7 lines
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.
Quoted 6 lines
The
wakeup_timeoutparameter 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