Prev: Link&Locate 86?
Next: MSP430 and Linux
From: rickman on 5 Sep 2006 21:49 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 5 Sep 2006 22:14 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 5 Sep 2006 23:55 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 6 Sep 2006 00:29 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 6 Sep 2006 01:14
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. |