What were the first chips with hardware support for SPI?

Question

The SPI four-wire serial bus is a very common interface between chips and other small devices these days, but was originally developed by Motorola in the mid-1980s. What were the first Motorola and non-Motorola devices that supported SPI in hardware? Did they call it "SPI" or "Serial Peripheral Interface" (in the sense of, "this device conforms to the SPI pseudo-standard and should be able to talk to any other SPI device") at that time, or did that come later?

For devices that "run programs," such as CPUs and perhaps certain very flexible serial interface chips, I'm interested only in hardware that provided explicit support for dealing with the SPI physical layer timing without program intervention during communication. For example, if the program is responsible for dealing with the moment-to-moment details of clock phase (e.g., via bit-banging) rather than just specifying CPOL and CPHA settings at setup, I don't count that device as having "SPI hardware."

For peripheral devices, I'm interested only in ones that themselves directly implement SPI and use only one single slave select, not ones that can "support" SPI via adding an external shift register and extra address decoding or register selection outside of the standard SPI lines. In other words, all communication between the controller and the device is done via SCLK, MOSI and MISO, and the device is selected with a single S̅S̅ line.

Answer 1

The first Motorola microcontrollers having an integrated SPI interface were the MC6805S2, MC6805K2 and MC6805K3, available in 1983. See the Microprocessors and Peripherals databook of the time. I doubt other manufacturers had this available before Motorola (if we exclude discrete logic implementations using shift registers, and only consider complete MCUs or peripherals).

They were already identifying this as "Serial Peripheral Interface".

But note that SPI isn't a standard anyway. It is more a tradition in electronic engineering, and it is very easily abused by manufacturers. It is not implemented quite the same everywhere, and compatibility can break in some corner cases (especially with older devices).

In short, even now, you can't really say "this device conforms to the SPI pseudo-standard and should be able to talk to any other SPI device" without checking the datasheet details of the two devices you want to be talking together. So in 1983, I don't think it yet crossed the mind of anyone to consider this as a universal way of interfacing devices. It was probably initially seen as just something practical that could easily be interfaced with shift registers to expand the GPIO capabilities. For example, in the databook I linked, I have been unable to find a single peripheral who has a slave SPI interface. They are all supposed to be interfaced to the CPU through a regular memory interface (with address and data bus).

Answer 2

What were the first chips with hardware support for SPI?

Asking for any chip here is a bit fruitless, as this would end up by naming some synchronous serial chip of the 74xx line or even before. After all, SPI wasn't really a new invention but a formal description of the interface of next to any shift register.

The SPI block was meant to offer a generic, configurable interface to any kind of clocked serial transfer to the outside world. Input and/or output.

Serial transfer is the most simple way to communicate over the least amount of wires. The SPI block was created to handle this at the lowest possible level, one that can attach any hardware from a single flip-flop all the way to some (other) microcontroller. No matter if it's output, input, or even a mixture of both. All needed is the ability to clock in (or out) data when selected. It was meant to ease of the task of bit-banging from the CPU, while being as flexible as possible to attach as many existing devices that fit this protocol.

That's also the reason why Motorola even bothered to implement CPOL/CPHA at all - to make it compatible to as many existing serial shift devices as possible. If SPI would be just as a new bus there would be no need for additional modes, as Motorola could just have defined one mode as the one to be used and save all effort here.

So lets take, for the sake of it, a 74164 of 1973.

By anding SCK and SS to be feed into CLK (pin 8) and hooking up MOSI to A and B (Pin 1,3), the '164 will accept single byte transfers and display them on its output lines. A nice little 8 bit output port, and rather straight foreward, isn't it? And that's exactly the reason why SPI was made.

The SPI four-wire serial bus [...] originally developed by Motorola in the mid-1980s.

The earliest controller I know would be 1984, the earliest relevant patent I could find was registered in 1987 and granted in 1989 - but about a more complex high performance controller. To my knowledge, Motorola never tried to protect the basic SPI implementation/protocol. After all, doing so would have slowed adoption which may have not been a good idea to promote it.

What were the first Motorola [...] devices that supported SPI in hardware

I'd say the M68HC11 would make a good candidate. Introduced in 1984 it held a basic SPI interface assigned to 4 pins of Port D.

[What were the first] non-Motorola devices that supported SPI in hardware

Do Motorola licensees count? Like Philips had several controllers early on.

For sure the AVR family is completely separate from the Motorola world but was able to do SPI from the start by their Universal Serial Interface (USI) block. But that's 1996.

Did they [other manufacturers] call it "SPI" or "Serial Peripheral Interface" at that time, or did that come later?

AFAIK there has been never made a fuzz around using name or abbreviation, as Motorola did neither trademark or copyright the name ... would be hard anyway, as it's just a function description.

