Adds a semaphore used by readers are writers.
Fixes writing to the flash from constant data stored in the flash, using a bounce buffer.
Handle reading into unaligned value buffers.
Removed memory allocation from most read and write paths. Only read paths that return a blob of data allocate memory now, and the iterator.
Store small integers as binary values, avoiding parsing and formatting in these paths.
* Sysparam implementation
sysparam improvements
Mostly done, a few minor cleanups left.
Add sysparam_editor example
Sysparam code cleanup
Add documentation to sysparam.h
Fix up sysparam.h docs
Added a couple more debug statements
Fix potential memory leak if realloc() fails
Major sysparam overhaul
Add sysparam_get_info function
Add sysparam initialization to app_main.c
* Fixed warnings, added license
In case of heap corruption or some other major problem, dumping details
in the exception handler can cause a crash loop - so fail out if we seem
to be going in circles.
Also reduces the IRAM footprint of the fatal exception handler, as only
the prelude (which disables interrupts & enables the flash mapping) is
in IRAM now.
Closes#54, relevant to #133.
Created `gpio_set_pullup` to configure pullups independently of direction.
Removed GPIO_INPUT_PULLUP direction type.
Added misc other helper functions in iomux.h
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