file system

Thu Feb 5 17:48:00 UTC 2004

Steve,
I put the monConnect() call at the top of bsp_start().
Then, after that point you can use any of the monitor's API
functions.  At that point, the most useful one is mon_printf();
however you have to be aware of the fact that sooner or later in
the startup of RTEMS it will take over the serial port; hence,
mon_printf() calls after that point wouldn't be needed.

Yes, you can pass arguments from the command line...
Just after monConnect(), call mon_getargv() as follows...

#include "monlib.h"

void bsp_start( void )
{
  int argc;
  char **argv, *stuff;

  monConnect((int(*)())(*(unsigned long *)MONCOMPTR),(void *)0,(void *)0);
  mon_getargv(&argc,&argv);

  /* PROCESS ARGLIST HERE */

  /* OR */

  stuff = mon_getenv("RTEMS_STUFF");

  /* PROCESS ENV VARS HERE */
  ...
}

Using the above call to mon_getargv() allows you to startup your application and
pass it arguments on the command line.  So, if your executable is called rtems_app,
then at the uMON> prompt, you could just type "rtems_app arg1 arg2 arg3..."

Alternatively, you could set up environment variables at the monitor shell then
use mon_getenv() to retrieve them in your application.

To get the correct value of MONCOMPTR, just type the "mstat" command and note the
value printed.

The monConnect() is in the monitor source code file monlib.c which you should just
include in your rtems build (along with the necessary header files).

Regarding bsp_cleanup()...
Not sure what this is (I'm pretty new to RTEMS), but if it is the terminating
function of the application, then sure, you could call mon_appexit() there.
It provides a clean transition from an application that has taken over all
target facilities (stack, io, etc...) back to the monitor.

Hope this helps.
Ed

Steve Strobel wrote:
> 
> I am also using MicroMonitor on a 5272 (custom board).  It doesn't take much effort to port it, because so many of the peripherals are built into the 5272 and don't change from board to board.  I did have to adapt a flash driver to the chip we are using (also not difficult).  I sent that driver to Mr. Sutter.
> 
> I haven't yet made calls to the MicroMonitor API from my RTEMS program (though I have from a program that doesn't include RTEMS).  What is the best place to call mon_connect from?  Is there a way to pass command line arguments from uMon into RTEMS?  Should bsp_cleanup call mon_appexit?  Thanks for any suggestions.  I hope to add conditional code to the 5272 BSP I am using (from Brett Swimley at Advanced Electronic Designs) that will make it interface cleanly with uMon (I plan to use at least the flash file system, TFS).
> 
> Steve
> 
> At 12:53 PM 2/2/2004 -0500, you wrote:
> >Pete,
> >[snip]
> >
> >However, just so you know, I have a port to a SunDevil card which is
> >based on a 5272 (contributed by Bill Knight), so it's probably not
> >a big deal to transition that over to your card.  I don't have
> >this target myself, but I have no reason to think it doesn't
> >work fine.
> >
> >Ed
> >
> >"D. Peter Siddons" wrote:
> >>
> >> Hi Ed,
> >>       Thanks for your response, also thanks to Leon Pollack for pointing
> >> me towards MicrMonitor.
> >>
> >> The target for my app is the Arcturus uCdimm-5272, which comes with its
> >> own rather limited monitor. I had shied away from replacing this with
> >> anything else. If nothing else there would be a learning curve plus the
> >> odd unbootable card :). It's somehow attractive to just take the
> >> commercial part as-delivered, program in the app and off you go. The
> >> ideal scenario would then be to have my files tacked on to the bootable
> >> RTEMS image and arrange so the app can read them (no writing or deleting
> >> needed). I wonder if one could use the IMFS for this? The task would
> >> then reduce to pre-formatting the info in the image to look like an IMFS
> >> filesystem, wouldn't it? Or am I misunderstanding something?
> >> Pete.
> >>
> >> Ed Sutter wrote:
> >> > Pete,
> >> > I run RTEMS with MicroMonitor underneath.  Provides an immediate
> >> > flash file system (read/write) for RTEMS-based applications.
> >> > If you're able to shift to MicroMonitor as your bootloader,
> >> > let me know and I'll be glad to give you details.
> >> > Ed Sutter
> >> >
> >> > "D. Peter Siddons" wrote:
> >> >
> >> >>Hi all,
> >> >>    I have an RTEMS application which resides in flash memory, and
> >> >>expects to read a configuration file at startup. It currently does this
> >> >>via tftp from a networked server, which works fine. I'd really like to
> >> >>make this thing stand-alone, so ideally it would read this information
> >> >>from some kind of local filesystem. There is enough capacity in the
> >> >>on-board flash memory if I could set up a filesystem in there; even more
> >> >>so if it could be compressed. It need only be read-only. Has anyone else
> >> >>done something similar? I've seen all the postings re compact flash, but
> >> >>I don't think that is at all the same.
> >> >>Thanks,
> >> >>Pete.
> >> >>
> >> >>--
> >> >>D. Peter Siddons
> >> >>Bldg. 725D, NSLS
> >> >>Brookhaven National Laboratory
> >> >>Upton, NY 11976
> >> >>USA.
> >> >>
> >> >>Email: siddons at bnl.gov
> >> >
> >> >
> >>
> >> --
> >> D. Peter Siddons
> >> Bldg. 725D, NSLS
> >> Brookhaven National Laboratory
> >> Upton, NY 11976
> >> USA.
> >>
> >> Email: siddons at bnl.gov
> 
> ---
> Steve Strobel                           WWW: http://www.link-comm.com
> Link Communications, Inc.               Phone: (406) 245-5002 ext 102
> MailTo:steve at link-comm.com              Fax: (406) 245-4889