Subject:
|
Re: Memory - Where did it go?
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 10 Jul 2006 03:40:08 GMT
|
Highlighted:
|
(details)
|
Viewed:
|
7765 times
|
| |
| |
In lugnet.robotics, Tom Stiles <hamrad45@hotmail.com> wrote:
>
> 1) Can any one give me some idea what the pre-loaded (system) files are and
> which one I can delete safely?
> 2) Can someone show me one of their more complicated programs and how much
> memory it took? (I am thinking about just generating some random
> programming with a lot of functions but no sound bytes to see how effiecent
> the program is when complied but an example of a large real program would be
> better).
With a newly loaded firmware:
C:\WINAPPS\projects\Bricxcc>nexttool /COM=x -freemem
70324
C:\WINAPPS\projects\Bricxcc>nexttool /COM=x -listfiles
NVConfig.sys=1
RPGReader.sys=14346
Demo.rxe=9436
Try-Touch.rtm=3788
Try-Light.rtm=4456
Try-Sound.rtm=6864
Try-Ultrasonic.rtm=3756
Try-Motor.rtm=2630
Woops.rso=4699
faceopen.ric=316
faceclosed.ric=316
! Startup.rso=8161
! Click.rso=451
! Attention.rso=1755
All of these files can be deleted without any negative impact aside from 1) not
hearing any goofy sounds when you turn on the NXT or press its buttons, 2) not
being able to run the "Try Me" programs (*.rtm), 3) not being able to run the
demo program, and 4) not being able to run any NXT Program (.rpg) programs
(which are interpreted by the RPGReader.sys executable). If you are interested
in downloading your own programs written in NXT-G or NBC then you do not need
any of these files.
C:\WINAPPS\projects\Bricxcc>nexttool /COM=x -clear
C:\WINAPPS\projects\Bricxcc>nexttool /COM=x -freemem
133824
NeXTTool is a utility I wrote which lets you interact via USB or Bluetooth with
the NXT brick from a Win32 command prompt. It requires the fantom.dll and the
National Instruments VISA drivers which are installed by the standard LEGO
Mindstorms NXT software which comes with the NXT set.
To communicate quickly with the NXT using BricxCC, NBC, or NeXTTool you should
create a nxt.dat file containing brick resource strings and alias names like so:
C:\WINAPPS\projects\Bricxcc>type nxt.dat
x=USB0::0X0694::0X0002::001653FF0156::RAW
C:\WINAPPS\projects\Bricxcc>nexttool -listbricks
USB0::0X0694::0X0002::001653FF0156::RAW
If you have a working bluetooth dongle and/or multiple NXT bricks turned on and
in the vicinity of your PC then the -listbricks action will list more than one
resource string. Redirect the output of -listbricks to nxt.dat and edit the
file in notepad. Add an alias name and = in front of each resource string and
save the file.
I have reinstalled the firmware on my NXT several times and haven't had any
problems with the clicking brick syndrome. I highly recommend doing all your
brick communication via USB as it is many, many times faster and more stable
than bluetooth. You can boot the NXT into SAMBA mode via NeXTTool and reinstall
the firmware as well:
C:\WINAPPS\projects\Bricxcc>nexttool /COM=x -boot
C:\WINAPPS\projects\Bricxcc>nexttool -firmware=firm103.rfw
C:\WINAPPS\projects\Bricxcc>nexttool /COM=x -clear
C:\WINAPPS\projects\Bricxcc>nexttool /COM=x -versions
Protocol version = 1.124
Firmware version = 1.3
Sounds (.rso files) are a huge memory hog on the NXT. Don't use them if you
want to maximize the memory available on the NXT. If you have to use them then
use Wav2Rso to resample the sound at 8k and convert the file to an 8 bit mono
file. An alternative to large .rso files is to use Melody files which are a
series of tone values (frequency/duration pairs). You can create Melody files
(.rmd) using BricxCC's Brick Piano or its MIDI conversion tool. If you want to
play a melody file using NXT-G then you will need to rename it with a .rso file
extension so that the PlaySound block will be able to find the file on the NXT
(it is hardcoded to append a .rso extension to whatever sound file name you
pick). I also have a MIDI batch converter utility and a RMD Player utility
which I haven't posted yet but they will be up on my website later this week.
Image files (.ric) are not nearly as large but they also can use a lot of
memory. Many blocks in the NXT-G language are extremely inefficient when it
comes to the code that is added to your program by the NXT-G compiler. The Draw
block is particularly bad. It implements 6 separate operations regardless of
which one you want to use and although that code is not entirely duplicated when
you use the Draw block multiple times in a program there is a lot of overhead in
calling the subroutine that is used to represent the draw block.
C:\WINAPPS\projects\Bricxcc>nexttool /COM=x -listfiles
d3.rxe=1412
d2.rxe=1210
d1.rxe=970
You can use my RXEDumper utility or NBC with the -x action to decompile a .rxe
file and see what all is being generated by the NXT-G compiler (or by the NBC
compiler, for that matter). Use NeXTTool to upload the .rxe file(s) to your
computer from the NXT.
C:\WINAPPS\projects\Bricxcc>nexttool /COM=x -upload=*.rxe
C:\WINAPPS\projects\Bricxcc>dir *.rxe
Volume in drive C has no label.
Volume Serial Number is 84A7-92D4
Directory of C:\WINAPPS\projects\Bricxcc
07/09/2006 09:32 PM 970 d1.rxe
07/09/2006 09:32 PM 1,210 d2.rxe
07/09/2006 09:32 PM 1,412 d3.rxe
07/09/2006 06:01 PM 2,164 goodbyemsg.rxe
4 File(s) 5,756 bytes
0 Dir(s) 72,613,892,096 bytes free
Using the decompiler will let you get a better handle for how inefficient the
NXT-G language and its compiler really are. I highly recommend that you trace
through the decompiled code of a few semi-complicated programs as doing so will
be a big eye-opener. The bottom line is that most of the blocks (LabView VIs)
in NXT-G are composed of several smaller blocks, each of which are composed of
several smaller blocks, etc. The blocks are all connected to each other by
wires that hook one block's outputs to other blocks' inputs. Each output is a
variable in your NXT-G program. Each input is a variable in your NXT-G program.
Even if those defined outputs and inputs are not directly used in your NXT-G
program the compiler output will still have all of those variables defined and
in use in your .rxe. At some point in the hierarchy of nested block definitions
you get down to low level LabView functions such as the subtract function which
will be represented by the compiler as a single opcode with three arguments in
the compiled executable but there aren't very many blocks in NXT-G which are a
direct map to such low level functions.
NXT-G is a graphical dataflow programming language. The virtual machine in the
NXT firmware was written by National Instruments to work like the virtual
machine in the LabView runtime. Partly because of this fact the compiler often
generates some really funky (complicated) code for things like loops.
Programs written in NBC with the same functionality as NXT-G programs are often
orders of magnitude smaller in size and much faster in execution speed.
I wrote a simple 5 block program in NXT-G called goodbyemsg.rbt. The "source
code" is 224,171 bytes in size. It compiles down to a 2,164 byte executable.
The equivalent program written in NBC has text source code that is 1,583 bytes
in size and it compiles down to a 382 byte executable.
John Hansen
http://bricxcc.sourceforge.net/
|
|
Message has 1 Reply: | | Re: Memory - Where did it go?
|
| I'm coming in a little late on this topic, but I wanted to restate things just a little. NXT programs are built using a library of blocks. These blocks are not "built-in", to the compiler, but are simply shipped and placed in the palette. Each of (...) (18 years ago, 20-Jul-06, to lugnet.robotics)
|
Message is in Reply To:
| | Memory - Where did it go?
|
| I got my Mindstorms NXT this past weekend and built the demo unit and then the Claw with only minor programming errors. Tonight I started using some of the various programming functions. My first program was to use the sonar and detect the presence (...) (18 years ago, 6-Jul-06, 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
|
|
|
|