[E3-hacking] PBL response

[Ralph Corderoy]

Hi again Matt,

> > Then I thought I'd try 'exp' and see what happens;  it moves to this
> > CS_HAVE_ACK state a bunch of times - I'm guessing because it gets
> > 006 16 times as the wakeup code print_strings a line of them.
> 
> Thanks.  You're right.  It moves to CS_HAVE_ACK on seeing an ACK
> regardless of its current state.  I also see the stdout is a bit
> corrupted when this happens.  You're executing un-trodden code paths
> there!
> 
> > Then it just sits there doing nowt.  I'll take a closer look later
> > on but just thought I'd let you know.  :)
> 
> It sends a couple of 0x0000 and 0x0002 requests in the hope that if
> it's got it wrong, and is sending too few bytes for a request, the
> following requests will provide the missing data, give a checksum
> error, and still prompt a reply as opposed to the E2 just waiting a
> long time for more data.

Actually, that's not what it does.  There's three states:  sending ESCs,
given up sending ESCs and sending some protocol in the hope of it
working, and having received an ACK.

Because it has never got into the ACK state before I was happy just to
log that an ACK had been seen and then stop.  It's only in the middle of
the three states above that protocol is attempted once it's given up
sending ESCs.

I'll have a look at altering the FSM tonight if you don't beat me to it.
I suspect it's a case of deleting the HAVE_ACK state and switching to
the `send some protocol' state when either we've given up sending them,
or we've seen an ACK.

Sorry for the confusion.


Ralph.