Subject:
|
Re: What I would do (2)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 1 Feb 2006 15:47:18 GMT
|
Viewed:
|
2090 times
|
| |
|
|
In lugnet.robotics, John Hansen wrote:
> I'm not saying that this will turn out to be the case, but it could. And in the
> unlikely event that it does I am seeking NQC user feedback. Which is more
> important: API compatibility or Performance?
Performance should come first.
But thinking about API compatability, hopefully we will get a more programmable
environment than the RCX's limitation from registers, functions and memory. A
slowdown process may also be needed to make the NXT run as slow as the RCX. The
multiplexing trick for touch sensors is a stumbling block until we get a work
around for it.
I'd suspect that an included RCX header+code file would be capable of down
converting the more refined sensor and motor values to the old RCX values using
functions. Of course, NCQ could have a compile option to do this in the
background. This is more elegant but more work for you. I think the major
consideration for backward compatability is naming. The header/code approach
would need hard coded constants as I doubt that the NXT will use different names
for the motors and sensors. But, the compile option would make this moot.
Writing down ideas as you create the NQC compiler to make this work won't be a
bad thing.
|
|
Message is in Reply To:
 | | Re: What I would do (2)
|
| (...) I like this concept, but what if in the case of NQC the new firmware turns out to be such a radically different design that it makes it extremely difficult, if not impossible, to carry over very much of the rather large API built into NQC to (...) (19 years ago, 31-Jan-06, to lugnet.robotics)
|
24 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
