EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

Compact Flash Interfacing

Started by Al Clark April 10, 2004
I am working on a compact flash design that will support Memory mode and 
I/O Mode but not True IDE Mode. The interface will be 16 bits only.

I can't see a compelling reason not to tie A0 & A5-A8 low. A9 is used in 
Attribute Memory. I have connections to REG, A10, A9, A4-A1.

Starting with the Memory Mode interface, I added IORD & IOWR to support I/O 
Mode. I ignore IOCS since all interfacing is 16 bits in my design.

Both CE lines are tied together.

Am I missing something?


-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
comp.dsp conference July 28 - Aug 1, 2004

details at http://www.danvillesignal.com/index.php?id=compdsp
email: compdsp@danvillesignal.com

Who says you can't teach an old dog a new DSP trick?
Al Clark <dsp@danvillesignal.com> wrote in message news:<Xns94C77CF238835aclarkdanvillesignal@66.133.130.30>...
> I am working on a compact flash design that will support Memory mode and > I/O Mode but not True IDE Mode. The interface will be 16 bits only. > > I can't see a compelling reason not to tie A0 & A5-A8 low. A9 is used in > Attribute Memory. I have connections to REG, A10, A9, A4-A1.
Depends on what CFs you are going to use it for. If you use networking types (ethernet/WiFi), you will need all address pins to get to the frame buffer. If you use I/O types (GPS, etc.), the lines you mentioned are good enough and 8 bits are just as good.
> > Starting with the Memory Mode interface, I added IORD & IOWR to support I/O > Mode. I ignore IOCS since all interfacing is 16 bits in my design. > > Both CE lines are tied together. > > Am I missing something?
For what?
> > > -- > Al Clark > Danville Signal Processing, Inc. > -------------------------------------------------------------------- > comp.dsp conference July 28 - Aug 1, 2004 > > details at http://www.danvillesignal.com/index.php?id=compdsp > email: compdsp@danvillesignal.com > > Who says you can't teach an old dog a new DSP trick?
tech@ide-cf.info-for.us (Tech Support for IDE-CF) wrote in
news:ec089244.0404101526.266c595b@posting.google.com: 

> Al Clark <dsp@danvillesignal.com> wrote in message > news:<Xns94C77CF238835aclarkdanvillesignal@66.133.130.30>... >> I am working on a compact flash design that will support Memory mode >> and I/O Mode but not True IDE Mode. The interface will be 16 bits >> only. >> >> I can't see a compelling reason not to tie A0 & A5-A8 low. A9 is used >> in Attribute Memory. I have connections to REG, A10, A9, A4-A1. > > Depends on what CFs you are going to use it for. If you use > networking types (ethernet/WiFi), you will need all address pins to > get to the frame buffer. If you use I/O types (GPS, etc.), the lines > you mentioned are good enough and 8 bits are just as good.
Thank you. I added I/O Mode so that I might be able to add an 802.11 card later. I'll add the additional lines. They already exist in my pld interface but I may need additional buffers for hot swapping. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- comp.dsp conference July 28 - Aug 1, 2004 details at http://www.danvillesignal.com/index.php?id=compdsp email: compdsp@danvillesignal.com Who says you can't teach an old dog a new DSP trick?
> >> >> Starting with the Memory Mode interface, I added IORD & IOWR to >> support I/O Mode. I ignore IOCS since all interfacing is 16 bits in >> my design. >> >> Both CE lines are tied together. >> >> Am I missing something? > > For what? > >> >> >> -- >> Al Clark >> Danville Signal Processing, Inc. >> -------------------------------------------------------------------- >> comp.dsp conference July 28 - Aug 1, 2004 >> >> details at http://www.danvillesignal.com/index.php?id=compdsp >> email: compdsp@danvillesignal.com >> >> Who says you can't teach an old dog a new DSP trick? >
Hi Everyone,

I will start a similar project. But haven' made up my mind about using
CF or SD cards.

Host processor will be the Motorola MPC565 powerpc. I'm getting the
big picture eabout using FAT ,ATA mode and intefacing to use.

But i'm still wondering about the hardware interfacing:

Should i use tri-state buffers between my adres/Data-bus and the card
?(Or between the SPI port in case of the SD card)

If so, how should i enable these buffers ? Wha type should these be.

What happens when you plug out a card ? Should there be a recovery
mechanism be implemented when this happens ?

Thanks to all.

Stijn

Jon S. wrote:

> Hi Everyone, > > I will start a similar project. But haven' made up my mind about using > CF or SD cards. > > Host processor will be the Motorola MPC565 powerpc. I'm getting the > big picture eabout using FAT ,ATA mode and intefacing to use. > > But i'm still wondering about the hardware interfacing: >
The hardware interfacing is just as its been described.
> Should i use tri-state buffers between my adres/Data-bus and the card > ?(Or between the SPI port in case of the SD card)
If any chip is on the A/D buss, would you remove it with power applied ??
> > If so, how should i enable these buffers ? Wha type should these be.
They are just chips on the A/D buss. How are you doing that now ?? Flash chips, memory chips, I/O chips .... Just be sure the tri-state chips have a in-line resistor to prevent static on the CF/SD pins don't crash your system.
> > What happens when you plug out a card ? Should there be a recovery > mechanism be implemented when this happens ? >
This is the hard part. This is also a software problem. On an old DOS machine ( or any computer for that matter) What would happen to your files if you removed the media. ( floppy for example) The next time you go to read/write that media, you may very well have corrupt files. ( FAT table corruption, cross linked files, all kind of nasty problems ) The same problem would accure if power on the system is lost, when files are open.
> Thanks to all. > > Stijn
Good Luck hamilton
hamilton <hamilton@deminsional.com> wrote in news:4079327c$1_4
@omega.dimensional.com:

