| |
In lugnet.org.ca.rtltoronto, Larry Pieniazek wrote:
> In lugnet.org.ca.rtltoronto, Kevin L. Clague wrote:
>
> > I tried to get it working under QuiteC, but had problems with receiving standard
> > RCX IR messages in QuiteC.
>
> Forgive a clueless question here, but is QuiteC different than NotQuiteC? If so
> where can I learn more about it? Thanks!
NQC compiles not quite C code into LEGO firmware opcodes. You download the .rcx
result, and LEGO firmware interprets the program. This makes it slow.
QuiteC and brickOS both use H8 native C compilers that spit out H8 assembly code
directly. The RCX hardware executed these instructions directly, so the code
can be *much* faster.
brickOS is a replacement firmware for LEGO's firmware, but instead of providing
an interpreter, it provides a simple kernel kind of environment providing
multi-tasking programming environment along with an architected interface to the
RCX hardware. The brickOS kernel provides a wonderful set of facilities, but at
the cost of CPU time (due to repeated interrupts for handling RCX hardware.),
and memory because of the space the kernel itself takes up.
QuiteC provides you an interrupt free environment for programming the RCX. It
also provides a very lightweight environment for accessing RCX hardware, so you
have access to a *lot* more of the RCX's precious RAM.
I was using QuiteC so that I could have larger opening books than I knew how to
handle in brickOS. The problem with QuiteC is that the infrared library it
provides is too slow to handle receiving the back to back bytes of an RCX
message. QuiteC inly provides receive library a byte at a time.
After doing some research I settled on using librcx by Kekoa Proudfoot. I
compiled the librcx code and my code using the cygwin compiler that people use
for brickOS. This combination gave me the huge available memory from QuiteC,
and use of Lego ROM code for infrared transmit and receive. librcx does incur
the loss of CPU performance due to repeated interrupts. Since I have this
interrupt overhead with brickOS (my only other meaningful choice, I don't know
Java), it is a don't care. With librcx, I get lots more memory available than
with brickOS, with similar interrupt overhead.
If you want more memory than brickOS can give you, I'd recommend librcx
solutions over QuiteC solutions.
With brickOS, Steve was able to get an opening book with about 300 entries.
With librcx, I'm able to get opening books with about 1700 entries.
>
> The oldest mention of the term "QuiteC" I could find on LUGNET was only 3 weeks
> ago but MAYBE I'm searching wrong?
>
> see http://news.lugnet.com/robotics/rcx/nqc/ as well... if it's different maybe
> a mention of QuiteC might be a good thing there?
Google will take you directly to the QuiteC home page.
If you want to know how to work with librcx, let me know and I can write
something up.
Kevin
|
|
Message has 1 Reply:
Message is in Reply To:
28 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
|
|
|
|
