Talk:Serial Peripheral Interface

Early comments

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

Serial Digital Interface DVB-SPI SCSI Parallel Interface

--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 people find 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)

across boards or single board

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 across 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 achievable distances will depend heavily 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)

The primary concern with using SPI across boards is signal integrity (and what did the poster mean by "across boards" -- how many and how large of boards? On a scale from a pair of 1" x 1" directly connected together to a dozen 20" x 20" with ten foot cables between them?). SPI was intended as a low cost, low complexity communication method. It's mostly just a shift register, latch and some glue logic, with the base assumption (requirement) that digital I/O signals (TTL or CMOS levels) would be valid in the operating environment. That means noise margins on the order of 0.4V and it has no particular ESD protection or error detection. In standard usage, simple digital I/O lines are used and good grounding assumed. SPI across boards will be sensitive to grounding issues, noise, excess capacitance, signal reflections, ESD, etc. that can degrade reliability, and there is no provision for error detection, because the assumptions that the design is based on is (again) that the digital I/O signals will be valid. 2601:601:9900:11A0:6896:F063:DF6A:333B (talk) 21:51, 4 April 2021 (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. 202.33.138.40 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)

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

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 ?

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

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

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

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

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?

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

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

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

Well-deserved B-class article. Correct me if I'm wrong: I marked the importance as low. -download | sign! 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

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?

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?

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

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.

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)

There is confusion in full duplex operation. The Mode terminology applies separately to the Master transmitting and the Master receiving. There are actually 8 possible modes instead of 4 it would seem. Clock idle low, you could transmit on either edge and receive on either edge, 4 possibilities. The diagram and mode descriptions appear to only apply to transmitting. As stated, there is no standard, but making readers aware of the possibility of transmit/receive differences in the "4 Modes" is important for troubleshooting at least, when people come here to learn what's wrong. The timing diagram should probably have another set of waveforms to show this possibility. 96.237.142.109 (talk) 13:28, 7 April 2020 (UTC)

Rename article?

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?

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

isn't this:

 SPIDELAY(SPISPEED - (SPISPEED/2));

the same as this?

 SPIDELAY(SPISPEED/2);

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:

       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();

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

Incorrect Information

"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

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

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?

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.

For slave:

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

For master:

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

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

Reference broken

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?

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

   Today, the HID I²C driver targets SoC systems that support Simple Peripheral Bus (SPB) and GPIO. In the future, Microsoft may support this driver on non-SoC systems.

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

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)

Terminology

Any ideas how we update, and preserve history in a simple way?

New Signal Names:

 SDO – Serial Data Out. An output signal on a device where data is sent out to another SPI device.
 SDI – Serial Data In. An input signal on a device where data is received from another SPI device.
 CS – Chip Select. Activated by the controller to initiate communication with a given peripheral.
 COPI (controller out / peripheral in). For devices that can be either a controller or a peripheral; the signal on which the device sends output when acting as the controller, and receives input when acting as the peripheral.
 CIPO (controller in / peripheral out). For devices that can be either a controller or a peripheral; the signal on which the device receives input when acting as the controller, and sends output when acting as the peripheral.
 SDIO – Serial Data In/Out. A bi-directional serial signal.

Deprecated signal names:

 MOSI – Master Out Slave In
 MISO – Master In Slave Out
 SS – Slave Select
 MOMI Master Out Master In
 SOSI Slave Out Slave In

A Redefinition of SPI Signal Names — Preceding unsigned comment added by Pbamberger (talk • contribs) 22:09, 3 July 2020 (UTC)

That is not an official specification, nor do they have the authority to do so. — Preceding unsigned comment added by 68.102.121.140 (talk) 22:33, 3 July 2020 (UTC)

SPI is a defacto standard, anyone can change it, no authority required pbamberger (talk) 00:05, 4 July 2020 (UTC)

Anyone can rewrite anything. Sure, do what you want for yourself / your group / your tiny organization, but that's where your mandatory influence ends. The same goes for others that choose a different set of SPI terms and acronyms too. Since this document isn't officially endorsed by any IC manufacturers nor written by any major specifications organization, and since a vast majority of engineers were excluded from the decision making process, it should be treated with the same importance as any other random document on the internet.