> > > Jon S. wrote: > >> Hi Everyone, >> >> I will start a similar project. But haven' made up my mind about using >> CF or SD cards. >> >> Host processor will be the Motorola MPC565 powerpc. I'm getting the >> big picture eabout using FAT ,ATA mode and intefacing to use. >> >> But i'm still wondering about the hardware interfacing: >> > The hardware interfacing is just as its been described. > >> Should i use tri-state buffers between my adres/Data-bus and the card >> ?(Or between the SPI port in case of the SD card) > > If any chip is on the A/D buss, would you remove it with power applied
??
> >> >> If so, how should i enable these buffers ? Wha type should these be. > > They are just chips on the A/D buss. How are you doing that now ?? > Flash chips, memory chips, I/O chips .... > Just be sure the tri-state chips have a in-line resistor to prevent > static on the CF/SD pins don't crash your system. >> >> What happens when you plug out a card ? Should there be a recovery >> mechanism be implemented when this happens ? >> >
My design uses 743384 buffers to isolate the CF from the rest of the system. The only lines that connect directly to the host are current limited lines (499 ohm series R with pullup) connected to the CD lines. After CD is true, I power up the CF card via a hot swap power controller and then I enable the buffers. Its interesting how most of the ap notes ignore hot-swapping issues even though I think most users are going to expect that the cards work this way. I expect they do this mostly so that their designs look less complex. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- comp.dsp conference July 28 - Aug 1, 2004 details at http://www.danvillesignal.com/index.php?id=compdsp email: compdsp@danvillesignal.com Who says you can't teach an old dog a new DSP trick?
jonsquire2000@hotmail.com (Jon S.) wrote in message news:<f0ae8fc3.0404110217.5220a74a@posting.google.com>...
> Hi Everyone, > > I will start a similar project. But haven' made up my mind about using > CF or SD cards. > > Host processor will be the Motorola MPC565 powerpc. I'm getting the > big picture eabout using FAT ,ATA mode and intefacing to use.
If you are using it as storage device, ATA mode is the best in performance and easiest to implement. You need a lot of bit banging SD cards.
> > But i'm still wondering about the hardware interfacing: > > Should i use tri-state buffers between my adres/Data-bus and the card > ?(Or between the SPI port in case of the SD card)
Only if you have many devices on the bus and you need better signal drivers. Otherwise, CS & CE are good enough logically.
> > If so, how should i enable these buffers ? Wha type should these be.
Bi-directional '245, I guess.
> > What happens when you plug out a card ? Should there be a recovery > mechanism be implemented when this happens ?
Not with ATA CF, you can't hotplug it anyway. With SD cards, you have to implement much of the controller firmware. So, it would be up to you to keep track of the media changes.
> > Thanks to all. > > Stijn

Al Clark wrote:
> > My design uses 743384 buffers to isolate the CF from the rest of the > system. The only lines that connect directly to the host are current > limited lines (499 ohm series R with pullup) connected to the CD lines.
I did a google search for "743384" but got no hits. What is "743384" ???
> > After CD is true, I power up the CF card via a hot swap power controller > and then I enable the buffers. > > Its interesting how most of the ap notes ignore hot-swapping issues even > though I think most users are going to expect that the cards work this > way. I expect they do this mostly so that their designs look less > complex. >
On Sunday, in article <407982aa$1_4@omega.dimensional.com>
     hamilton@deminsional.com "hamilton" wrote:
>Al Clark wrote: >> >> My design uses 743384 buffers to isolate the CF from the rest of the >> system. The only lines that connect directly to the host are current >> limited lines (499 ohm series R with pullup) connected to the CD lines. > >I did a google search for "743384" but got no hits. > >What is "743384" ???
If it is parts I have used in the past they are from TI and from memory 74CBT3384 octal Level translators, especially useful for 5V to 3V translation. Saved a lot of power on heat on some designs for me as the data path was 50 bits wide and 40MHz. next stage would have used a lot of current on its 5V tolerant inputs. ... -- Paul Carpenter | paul@pcserv.demon.co.uk <http://www.pcserv.demon.co.uk/> Main Site <http://www.gnuh8.org.uk/> GNU H8 & mailing list info. <http://www.badweb.org.uk/> For those web sites you hate.
paul$@pcserv.demon.co.uk (Paul Carpenter) wrote in
news:20040411.2106.298055snz@pcserv.demon.co.uk: 

> On Sunday, in article <407982aa$1_4@omega.dimensional.com> > hamilton@deminsional.com "hamilton" wrote: >>Al Clark wrote: >>> >>> My design uses 743384 buffers to isolate the CF from the rest of the >>> system. The only lines that connect directly to the host are current >>> limited lines (499 ohm series R with pullup) connected to the CD >>> lines. >> >>I did a google search for "743384" but got no hits. >> >>What is "743384" ??? > > If it is parts I have used in the past they are from TI and from > memory 74CBT3384 octal Level translators, especially useful for 5V to > 3V translation. Saved a lot of power on heat on some designs for me as > the data path was 50 bits wide and 40MHz. next stage would have used a > lot of current on its 5V tolerant inputs. > > ... >
I use SN74CBTS3384DBR from TI. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- comp.dsp conference July 28 - Aug 1, 2004 details at http://www.danvillesignal.com/index.php?id=compdsp email: compdsp@danvillesignal.com Who says you can't teach an old dog a new DSP trick?

The 2024 Embedded Online Conference