FirmwareArchitecture - Revision history

Kirkscheper: Added links to the relevant code directories

2017-11-28T12:56:28Z

Added links to the relevant code directories

← Older revision		Revision as of 06:56, 28 November 2017
Line 1:		Line 1:
			Some background information on the Firmware, Subsystems and Modules can be found on the [[Airframe Configuration]] page.

			== Firmware ==
			Paparazzi is currently split into various firmware types where Fixedwing and Rotorcraft are the main autopilot firmware versions. These firmwares implement some vehicle type specific code using predefined Makefiles defined in [https://github.com/paparazzi/paparazzi/tree/master/conf/firmwares conf/firmwares] subfolder.

	== Low Level drivers ==		== Low Level drivers ==
	low level code organization is roughly:		low level code organization is roughly:
	* ~~'''~~sw/airborne/mcu_periph~~'''~~ : interfaces/drivers for MCU peripherals like I2C, SPI, ADC, etc... (the HAL)		* [https://github.com/paparazzi/paparazzi/tree/master/sw/airborne/mcu_periph sw/airborne/mcu_periph] : interfaces/drivers for MCU peripherals like I2C, SPI, ADC, etc... (the HAL)
	* ~~'''~~sw/airborne/peripherals~~'''~~ : drivers for external peripherals, like sensor chips, etc...		* [https://github.com/paparazzi/paparazzi/tree/master/sw/airborne/peripherals sw/airborne/peripherals] : drivers for external peripherals, like sensor chips, etc...
	* ~~'''~~sw/airborne/arch~~'''~~ : everything that is architecture specific (''lpc21'', ''stm32'', ''linux'', ..)		* [https://github.com/paparazzi/paparazzi/tree/master/sw/airborne/arch sw/airborne/arch] : everything that is architecture specific (''lpc21'', ''stm32'', ''linux'', ..)
	* ~~'''~~sw/airborne/boards~~'''~~ : board definitions, pinout, etc... (no need to touch this unless you want to support a new board)		* [https://github.com/paparazzi/paparazzi/tree/master/sw/airborne/boards sw/airborne/boards] : board definitions, pinout, etc... (no need to touch this unless you want to support a new board)

			== Modules ==
			[[Modules]] use code generation in order to allow people to use them by only editing the vehicle's xml configuration as opposed to changing/adding to the code of the autopilot. This makes the paparazzi build process highly configurable. Typically, function calls are generated for initialization and in the main loop for timers (periodic in paparazzi slang) and events. The event and periodic functions of the Modules get called at the end of event_task_ap and periodic_task_ap respectively.

			Modules are used to configure all parts of paparazzi other than the firmware described above. The build configuration for each module is described using xml description language and the located in the [https://github.com/paparazzi/paparazzi/tree/master/conf/modules conf/modules] subfolder. These modules implement not only the user implemented mission specific code but also the low level drivers and subsystems.

			[https://github.com/paparazzi/paparazzi/tree/master/sw/airborne/modules sw/airborne/modules] contains the mission specific software such as image processing, video recording or relay or guidance commands.

			=== Creating a new Module ===
			*See [[Modules]] for more information


	== Subsystems ==		== Subsystems ==
	[~~[Subsystems~~]~~] are just a convention used to provide several implementations~~ of ~~a peripheral (like microcontroller peripherals, an external imu board...), protocol (gps~~, ~~communications...) or algorithm (control~~, ~~estimation...). Function calls are written "by hand"~~ and ~~the build system takes care to compile the particular implementation~~.		[https://github.com/paparazzi/paparazzi/tree/master/sw/airborne/subsystems /sw/airborne/subsystems] contains the code base for some of the more critical mission independent software such as AHRS, IMU, INS and GPS.

	They are selected and configured with a <source lang="xml" enclose="none"><subsystem name="foo" type="bar"></source> in the [[Airframe_Configuration#Firmware_and_Hardware_definitions\|firmware section of the airframe file]]. All this does is basically include a makefile <tt>foo_bar.makefile</tt> that adds the respective sources and adds a few configuration options. (See <tt>conf/autopilot/subsystems/...</tt>)
	This makes it easier to put an airframe file together (they replace the old raw makefile section) and also allows us to change the code and move/rename files behind the scenes without breaking everyones airframe files.
	{\| class="wikitable"		{\| class="wikitable"
	\|-		\|-
	\| Since '''v5.8''' it is possible to safely replace ''subsystem'' by ''module'' in your airframe file. The ~~roadmap~~ of ~~Paparazzi is to convert existing~~ subsystems ~~to [[modules]]~~.		\| Since '''v5.8''' it is possible to safely replace ''subsystem'' by ''module'' in your airframe file. The following describes the original description of the legacy subsystems.
	\|}		\|}

			They are selected and configured with a <source lang="xml" enclose="none"><subsystems name="foo" type="bar"></source> in the [[Airframe_Configuration#Firmware_and_Hardware_definitions\|firmware section of the airframe file]]. All this does is basically include a makefile <tt>foo_bar.makefile</tt> that adds the respective sources and adds a few configuration options. (See <tt>conf/autopilot/subsystems/...</tt>)
			This makes it easier to put an airframe file together (they replace the old raw makefile section) and also allows us to change the code and move/rename files behind the scenes without breaking everyones airframe files.

	=== Creating a new Subsystem ===		=== Creating a new Subsystem ===
	A new subsystem is required when adding support for new or alternate core functionalities, as listed above. Some new subsystems will rely on underlying peripheral or MCU peripheral drivers (for example a new IMU subsystem), others do not need this (for example a new set of control loops). An MCU peripheral uses on-chip hardware peripherals in the main microcontroller (such as the SPI hardware), while normal peripherals are external hardware such as an analog to digital converter integrated circuit (such as the MAX1168).		A new subsystem is required when adding support for new or alternate core functionalities, as listed above. Some new subsystems will rely on underlying peripheral or MCU peripheral drivers (for example a new IMU subsystem), others do not need this (for example a new set of control loops). An MCU peripheral uses on-chip hardware peripherals in the main microcontroller (such as the SPI hardware), while normal peripherals are external hardware such as an analog to digital converter integrated circuit (such as the MAX1168).
Line 31:		Line 49:
	Finally, master is always being updated and changed, so if you aren't quite sure about something, don't hesitate to ask on the mailing list. In addition, there may be style differences between newer, updated subsystems and older subsystems.		Finally, master is always being updated and changed, so if you aren't quite sure about something, don't hesitate to ask on the mailing list. In addition, there may be style differences between newer, updated subsystems and older subsystems.

	== ~~Modules ==~~		=== Discussion ===
	[[Modules]] use code generation in order to allow people to use them by only editing the vehicle's xml configuration as opposed to changing/adding to the code of the autopilot. Typically, function calls are generated for initialisation and in the mainloop for timers (periodic in paparazzi slang) and events. The event and periodic functions of the Modules get called at the end of event_task_ap and periodic_task_ap respectively.

	~~=== Creating a new Module~~ ===
	*See [[Modules]] for more information

	~~== Discussion~~ ==
	So the difference is that with subsystems you explicitly call the functions (e.g. control loops) from the main ap loop, whereas the event/periodic functions of the Modules get called at the end of the main event/periodic tasks. So Modules are perfect to add stuff like extra payload and sensors, but Subsystems give you tighter control over when and in what order to call functions (e.g. for estimation/control).		So the difference is that with subsystems you explicitly call the functions (e.g. control loops) from the main ap loop, whereas the event/periodic functions of the Modules get called at the end of the main event/periodic tasks. So Modules are perfect to add stuff like extra payload and sensors, but Subsystems give you tighter control over when and in what order to call functions (e.g. for estimation/control).

Flixr at 16:43, 11 March 2016

2016-03-11T16:43:24Z

← Older revision		Revision as of 10:43, 11 March 2016
Line 1:		Line 1:
	== Low Level drivers ==		== Low Level drivers ==
	low level code organization is roughly:		low level code organization is roughly:
	* '''sw/airborne/mcu_periph''' : interfaces/drivers for MCU peripherals like I2C, SPI, ADC, etc...		* '''sw/airborne/mcu_periph''' : interfaces/drivers for MCU peripherals like I2C, SPI, ADC, etc... (the HAL)
	* '''sw/airborne/peripherals''' : drivers for external peripherals, like sensor chips, etc..		* '''sw/airborne/peripherals''' : drivers for external peripherals, like sensor chips, etc...
	* '''sw/airborne/arch''' : ~~parts of the implementations~~ that ~~differ according to the MCU~~ architecture (~~e.g.~~ ''lpc21'', ''stm32'')		* '''sw/airborne/arch''' : everything that is architecture specific (''lpc21'', ''stm32'', ''linux'', ..)
	* '''sw/airborne/boards''' : board definitions, pinout, etc... (no need to touch this unless you want to support a new board)		* '''sw/airborne/boards''' : board definitions, pinout, etc... (no need to touch this unless you want to support a new board)

Ghattenb: /* Subsystems */

2016-02-16T17:27:44Z

Subsystems

← Older revision		Revision as of 11:27, 16 February 2016
Line 11:		Line 11:
	They are selected and configured with a <source lang="xml" enclose="none"><subsystem name="foo" type="bar"></source> in the [[Airframe_Configuration#Firmware_and_Hardware_definitions\|firmware section of the airframe file]]. All this does is basically include a makefile <tt>foo_bar.makefile</tt> that adds the respective sources and adds a few configuration options. (See <tt>conf/autopilot/subsystems/...</tt>)		They are selected and configured with a <source lang="xml" enclose="none"><subsystem name="foo" type="bar"></source> in the [[Airframe_Configuration#Firmware_and_Hardware_definitions\|firmware section of the airframe file]]. All this does is basically include a makefile <tt>foo_bar.makefile</tt> that adds the respective sources and adds a few configuration options. (See <tt>conf/autopilot/subsystems/...</tt>)
	This makes it easier to put an airframe file together (they replace the old raw makefile section) and also allows us to change the code and move/rename files behind the scenes without breaking everyones airframe files.		This makes it easier to put an airframe file together (they replace the old raw makefile section) and also allows us to change the code and move/rename files behind the scenes without breaking everyones airframe files.
			{\| class="wikitable"
			\|-
			\| Since '''v5.8''' it is possible to safely replace ''subsystem'' by ''module'' in your airframe file. The roadmap of Paparazzi is to convert existing subsystems to [[modules]].
			\|}
	=== Creating a new Subsystem ===		=== Creating a new Subsystem ===
	A new subsystem is required when adding support for new or alternate core functionalities, as listed above. Some new subsystems will rely on underlying peripheral or MCU peripheral drivers (for example a new IMU subsystem), others do not need this (for example a new set of control loops). An MCU peripheral uses on-chip hardware peripherals in the main microcontroller (such as the SPI hardware), while normal peripherals are external hardware such as an analog to digital converter integrated circuit (such as the MAX1168).		A new subsystem is required when adding support for new or alternate core functionalities, as listed above. Some new subsystems will rely on underlying peripheral or MCU peripheral drivers (for example a new IMU subsystem), others do not need this (for example a new set of control loops). An MCU peripheral uses on-chip hardware peripherals in the main microcontroller (such as the SPI hardware), while normal peripherals are external hardware such as an analog to digital converter integrated circuit (such as the MAX1168).

Flixr: add some basic low level code layout stuff

2014-04-07T16:22:49Z

add some basic low level code layout stuff

← Older revision		Revision as of 10:22, 7 April 2014
Line 1:		Line 1:
			== Low Level drivers ==
			low level code organization is roughly:
			* '''sw/airborne/mcu_periph''' : interfaces/drivers for MCU peripherals like I2C, SPI, ADC, etc...
			* '''sw/airborne/peripherals''' : drivers for external peripherals, like sensor chips, etc..
			* '''sw/airborne/arch''' : parts of the implementations that differ according to the MCU architecture (e.g. ''lpc21'', ''stm32'')
			* '''sw/airborne/boards''' : board definitions, pinout, etc... (no need to touch this unless you want to support a new board)

	== Subsystems ==		== Subsystems ==
	[[Subsystems]] are just a convention used to provide several implementations of a peripheral (like microcontroller peripherals, an external imu board...), protocol (gps, communications...) or algorithm (control, estimation...). Function calls are written "by hand" and the build system takes care to compile the particular implementation.		[[Subsystems]] are just a convention used to provide several implementations of a peripheral (like microcontroller peripherals, an external imu board...), protocol (gps, communications...) or algorithm (control, estimation...). Function calls are written "by hand" and the build system takes care to compile the particular implementation.

Flixr: /* Creating a new Subsystem */

2013-07-10T08:54:48Z

Creating a new Subsystem

← Older revision		Revision as of 02:54, 10 July 2013
Line 6:		Line 6:

	=== Creating a new Subsystem ===		=== Creating a new Subsystem ===
	A new subsystem is required when adding support for new or alternate core functionalities, as listed above. Some new subsystems will ~~relay~~ on underlying peripheral or MCU peripheral drivers (for example a new IMU subsystem), others do not need this (for example a new set of control loops). An MCU peripheral uses on-chip hardware peripherals in the main microcontroller (such as the SPI hardware), while normal peripherals are external hardware such as an analog to digital converter integrated circuit (such as the MAX1168).		A new subsystem is required when adding support for new or alternate core functionalities, as listed above. Some new subsystems will rely on underlying peripheral or MCU peripheral drivers (for example a new IMU subsystem), others do not need this (for example a new set of control loops). An MCU peripheral uses on-chip hardware peripherals in the main microcontroller (such as the SPI hardware), while normal peripherals are external hardware such as an analog to digital converter integrated circuit (such as the MAX1168).

	The general strategy for adding a new subsystem should be something along the lines of:		The general strategy for adding a new subsystem should be something along the lines of:

Scdwyer: /* Creating a new Module */

2013-02-21T23:41:28Z

Creating a new Module

← Older revision		Revision as of 17:41, 21 February 2013
Line 25:		Line 25:

	=== Creating a new Module ===		=== Creating a new Module ===
	*~~TODO~~		*See [[Modules]] for more information

	== Discussion ==		== Discussion ==

Scdwyer: added info about creating a new subsystem

2013-02-21T23:37:41Z

added info about creating a new subsystem

@@ Line 4: / Line 4: @@
 They are selected and configured with a <source lang="xml" enclose="none"><subsystem name="foo" type="bar"></source> in the [[Airframe_Configuration#Firmware_and_Hardware_definitions|firmware section of the airframe file]]. All this does is basically include a makefile <tt>foo_bar.makefile</tt> that adds the respective sources and adds a few configuration options. (See <tt>conf/autopilot/subsystems/...</tt>)
 This makes it easier to put an airframe file together (they replace the old raw makefile section) and also allows us to change the code and move/rename files behind the scenes without breaking everyones airframe files.
 == Modules ==
 [[Modules]] use code generation in order to allow people to use them by only editing the vehicle's xml configuration as opposed to changing/adding to  the code of the autopilot. Typically, function calls are generated for initialisation and in the mainloop for timers (periodic in paparazzi slang) and events. The event and periodic functions of the Modules get called at the end of event_task_ap and periodic_task_ap respectively.
 == Discussion ==

Flixr: a bit more about module/subsystem differenences and subsystem makefiles

2012-04-21T12:31:04Z

a bit more about module/subsystem differenences and subsystem makefiles

← Older revision		Revision as of 06:31, 21 April 2012
Line 1:		Line 1:
	== ~~Modules~~ ==		== Subsystems ==
	~~Modules use code generation in order to allow people to use them by only editing the vehicle's xml configuration as opposed to changing/adding~~ to ~~the code~~ of ~~the autopilot~~. ~~Typically~~, ~~function~~ calls are ~~generated for initialisation~~ and in the ~~mainloop for timers (periodic in paparazzi slang) and events~~.		[[Subsystems]] are just a convention used to provide several implementations of a peripheral (like microcontroller peripherals, an external imu board...), protocol (gps, communications...) or algorithm (control, estimation...). Function calls are written "by hand" and the build system takes care to compile the particular implementation.

	[[~~Modules~~ \| ~~modules page~~]]		They are selected and configured with a <source lang="xml" enclose="none"><subsystem name="foo" type="bar"></source> in the [[Airframe_Configuration#Firmware_and_Hardware_definitions\|firmware section of the airframe file]]. All this does is basically include a makefile <tt>foo_bar.makefile</tt> that adds the respective sources and adds a few configuration options. (See <tt>conf/autopilot/subsystems/...</tt>)
			This makes it easier to put an airframe file together (they replace the old raw makefile section) and also allows us to change the code and move/rename files behind the scenes without breaking everyones airframe files.

	== ~~Subsystems~~ ==		== Modules ==
	~~Subsystems are just a convention used~~ to ~~provide several implementations~~ of ~~a peripheral (like microcontroller peripherals, an external imu board..~~.), ~~protocol~~ (~~gps, communications...~~) ~~or algorithm (control, estimation~~.~~..). Function calls are written "by hand"~~ and the ~~build system takes care to compile~~ the ~~particular implementation~~.		[[Modules]] use code generation in order to allow people to use them by only editing the vehicle's xml configuration as opposed to changing/adding to the code of the autopilot. Typically, function calls are generated for initialisation and in the mainloop for timers (periodic in paparazzi slang) and events. The event and periodic functions of the Modules get called at the end of event_task_ap and periodic_task_ap respectively.

	~~[[Subsystems]]~~

	== Discussion ==		== Discussion ==
	Modules ~~naturally provide~~ the ~~"several implementations" feature~~ of the ~~Subsystems~~. So, ~~ideally we could have a "generic" main.c consisting only~~ in ~~calls~~ to ~~the generated~~ functions.		So the difference is that with subsystems you explicitly call the functions (e.g. control loops) from the main ap loop, whereas the event/periodic functions of the Modules get called at the end of the main event/periodic tasks. So Modules are perfect to add stuff like extra payload and sensors, but Subsystems give you tighter control over when and in what order to call functions (e.g. for estimation/control).
	~~This has the advantage of providing flexibility~~ for ~~specifying timing parameters from the xml, like for example the frequency of~~ control ~~or estimation algorithm~~.

			Modules naturally provide the "several implementations" feature of the Subsystems. So, we could have a "generic" main.c consisting only in calls to the generated functions.
			Nevertheless, care should be taken that switching to a "module only" configuration doesn't become detrimental to the readability and debugability of the code.

	~~Nevertheless~~, ~~care should be taken that switching to~~ a "module ~~only" configuration doesn't become detrimental to the readability and debugability of the code~~.		You can also wrap some subsystem code as a modules (e.g. infrared), or the other way round (e.g. imu_ppzuav). As you can see with the imu_ppzuav module it also still expects a direct ImuEvent call from main_ap, so you could say it's not a "pure" module.

	[[Category:Software]] [[Category:Developer_Documentation]]		[[Category:Software]] [[Category:Developer_Documentation]]

Flixr: /* Discussion */

2011-11-22T10:55:06Z

Discussion

← Older revision		Revision as of 04:55, 22 November 2011
Line 15:		Line 15:

	Nevertheless, care should be taken that switching to a "module only" configuration doesn't become detrimental to the readability and debugability of the code.		Nevertheless, care should be taken that switching to a "module only" configuration doesn't become detrimental to the readability and debugability of the code.


	~~Fixedwing and Rotorcraft use different gps code and we'll have to decide when we merge if we make it a module or a subsystem.~~

	[[Category:Software]] [[Category:Developer_Documentation]]		[[Category:Software]] [[Category:Developer_Documentation]]

Flixr: /* Subsystems */

2011-11-07T12:19:43Z

Subsystems

← Older revision		Revision as of 06:19, 7 November 2011
Line 5:		Line 5:

	== Subsystems ==		== Subsystems ==
	Subsystems are just a convention used to provide several implementations of a peripheral (like microcontroller peripherals, an external imu board...), protocol (gps, communications...) or algorithm (control, estimation...). Function calls are written "by hand" and the build system takes care to compile the particular implementation.		Subsystems are just a convention used to provide several implementations of a peripheral (like microcontroller peripherals, an external imu board...), protocol (gps, communications...) or algorithm (control, estimation...). Function calls are written "by hand" and the build system takes care to compile the particular implementation.

			[[Subsystems]]

	== Discussion ==		== Discussion ==