Subject:
|
Re: Light Sensor help
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 10 Apr 2002 01:16:00 GMT
|
Original-From:
|
Steve Baker <sjbaker1@airmail#stopspam#.net>
|
Reply-To:
|
sjbaker1@airmail.%NoMoreSpam%net
|
Viewed:
|
795 times
|
| |
|
|
"T. Alexander Popiel" wrote:
> > Personally, I think 330 byte codes per second is very slow. Any attempt
> > at a series evaluation of trig function would take seconds!
>
> Yeah, but why are you doing trig via series evaluation, instead of just
> doing a table lookup? For that matter, do you really need the trig at
> all?
Well, I can think of lots of reasons why you might want trig - if you know what
direction you are moving in and how far you've travelled, trig will let you
figure out where you are relative to where you started.
Using an NQC lookup table isn't really recommended with the limited storage
facilities and access mechanisms.
Overall, I'd say that any of the byte-code based approaches are great for
simple applications where no great software sophistication is needed - but
as soon as you need more speed/storage/complexity than NQC can provide, you
have to abandon bytecode and switch over to using the raw instruction set
of the underlying microprocessor.
That means using something like LegOS instead of the Lego firmware and
compiling your programs using a full-up cross-compiler such as GCC. (There
are a couple of other options too - but I think LegOS is the most promising).
That'll allow your programs to run at least 100 times faster than NQC
(maybe more - I havn't timed it) and to use the features of the processor
much more efficiently. Of course you'll be writing in real honest-to-
goodness-C and not "Not Quite C" - so you'll have to accept some changes
in the way you work.
Unfortunately, the development environment is also a lot less friendly
and considerably harder to set up than NQC. But if you've done a lot of
non-Lego C programming in the past though you shouldn't have any trouble
getting it all together.
NQC is remarkable for what it is and it does a great job of turning
the bytecoded system into something friendly. I still use it for lots
of quick hacks and non-demanding applications - also for programming
the "Scout" (which can't run LegOS because you can't replace it's firmware).
> The RCX doesn't have the memory or the speed to do anything
> computationally interesting...
That's really not true once you dump Lego's firmware.
----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net> WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
http://prettypoly.sf.net http://freeglut.sf.net
http://toobular.sf.net http://lodestone.sf.net
|
|
Message has 1 Reply:
 | | Re: Light Sensor help
|
| "Steve Baker" <lego-robotics@crynwr.com> wrote in message news:3CB39250.8CC16B...ail.net... (...) what (...) you (...) storage (...) If you need to use a lookup table where you know the values of the table at compile time, using a case statement (...) (23 years ago, 10-Apr-02, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Light Sensor help
|
| (...) Yes, it all appears to be synchronous. However, only one bytecode instruction is run in any given 3ms; any active tasks interleave their instructions. If you have two tasks running, they will each be getting an instruction every other 3ms. If (...) (23 years ago, 10-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
|
|
|
|
