nowbotki

Jun 20, 2017. Serial Peripheral Interface or SPI is a synchronous serial communication protocol that provides full – duplex communication at very high speeds. In the 1980's as a standard, low – cost and reliable interface between the Microcontroller (microcontrollers by Motorola in the beginning) and its peripheral ICs. SPI (Serial Peripheral Interface) is a full duplex synchronous serial communication interface used for short distance communications. It is usually used for communication between different modules in a same device or PCB. SPI devices communicates each other using a master slave architecture with a single master.

1. Motorola Serial Peripheral Interface Spi Protocol

SPI (4 wire). ○ Serial Peripheral Interface. ○ 4 wires (really 3 + 1 for each device). ○ Intended for CPU to Peripheral communication and control. ○ Defined by Motorola.

Introduction to Serial Peripheral Interface

Another option for low-cost, low-speed communication 'inside the box' is the serial peripheral interface.

Several months ago in Beginner's Corner, we covered the inter-integrated circuit bus. I²C is a popular technology for low-cost, low-speed, communication 'inside the box' ('I²C,' August 2001, p. 87 ). Another choice to consider is the serial peripheral interface (SPI).

SPI vs. I²C

Both SPI and I²C provide good support for communication with slow peripheral devices that are accessed intermittently. EEPROMs and real-time clocks are examples of such devices. But SPI is better suited than I²C for applications that are naturally thought of as data streams (as opposed to reading and writing addressed locations in a slave device). An example of a 'stream' application is data communication between microprocessors or digital signal processors. Another is data transfer from analog-to-digital converters.

SPI can also achieve significantly higher data rates than I²C. SPI-compatible interfaces often range into the tens of megahertz. SPI really gains efficiency in applications that take advantage of its duplex capability, such as the communication between a 'codec' (coder-decoder) and a digital signal processor, which consists of simultaneously sending samples in and out.

SPI devices communicate using a master-slave relationship. Due to its lack of built-in device addressing, SPI requires more effort and more hardware resources than I²C when more than one slave is involved. But SPI tends to be simpler and more efficient than I²C in point-to-point (single master, single slave) applications for the very same reason; the lack of device addressing means less overhead.

Inside the box

SPI is a serial bus standard established by Motorola and supported in silicon products from various manufacturers. SPI interfaces are available on popular communication processors such as the MPC8260 and microcontrollers such as the M68HC11. It is a synchronous serial data link that operates in full duplex (signals carrying data go in both directions simultaneously).

Devices communicate using a master/slave relationship, in which the master initiates the data frame. When the master generates a clock and selects a slave device, data may be transferred in either or both directions simultaneously. In fact, as far as SPI is concerned, data are always transferred in both directions. It is up to the master and slave devices to know whether a received byte is meaningful or not. So a device must discard the received byte in a 'transmit only' frame or generate a dummy byte for a 'receive only' frame.

Figure 1: Single master, single slave SPI implementation

SPI specifies four signals: clock (SCLK); master data output, slave data input (MOSI); master data input, slave data output (MISO); and slave select (ÇSS). Figure 1 shows these signals in a single-slave configuration. SCLK is generated by the master and input to all slaves. MOSI carries data from master to slave. MISO carries data from slave back to master. A slave device is selected when the master asserts its ÇSS signal.

If multiple slave devices exist, the master generates a separate slave select signal for each slave. These relationships are illustrated in Figure 2.

Figure 2: Single master, multiple slave SPI implementation

The master generates slave select signals using general-purpose discrete input/output pins or other logic. This consists of old-fashioned bit banging and can be pretty sensitive. You have to time it relative to the other signals and ensure, for example, that you don't toggle a select line in the middle of a frame.

While SPI doesn't describe a specific way to implement multi-master systems, some SPI devices support additional signals that make such implementations possible. However, it's complicated and usually unnecesary, so it's not often done.

A pair of parameters called clock polarity (CPOL) and clock phase (CPHA) determine the edges of the clock signal on which the data are driven and sampled. Each of the two parameters has two possible states, which allows for four possible combinations, all of which are incompatible with one another. So a master/slave pair must use the same parameter pair values to communicate. If multiple slaves are used that are fixed in different configurations, the master will have to reconfigure itself each time it needs to communicate with a different slave.

At a higher level

SPI does not have an acknowledgement mechanism to confirm receipt of data. In fact, without a communication protocol, the SPI master has no knowledge of whether a slave even exists. SPI also offers no flow control. If you need hardware flow control, you might need to do something outside of SPI.

