file system

[Ed Sutter]

Greg,
Ok here goes...
To make a long story short, MicroMonitor (uMon) is a boot loader;
however, based on uMon's feature set, I tend to refer to it as an
embedded system platform.  I'm probably shooting myself in the foot
for making this comparison but, at a high level, you can compare it
to DOS/BIOS on a PC.  It provides a convenient means of getting
started and allows the application programmer to take a lot for
granted.  On top of DOS, the application programmer can add another
OS and that OS has the option of using the BIOS hooks to get to some
of the system periphery (console, file system, environment, heap, etc...)
or the OS can contain its own device drivers that sidestep the BIOS
hooks.

This is much the same principle that uMon has, but for embedded systems.
Replace the above use of "DOS" with "uMon", "OS" with "RTOS" and "BIOS"
with "uMon API", and the same applies to uMon on an embedded system.

In an RTEMS environment, the final executable (usually an elf file) simply
becomes an application that resides in the file system (TFS) provided by
uMon.  To get this to run in a uMon-based target, a simple hook function
(monConnect()) is called to initialize the uMon API accessible to the
RTEMS application.  For folks writing new BSPs, this is very useful because
you can use the monitor's debug facilities to get started, plus all of those
facilities remain target-resident, so they're not lost when you deploy a product.

For example, when I started with the powerpc port of RTEMS I was able to
immediately add mon_printf() calls to the initialization code way before the
uart drivers were up and running in RTEMS.  This is immediately useful, but
only the beginning.  Without any need for a debugger, uMon supports symbolic
access to global variables, plus if the system crashes, the core is observable
from the uMON prompt.  This includes a stack trace in most cases.

Plus, for file system access, there's nothing to do if you choose to...
The uMon API provides all the hooks you need to add/delete/modify files in
the flash.  I also have a basic set of newlib hooks for applications to hook
up to uMon so that calls like fprintf, fopen, getenv, etc... use the underlying
uMon facilities.

Anyway, IMHO, the uMon/RTEMS combination is a good one.  If there are any
specific questions.  Please don't hesitate to ask.

Hope this helps.
Ed Sutter

PS...
I am working with folks at Microcross (microcross.com) to put together a 
MicroMonitor training manual.  Meanwhile, there is a lot of uMon-related
stuff at their site that you can download...
http://www.microcross.com/html/micromonitor.html

gregory.menke at gsfc.nasa.gov wrote:
> 
> I'd like some details about Micromonitor too- we have a similar need
> at the moment.
> 
> Thanks,
> 
> Gregm
> 
> Ed Sutter writes:
>  > 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
>  >
>  >