STM32 Serial Communication: Interrupt vs Polling

1. From Polling to Interrupt

Many students prefer polling over interrupt-driven operations.

Is this related to our nature? Everyone likes to have everything under control and dislikes being interrupted. We often have experiences where we are talking to someone and suddenly receive a phone call, and after the call, we can’t remember what we were discussing! This awful experience deeply influences us, leading us to believe that machines might behave similarly; frequent interruptions might mess things up. Fortunately, while machines are generally less intelligent than humans, they can handle such issues meticulously. When an interrupt occurs, the machine diligently saves its current state before processing the interrupt event, and once the interrupt is handled, it seamlessly resumes its previous task.

Upon reflection, could we also jot down what we’re discussing before answering a call? Why don’t we do this? One reason might be that we don’t have a pen at hand, or perhaps we are overly confident in our intelligence compared to machines. Of course, the most likely reason is that most of the time, we are discussing rather boring topics, haha.

We open the following project in Keil:

STM32Cube_FW_F0_V1.11.0\Projects\STM32F030R8-Nucleo\Examples\UART\UART_TwoBoards_ComIT\MDK-ARM\Project.uvprojx

If we look closely, we will find that there is almost no difference from the code that uses polling, especially in the initialization part, which is identical. Where is the interrupt-driven method?

Let’s continue looking and we finally find some differences:

STM32 Serial Communication: Interrupt vs Polling

Here we find that the serial port sending calls a different function. The secret lies in this function:

The function HAL_UART_Transmit_IT has three parameters:

UART_HandleTypeDef *huart, to let the function know which serial port is being handled

uint8_t *pData, the starting address of the data to be sent

uint16_t Size, the size (length) of the data to be sent

The three steps of this function:

Step 1: Assign the starting address of the data to be sent and its length to the serial port handle.

Step 2: Based on the parameters (8B or 9B), mount different handling functions.

Step 3: Enable interrupts (an interrupt will occur when the serial port sending register is empty).

After completing these tasks, the HAL_UART_Transmit_IT function exits, allowing the main program to continue executing other operations. This is entirely different from polling. If we look back at the polling method’s HAL_UART_Transmit, we will find that this function waits until all data is sent before exiting, during which the MCU is 100% occupied and cannot perform other tasks. The polling method’s sending function has a parameter of 5000, which is a sending timeout parameter; regardless of whether the sending is complete, it will forcibly exit this function after 5 seconds to prevent being stuck in this function due to hardware or other reasons.

2. Further Discussion on Handle

We did not translate the word “Handle” as “句柄” because the term “句柄” itself is a neologism that is not easy to understand and could lead to misconceptions. Therefore, we believe it is better not to translate “Handle.” Handle is an important concept, and we need to repeatedly appreciate the benefits of using it to manage hardware modules.

We can think of it as an office responsible for loading and unloading cargo ships; the type declaration (like UART_HandleTypeDef) is a template for creating this office. If there are five docks, we create five offices. These offices are similar, but each is different, built at different docks, with different personnel, and can call different fleets. This office can wait for commands from the central agency (MCU) or operate in a better way.

The interrupt method is like establishing an automated processing workflow for this office; when an empty cargo ship arrives at the dock, it automatically triggers some staff members in the office to dispatch a fleet to load the cargo onto the ship. The polling method, on the other hand, requires everything to wait for commands from the central command center (MCU), even if many staff members in the office are idle.

The handle below is like such an office, and the initialization process informs it that it is built on USART1, along with baud rate, parity, stop bits, and other information.

The HAL_UART_Transmit_IT function informs this office that there is a batch of 8BIT cargo stored in the warehouse aTxBuffer, and establishes an automated processing workflow by pointing TxISR to the appropriate fleet (function UART_TxISR_8BIT).

3. The Process of Interrupt Generation and Execution

From the diagram below, we can see the process from interrupt generation to execution, one for when the sending register is empty and the other for when sending is complete.

References:

PM0215 STM32F0xxx Cortex-M0 programming manual

UM1785 Description of STM32F0 HAL and low-layer drivers

STM32F030 Datasheet

STM32F030 Reference Manual

Writing code is hard work; if you like it, please give a thumbs up!

Scan to follow the official account:

Join WeChat group:

Recommended Reading:

Album | Linux Articles Collection

Album | Programming Life

Album | C Language

My Knowledge Circle

Follow the official account and reply “1024” to get the link to the learning materials.

Thank you for your likes, follows, shares, and support; I will cherish every encouragement!

STM32 Serial Communication: Interrupt vs Polling

Understanding the Relationship Between Micro:bit and Arduino

Getting Started with the Arduino ESP32 Core Library

Implementing Neural Networks on a 10-Cent RISC-V MCU Without a Multiplier

Getting Started with Arduino: Light Up Your First LED from Scratch

How Highly Integrated Embedded Processors Drive the Development of Industrial Robots

Leave a Comment Cancel reply

Menu