Re: Quirk with on_sms callback

[Jeremy Lainé]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi again!

> +static gn_error AT_GetManufacturer(gn_data *data, struct
> gn_statemachine *state)
> +{
> +    strncpy(data->manufacturer, "Motorola", GN_MANUFACTURER_MAX_LENGTH);
> +    return GN_ERR_NONE;
> +}
> +
> +static gn_error AT_GetModel(gn_data *data, struct gn_statemachine *state)
> +{
> +    strncpy(data->model, "EZX", GN_MODEL_MAX_LENGTH);
> +    return GN_ERR_NONE;
> +}
> 
> The existing way doesn't work?

No, unfortunately not, the baseband processor ("modem") on the EZX
handsets replies neither "OK" nor "ERROR" for the commands it does not
support, it just gives an extended error code. This is why I crippled
the commands querying manufacturer/model, and also why you need to
explicitly set "AT-EZX" as the model, since it is not possible to
determine the driver flavour in the usual fashion.


> +typedef struct {
> +    int length;
> +    char buffer[512];
> +} atezx_mt_sms;
> 
> Why is that?

I use this structure for storing data about incoming SMS notifications.
The problem here is that you get an unsolicited message of the form:

AT+CMT: <some length>

<hex SMS data>

Unfortunately, other unsolicited messages seem to sometimes come between
the two parts (to be confirmed), so I needed to store data somewhere in
the meantime. Come to think of it, I currently don't do anything with
the message length so this could probably be scrapped.

This brings up another topic I would quite like discussing with you
which is the handling of unsolicited messages. There are a number of
messages which I would like to support, but as they are totally specific
to EZX platforms I want to isolate them in the atezx driver. The problem
is that at the moment this is not possible, unsolicited messages are
handled by atbus.c. Is there any way we could delegate this to the
actual phone drivers to allow customisation?

> +    void *extra_data;
> 
> And this one I would really like to avoid.

The atgen driver does not provide any way for derived drivers to store
their additional state data, which is why I added this. There are
basically two approaches here:

a/ we explicitly declare every possible bit of additional information
for all drivers derived from atgen as part of the atgen driver instance
data, and whenever a driver needs a new field we have to go back and
change atgen

b/ we provide an opaque data structure which allows drivers to manage
their own data. This is what I chose.

How would you prefer to see this handled?

Thanks for you comments!

Jeremy

- --
http://www.jerryweb.org/             : JerryWeb.org
http://sailcut.sourceforge.net/      : Sailcut CAD
http://opensource.polytechnique.org/ : Polytechnique.org Free Software
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFpWbL4mJJZqJp2ScRAvR5AKCPk03o41dnWJuwM0N0s4RChak0VwCgpMny
xy5vFFpYeZrg+N2Jtp0ZWT0=
=4mYr
-----END PGP SIGNATURE-----