UART interrupt-driven communication in Embedded C - Step-by-Step Execution

Concept Flow - UART interrupt-driven communication

UART Initialized

↓

Enable UART Interrupt

↓

Wait for Data

↓

Interrupt Occurs

↓

Interrupt Service Routine (ISR)

↓

Read Data

↓

Process/Store Data

↓

Clear Interrupt Flag

↓

Return to Main Program

↓

Repeat Waiting for Data

The UART is set up and interrupts enabled. When data arrives, an interrupt triggers the ISR, which reads and processes the data, then returns control to the main program.

Execution Sample

Embedded C

void UART_ISR(void) {
    if (UART_Receive_Interrupt_Flag) {
        char data = UART_Read();
        buffer[index++] = data;
        UART_Clear_Interrupt_Flag();
    }
}

This interrupt service routine runs when UART data is received, reads the data, stores it in a buffer, and clears the interrupt flag.

Execution Table

Step	Interrupt Flag	Action	Data Read	Buffer State	Interrupt Flag Cleared
1	Set (Data received)	Enter ISR	-	[]	No
2	Set	Read UART Data	'A'	[]	No
3	Set	Store Data in Buffer	-	['A']	No
4	Set	Clear Interrupt Flag	-	['A']	Yes
5	Cleared	Exit ISR	-	['A']	Yes
6	Cleared	Wait for next data	-	['A']	Yes

💡 Interrupt flag cleared, ISR ends, main program resumes waiting for new data.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
UART_Receive_Interrupt_Flag	Set	Set	Set	Cleared	Cleared
data	N/A	'A'	'A'	'A'	'A'
buffer	[]	[]	['A']	['A']	['A']
index	0	1	1	1	1

Key Moments - 3 Insights

Why do we need to clear the interrupt flag inside the ISR?

If the interrupt flag is not cleared (see step 4 in execution_table), the ISR will be called repeatedly for the same event, causing an infinite loop.

What happens if the buffer index is not incremented after storing data?

If index is not incremented (step 3), new data will overwrite the previous data in the buffer, losing information.

Why does the main program wait after the ISR finishes?

After ISR ends (step 5 and 6), the main program waits for the next interrupt, allowing the CPU to do other tasks until new data arrives.

Visual Quiz - 3 Questions

Look at the execution_table, what is the buffer state after step 3?

A ['B']

B []

C ['A']

D ['A', 'B']

💡 Hint

Check the 'Buffer State' column at step 3 in the execution_table.

At which step is the interrupt flag cleared?

A Step 4

B Step 2

C Step 5

D Step 1

💡 Hint

Look at the 'Interrupt Flag Cleared' column in the execution_table.

If the interrupt flag is not cleared, what will happen according to the execution flow?

A ISR will not be called again

B ISR will be called repeatedly for the same data

C Data will be lost immediately

D Main program will stop

💡 Hint

Refer to key_moments explanation about clearing the interrupt flag.

Concept Snapshot

UART interrupt-driven communication:
- Initialize UART and enable interrupts
- When data arrives, interrupt triggers ISR
- ISR reads data, stores it, clears interrupt flag
- Control returns to main program
- Main program waits for next interrupt
Key: Always clear interrupt flag inside ISR to avoid repeated calls.

Full Transcript

This visual execution trace shows how UART interrupt-driven communication works in embedded C. The UART is initialized and its interrupt enabled. When data arrives, the UART sets an interrupt flag, triggering the interrupt service routine (ISR). Inside the ISR, the program reads the incoming data, stores it in a buffer, increments the buffer index, and clears the interrupt flag to prevent repeated interrupts. After clearing the flag, the ISR exits, returning control to the main program, which waits for the next data. The variable tracker shows how the interrupt flag, data, buffer, and index change step-by-step. Key moments clarify why clearing the interrupt flag is essential and why the buffer index must be incremented. The quiz questions help reinforce understanding by referencing the execution table and variable states.

Practice

1. What is the main advantage of using UART interrupt-driven communication in embedded systems?

easy

A. It allows the CPU to perform other tasks while waiting for UART data.

B. It requires the CPU to constantly check the UART status manually.

C. It disables all other interrupts during UART communication.

D. It slows down data transmission to avoid errors.

Solution

1. Step 1: Understand UART polling vs interrupt

   Polling requires CPU to wait and check UART status repeatedly, wasting time.

2. Step 2: Identify interrupt-driven benefit

   Interrupt-driven UART lets CPU do other work and only handles UART when data arrives.

3. Final Answer:

   It allows the CPU to perform other tasks while waiting for UART data. -> Option A

4. Quick Check:

   Interrupt-driven = CPU multitasks [OK]

