Understanding SPI Timing: When Does the Data Become Valid?

A sometimes-confusing aspect of SPI communication is understanding why some devices require data to be read before a clock pulse, while others require a clock pulse before valid data becomes available. Many SPI tutorials focus on the four SPI modes, but they often skip the reason those modes exist in the first place. The answer lies in understanding when a device places data onto the communication line relative to the clock signal.

This discussion focuses on the timing relationship between the communicating devices. The exact SPI peripheral configuration required to achieve that timing may vary among microcontroller families.

In a recent project, this author used a 74HC597 parallel-to-serial shift register (Figure 1) as part of an absolute linear encoder interface. The encoder captures position bits in parallel and then shifts the position data out serially to an Arduino. This arrangement provides an excellent real-world example of why timing matters and why a device may effectively require a "read-then-clock" communication sequence.

Figure 1: Functional diagram of the Nexperia 74HC597 parallel to serial shift register. (Image source: Nexperia)

This article explores the difference between read-then-clock and clock-then-read timing and demonstrates why selecting the correct SPI phase is critical when working with shift registers and similar devices.

The first question to ask

When communicating with a serial device, the first question is not: Which SPI mode should I use?

Instead, ask: When does the first data bit become valid?

There are two common possibilities:

1. Read-Then-Clock – The first bit is already present on the data line before the first clock pulse (as with a 74HC597). The receiver must sample the bit before the clock edge that shifts the next bit into position, or the first bit may be lost.
2. Clock-Then-Read – The first clock pulse causes a new bit to appear on the data line (74HC165). The receiver must wait until after the clock pulse before reading.

Understanding when a device makes data valid often points toward the correct SPI phase setting, although the timing diagram should always be considered the final authority.

The 74HC597 example

The 74HC597 is an 8-bit parallel-in, serial-out shift register. During a load operation, eight parallel inputs are captured simultaneously.

Suppose the inputs contain: 10110010

After the load operation is completed, the register contains:

Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bit0

 1      0     1      1      0      0      1      0

At this moment, the most significant bit is already available at the serial output.

     1   0   1   1   0   0   1   0
     ^
     |
 First Bit

No clock pulses have occurred yet. The first bit is simply waiting to be read. This behavior is typical of many parallel-to-serial shift registers.

Why clocking first can lose data

Imagine the Arduino immediately generates a clock pulse.

Before the clock:

1 0 1 1 0 0 1 0

After the clock:

0 1 1 0 0 1 0 x

The original first bit has already shifted out of the register. The output now contains what was previously the second bit. If the Arduino reads after the shift occurs, the first bit has been lost and a bit of unknown value has replaced the last bit.

After a full 8 bit read:

Instead of receiving: 10110010

The received data becomes: 0110010x

Every bit is effectively shifted by one position. For some applications this results in completely incorrect data. In many debugging situations, an off-by-one bit shift is a strong indication that the data was sampled at the wrong time relative to the clock.

Read-then-clock operation

For devices such as the 74HC597, the communication sequence is conceptually:

Read Bit 7 – Clock - Read Bit 6 – Clock - Read Bit 5 - Clock...

Each clock pulse advances the next bit into position. The receiver captures the available bit first and then shifts the next bit into position.

Conceptually, a 74HC597 behaves like a read-then-clock device because the first bit already exists before clocking begins. In a hardware SPI implementation, the controller's sampling edge must simply occur before the edge that causes the next shift.

Seeing the concept in software

Software SPI, often called bit-banged SPI, makes the timing relationship easy to visualize.

A simplified read-then-clock implementation might look like (Figure 2):

Copy
byte value = 0;
for (int i = 0; i < 8; i++)		  //One loop for each of 8 bits
{
	value <<= 1;		  //Shift to left (fills LSB with 0)
	if (digitalRead(MISO))	  //Read MISO, if 1 replace LSB
		{value |= 1;}	
	digitalWrite(SCK, HIGH);  //Pulse the clock once
	digitalWrite(SCK, LOW);
}

Figure 2: Read then clock C++ programming example.

Notice the sequence inside the loop:

1. Read the data line.
2. Generate a clock pulse.
3. Repeat.

This directly matches the behavior required by a shift register that already presents its first bit.

Clock-then-read devices

Not all serial devices behave this way. Many SPI devices present or update their output data in response to a clock edge.  In this case the clock pulse occurs first because the device does not present valid data until the clock event occurs (Figure 3).