Slaves can be thought of as input/output devices of the master. SPI does not specify a particular higher-level protocol for master-slave dialog. In some applications, a higher-level protocol is not needed and only raw data are exchanged. An example of this is an interface to a simple codec. In other applications, a higher-level protocol, such as a command-response protocol, may be necessary. Note that the master must initiate the frames for both its command and the slave's response.

Both SPI and I²C offer good support for communication with low-speed devices, but SPI is better suited to applications in which devices transfer data streams.

SPI's full duplex communication capability and data rates (ranging up to several megabits per second) make it, in most cases, extremely simple and efficient for single master, single slave applications. On the other hand, it can be troublesome to implement for more than one slave, due to its lack of built-in addressing; and the complexity only grows as the number of slaves increases.

Far from being just a dumb 'byte port,' SPI is often an elegant solution for modest communication needs. It can also serve as a platform on which to create higher-level protocols.

David Kalinsky is director of customer education at OSE Systems and a lecturer and seminar leader on embedded software technologies. He has been involved in the design of many embedded medical and aerospace systems. David holds a Ph.D. in nuclear physics from Yale University and can be reached by e-mail at david@enea.com.

Roee Kalinsky is a senior design engineer at QThink, where he is presently involved in ASIC design and the development of design methodology. He has designed numerous embedded systems including networking, multimedia, and hand-held products. Roee holds a BSEE from the University of California at San Diego. He can be reached by e-mail at roeek@qthink.com.

Most Commented

Early comments[edit]

'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?

--65.70.89.241 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 peoplefind what they were really looking for, when they were really looking for a opto-isolator.--75.37.227.177 05:08, 26 July 2007 (UTC)

accross boards or single board[edit]

Is SPI used as an interconnect across boards, or is it an onboard bus only? —Preceding unsigned comment added by 63.231.83.177 (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 117.240.114.84 (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)

As prior art demonstrates, however, SPI can be used for inter-board applications directly, as the multitudinous quantities of Pmod adapters illustrates, both with and without cables. However, to do this, you need to distinguish between slave and master ports. Digilent also defines an interrupt pin for use when you have two FPGA boards working together and need asynchronous communications between them. No Pmod device I'm aware of uses this interrupt pin, though. Digilent's document in Pmod ports indicates they're able to push 24Mbps over a distance of 12 feet (4m) using DC-coupled, 3.3V, single-ended logic connected via cat-5 cable. I have used SD cards in SPI mode at 1Mbps over a 12-inch distance reliably using unbalanced cabling. See https://www.digilentinc.com/Pmods/Digilent-Pmod_%20Interface_Specification.pdf

SPI can support hot-plug with the addition of a change-detect signal (e.g., the CD signal on Digilent's PmodSD card: see https://reference.digilentinc.com/_media/reference/pmod/pmodsd/pmodsd_sch.pdf). In the absence of this, MISO floats high in most SPI implementations, so an extended run of $FF bytes can be interpreted as a line-break condition. Without the CD signal, the master would need to periodically poll the candidate slave somehow. — Preceding unsigned comment added by 173.11.86.22 (talk) 19:17, 3 December 2016 (UTC)

Parallel port voltage[edit]

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[edit]

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[edit]

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. 202.33.138.40 05:13, 29 November 2006 (UTC)

Daisy chain connection of several SPI slaves[edit]

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)

Freescale (Intelligent High Current Self-Protected Hi-Side Switch) MC33982^[1] and MC33984^[2] both support daisy chain. DFH 20:54, 22 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. 57.66.65.38 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! 69.226.247.176 19:19, 14 August 2007 (UTC)

QSPI[edit]

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)

U.S. Patent 4,816,996, U.S. Patent 4,958,277, U.S. Patent 5,805,922 are examples of QSPI. DFH 22:18, 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 ?[edit]

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)

It seems the article began (or was duplicated) as Serial Peripheral Interface, which is now a redirect to here, but has some edit history. These circumstances make a move back more difficult. It may be simpler just to make 'bus' lowercase. DFH 22:01, 22 December 2006 (UTC)

Clock phase and polarity[edit]

I am about to replace the particular example 'For example, the LPC2104/2105/2106 (a ARM7TDMI 60 MHz microcontroller)' by a reference to the SPI Block Guide. DFH 16:35, 4 January 2007 (UTC)

Glad to see a more generic reference! Cburnett 20:14, 4 January 2007 (UTC)

Missing Bar over SS[edit]

The bars over SS are missing.(There should be bars over SS to indicate the Active Low nature) —The preceding unsigned comment was added by 203.91.193.50 (talk) 10:03, 6 March 2007 (UTC).

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. -- 69.226.212.132 06:09, 2 June 2007 (UTC)

MicroWire[edit]

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. --69.226.212.132 06:12, 2 June 2007 (UTC)

