Introduction to RTOS Part 9 - Hardware Interrupts | Digi-Key Electronics

preview_player
Показать описание
Hardware interrupts are important in many embedded systems. They allow us to respond to external events (such as a button being pressed) or internal events (such as a timer expiring) in an asynchronous manner, which means that the processor can stop whatever it was doing to run an interrupt service routine (ISR).

In most RTOSes, such as FreeRTOS, hardware interrupts occur at a higher priority than all other tasks. This means, unless specifically disabled, hardware interrupts will halt the execution of any currently running task. The CPU will be forced to handle the interrupt before returning to the task.

A few tips when working with interrupts:
ISRs should never block, which means you should only use FreeRTOS kernel function calls that end in “FromISR”
You should keep ISRs as short as possible to avoid delaying tasks longer than necessary
Any global variables that get updated in an ISR should be declared with the “volatile” qualifier

Rather than perform processing inside an ISR, you can “defer processing” by collecting data into a buffer and letting a task do the processinging. In the video, we look at how to accomplish deferred processing using semaphores (note that you can also use queues and task notifications).

When an ISR is done, it can set a lock (e.g. “give” a semaphore), which will unblock a task. This task can then use any data collected by the ISR (e.g. a new ADC value, a buffer filled with data from the serial port, etc.). With this method, you can keep ISRs short while relying on a task to perform any necessary processing.

Product Links:

Related Videos:

Related Project Links:

Related Articles:

Learn more:

Рекомендации по теме
Комментарии
Автор

I'm just started working with ESP32 at my new work and I cannot tell you how much this series has helped me! Thank you so much for making this available! <3

abhijanwasti
Автор

​0:29 external interrupts
​1:40 what happens when an interrupt is fired
2:37 demo
8:45 binary semaphore
12:06 Task notifications
12:28 Challenge

mohamedhassanin
Автор

I like this series, sometimes my code works but there is a better way to implement the same

MrKoval-nmky
Автор

Thank you for another great tutorial, however, I found the explanation of critical sections confusing and needed to do more research. I feel like the subjects of ISR critical sections, mutexes and spinlocks should be separated here. In my understanding, ISR critical sections are used to disable all interrupts for a very short period of time, to prevent race conditions between tasks and ISRs. Even though we may be in an ISR in one core, a task running on another core could still access the same variable; so we should protect it further with a mutex or spinlock. Mutexes and spinlocks can be used interchangeably, however, spinlocks are used here by default to prevent wasted CPU cycles. As opposed to spinlocks, mutexes put tasks to sleep, and that uses many CPU cycles. This isn't recommended if we access variables often and for short periods of time, as is the case in ISRs, therefore spinlocks are the obvious choice in ISR critical sections. Please correct me if I'm wrong.

ksawery
Автор

What happens when we call portyieldfromisr when there is no other task with higher priority that becomes unblocked after we have given the semaphore?
I'm guessing it will call forth the schedular but that wont do anything because the other task is not ready yet and we just added 1 or 2 ticks lag to the normal process, is this correct? and is this the only downside of calling portyieldfromisr, if so why is this not routine behaviour?

TomSky
Автор

Hi hymel thanks for making a lecture🎉, make a video on clock, based on that tick how a timer works in mcu

balachandarjeyalatha
Автор

Hi, thank you for your effort to face it from the point of view of beginners, as i am.
Question:about at 10:20 you perform an ADC conversion inside an ISR, in contrast with the rule of keeping every ISR very short.
Was it done just for easyness of explanation?Thanks.

blisca
Автор

I wonder, what is the benefit of removing the setup task after execution? it seems pointless as the setup task only gets called once after booting anyway, doesn't it automaticly get removed?

TomSky
Автор

at the esp-idf we have general porpose timr and high resolution timer.what dιd
you used?

steliossideris
Автор

Nice challenge problem. Image the look on their faces when they find out the template for a ring buffer isn't in the STL.

KaiseruSoze
Автор

About the semaphore and the overrun flag in the challenge answer:

Looks like the state is either (semaphoreTake TRUE + overrun = 0) OR (FALSE + 1),
-> with (TRUE + 1) and (FALSE + 0) being unreachable.

So, is the whole point of the overrun flag a signaling mechanism so that the error message "Error: Buffer overrun. Samples have been dropped." can be printed out?

Suppose if we don't care about error message,
-> buf_overrun is not needed in the ISR condition check "if ((idx < BUF_LEN) && (buf_overrun == 0))"
-> if we use "if (idx >= BUF_LEN && xSemaphoreTakeFromISR(sem_done_reading, &task_woken) == pdTRUE)" to guard the whole buffer full section,
-> so idx is not reset to 0
-> "if (idx < BUF_LEN)" always fails until semaphoreTake is successful

Did I understand it correctly?

MingOnUTube
Автор

I'm getting an error when I try to run this on my ESP32-S2-WROOM. The error I get is "abort() was called at PC 0x40027db7 on core 0" and then the ESP32 reboots and it just keeps repeating this. This makes me believe there is some sort of overflow happening (maybe with the timer_divider?). When I comment out the timerAttachInterrupt() line of code, I don't get the error. Anybody have anything they'd recommend I try?

SmokinLoken
Автор

Thank you for the knowledge shared, but I have an issue. I've tried several codes, but none of them seem to work. I don't understand how to use it on STM32F4. I'm using a hardware timer from TIM1, but it's not functioning. Can someone help me with how to code on STM32 using Arduino IDE?

Dodek_Mardana
Автор

I got error with the solution simple: Average: 124Guru Meditation Error: Core 1 panic'ed (Unhandled debug exception). any hint?

mimo
Автор

In esp32 which core will execute ISR functions? Is it possible to shift the ISR to a particular Core

abhinavabhi
Автор

Jesus Christ this was too fast to understand it all lol

fernandoi
Автор

This should be titled Timer Interrupts not Hardware Interrupts.

louiscelenza
Автор

I hate to be a slow listener 🤣, my old C++ professor was talking faster than this guy…C++ is an easy code but talking x2 speed, they try to give the illusions that is hard to learn it🤣.. so talking and explaining fast won’t make look smarter

eddw