Start and stop conditions in Embedded C - Deep Dive

Overview - Start and stop conditions

What is it?

Start and stop conditions are special signals used in communication protocols like I2C to mark the beginning and end of data transfer between devices. The start condition tells devices to get ready to send or receive data, while the stop condition signals that the communication is finished. These conditions help devices know when to listen or talk on the shared communication line.

Why it matters

Without clear start and stop signals, devices on a shared communication line would not know when a message begins or ends, causing confusion and data errors. This would be like trying to have a conversation without knowing when someone starts or stops talking. Start and stop conditions ensure reliable and organized data exchange, which is critical in embedded systems controlling sensors, displays, and other hardware.

Where it fits

Before learning start and stop conditions, you should understand basic digital signals and how devices communicate using protocols like I2C. After mastering start and stop conditions, you can learn about data framing, acknowledgments, and error handling in communication protocols.

Mental Model

Core Idea

Start and stop conditions are special signals that tell devices when to begin and end communication on a shared data line.

Think of it like...

It's like raising your hand to start speaking in a group and lowering it to show you're done, so others know when to listen or talk.

┌───────────────┐
│ Shared Bus    │
│ (SDA & SCL)   │
└──────┬────────┘
       │
       ▼
┌───────────────┐       ┌───────────────┐
│ Master Device │──────▶│ Slave Device  │
└───────────────┘       └───────────────┘

Start Condition: SDA line goes LOW while SCL is HIGH
Stop Condition: SDA line goes HIGH while SCL is HIGH

Build-Up - 6 Steps

1

Foundation

Understanding I2C Bus Basics

Concept: Introduce the I2C bus lines and their roles in communication.

I2C uses two lines: SDA (data) and SCL (clock). Both lines are open-drain, meaning devices can pull them LOW but not drive them HIGH directly. Pull-up resistors keep lines HIGH when no device pulls them LOW. Devices communicate by changing these lines' states in a timed way.

Result

You know the physical lines and electrical behavior that form the basis for start and stop conditions.

Understanding the electrical nature of SDA and SCL lines is essential because start and stop conditions depend on specific changes on these lines.

2

Foundation

Defining Start and Stop Conditions

Concept: Learn the exact signal changes that define start and stop conditions on the I2C bus.

A start condition happens when SDA changes from HIGH to LOW while SCL is HIGH. A stop condition happens when SDA changes from LOW to HIGH while SCL is HIGH. These transitions are unique and cannot be confused with normal data bits, which change only when SCL is LOW.

Result

You can identify start and stop conditions by observing SDA and SCL line changes.

Knowing the exact timing and line states that define start and stop conditions helps devices recognize communication boundaries reliably.

3

Intermediate

Start Condition in Communication Flow

🤔Before reading on: Do you think the start condition can occur anytime during data transfer or only at the beginning? Commit to your answer.

Concept: Understand when and why the start condition is sent in a communication sequence.

The master device sends a start condition to signal the beginning of a communication session. This alerts all slave devices to listen for their address. The start condition can also be repeated to keep control of the bus without releasing it.

Result

You see how the start condition initiates communication and can be used multiple times to chain messages.

Recognizing that start conditions mark communication start and can be repeated prevents bus conflicts and enables complex data exchanges.

4

Intermediate

Stop Condition and Bus Release

🤔Before reading on: Does the stop condition only end communication or can it also reset the bus? Commit to your answer.

Concept: Learn how the stop condition ends communication and frees the bus for others.

The stop condition signals the end of data transfer. After the stop, the bus lines return to idle (both HIGH), allowing other devices to start communication. If a device holds the bus too long without a stop, others cannot communicate.

Result

You understand how stop conditions ensure orderly bus sharing among devices.

Knowing that stop conditions release the bus helps prevent deadlocks and ensures smooth multi-device communication.

5

Advanced

Repeated Start Condition Usage

🤔Before reading on: Do you think repeated start conditions are optional or necessary in multi-part messages? Commit to your answer.

Concept: Explore how repeated start conditions allow multiple messages without releasing the bus.

A repeated start condition is a start sent without a preceding stop. It lets the master keep control of the bus to send another message immediately. This is useful for reading data after writing an address without interruption.

Result

You see how repeated starts improve efficiency and prevent other devices from interrupting.

Understanding repeated starts reveals how complex communication sequences maintain bus control and data integrity.

6

Expert

Start/Stop Conditions in Hardware Implementation

🤔Before reading on: Are start and stop conditions generated purely by software or hardware in embedded systems? Commit to your answer.

Concept: Learn how microcontrollers generate and detect start and stop conditions at the hardware level.

Most microcontrollers have hardware modules that detect start and stop conditions by monitoring SDA and SCL lines. They generate interrupts or flags for software to respond. Hardware handles timing precisely, reducing software load and errors. Software can also manually generate these signals by controlling pins directly in bit-banging.

Result

You understand the balance between hardware automation and software control in managing start and stop conditions.

Knowing hardware involvement explains why start/stop detection is reliable and how software can optimize communication timing.

Under the Hood

Start and stop conditions are detected by monitoring the SDA and SCL lines' voltage levels. The bus uses open-drain outputs with pull-up resistors, so devices pull lines LOW to signal. The start condition is a HIGH-to-LOW transition on SDA while SCL is HIGH, which is unique and triggers devices to prepare for data. The stop condition is a LOW-to-HIGH transition on SDA while SCL is HIGH, signaling the end of communication. Hardware modules in microcontrollers watch these transitions and set flags or interrupts for software to handle data transfer.

