Subject:
|
Re: NQC vs Spirit communication speed
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Fri, 11 May 2001 17:51:40 GMT
|
Viewed:
|
1989 times
|
| |
|
|
In article <dbaum-295BE9.11412611052001@lugnet.com>, Dave Baum
<dbaum@spambgoneenteract.com> wrote:
> * Enabling predictive replies (set fPredictive field true) can help a
> lot since in many cases the link is able to tell when a complete reply
> is received without waiting for the full timeout. Actually, one of my
> gripes with the RCX packet format is that you can't always tell the
> length of a packet without also interpreting the contents of the packet.
> This makes it difficult to partition the delivery of packets from the
> use of packets. So not all of the packet times will take advantage of
> predictive replies. I think I included data for the ones NQC commonly
> uses, but probably not for the stuff you are doing. Look at the
> PredictReplyLength() method - it needs to return the expected number of
> bytes for a given bytecode. The default is 1000, which really just
> means keep reading until the timeout.
I looked into this a bit more and the poll bytecode (0x12) didn't have a
case in the PredictReplyLength() switch. If you add...
case 0x12: // poll
return 2;
then poll will be a lot faster. If you run into other bytecodes that
you use a lot, adding them into the switch statement will help. At some
point I'll go through and put them all in (or code them as a table
instead of a switch).
Dave Baum
--
reply to: dbaum at enteract dot com
|
|
Message is in Reply To:
 | | Re: NQC vs Spirit communication speed
|
| The retry timing for RCX_Link uses a dynamic backoff, which is a good general purpose solution if you're going to be sending lots of packets (like a typical NQC download) and the latency through the serial driver is unknown and/or unpredictable (...) (23 years ago, 11-May-01, to lugnet.robotics.rcx.nqc)
|
8 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
