SPI data transfer sequence in Embedded C - Deep Dive

Overview - SPI data transfer sequence

What is it?

SPI data transfer sequence is the step-by-step process used to send and receive data between devices using the Serial Peripheral Interface (SPI) protocol. SPI is a way for microcontrollers and sensors or other chips to talk to each other quickly using four wires. The sequence controls how bits move in and out, ensuring both sides understand each other.

Why it matters

Without a clear SPI data transfer sequence, devices would not know when to send or listen for data, causing communication errors or lost information. This would make many embedded systems unreliable, like sensors giving wrong readings or displays showing garbage. SPI data transfer sequence ensures fast, synchronized, and error-free data exchange, which is critical for real-time control and sensing in electronics.

Where it fits

Before learning SPI data transfer sequence, you should understand basic digital signals and microcontroller pins. After this, you can learn how to configure SPI hardware registers and write drivers to use SPI in real projects.

Mental Model

Core Idea

SPI data transfer sequence is a timed dance where one device sends bits while the other listens, synchronized by a clock signal, so both share data perfectly.

Think of it like...

Imagine two people passing a secret message using flashlights in a dark room. One flashes a light on or off to send bits, while the other watches carefully, both following a rhythm set by a metronome to stay in sync.

┌───────────────┐      ┌───────────────┐
│ Master Device │─────▶│ Slave Device  │
└───────────────┘      └───────────────┘
      │                      ▲
      │ MOSI (Master Out)     │ MISO (Slave Out)
      │                      │
      ▼                      │
  ┌─────────┐   SCLK (Clock) ─┤
  │ Clock   │◀────────────────┘
  └─────────┘

Sequence:
1. Master pulls SS low to select slave
2. Master sends clock pulses on SCLK
3. On each clock, master sends bit on MOSI
4. Slave reads MOSI and sends bit on MISO
5. After all bits, master releases SS

Build-Up - 7 Steps

1

Foundation

Understanding SPI Basic Signals

Concept: Introduce the four main SPI signals and their roles.

SPI uses four wires: MOSI (Master Out Slave In), MISO (Master In Slave Out), SCLK (Serial Clock), and SS (Slave Select). MOSI sends data from master to slave. MISO sends data from slave to master. SCLK is the clock signal from master to synchronize data bits. SS tells the slave when to listen.

Result

You know what each SPI wire does and why they are needed.

Knowing the role of each wire is essential to understand how data moves and how devices stay synchronized.

2

Foundation

Bitwise Data Transfer Concept

Concept: Data is sent one bit at a time, synchronized by clock pulses.

SPI sends data bit by bit. On each clock pulse, the master sends one bit on MOSI, and the slave reads it. Simultaneously, the slave sends one bit on MISO, and the master reads it. This happens for 8 or more bits depending on data size.

Result

You understand that SPI transfers data serially, one bit per clock cycle.

Realizing data moves bitwise helps grasp why timing and clock signals are critical.

3

Intermediate

Starting and Ending a Transfer

Concept: The slave select (SS) line controls when a transfer begins and ends.

Before sending data, the master pulls the SS line low to select the slave device. This tells the slave to prepare for data. After all bits are sent, the master sets SS high to end communication. This prevents other devices from interfering.

Result

You know how devices know when to start and stop talking.

Understanding SS control prevents data collisions and ensures only the intended device communicates.

4

Intermediate

Clock Polarity and Phase Effects

🤔Before reading on: do you think data is always read on the clock's rising edge? Commit to your answer.

Concept: Clock polarity (CPOL) and phase (CPHA) settings determine when data is sampled and shifted.

SPI can use different clock settings: CPOL controls the idle state of the clock (high or low), and CPHA controls whether data is sampled on the first or second clock edge. These settings must match on both devices to communicate correctly.

Result

You understand why SPI devices have modes and how clock settings affect data timing.

Knowing clock modes helps avoid mysterious communication errors caused by timing mismatches.

5

Intermediate

Full-Duplex Data Transfer Explained

Concept: SPI can send and receive data simultaneously during one transfer.

While the master sends data on MOSI, the slave sends data back on MISO at the same time. This is called full-duplex. Both devices shift out and shift in bits together, synchronized by the clock.

Result

You see how SPI can exchange data both ways in one go, making it fast and efficient.

Understanding full-duplex clarifies why SPI is preferred for fast, two-way communication.

6

Advanced

Handling Multi-Byte Transfers

