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

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

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(a)gmail.com&gt; 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.

Regards, -Denis

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

Regards, -Denis

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