 | | Re: NQC vs Spirit communication speed
|
|
(...) I'm using AutoLink.Send for most things. Initially I was always closing the link at the end of each method (which mostly map to the Spirit OCX API). I've made that configurable and at present I'm running with it set to leave the link open. (...) (23 years ago, 11-May-01, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: NQC vs Spirit communication speed
|
|
(...) 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, (...) (23 years ago, 11-May-01, to lugnet.robotics.rcx.nqc)
|
| |
| | 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)
|
| |
| | NQC vs Spirit communication speed
|
|
This is more a general RCX communication question, actually. As I mentioned here previously, I've ported the NQC communication code to Delphi for the purposes of modifying RcxCC to not use the Spirit OCX. At present I have a version of RcxCC that (...) (23 years ago, 11-May-01, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: API changes
|
|
My only concern with these proposed changes is possible increased memory usage. Encapsulation, error reporting, thread synchronisation etc are nice; but with just 32k of RAM I would question whether these are appropriate for some applications. For (...) (23 years ago, 11-May-01, to lugnet.robotics.rcx.legos)
|
