gnokii-users
[Top][All Lists]
Advanced

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

Re: 3110: prevent use of sm_block_many()


From: Christopher Kemp
Subject: Re: 3110: prevent use of sm_block_many()
Date: Thu, 27 Feb 2003 09:17:03 +0000 (GMT)

On Thu, 27 Feb 2003, Osma Suominen wrote:

> Hi folks,
>
> there's been a relatively long silence on the statemachine issues on the
> list. But I found yet another solution for the 3110 that would fix the
> problem of multiple message types which was previously "solved" with an
> ugly block_many() / sm_block_many() function.
>
> Since the 3110 has its own version of FBUS code (fbus-3110.c), the way
> in which message types are reported from the link to the statemachine
> can be adjusted. (This is along the lines of what Bozo suggested a while
> ago, only a bit less crude.)
>
> So what the link code now does is that it folds the related message
> types (e.g. SMS sent OK (0x28) and SMS sent error (0x29)) into one and
> only reports the type for the succesful action (here 0x28) to the
> statemachine. The driver can thus wait for only this one type of message
> with the normal sm_block(), and the incoming functions check which one
> of the two actually happened by looking at message[0]. In my opinion
> this is not as ugly as it may first seem because the other phone drivers
> actually do quite the same thing, only their protocol is different and
> only has one message type for each type of reply so no folding has to be
> done.

Yes, good point, that sounds fine to me - the message numbers used for the
statemachine were not specifically supposed to be the message ids (eg AT
mode).  Slight quibble though, don't you want to fold all except the last
sms message into a dummy number and only return 0x28 when the last packet
is successfully received by the incoming function?  So sm_block (with a
large timeout to cover getting all the packets) waits until all the
packets have been processed.

Chris





reply via email to

[Prev in Thread] Current Thread [Next in Thread]