Subject:
|
Re: NQC 2.x event processing
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Sun, 4 Jun 2000 02:35:25 GMT
|
Viewed:
|
5026 times
|
| |
|
|
In article <3939AF83.2F43@gmccomb.com>, Gordon McComb
<gmccomb@gmccomb.com> wrote:
> Dave, I'm curious if the system of events and event-trapping in NQC 2.x
> will remain about the same as it is now. I played around with it this
> last week, and had little success (it worked once or twice, I *think*),
> but what struck me was how much I liked the events system in the LEGO
> pBrick script language. It's pretty clear they've developed their
> language around subsumption architecture, and while it's possible to
> replicate this with procedural code, it sure is nice to have it
> built-in.
I don't have any changes in mind for the monitor/catch construct,
although I'll listen to suggestions if people have any. There was a
brief discussion about this a while back:
http://www.lugnet.com/robotics/rcx/nqc/?n=570
At that point I was already pushing a procedural approach - mostly
because the zen of NQC is to be like C, so I was looking for things
similar in feel to C or C++.
fwiw, I've been playing with the monitor/catch stuff for a while now and
I like it. There was a lot of trial and error just getting the events
set up and working (yes, I'll document this eventually), but after that
the monitor/catch syntax (and acquire/catch as well) led to a reasonbly
clean program structure.
I haven't played with the pBrick scripting myself, so I'm not sure
exactly what sort of syntax or feature you'd like to see. Bear in mind
that NQC is similar to C in that is doesn't put too much between the
programmer and the metal (or in the RCX case the bytecode interpreter).
I don't have an objection to layering more sophisticated APIs (or
perhaps even syntaxes) on top of basic low level forms, but I certainly
don't want to start off with a lot of program structure being defined by
the compiler.
The APIs for configuring the events may change a bit. For one thing,
SetEvent() got a little better in 2.2 a2 because you can now specify the
event source directly rather than using special constants...
SetEvent(0, SENSOR_1, EVENT_TYPE_PRESSED);
SetEvent(0, Timer(0), EVENT_TYPE_PRESSED);
Setting the parameters for events is currently a bit tedious because you
always have to use Set() calls. Right now I'm playing around with the
compiler a bit to see if I can easily get it to allow direct
assignment...
UpperLimit(0) = 10;
instead of
Set(UpperLimit(0), 10);
If I get assignment working, I may then move to an array style syntax:
UpperLimit[0] = 10;
since "UpperLimit(0) = 10;" looks very strange to most people (although
some C++ programs have a lot of this sort of thing).
Dave
--
reply to: dbaum at enteract dot com
|
|
Message has 1 Reply:
 | | Re: NQC 2.x event processing
|
| (...) #3, which was the approach you took. (...) I think what I liked about the approach in pBrick script was that it was fairly like coding a microcontroller in assembler: set up an interrupt vector and then include a label and code for the (...) (26 years ago, 5-Jun-00, to lugnet.robotics.rcx.nqc)
|
Message is in Reply To:
| | NQC 2.x event processing
|
| Dave, I'm curious if the system of events and event-trapping in NQC 2.x will remain about the same as it is now. I played around with it this last week, and had little success (it worked once or twice, I *think*), but what struck me was how much I (...) (26 years ago, 4-Jun-00, to lugnet.robotics.rcx.nqc)
|
6 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
|
|
|
|