Shift register picture desirable[edit]

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. --69.226.212.132 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'. ;) 69.226.213.6 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?[edit]

It would be useful if somebody could explain where generally the SPI devices are to be found.83.208.14.127 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.) 69.226.213.6 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.

(I suppose I should also consider simulating SPI ports with 'bit-banging' GPIO pins,and also programming a FPGA or FPSLIC to handle SPI).

Are there other microcontrollers that I should look at?--75.37.227.177 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. 69.226.247.176 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)

JTAG[edit]

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

Picture of Bus interface problem[edit]

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)

Assessment[edit]

Well-deserved B-class article. Correct me if I'm wrong: I marked the importance as low. -downloadsign! 22:18, 7 April 2009 (UTC)

Preachy section about 'You should ask what someone means by 3-wire serial bus' is superfluous. 64.238.49.65 (talk) —Preceding undated comment added 14:27, 27 July 2009 (UTC).

Commercial link[edit]

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.

RCelistrinoTeixeira (talk) 11:46, 4 July 2009 (UTC)

Baud rate?[edit]

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?

--68.0.124.33 (talk) 16:34, 13 November 2010 (UTC)

What is GSPI?[edit]

What is GSPI? —Preceding unsigned comment added by 71.131.2.31 (talk) 06:53, 22 October 2010 (UTC)

MOSI / MISO timing[edit]

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.

146.103.254.11 (talk) 07:13, 8 June 2011 (UTC)Josh

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)

Rename article?[edit]

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[edit]

Isn't In-circuit serial programming (as described in the article) just an application of the SPI bus?

Sylvain Leroux (talk) 13:40, 27 March 2012 (UTC)

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 a concept in its own right and unrelated to SPI. Therefore the article should not be merged. GangstaUK (talk) 14:55, 10 April 2012 (UTC)

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)

That is correct. I remove the merge proposal Sylvain Leroux (talk) 11:53, 27 June 2012 (UTC)

The Code Sample[edit]

isn't this:

the same as this?

if not, can someone comment the code to say why! — Preceding unsigned comment added by 87.194.212.27 (talk) 14:29, 16 July 2012 (UTC)

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:

Motorola Serial Peripheral Interface Spi Protocol

An earlier comment:

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:

GingerKarma (talk) 05:13, 27 March 2013 (UTC)

Incorrect Information[edit]

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

BrainSlugs83 (talk) 09:25, 19 September 2012 (UTC)

History[edit]

When did SPI come out? Has the popularity of it been increasing in the last few years? Perhaps this article could use a history section up top. —Voidxor (talk) 08:06, 3 February 2009 (UTC)

Agree. This article needs a history section. • Sbmeirow • Talk • 13:31, 26 March 2013 (UTC)

Motorola's MC68HC11 Reference Manual is from 1989. In a 1986 patent, however, Motorola names a completely different invention 'Serial Peripheral Interface (SPI)'. Thus, it is safe to say that the SPI was developed in the late eighties. --Rainald62 (talk) 15:05, 15 August 2016 (UTC)

Pronunciation of SPI[edit]

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 137.71.23.54 (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?[edit]

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?[edit]

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.

For slave:

For master:

Beeflo (talk) 15:12, 11 February 2015 (UTC)

Reference broken[edit]

pdf document link 'SPI Block Guide V03.06' do not provide said document. — Preceding unsigned comment added by 80.50.149.118 (talk) 10:28, 26 March 2016 (UTC)

Done The entire internet suffers from link rot. • Sbmeirow • Talk • 20:42, 26 March 2016 (UTC)

SPI vs SPB?[edit]

I was reading Microsoft technical titled *HID over I2C*, which said:

Of course I've heard of SPI, and I'm familiar with it, but this seems to reference something different (not sure) called **Simple Peripheral Bus**. When I used that as a Wikipedia search, it got referred to the SPI page.

Is this an indication that the Simple Peripheral Bus (SPB) is the same as Serial_Peripheral_Interface, or are the different?

If different, should we remove 'bus' from the title of this article? I usually see it referred to as SPI rather than SPIB.

Also if not, an article regarding Simple Peripheral Bus (SPB) seems appropriate. Does anyone have any additional information?

--Burt Harris (talk) 20:26, 20 May 2018 (UTC)

SPIHD and SPIWP ???[edit]

Anyone ever encounter these? It appears they are particular to ExpressIf ICs and correspond to SIO2 and SIO3 signals of QSPI, but I am not sure. I am curious what the HD and WP mean, but can't find anything anywhere! It would be nice to have those names included here, along with any other industry names for those lines.--38.88.217.186 (talk) 22:54, 19 June 2019 (UTC)