Also implement some ordering (quite ugly still) in the module init and task creation order so we can decide which module to start/init first
and which module to start/init last.
This will be replaced/adapter with the uavobject list later (once it's implemented).
reserving some space for module init and task create parameters to customize module/task creation (this will be usefull once we get the list and customization from customer).
Changes have been made for OP and CC. Tested comped with CC,OP, sim_posix.
Only ran on bench with CC for couple of minutes (code increase expected but no dropping of stack which is good).
This gives task creation at the time wherethe all heap is available.
- create linker section for those <module>Initialize()
- later this list will incorporate parameters as well. (this probably will be more a OP feature to swap/remove/delete module on the fly.
- this is not done at compile time anymore by Makefile.
- this will allow us to have control on the module start at run-time (not implemented but build the ground for it).
- this simplify the startup (Part of code re-org).
- this change does not affect sim_posix and win32 (since they don't need that)
- ensure it's compiling for PiOS.posix
- port to PiOS.win32 but not tested (not compiled)
- tested on CC
- compile on OP.
- this free ~200 bytes.
- current avalable bytes (is we keep the same remaining bytes on the stack than before) is easily passed the 1.2Ko mark on CC with new gcc (4.5.2)
- this does not include init-reorg for each module (I still think more can be freed)
config plugin updates. Has not been tested in flight yet although seems
sensible so please be careful when using this code.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@3166 ebee16cc-31ac-478f-84a7-5cbb03baadba
rotate sensors to make sure stabilization behaves well so don't use till then.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@3100 ebee16cc-31ac-478f-84a7-5cbb03baadba
Note: AttitudeSettings changed so you'll need to re-zero it
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@3090 ebee16cc-31ac-478f-84a7-5cbb03baadba
that it will completely follow the accel attitude each cycle and is way too
high. Ki=1 means the gyro bias wil be correct by accels each cycle (way too
high).
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2755 ebee16cc-31ac-478f-84a7-5cbb03baadba
convergence of gyro bias, then the normal values can be lower.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2753 ebee16cc-31ac-478f-84a7-5cbb03baadba
because this is what is determines when the Stabilization code executes.
Because we aren't oversampling gyros relative to the PID in CC we should set
the attitude first (computational time to do so is negligible).
Also change update rate to 500 Hz.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2750 ebee16cc-31ac-478f-84a7-5cbb03baadba
functions to use it easily
Conflicts:
flight/Modules/Attitude/attitude.c
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2707 ebee16cc-31ac-478f-84a7-5cbb03baadba
queue, which update sensors waits for. This confirms one update per gyro
update. All available accel data will be pulled off each time.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2705 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
