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.
Seems I got the functionality of this bit inverted when
initially testing.
In testing it also seems open drain mode is ignored on some pins, which
still source current. Needs more investigation though (may be pullups
internal to the ESP modules or set by default in software.)
Relates to #45
Seems I got the functionality of this bit inverted when
initially testing.
In testing it also seems open drain mode is ignored on some pins, which
still source current. Needs more investigation though (may be pullups
internal to the ESP modules or set by default in software.)
Relates to #45
Mostly determined from reverse engineering and poking around.
Includes first "experiments" program with random bits and pieces for
poking at registers, may be useful to keep in source control but not
useful for writing actual programs.
- Fix dir-locals so emacs won't inject occasional tabs to case statements.
- Fix stray tab indentation in example programs. (Thx @pfalcon for pointing this out)
