Re: [MM] [PATCH v3] serial: Add support to optionally send line-feed at the end of AT commands.

On Fri, 2013-03-01 at 02:21 +0000, Ori Inbar wrote:
-----Original Message-----
From: networkmanager-list [mailto:networkmanager-list-
bounces gnome org] On Behalf Of Dan Williams
Sent: Thursday, February 28, 2013 11:09 AM
To: Aleksander Morgado
Cc: networkmanager-list gnome org
Subject: Re: [MM] [PATCH v3] serial: Add support to optionally send line-feed
at the end of AT commands.

On Thu, 2013-02-28 at 17:59 +0100, Dan Williams wrote:
On Thu, 2013-02-28 at 16:34 +0100, Aleksander Morgado wrote:
On 02/28/2013 03:20 PM, Dan Williams wrote:
Also, are you going to suggest a new plugin for MM using this
property set to TRUE? If so, it may be a good idea to send all
relevant commits, including this one, in the same patch series, along
with the plugin.
Now that I think about it, is there any reason we're not doing
this for
*all* devices?  Do you think any devices would care?  I'm not near
my pile-of-modems at this time, but at least the E362 and my
Longcheer-based Zoom 4597 don't care whether there's a <LF> at the
end of every command.

Good point, it probably isn't a big deal if we add that by default.
Ori, are you able to provide a patch for that?

I did hack that up already when testing with my Zoom and the E362, so
here we go as a first-pass.  Ori, can you test this and make sure it
works on your device?

Bad news; the Zoom 4597 (Longcheer) apparently crashes when you send
+CPNNUM<CR><LF>", but seems to be fine with "AT+CPNNUM<CR>" :(  All
other commands are fine up until that point (eg ATI, AT+CPIN?, +CRSM,
etc) but it's somewhat telling that the first custom command crashes it :)
Perhaps Longcheer forgot to teach the custom AT parser they added to the
firmware about <LF>?

I'd like to test a few more devices and write a quick tool to make sure the
extra <LF> is the problem, but in the mean time, if anyone else can test the
patch and see if it causes problems that would be great.


Hi Dan
I think it will best to add that property where each plugin can choose if it needs the <LF> or not.
This way we won't break existing working plugins. It is safer this way.
Yes this is needed for a new Altair LTE plugin I will add soon.

I agree, should be plugin specific.  The patch I posted is still the
correct way to make this happen, but obviously misses the code to
enable/disable based on MMAtSerialPort properties set by the plugin.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]