Consolidate interrupt management in core as esp/interrupts.h & esp_interrupts.c

This commit is contained in:
Angus Gratton 2015-09-24 08:58:34 +10:00
parent 65307aed75
commit ed8470631f
8 changed files with 83 additions and 98 deletions

View file

@ -265,60 +265,3 @@ void IRAM vPortExitCritical( void )
portENABLE_INTERRUPTS();
}
/*-----------------------------------------------------------*/
/* Main ISR handler for FreeRTOS side of the ESP libs?
As far as I can tell, the "real" Xtensa ISRs ("Exceptions") are
handled in libmain.a (xtensa_vectors.o) which then can call into here
passing an interrupt mask.
*/
_xt_isr isr[16];
void IRAM _xt_isr_attach(uint8_t i, _xt_isr func)
{
isr[i] = func;
}
uint16_t IRAM _xt_isr_handler(uint16_t i)
{
uint8_t index;
/* I think this is implementing some kind of interrupt priority or
short-circuiting an expensive ffs for most common interrupts - ie
WDT And GPIO are common or high priority, then remaining flags.
*/
if (i & (1 << INUM_WDT)) {
index = INUM_WDT;
}
else if (i & (1 << INUM_GPIO)) {
index = INUM_GPIO;
}else {
index = __builtin_ffs(i) - 1;
if (index == INUM_MAX) {
/* I don't understand what happens here. INUM_MAX is not
the highest interrupt number listed (and the isr array
has 16 entries).
Clearing that flag and then setting index to
__builtin_ffs(i)-1 may result in index == 255 if no
higher flags are set, unless this is guarded against
somehow by the caller?
I also don't understand why the code is written like
this in esp_iot_rtos_sdk instead of just putting the i
&= line near the top... Probably no good reason?
*/
i &= ~(1 << INUM_MAX);
index = __builtin_ffs(i) - 1;
}
}
_xt_clear_ints(1<<index);
isr[index]();
return i & ~(1 << index);
}

View file

@ -73,8 +73,8 @@ extern "C" {
#include "esp8266.h"
#include "espressif/esp8266/ets_sys.h"
#include <stdint.h>
#include "xtensa_rtos.h"
#include "xtensa_interrupts.h"
#include "xtensa_rtos.h"
#include <esp/interrupts.h>
/*-----------------------------------------------------------
* Port specific definitions for ESP8266