Re: IDE-Harddiskdriver for MCUs

[joel@OARcorp.com]

On Fri, 4 Jun 1999, Peter Shoebridge wrote:

> How does one get access to the current RTEMS development tree?

By being a contributor (either financially or technically) to the RTEMS
Project. :)

The development tree varies widely in stability (mostly from a build
standpoint) from day to day and the intent it to minimize the number of
people who could be impacted by it.  Wide access to snapshots has serious
implications to us.  We (being the RTEMS development team in the broadest
sense) do not want to think someone fielded a system based on a random
RTEMS snapshot.

--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


> Peter
> 
> ----- Original Message -----
> From: <joel@OARcorp.com>
> To: <crossgcc@cygnus.com>
> Sent: Friday, June 04, 1999 10:12 AM
> Subject: Re: IDE-Harddiskdriver for MCUs
> 
> 
> >
> > On Fri, 4 Jun 1999, Kai Schaeffer wrote:
> >
> > > in a project I plan to connect a Flash memory card to a microcontroler
> > > (68376). The Flash-card have an IDE-connector and it seems to me it is
> not
> > > very difficult to connect it to a MCU. It is also not a big problem to
> > > write a software which read/write some sectors from the Flashcards (or
> > > Harddisk!). It is an other thing to implement a filesystem. But I think
> > > there exists the following:
> > >
> > > 1. The glibc for my MCU with everything I need execpt the low level
> routines.
> > > 2. The source code of Linux with well implemented VFAT/FAT-Driver.
> > >
> > > So the question is, if it is possible to adapt the Linux-drivers to use
> > > them in an embedded application. I am sure it is very usefull for many
> > > people to have a real harddisk/filesystem in there embedded systems.
> >
> > Anything is possible given enough time and money. :)
> >
> > Seriously, you would need to provide an adaption layer to glue the Linux
> > code to whatever RTOS structure you end up with.  It would be a more
> > profitable investment of effort to provide the glue that would let
> > multiple Linux filesystems and device drivers work largely unchanged than
> > to hack working code mercilessly to fit it into your system.  Plus leaving
> > the original code intact as much as possible eases merging future
> > upgrades to the original source.
> >
> > Another issue to consider is the memory requirements of the code you are
> > moving.  On any embedded system, you have memory constrants that were
> > probably not a design consideration on the code you are moving from UNIX.
> >
> > > So the first question is, if there is already a solution for this
> > > problem?! If not, the other questions are:
> > >
> > > 1. Are there other persons who thinks it is interesting and usefull?
> >
> > Since we implemented much of this for RTEMS, I would have to say yes.
> >
> > > 2. Are there other persons who can help to realize this idea?
> >
> > FWIW the current RTEMS development tree has all the infrastructure to plug
> > filesystems into.  We have currently only implemented two filesystems: an
> > "In-Memory File System" (IMFS) which is totally in RAM and a TFTP
> > filesystem which is a filesystem interface to a TFTP client.
> >
> > To implement a non-volatile filesystem, you would need the Flash or disk
> > device driver and the filesystem manager that organizes the blocks.
> >
> > This avoids more effort than you think.   There is a significant amount of
> > work to implement all the system calls that a C library requires and to
> > implement the filesystem infrastructure to get mounts.
> >
> > Does this sound like it is going where you are thinking of?
> >
> > --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.
> >
> 
> _______________________________________________
> 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.
> 

_______________________________________________
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.