1
0
mirror of https://bitbucket.org/librepilot/librepilot.git synced 2024-11-30 08:24:11 +01:00
Commit Graph

69 Commits

Author SHA1 Message Date
Stacey Sheldon
2119067722 Merge remote-tracking branch 'op-revo/james/revo' into revo-next
Conflicts:
	Makefile
	flight/Modules/Attitude/revolution/attitude.c
	flight/Modules/Battery/battery.c
	flight/Modules/FixedWingPathFollower/fixedwingpathfollower.c
	flight/Modules/GPS/GPS.c
	flight/Modules/ManualControl/inc/manualcontrol.h
	flight/Modules/ManualControl/manualcontrol.c
	flight/Modules/OveroSync/overosync.c
	flight/Modules/PathPlanner/inc/pathplanner.h
	flight/Modules/PathPlanner/pathplanner.c
	flight/Modules/Sensors/sensors.c
	flight/Modules/VtolPathFollower/vtolpathfollower.c
	flight/PiOS/Boards/STM32F4xx_Revolution.h
	flight/PiOS/Boards/pios_board.h
	flight/PiOS/STM32F4xx/library.mk
	flight/PiOS/inc/pios_hmc5883.h
	flight/PiOS/inc/pios_l3gd20.h
	flight/PiOS/inc/pios_rfm22b_priv.h
	flight/Revolution/Makefile
	flight/Revolution/Makefile.osx
	flight/Revolution/System/inc/pios_config.h
	flight/Revolution/UAVObjects.inc
	ground/openpilotgcs/src/libs/utils/coordinateconversions.cpp
	ground/openpilotgcs/src/libs/utils/homelocationutil.cpp
	ground/openpilotgcs/src/libs/utils/homelocationutil.h
	ground/openpilotgcs/src/plugins/config/configrevowidget.cpp
	ground/openpilotgcs/src/plugins/hitlnew/il2simulator.cpp
	ground/openpilotgcs/src/plugins/opmap/opmapgadgetwidget.cpp
	ground/openpilotgcs/src/plugins/plugins.pro
	ground/openpilotgcs/src/plugins/uavobjects/uavobjects.pro
	package/Makefile
	shared/uavobjectdefinition/fixedwingpathfollowersettings.xml
	shared/uavobjectdefinition/fixedwingpathfollowerstatus.xml
	shared/uavobjectdefinition/flightstatus.xml
	shared/uavobjectdefinition/hwsettings.xml
	shared/uavobjectdefinition/manualcontrolsettings.xml
	shared/uavobjectdefinition/pathdesired.xml
	shared/uavobjectdefinition/vtolpathfollowersettings.xml
	shared/uavobjectdefinition/waypoint.xml
2012-10-30 00:08:43 -04:00
Stacey Sheldon
75170177df console: example usage of the debug console 2012-10-11 00:22:07 -04:00
James Cotton
13cabd2ea4 Merge branch 'next' into revo
Conflicts:
	flight/PiOS/Common/pios_rfm22b.c
2012-10-04 16:38:08 -05:00
Laura Sebesta
f2ffd1fb99 Changed DIAGNOSTICS flag to be individual to each module instead of global.
The upshot is the stack usage monitor can be turned on at a lower RAM threshold.
2012-08-24 12:04:05 +02:00
James Cotton
75db0fcb35 Merge branch 'next' into revo
Conflicts:
	flight/Modules/GPS/GPS.c
	shared/uavobjectdefinition/manualcontrolsettings.xml
	shared/uavobjectdefinition/systemalarms.xml
