Subject:
|
Re: reply framing in firmdl3/rcx_comm.c
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Fri, 7 Feb 2003 14:14:25 GMT
|
Viewed:
|
2841 times
|
| |
|
|
--- From: Kekoa Proudfoot [via Pat LaVarre]
...
About message framing, I would not say that the designers at Lego had something
specific in mind for RCX-to-PC messages. Framing for those messages is very
ad-hoc.
One thing which is very useful is the fact that all RCX-to-PC messages are
initiated by the PC, that is, the PC and RCX operate in request/response mode.
The tower shuts off five seconds or so after the PC sends a request, so the
RCX cannot initiate communication arbitrarily. The tower might not be powered
up to receive messages set outside of request/response mode.
Since RCX-to-PC messages are initiated by the PC, the PC knows it should wait
to receive a response before continuing with another request. This waiting can
be implemented in two ways, either waiting until no more bytes are received or
using knowledge of the request sent to determine exactly how many bytes to wait
for as a response. Still, I would not consider the waiting to be the entirety
of the framing algorithm. The 55 ff 00 header and the checksum bytes also help
to frame what is considered a valid message.
...
--- End From
I hope someone finds this incisive summary helpful. Myself I find it too
complete & compelling for me to be left with any reply of substance.
|
|
Message is in Reply To:
 | | reply framing in firmdl3/rcx_comm.c
|
| --- From: Kekoa Proudfoot [via Pat LaVarre] About rcx_comm.c waiting twice, I see where the confusion is now. If no bytes are available, the wait will be T. If some bytes are available, obviously you have to wait at least as long as it takes for all (...) (22 years ago, 6-Feb-03, to lugnet.robotics.rcx)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