🤔Before reading on: do you think SPI automatically knows how many bytes to send? Commit to your answer.

Concept: SPI transfers multiple bytes by repeating the bit sequence while keeping SS low.

To send more than one byte, the master keeps SS low and sends multiple 8-bit sequences back to back. The slave keeps reading and sending bytes until SS goes high. The software or hardware must manage how many bytes to send.

Result

You understand how longer messages are sent over SPI and the role of SS in framing data.

Knowing multi-byte handling prevents partial data reads and ensures complete message transfer.

7

Expert

SPI Transfer Timing and Hardware Buffers

🤔Before reading on: do you think SPI hardware always sends data instantly when clock ticks? Commit to your answer.

Concept: SPI hardware uses shift registers and buffers to manage timing and data flow efficiently.

Inside SPI hardware, shift registers move bits out and in synchronized with the clock. Buffers hold data bytes before and after transfer to allow continuous streaming without CPU delays. Interrupts or DMA can be used to handle data without blocking the processor.

Result

You see how SPI hardware optimizes data transfer timing and reduces CPU load.

Understanding hardware internals helps design efficient SPI drivers and avoid timing bugs in real systems.

Under the Hood

SPI works by using a shift register inside both master and slave devices. When the master generates a clock pulse, both devices shift one bit out and one bit in simultaneously. The SS line enables the slave's shift register to connect to the bus. The clock polarity and phase settings control exactly when bits are sampled and shifted, ensuring both devices stay in sync. Hardware buffers and interrupts help manage continuous data streams without CPU waiting.

Why designed this way?

SPI was designed for simplicity and speed in embedded systems. Using separate lines for data in and out allows full-duplex communication, unlike older protocols that only send or receive at a time. The clock line ensures precise timing without complex handshakes. This design trades off longer wiring for faster, simpler communication, ideal for short-distance chip-to-chip links.

┌───────────────┐       ┌───────────────┐
│   Master      │       │    Slave      │
│ ┌───────────┐ │       │ ┌───────────┐ │
│ │ Shift Reg │ │◀─────▶│ │ Shift Reg │ │
│ └───────────┘ │       │ └───────────┘ │
│      │        │       │       │       │
│  MOSI│        │       │MISO   │       │
│  MISO│        │       │MOSI   │       │
│  SCLK│────────┼──────▶│SCLK   │       │
│  SS  │────────┼──────▶│SS     │       │
└──────┴────────┘       └───────┴───────┘

Clock pulses shift bits out and in simultaneously.
SS enables slave's shift register connection.

Myth Busters - 4 Common Misconceptions

Quick: Does SPI always send data only from master to slave? Commit yes or no.

Common Belief: SPI only sends data from the master to the slave device.

Reality: SPI sends data both ways at the same time (full-duplex), with master sending on MOSI and slave sending on MISO simultaneously.

Why it matters: Assuming one-way data flow can cause bugs where the master misses data sent back by the slave, leading to incomplete communication.

Quick: Is the slave select (SS) line optional in SPI communication? Commit yes or no.

Common Belief: The SS line is optional and can be left unused if only one slave is connected.

Reality: SS is essential to tell the slave when to listen and when to ignore the bus. Without SS, the slave may misinterpret noise as data.

Why it matters: Ignoring SS can cause data corruption and unpredictable device behavior, especially in multi-slave setups.

Quick: Does changing clock polarity (CPOL) affect data correctness? Commit yes or no.

Common Belief: Clock polarity settings do not affect SPI data transfer correctness.

Reality: CPOL and CPHA settings must match on both devices; otherwise, data bits are sampled at wrong times, causing errors.

Why it matters: Mismatched clock settings cause silent data corruption, which is hard to debug in embedded systems.

Quick: Can SPI hardware automatically detect message length? Commit yes or no.

Common Belief: SPI hardware knows how many bytes to send or receive automatically.

Reality: SPI hardware just shifts bits; software or higher-level protocols must manage message length and framing.

Why it matters: Assuming automatic length detection leads to incomplete or extra data being read, causing communication failures.

Expert Zone

1

Some SPI devices require specific timing delays between SS assertion and clock start, which can cause subtle bugs if ignored.

2

Using DMA with SPI can greatly improve throughput but requires careful buffer alignment and synchronization.

3

In multi-slave systems, managing SS lines and bus contention is critical; some designs use hardware decoders or GPIO expanders for SS control.

When NOT to use

SPI is not suitable for long-distance communication or networks with many devices. For those cases, protocols like I2C, UART, or CAN bus are better because they support addressing and error checking.

