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:
> A couple of things -- again it depends on the application
.../...
> If you have high bandwidth needs than a parallel approach is the ticket
> such as with CF (ATA/IDE)...

In article <bs80mo$a8ljr$2...@ID-188203.news.uni-berlin.de>, 
t...@gmx.de says...
> 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
> 
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):
http://www.xilinx.com/ipcenter/posphyl4/PL4sellsheet.pdf

Rich

"Rich" <***r...@dwave.net***> schrieb im Newsbeitrag
news:M...@news.visi.com...
> In article <bs80mo$a8ljr$2...@ID-188203.news.uni-berlin.de>,
> t...@gmx.de says...
> > 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
> >
> 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):
> http://www.xilinx.com/ipcenter/posphyl4/PL4sellsheet.pdf
>
> Rich

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" <t...@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.
> 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.

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" <m...@NOcustomSPAMware.nl> schrieb im Newsbeitrag
news:3fe843bc$1...@news.nb.nu...
> "M.Randelzhofer" <t...@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.
> > 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.
>
> What I always have failed to see is how do you separate the
> <bytes|words|whatever> from eachother with only these three wires?
>
> Meindert
>
>

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/detail/-/020142293X/qid=1072188492//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 <m...@NOcustomSPAMware.nl> wrote:

> What I always have failed to see is how do you separate the
><bytes|words|whatever> from eachother with only these three wires?

You count the bits.

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

On 2003-12-23, Grant Edwards <g...@visi.com> wrote:
> On 2003-12-23, Meindert Sprang <m...@NOcustomSPAMware.nl> wrote:
>
>> What I always have failed to see is how do you separate the
>><bytes|words|whatever> from eachother with only these three wires?
>
> You count the bits.

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" <t...@gmx.de> 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).

>That's why SPI-4.2 is only used with 622 to 800 megabits per second...
>(bundled up to 10Gbits)
>See Xilinx app notes.

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" <t...@gmx.de> writes:

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

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.

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

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" <m...@NOcustomSPAMware.nl> writes:

>What I always have failed to see is how do you separate the
><bytes|words|whatever> from eachother with only these three wires?

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!