Subject:
|
Re: NQC 2.1 b2 in beta test
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Thu, 13 Jan 2000 02:48:26 GMT
|
Reply-To:
|
mattdm@mattdm!StopSpammers!.org
|
Viewed:
|
1723 times
|
| |
| |
Dave Baum <dbaum@spambgoneenteract.com> wrote:
> 1) The IR tower times out. NQC should probably do something to keep it
> alive - and that "something" should be as minimal as possible so as not to
> clobber *too much* incoming data.
Yes, this is why I'd like someone else to implement this. I just want to use
it. *grin*
> 2) How should the receive data be formatted? Raw serial bytes? Raw
> packet payload (strip out header, complements, and checksum)? Should it
> actually walk into the packet and only show the RCX "messages"?
RCX messages is what I'm interested in. It might be reasonable to have
several modes.
> 3) Does this really belong in NQC, or should it be a separate executable?
> The NQC command line is getting a bit unwieldy due to everything I've
> crammed into it.
Good question. I don't think this feature is out of line with ones that
already exist (datalog, run, msg....). On one hand, I can certainly see the
logic of seperating out the talking-to-the-brick-related functions, but on
the other, it's extremely convenient to compile and download in one step,
and if that's going to be in there, the rest might as well be too.
--
Matthew Miller ---> mattdm@mattdm.org
Quotes 'R' Us ---> http://quotes-r-us.org/
|
|
Message is in Reply To:
| | Re: NQC 2.1 b2 in beta test
|
| (...) I remember discussing this briefly, but I don't think we ever came up with a final "spec" for the feature. Here are the issues I forsee: 1) The IR tower times out. NQC should probably do something to keep it alive - and that "something" should (...) (25 years ago, 13-Jan-00, to lugnet.robotics.rcx.nqc)
|
25 Messages in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|