I don't know what is needed to certify as a major specification organization but here's a statement of the Open Source Hardware Association advocating new SPI signal names: https://www.oshwa.org/a-resolution-to-redefine-spi-signal-names/. Further here's a memo from the Internet Engineering Task Force: https://www.ietf.org/archive/id/draft-knodel-terminology-05.txt. Granted, it's still a "work in progress" document and while not talking about Hardware and SPI they specifically mention the master-slave terminology and how exclusionary terminology is to be avoided in RFC documents. I'd consider OSHWA and IETF as major organizations and as such think it's appropriate to at least mention the proposal of alternative names. 188.192.200.51 (talk) 09:48, 18 March 2021 (UTC)

Is this going ahead or not? SaadiSave (talk) 03:34, 27 April 2021 (UTC)

You do not have the right to use exclusionary language. Furthermore, OSHWA and IETF are major organisations. SaadiSave (talk) 03:34, 27 April 2021 (UTC)

Wikipedia is not censored. IETF is an internet organization, just a reminder that SPI isn't internet. OSHWA doesn't have any authority to officially rename anything outside of their group. Master/Slave is what datasheets and books calls it. Human slavery is bad, but hardware isn't humans thus it's a moot point.

Regardless of how anyone feels about the underlying impetus for the creation of the newer terminology, it are now being used by IC manufacturers. Texas Instruments, for example, is using them (SDO, SDI, PICO and POCI) in newer documentation. Wikipedia documents the world as it is. It should include a description of the newer terminology. For example:

https://www.ti.com/lit/ml/sllt215a/sllt215a.pdf

https://www.ti.com/lit/ml/scea128/scea128.pdf

https://www.ti.com/lit/ds/symlink/tmag5170d-q1.pdf

https://www.ti.com/lit/ds/symlink/tmp126.pdf

https://www.ti.com/lit/ds/symlink/mspm0l1304.pdf

...and lots more: https://www.ti.com/sitesearch/en-us/docs/universalsearch.tsp?langPref=en-US&searchTerm=SPI%20PICO&nr=205#q=SPI%20PICO&numberOfResults=25&f:technicalDocuments=%5BData%20sheet%5D — Preceding unsigned comment added by James Montgomerie (talk • contribs) 22:46, 3 May 2023 (UTC)

I think this is something that needs to be considered at a higher level within Wikipedia:WikiProject Computing as master-slave terminology is still fairly ubiquitous in computing, particularly in hardware, and since hardware moves fairly slowly (many engineers still use datasheets and reference books from the 20th century!) I think it's unwise to abandon it so readily. A template along the lines of "This article uses master-slave terminology, for alternative terminologies used by some manufacturers and vendors click here" might be a good compromise. 51.7.119.190 (talk) 14:47, 9 June 2023 (UTC)

It's almost 2024. I do notice more and more new datasheets like Texas Instruments you mentioned tend to use PICO and POCI. In addition, I'm noticing NXP as of now uses COTI and CITO:

Serial peripheral interface (SPI) is the full duplex synchronous serial interface consisting of four signals: SCLK (serial clock), COTI (controller out, target in), CITO (controller in, target out) and TS (target select) used for short-distance, high-speed communications. The SPI bus operates with a single controller device and one or more target devices with data rate ranges from 5 to 20 Mbit/s.

I did make some edits to the article and added a footnote with brief explanation. Unfortunately there are so many various names (e.g. PICO vs COTI) that these various new naming schemes will take extra words to try to explain. I don't know the best way to word the article, though. Hopefully one naming scheme will dominate. Em3rgent0rdr (talk) 06:12, 21 July 2023 (UTC)

I've renamed the section "Independent slave configuration" to be "Multidrop configuration" because Multidrop bus is more technically accurate and hyperlinkable and avoids problematic "slave" word as the section title.

Thinking about the naming scheme more, I'm thinking all these acronyms are overwhelming. I think just write "Serial Out" and "Serial In" and "Chip Select" and "Clock" for this article. The "XIYO" and "YOXI" naming (where X and Y are one of the words "Master", "Slave", "Controller", "Target", "Peripheral") is useful when one device can operate as both an X or Y. But in all the diagrams for this article each device is only operating as one or the other and not both. Spelling out "Serial Out" or "Serial In" on each pin makes it clear that that pin is a serial output or input, so reader doesn't have to dissect what acronyms are. Em3rgent0rdr (talk) 21:26, 21 July 2023 (UTC)

