- 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.
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.
order to free a timer. Mode PIOS_DELAY (not working cleanly) to TIM3 because
Spektrum resets TIM2 count.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2758 ebee16cc-31ac-478f-84a7-5cbb03baadba
also increase the telem queue to decrease event errors (can be reverted later if
we need the memory back)
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2730 ebee16cc-31ac-478f-84a7-5cbb03baadba
2. Disable FirmareIAP module in CC (somehow causes lockups when also using vTaskDelayUntil in Attitude WTF)
3. Make the SPI bus run a little faster so we can handle the 3200 Hz from accel
while running the filter at 333 Hz
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2664 ebee16cc-31ac-478f-84a7-5cbb03baadba
Beginning of unifying the input types into PIOS_RECEIVER.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2568 ebee16cc-31ac-478f-84a7-5cbb03baadba
semaphores for sharing the bus between the flash chip and this though.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2473 ebee16cc-31ac-478f-84a7-5cbb03baadba
size (may eventually need to be per revision if we get bigger ram). Typo in a
the ifdefs to get allow disabling SDCARD
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2423 ebee16cc-31ac-478f-84a7-5cbb03baadba
PIOS_USD_SDCARD. However, this needs to be cleaned up and abstracted out of
the UAVObjectManager who shouldn't care about the storage layer.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2417 ebee16cc-31ac-478f-84a7-5cbb03baadba
