SPI Bus Specification
in [Embedded]
|
Prev: Link&Locate 86?
Next: MSP430 and Linux
From: Alf Katz on 6 Sep 2006 06:18 "rickman" <gnuarm(a)gmail.com> wrote in message news:1157507358.338962.101330(a)m79g2000cwm.googlegroups.com... > > Yes, sorry I forgot the question. I am looking for timing specs on the > bus. > Yepp, as you've alluded to elsewhere, there is no timing spec for the bus. This is determined entirely by the devices at either end. Some devices can only run at 100kbaud or so, while others run at faster than 80Mbaud. Asking for a generic timing spec is a bit like asking for a single timing spec for microprocessor parallel busses. Cheers, Alf
From: rickman on 6 Sep 2006 07:50 Wulf wrote: > 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 :) . Ay, there's the rub! I don't have info on the source or destination. I am just a middle man. But with a 100 kHz bus clock, I am pretty confident that this will work. Someone cautioned me that if the jitter swaps the edges of clock and data it could be a problem. But I think this is not true unless you cause an edge to move a half clock cycle. I don't see how it can matter if the data changes slightly before the active edge of the clock (instead of after) since the active edge for the receiver is the other edge. > 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. I am not asking for help with the logical design. I am looking for timing information so I can determine how much slack there is in the system I am working with. Obviously there is no bus level spec on the timing. Rather it is up to each designer to assure that his use of different devices is compatible.
From: PeteS on 6 Sep 2006 08:24 rickman wrote: > Wulf wrote: > > 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 :) . > > Ay, there's the rub! I don't have info on the source or destination. > I am just a middle man. But with a 100 kHz bus clock, I am pretty > confident that this will work. Someone cautioned me that if the jitter > swaps the edges of clock and data it could be a problem. But I think > this is not true unless you cause an edge to move a half clock cycle. > I don't see how it can matter if the data changes slightly before the > active edge of the clock (instead of after) since the active edge for > the receiver is the other edge. > > > > 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. > > I am not asking for help with the logical design. I am looking for > timing information so I can determine how much slack there is in the > system I am working with. Obviously there is no bus level spec on the > timing. Rather it is up to each designer to assure that his use of > different devices is compatible. As you don't know what devices you are working with, then be very careful not merely of speeds and timings. A *lot* of older Mot chips (back when they still _were_ Motorola) truncated the least significant bit on the bus to valid for only the firrst 50% of the bit time. Whether that is true for the devices you are delaing with is unknowable for both of us. Cheers PeteS
From: rickman on 6 Sep 2006 08:40 Alf Katz wrote: > "rickman" <gnuarm(a)gmail.com> wrote in message > news:1157507358.338962.101330(a)m79g2000cwm.googlegroups.com... > > > > Yes, sorry I forgot the question. I am looking for timing specs on the > > bus. > > > > Yepp, as you've alluded to elsewhere, there is no timing spec for the bus. > This is determined entirely by the devices at either end. Some devices can > only run at 100kbaud or so, while others run at faster than 80Mbaud. Asking > for a generic timing spec is a bit like asking for a single timing spec for > microprocessor parallel busses. I am getting that. Unlike nearly all other serial buses, SPI has no real spec and, as you say, is like embedded CPU memory busses, a custom design for each device. That is a good analogy. But even CPU memory busses have become standardized to work with standard memory such as SDRAM, DDR, etc.
From: Alf Katz on 7 Sep 2006 07:27
"rickman" <gnuarm(a)gmail.com> wrote in message news:1157546456.490519.80300(a)m79g2000cwm.googlegroups.com... > Alf Katz wrote: >> "rickman" <gnuarm(a)gmail.com> wrote in message >> news:1157507358.338962.101330(a)m79g2000cwm.googlegroups.com... >> > >> > Yes, sorry I forgot the question. I am looking for timing specs on the >> > bus. >> > >> >> Yepp, as you've alluded to elsewhere, there is no timing spec for the >> bus. >> This is determined entirely by the devices at either end. Some devices >> can >> only run at 100kbaud or so, while others run at faster than 80Mbaud. >> Asking >> for a generic timing spec is a bit like asking for a single timing spec >> for >> microprocessor parallel busses. > > I am getting that. Unlike nearly all other serial buses, SPI has no > real spec and, as you say, is like embedded CPU memory busses, a custom > design for each device. That is a good analogy. But even CPU memory > busses have become standardized to work with standard memory such as > SDRAM, DDR, etc. > LOL, have they? I'll have to try connecting my brand new TMS470 ARM7 processor's external bus to an SDRAM (or a DDR for that matter). Dunno why I've been wasting money on static and pseudo-static ram. You can have standards, but you pay for them in price, performance, or both. SPI is a very lightweight interface, silicon wise. Cheers, Alf |