2012-08-12 14:38:38 -05:00
Richard Flay (Hyper)
6d34795494 Re-enabled simposix SDCard support, and removed obsolete SDCard alarm usage from System module 2012-08-01 19:53:59 +09:30
James Cotton
9865466da9 Make sure to create the system queue BEFORE calling task start. Systemmod
initializes differently than other threads and I missed htat.  Huge thanks to
Hyper for making me realize that despite the fact I didn't see it :D.
2012-07-24 09:51:03 -05:00
James Cotton
e38325c745 Should check that the queue allocates and initialize shoudl return -1 if not 2012-07-23 08:47:43 -05:00
James Cotton
545018244c Make saving occur within the system thread instead of the event system thread 2012-07-22 23:03:27 -05:00
James Cotton
42501d6312 Merge branch 'nosave_while_armed' into revo 2012-07-22 02:13:25 -05:00
James Cotton
3eb41d3ef2 When the systemmod callback happens exit if the operation is error or completed 2012-07-19 22:18:36 -05:00
James Cotton
27ad0fcf6f Don't allow the system to save while armed 2012-07-19 21:51:31 -05:00
James Cotton
33beafed27 Remove outdated alarm for sdcard in systemmod. Only affected simulation. 2012-07-03 10:53:10 +02:00
James Cotton
93b77becc0 More the system task priority down and increase the timeout for erasing the
flash so it says completed.  However, it still blocks the system for a long
time.  During an erase the heartbeat will flash at 10 Hz to indicate what's
happening.

This still blocks telemetry even after lowering hte system priority (and there
is a vTaskDelay) which makes me think that the SPI bus being locked is blocking
Sensors or somethign else.  This should not be permited when the system is
armed.

The reason the system locks up during the erase is that the file system
operations occur within the event dispatcher thread.  It is very bad practice
for anything to block this (i.e. callbacks should never take very long).  We
should probably move the object persistence handling into the system thread or
something but that can be a separate issue.
2012-06-11 12:03:32 -05:00
James Cotton
e341a37bd1 Need to add a small delay after save for the load to work correctly. Odd. 2012-06-03 17:26:10 -05:00
James Cotton
25f85ee4fe Add an error flag to ObjectPersistence and when saving a setting make it verify
that the data reads successfully.
2012-06-02 10:23:27 -05:00
James Cotton
f4663b98e4 When the event system or object manager has an error store the object ID in the
SystemStats.
2012-03-20 23:18:07 -05:00
James Cotton
c242ab8b86 Merge branch 'next' into revolution3
Conflicts:
	flight/AHRS/ahrs.c
	flight/AHRS/pios_board.c
	flight/Bootloaders/Revolution/Makefile
	flight/CopterControl/System/pios_board.c
	flight/INS/pios_board.c
	flight/OpenPilot/Makefile
	flight/OpenPilot/System/openpilot.c
	flight/OpenPilot/System/pios_board.c
	flight/PiOS/Boards/STM32103CB_CC_Rev1.h
	flight/PiOS/Boards/STM32F4xx_Revolution.h
	flight/Revolution/Makefile
	flight/Revolution/System/inc/pios_config.h
	flight/Revolution/test.c
2012-01-24 10:46:35 -06:00
Stacey Sheldon
6bb4f0c61d leds: use boot-time config for PiOS LED layer
LEDs are now configured based on a board-specific initialization
in PIOS_BOARD_Init().

LEDs are now named:
  PIOS_LED_HEARTBEAT
  PIOS_LED_ALARM
2012-01-22 18:22:59 -05:00
James Cotton
bb0bfe0ae4 Merge branch 'next' into revolution3
Conflicts:
	flight/Bootloaders/CopterControl/Makefile
	flight/Bootloaders/PipXtreme/Makefile
	flight/Bootloaders/Revolution/inc/pios_config.h
	flight/CopterControl/Makefile
	flight/INS/inc/pios_config.h
	flight/Libraries/taskmonitor.c
	flight/Modules/Altitude/altitude.c
	flight/Modules/Attitude/attitude.c
	flight/OpenPilot/Makefile
	flight/OpenPilot/Makefile.posix
	flight/OpenPilot/System/inc/pios_usb_board_data.h
	flight/OpenPilot/System/inc/taskmonitor.h
	flight/OpenPilot/System/pios_board.c
	flight/OpenPilot/System/taskmonitor.c
	flight/PiOS/Boards/STM32F4xx_Revolution.h
	flight/PiOS/STM32F4xx/pios_bmp085.c
	flight/PiOS/STM32F4xx/pios_iap.c
	flight/PiOS/pios.h
	flight/Revolution/System/inc/pios_config.h
	flight/Revolution/System/inc/taskmonitor.h
	flight/Revolution/System/taskmonitor.c
	ground/openpilotgcs/src/plugins/serialconnection/serialplugin.cpp
	shared/uavobjectdefinition/systemalarms.xml
	shared/uavobjectdefinition/taskinfo.xml
