Subject:
|
Re: command framing as seen from kernel/program.lrkey_handler
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Sat, 1 Feb 2003 17:32:54 GMT
|
Viewed:
|
3801 times
|
| |
|
|
"Pat LaVarre" <ppaatt@aol.com> wrote:
> Sorry to see the source less online than: http://lxr.linux.no/source/
Here's the link:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/brickos/brickos/kernel/
> 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.
and
> 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)).
If I'm interpreting your shorthand correctly: there's no fast way to
execute log2() on the H8 (i.e. no O(1) solution), hence masking the
bits is used as a quicker alternative. The H8 does have instructions
that could be used here for testing and manipulating individual bits,
though. Some examples are: btst, bset, bclr, bnot, etc...
OTOH, perhaps you are saying that line 92 of remote.c could be
written like this:
for ( ; k = keys_on & -keys_on; keys_on ^= k)
lr_handler(LREVT_KEYON, k);
for ( ; k = keys_off & -keys_off; keys_off ^= k)
lr_handler(LREVT_KEYOFF, k);
> 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.
Indeed. ;-)
> 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?
I agree, it's not entirely ideal. An improvement might be:
switch (lnp_rcx_temp1 & 0x07)
{
case 1: lnp_rcx_message = 1; break;
case 2: lnp_rcx_message = 2; break;
case 4: lnp_rcx_message = 3; break;
}
if (lnp_remote_handler)
lnp_remote_handler( (lnp_rcx_temp0<<8)+lnp_rcx_temp1 );
Of course, it might be nicer if the remote handler got to decide
whether it wanted to handle the message keys or not. If it didn't
want the message keys, then it could call a system default handler
that would interpret them.
Cheers,
Mark
|
|
Message has 1 Reply:
Message is in Reply To:
5 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
