Dear all,

Can anyone point me to details on using CF cards? I haven't found much
so far...

I'd like to use some kind of large (32MB or more) nv memory in my
embedded system. Is CF a good choice? If not then what is?

Wlad

On Fri, 19 Dec 2003 19:04:17 +0100, Wlad <whanski@wp.pl> wrote:

It may or may not be. What does your system want to do?

The main limitation for CF is that it is flash -- you can't write
flash over and over again without it failing eventually.

As for using them, there are multiple ways to access CF. Hit
CompactFlash.org and you can download the specs.
--
Alex Pavloff - remove BLAH to email
Software Engineer, ESA Technology

Wlad <whanski@wp.pl> wrote in message news:<3FE33DA0.4030300@wp.pl>...
In true ATA mode, same as using an IDE hard disk.
In memory mode, same as using paged memory.

If your system can handle IDE drives, then CF is the best choice.

IDE Compact Flash Drive at http://ide-cf.info-for.us

Tech Support for IDE-CF wrote:

What a weird website.

Depends. If you expect to

- want more memory, or
- produce small quantities, or
- have your product still produced in a few years

then CF certainly is a wise choice.

Otherwise you may jump on the cellular phone waggon and choose
whatever chip they currently use. Today, most have 4-8 MB ('320/640).
Sharps LRS1395A for example is a dual-die MCP (16MB total). Using
two of them is certainly cheaper than a CF + socket. But be careful,
once the cellur phone industry doesn't want this chip anymore, it
will probably disappear in no time.

Marc

Wlad wrote:
Depends on your embedded system -- For example if your using a Motorola
Processor you may consider MMC or SD Flash memory as both support the
serial SPI interface -- an interface found in many Motorola Processors.

JoeG <JoeG@yahoo.com> writes:

Using SPI is definitely a bad choice when you are thinking of mass
data transfers. On some devices (like MPC8xx) the SPI interface is
awfully slow. Even Motorola says: "SPI was not designed to be a high-
bandwidth channel." (see FAQ-10335).

Best regards,

Wolfgang Denk

--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Web: www.denx.de
How does a project get to be a year late? ... One day at a time.

"Wolfgang Denk" <wd@denx.muc.de> schrieb im Newsbeitrag
news:HqBEv5.Jw9.3.diddl.denx@denx.muc.de...
That's why SPI-4.2 is only used with 622 to 800 megabits per second...
(bundled up to 10Gbits)
See Xilinx app notes.

MIKE

M.Randelzhofer wrote:

A couple of things -- again it depends on the application -- if the
Memory is only going to be used for configuration with some minor
read/writes -- SPI is fine. After all, MMC and SD have SPI.

If you have high bandwidth needs than a parallel approach is the ticket
such as with CF (ATA/IDE)...

In article <jaQFb.1140$2X.778@newssvr27.news.prodigy.com>, JoeG wrote:
The CF is faster, but the memory cycles are slow when compared to modern
microcontrollers. You may need lots of wait cycles (20 or 100 even), which
slows down your MCU. Interfacing CF to an MCU with no built-in CF support
may require some glue logic (for timing, address decodign and control signal
generation). Also, many CF cards are slow writing data (100...200
kilobytes/s). But I still use CF cards.. ;-)

-jm

Hi !

With our design (MPC 8xx at 66 Mhz), we use a Compact Flash
throught an ATA driver and a FAT16 file system. It's a very
cheap and easy-to-use solution for embedded design, and it's
quite fast (4000 kilobyte/sec when reading files, and very
low access time).

The main drawback is the file system coherency when the system
is shutting down : you need a small amount of time to sync
the data. FAT16 is probably not the best file system in
this point of view.

Regards
Emmanuel

JoeG wrote:

In article <bs80mo$a8ljr$2@ID-188203.news.uni-berlin.de>,
techseller@gmx.de says...
being mentioned in this thread.
For more on SPI-4.2 (System Packet Interface):
http://www.xilinx.com/ipcenter/posph...4sellsheet.pdf

