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
UAVObjects, but pass it in from the macro definition. Saves memory for each
objects.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2559 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