Why designed this way?

The design uses line transitions during SCL HIGH because data bits only change when SCL is LOW, so these transitions cannot be mistaken for data. Open-drain lines with pull-ups allow multiple devices to share the bus safely without electrical conflicts. This method was chosen for simplicity, reliability, and minimal wiring, making I2C popular for embedded systems.

┌───────────────┐
│ SDA Line      │
│               │
│  HIGH ────────┐    Start: HIGH→LOW while SCL HIGH
│              ││
│  LOW  ────────┘
│               │
│ SCL Line      │
│               │
│  HIGH ────────────────
│               │
│  LOW  ────────────────
└───────────────┘

Start Condition: SDA falls while SCL is HIGH
Stop Condition: SDA rises while SCL is HIGH

Myth Busters - 4 Common Misconceptions

Quick: Does the start condition happen when SDA goes LOW at any time? Commit to yes or no.

Common Belief: The start condition is just when SDA goes LOW, no matter what SCL is doing.

Reality: The start condition only occurs when SDA goes from HIGH to LOW while SCL is HIGH. If SCL is LOW, it's just data changing.

Why it matters: Misunderstanding this causes devices to misinterpret data bits as start signals, leading to communication errors.

Quick: Can a stop condition happen while SCL is LOW? Commit to yes or no.

Common Belief: The stop condition can happen anytime SDA goes HIGH, regardless of SCL.

Reality: The stop condition only happens when SDA goes from LOW to HIGH while SCL is HIGH.

Why it matters: Incorrect stop detection can cause devices to think communication ended prematurely, causing data loss.

Quick: Is it safe to ignore repeated start conditions in I2C communication? Commit to yes or no.

Common Belief: Repeated start conditions are optional and can be replaced by stop then start.

Reality: Repeated starts are essential in some cases to keep bus control without releasing it, especially for combined write-read operations.

Why it matters: Ignoring repeated starts can cause bus conflicts or failed data reads in multi-part transactions.

Quick: Do software-only implementations detect start/stop conditions as reliably as hardware? Commit to yes or no.

Common Belief: Software can detect start and stop conditions just as reliably as hardware modules.

Reality: Hardware modules detect these conditions more reliably and with precise timing, while software detection can miss or delay signals.

Why it matters: Relying solely on software detection can cause timing errors and communication failures in fast or complex systems.

Expert Zone

1

Start and stop conditions must be glitch-free; electrical noise can cause false triggers, so hardware filters or software debouncing are often used.

2

Repeated start conditions allow atomic multi-message transactions, preventing other masters from interrupting the bus mid-communication.

3

In multi-master setups, arbitration uses start and stop conditions combined with data bits to decide which master controls the bus.

When NOT to use

Start and stop conditions are specific to protocols like I2C. For high-speed or complex communication, protocols like SPI or UART do not use these conditions and rely on different signaling. Use start/stop conditions only when working with bus protocols that require them.

Production Patterns

In production embedded systems, start and stop conditions are managed by hardware I2C controllers with interrupt-driven software handlers. Repeated starts are used for sensor read sequences. Error handling includes detecting missing stop conditions to reset the bus. Bit-banging implementations carefully time start/stop signals to avoid bus conflicts.

Connections

Semaphore in Operating Systems

Both manage access control and signaling between multiple agents.

Understanding start and stop conditions as signals to control bus access is similar to how semaphores control resource access in OS, helping grasp synchronization concepts.

Handshake Protocols in Networking

Start and stop conditions act like handshake signals to establish and terminate communication sessions.

Recognizing start/stop as handshake signals clarifies their role in ensuring both sides agree on communication timing, similar to network protocols.

Traffic Lights in Road Systems

Start and stop conditions regulate when devices can 'go' or 'stop' on a shared communication line.

Seeing start/stop as traffic signals helps understand how orderly communication prevents collisions and confusion on shared lines.

Common Pitfalls

#1 Misinterpreting data line changes as start or stop conditions.

Wrong approach:

Detect start condition whenever SDA goes LOW, ignoring SCL state.

Correct approach:

Detect start condition only when SDA goes from HIGH to LOW while SCL is HIGH.

Root cause:

Not considering the clock line state leads to false detection of communication boundaries.

#2 Failing to send a stop condition after communication.

Wrong approach:

Master sends data but never releases the bus with a stop condition.

Correct approach:

Master sends a stop condition by transitioning SDA from LOW to HIGH while SCL is HIGH to end communication.

Root cause:

Not understanding that stop condition frees the bus causes bus lock and communication deadlock.

#3 Ignoring repeated start conditions in multi-part messages.

Wrong approach:

Master sends stop then start between write and read operations instead of repeated start.

Correct approach:

Master sends repeated start condition without stop to maintain bus control during multi-part transactions.

Root cause:

Lack of knowledge about repeated start usage leads to bus conflicts and failed data reads.

Key Takeaways

Start and stop conditions are special signals on the I2C bus that mark the beginning and end of communication by specific changes on SDA while SCL is HIGH.

These conditions ensure devices know when to listen or talk, preventing data confusion on a shared line.

Repeated start conditions allow continuous communication without releasing the bus, enabling complex data exchanges.

Hardware modules detect start and stop conditions precisely, improving reliability over software-only detection.

Misunderstanding these signals leads to communication errors, bus conflicts, and system failures in embedded devices.