Copy
byte value = 0;
for (int i = 0; i < 8; i++)		  //One loop for each of 8 bits
{
	digitalWrite(SCK, HIGH);  //Pulse the clock once
	digitalWrite(SCK, LOW);
	value <<= 1;		  //Shift to left (fills LSB with 0)
	if (digitalRead(MISO))	  //Read MISO, if 1 replace LSB
		{value |= 1;}	
}

Figure 3: Clock then read C++ programming example.

For these devices the sequence is closer to:

1. Generate a clock pulse.
2. Read the data line.
3. Repeat.

Where SPI modes fit in

At this point the purpose of SPI modes becomes clearer. SPI modes allow the microcontroller to determine when data should be sampled relative to the clock.

A useful way to think about SPI phase is:

• Data Already Exists - The device presents valid data before the clock edge occurs. The receiver samples first and shifts later.
• Clock Creates Data - The device outputs new data in response to the clock edge. The receiver waits until after the clock event before sampling.

Rather than memorizing mode numbers, many engineers begin by studying the timing diagram and asking: Is the first bit already available, or does the clock create it? The answer typically reveals the correct phase relationship.

A brief note about SPI modes

SPI modes are defined by two settings:

• CPOL (Clock Polarity) determines whether the clock idles high or low.
• CPHA (Clock Phase) determines whether data is sampled on the first or second clock edge.

For many shift register applications, the most important setting is CPHA because it determines whether sampling occurs before or after the clock edge that shifts data. Devices that present valid data prior to the first sampling edge are often compatible with CPHA = 0 operation, while devices that update data in response to the initial clock edge often require CPHA = 1. The exact mode depends on both CPHA and CPOL and should always be verified against the timing diagram.

The exact SPI mode as shown in Figure 4 should always be verified using the device timing diagram, but understanding whether a device is operating as a read-then-clock or clock-then-read system often makes the correct phase selection much easier to determine.

Figure 4: SPI mode chart.

Rather than memorizing these four combinations, it is often more useful to understand why the device requires a particular phase relationship in the first place.

Relationship to an absolute encoder

In the linear encoder project described previously, the 74HC597 captures the state of multiple position-sensing elements and converts that information into a serial data stream. Once the data is loaded into the shift register, the most significant bit is already present at the serial output.

Suppose the encoder position value is: 10100110

Immediately after loading: Serial Output = 1

No clock pulses have occurred yet. The controller must capture that bit before shifting the register.

Otherwise, the first bit is lost and the entire position value becomes misaligned. This is why some encoder interfaces appear to require a read-then-clock sequence. The data is already available before the serial transfer begins.

Thinking beyond SPI modes

Many SPI tutorials begin with Mode 0, Mode 1, Mode 2, and Mode 3. While those settings are important, they sometimes obscure the more fundamental question: When is the data valid?

Once it is determined that a device is operating as a read-then-clock or clock-then-read system, the purpose of clock phase becomes much easier to understand. The SPI mode is not an arbitrary software setting. It is simply a way to match the microcontroller's timing to the behavior of the device on the other end of the connection.

Other SPI peripheral considerations

While the data-valid concepts discussed here apply broadly to SPI devices and shift registers, some microcontrollers implement SPI peripherals with additional timing options beyond the standard CPOL and CPHA settings. In these cases, selecting the correct SPI mode may be necessary but not sufficient. Input delays, output delays, dummy cycles, clock rates, and other peripheral-specific settings can also affect communication. Always verify operation against both the device timing diagram and the microcontroller's SPI peripheral documentation.

Conclusion

In many cases, the critical SPI parameter is not clock polarity (CPOL) but clock phase (CPHA), because phase determines whether data is sampled before or after the clock edge that shifts the next bit into position.

The 74HC597 provides an excellent example of why SPI timing matters. After data is loaded into the shift register, the first bit is already present at the serial output. Reading that bit before shifting ensures that no information is lost. Other devices operate differently and generate valid data only after a clock edge occurs.

Understanding this distinction helps explain why SPI phase settings exist and why selecting the correct mode is so important. Instead of memorizing four SPI modes, start by examining the device's timing diagram and asking a simple question: Is the data already waiting to be read, or does the clock pulse create the data? The answer often reveals everything you need to know about how the interface should be configured.