Subject:
|
Re: What I would do (2)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 31 Jan 2006 18:54:31 GMT
|
Viewed:
|
1837 times
|
| |
|
|
In lugnet.robotics, Tim Byrne wrote:
> Hopefully I can keep the number of Mindstorms languages I need to be proficient
> with down to 2 regardless of what brick I am using. NQC when the standard
> firmware is enough, and BrickOS when more flexibility is needed.
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 the new brick.
Would you prefer that NQC work miracles (at the expense of performance) to keep
the NXT API as much as possible directly compatible with the RCX2 API or would
you prefer that NQC work as close to the metal as possible at the expense of API
compatibility? By "work miracles" I mean something along the lines of "generate
lots of extra code behind the scenes as needed, including such things as hidden
tasks and subroutines which act as helpers to the NXT version of the NQC API".
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?
John Hansen
|
|
Message has 6 Replies:
 | | Re: What I would do (2)
|
| (...) As the brick, sensor, motors... are quite different, direct portability is not of paramount importance for me. So I vote for performance. Philo (18 years ago, 31-Jan-06, to lugnet.robotics)
| | | Re: What I would do (2)
|
| (...) The optimum solution would be both - provide a new API that gets the most out of the new firmware, but an optional "compatability layer" that adds what is necessary to provide an API compatable with the RCX. Note that I'd vote to get the new (...) (18 years ago, 31-Jan-06, to lugnet.robotics)
| | | Re: What I would do (2)
|
| (...) Oh, performance! NXT NQC should match the NXT brick's capabilities. How many people have such sophisticated programs that they need to port from the RCX to the NXT to realisically demand compatibility? I mean this a robot hobby tool. Half the (...) (18 years ago, 31-Jan-06, to lugnet.robotics)
| | | Re: What I would do (2)
|
| (...) Definitely performance! Trying to porting an old RCX program to the NXT would be near impossible -- everything is so different there. Just as you'd have to totally rebuild your robot, you have to do a total rewrite of your code anyway. So (...) (18 years ago, 1-Feb-06, to lugnet.robotics)
| | | Re: What I would do (2)
|
| (...) 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 (...) (18 years ago, 1-Feb-06, to lugnet.robotics)
| | | Re: What I would do (2)
|
| (...) I'd say: Go for the NXT thing! Give us a language that utilizes the NXT as much as possible. As the NXT is both faster and has more memory than RCX (not to mention the CyberMaster, which is all I have for the moment) it doesn't seem (...) (18 years ago, 1-Feb-06, to lugnet.robotics)
|
Message is in Reply To:
| | Re: What I would do (2)
|
| (...) I would be in favor of having a port of BrickOS for NXT (instead of having another thing to learn). I'm not gonna throw away my RCXs and I would prefer having similar languages for both bricks. Yes programmers would need to know the nuances (...) (18 years ago, 26-Jan-06, to lugnet.robotics)
|
24 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
