From: rickman on
Jim Stewart wrote:
> rickman wrote:
> > I searched this group and could not find much on an actual spec for the
> > SPI bus. I know that this bus is very loose. One of my coworkers
> > refers to it as a non-standard standard. But I will be doing some
> > strange things to a couple of SPI bus interfaces to pass them through a
> > cable using fewer pins than otherwise required and the relative timing
> > will be delayed by up to a uS or so. The bus will be running with a
> > 101 kHz clock so I expect this will work, but I wanted to find some
> > timing data on the bus.
> >
> > I did find a Freescale doc that shows the clock phasing an polarity,
> > but no timing requirements. I guess it is up to the engineer to verify
> > the low level timing of the various devices on the bus?
> >
> > I could not find anything on timing at the Freescale site.
>
> You never really asked a question so I'm not
> sure whether you're interested in a reply.
>
> In any case, I've had much the same experience.
> There doen't seem to be anything like a formal
> published specification. I've had to analyze
> each implementation I've done.

Yes, sorry I forgot the question. I am looking for timing specs on the
bus.

I know that the devices clock data out on one clock edge and in on the
other. But I don't know how much time is allowed for the output to
settle and setup on the input. So I don't know how much time can be
budgeted to the multiplexer function. With a 10 us bit time I expect
it will be no real problem if I jitter the signal edges by 1 or 2 us.

I was thinking of capturing the parallel data in a register and
shifting it out to the other side and then clocking it into an output
register. But this takes a lot more resources and it is not at all
clear to me that this will work better. Just because of the issues of
metastability even this approach can change the relative timing of any
two signals by 1 us. So I think I will take the easy approach and not
latch the inputs and let the outputs update sequentially on the fly
rather than simultaneously.

Even if it is just for our project, there really needs to be a timing
spec just to make sure we are all on the same page.

From: rickman on
Donald wrote:
> Most chips that have an SPI port will define its version in their data
> sheet.
>
> This site is as generic as it can get.
>
> http://elm-chan.org/docs/spi_e.html

Thanks, I think the answer to the question I didn't ask is that there
is no spec. It is up to the designer to allocate timing margins based
on the chips they are using. I don't know the chips at the other end
of this interface (actually either end), but the timing is very
generous so I will just assume that I have timing margin to spare. I
am also going to assume that it does not matter if I introduce +-1 us
of relative jitter in the signals on the bus. Since the data is
clocked out on one edge and in on the other, this will not cause any
signals to cross a critical timing boundary.

I do remember seeing a timing spec on the SPI bus that showed some
nominal amount of output delay and input setup. But I can't find that
again for the life of me.

From: Neil on
rickman wrote:
> I searched this group and could not find much on an actual spec for the
> SPI bus. I know that this bus is very loose. One of my coworkers
> refers to it as a non-standard standard. But I will be doing some
> strange things to a couple of SPI bus interfaces to pass them through a
> cable using fewer pins than otherwise required and the relative timing
> will be delayed by up to a uS or so. The bus will be running with a
> 101 kHz clock so I expect this will work, but I wanted to find some
> timing data on the bus.
>
> I did find a Freescale doc that shows the clock phasing an polarity,
> but no timing requirements. I guess it is up to the engineer to verify
> the low level timing of the various devices on the bus?
>
> I could not find anything on timing at the Freescale site.
>

Since there are several SPI schemes there is not one answer.
The chips have the timing diagrams. You need to data sheets for the
chips you are talking to.
Note that many A2Ds use the clock for the conversion. It may need to be
uniform.
From: Dan Henry on
On 5 Sep 2006 19:14:25 -0700, "rickman" <gnuarm(a)gmail.com> wrote:

>Donald wrote:
>> Most chips that have an SPI port will define its version in their data
>> sheet.
>>
>> This site is as generic as it can get.
>>
>> http://elm-chan.org/docs/spi_e.html
>
>Thanks, I think the answer to the question I didn't ask is that there
>is no spec.

I recall "The Specification" being the "Synchronous Serial Peripheral
Interface" section in what was known (in the '80s?) as the "Pink
Book"; that is, the M68HC11 Reference Manual in which SPI was
(presumably) first introduced. No longer pink, the most recent
version I know of is available as:

http://www.freescale.com/files/microcontrollers/doc/ref_manual/M68HC11RM.pdf

Still, it does not have the timing information you seek.

>It is up to the designer to allocate timing margins based
>on the chips they are using.

Yep.

>I don't know the chips at the other end
>of this interface (actually either end), but the timing is very
>generous so I will just assume that I have timing margin to spare. I
>am also going to assume that it does not matter if I introduce +-1 us
>of relative jitter in the signals on the bus. Since the data is
>clocked out on one edge and in on the other, this will not cause any
>signals to cross a critical timing boundary.

Setup and hold times along with maximum clock rate are the important
things, I think.

>I do remember seeing a timing spec on the SPI bus that showed some
>nominal amount of output delay and input setup. But I can't find that
>again for the life of me.

--
Dan Henry
From: Wulf on
On 5 Sep 2006 09:51:42 -0700, "rickman" <gnuarm(a)gmail.com> wrote:

>I searched this group and could not find much on an actual spec for the
>SPI bus. I know that this bus is very loose. One of my coworkers
>refers to it as a non-standard standard. But I will be doing some
>strange things to a couple of SPI bus interfaces to pass them through a
>cable using fewer pins than otherwise required and the relative timing
>will be delayed by up to a uS or so. The bus will be running with a
>101 kHz clock so I expect this will work, but I wanted to find some
>timing data on the bus.
>
>I did find a Freescale doc that shows the clock phasing an polarity,
>but no timing requirements. I guess it is up to the engineer to verify
>the low level timing of the various devices on the bus?
>
>I could not find anything on timing at the Freescale site.


The SPI is relatively easy. I've done several. Both bit-banged out and
hardware dedicated on uP's . Just check your timing diagrams for both
the source and destination. I've always used the CPU as master. Also,
make sure to not violate any setup and hold times as well. At 100kHz
it should be a breeze :) .

If you want more information you will have to provide details on what
you are talking about as far as "fewer pins", SPI doesn't have that
many pins.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Link&Locate 86?
Next: MSP430 and Linux