0
\$\begingroup\$

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?

\$\endgroup\$
5
  • 1
    \$\begingroup\$ Interrupt interrupts current cpu work on some event... And execute some code assigned to it... It may be based on timer but it may be based on "value changed" of some device(fx pin state) \$\endgroup\$
    – Selvin
    Jul 24, 2023 at 8:53
  • \$\begingroup\$ Are you interested in knowing about how interrupts work in general, or specifically in your program? \$\endgroup\$
    – user253751
    Jul 24, 2023 at 9:12
  • \$\begingroup\$ I want generally how it works and how can be it implemented in controller? \$\endgroup\$
    – Kuralmozhi
    Jul 24, 2023 at 10:23
  • 1
    \$\begingroup\$ why do you 'need to work with interrupts' ? Generally, if you need to, you'll know why, and therefore how. Is it that the AHT25 library requires them? If so, the library will probably configure them behind the scenes, and all you need to do is make sure they don't conflict with any other libraries trying to use the same ones, a good library should tell you in requirements what it needs. \$\endgroup\$
    – Neil_UK
    Jul 24, 2023 at 11:18
  • \$\begingroup\$ AHT25 doesn't requires interrupts, I want to learn how it works? and how can be it done through my project. \$\endgroup\$
    – Kuralmozhi
    Jul 24, 2023 at 11:20

1 Answer 1

2
\$\begingroup\$

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.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ It's worth noting that a by the very physics of what temperature is, there's absolutely no sense in expecting a temperature sensor to cause an interrupt. Whether or not your not your your microcontroller reacts to a changed temperature within a couple dozen microseconds makes no difference. So, you just query the sensor every so and so often – my guess is once or twice per second is already more than enough – and don't use an interrupt. \$\endgroup\$ Jul 24, 2023 at 13:31
  • \$\begingroup\$ Thanks @jonathanjo ! well explained about basic concept of interrupts! \$\endgroup\$
    – Kuralmozhi
    Jul 25, 2023 at 3:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.