j3d1/esp-open-rtos
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
esp-open-rtos/core/esp_interrupts.c

46 lines
899 B
C
Raw Permalink Normal View History

Consolidate interrupt management in core as esp/interrupts.h & esp_interrupts.c
2015-09-23 22:58:34 +00:00
/* ESP8266 Xtensa interrupt management functions
*
*
* Part of esp-open-rtos
* Copyright (C) 2015 Angus Gratton
* BSD Licensed as described in the file LICENSE
*/
#include <esp/interrupts.h>
_xt_isr isr[16];
lwip sys_arch: Add functional xInsideISR implementation Relies on global flags set when the user ISR is executing. Unclear if this fixes any bugs as ISR code may not have been calling into LWIP, but the previous implementation was broken.
2016-04-20 05:04:29 +00:00
bool esp_in_isr;
Consolidate interrupt management in core as esp/interrupts.h & esp_interrupts.c
2015-09-23 22:58:34 +00:00
void IRAM _xt_isr_attach(uint8_t i, _xt_isr func)
{
isr[i] = func;
}
Simplify interrupt and RTOS timer tick handlers RTOS Timer tick handler is now the same as any other ISR. This causes a few subtle behaviour changes that seem OK but are worth noting: * RTOS tick handler sdk__xt_timer_int() is now called from one stack frame deeper (inside _xt_isr_handler()), whereas before it was called from the level above in UserHandleInterrupt. I can't see any way that the extra ~40 bytes of stack use here hurt, though. * sdk__xt_timer_int() was previous called after all other interrupts flagged in the handler, now it's called before the TIMER FRC1 & FRC2 handlers. The tick handler doesn't appear to do anything particularly timing intensive, though. * GPIO interrupt (value 3) is now lower priority than the SPI interrupt (value 2), whereas before it would have been called before SPI if both interrupts triggered at once.
2015-09-24 00:17:07 +00:00
/* Generic ISR handler.
Handles all flags set for interrupts in 'intset'.
Consolidate interrupt management in core as esp/interrupts.h & esp_interrupts.c
2015-09-23 22:58:34 +00:00
*/
Simplify interrupt and RTOS timer tick handlers RTOS Timer tick handler is now the same as any other ISR. This causes a few subtle behaviour changes that seem OK but are worth noting: * RTOS tick handler sdk__xt_timer_int() is now called from one stack frame deeper (inside _xt_isr_handler()), whereas before it was called from the level above in UserHandleInterrupt. I can't see any way that the extra ~40 bytes of stack use here hurt, though. * sdk__xt_timer_int() was previous called after all other interrupts flagged in the handler, now it's called before the TIMER FRC1 & FRC2 handlers. The tick handler doesn't appear to do anything particularly timing intensive, though. * GPIO interrupt (value 3) is now lower priority than the SPI interrupt (value 2), whereas before it would have been called before SPI if both interrupts triggered at once.
2015-09-24 00:17:07 +00:00
uint16_t IRAM _xt_isr_handler(uint16_t intset)
Consolidate interrupt management in core as esp/interrupts.h & esp_interrupts.c
2015-09-23 22:58:34 +00:00
{
lwip sys_arch: Add functional xInsideISR implementation Relies on global flags set when the user ISR is executing. Unclear if this fixes any bugs as ISR code may not have been calling into LWIP, but the previous implementation was broken.
2016-04-20 05:04:29 +00:00
esp_in_isr = true;
Simplify interrupt and RTOS timer tick handlers RTOS Timer tick handler is now the same as any other ISR. This causes a few subtle behaviour changes that seem OK but are worth noting: * RTOS tick handler sdk__xt_timer_int() is now called from one stack frame deeper (inside _xt_isr_handler()), whereas before it was called from the level above in UserHandleInterrupt. I can't see any way that the extra ~40 bytes of stack use here hurt, though. * sdk__xt_timer_int() was previous called after all other interrupts flagged in the handler, now it's called before the TIMER FRC1 & FRC2 handlers. The tick handler doesn't appear to do anything particularly timing intensive, though. * GPIO interrupt (value 3) is now lower priority than the SPI interrupt (value 2), whereas before it would have been called before SPI if both interrupts triggered at once.
2015-09-24 00:17:07 +00:00
/* WDT has highest priority (occasional WDT resets otherwise) */
if(intset & BIT(INUM_WDT)) {
_xt_clear_ints(BIT(INUM_WDT));
isr[INUM_WDT]();
intset -= BIT(INUM_WDT);
Consolidate interrupt management in core as esp/interrupts.h & esp_interrupts.c
2015-09-23 22:58:34 +00:00
}
Simplify interrupt and RTOS timer tick handlers RTOS Timer tick handler is now the same as any other ISR. This causes a few subtle behaviour changes that seem OK but are worth noting: * RTOS tick handler sdk__xt_timer_int() is now called from one stack frame deeper (inside _xt_isr_handler()), whereas before it was called from the level above in UserHandleInterrupt. I can't see any way that the extra ~40 bytes of stack use here hurt, though. * sdk__xt_timer_int() was previous called after all other interrupts flagged in the handler, now it's called before the TIMER FRC1 & FRC2 handlers. The tick handler doesn't appear to do anything particularly timing intensive, though. * GPIO interrupt (value 3) is now lower priority than the SPI interrupt (value 2), whereas before it would have been called before SPI if both interrupts triggered at once.
2015-09-24 00:17:07 +00:00
while(intset) {
uint8_t index = __builtin_ffs(intset) - 1;
uint16_t mask = BIT(index);
_xt_clear_ints(mask);
isr[index]();
intset -= mask;
Consolidate interrupt management in core as esp/interrupts.h & esp_interrupts.c
2015-09-23 22:58:34 +00:00
}
lwip sys_arch: Add functional xInsideISR implementation Relies on global flags set when the user ISR is executing. Unclear if this fixes any bugs as ISR code may not have been calling into LWIP, but the previous implementation was broken.
2016-04-20 05:04:29 +00:00
esp_in_isr = false;
Simplify interrupt and RTOS timer tick handlers RTOS Timer tick handler is now the same as any other ISR. This causes a few subtle behaviour changes that seem OK but are worth noting: * RTOS tick handler sdk__xt_timer_int() is now called from one stack frame deeper (inside _xt_isr_handler()), whereas before it was called from the level above in UserHandleInterrupt. I can't see any way that the extra ~40 bytes of stack use here hurt, though. * sdk__xt_timer_int() was previous called after all other interrupts flagged in the handler, now it's called before the TIMER FRC1 & FRC2 handlers. The tick handler doesn't appear to do anything particularly timing intensive, though. * GPIO interrupt (value 3) is now lower priority than the SPI interrupt (value 2), whereas before it would have been called before SPI if both interrupts triggered at once.
2015-09-24 00:17:07 +00:00
return 0;
Consolidate interrupt management in core as esp/interrupts.h & esp_interrupts.c
2015-09-23 22:58:34 +00:00
}
Reference in a new issue Copy permalink