Facebook
Google
GitHub
Linkedin
Its not about selecting a specific microcontroller; rather, it's about choosing the right communication method for uart : polling or interrupts. Use microcontrollers like PIC, AVR, or ARM, instead of 8051
Choosing Between Polling and Interrupts: When and Why?"
- Thread starter Kittu20
- Start date
It makes a big difference on how well those methods work with other processing happening on the controller like trying to send/receive high speed serial data from a Ethernet module while handling the other things you listed.
- 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.
I've done my best to anticipate potential solutions and trade-offs for these scenarios, but I believe in the power of collective knowledge. I'm eager to learn from your experiences and expertise. Whether you've encountered similar situations, have valuable insights, your input would greatly enrich my understanding.
So, let's dive into these scenarios together and engage in a constructive dialogue.
Share any tips that could shed light on the best paths forward.
Thank you in advance for your contributions! I'm genuinely excited to learn from you all.
But these choices are not separable! Unless you are in one of the relatively rare circumstances in which one choice is simply not workable or practicable, which one is more reasonable depends on a large variety of factors, including, but in no way limited to, the choice of controller.
When I was first introduced to minicomputer programming, all devices were handled with blocking poll of device flags.
Why? Because there was nothing else for the program to do.
The code waited for the user to press a key on the teletypewriter keyboard.
Then the program printed out a message on the printer. It always waited for the last character to be printed before sending another character.
Thus, polling is very effective and works well, if that is acceptable for the application.
In other words, it all depends on the application.
Why? Because there was nothing else for the program to do.
The code waited for the user to press a key on the teletypewriter keyboard.
Then the program printed out a message on the printer. It always waited for the last character to be printed before sending another character.
Thus, polling is very effective and works well, if that is acceptable for the application.
In other words, it all depends on the application.
I'm a believer that actually building things is how you learn in electronics. Constructive dialogue, when one party is not up to speed, is frustrating on both parties because I'm not a teacher, I'm primary a problem solver.
Stop talking and start building, testing and probing, then we can talk about what you have, problems and solutions.
While I've got a good grasp of the theoretical explanations, I'm struggling a bit when it comes to making the right choice in practical scenarios. I'd be happy to hear your thoughts on example in post #6, #19 and whether you'd recommend using polling or interrupts
This question is slightly different from the original question but you mentioned DMA so asking for clarification.
I've been pondering over a specific scenario and could use your expertise in making the right choice. Imagine this: you're sending data from a PIC16F877A microcontroller to PC/laptop via UART, with settings of 8N1, no parity bit, and a baud rate of 9600. RS232
The question is: in this context, would you recommend sticking to the traditional approach or exploring the use of Direct Memory Access (DMA)?
This is why the choice of controller is important. The PIC16F877A doesn't have DMA.
My bad, For example PIC32MZ2048EFH144, One of the PIC microcontrollers that offers Direct Memory Access (DMA) features is the "PIC32MZ" family of microcontrollers from Microchip Technology. These microcontrollers are equipped with DMA controllers that enable efficient data transfers between memory and peripherals without involving the CPU.
That's a totally different class of controller. Very capable but it's 32-bit and more complicated to configure and program. A suitable 8-bit controller with a modern interrupt architecture, fast context switching and DMA would be something like the PIC18F47Q84 that runs up to 64Mhz. I'm using one my FM80 project. Even if you don't use DMA, the vectored interrupt architecture with shadow-registers will improve interrupt speed and reduce latency and the UART with FIFO receiver buffering reduces the possibilities of receive overflow conditions.
https://www.microchip.com/en-us/product/pic18f47q84
Last edited:
As @nsaspook is struggling to get you to grasp, the choice between polling and interrupts is not one that can be made outside a comprehensive specification of the system which will use one or the other. As @MrChips pointed out, this system even includes the programmer because familiarity and competency with one or the other technique will be one of the factors in choosing.
A naïve reduction of what is effectively an irreducible system will never serve as a platform for learning about the tools and techniques used to build it. The practical outcome of the irreducibility of the problem is that we must take an iterative approach.
Starting at a very high level with descriptions of functionality with the only implementation details being those that are actual constraints we iterate down into lower level descriptions that combine implementation details concerning methods, and continuing until we’ve reached things that are physical.
The question of polling vs. interrupts is several layers down into the design. All of the other parts that accumulated via the design process to that point figure in the decision. It is even possible that it will change when even lower level decisions are made, the impact propagating back into higher levels as often happens.
So, as is often the case with your questions, your “simplified” scenarios are made useless by the very fact that you don‘t know the answer to the question you are asking. A real answer requires a comprehensive description of the system in which the choice will be implemented.
The only way you are going to be able to do this is by choosing something that has been designed and implemented already, and where the choice has been made—and then working out why the choice was made in that real world case. You simply don’t know what needs to be present in your scenario to get a real answer.
A naïve reduction of what is effectively an irreducible system will never serve as a platform for learning about the tools and techniques used to build it. The practical outcome of the irreducibility of the problem is that we must take an iterative approach.
Starting at a very high level with descriptions of functionality with the only implementation details being those that are actual constraints we iterate down into lower level descriptions that combine implementation details concerning methods, and continuing until we’ve reached things that are physical.
The question of polling vs. interrupts is several layers down into the design. All of the other parts that accumulated via the design process to that point figure in the decision. It is even possible that it will change when even lower level decisions are made, the impact propagating back into higher levels as often happens.
So, as is often the case with your questions, your “simplified” scenarios are made useless by the very fact that you don‘t know the answer to the question you are asking. A real answer requires a comprehensive description of the system in which the choice will be implemented.
The only way you are going to be able to do this is by choosing something that has been designed and implemented already, and where the choice has been made—and then working out why the choice was made in that real world case. You simply don’t know what needs to be present in your scenario to get a real answer.
While I've done some reading on both approaches, I'm finding it a bit challenging to decide which one is the better fit for my specific project Post #19.
I'm reaching out to you all because I believe your real-world experiences could offer valuable insights. Have any of you been in a similar situation before, where you had to choose between using interrupts or polling for your project? If so, could you share your decision-making process? What factors did you consider, and ultimately, what led you to choose one approach over the other?
I'm reaching out to you all because I believe your real-world experiences could offer valuable insights. Have any of you been in a similar situation before, where you had to choose between using interrupts or polling for your project? If so, could you share your decision-making process? What factors did you consider, and ultimately, what led you to choose one approach over the other?
Thank you for taking the time to respond. I apologize if my initial description lacked the necessary details. I'm committed to providing all the relevant information to you understand my project better.
could you kindly advise me on what specific aspects I might be missing that are crucial for determining whether interrupts or polling would be the more suitable approach for my project?
Your insights will be immensely valuable in helping me make an informed decision.
Thank you once again for your assistance.
I outlined a method at the end of the previous post. But I think you need to avoid posing artificial questions altogether and build something, then ask questions that arise organically. The idea of using case study solutions, as I mentioned in the previous post is a possible, if weaker, option.
In any case, sometimes what looks like a question isn’t one if you know other things, and can’t be answered without those things. So, look at the entire system not arbitrary parts whose boundaries are quite possibly illusory.
But how do you think that we all got that real-world experience?
By making decisions and trying them out. Not all of those decisions were good ones -- and it was from those decisions that we usually learned the most and that then informed later decisions.
Pick a simple project and do it both ways. Then ask yourself what was easy and what was hard about each way. Then do that on another, different project. And another. You will start getting a feel for when YOU want to use polling versus when YOU want to use interrupts.
As the saying goes, good judgement comes from experience, and experience comes from poor judgement.
Are you sure this is the case?
Some people "seem" to learn from books, but are never able to make the leap from book learning to actually being able to apply that knowledge in a practical application.
Some highly educated people don't know the difference between being able to use something like an opamp and actually being able to design an opamp. I came to understand this when I was talking to a guy who had a PhD in Computer Engineering and he was trying to impress me with his knowledge. He told me he liked to design opamps. I found that he knew nothing about actually designing opamps when he tried to engage me on that topic.
I'll show you how odd ball requirements can change/mix-up the polling/interrupt choice.
For the Q84, the serial port does normal 8-bit receive/transmit interrupts but the odd ball FM80 serial data format is 9-bits, no parity and one stop 9N1. The 9-th bit high starts the data protocol packet.
https://github.com/jorticus/pymate/blob/master/doc/protocol/Protocol.md
I don't want parity 9-th bit emulation (other implementations have) and 9-th bit address detection doesn't work with this 9-th bit set protocol.
The yellow trace is the MISC scope trace gpio that times the function cpu usage and frequency. The Purple trace is the TX/RX uart register access IO_RB6 gpio scope trace toggles.
The polling cpu cost is 33us every 500us interrupt but reliable communications to the FM80 charge controller is the critical task of the board and there is plenty of extra time for other compute task to work with.
So here we have polling and interrupts used together as a system to send and receive UART data.
For the Q84, the serial port does normal 8-bit receive/transmit interrupts but the odd ball FM80 serial data format is 9-bits, no parity and one stop 9N1. The 9-th bit high starts the data protocol packet.
https://github.com/jorticus/pymate/blob/master/doc/protocol/Protocol.md
The Q84 and many controllers can handle 9N1 data but it's normally for parity or 9-th bit address detection as is seen in RS-485 systems.
I don't want parity 9-th bit emulation (other implementations have) and 9-th bit address detection doesn't work with this 9-th bit set protocol.
The solution was to use a timer that interrupts every 500us (also used to update 1ms software timers in the program) and to poll/set the UART data and 9-th bit flags in a function the timer calls during it's interrupt.
The yellow trace is the MISC scope trace gpio that times the function cpu usage and frequency. The Purple trace is the TX/RX uart register access IO_RB6 gpio scope trace toggles.
The polling cpu cost is 33us every 500us interrupt but reliable communications to the FM80 charge controller is the critical task of the board and there is plenty of extra time for other compute task to work with.
So here we have polling and interrupts used together as a system to send and receive UART data.
For the example in post #19 i see one good reason to use interrupt if the MCU is put to sleep state in most time and wakes up from interrupt generated by detecting access card in reader. Other tasks can use polling or interrupt mostly with equal results.
