Hey everyone,

Polling and interrupts are two different approaches to handling input and events in embedded systems. Polling involves repeatedly checking a device or condition to determine if an action is required. In contrast, interrupts allow a device or condition to signal the CPU when it needs attention

I wanted to start a discussion about the choice between using polling and interrupts in various scenarios. Both methods have their specific use cases and advantages. When do you prefer to use polling, and when do you find interrupts to be a better option? Let's share our insights and experiences to better understand the situations where each approach shines.

Looking forward to hearing your thoughts

 

Interrupts and polling is also an option.

 

Interrupts and polling is also an option.

From what I gather in pic microcontroller, peripheral flags seem to indicate the status of a specific peripheral, while interrupt flags are related to triggering interrupts when certain events occur. But when should we opt for one over the other? Are there scenarios where using peripheral flags is more advantageous, or does the efficiency of interrupt flags win in most cases?

 

When do you prefer to use polling, and when do you find interrupts to be a better option?

It could be personal preference. It could be ignorance.

When an operating system polls, it checks for work regardless of whether there's actually any work to be done. With interrupts, the CPU processes wanting resources let the CPU know. While it's waiting for interrupts, it can work on other more important things.

 

It depends on what you're polling for and what the interrupt does. I normally use polling (mainly state-machine polling so the entire process does not block), interrupts (for things like serial data I/O), FIFO buffers and DMA (that triggers an interrupt at the selected events completion of the serial data transfer) together in the same embedded project.
Interrupts (non-vectored interrupts are what's seen on most low-end 8-bit controllers must check several interrupt flags per interrupt from any source) are not always the best or most efficient approach for I/O if the highest possible speed with deterministic timing is critical for something. Selecting a device with capable hardware (vectored interrupts, shadow registers for quick context switches, etc ...) that can optimize polling, interrupts and DMA is very important too.

https://forum.allaboutcircuits.com/...polling-dma-and-interrupt.152493/post-1309150

https://forum.allaboutcircuits.com/threads/pic32mk-mc-qei-example.150351/post-1617150

 

It depends on what you're polling for and what the interrupt does

I've been using polling method when it comes to sending or receiving data from microcontroller to PC via UART,

Let's take two examples to delve into this further

Example 1 - Ethernet Module: Imagine you have an Ethernet module that operates over UART. You want to send data from your microcontroller to a PC. In this scenario, would you prefer to use the polling method for UART communication? What are the advantages and drawbacks of this approach?

Example 2 - GPS Module: Now, let's switch gears. You have a GPS module that communicates via UART and you want to read GPS data from the receiver to your microcontroller. Would you still stick with polling for this case, or would you consider using interrupts? What factors would influence your decision?

 

From what I gather in pic microcontroller, peripheral flags seem to indicate the status of a specific peripheral, while interrupt flags are related to triggering interrupts when certain events occur. But when should we opt for one over the other? Are there scenarios where using peripheral flags is more advantageous, or does the efficiency of interrupt flags win in most cases?

There's often, perhaps usually, no compelling reason to use one over the other and either could be a reasonable choice. It often comes down to what the developer is most used to and comfortable with. If they have done a lot of work on very low end MCUs that didn't even have interrupts, then they have learned effective ways to write polling code. They are then likely to continue using that approach well beyond the point where the advantages of using interrupts in a particular case would clearly favor it -- we use what we know. The tendency would be to resort to interrupts only once they are in a situation where polling just won't do. The same can be true going the other way. People can get too entrenched in using interrupts for everything and will continue to do so even when a very simple polling approach would be more than adequate and possibly allow the use of a smaller, cheaper MCU.

Ideally, a developer would consider both options and weight each approach on its merits for that particular application and what is and is not important for that project. The decision that would be made for a design destined for mass production starting in a year might be very different than the one made for a one of a kind system that needs to be up and running two weeks from now.

 

When an operating system polls, it checks for work regardless of whether there's actually any work to be done. With interrupts, the CPU processes wanting resources let the CPU know.

I encountered a confusing statement: "When an operating system polls, it checks for work regardless of whether there's actually any work to be done."

I wasn't discussing any specific OS, and now I'm curious. Is this related to certain systems like FreeRTOS? Could you explain polling in this context, or how it varies across different OSs? Grateful for insights!

Thanks!

 

Example of using both:

I always oversample analog signals at the fastest constant rate my application will allow. This helps greatly to simplify the analog front end and reduce aliasing artifacts and noise.

I'll use my interrupt to capture and accumulate the fast conversions, and maintain a count of the conversions processed.

At some point, my interrupt routine will set a flag to indicate a certain number of conversions have been accumulated. The main program will poll for that flag, at which time it will capture and process the accumulated data.

 

Ideally, a developer would consider both options and weight each approach on its merits for that particular application and what is and is not important for that project. The decision that would be made for a design destined for mass production starting in a year might be very different than the one made for a one of a kind system that needs to be up and running two weeks from now.

I'd love your take on two real-world cases where we're familiar with both methods:

Example 1: Ethernet Module Communication We're dealing with an Ethernet module using UART to send data from a microcontroller to a PC. Given your experience, which approach (polling or interrupt) would you lean towards for this task and why?

Example 2: GPS Module Data Retrieval Now, let's talk about reading GPS data from a module via UART to the microcontroller. In your opinion, considering both options, which method suits this situation best?

 

I should point out that -- given the hardware in question and the problem being solved -- there is always a best, optimum solution.

But there are also lazy and/or inexperienced programmers who can't or won't implement it.

I shoot for optimum. It takes more time up front in the design phase, but once it's written, code is free.

 

I encountered a confusing statement: "When an operating system polls, it checks for work regardless of whether there's actually any work to be done."

I wasn't discussing any specific OS, and now I'm curious. Is this related to certain systems like FreeRTOS? Could you explain polling in this context, or how it varies across different OSs? Grateful for insights!

Thanks!

It's not an operating system issue -- that's just the context that the writer was using for their discussion.

When any program does polling, it has to spend time checking to see if what is being polled needs action taken. In the case of things that need to be reacted to in a timely fashion, this almost always means that you are checking it dozens, hundreds, or even thousands of time only to discover that there's nothing that needs to be done for every time that you check and there is. In other cases, it might not matter whether you catch it quickly and so you can poll it at a slow enough rate that you expect to find something to do more often than not. It all depends on the specifics of the situation.

 

It's not an operating system issue -- that's just the context that the writer was using for their discussion.

When any program does polling, it has to spend time checking to see if what is being polled needs action taken. In the case of things that need to be reacted to in a timely fashion, this almost always means that you are checking it dozens, hundreds, or even thousands of time only to discover that there's nothing that needs to be done for every time that you check and there is. In other cases, it might not matter whether you catch it quickly and so you can poll it at a slow enough rate that you expect to find something to do more often than not. It all depends on the specifics of the situation.

Thanks again for sharing your expertise and experiences – you all make this community a fantastic place to learn

 

I should point out that -- given the hardware in question and the problem being solved -- there is always a best, optimum solution.

But what constitutes optimum? In many cases, ten people could come up with ten quite different solutions and each have a reasonable claim that theirs is a better solution to the problem than any of the others.

But I would agree that the space of possible "best" solutions is greatly narrowed, especially compared to a wide-open discussion looking for some cookie-cutter "best" approach.

But there are also lazy and/or inexperienced programmers who can't or won't implement it.

I shoot for optimum. It takes more time up front in the design phase, but once it's written, code is free.

Many engineers (myself included) tend to over-optimize. We forget that the metric of what is "optimum" really needs to take into account not wasting the customer's time or money making a design that meets their requirements somehow meet it "better".

 

I'd love your take on two real-world cases where we're familiar with both methods:

Example 1: Ethernet Module Communication We're dealing with an Ethernet module using UART to send data from a microcontroller to a PC. Given your experience, which approach (polling or interrupt) would you lean towards for this task and why?

Example 2: GPS Module Data Retrieval Now, let's talk about reading GPS data from a module via UART to the microcontroller. In your opinion, considering both options, which method suits this situation best?

As already noted -- more than once -- the decision is based on lots of factors, most of which go beyond the limited information in your examples. A big factor is going to be what other things is the system having to do. If the system is lightly loaded, then it may come down to a coin toss.

 

I've been using polling method when it comes to sending or receiving data from microcontroller to PC via UART,

Let's take two examples to delve into this further

Example 1 - Ethernet Module: Imagine you have an Ethernet module that operates over UART. You want to send data from your microcontroller to a PC. In this scenario, would you prefer to use the polling method for UART communication? What are the advantages and drawbacks of this approach?

Example 2 - GPS Module: Now, let's switch gears. You have a GPS module that communicates via UART and you want to read GPS data from the receiver to your microcontroller. Would you still stick with polling for this case, or would you consider using interrupts? What factors would influence your decision?

Almost anytime you're dealing with serial data rx or tx of more than a few bytes, you will want to buffer it to isolate the software rx/tx process, from the hardware rx/tx process, and to abstract the I/O to a common stable interface of something like a ring-buffer.

Example 1: Here is an example of my choices.
I used DMA and DMA completion interrupts to send data because the ETH module serial interface speed is > 400kbs. Using just interrupts would eat a lot of cpu cycles at that speed to keep-up with the transfer rate. Even polling at that speed is iffy unless to totally disable interrupts to be sure you don't miss a flag update.
https://forum.allaboutcircuits.com/...nd-sensor-node-for-canbus.189388/post-1795532

https://forum.allaboutcircuits.com/...nd-sensor-node-for-canbus.189388/post-1797196

Lots of functionality concurrency and overlapping I/O using polling, interrupts and DMA to make it work.


https://www.waveshare.com/uart-to-eth.htm

 

But what constitutes optimum? In many cases, ten people could come up with ten quite different solutions and each have a reasonable claim that theirs is a better solution to the problem than any of the others.

But I would agree that the space of possible "best" solutions is greatly narrowed, especially compared to a wide-open discussion looking for some cookie-cutter "best" approach.

Many engineers (myself included) tend to over-optimize. We forget that the metric of what is "optimum" really needs to take into account not wasting the customer's time or money making a design that meets their requirements somehow meet it "better".

I hate writing code more than once. I tend to build library modules that I can link into my current application with the assumption that I will use them again (and again) in other -- unrelated and unknown -- projects.

Optimum to me means: a complete module that does the work required in the smallest possible code space in the shortest amount of execution time with the fewest resources. These criteria are sometimes mutually exclusive, so, yeah, the balance may change from (good) programmer to programmer.

If you've followed any of the past debates between @nsaspook and I, you'll know that we operate in different worlds. I mostly do small embedded controllers where I'm limited in memory, hardware, speed, and power, so I try to optimize accordingly. Unsurprisingly, my language of choice is .asm.

One writing PC applications with effectively unlimited memory, instruction cycles, and AC power would choose their optimizations differently (most likely time-to-code). I don't live in that world.

 

You can use polling in non-critical processes.

Polling can be blocking or non-blocking.
With blocked polling, you wait until a given condition is satisfied before moving on. For example, you can wait until a disk drive is ready before writing a file.
With non-blocked polling, if a disk drive is not ready, you do something else and come back and check again.

When time is critical, you use interrupts.
You can mix polling and interrupts in the same system. It is not one versus the other.

 

As already noted -- more than once -- the decision is based on lots of factors, most of which go beyond the limited information in your examples. A big factor is going to be what other things is the system having to do. If the system is lightly loaded, then it may come down to a coin toss.

I can describe my example in details to take your opinion.

A door access control system combines several components, including an 8051 microcontroller, to manage secure access effectively:

• 8051 Microcontroller: Serves as the system's brain, controlling interactions between other components. It processes RFID data, manages RTC, EEPROM, and Ethernet communication, and controls the EMLOCK.
• RTC (Real-Time Clock): Provides accurate time for scheduling access permissions based on time windows.
• EEPROM: Stores user credentials, access rights, and event logs even during power loss

• EMLOCK (Electromagnetic Lock): Electronically controlled lock for secure door access.
• RFID Reader: Identifies users via RFID cards/tags.

Workflow:

1. User presents RFID card.
2. RFID reader captures card's ID.
3. 8051 microcontroller checks user's access permissions based on RTC and EEPROM data.
4. If access is allowed, 8051 microcontroller commands EMLOCK to unlock the door.
5. User enters, and system records the event.
6. Access data may be sent via Ethernet for central monitoring.

 

First I would not use a 8051 Microcontroller unless it was an absolute requirement like a school mandated controller for a grade. The choice of controller is very important and the 8051 hardware architecture is archaic.