Looking some more and I found a 2018 Analog Devices "Introduction to SPI" article that uses the names "Main" and "Subnode", which conveniently preserves the same abbreviations "MISO" and "MOSI" while avoiding any references to "slave" at all. This might be the best way to go about renaming. Em3rgent0rdr (talk) 21:54, 21 July 2023 (UTC)

Redoing the diagrams now, and I'm finding "Main" and "Sub" work out very nicely because they are so short. While "peripheral" or "controller" or "target" just take too much space in a diagram. Em3rgent0rdr (talk) 23:07, 21 July 2023 (UTC)

I spent some time simplifing the diagrams with the very short word "Main" and "Sub" and made an edit which changed "Master" to "Main" and "Slave" to "Sub" and quickly got into "Operation" section, while moving the longer debate about pin namings to a very end section "Alternative namings": https://en.wikipedia.org/w/index.php?title=Serial_Peripheral_Interface&oldid=1166540433

This has the big advantage of preserving the original abbreviations "MISO" and "MOSI" while avoiding referencing slavery. Em3rgent0rdr (talk) 07:00, 22 July 2023 (UTC)

While I understand and appreciate the intent to promote inclusive terminology and avoid the perpetuation of potentially hurtful terms, and agree that it is a good idea to move in this direction, I think that deceiving the reader by claiming that M stands for "main" and S stands for "sub" is a terrible approach.

• First, the provided link suggesting the use of "main" and "sub" seems to be a primary source / original proposal that doesn't cite any prior uses of the term in the context of SPI, whereas this Wikipedia article is describing a historically used interface / de facto standard.
• Second, choosing the alternative names "main" and "sub" just because they allow retrofitting the acronyms doesn't seem like a valid argument to choose those; it would be better to use descriptive names rather than making up what the acronyms mean.
• Third, making up naming conventions when most of the existing literature uses a different one leads to confusion and reduces the value of the article.
• Fourth, the fact that SPI is a de facto standard (as argued earlier) is not a valid reason to change it at will by an independent party. This would be a valid point if it were shown that a majority of adopters (or at least a significant amount) have adopted this terminology, but precisely because it is a de facto standard it cannot be changed by a single person or entity.
• Finally, the aim of Wikipedia as an encyclopedia is to describe what is, not what should be; reality, not opinion. If an editor believes that a term should not be used, it is wrong to claim that the term is not used; if anything, they should state the reasons why the term should not be used.

Overall, I think that the way this has been tackled, while well-intentioned, breaks Wikipedia's policies, and should be approached differently.

My proposal of how this issue should be approached in the article is as follows:

