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!
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.
Actually, spin locks are the opposite! The spin through cycles which uses more cpu cycles, while a mutex will block and therefore not use cpu. The reson why we use spin locks is because the "cost" of a spinlock is lower if we are not waiting too long, which should be the case with an IRS critical section. If however we may need to wait a while for the resource, then spinlocks, or "busy waiting" are wasteful and a mutex is preferred
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.
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?
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?
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?
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?
Hehe...yup, this was a challenging one :) I figured that at this point, I’ve talked about almost all of the “tools” in FreeRTOS to make something like a multithreaded sample-and-process program. The ring or double buffer parts are missing, but I figured that there are enough examples out there on how to use/make them (and they’re not really RTOS related, anyway) :)
@@sigusr For this particular example, you can probably get away with using a queue, as data is being produced and consumed relatively slowly. However, queues are slow compared to direct memory read/writes, as they have extra overhead to be thread-safe. The point of the exercise is to create an RTOS application where you need to work with data being captured from a sensor at a rapid pace (and therefore would not be able to use a queue). If you're curious, this person found that queues can be written to or read from at about 3 us per access on the ESP32: techtutorialsx.com/2017/09/16/esp32-arduino-freertos-queues-performance-test/
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?
The core in which the ISR was assigned (attached) will be the core that executes the ISR. It is not possible to move the ISR once attached to a core. This section gives more information about ISR: docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/intr_alloc.html#internal-peripheral-interrupts
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
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!
Glad it helped!
Which work do you do?
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
I like this series, sometimes my code works but there is a better way to implement the same
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.
Actually, spin locks are the opposite! The spin through cycles which uses more cpu cycles, while a mutex will block and therefore not use cpu. The reson why we use spin locks is because the "cost" of a spinlock is lower if we are not waiting too long, which should be the case with an IRS critical section. If however we may need to wait a while for the resource, then spinlocks, or "busy waiting" are wasteful and a mutex is preferred
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.
Hi hymel thanks for making a lecture🎉,make a video on clock ,based on that tick how a timer works in mcu
Thanks for the info..👍
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?
Nice video liked it 👍
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?
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?
at the esp-idf we have general porpose timr and high resolution timer.what dιd
you used?
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?
Nice challenge problem. Image the look on their faces when they find out the template for a ring buffer isn't in the STL.
Hehe...yup, this was a challenging one :) I figured that at this point, I’ve talked about almost all of the “tools” in FreeRTOS to make something like a multithreaded sample-and-process program. The ring or double buffer parts are missing, but I figured that there are enough examples out there on how to use/make them (and they’re not really RTOS related, anyway) :)
Is there any reason not to use xQueueSendToBackFromISR(..) instead of a custom double buffer?
@@sigusr For this particular example, you can probably get away with using a queue, as data is being produced and consumed relatively slowly. However, queues are slow compared to direct memory read/writes, as they have extra overhead to be thread-safe. The point of the exercise is to create an RTOS application where you need to work with data being captured from a sensor at a rapid pace (and therefore would not be able to use a queue).
If you're curious, this person found that queues can be written to or read from at about 3 us per access on the ESP32: techtutorialsx.com/2017/09/16/esp32-arduino-freertos-queues-performance-test/
thanks shawn
I got error with the solution simple: Average: 124Guru Meditation Error: Core 1 panic'ed (Unhandled debug exception). any hint?
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?
Great
In esp32 which core will execute ISR functions? Is it possible to shift the ISR to a particular Core
The core in which the ISR was assigned (attached) will be the core that executes the ISR. It is not possible to move the ISR once attached to a core. This section gives more information about ISR: docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/intr_alloc.html#internal-peripheral-interrupts
@@ShawnHymel Thanks
Jesus Christ this was too fast to understand it all lol
see you again
This should be titled Timer Interrupts not Hardware Interrupts.
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
Absolutely!
I suspect his prescalar got wrongly programmed :)