- use IRQStack for ISRs (at begening of SRAM) (let's call it the irq stack)
- use end of heap for stack needed during initialization (let's call it the init stack).
- the systemStats in GCS indicate the remaining bytes in the IRQ stack (this is realy usefull to monitor our (nested) IRQs.
This is the base ground to provide as much memory as possible available at task creation time.
Next step is to re-organize the initialization in order to move all the init out of the thread's stacks onto the init stack.
This will provide as much memory as possible available at task creation time.
Basically the stack during initialization will be destroyed once the scheduler starts and dynamic alloc are made (since the init stack is at the end of the heap). We will need to make sure we don't clobber the heap during initialization otherwise this will lead to stack corruption.
outputs. Warning: This has no failsafes like arming. We should discuss if
this is appropriate.
In addition accessory objects can be routed throught the mixer for collective
or flaperon.
matches. Read the flash first bytewise to compute CRC instead of buffering
which is more RAM efficient but very inefficient as it sets up many one byte
SPI transfers.
Also incremented the filesystem magic flag to trigger an automatic flash wipe
on this upgrade.
- only affect flight/PiOS (no change for posix and win32)
- tested on recent master (some runtime on CC with GCS)
- the new timer feature is not compiled-in since we don't use it yet.
- NO TEST FLIGHT
When running flight software from master (cf74908), my
config was pushing the system module stack usage to within
16 bytes of its limit. This triggers a stack overflow
alarm which prevents the quad from arming/flying.
This change increases the available stack size such
that there are 72 bytes of stack free (a previously stated
safe margin) when my quad is sitting idle and unarmed on
the bench.
The pipxtreme boards use a sector of the on-board flash
for configuration storage. Adjust the memory maps to
reflect this.
The board_info_blob is also extended to include the EE
bank definitions. This should be used by the pipxtreme
firmware rather than determining it based on chip size.
