 | | 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)
|
| |
| | Re: What I would do (2)
|
|
(...) Very good point! So one design goal/guiding principle would be try not to break brickOS programs for NXT and provide if nessecary a easy software upgrade path. (...) I would really like to point out (to the general audience) what I see as a (...) (18 years ago, 27-Jan-06, to lugnet.robotics)
|
| |
| | Re: What I would do (2)
|
|
(...) I'll add it to my tool belt if it'll run on Linux ;) I certainly don't mean to slight the NXT software (I haven't even played with it yet). I assume it will be quite capable. (...) Indeed. Programming languages are simply tools. They should be (...) (18 years ago, 27-Jan-06, to lugnet.robotics)
|
| |
| | Re: What I would do (2)
|
|
(...) <snippage> (...) Ed, can you point me to the sort of things you have read which make you believe the NXT software and its underlying firmware will provide the sort of control and flexibility which such things as NQC and alternate firmwares (...) (18 years ago, 31-Jan-06, to lugnet.robotics)
|
| |
| | 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 (...) (18 years ago, 31-Jan-06, to lugnet.robotics)
|
| |
| | 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)
|
|
(...) Absolutely. I think the design of the NXT NQC should be dependent on the standard firmware just as NQC was based on the RCX firmware. David nailed exactly what I'm interested in. Even when using NQC it still **feels** like I'm writing in C. It (...) (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)
|