1. Be honest in the article. Indicate that the two ends of the communication were historically named "master" and "slave", as was common practice in similar interconnects, and that's why the acronyms MOSI and MISO are used (as seen in the application note from Motorola from 1987, among many others), and do not try to imply that the acronyms mean something else.
2. Clarify, at the beginning of the article, that these historical terms are nowadays seen as archaic terms with negative connotations, and that it is preferred to avoid them.
3. Use alternative but valid and meaningful names throughout the article ("valid" in this context means that they are actually commonly used, and not chosen on the spot for the redaction of the article). "Host" (or perhaps "controller") and "peripheral" seem to be reasonable and descriptive choices that are commonly used (after all, that's what the "P" in "SPI" stands for). But trying to cram made up terms such as "main" and "sub" just because "they fit the acronym" is just wrong.
4. Avoid the use of "master" and "slave" throughout the article except when describing the meaning of the acronyms, using the alternative names to the extent possible without affecting the meaning of the article.
5. Avoid using constructions that suggest a reinterpretation of the acronyms. For example, replace phrases like "main out, sub in" with "host to peripheral" so that it is clear that it's just describing what MOSI is and not stating what MOSI means (leaving "master out, slave in" as a note below, with quotes, to indicate that it is showing the origin of the acronym and not its preferred description).

With this approach, the article can be written in a way that avoids the use of these terms, but focusing on the content rather than avoiding the use of the old terminology in a forced manner.

--Cousteau (talk) 11:35, 18 November 2024 (UTC)

Per WP:NOTCENSORED, you should not sterilize terms because someone people find them offensive. The historical terms have been around for decades, and shouldn't be removed from the top sections. 98.164.2.109 (talk) 16:33, 22 July 2023 (UTC)

(1) The words aren't being censored to begin with (they are mentioned in the Alternative Namings section), so WP:NOTCENSORED is not a relevant objection.

(2) They are moved not because some people find them offensive, but rather those wordings are being less-and-less used as time goes on, which is just a matter of fact of the world as it is now, and Wikipedia is reflecting that new fact.

Anyway "Master" and "Slave" take too much space to write than "Main" and "Sub" as used in the 2018 Analog Devices article, and that shorter wording suffices and fits better in the diagrams. Em3rgent0rdr (talk) 20:58, 22 July 2023 (UTC)

You say: "but rather those wordings are being less-and-less used as time goes on". I have to say that this is the first time in more than 15 years in the field when I see Main and Sub instead of Master and Slave.89.37.121.170 (talk) Apass (sorry, not registered user) 89.37.121.170 (talk) 06:57, 13 September 2023 (UTC)

"Main" and "Sub" actually have been used since the earliest programmable computers which had "sub" routines which were called by the "main" routine. That has been embodied ever since in C-derivative languages which name the entry function as the "main()" function. And GitHub since 2020 and GitLab since 2021 use "main" instead of "master".

Unfortunately with SPI nowadays different companies now use different terms instead of "master" and "slave", but there are still tons of datasheets that will persist with pin acronyms "MOSI" and "MISO", which "main" and "sub" at least conveniently have the same first letters. Em3rgent0rdr (talk) 15:27, 13 September 2023 (UTC)

Does not apply. A "subroutine" is a subcomponent of the main routine (or of another subroutine), whereas in this case the peripheral is not a subcomponent (part) of the host, but a separate entity that coexists in parallel with the host. If anything, it would be more like a "coroutine".

Rather than making up new names that hardly anybody has ever used in this context, which would lead to confusion, I'd prefer to use existing and descriptive ones, even if they don't match the acronyms. "Host" (or "controller") and "peripheral" (or "node") are more descriptive and historically used (*points at the P in SPI*). Cousteau (talk) 09:52, 19 November 2024 (UTC)

Embedded developer here. I would like to make a few points.

1. I've never heard of "main/subnode" before. It's confusing having anything but the well-established "master/slave" terminology, that people actually use and expect to see, in the intro section.
2. This battle should be fought on the master–slave (technology) article, not here. Unless that article is renamed, it makes no sense to clutter this page with the problem.
3. If there was an official source, with the authority to do so, that renamed it in the context of SPI, then there would be an argument to rename it here regardless of the previous point. However, as far as I know, there isn't one. (From skimming the above, it looks like Sparkfun's initiative is unofficial and therefore doesn't count.)
4. Using the words "master" and "slave" (or any other words) as technical labels does no harm to anyone, except readers who have already been conditioned by something else to have an unwanted emotional response to seeing those words. However, going out of one's way to use alternative words only exacerbates these negative associations. (Case in point: had this article just said master/slave in the first place, I would have scrolled through, read what I needed to, not been reminded of actual historical slavery at all, and gotten on with my day; instead, I've now had a lot of unwanted negative thoughts put in my head.) To put it another way, the idea that these words (or any words) are "problematic" is a self-fulfilling prophecy. We all want to see equality in the world, but changing a few words around does nothing to that end - it would be far more constructive to put effort towards actually solving real problems, and then no one would be worrying about this in the first place.

To this end, I've renamed this section's title to be relevant, removed the word "subservient" from the article, and rewritten the section on terminology positively. I've also adjusted the intro section to make the page as a whole read more sensibly, though I don't think the terms "main" and "sub" should be used throughout the article; "main device" and "peripheral device" would be much more correct. ~ Keiji (iNVERTED) (Talk) 14:29, 21 December 2023 (UTC)

A further thought: I'm actually a little surprised that nobody's suggested borrowing the term "host" from USB. Then we'd have HOPI/HIPO. ~ Keiji (iNVERTED) (Talk) 18:50, 21 December 2023 (UTC)

