1) Combining all binary or mode values into a single byte
2) Adding accessor functions to read/write the flag bits
3) Reduced the size of the time values from 32 bits to 16 bits
can catch it and return -1. Do NOT panic when they are null as this is
something that should be caugth at run time in some cases.
Ideally as a compromise in a task start it could have a set of
PIOS_Assert(ObjectNameHandle()) to make sure the minimal set of objects it
needs are there.
Also reduce heap has it does not fit in SRAM anymore (not with current compiler).
(that's ok since if there is more space available, it will be reclaimed).
Merge branch 'master' into OP-423_Mathieu_Change_Init_To_Reduce_Memory_Footprint
Conflicts:
flight/CopterControl/System/inc/pios_config.h
flight/Modules/ManualControl/manualcontrol.c
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.
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.
per target as defined in Makefile (and/or Make include file) For
OpenPilot this is flight/OpenPilot/UAVObjects.inc For sim_posix and
sim_win32 needs rebuild of uavobjectgenerator and uavobjects!
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2736 ebee16cc-31ac-478f-84a7-5cbb03baadba
Putting Corvus patch back in. Need to delete uavobjects-synthetics directory
for this to work.
This reverts commit 9cd98bec8fb5e0679c625eb256a94d161a8ce345.
Conflicts:
flight/CopterControl/Makefile
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2671 ebee16cc-31ac-478f-84a7-5cbb03baadba
Note: This patch did not build after a clean build.
This reverts commit 7e75b5d16481a32689433c868b67916816d8b9fb.
Conflicts:
flight/CopterControl/Makefile
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2651 ebee16cc-31ac-478f-84a7-5cbb03baadba
On architectures supporting automatic initializing, flight/UAVObjects/uavobjectsinit_linker.c is used
On architectures NOT supporting automatic initializing, an uavobjectgenerated file build/uavobject-synthetics/flight/init/uavobjectsinit.c is used
build/uavobjects-synthetics/flight/uavobjectsinit.c went away, so that a wildcard include in the Makefile will not include the (wrong) initialisation code in either version
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2640 ebee16cc-31ac-478f-84a7-5cbb03baadba
The UAVObject initcall list is now automatically
generated at link time based on the exact set of
UAVObjects linked into the firmware image.
This will allow any subset of UAVObjects to be
used in any firmware image.
The uavobj_initcall() macro automatically adds the
marked function's address into the .initcalluavobj.init
ELF section.
The UAVObjectsInitializeAll() function now simply
iterates over the functions listed in the
.initcalluavobj.init section and calls them.
You can see the contents of this section in the ELF file
like this:
./tools/arm-2009q3/bin/arm-none-eabi-objdump \
--syms -j .initcalluavobj.init \
./build/openpilot/OpenPilot.elf
This is fundamentally the same mechanism that the Linux
kernel uses to initialize the specific set of components
that the user has selected in their kernel configuration.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2630 ebee16cc-31ac-478f-84a7-5cbb03baadba
exists, no need to store pointers to it, but put the structure for the first LL
object in the ObjectListStruct
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2560 ebee16cc-31ac-478f-84a7-5cbb03baadba