Rich

"Rich" <***rich@dwave.net***> schrieb im Newsbeitrag
news:MPG.1a51b9fcf610873a989681@news.visi.com...
The original SPI definition from Motorola is very slim and only hardware.
There is a clock, a data send and a data receive line. This implies
concurrent sending and receiving. And also the extra clock line implies that
there is no clock information on the data lines. Nothing about a protocol.
This simple scheme is an invitation to simple, efficient and very high speed
data transfers at the cost of 3 separate wires (which should be differential
like LVDS in very high speed apps).
And of course, SPI also works for relatively slow microcontroller ports.

MIKE

"M.Randelzhofer" <techseller@gmx.de> wrote in message
news:bs9dpv$aqjnu$1@ID-188203.news.uni-> The original SPI definition from
Motorola is very slim and only hardware.
What I always have failed to see is how do you separate the
<bytes|words|whatever> from eachother with only these three wires?

Meindert

"Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> schrieb im Newsbeitrag
news:3fe843bc$1@news.nb.nu...
That's a good question. How to synchronize multiple <bytes|words|whatever> ?
It depends on the protocol.
It's the stuff which is not as simple as the hardware SPI definition.
One important issue is, that there is no standard protocol defined.
Almost every SPI chip uses a different approach.

The easiest way is to spent another wire as a "chip select".
Lots of ADC and DAC companies do that.
See
http://www.national.com/pf/AD/ADC0831.html
as an example. National name for SPI is microwire.

Another method is to use an unique serial pattern on the data lines, to
distiguish between the "address" and the "data" information.

If you are interested in these networking details, i can recommend the
following book:

FRED HALSALL
DATA COMMUNICATIONS, COMPUTER NETWORKS and OPEN SYSTEMS.
http://www.amazon.com/exec/obidos/tg...072188492//ref
=sr_8_xs_ap_i0_xgl14/002-4063803-2561624?v=glance&s=books&n=507846

(I'm not working for amazon)

MIKE

On 2003-12-23, Meindert Sprang <mhsprang@NOcustomSPAMware.nl> wrote:

You count the bits.

--
Grant Edwards grante Yow! .. I'll make you
at an ASHTRAY!!
visi.com

On 2003-12-23, Grant Edwards <grante@visi.com> wrote:
I should have mentioned that the point in time where you start
(or stop) counting the bits is generally defined by a fourth
wire (chip select):

1) Assert chip select
2) Shift some data in/out
3) Deassert chip select

--
Grant Edwards grante Yow! Do you have exactly
at what I want in a plaid
visi.com poindexter bar bat??

"M.Randelzhofer" <techseller@gmx.de> writes:

You never used a MPC8xx before, did you?

Getting a sustained rate of 3...4 megabits per second might become a
major problem.

Best regards,

Wolfgang Denk

--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Web: www.denx.de
"All my life I wanted to be someone; I guess I should have been more
specific." - Jane Wagner

"M.Randelzhofer" <techseller@gmx.de> writes:

Right, and it is missing things like if there is a framesync signal
or not, which may make interfacing devices a problem if one requires
a framesync which the other does not provide.

There may be efficient implementations of SPI (like on some TI DSPs)
....except that on the MPC8xx Motorola implements SPI in microcode,
running at the lowest priority on a fully loaded CPM :-(

Best regards,

Wolfgang Denk

--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Web: www.denx.de
Every solution breeds new problems.

"Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> writes:

It depends - some devices provide / require a separate "framesync"
signal; otherwise you will address a device on the bus, and start
transmitting. The device is expected to count the bits. When the
message is complete, you deselect the device. Device addressing and
selection is not standardized.

Best regards,

Wolfgang Denk

--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Web: www.denx.de
EMACS belongs in <sys/errno.h>: Editor too big!