The FreeRTOS IDLE task was using 512 bytes of stack.
The UAVObject Event task was also using 512 bytes of stack.
Both have been reduced, recovering 400+ bytes of heap.
heap reamining is low (about 500) but stacks can be ajusted (specially the 200 bytes from system) to give the level close to 1Ko if needed.
Merge branch 'master' into OP-423_Mathieu_Change_Init_To_Reduce_Memory_Footprint
Conflicts:
flight/CopterControl/System/inc/FreeRTOSConfig.h
flight/CopterControl/System/inc/pios_config.h
It was tested being merged with OP-472_CorvusCorax_CopterControl-Guidance_v3
branch, Spektrum on USART3 and GPS on USART1 and seems to work.
Currently defaults mimic original behavior, that is, if USE_SPEKTRUM
is not defined - define USE_PWM and USE_GPS. Thsi should be refactored
later to make it configurable from the Makefile.
Also it was not ported to the OP MB: it currently does not support the
S.Bus hardware and still has original behavior with the patch. But this
is one more step to dynamic configuration of ports.
TODO: This should be dynamic in the future.
But for now define any compatile combination of:
USE_I2C (shared with USART3)
USE_TELEMETRY
USE_GPS
USE_SPEKTRUM
USE_SBUS (USART1 only, it needs an invertor)
and optionally define PIOS_PORT_* to USART port numbers
Defaults are:
#define PIOS_PORT_TELEMETRY 1
#define PIOS_PORT_GPS 3
#define PIOS_PORT_SPEKTRUM 3
#define PIOS_PORT_SBUS 1
#define USE_TELEMETRY
#define USE_GPS
Telemetry, GPS and PWM input are enabled by default.
- 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.
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
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
