Subject:
|
Re: Light Sensor help
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 10 Apr 2002 13:12:06 GMT
|
Viewed:
|
726 times
|
| |
|
|
"Steve Baker" <lego-robotics@crynwr.com> wrote in message
news:3CB39250.8CC16B7F@airmail.net...
> "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.
If you need to use a lookup table where you know the values of the table at
compile time, using a case statement that places a value in a local variable
is your best bet. This way it does not take valuable global or local
variable space, and allows for larger tables than you could get using
variables.
Kevin
>
> 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 is in Reply To:
 | | Re: Light Sensor help
|
| (...) 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 (...) (22 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
|
|
|
|
