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

Simplify interrupt and RTOS timer tick handlers

Browse source 
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.
This commit is contained in:
Angus Gratton 2015-09-24 10:17:07 +10:00
parent ed8470631f
commit 89c481c606
4 changed files with 31 additions and 68 deletions
Download patch file Download diff file Expand all files Collapse all files

55
core/esp_interrupts.c
View file

@ -14,47 +14,26 @@ void IRAM _xt_isr_attach(uint8_t i, _xt_isr func)
isr[i] = func;
}
/* This ISR handler is taken directly from the FreeRTOS port and
probably could use a cleanup.
/* Generic ISR handler.
Handles all flags set for interrupts in 'intset'.
*/
uint16_t IRAM _xt_isr_handler(uint16_t i)
uint16_t IRAM _xt_isr_handler(uint16_t intset)
{
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;
}
/* 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);
}
_xt_clear_ints(1<<index);
while(intset) {
uint8_t index = __builtin_ffs(intset) - 1;
uint16_t mask = BIT(index);
_xt_clear_ints(mask);
isr[index]();
intset -= mask;
}
isr[index]();
return i & ~(1 << index);
return 0;
}