2012-01-21 11:27:03 -06:00
Stacey Sheldon
b05697c2cf taskinfo: ensure usage of TaskInfo uavo is covered by DIAG_TASKS
OpenPilot platform (and thus sim too) was missed when the
DIAG_TASKS macro was broken out from the DIAGNOSTICS macro.

This allowed accesses to the TaskInfo UAVO even though it hadn't
been initialized.
2012-01-15 18:16:50 -05:00
Stacey Sheldon
c97b108a1f bootfault: make IAP usage depend on PiOS config
The sim platforms don't support an IAP mechanism.  Let
PiOS config control when we try to use it.
2012-01-15 18:16:49 -05:00
Stacey Sheldon
f886af186d bootfault: add support for recovery from init failures
After 3 failed warm start attempts, the init sequence
will force the RAM version of the HWSettings object
to its defaults.  This should allow a user to regain
connectivity to a board that is continually faulting
during init.

This is accomplished by:
 - Incrementing a boot counter that is stored in the
   STM32 BKP registers.  These registers survive a
   warm start but are cleared on a cold start (ie. powerup).
 - On multiple failures, force hwsettings to defaults
   and raise the (new) BootFault alarm to prevent arming.
 - Resetting the boot counter whenever the system manages
   to successfully run the System Module task.

NOTE: This does not actually change the hwsettings object in
      flash.  That's up to the user.

This is intended to catch ONLY faults during early initialization.
It should not be used to recover from faults after the application
is up and running.
2011-12-30 23:05:38 -05:00
Stacey Sheldon
7c03875013 diag-tasks: make taskinfo diagnostics a separate enable
This allows task stack analysis without turning on all
of the other diagnostics.
2011-12-30 23:05:37 -05:00
James Cotton
c70a9a5381 Sanitize the floating point math in systemmod.c to be consistently floating and
not double
2011-11-26 15:16:16 -06:00
James Cotton
b110e9c549 Style suggestions to cleanup GPS from Stac 2011-11-12 21:31:01 -06:00
Corvus Corax
aa69027cb2 Merge branch 'next' into CC_GPS 2011-11-11 11:44:11 +01:00
Corvus Corax
e03e3c2ed8 removed "special code" to start optional modules 2011-11-11 11:22:54 +01:00
Oleg Semyonov
8f77d07119 System Module: fix stupid out of memory detection bug 2011-11-07 19:14:55 +02:00
Oleg Semyonov
f71361ca83 Merge branch 'next' into os/GPS-on-CopterControl_next_v2
Conflicts:
	flight/Modules/System/systemmod.c
2011-10-22 23:00:47 +03:00
Corvus Corax
cb8d9c791c PiOS.posix: fixed missing defines in pios_config. removed platform specific inclde from Systemmod (pios_config.h gets included from pios.h) 2011-10-19 22:28:39 +02:00
Corvus Corax
b00751af91 Systemmod bugfix: UAVObject used without Initialization 2011-10-19 22:28:08 +02:00
Oleg Semyonov
53c098dd08 Merge branch 'next' into os/GPS-on-CopterControl_next_v2
Conflicts:
	flight/OpenPilot/System/pios_board.c
	flight/OpenPilot/UAVObjects.inc
	shared/uavobjectdefinition/hwsettings.xml
