Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!helios.ee.lbl.gov!bevb.bev.lbl.gov!biocca
From: biocca@bevb.bev.lbl.gov (Alan Biocca)
Newsgroups: comp.realtime
Subject: Re: vxWorks memory partitions
Keywords: free forget debug_cycle vxWorks
Message-ID: <2605@helios.ee.lbl.gov>
Date: 11 May 89 15:22:23 GMT
References: <3213@ncar.ucar.edu> <2603@helios.ee.lbl.gov>
Sender: usenet@helios.ee.lbl.gov
Reply-To: AKBiocca@lbl.gov (Alan Biocca)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 51

In article <2603@helios.ee.lbl.gov> wlbrown@lbl.gov (Bill Brown) writes:
>In article <3213@ncar.ucar.edu> cmiller@hao.ucar.edu (Charlie Miller) writes:

>>The apparent problem: In the debug cycle of modify, load, try, modify, reload,
>>vxWorks eventually uses up all available memory by not deallocating partitions
>>allocated to each program loaded even though the new program has the same
>>name.  It just allocates new partitions until no more are available then
>>refuses to allow loads.  The only way I have found to get around this is
>>to manually do free(program_name) from the shell or to reset. There must be
>>a way to automate this process.

How about creating a load script that does 'free x' 'load x' ???????

>>Any suggestions??

>>Also, I would like to hear from other vxWorks users out there.  What are
>>your applications, etc.

>An interesting idea, this.  I've wanted to do something like this (similar
>to the 'forget' word in FORTH) but never thought of trying 'free'.

>I usually have more than one file that needs to be loaded and I use a
>script like this:
>	ld <framis_1.o
>	ld <framis_2.o
>	ld <doohickey.o
>    which resides in a file called "ld_this_stuff"

>After doing ->cd "host:~me/vxworks/current_dir" in invoke the script by
>	<ld_this_stuff
    
A convenient aid here is to enable the vxStartup feature of vxWorks and
create a vxStartup file that contains your startup and program load commands.
Then a periodic reboot of vxWorks is pretty painless.

vxWorks is being used here at Lawrence Berkeley Lab (LBL) for a number
of applications.  Initially it was purchased for the Keck Ten Meter Telescope
Active Control System to run the 108 motors that position the 36 hexagonal
main mirror segments to within a few nanometers.  The VME crate that performs
this control contains twelve CPU's running vxWorks.  It was later adopted for
much of the other subsystems within that project.  The next project at LBL
to obtain vxWorks was the BEVALAC Accelerator and we are currently using it
to bridge between the new Sun-based operator consoles and the old Modcomp
control system.  As time progresses we will be adding new controlled items
to the system via vxWorks and eventually replacing the older Modcomp based
controls.  Other projects here are in various stages of considering or
planning systems using vxWorks for NMR Research data acquisition and control,
magnetic measurements, physics experiments data acquisition, seismic data
acquisition and realtime analysis, and so on.

	Alan K Biocca