Subject:
|
command framing as seen from kernel/program.lrkey_handler
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Sat, 1 Feb 2003 13:48:44 GMT
|
Viewed:
|
3820 times
|
| |
|
|
> Subject: Re: frame RCX reply how
> From: "Brian B. Alano" <throwaway@insightbb.com>
> Newsgroups: lugnet.robotics.rcx
> Date: Sat, 1 Feb 2003 01:06:27 GMT
>
> give you a direct answer, but I don't know ...
>
> sources which you can adopt, co-opt, or
> reverse-engineer to get where you are going ...
>
> 2. ...
Thanks for the tip, in reply here is a perhaps stunningly ignorant walkthru of
how brickos frames standard commands, viewed by the newbie Me from
kernel/program.lrkey_handler.
The missing (key & -key) might interest people who haven't used log2 & - to
isolate lsb's before. The implications of "if a message, set message number
and exit" when only a message in part might interest a broader audience.
>
http://www.lugnet.com/jump.cgi?http://sourceforge.net/project/showfiles.php%3Fgroup_id%3D58151
> kernel/remote.c, kernel/lnp.c and program.c
Thanks, I reached: kernel/lnp.c kernel/remote.c kernel/program.c
Sorry to see the source less online than: http://lxr.linux.no/source/
Amused to see the downloader here now truncates to 31 chars the filename
"brickos-0.2.6.09.newConf2.tar.gz".
> IR ... remote ... payload ... passed to ...
> Normally, ... lrkey_handler() in program.c.
Thanks, I reached switch (key) case LRKEY_BEEP ...P5 ...P4 ...P3 ...P2 ...P1
...A1 ...A2 ...B1 ...B2 ...C1 ...C2.
The hex meant doesn't plainly appear in the .c, but `grep -r LRKEY include`
found include/remote.h: #define LRKEY_M1 ... LRKEY_BEEP to equal x1 .. x8000,
which at a glance precisely matches the big-endian ushort arg of a standard op
xD2 RemoteCommand payload.
lr_set_handler appears in include/remote.h also, being little more than a
creative name for {lr_handler =}. `grep -r lr_handler include kernel` tells us
only kernel/remote.c cares. remote.lr_process walks thru key_on = is & ~was,
key_off = was & ~is, not conventionally by progressively clearing each log2(key
& -key) but rather by if-testing each (key & (1 << n)).
remote.lr_process runs inside the main loop of remote.lr_thread once for each
wait_event(&lr_waitdata, 0), with the lr_keys bit-or of LRKEY values having
come from lr_data.
I guess we should disregard the comment:
unsigned int lr_data; // lnp data byte
unless there is some sense in which "byte" can mean 16 bits.
grep says nonzero lr_data comes from remote.lr_getdata, which is reached
indirectly, courtesy lnp_remote_set_handler of include/lnp/lnp.h setting
lnp_remote_handler. Only kernel/lnp cares, specifically the
lnp.lnp_integrity_byte said to decode "LNP packets with a state machine".
Again the naming conventions obscure the meaning of such plain code as
{lnp_integrity_state++;}, but grep suggests include/lnp/sys/lnp.h, all together
implying brickos can receive standard op xD2 RemoteCommand #ifdef
CONF_RCX_PROTOCOL and standard op xF7 InternMessage #ifdef CONF_RCX_MESSAGE.
For example, LNPwaitRB0 = (LNPwaitRMH4 + 1).
Among other packets copied Out to the RCX from the PC, the lnp_integrity_state
sequences seemingly accept x 55 FF ~FF D2 ~D2 xx ~xx yy ~yy sum ~sum i.e. a
RemoteCommand packet, else reset to start fresh after any byte is wrong.
I'm not immediately confident that we mean what we wrote as kernel/lnp.c:
case LNPwaitRCI: ...
if (lnp_rcx_temp1 & 0x07)
I mean, I agree the comment is precisely correct as written: "// if a message,
set message number and exit".
But what I don't understand is why this is a Good Thing if the message came
from the remote. I wonder why we choose to toss all other remote key key
press/release notifications whenever one of LRKEY_M1 LRKEY_M2 LRKEY_M3 is
pressed. Just because premature optimisation is the root of all evil? Or did
I misread some code?
Curiously, cluelessly, thankfully yours, Pat LaVarre
|
|
Message has 1 Reply:
5 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
