Re: IDE-Harddiskdriver for MCUs

[joel@OARcorp.com]

On Mon, 7 Jun 1999, Robert J. Brown wrote:

> >>>>> "joel" == joel  <joel@OARcorp.com> writes:
> 
>     joel> On Fri, 4 Jun 1999, Robert J. Brown wrote:
> 
>     >> I implemented a diskless filesystem last year for a project for
>     >> a client.  I did not have to write persistent data to the
>     >> filesystem -- only temporary data.  I also had the ability to
>     >> pre-load constant files at system build time.  The application
>     >> was an embedded webserver with CGI capability.  We talked about
>     >> adding tha ability to write flash at runtime, but there are
>     >> timing issues and interrupt latency problems when you do that,
>     >> and we might have missed an interrupt her or there.  :-(
> 
>     joel> One of the RTEMS uses has used the TFTP client filesystem to
>     joel> download a tar image of the initial filesystem contents for
>     joel> his RTEMS based web server. :)
> 
>     joel> Your setup sounds very similar to the RTEMS In-Memory File
>     joel> System (IMFS).  Our functionality goal for the IMFS may have
>     joel> been a bit higher though since one of its primary purposes
>     joel> was to fully exercise the filesystem infrastructure and
>     joel> POSIX 1003.1b functionality.  So it supports regular files,
>     joel> device files, directories (readdir family), symbolic links,
>     joel> permissions, etc..  We needed a filesystem that was easy to
>     joel> test the entire set of system calls with and IMFS was the
>     joel> result.
> 
> My diskless filesystem was just as minimal as I could get and still
> get the webserver to run.  I supported filenames with "/" in them like 
> any other character instead of a nested directory structure.  It was
> good enough to make the webserver work.  I only supported open for
> read, open for write, delete, and filesize operations, as that was all 
> I needed for the task at hand.

It's amazing how little it takes to actually get something useful. :)

The C library (especially newlib) is very nicely layered on top of a
handful of system calls.   

Since the IMFS was developed to test eveyr feature of the filesystem
infrastructure, it is probably much more full-featured than any embedded
system would actually require in a RAM based filesystem.  :)

> Because memory was tight (isn't it always?), I used a psuedo-sector
> pool and allocated sectors as needed to grow the file size.  I kept
> directory entries in their own seperate structure because it was
> simpler that way.  Number-of-sectors and bytes-per-sector were
> parameters that were tunable at build time, so once you knew the sizes 
> of the canned files and the amount of free space, you could optimize
> the space requirements pretty well.

The IMFS simply used malloc so does not have a Number-of-sectors but there
is a bytes-per-sector like build-time parameter.  I used it during testing
to run files out to the maximum size.  If I used a larger allocaiton unit
size, then I did not have enough physical memory to exercise the limits of
the file system.  Making the bytes-per-sector small meant that I quickly
hit the limits of the number of allowed sectors per file.

--joel
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985


_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.