#328 ESP32 Secrets: Interrupts, and Deep-Sleep under the Hood

Do you need speedy reactions and simple coding? Then, interrupts are a good thing to use. And, because interrupts have things in common with deep-sleep, we will also dig into that topic. And we will find some “Secrets of the ESP32”. For sure, we will look “under its hood.”
I am a proud Patreon of GreatScott!, Electroboom, Electronoobs, EEVblog, and others.

Links:

The links above usually are affiliate links which support the channel (no additional cost for you).
If you want to support the channel, please use the links below to start your shopping. No additional charges for you, but I get a commission (of your purchases the next 24 hours) to buy new stuff for the channel

Please do not try to Email me or invite me on LinkedIn. These communication channels are reserved for my primary job
As an Amazon Associate, I earn from qualifying purchases

[AndreasSpiess]

At 15:20 I mixed micro with milliseconds. As you can see on the oscilloscope it is milliseconds

[jackm]

How lucky we all are that these super well-produced, interesting and informative videos are available to view at our leisure. What a world we all live in! Thank You Andress!

[KarmaDonyo]

This is the second video I've watched by Andreas, and I subscribed after watching the first few minutes of this. With so much bad information out there, this channel is a breath of fresh air. So much to unpack in this video. I'll be watching it again and again, thank you Andreas.

[santorcuato]

Thanks Andreas, you ever find the way to make it clear and easy to understand. The two channel osciloscope trick is really interesting, but this is part of your very high end workshop...

[myksmith]

Brilliant video. Exactly what I wanted.
And excellent overview for the beginner or even the experienced.
I worked on embedded systems 15 years ago - we used microcontrollers, GPS, cellular comms, and used this to create telematics devices installed on John Deere and Liebherr equipment (and others). We read the CAN bus, and used interrupts for things like movement, engines turning on and other interrupts. Since then I've been doing product management, and now I'm getting back into this level of coding... and was depressed that Arduinos don't have good interrupts and sleep.
Your video has brought me back up to speed SUPER quickly, helping me restore my memory from tape, and quickly jumpstarting me with a new microcontroller board.

[SuperMrHolland]

As always a pleasure to watch. I like that you are not only focusing on hardware, but also explains how to utilize software to make project simple and easy to make

[Arthur-Descamps]

Thank you ! Perfect timing ! We were just running into random crashes yesterday with our encoders running off ESP 8266. Cleaning up the interrupt functions based on your advises solved our issue ! For the little story, We are building a 4DOF motion platform using salvaged standing desk electric pistons and ESPs. Such a great content every time ! Thanks again !

[TheModelmaker]

Great Topic, The ESP32 has so many new features, performance advantages and value over the Arduino. For the hobbyist, one platform can serve many projects . Your post make the transition worth attempting. Keep them coming!

[aspzx]

It would be interesting to see a video on using the ULP core for running code without waking up the ESP32. Would be nice to explore the possibilities and limitations of the ULP core.

[PhG]

Well done ! Indeed interesting, again I've learned something new.

[bgable]

Great job of using the KISS principle, Keep It Simple S.... Silly. This is the most straight for explanation of ISRs, aka, AST as we know them on our beloved VAX-32s. Thanks for showing us all your amazing "scope" work! I'm REALLY enjoying your 2020 video's along with all the others, VERY HELPFUL!!!

[yayser]

Greetings from Turkey Andreas, I just wanted to thank you for all the great videos you have put out here on the channel. I can't imagine what I would do without you. Loved the cat btw :)

[czarekcz]

Mr Spiess, I enjoy your presentations and like this one too. Thank you for all your effort and shared knowledge. There are several reasons why CPU like this one may have long interrupt latency. One of them (and it is a Real Time limitations of large processors like multicore Intel and ARM) is cache coherency. Simple, interrupt code maybe not present in cache and other current content of the cache need to be saved before reloading new one to/from RAM. For vary fast approach, user need to instruct compiler (I dont know how to do it at ESP32 yet) to keep interrupt service routine (if short) permanently in cache. This is typical approach for RT Linux for example.

[bernhardgabler]

A great part of the inaccuracy in the interrupt code (at 7:13 in video) is caused by your own loop code:
{ frequency = count; display(0, "frequency=", frequency); lastEntry=millis(); count=0 }

You use count but reset it only after displaying on the pretty slow LCD. That means, all events that occur during the LCD operation are not counted, but lost. Also, if the duration of LCD output varies, it worsens the count precision. You could improve it if you first completed the job of count handling:

{ frequency = count; count=0; display(0, "frequency=", frequency); lastEntry=millis(); }



BTW, your polling loop (at 3:54 in video) would be more elegant if you replaced
lastentry= millis(); while (millis() < lastEntry + 1000) {...}
with
endTime=millis()+1000; while (millis() < endTime) {...}
This way the addition would be done only once. However a good compiler might catch this and produce the same binary code.

[difegam]

Thank you for the explanation... You are really making a valuable content. I'm already sitting in the first row waiting a next video.

[klassichd]

Thanks a lot for your effort, your experiments, the video and the explanations. And we are now back to the same question we discussed when the ESP32 became availabe: How to use the different cores for different tasks in Arduino IDE, e.g. to decouple WiFi. Up to now I did not find a solution. This is why my counter at the water meter still uses 2 pcs ESP8266. One just for counting and tranferring data via HW-serial without any WiFi output and the second for analyzing the data and communication with my home automation system. Not very elegant, but runs very stable, uptime 657 days since the last blackout caused by road construction works.

[StefanoBettega]

I agree with your idea of being the RTOS influencing the interrupt latency. The RTOS itself (which seems to mee FreeRTOS reading the definitions you wrote to allow ISRs to be safely called) has surely some routines to schedule our loop() function with its own tasks, which can be in turn the communications module handlers (Wifi and/or Bluetooth). Even though you disable them, they could be still working for some reason. In addition the scheduler itself can use an interrupt to switch internal tasks, and this can be another jitter cause.

[RobBarter]

Thank you for pointing me towards the Otii. Now have one and it is becoming an essential piece of kit. Especially now I’m investigating why my new custom board is using 1mA more than it should be

[JanJeronimus]

To experiment with measuring a higher frequency a (simple) hardware frequency divider could be added.

[alexandern]

Thank you for another interesting and instructive video Andreas.
>edit: went through the comments and found this was already reported, sorry
I just wanted to add that RTOS seems indeed to be a culprit for the interrupt response latency and jitter. I think that attachInterrupt actually hooks up not to the interrupt controller but to an RTOS callback function. This function is entered the queue of RTOS tasks, and get executed after the completion of all the previous tasks only. Apparently it is possible to get a fast interrupt response when programming using noOS SDK from Espressif but I did not try this yet.