Re: 3110 statemachine handling (patch)

[Ladislav Michl]

On Tue, Feb 18, 2003 at 01:55:58PM +0200, Osma Suominen wrote:
> On Tue, 18 Feb 2003, Pawel Kot wrote:
> 
> > Thanks for your work and the detailed description. I need to think a bit
> > longer about the issue. I need to make some decision what to do with
> > statemachine and I want to make a wise decision :-)
> >
> > I hope you won't mind waiting till tomorrow.
> 
> That's no problem. I just hope that we find a solution because not
> having one that works keeps me from improving the 3110 code.
> 
> According to my current understanding there are a few distinct
> situations where the statemachine should be used to receive packets,
> plus some variations on them such as different timeouts or retry policy.

is it possible to sent several messages and got reply in random order
with nokia phones?

> In each situation the following questions are relevant:
> 
> 1.    have you just sent something or not?
> 1.1.  if yes, do you want to resend what you just sent in case no
>       reply comes in before timeout?
> 2.    how long is the timeout value?
> 3.    what are the answer(s) you expect?
>       - a single message type
>       - a sequence of message types (i.e. all of them)
>       - one of several possible message types
> So the basic sm_block() family assumes you have just sent a message, and
> you can specify the timeout and retry policy. It also assumes that you
> receive a message of a certain type (only one). These are assumptions
> that work well with most phones, but not always with the 3110.
> 
> The ones I have added differ in the following ways:
> 
> expect_message() does not assume that you have sent a message (thus
> the question of retrying is not relevant). The timeout is fixed but
> could be made into a parameter if necessary. A single message type is
> expected.
> 
> block_many() and block_many_timeout() assume that you have sent a
> message, assumes that you want to retry, allow you to set the timeout or
> use the default, and assume that you expect one (and only one) of
> several possible message types to appear, so they take an array of
> message types as a parameter.
> 
> As you can see there would be other possible combinations, but those are
> AFAIK not relevant for any of the phone drivers so there is not much
> point in writing them. I have implemented the ones that are needed for
> the 3110 phone driver.

just for the sake of completeness communication protocol of Dancall phones
is in cvs now [1], so i'll provide some additional informations here
(IMHO) usefull for statemachine design:

1) before any frame is sent to phone, driver has to check if there are
   no unconfirmed frames. better way of course is always finish
   transaction (see point 2).
2) once frame from phone is received, link has to sent 0xa5 - sooner is
   better; you need setserial low_latency to be fast enough. however
   even Celeron based PEECEE is not sometimes fast enough and it's
   possible that phone starts retransmit last frame. no new frame should
   be sent by driver at this point until previous is confirmed with 0xa5
   and phone stops retransmit. otherwise bad bad things happens. at this
   point you need link_rx_statemachine to be running, but it is _not_
   waiting for any particular frame. it only tries to transmit 0xa5 to
   phone as soon as it receives incoming packet. ie. i have to wait
   until communication complete, not until frame is received. this could
   be hacked into cbus_link_loop, but all depends on how sm_block and 
   family will look like...

currently i'm using terribly hacked gnokii to communicate with dancall
and i can say that communication is quite stable and is even possible to
disconnect serial cable for a while without data lose :) code in cvs is
not what i'm describing here, because it was not possible to commit it
without changing statemachine. i can upload it somewhere if anyone is
interested.

> Note that the block_many() code already existed in the 3110 driver, but
> not as a separate function, only as a part of several different
> functions. I cleaned up that code and put it into a new function that
> the different operations in the 3110 code can use.
> 
> The expect_message() is roughly similar to some of the variations of the
> sm_block() functions that have appeared in different gnokii versions.
> However, the current sm_block()  cannot be used for the purpose because
> it is impossible to specify that no retries should ever be made (the
> code does a retry if the phone does not even acknowledge the recently
> sent message). It might be possible to modify the sm_block() family so
> that it could again be used for this purpose, but I doubt it would be
> very useful. "if it works, don't fix it"
>
> Sometimes I get the feeling that I write too many explanations and too
> little code ;)

this is _very_ nice and useful summary. keep that way.

[1] please read it first :)

        ladis