Hint: Interrupts free CPU from waiting, improving multitasking [OK]

Common Mistakes:

• Confusing polling with interrupt-driven method
• Thinking interrupts disable other tasks
• Assuming interrupt slows communication

2. Which of the following is the correct way to enable UART receive interrupt in embedded C?

easy

A. UART->CR1 &= ~UART_CR1_RXNEIE;

B. UART->CR1 = 0;

C. UART->CR1 |= UART_CR1_RXNEIE;

D. UART->CR1 |= UART_CR1_TXEIE;

Solution

1. Step 1: Identify RX interrupt enable bit

   UART_CR1_RXNEIE enables receive-not-empty interrupt.

2. Step 2: Enable RX interrupt without clearing other bits

   Use bitwise OR (|=) to set RXNEIE bit.

3. Final Answer:

   UART->CR1 |= UART_CR1_RXNEIE; -> Option C

4. Quick Check:

   Enable RX interrupt = |= UART_CR1_RXNEIE [OK]

Hint: Use |= to set interrupt enable bits without clearing others [OK]

Common Mistakes:

• Using &= ~ to enable instead of disable bits
• Setting TX interrupt instead of RX
• Overwriting CR1 register instead of OR-ing

3. Given this UART interrupt handler code snippet, what will be the output if a byte 'A' (0x41) is received?

void USART1_IRQHandler(void) {
  if (USART1->SR & USART_SR_RXNE) {
    char data = USART1->DR;
    USART1->DR = data + 1;
  }
}

medium

A. The UART sends back 'A' unchanged.

B. The UART sends back 'B' (0x42) after receiving 'A'.

C. The UART sends back 'C' (0x43) after receiving 'A'.

D. No data is sent back.

Solution

1. Step 1: Read received data

   Data 'A' (0x41) is read from USART1->DR.

2. Step 2: Write back data + 1

   Data + 1 = 0x41 + 1 = 0x42, which is 'B'.

3. Final Answer:

   The UART sends back 'B' (0x42) after receiving 'A'. -> Option B

4. Quick Check:

   Received 'A' + 1 = 'B' [OK]

Hint: Adding 1 to 'A' (0x41) gives 'B' (0x42) [OK]

Common Mistakes:

• Confusing ASCII values and characters
• Assuming data is unchanged
• Ignoring the addition operation

4. Identify the bug in this UART interrupt handler code:

void USART2_IRQHandler(void) {
  if (USART2->SR & USART_SR_TXE) {
    USART2->DR = tx_buffer[tx_index++];
  }
  USART2->SR &= ~USART_SR_TXE;
}

medium

A. The USART2->DR register should not be written inside the interrupt.

B. The interrupt handler should clear RXNE flag instead of TXE.

C. The tx_index variable is not incremented correctly.

D. Clearing the TXE flag manually is incorrect; it is cleared by hardware.

Solution

1. Step 1: Understand TXE flag behavior

   TXE (transmit data register empty) flag is cleared automatically by hardware when data is written to DR.

2. Step 2: Identify incorrect manual clearing

   Code tries to clear TXE by writing to SR register, which is read-only or managed by hardware.

3. Final Answer:

   Clearing the TXE flag manually is incorrect; it is cleared by hardware. -> Option D

4. Quick Check:

   TXE flag cleared by hardware, not software [OK]

Hint: TXE flag clears automatically; don't clear it manually [OK]

Common Mistakes:

• Trying to clear hardware-managed flags manually
• Confusing TXE and RXNE flags
• Not incrementing buffer index properly

5. You want to implement a UART interrupt-driven echo program that receives data and immediately sends it back. Which sequence of actions should the interrupt handler perform to work correctly and efficiently?

hard

A. Check RXNE flag, read data from DR, write data back to DR, do not clear RXNE flag manually.

B. Clear RXNE flag manually, read data from DR, write data back to DR, check TXE flag.

C. Check TXE flag, write data to DR, clear TXE flag manually, then read data from DR.

D. Check RXNE flag, read data from DR, write data back to DR, clear RXNE flag manually.

Solution

1. Step 1: Handle RXNE flag correctly

   Check RXNE flag to know data received; read data from DR clears RXNE automatically.

2. Step 2: Write data back without manual flag clearing

   Write data to DR to send; TXE flag is managed by hardware, no manual clearing needed.

3. Final Answer:

   Check RXNE flag, read data from DR, write data back to DR, do not clear RXNE flag manually. -> Option A

4. Quick Check:

   Read clears RXNE; no manual flag clearing needed [OK]

Hint: Read clears RXNE; hardware manages flags automatically [OK]

Common Mistakes:

• Manually clearing RXNE or TXE flags
• Checking TXE before reading RXNE
• Writing data before reading received byte