Compact Flash use.

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.

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

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

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.

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

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

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

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:

.../...

SPI-4.2 has nothing to do Motorola's SPI (Serial Peripheral Interface) being mentioned in this thread. For more on SPI-4.2 (System Packet Interface):

Rich

"Rich" schrieb im Newsbeitrag news: snipped-for-privacy@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

that

speed

What I always have failed to see is how do you separate the from eachother with only these three wires?

Meindert

"Meindert Sprang" schrieb im Newsbeitrag news:3fe843bc$ snipped-for-privacy@news.nb.nu...

protocol.

That's a good question. How to synchronize multiple ? 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

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.

(I'm not working for amazon)

MIKE

You count the bits.

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

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

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

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

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