2011-09-28 22:02:02 +03:00
Corvus Corax
658ae3f809 Modules/System: removed comment line 2011-08-25 16:26:46 +02:00
Corvus Corax
4bd72923e5 Merge branch 'CorvusCorax_unidirectional-GPS-com' into CC_GPS
Conflicts:
	flight/Modules/GPS/GPS.c
	flight/Modules/GPS/GTOP_BIN.c
	flight/Modules/GPS/NMEA.c
	shared/uavobjectdefinition/hwsettings.xml
2011-08-25 15:33:23 +02:00
Stacey Sheldon
edc0caf521 heap: set memory critical alarm on malloc failures
Activate the FreeRTOS malloc failed hook and use it
to set the memory critical alarm.
2011-08-21 23:14:32 -04:00
James Cotton
368323fd59 Merge remote-tracking branch 'origin/james/erase_settings' into next 2011-08-20 13:07:01 -05:00
Corvus Corax
1ad65e0718 Fixed include in sysstemmod. pios_config.h should not be included explicitly. 2011-08-20 15:04:00 +02:00
Corvus Corax
dfd301571a HWSettings: Allow late Initialization and Start of Modules as defined in Makefile(available modules) and UAVObject(actually started modules) 2011-08-20 01:24:06 +02:00
James Cotton
35eef66bfe OP-557: Add a UAVO access method to erase the entire flash chip. Normally not
needed by users because if too much changes I change the FS magic and trigger a
wipe.

Possibly the erase should require a particular "magic" object id value to
execute?  This would make it harder to do manually through UAVOs though.
2011-08-15 10:33:27 -05:00
James Cotton
96c2d24253 Merge branch 'next' into camera_stabilization
Conflicts:
	flight/CopterControl/Makefile
	flight/CopterControl/System/coptercontrol.c
	flight/Modules/Actuator/actuator.c
	flight/Modules/GPS/GPS.c
	flight/Modules/ManualControl/manualcontrol.c
	flight/Modules/Stabilization/stabilization.c
	flight/Modules/System/systemmod.c
	shared/uavobjectdefinition/manualcontrolsettings.xml
	shared/uavobjectdefinition/stabilizationdesired.xml
2011-07-30 10:06:10 +09:00
Mathieu Rondonneau
612a439199 OP-423: simplify the MODULE_INITCALL macro and remove the ordering loops 2011-07-12 20:44:32 -07:00
Mathieu Rondonneau
9b9b5a1367 OP-423: remove ';' at the end of macro 2011-07-05 19:44:54 -07:00
Mathieu Rondonneau
6683ce8570 OP-423: Make it more obvious that MODULE_TASKCREATE_ALL and MODULE_INITIALIZE_ALL are macro (for now):
- remove the ;
  - also encapsulate the macro by {} in his own scope.
2011-06-25 11:40:01 -07:00
Mathieu Rondonneau
de55c56427 OP-423: Change capital on macro to be uppercase for consistency. 2011-06-24 22:03:03 -07:00
Mathieu Rondonneau
fc1e3f574c OP-423: Split task create and module init in order to postpone task creation once the full heap is available.
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.
2011-06-19 22:35:40 -07:00
Mathieu Rondonneau
5e3e7cc4e3 OP-423 Fix issue with init not properly started in the right order endup up object thinking other where not init. 2011-06-18 17:28:37 -07:00
James Cotton
5044ea36de Start initializing objects in the modules that consume them. Shouldn't affect
OP yet but not tested.
2011-06-18 14:20:51 -05:00
Mathieu Rondonneau
65cf467ca4 OP-423: move the module initialize funtion into a specific section for OP and CC.
- 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)
2011-06-16 22:13:19 -07:00
Mathieu Rondonneau
7598e898fa OP-423 Step-1: split system stack and implement water mark for IRQstack:
- 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.
2011-06-12 20:23:00 -07:00