Subject:
|
RE: NXT Programming with C Question
|
Newsgroups:
|
lugnet.robotics.nxt.nxthacking
|
Date:
|
Sun, 20 May 2007 01:46:21 GMT
|
Reply-To:
|
<DICKSWAN@SBCGLOBAL.NETihatespam>
|
Viewed:
|
16143 times
|
| |
|
|
> In lugnet.robotics.nxt.nxthacking, Alexis Morris wrote:
>
> > does anyone know why plain C code can't just
> > compile and run on the NXT...
Ralph and Brian have provided good input that parallels my experience.
Here's a little more information.
If you have access to the IAR tools you can compile the NXT firmware
available in the NXT SDK from LEGO "out of the box". I believe there are
now available ports that will allow the use of the GCC tool chain. This
will allow you to re-use all of the LEGO supplied device driver code and
you can write your own code as long as you conform to the calling
parameters and constraints of these device drivers.
It is these "constraints" that will cause you grief. The LEGO firmware
is a single task solution without any of the niceties of a small RTOS.
In particular:
1. Every module works on a "cooperative multitasking" design. The
software module is called once per millisecond and by design it must
take a very short time slice and return.
2. There are about a dozen modules that are called sequentially on the
1-msec timer tick. The first 11 are the LEGO supplied device drivers and
the last one is special (i.e. the file "C_cmd.c" in the LEGO Firmware).
This module must consume all the available real-time until the next
available 1-msec tick. For LUA, RobotC and NXT-G this module is the VM
interpreter for the byte codes and executes as many byte codes as
possible in the 1-msec tick.
3. The VM interpreters provide the neat things like multi-tasking. THIS
IS HUGE BENEFIT for end user program design.
4. The VM interpreters also converting the more complex device driver
function calls into more friendly function calls.
I don't think it would be easy to convert the LEGO supplied device
drivers into something easy to use with a microprocessor RTOS. They have
been written assuming the "cooperative multitasking" architecture and
take advantage of the fact that only one module is active / running at a
time. They are not thread safe and have no critical sections to block
simultaneous access to volatile variables.
Both LUA and RobotC have very fast VM interpreters that are likely more
than adequate for any but the most taxing end user program. RobotC binds
data types at compile time whereas LUA does this at run time so you'll
find RobotC programs execute faster. But, my experience is that they are
both have significantly faster execution speed when compared with
programs written using the graphical NXT-G language.
OF course, the other benefit is that the RobotC (and NXT-G) firmware
takes up about 1/2 of the 256K flash. [I don't know about LUA, but
suspect it is in the same ballpark give or take 30K]. End user programs
are typically well under 10k in size -- most RobotC programs are under
1K. It's a lot shorter to download this smaller size rather than a
complete firmware replacement. And, for the systems that support
Bluetooth, you can download files over BT but not do a firmware reload
-- the boot loader only works on the USB port.
|
|
Message is in Reply To:
6 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