Production Patterns

In real systems, SPI is often used with interrupt-driven or DMA-based drivers for efficient data transfer. Multi-byte transfers are wrapped in higher-level protocols with checksums. SS lines are controlled by GPIOs or hardware peripherals, and clock settings are carefully matched to device datasheets.

Connections

I2C Protocol

Both are serial communication protocols but differ in wiring and addressing.

Understanding SPI's simple four-wire full-duplex design helps contrast it with I2C's two-wire half-duplex bus with addressing, clarifying trade-offs in embedded communication.

Synchronous vs Asynchronous Communication

SPI is synchronous, relying on a clock signal, unlike asynchronous protocols like UART.

Knowing SPI's synchronous nature explains why timing and clock polarity matter, unlike asynchronous methods where start/stop bits handle timing.

Human Conversation Timing

SPI's clock synchronization is like two people speaking in rhythm to avoid talking over each other.

Recognizing the importance of timing in communication helps understand why SPI uses a clock line to coordinate data exchange precisely.

Common Pitfalls

#1 Ignoring the SS line and leaving it always high.

Wrong approach:

/* Master code without SS control */
// SPI transfer without pulling SS low
spi_send_byte(0x55);

Correct approach:

/* Master code with SS control */
set_SS_low();
spi_send_byte(0x55);
set_SS_high();

Root cause:

Misunderstanding that SS signals the slave to listen, causing the slave to ignore data or misinterpret noise.

#2 Mismatching clock polarity and phase between master and slave.

Wrong approach:

/* Master uses CPOL=0, CPHA=0; Slave uses CPOL=1, CPHA=1 */
spi_init(CPOL_0 | CPHA_0);
// Slave configured differently

Correct approach:

/* Both master and slave use same CPOL and CPHA */
spi_init(CPOL_0 | CPHA_0);
// Slave configured identically

Root cause:

Assuming default clock settings work for all devices without checking datasheets.

#3 Sending multi-byte data but toggling SS between bytes.

Wrong approach:

set_SS_low();
spi_send_byte(0x12);
set_SS_high();
set_SS_low();
spi_send_byte(0x34);
set_SS_high();

Correct approach:

set_SS_low();
spi_send_byte(0x12);
spi_send_byte(0x34);
set_SS_high();

Root cause:

Not realizing that SS must stay low for the entire multi-byte transfer to keep slave selected.

Key Takeaways

SPI data transfer sequence is a precise timing process where master and slave exchange bits synchronized by a clock and controlled by a slave select line.

Understanding the roles of MOSI, MISO, SCLK, and SS wires is essential to grasp how SPI communication works.

Clock polarity and phase settings must match on both devices to avoid silent data corruption.

SPI supports full-duplex communication, sending and receiving data simultaneously, making it fast and efficient.

Proper management of SS line and multi-byte transfers ensures reliable data framing and prevents communication errors.

Practice

1. In SPI communication, what happens during a data transfer sequence?

easy

A. Data is only sent, no data is received.

B. Data is sent and received simultaneously, one byte at a time.

C. Data is received first, then sent after completion.

D. Data is sent in large blocks without waiting for response.

Solution

1. Step 1: Understand SPI full-duplex nature

   SPI sends and receives data simultaneously, byte by byte.

2. Step 2: Confirm data transfer behavior

   Each byte sent triggers a byte received at the same time.

3. Final Answer:

   Data is sent and received simultaneously, one byte at a time. -> Option B

4. Quick Check:

   SPI full-duplex = simultaneous send/receive [OK]

Hint: Remember SPI sends and receives one byte at a time simultaneously [OK]

Common Mistakes:

• Thinking SPI only sends data without receiving
• Assuming data is received after all sending completes
• Believing SPI transfers data in large blocks

2. Which of the following code snippets correctly waits for SPI transfer completion before reading received data?

easy

A. while(!(SPI_SR & SPI_SR_RXNE)); uint8_t data = SPI_DR;

B. uint8_t data = SPI_DR; while(!(SPI_SR & SPI_SR_RXNE));

C. while(SPI_SR & SPI_SR_BSY); uint8_t data = SPI_DR;

D. while(!(SPI_SR & SPI_SR_TXE)); uint8_t data = SPI_DR;

Solution

1. Step 1: Identify the correct flag for received data ready

   SPI_SR_RXNE indicates data received and ready to read.

