Subject:
|
Re: NQC versus Lego RCX Code Speed
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sat, 7 Oct 2000 21:11:40 GMT
|
Original-From:
|
Doug Wilcox <doug@wilcoxfamily.%SayNoToSpam%net>
|
Viewed:
|
940 times
|
| |
|
|
Yes, this explains my observations perfectly!
I will probably set up some more experiments--attempting to exactly
duplicate the function of my oddly-behaving RCX Code (my currently-running
NQC program is very close already), and try to get some real observation and
statistics down, as well as getting a graphic of the RCX Code program for
comparison.
As I'd said, the behavior was not consistent on all "watched processes"--one
touch sensor would trigger virtually instantaneously, but the other was
significantly delayed--enough so that I thought the RCX might be defective.
Thanks again, Kekoa Proudfoot, Ralph Hempel, Luis Villa, Steve Baker, John
Tamplin, Mike Pulver, and Cong, for your valuable insights.
--Doug Wilcox
----- Original Message -----
From: Kekoa Proudfoot <kekoa@pixel.Stanford.EDU>
To: <lego-robotics@crynwr.com>
Sent: Friday, October 06, 2000 4:12 PM
Subject: Re: NQC versus Lego RCX Code Speed
> Wilcox, Doug <Doug.Wilcox@iMcKesson.com> wrote:
> > I noticed this when I had a fairly simple program written in RCX Code • that
> > was checking two separate bumpers and backing and turning depending on • which
> > one was pressed. (The only other routine in the program was to emit a • beep
> > every 5 seconds) The second bumper would only "trigger" after a 1-2 • second
> > delay. I thought I had a bad RCX or bad sensor, but I tried the same • program
> > on my second RCX with different sensors, and the same thing happened! • This
> > delay behavior might only be a problem using certain combinations of • Sensor
> > Watchers, but it did get me thinking about what's going on under the • hood.
>
> With regards to your comment about sensor watchers, yes they are slow. If
> I remember correctly, they are implemented by a task that loops forever
> polling the sensors and starting other tasks whenever an event of the
> proper type occurs. Tasks are executed in a tightly interleaved fashion
> (one instruction at a time from each active task), which I imagine is not
> particularly efficient in some cases. For example, when a sensor watcher
> is triggered, I believe the poll task is still running, increasing • response
> time by at least 2x.
>
> With NQC, you have control over how sensors are polled and how the
> responses execute. If you stick to a single task, you normally stop
> polling while you are responding to an event, reducing response time.
>
> Does this explain what you observe?
>
> -Kekoa
>
|
|
Message is in Reply To:
 | | Re: NQC versus Lego RCX Code Speed
|
| (...) With regards to your comment about sensor watchers, yes they are slow. If I remember correctly, they are implemented by a task that loops forever polling the sensors and starting other tasks whenever an event of the proper type occurs. Tasks (...) (24 years ago, 6-Oct-00, to lugnet.robotics)
|
3 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
