What is Interrupts in ESP32? [closed]

Question

I am working with ESP32 WROOM32 Controller and AHT25 Temperature and Humidity sensor. I need to work with Interrupts in my device. Basically I don't know what is interrupts and How to use my device using interrupt mode? and Why this is needed? Is timer and interrupt are same? I go through internet but I can't understand this concept?

Answer 1

The basic idea of interrupts is approximately this: when the interrupt is requested, the CPU will do a hardware-triggered jmp-to-subroutine.

• Most CPUs have a number of interrupt sources
• They are usually prioritised
• They usually are only checked between instructions
• The jump-to-interrupt-routine normally pushes as much state as is required to invisibly return once it's finished
• Usually, this is at least the condition codes/flags, and the program counter
• The interrupt response routine is usually "vectored", that is to say there is a pointer to it at some specific location in memory
• Correspondingly, the return-from-interrupt instruction will pop the appropriate registers from the stack
• Typically the interrupt request line will be active low with a number of devices which can pull it low
• The CPU's response must therefore find out which device it was by polling all the devices which might request a particular interrupt
• A modern highly-integrated devices is likely to have a large number of internal devices such as timers which can generate an interrupt when they count down to zero or other predefined state
• General purpose IO is often equipped with interrupt on rising edge / falling edge / any edge
• Many devices have "software interrupts", which are similar except the trigger is a particular instruction
• Many devices have "exceptions" which are similar except the trigger is some kind of improper data (such as division by 0)

For a concrete example

• Once an Interrupt request line goes active
• The CPU notices before the next instruction is fetched
• And instead of doing a normal instruction fetch
• The current PC is pushed onto the stack
• The current flags are pushed onto the stack
• Flags are changed to indicate already servicing an interrupt
• The memory pointer at TOPMEM-4 is fetched
• This address is loaded into the PC
• Code is excuted, perhaps loading data from a peripheral
• And very carefully modifying absolutely no registers
• The return from interrupt pops the flags and PC
• And exceution continues as normal

This is in fact the behaviour of the 6809 CPU, which is a good model for later, more complex systems because it has:

• Several levels of prioritisation
• Vectoring
• Software interrupts (aka "traps")
• Exceptions (eg DIV0)

The example you give, a I2C connected temperature and humidity sensor is not a typical candidate for interrupt-driven responses. This is because: it has no method to directly ask for the interrupt, and must be polled. The most common way to use this would be to use timer-based interrupts (ie, poll the device periodically). However, as the measurements are not likely to be wanted frequently, it would be more usual to just poll periodically.

Contrast this with, say, a serial input, where the CPU wants to fetch the data absolutely as soon as it can and doesn't want to poll. In fact, in a typical computer's operating system it does nothing and waits for a device to request an interrupt.