2. Step 2: Confirm waiting loop and reading order

   Wait until RXNE is set, then read SPI_DR to get received byte.

3. Final Answer:

   while(!(SPI_SR & SPI_SR_RXNE)); uint8_t data = SPI_DR; -> Option A

4. Quick Check:

   Wait RXNE flag before reading data [OK]

Hint: Wait for RXNE flag before reading SPI data register [OK]

Common Mistakes:

• Waiting for TXE instead of RXNE
• Reading data before checking RXNE flag
• Waiting for BSY flag incorrectly

3. Given the following code snippet, what will be the content of the array received[3] after execution?

uint8_t data_to_send[3] = {0xA1, 0xB2, 0xC3};
uint8_t received[3];
for(int i = 0; i < 3; i++) {
  SPI_DR = data_to_send[i];
  while(!(SPI_SR & SPI_SR_RXNE));
  received[i] = SPI_DR;
}

medium

A. [0xA1, 0xB2, 0xC3]

B. [unknown garbage values]

C. [data received from SPI slave during transfer]

D. [0x00, 0x00, 0x00]

Solution

1. Step 1: Understand SPI transfer behavior

   Each byte sent causes a byte to be received simultaneously from the slave device.

2. Step 2: Analyze received array assignment

   received[i] stores the byte read from SPI_DR after waiting for RXNE flag.

3. Final Answer:

   Data received from SPI slave during transfer -> Option C

4. Quick Check:

   Received array = slave response bytes [OK]

Hint: Received data is from slave, not the sent bytes [OK]

Common Mistakes:

• Assuming received data equals sent data
• Ignoring that SPI_DR reads slave response
• Expecting zeros or uninitialized values

4. Identify the error in this SPI data transfer loop:

for(int i = 0; i < 4; i++) {
  SPI_DR = data[i];
  received[i] = SPI_DR;
  while(!(SPI_SR & SPI_SR_RXNE));
}

medium

A. Loop counter exceeds array size.

B. Not sending data before reading.

C. Missing SPI enable command.

D. Reading SPI_DR before waiting for RXNE flag.

Solution

1. Step 1: Check order of reading SPI_DR and waiting for RXNE

   The code reads SPI_DR before waiting for RXNE flag, which is incorrect.

2. Step 2: Correct sequence for SPI read

   Must wait for RXNE flag before reading SPI_DR to get valid received data.

3. Final Answer:

   Reading SPI_DR before waiting for RXNE flag. -> Option D

4. Quick Check:

   Wait RXNE before reading SPI_DR [OK]

Hint: Always wait RXNE flag before reading SPI_DR [OK]

Common Mistakes:

• Reading SPI_DR too early
• Ignoring RXNE flag status
• Assuming data is ready immediately after writing

5. You want to send an array of 5 bytes over SPI and store the received bytes simultaneously. Which code snippet correctly implements this transfer sequence?

hard

A. for(int i=0; i<5; i++) { SPI_DR = tx[i]; while(!(SPI_SR & SPI_SR_RXNE)); rx[i] = SPI_DR; }

B. for(int i=0; i<5; i++) { while(!(SPI_SR & SPI_SR_TXE)); SPI_DR = tx[i]; rx[i] = SPI_DR; }

C. for(int i=0; i<5; i++) { SPI_DR = tx[i]; rx[i] = SPI_DR; while(!(SPI_SR & SPI_SR_RXNE)); }

D. for(int i=0; i<5; i++) { while(SPI_SR & SPI_SR_BSY); SPI_DR = tx[i]; rx[i] = SPI_DR; }

Solution

1. Step 1: Confirm correct order of operations

   Send byte by writing SPI_DR, wait for RXNE flag, then read received byte.

2. Step 2: Validate correct snippet

   The correct snippet writes SPI_DR, waits for RXNE, then reads SPI_DR into rx array correctly.

3. Step 3: Check distractors for errors

   Others read SPI_DR before RXNE is set, read before waiting, or wait for incorrect flags like BSY.

4. Final Answer:

   for(int i=0; i<5; i++) { SPI_DR = tx[i]; while(!(SPI_SR & SPI_SR_RXNE)); rx[i] = SPI_DR; } -> Option A

5. Quick Check:

   Send, wait RXNE, then read = correct SPI transfer [OK]

Hint: Send byte, wait RXNE flag, then read received byte [OK]

Common Mistakes:

• Reading SPI_DR before RXNE flag is set
• Not waiting for transfer completion
• Confusing TXE and RXNE flags