For peripheral devices, I'm interested only in ones that themselves directly implement SPI and use only one single slave select, not ones that can "support" SPI via adding an external shift register and extra address decoding or register selection outside of the standard SPI lines

Erm. You're missing the point. A shift register is already the peripheral device to be connected - not an intermediate part. Hook it up to a SPI port and it offers 8 input or output lines to extend the CPU's GPIO.

Answer 3

The first mention of SPI that I can find is in the Motorola data book Single-chip Microcomputer Data from 1984.¹

The three devices in that book that support "Serial Peripheral Interface" are the 6505K2/K3, 6505S2 and 68HC11A4. The data sheets for all of these are marked "This document contains information on a product under development. Motorola reserves the right to change or discontinue this product without notice." Contrasting this with "This document contains information on a new product" or no notice at all on other data sheets, I conjecture that these devices were not available for some time after the book had been printed, but the descriptions themselves make it clear that this is when SPI had been invented. (Nothing like it appears in the 1981 data book).

The 6805K2/K3 (227/275) data sheet and 6805S2 (390/438) description label the SPI interface pins differently from what eventually became the standard: SPIS (slave select, still active low, despite no overbar), SPICL (clock), and two pins both labeled SPID (data) which correspond to MISO and MOSI. (I guess at the time of writing they'd not figured out how to clearly separate the two, since they both do both input and output, depending on role.) The 68HC11A4 data sheet (599/647), however, uses the now-standard S̅S̅, SCK, MOSI and MISO designations.

The 6505K2/K3 data sheet gives no information on SPI, other than to say that it's there.

The 68HC11A4 data sheet, which describes it on the first page as "A New Serial Peripheral Interface" (emph. mine), provides little more: just a half page of text containing a brief description and a paragraph on each pin. (613/661) But the two sample system configurations they give (figure 5) are quite interesting. The first is a "Master-slave system configuration" consisting of five MC68HC11A4 MCUs, one master and four slaves. The second is the same hardware in a multi-master configuration (three master/slave, two slave).

The 6805S2 description, however, really gets into the details, providing an entire 25 page section on SPI (415/463) which describes not only the hardware but how to use it in many different ways.² Much of it, the majority in fact, discusses how to deal with bus arbitration using the clock line, the data line, a common select line or combinations of these. There's also discussion of addressing devices via addresses in the messages, rather than using select lines for this.

The example configuration in figure 4-15 (438/486) shows a three-wire daisy-chain configuration with slaves "MCU 1", "MCU 2" and "Peripheral" and master device "MCU 3." These all share a common slave select line with a pull-up resistor to Vcc. As the text mentions, all devices must understand some sort of protocol within the data stream to determine if messages are addressed to them, they should change the direction of information flow, and so on.

The example configuration in figure 4-16 (439/487) is three MCUs in a bus configuration, again sharing a common slave select line with a pull-up resistor to Vcc. This could be multi-master using any of a variety of arbitration methods described in the text.

All this attention paid to multiple masters, bus arbitration, suggestions of addressing in packets and so on makes me disagree with the the other answers here that suggest this was designed primarily as a simple way to talk to 74xxx shift registers and the like. The ability to do that as well was clearly something they had in mind (the 68HC11A4 data sheet mentions that it provides both "Interface With Low Cost 'Dumb' Peripherals" and "Interface With Intelligent Peripherals on Master/Slave Basis" (613/661)) since with some minimal design work it comes "for free," but the massive amount of work put into desiging for and describing bus arbitration and the multiple examples of multi-MCU systems, including multi-master multi-MCU systems, makes it clear that the intent was to provide a lot more.

As well demonstrating use of the SPI interface be used for MCU-MCU communication, Motorola had at least two peripherals in this catalogue explicitly claiming to use an SPI interface:

• MC68HC68A1: Serial 10-bit analog-to-digital converter. "Interface to the A/D converter is through a standard serial peripheral interface (SPI) unit." (623/671) This appears to use a two-way communication protocol with configuration commands sent to the chip and results and samples sent back to the controller, but the exact protocol isn't documented here.
• MC68HC68R1/2: 8-bit serial static RAMs. "Directly compatible with SPI interface." (624/672) And address/control byte followed by data bytes are sent to the RAM and (on reads) it sends back data bytes.

---

¹ Except where noted otherwise, page references here are to this book in the form "(nnn/mmm)" where nnn is the page number from section 3 and mmm is the page of the PDF document: "(227/275)" is page 3-227 in the book and page 275 of the PDF.

² Interestingly, the 6805S2 offers some extra capabilities in the SPI hardware let it (with a bit of software support) do one-wire operation without a clock line. (435/483) This is claimed to allow you to use the SPI hardware to communicate with the ACIA built-in to the 6801. This did not appear in later 68HC11 data sheets I've looked at. There's also discussion of configurations that today would not be considered "SPI," such as single-line half-duplex data transmission/reception.