- switch back to MSP stack before starting the scheduler so that the sheduler can use the IRQ stack (when/if needed).
- call the C portable function in heap1 to claim some stack back (the number to claim is taken from linker file).
- start the scheduler from reset vector (I move this here from main because it make sense to not go back to C (so that I don't need to copy the rolled stack in case the sheduler returns). This make it more clean.
- Also I have added the call to the mem manager if sheduler return. that way, we don't reset indefinitely if memory runs out. We will go to this handler and figure things out (right now, it's just looping but at least not rebooting. Probably trap NMI would be better (later improvement).
The part missing for this part is the weak attribute for the function in heap1.c so that we don't have to update everything with empty stub.
I think the weak atrribute for C function called in assembly is arch dependent so I am not sure if this is possible (will look into it, maybe somebody outthere nows).
Right now, it's heap1 dependent and won't work with heap2. I will clean that up the next couple of days.
I did some test and it looks good.
this is without init code re-organization so we don't free as much as we will be it's good starts.
This compile with sim_posix (since it does not affect portable code) so this is really clean.
I only tested this with CC. I will port it for OP when I will work on heap2.
- 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.