A big advantage of "Main" and "Sub" is that it preserves the signal abbreviations MOSI and MISO, and are short and unambiguous and expresses the same relationship as master/slave, making it an easy substitution, and were first done for SPI in 2018 in the analog devices (https://www.analog.com/en/analog-dialogue/articles/introduction-to-spi-interface.html) before all these other orgs started suggesting different SPI naming schemes. ("Main" and "Secondary" also preserves the abbreviation, but is a little longer.) "Host" does seem like a good word for master. I didn't notice any org using that before, but now I've searched and found Microchip uses "Host" and "Client": https://onlinedocs.microchip.com/pr/GUID-EF58F3A9-B49B-4C31-A7EC-B71EBB831870-en-US-5/index.html

I've never quite liked "Peripheral" cause that is more about relative location, not a relationship like Main/Sub, and its a long word to fit on diagrams. With SPI the central device's SPI could very well be operating in "slave" mode, for instance when setup to respond to input from a peripheral operating in "master" mode that could trigger at any time. Em3rgent0rdr (talk) 20:49, 21 December 2023 (UTC)

"Peripheral" is especially bad because the SPI controller is a peripheral device to the CPU, e.g. it sits on the Advanced Peripheral Bus on a Cortex MCU. So "Peripheral In" could be understood to mean both. 2001:9E8:141D:4C00:8338:C274:D340:F513 (talk) 10:43, 3 October 2024 (UTC)

You raise an interesting point because most of the alternatives provided here focus on which end is "the important device" and which one is "the peripheral", whereas "master" and "slave" are actually about "which side establishes the communication" and "which side responds", regardless of which one is the "important" one. This concept of "which side rules over the communication" has been historically referred to as the (rather unfortunate, in hindsight) names "master" and "slave", and I don't know if there is a commonly used terminology to use as an alternative. --Cousteau (talk) 10:17, 19 November 2024 (UTC)

No battle should be fought. Why would that page need to be renamed before this one can be improved? Nonsense.

SPI is clearly a technology that notable/large industry players have chosen as ground for their early steps toward a positive change. Given that, surely the Wikipedia page on that very topic would be one of the first to reflect the change happening in the world?

Yes, SPI is not a "real" standard. There is no singular authoritative body releasing a specification. However, there are a number of organisations that collectively hold a similar power over SPI as an ad-hoc standard and several of them already use different terminology (among other differences).

Your argument (3) is broken. There is no official SPI so judging something invalid for its "unofficial" status is unfathomable. Further, it actually sounds like a reason it should be less trouble to change this. Hey, maybe that's one of the reasons why Sparkfun et al. chose SPI!

Your statements are typical of those from one with unchecked privilege. It's interesting that seeing a pair of words that you weren't already used to seeing was the worst thing in the article for you. Your experience is not universal. Choname (talk) 04:17, 21 March 2024 (UTC)

Precisely because it's a de facto standard, what it represents is what the majority of adopters make it mean. The only way it will change is if a large enough number of adopters shift their interpretation of it. And even if Wikipedia did have the power to change it directly, that would be some sort of original research -- Wikipedia is not meant to do that. --Cousteau (talk) 09:59, 19 November 2024 (UTC)

The terms "Master" and "Slave" have been the common terms for the SPI bus over 40+ years, per mountains of historical published documents, thus should automatically take precedence in this article. This article should never have been converted over to new terms!! Per WP:NOTCENSORED, "Wikipedia may contain content that some readers consider objectionable or offensive‍—‌even exceedingly so. Attempting to ensure that articles and images will be acceptable to all readers, or will adhere to general social or religious norms, is incompatible with the purposes of an encyclopedia." 06:26, 21 March 2024 (UTC)

Why do certain sectors of American society have to be so bloody dumb, arrogant and cynical? Some news for you: "Master" has bugger all to do with your cotton plantations or whatever you associate it with. In fact, Master is a term of respect both in European and African societies as well as certain professions (law, nautical, …) As for "slave", if anyone is to take offence, that would be the actual Slavs, who hardly happen to be aware that the word has anything to do with them. Do grow up, for fuck's sake.

Intel Enhanced Serial Peripheral Interface Bus

This final section was surely added by an Intel marketing person: https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#Intel_Enhanced_Serial_Peripheral_Interface_Bus. The whole page provides a good balance of vendor-specific implementation and the core general knowledge of SPI. However, getting to the bottom of the page the reader is met with a small wall of text that is really just pro-Intel and the details don't help the general knowledge of SPI at all. This section should likely be housed elsewhere (and probably already is), with a link to that source and some choice SPI-specific details included here. --73.59.110.102 (talk) 05:49, 6 August 2020 (UTC)

I agree. The eSPI standard is sufficiently different to SPI to merit a new page with just a link from SPI. For example "1-bit, 2-bit, or 4-bit communications at speeds from 20 to 66 MHz", SPI is just a way to clock bits around, anything with this degree of formality is a totally different thing needs a new page. Mtpaley (talk) 18:43, 6 August 2020 (UTC)

Reads like a technical guide

Much of this article reads more like a technical reference or guide than an encyclopedic article, and really could use a rewrite with these guidelines in mind. The code example in particular really doesn't belong. Lots of it could be very useful on Wikibooks, Wikisource, and Wikiversity though! Jonathan FarnhamJ 22:08, 2 March 2021 (UTC)

I can't agree on a re-write. I've seen some re-writes recently from authors intending to fix an article; to make it adhere to WP guidelines. But, the result is garbage ... that adheres to the guidelines. Rules are good. But, quality is more than following rules. If there's info in the article that is too detailed, too technical, then let's remove it. Let's not throw out the baby with the bath water. Stevebroshar (talk) 15:15, 27 September 2024 (UTC)

SPI NAND

I don't understand why this section has been added. The article is about the SPI standard not types of flash storage. The linked article seems to be implying that using SPI on flash is somehow new but it has been commonly used for decades and it is irrelevent for this article if it is NAND/NOR or something exotic. It even says that their product offers 10 year retention and so can be used for boot code, I don't know about you but knowing that the computer in my car/tv/whatever only has a 10 year life seems like a strange advert. Why should this be kept? Mtpaley (talk) 10:15, 30 August 2021 (UTC)

• Section deleted Mtpaley (talk) 16:56, 3 September 2021 (UTC)

Capture timing

In the Data transmission section, the second of these sentences is not always correct:

"On the clock edge, both master and slave shift out a bit and output it on the transmission line to the counterpart. On the next clock edge, at each receiver the bit is sampled from the transmission line and set as a new least-significant bit of the shift register.".

The last sentence seems to contradict these two in the Clock phase and polarity section:

"SPI master and slave devices may well sample data at different points in that half cycle. This adds more flexibility to the communication channel between the master and slave.".

Confusion around this, including references to this article, has recently caused a few dozen engineer*hours at my day job. As a first attempt at explaining the complexity, would it be OK to change the sentences in the Data transmission section to remove some of the the specific detail:

"In each clock cycle, one bit is shifted from the sender to the receiver on each data line."

And change the sentences in the Clock phase and polarity section to:

"Some SPI devices sample data at different points in the clock cycle. For example, a SPI controller could sample incoming data immediately before it generates the same clock edge that will cause the peripheral device to output the next data. This technique is commonly used when accessing SPI memory chips, to provide the peripheral with almost a full clock cycle to output data rather than only a half cycle."

--Ianr44 (talk) 09:55, 2 September 2021 (UTC)

Does some of that confusion relate to the last paragraph of the ‘Mode numbers’ subsection?

It seems to make sense to have more general (and easily understood statements) earlier in the article. Reading halfway in shouldn’t be required to correct a reader’s misunderstanding from an earlier section - we’re not writing mystery novels here. 😊

Ianr44: If your believe your proposal has a sound technical basis and is well-sourced, please ‘be bold’ and make the change.

--Jim Grisham (talk) 14:42, 22 November 2021 (UTC)

Suggestion to remove stuff

IMO, the Development tools section is too loosely related to be warranted in this article. I suggest removal.

The Intel's Enhanced Serial Peripheral Interface section seems fine as a variant, but seems overly long. All other variants get just a few sentences. Is this variant so important it deserves such a long treatment? Stevebroshar (talk) 14:25, 28 September 2024 (UTC)