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.