Subject:
|
RE: RCX to RCX NQC
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Thu, 15 Sep 2005 01:13:24 GMT
|
Viewed:
|
4308 times
|
| |
|
|
The message "toggle" bit was a good concept that has very
limited value in practical use.
I guess the intent was to prevent unexpected behavior when a
PC program attempts retransmission after a message failure.
Suppose the failure condition was that RCX had received the
message but that PC failed to receive the acknowledgement
from the RCX. The end result is that the RCX receives two
valid messages. If the message was opcode "X += 1" then the
end result is that "X" got incremented twice instead of
once. However, most messages are "benign" and it doesn't
matter if they're sent twice.
In the real world, messages that can cause unexpected
results (i.e. "X += 1") are never sent. So, it would be
pretty safe to simply have the messaging software ignore the
"toggle" bit.
You might think that program downloading is a case where
double sending of the same message would be of this "cause
an unexpected result" class. But this message is specially
handled by the firmware. There's an index field within the
message that is incremented after reception of a successful
"download" packet. Firmware ignores download messages with
the wrong index so the double transmission is handled almost
OK. What firmware doesn't do is rewrite the data again so
that if the first message failed with a corrupted data byte
it won't handle the retransmission.
The Lego firmware ignores the toggle bit for the remote
message, program download message, "set mailbox message,
upload datalog and a few others, which is why they may work
in the application discussed in an earlier message in this
thread.
The actual remote control has the remote continuously send
messages containing a bit map of which keys are pressed.
When the last key is released, it sends one message where
the bit map is all zeroes. The RCX firmware receives these
messages and looks for changes in the bit map from message
to message to trigger the appropriate action. When the
remote is used to direct control a motor, a timer is also
started whenever remote message is received. When the timer
expires it will also end the direct motor control mode which
catches the case of the last (all keys up) message from the
remote being lost.
If you use my replacement firmware, you'll get a lot of
benefits on this topic:
* It ignores the toggle bit for 'benign" message opcodes.
* It properly handles retransmission of failed download
messages.
-----Original Message-----
From: news-gateway@lugnet.com
[mailto:news-gateway@lugnet.com]On Behalf Of Steve
Hassenplug
Sent: Wednesday, September 14, 2005 4:07 PM
To: lugnet.robotics.rcx@lugnet.com
Subject: Re: RCX to RCX NQC
On Wed, September 14, 2005 3:15 pm, Brian Davis wrote:
> How does the remote get around this? Or does it? It • seems to imply that
> commanding a pBrick with the computer IR link or a remote
at the same time would
I'm pretty sure, both the remote, and the send message
commands only have one
op-code, and are done differently from the rest.
Steve
|
|
Message is in Reply To:
 | | Re: RCX to RCX NQC
|
| (...) I'm pretty sure, both the remote, and the send message commands only have one op-code, and are done differently from the rest. Steve (19 years ago, 14-Sep-05, to lugnet.robotics.rcx)
|
8 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
