Talk:Serial Peripheral Interface Bus
|This is the talk page for discussing improvements to the Serial Peripheral Interface Bus article.|
|WikiProject Computing||(Rated B-class, Mid-importance)|
- 1 Early comments
- 2 accross boards or single board
- 3 Parallel port voltage
- 4 Upper Canada Technologies
- 5 Need more details
- 6 Daisy chain connection of several SPI slaves
- 7 QSPI
- 8 Why is bus capitalized in the article's title ?
- 9 Clock phase and polarity
- 10 Missing Bar over SS
- 11 MicroWire
- 12 Shift register picture desirable
- 13 so where can one find it?
- 14 JTAG
- 15 Picture of Bus interface problem
- 16 Assessment
- 17 Commercial link
- 18 Baud rate?
- 19 What is GSPI?
- 20 Kapil Thakar
- 21 MOSI / MISO timing
- 22 Rename article?
- 23 Merge with In-circuit serial programming
- 24 The Code Sample
- 25 Incorrect Information
- 26 History
- 27 Pronunciation of SPI
- 28 Why was Code Section deleted?
- 29 How about a timing diagram?
"A serial peripheral bus is the most flexible choice [...]"
"[...] making it an excellent choice for some data transmission systems."
"SPI looks at first like a non-standard. However, [...]"
"The interface is also easy to implement for bench test equipment [...]"
This article is well written, but does anyone else get the feeling that this article was written by the SPI Promotional Society?
--Dan McCarty 14:52, 21 June 2006 (UTC)
I have to disagree on both counts! I don't think the article is very well written, (though I've seen worse). To me it reads like it was written by an engineering student who's just learnt about SPI, and therefore doesn't have much context to hang it on. It also suffers from having the waffly marketing-type crud you highlighted, presumably for padding and to cover gaps.
I'll try to edit it over the next few days. Please let me know what you think.
--Ianlewis 12:30, 3 August 2006 (UTC)
Should we mention these similar-sounding interface buses?
--184.108.40.206 20:16, 6 September 2006 (UTC)
I would have to say no. Mainly because they are unrelated. Certainly not the SCSI or DVB-SPI ones (they are both parallel). And SDI - a very dissimilar interface. SPI is a basic interface, and I think only basic/lowlevel interfaces should be mentioned w/ it.
--User:RonB 13:56, 6 September 2006 (CST)
Yes, physically they are very different. But all of them have the same acronym -- SPI. So people that are looking for information on something spelled "SPI" might appreciate a hint as to where to find what they are looking for. So I think this article should mention the other things called "SPI" -- similar to the way the top of the optoisolator page helps people find what they were really looking for, when they were really looking for a opto-isolator. --220.127.116.11 05:08, 26 July 2007 (UTC)
accross boards or single board
Is SPI used as an interconnect across boards, or is it an onboard bus only? —Preceding unsigned comment added by 18.104.22.168 (talk • contribs) there is no reason it can't be used accross boards, the standard doesn't define any standard connectors though and as the article says its a very loose standard. As with any bus of this nature achiveable distances will depend heavilly on clock speed and characteristics of the interconnecting lines. Plugwash 23:36, 7 October 2006 (UTC)
How many slave devices can be connected on SPI bus? Is there is any figure just like in RS485 it is 32 ? Dose SPI defines maximum loading on SCLK?? — Preceding unsigned comment added by 22.214.171.124 (talk) 05:38, 29 June 2011 (UTC)
As mentioned in the article, SPI doesn't support hot plug, can't be used inter-board application directly, but still be ok if you use some kinds of isolated switches. — Preceding unsigned comment added by BladesWoods (talk • contribs) 07:44, 30 March 2013 (UTC)
Parallel port voltage
The parallel port voltage level on the most recent PCs is less than 5V. This can make it difficult to use it for direct SPI control, so some sort of interface IC is usually needed. DFH 12:03, 3 November 2006 (UTC)
Upper Canada Technologies
Upper Canada Technologies was the company that supplied the "IOport" driver to enable WinNT machines to directly control the parallel port. Their web address was http://www.uct.on.ca/ but this is no longer a valid URL. DFH 12:11, 3 November 2006 (UTC)
Need more details
The page needs more details IMO; sorry I have time to gripe about it now, but not enough to fix it much (I'm researching on whether disabling the frame select/chip select is mandatory between frames when SCPH=0, and my boss is checking every no and then...). Even the external links don't have much detail. 126.96.36.199 05:13, 29 November 2006 (UTC)
Daisy chain connection of several SPI slaves
A diagram depicting this would be a useful addition to the article. DFH 19:08, 21 December 2006 (UTC)
- I'll put it on my list to do. Can you name any specific devices that do daisy chaining? Cburnett 19:26, 21 December 2006 (UTC)
- Done. Cburnett 20:58, 21 December 2006 (UTC)
- Thanks, but I noticed there is a line missing from slave 3 back to the master. DFH 20:48, 22 December 2006 (UTC)
- Fixed. Cburnett 00:16, 26 December 2006 (UTC)
- Thank you. 188.8.131.52 13:35, 4 January 2007 (UTC)
Suggestion for most of the pictures showing master and one or more slaves: use a different color for the chipselect signal(s), so they stand out more. Or different thickness, hatching etc ... colorblind people use Wikipedia too! 184.108.40.206 19:19, 14 August 2007 (UTC)
We don't need a separate Wikipedia article about Queued Serial Periperal Interface (QSPI). An additional section in this article would suffice. Any volunteers? I am therefore removing the QSPI redlink from the See also section. DFH 19:37, 21 December 2006 (UTC)
- I created the respective redirects: QSPI, Queued Serial Peripheral Interface Bus, Serial Peripheral Interface. Cburnett 20:11, 21 December 2006 (UTC)
- Do you have any documentation on it? I can't seem to find any good docs in my quick google search. Cburnett 03:21, 22 December 2006 (UTC)
- I too did a quick Google search yesterday, yet didn't stumble upon a proper spec. There are probably some Motorola or Freescale products which embody it. I will search again soon. DFH 20:46, 22 December 2006 (UTC)
- This section now cites a useful reference. DFH 20:23, 5 January 2007 (UTC)
This wrongly presented QSPI as if it was a new kind of SPI; it's not. It's just one of many controller interfacew. I just updated this, along with a lot of other stuff that was excessively specific to the use of SPI on certain Freescale products ... whence all these eight bit restrictions, gaagh! At this point I have no clue what sort of "expansion" would be appropriate there.
Why is bus capitalized in the article's title ?
Bus is not a proper noun, nor is it part of the acronym. Should the title be changed to Serial Peripheral Interface bus (by means of a page move)? DFH 21:16, 22 December 2006 (UTC)
- I'd say drop the "bus" altogether. If not that, then lowercase "bus". Cburnett 21:26, 22 December 2006 (UTC)
Clock phase and polarity
- Glad to see a more generic reference! Cburnett 20:14, 4 January 2007 (UTC)
Missing Bar over SS
- I agree, maybe these should be here. Especially since the broad nature of the article uses the notion that SS is always asserted when the line is pulled low (and idle high). Now granted, EVERY chip that I have used makes this the state of operation, but is this a given for all parts or is this just a convention that most choose to follow? And generally, this is defined by the slave parts, since most parts that implement master mode don't allow use of the SS line as a assertion out line.--Ronb 16:32, 7 April 2007 (UTC)
- Done. Cburnett 16:41, 7 April 2007 (UTC)
- My two cents: use the 'nCS' convention (or if you must, 'nSS') rather than trying for fancy typography.
I just updated the article to point out that chipselects are not always active low. -- 220.127.116.11 06:09, 2 June 2007 (UTC)
IMO there's no point in having a separate page on MicroWire. Maybe someone with an account can merge that one into this page. Ideally there should be a bit more info there, too. --18.104.22.168 06:12, 2 June 2007 (UTC)
Shift register picture desirable
Someone with a bit of time to create art might consider the classic picture showing how the master and slave side shift registers hook up to each other. SPI controller documentation for most SOC chips will have such a picture. When updating the description of data transfer, I added verbiage to say what happens ... but that's very amenable to a picture (pick some oddball word size, maybe 11 bits). That level of presentation -- words, not bits -- has been mostly missing; which is too bad since it's the level that most developers think at. --22.214.171.124 06:20, 2 June 2007 (UTC)
- I have added an image. Comments and suggestions? Cburnett 01:55, 25 June 2007 (UTC)
- Artwork ... thanks! My first reaction was that showing the memory is a bit confusing; it's just sitting there. I'd suggest just focussing on the shifty bits; getting beyond that starts to get into structures that won't exist in all controllers (like tx/rx buffer registers, possibly backed by FIFOs or with DMA, etc). A picture I happened to have readily at hand is Fig 17-2 in Atmel's ATmega168 spec ... no memory drawn, but it does show the master with clock generator and managing chipselect. On closer examination, the bit numbering is also a bit confusing. Normally bit 0 is the LSB and would be shown on the right ... here it's shown on the left! But in deference to those heretical systsems where bit 0 is the MSB (and thus is shown on the left), it might be better to just label "MSB" and "LSB". I hope you prefer "copious feedback" to "grunt, yeah". ;) 126.96.36.199 15:54, 28 June 2007 (UTC)
- I was thinking and planning a short series of images: a copy from memory to the buffer; then the transfer; then storing back to memory. I was waiting for feedback before investing that much work. Hindsight says I should have mentioned this above. :) I always welcome constructive feedback! Cburnett 16:32, 28 June 2007 (UTC)
so where can one find it?
It would be useful if somebody could explain where generally the SPI devices are to be found. 188.8.131.52 00:56, 25 June 2007 (UTC)
- Guess I'm not sure what you mean. You can find it on many, many microcontrollers (PIC, Atmel, Philips, etc.) and many, many devices (Maxim for one). Cburnett 01:35, 25 June 2007 (UTC)
- I'm not sure either. Most distributors have on-line catalogs nowadays, and you can probably just enter SPI as a search key. I've done that with DigiKey(.com) with success. Chip vendors don't tend to sort by interconnect though; if you want a Zigbee chip, you'd just have to *know* that they almost universally talk SPI. (Except for modules that embed a SPI chip and a microcontroller, offering a "high level" interface with a UART or something to the micro.) 184.108.40.206 15:31, 28 June 2007 (UTC)
I'm looking for a microcontroller with at least 3 SPI ports, preferably more. (I have a pile of SPI peripherals that unfortunately can't share the same bus). So far the only microcontroller I've found with 3 SPI ports is the "Intel PXA270" XScale processor.
Are there other microcontrollers that I should look at? --220.127.116.11 05:08, 26 July 2007 (UTC)
- Yes; I'm no PXA fan, myself. The key is: don't limit yourself to SPI-specific controllers. ISTR that pxa270 doesn't have dedicated SPI; it has a multipurpose SSP controller which can be used in SPI mode (among other modes including I2S). Lots of controllers have similar multipurpose serial ports ... OMAP1 has McBSP, which can be used in SPI mode, so an OMAP5912 supports a whole bunch of SPI: 3 McBSP ports, one MicroWire, one SPI ... two MMC slots with SPI support, and ISTR a few other controllers too. Atmel AT91rm9200 has one SPI and three SSC; AT91sam9261 has two spi and three SSC, as does the AVR32 AT32AP7000. And yes, bitbanging SPI is really easy, depending on the data rates you need and how much CPU bandwidth you have free. 18.104.22.168 19:15, 14 August 2007 (UTC)
- Another option may be to use some basic logic chips (or a PAL) to gate the SPI outputs so that only one chip at a time sees SPI activity even though the controller has only one SPI interface. Plugwash 00:18, 15 August 2007 (UTC)
It seems like a bit of a stretch to call JTAG an "application stack" for SPI. Yes, JTAG and SPI are both serial shift registers. But that's about all they have in common. It's flat wrong to imply that TMS is SSn with a 'different signal name'. The way TMS is used in JTAG is not generally equivalent to or compatible with the way SSn is used in SPI. You couldn't, for example, hook up a generic microcontroller SPI master directly to a JTAG port and expect it to work--at least not without a lot of manual bit-banging to get the required behavior on TMS (toggle around for a few cycles to begin shifting; put TMS high on last data bit, etc). 22.214.171.124 17:15, 28 June 2007 (UTC)
- There are other SPI protocols, including MMC/SD in SPI mode, that have "strange" rules about chipselect signaling. (MMC/SD has cases where it requires clocks and data to go out when chipselect is inactive.) And they don't shy away from calling themselves "SPI". Generic microcontrollers tend to cheap out on SPI hardware, with restrictions like only handling 8 bit words unless they clock bits out "by hand", and not being able to support all modes; that makes it difficult to use them to master some SPI devices. But that doesn't affect the truth that JTAG is layered over the four signal wires of SPI ... which is quite a lot to have in common, given that's about all that SPI covers! And in any case, the value (and complexity) of JTAG is in that stack, not the lowlevel signaling. Vendor commands, BSDL, etc. 126.96.36.199
Picture of Bus interface problem
There seems to be a problem with the first picture for the SPI interface. The MOSI of the Master should go to the MISO of the slave and the MOSI of the slave to the MISO of the master. —Preceding unsigned comment added by Mihaigalos (talk • contribs) 22:02, 6 October 2007 (UTC)
- MOSI means "master out, slave in". So the MOSI pins get connected together and MISO pins get connected together. Thus, you don't have to rewire if you switch the master around. Cburnett 04:32, 7 October 2007 (UTC)
There was a link on the article for a commercial hardware implementation of SPI, that was not interesting as a reference and in my opinion configured advertising. I suppressed it.
I came here trying to work out what typical "baud rates" are for SPI, i mean I understand it is dependent on device but shouldn't this article at least mention something about that? Comparing it to other comm methods maybe or something? Compared to clock rate or anything? There's nothing about speed in this article. I've been googling for the answer but this info seems very hard to come by. Vespine (talk) 04:36, 15 June 2010 (UTC)
- One nice thing about SPI is that SPI doesn't require baud rate settings. The master can pick any random convenient bit rate, even pause in the middle of a byte if something more important interrupts it, and -- as long as the bit rate is always less than the maximum bit rate supported by the slave -- everything will work perfectly.
- The SPI slaves on a JTAG chain can support at least 10 Mbit/s and many chips support 100 Mbit/s; the SPI slave inside a MultiMediaCard can handle communications at a bit rate of 20 Mbit/s; the one in a SD card (in MMC-compatible SPI mode) and the 74HC595 at 25 Mbit/s. (See those articles for references).
- Like all SPI devices, all of them also support at any slower rate the master may choose, down to practically 0.
- In particular, many people build prototypes that drive the clock on a SD/MMC card at 4 Mbit/s -- the maximum bit rate of the Arduino (and most clones) when used as an SPI master -- or the same card at 2.8334 Mbit/s (a convenient multiple of the 44.1 kSamples/s CD audio sampling rate).
- Once a command has been transferred, serial SRAM and serial FRAM and the 74HC595 and most JTAG chips are immediately ready for the next command. However, flash chips and flash cards will generally give the "busy" response to every message until it is ready to accept another command -- I see some SPI flash chips with a "typical" erase sector time more than half a second -- so their actual goodput storage rate may be many times lower than the communications rate.
- Does that answer your question?
- How can the article be improved to make this clear to the next reader with the same question?
- --188.8.131.52 (talk) 16:34, 13 November 2010 (UTC)
What is GSPI?
MOSI / MISO timing
I think your timing diagram is incorrect. In a typical implementation you clock the slave on the other clock edge as the master. You need to do this to ensure stability on the MOSI/MISO line when the data is clocked into the shift register. The MISO line should therefore change value on the opposite edge, not on the same edge as the MOSI line. Typically the slave writes the first data bit to the MISO line as soon as the chip select is asserted, even before the first clock pulse is received.
- Actually I don't think there is a error in the timing diagram, but rather in the describing text.
- The MOSI and MISO lines change state at the same clock edge, just as the diagram illustrates, but the slave typically samples the MOSI line at the oposite edge. Brolin (talk) 18:11, 20 December 2011 (UTC)
Is anyone interested in renaming this article to "SPI bus"? Recently, the "Controller area network" article was renamed to the "CAN bus", see http://en.wikipedia.org/wiki/Talk:CAN_bus#Requested_move_2 This isn't a formal request, but instead meant to be a discusion. • Sbmeirow • Talk • 15:37, 14 January 2012 (UTC)
- It looks like that was done because they could not agree whether it should be Controller Area Network and Controller area network. It is best to avoid acronyms in titles (see WP:ACRONYMTITLE). ~KvnG 15:44, 14 January 2014 (UTC)
Merge with In-circuit serial programming
Isn't In-circuit serial programming (as described in the article) just an application of the SPI bus?
I am not sure what protocol is used for ICSP, but it looks a lot more like I2C than SPI (note that it only uses a clock and a **bidirectional** data pin, whereas SPI uses independent input and output pins)
ICSP is intended for writing a piece of firmware into a programmable IC once is soldered on the PCB. SPI is a communications protocol between two or more ICs to exchange data in the normal usage. Even if ICSP uses a protocol like SPI, they should not be merged as they relate to different purposes. Links to SPI page should be used in the ICSP page to give more details. JoanCAbelaira (talk) 08:22, 17 May 2012 (UTC)
The Code Sample
SPIDELAY(SPISPEED - (SPISPEED/2));
the same as this?
They're only the same if SPISPEED is an even number. If SPISPEED is odd, using (SPISPEED/2) for both timers will result in clock drift due to the single timing count which is discarded each bit. GingerKarma (talk) 06:26, 26 March 2013 (UTC)
This looks like a bug to me:
CLRCLK(); /* write MOSI on falling edge of previous clock */ if (byte & 0x80) SETMOSI(); else CLRMOSI();
An earlier comment:
/* Data are propagated on a falling edge (high->low clock transition). */ SETGPOL(0);
specifies that data is clocked out on the falling edge of the clock. Shouldn't the data bit be set up before the clock line is cleared? I would propose that the code should be as follows:
/* write MOSI on falling edge of clock */ if (byte & 0x80) SETMOSI(); else CLRMOSI(); CLRCLK();
"Most slave devices have tri-state outputs so their MISO signal becomes high impedance (disconnected) when the device is not selected. Devices without tri-state outputs can't share SPI bus segments with other devices; only one such slave could talk to the master, and only its chip select could be activated."
- First off, can't is a strong word here -- a slave device without a tri-state MISO (output) pin can just have it's MISO pushed through a tri-stateable buffer, and have the buffer's /E pin tied to the slave device's /E pin. Not to mention, if you weren't interested in the data from MISO on that particular slave device, you could just leave MISO disconnected (i.e., no additional hardware solution, let's you write to multiple devices that do not have tri-state MISOs, and still read from the devices that matter.) Alternately, if you did need to be able to read from that slave device, and you don't have a tri-state buffer, you could use a separate IO pin for that particular slave device, etc...
- Second off, any /E (chip select) pin of any device could still be enabled, and data could still be sent to any device on the bus via the MOSI pin (regardless of what was going down on the MISO pins).
Pronunciation of SPI
I find it interesting that a particular user does not believe that "SPI" could be pronounced like "SPY" and is asking for references. Anyone who has worked in the industry since the SPI bus has been implemented (30+ years now?) has probably heard it called S-P-I (spelled out) or alternatively, like the word "SPY" (long I sound in English, but not like "SPEE", which has a short I sound). I work at a major semiconductor company and we use the pronunciation "SPY" all the time for SPI (along with "S-P-I".) It is akin to saying a "Dual Inline Package" (DIP) is a "dip", pronounced the same way as in what you use with potato chips...however, I've rarely heard anyone say a "D-I-P" package. If you need some sort of internet reference, here is one: http://electronics.stackexchange.com/questions/57902/how-do-you-pronounce-the-following-set-of-words, you'll see people use both "S-P-I" and "SPY" being used as pronunciations. — Preceding unsigned comment added by 184.108.40.206 (talk) 18:23, 3 May 2013 (UTC)
- Hi, the particularly interested user questioning the pronunciation "spy" is me. ;-) In all those decades I never heard it being pronounced "spy", that's why I asked for a source. Thanks for providing one. To be honest, I do not count this forum post as a reliable reference, but I will leave it at that. If you find better sources, please provide them. Thanks. --Matthiaspaul (talk) 22:27, 3 May 2013 (UTC)
Why was Code Section deleted?
Why was the code simulation section deleted? It should be considered "pseudo-code" of how SPI works, which is sometimes more helpful than textual descriptions. • Sbmeirow • Talk • 23:09, 29 January 2015 (UTC)
How about a timing diagram?
I'm considering adding some timing diagrams to this article to illustrate typical timing arcs, but since there is no standard, I fear that it would be too definite to be factual. Would it be?
I'm considering the following arcs for the timing diagram. What problems are there with these? The way to read is: [first in time] -> [second in time] [timing type]. I've made these arcs relative because of SPI variations. For example, instead of writing "ss falling edge" I've written "ss enable" because enable can be either high or low.
[ss enable] -> [sclk receive edge] [setup] [sclk receive edge] -> [ss disable] [hold] [mosi] -> [sclk receive edge] [setup] [sclk receive edge] -> [mosi] [hold] [ss enable] -> [miso] [delay] [sclk transmit edge] -> [miso] [delay]
[ss enable] -> [sclk receive edge] [delay] [receive edge] -> [ss disable] [delay] [miso] -> [sclk receive edge] [setup] [sclk receive edge] -> [miso] [hold] [ss enable] -> [mosi] [delay] [sclk transmit edge] -> [mosi] [delay]