Subject:
|
Re: Light Sensor help
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 9 Apr 2002 20:06:44 GMT
|
Original-From:
|
T. Alexander Popiel <popiel@wolfskeep%NoMoreSpam%.com>
|
Viewed:
|
631 times
|
| |
|
|
In message: <GuB96o.CKA@lugnet.com>
"John Barnes" <barnes@sensors.com> writes:
>
> The purpose of this post however, is to ask if anyone has done any timing
> tests to find out what the byte code execution speeds are recently. Easy
> enough to do, set up an empty loop that goes round say 10,000 times and time
> it with a stop watch, and then insert different instructions into the loop
> and check out how much longer the overall time increases by.
Yes, I just recently did some timing tests, using that exact method.
Each bytecode takes 2.9 +/- .2 ms to execute, as near as I can tell.
This appears to be independent of which bytecode it is (though I did
not test any that I really expected to be expensive (the multiply and
divide codes, that is)). I specifically tested jmp, jmpl, chk, chkl,
setv, addv, subv, out, and dir (using the NQC disassemble nomenclature).
For setv and chkl, I tested sources 0 (variable), 2 (immediate), and
9 (cooked sensor). I did _not_ test source 36 (indirect).
Also, calling a subroutine takes that same 2.9 +/- .2 ms for each of
the call instruction and the return instruction (in addition to whatever
else is in the subroutine).
> I'd like to think that someone has already done this before, but I can't
> seem to find a post anywhere and if it's that old, it probably wasn't on
> vers 2.0 firmware.
I did this on both 1.5 and 2.0, with no detectable difference.
> It might be very insightful to know just how slow the interpreter is. I have
> a nasty feeling that the effective code execution speed of NQC programs is
> really slow.
Actually, it's not too horrible... particularly if you drive your
motors in a separate task from the sensor readings, and use one of
the global variables to communicate between the tasks. You can get
worst case response from sensor change to motor output in under 30ms
without half trying.
- Alex
|
|
Message has 2 Replies:
 | | Re: Light Sensor help
|
| (...) Wow! That is very interesting. I wonder if the whole thing is synchronous and based on the 3mS sensor read cycle? This would mean that every process gets one of its byte codes "done" during this periodic 3mS spring-clean cycle. I guess the (...) (23 years ago, 9-Apr-02, to lugnet.robotics)
| | | Re: Light Sensor help
|
| "T. Alexander Popiel" <lego-robotics@crynwr.com> wrote in message news:20020409200644....eep.com... (...) time (...) loop (...) I did some similar tests and found similar results. The results held up well up to about 3 tasks, but by the time we (...) (23 years ago, 9-Apr-02, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Light Sensor help
|
| I am posting this to the general robotics newsgroup (I hope) (...) The answer to this bit is easy - the RCX reads the sensors once every 3 mS under the Lego firmware. (I have no idea what the LegOS kernel does.) The purpose of this post however, is (...) (23 years ago, 9-Apr-02, to lugnet.robotics)
|
9 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
|
|
|
|
