David Smead wrote:
> I downloaded the IBM application guide for the micro-drive. It will work
> in PC Card Mode or True IDE. -OE gets grounded for IDE, and is the output
> enable otherwise.
> You can save a few pins with the IDE mode, but that might come back to
> haunt you later.
> I'm studying the CF spec and IBM details now since I too plan to use it.
> I finally dug through old boxes for my 1994 schematic of 68341 interface
> to an IDE drive. I'm not ready yet to guess what bus pins and what port
> pins will be required for memory mode, however.
> David Smead
> On Fri, 6 Oct 2000, Tom Walsh wrote:
> > Sebastian Andersson wrote:
> > >
> > > On Fri, Oct 06, 2000 at 11:08:19AM -0400, Tom Walsh wrote:
> > > > Glenn,
> > > >
> > > > Seems like we both need the same thing, a working CF drive system. I
> > > > am curious as to why you are going with the True IDE mode as opposed to
> > > > the Memory Mapped mode of the CF? Have you looked into the IDE drive
> > > > code under uClinux, how big a job will it be to rewrite the ide.c stuff?
> > >
> > > Is Memory Mapped Mode supported by real CF harddrives like IBMs
> > > small 1GB drive?
> > Well, I cannot answer for IBM, but according to the Compact Flash
> > Association "CF+ and Compact Flash Specification, Version 1.4", it says
> > that the CF can operate in one of three modes: I/O Mapped, Memory
> > Mapped, or True IDE.
> > >
> > > We choose True IDE Mode in a custom hardware device of ours so we
> > > could reuse the design/code if we wanted to add a real HD via an IDE
> > > cable.
> > >
> > Oh, I agree totally, but on the performance of the DragonBall processor
> > is so low that adding a "real" IDE drive to the system may make it drop
> > significantly if you add in the access delays of the drive mechanicals.
> > I don't see the addition of a "real" hard drive being an actual benefit,
> > on an ARM system, yes, the system performance is such that you can take
> > advantage of large data storage arrays.
> > One drawback to using the Compact Flash in the True IDE mode is that
> > mode of operation is NOT supported / implemented in the CF+ cards
> > (according to the spec it is optional). My main reason for selecting CF
> > memory is that it is available at any photo store. What bothers me is
> > the Lexar Media device that I purchased locally says it is "CompactFlash
> > (TM)" but the back of the device it has the CF+ symbol, I find that
> > disturbing, it would suggest that we would have to be carefull about
> > what devices / manufacturers we can use (in True IDE mode). I suggest
> > that the "lowest common denominator" is the better approch (I/O or
> > Memory Mapping modes), unless there are compelling reasons???
> > My idea is that the "sectors" are still accessable in Memory Map mode, I
> > am thinking of running the device as such and hacking the ide.c to
> > interface to the device in that mode. Another problem with True IDE
> > mode is that you have to add additional circuitry to 'power cycle' the
> > CF into the IDE mode.
Agreed. What I want (need) is something that I can offer as a solution
to a customer who would like to use the Compact Flash to possibly dump
data to "device" and archive it. If I use the True IDE mode, and you
know customers, they are clueless as to technology(!!!!), this guy goes
to Walmart to purchase another compact flash and that one doesn't have
the IDE mode ('cause it is CF+ spec'ed), who gets the blame? It is okay
for a hobbist to have a 'cool thing' but deadly if the clueless user
fails to get it to work!
-- Tom Walsh - WN3L - Embedded Systems Consultant 'www.openhardware.net', 'www.cyberiansoftware.com' "Windows? No thanks, I have work to do..." This message resent by the firstname.lastname@example.org list server http://www.uClinux.com/
This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:38 EST