Subject:
|
Re: frame RCX reply how
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Sat, 1 Feb 2003 17:02:35 GMT
|
Viewed:
|
4152 times
|
| |
|
|
> From: "Brian B. Alano" <throwaway@insightbb.com>
> Date: Sat, 1 Feb 2003 01:06:27 GMT ...
>
> 3. ... (perhaps the best) place to look would be
> http://hometown.aol.com/johnbinder/bricxcc.htm
> ... Bon chance!
Bingo! I reached the bricktools/ of the frame-free:
http://members.aol.com/_ht_a/johnbinder/bricxcc.htm
http://members.aol.com/_ht_a/johnbinder/bricxcc_src.zip
427,998 bytes
At a glance, I missed how bricxcc toggles x08 in the command op to let command
ops be repeated, but I'd now guess the bricxcc algorithm for framing standard
RCX replies is:
1) Discard all bytes received.
2) Send the bytes of the command packet.
3) Loop to receive bytes, one at a time. Fail if any one byte takes too long,
else after receiving a few thousand. Succeed as soon as the receive buffer
ends with a well-formed reply of the expected length.
A byte took "too long" to read if it takes longer than 50 to 400ms. Any given
read has a specific timeout, calculated by code that didn't immediately make
sense to me.
A reply packet is "well-formed" if it is x 55 FF 00 aa ~aa bb ~bb ... zz ~zz,
provided also that aa is the expected reply op and zz is the sum of all the
complemented bytes.
The expected reply op is the command op complemented, I think including bit 3.
The expected reply payload length in bytes is 0 except:
1 for ops x 25 35 45 75
2 for ops x 12 30
8 for op x15
25 for op xA5
188 for op x20
variable for ops x 63 A4
The variable expected reply payload of op xA4 Upload [aka UploadDatalog] is the
DatalogSize from command byte offsets 4:3. The variable expected reply payload
of op x63 Upload Ram is the ByteCount from command byte offset 3. (Seemingly
~kekoa/rcx/opcodes.html does not document LASM op x63??)
> > http://members.aol.com/_ht_a/johnbinder/bricxcc_src.zip
> > 427,998 bytes
To reach these conclusions, I visited bricktools/ and began in FakeSpirit.pas
and `grep`ped much.
Immediately I recognised a xD2 RemoteCommand enumeration:
kRemoteKeysReleased = $0000;
...
kRemotePlayASound = $0080;
Glancing further at random, "Ping" caught my eye. I see function
TFakeSpirit.Ping tests fLink.Send(cmd.MakePing) >= kRCX_OK. grep MakePing
leads to rcx_cmd.pas which mentions kRCX_PingOp, which grep finds = $10 in
rcx_constants.pas, again recognisable hex.
grep Send gets a gazillion hits, being overloaded way way way beyond My ability
to decipher Delphi .pas. But in *.pas we see: private fLink : TAutoLink. And
in *.pas we see: TAutoLink = class(TRcxLink). And in rcx_link.pas we see: unit
rcx_link.
So I chose to pursue:
fResult := TransportSend(data, length, @fReply[0], expected, kMaxReplyLength,
retry);
I clicked thru TransportSend to SendFromTxBuffer and concluded, as in the
summary above:
1) Discard all bytes received.
2) Send the bytes of the command packet.
I clicked thru TransportSend to TransportReceiveReply and concluded, as in the
summary above:
3) Loop to receive bytes, one at a time. Fail if ... Succeed as soon as ....
In particular, TransportReceiveReply repeatedly calls NQCSerial.Read(tmpRxD, 1,
timeout) and then tries TransportFindReply, which divides into FindSync and
TransportVerifyReply.
FindSync scans for fSync i.e. const ... rcxSync : array[1..4] of Byte = (3,
$55, $ff, $00) i.e. a standard header preceded by its own length. I'm thinking
the = *psync of .c is := psync^ in .pas, and += is Inc(, and return is Result
:= ... Exit, etc.
TransportVerifyReply defines "a well-formed reply of the expected length".
Back up in function TRcxLink.Send, before calling TransportSend, we calculate
ExpectedReplyLength i.e. PredictReplyLength plus the 1 byte length of a
checksum. In PredictReplyLength I read the "expected reply payload length"
rules.
Meanwhile, maybe TransportAdjustTimeout means fRxTimeout ranges between
kMinTimeout = 50 and kMaxTimeout = 400, over time, adapting complexly to what
works.
My ignorance of .pas and of bricxcc leaves me vague on some detailed issues,
like maybe this code commonly wastes time testing the command echo to see if it
is the expected reply, since that echo likewise begins with x 55 FF 00, but I
gathered the impressions summarised above.
Thanks again everyone, Pat LaVarre
|
|
Message is in Reply To:
 | | Re: frame RCX reply how
|
| I wish I could give you a direct answer, but I don't know. However, I suspect (as I'm sure you do) that what you are looking for has already been done. Below are three possible sources which you can adopt, co-opt, or reverse-engineer to get where (...) (21 years ago, 1-Feb-03, to lugnet.robotics.rcx)
|
16 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
