Chat en direct avec un représentant Tek. Service disponible de 9 h à 17 h, CET jours ouvrables.


Appelez-nous au

Disponible de 9 h à 17 h CET jours ouvrables.


Télécharger des manuels, des fiches techniques, des logiciels, etc. :



Tackling SPI Bus Design, Decode and Debug Challenges


Figure 1: 4-wire SPI

In today’s embedded, Internet of Things (IoT) world it seems like everyone has a development board to offer. Boards like those from Arduino, and Raspberry Pi are being used to educate a whole new generation of engineers and hobbyists alike. These development boards have processors complete with GPIO, analog inputs, UARTs, timers, and of course I2C and SPI. It is serial communication, specifically the Serial Peripheral Interface (SPI) that will be our focus here.

SPI uses a full duplex communication protocol with a master/slave architecture. In its simplest description, SPI is used by processors, sensors, memory, and other peripherals to send data to one another. SPI is also what is known as a “de facto” standard. This means that there is no formal standard (in contrast to I2C), and as such you will find a wide variation of implementations. It is common to find different word sizes, clocking schemes and even 2- to 5-wire interfaces. These variations can cause a lot of design debug issues. For the purposes of this post, we will focus on the most common 4-wire interface.

As seen in Figure 1, the simple 4-wire version of SPI uses a clock line, two data lines, and a select line. Some manufacturers may refer to this as a 3-wire interface; choosing to treat the select line separately from the clock and data lines.

The signal lines for SPI are typically defined as:

  • Master Out Slave In (MOSI): The Master generates the signal received by the Slave.
  • Master In Slave Out (MISO): The Slave generates the signal received by the Master.
  • Serial Clock (SCLK or SCK): The Master generates the clock signal to synchronize data transfers     between the Master and the Slave.
  • Slave Select (SS)/Chip Select (CS): The Master generates the signal to select individual Slave devices.


With SPI there are two types of slave configurations: cascaded (Figure 2) and independent (Figure 3). Most embedded applications will use an independent configuration because of the need to control and interact with specific SPI peripherals.



Figure 2: 4-wire SPI cascaded configuration                         Figure 3: 4-wire SPI independent configuration


Of the serial communication protocols, SPI is capable of the fastest speeds and is capable of handling multiple slaves from a single master device. As you look at throughput rates, you should also consider the number of wires required by SPI. As you add additional Slaves the number of wires can become worrisome. The combination of configurations (and associated wires) along with the previously mentioned implementation variations can rapidly become a test and debug challenge.

When designing a system that uses an SPI bus, a single signal often includes address, control, data, and clock information. This can make isolating events of interest difficult. Using an MSO/DPO2000B oscilloscope you can not only view all those signals, but can also trigger on events of interest. Adding a DPO2EMBD application module lets you decode the transmitted data right on your oscilloscope, avoiding the hassle of manually decoding the data bit by bit. Automatic trigger, decode and search on bus events and conditions gives you a robust set of tools for debugging serial buses. Now you can automatically trigger, decode and search for serial packet content like start of package, address, data and more, right on your oscilloscope.  Debug of your complex design has never been simpler or faster.