RE: IDE-Harddiskdriver for MCUs

[joel@OARcorp.com]

On Tue, 8 Jun 1999, Peter Shoebridge wrote:

> Can you give any time scales as to when the current code will/may see the
> light of day. I'm working on file system stuff at the moment. I have an
> ATA/ATAPI driver plus drivers for FAT16/32 (read only at the moment) and
> ISO9660, plus a UDF driver in the works.

We are starting down a freeze path now for a public release.  I don't even
attempt to predict when that will result in a release since whatever I say
will undoubtedly be wrong.

There has been a lot of work since 4.0 -- remote debug server across
network, better C++ support including a port of OmniOrb, work on TAO, the
filesystem infrastructure, more POSIX support, an effort to reduce minimum
executable size, more use of automake, and a general movement to following
GNU Makefile conventions.  Basically the build issues need to settle.

> I had not really thought about donating them to the cause (so to speak) but
> that could be a possibility (although, I'd have concerns as to how general
> purpose they are - they work for me!, but, I suppose I wouldn't find out
> until I released them!!).
> 
> Your thoughts?

If you have used this code in any fashion and it works :), then
integrating it would be a welcome addition to RTEMS.  Real filesystems are
the logical next step.

--joel


> Peter Shoebridge
> 
> -----Original Message-----
> From:	owner-crossgcc@cygnus.com [mailto:owner-crossgcc@cygnus.com] On Behalf
> Of joel@OARcorp.com
> Sent:	Friday, June 04, 1999 1:51 PM
> To:	crossgcc@cygnus.com
> Subject:	Re: IDE-Harddiskdriver for MCUs
> 
> 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.
> _______________________________________________
> 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.