Developer Guide - Revision history

Ewoud: /* Coding Standards */

2017-11-28T14:42:39Z

Coding Standards

← Older revision		Revision as of 08:42, 28 November 2017
Line 84:		Line 84:
	Info on the [[Builds\|Continuous Integration builds]] (CI) server		Info on the [[Builds\|Continuous Integration builds]] (CI) server

	==[[Coding Standards]]==		==Coding Standards==
	JPL (Jet Propulsion Laboratory) released their own coding standards (can be downloaded for free here: [http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf JPL C Coding Standards and Guidelines]). They include MISRA-C rules and directives, but add their own rules on top of that. They also specify different levels of compliance (LOC) because not always it is necessary to comply with all of the rules. Anyway, they are making things that go to space, so we can definitely learn something about good coding practices from them.		JPL (Jet Propulsion Laboratory) released their own coding standards (can be downloaded for free here: [http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf JPL C Coding Standards and Guidelines]). They include MISRA-C rules and directives, but add their own rules on top of that. They also specify different levels of compliance (LOC) because not always it is necessary to comply with all of the rules. Anyway, they are making things that go to space, so we can definitely learn something about good coding practices from them.

Flixr at 13:30, 12 November 2017

2017-11-12T13:30:00Z

← Older revision		Revision as of 07:30, 12 November 2017
Line 87:		Line 87:
	JPL (Jet Propulsion Laboratory) released their own coding standards (can be downloaded for free here: [http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf JPL C Coding Standards and Guidelines]). They include MISRA-C rules and directives, but add their own rules on top of that. They also specify different levels of compliance (LOC) because not always it is necessary to comply with all of the rules. Anyway, they are making things that go to space, so we can definitely learn something about good coding practices from them.		JPL (Jet Propulsion Laboratory) released their own coding standards (can be downloaded for free here: [http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf JPL C Coding Standards and Guidelines]). They include MISRA-C rules and directives, but add their own rules on top of that. They also specify different levels of compliance (LOC) because not always it is necessary to comply with all of the rules. Anyway, they are making things that go to space, so we can definitely learn something about good coding practices from them.

			==[[DevGuide/Releasing]]==
			Info for maintainers on how to create a new release.

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

Podhrmic: removed copyrighted MISRA content

2016-08-11T17:07:19Z

removed copyrighted MISRA content

Show changes

IHaveADrone: /* MISRA-C Rules */ removed random spaces inside of words

2016-07-15T19:20:30Z

MISRA-C Rules: removed random spaces inside of words

← Older revision		Revision as of 13:20, 15 July 2016
Line 101:		Line 101:
	* The name, and documentation, of the encapsulating macro or function makes the intent of the assembly language clear;		* The name, and documentation, of the encapsulating macro or function makes the intent of the assembly language clear;
	* All uses of assembly language for a given purpose can share the same encapsulation which improves maintainability;		* All uses of assembly language for a given purpose can share the same encapsulation which improves maintainability;
	* The assembly language can easily be substituted for a ~~diff erent~~ target or for purposes of static analysis.		* The assembly language can easily be substituted for a different target or for purposes of static analysis.
	Note: the use of in-line assembly language is an extension to standard C, and therefore violates Rule 1.2.		Note: the use of in-line assembly language is an extension to standard C, and therefore violates Rule 1.2.

Line 147:		Line 147:

	==== Rationale ====		==== Rationale ====
	If a comment starting ~~sequen ce~~, /* or //, occurs within a /* comment, is it quite likely to be caused by a missing */ comment ending sequence.		If a comment starting sequence, /* or //, occurs within a /* comment, is it quite likely to be caused by a missing */ comment ending sequence.
	If a comment starting sequence occurs within a // comment, it is probably because a region of code has been commented-out using //.		If a comment starting sequence occurs within a // comment, it is probably because a region of code has been commented-out using //.

Line 154:		Line 154:

	==== Example ====		==== Example ====
	Consider the following code ~~fr agment~~:		Consider the following code fragment:

	<source lang="c">		<source lang="c">
Line 181:		Line 181:

	==== Amplification ====		==== Amplification ====
	Line-splicing occurs when the \ character is immediately followed by a new-line character. If the source ~~fi le~~ contains multibyte characters, they are converted to the source character set before any splicing occurs.		Line-splicing occurs when the \ character is immediately followed by a new-line character. If the source file contains multibyte characters, they are converted to the source character set before any splicing occurs.

	==== Rationale ====		==== Rationale ====
Line 188:		Line 188:

	==== Example ====		==== Example ====
	In the following non-compliant ~~exampl e~~, the physical line containing the if keyword is logically part of the previous line and is therefore a comment.		In the following non-compliant example, the physical line containing the if keyword is logically part of the previous line and is therefore a comment.

	<source lang="c">		<source lang="c">
Line 242:		Line 242:
	==== Rationale ====		==== Rationale ====
	If two identifiers differ only in non-significant characters, the behaviour is undefined.		If two identifiers differ only in non-significant characters, the behaviour is undefined.
	If portability is a concern, it would be prudent to apply this rule using the minimum limits ~~specifi ed~~ in The Standard.		If portability is a concern, it would be prudent to apply this rule using the minimum limits specified in The Standard.
	Long identifiers may impair the readability of code. While many automatic code generation systems produce long identifiers, there is a good argument for keeping identifier lengths well below this limit.		Long identifiers may impair the readability of code. While many automatic code generation systems produce long identifiers, there is a good argument for keeping identifier lengths well below this limit.
	Note: In C99, if an extended source character appears in an external identifier and that character does not have a corresponding universal character, The Standard does not specify how many characters it occupies.		Note: In C99, if an extended source character appears in an external identifier and that character does not have a corresponding universal character, The Standard does not specify how many characters it occupies.
Line 286:		Line 286:

	==== Example ====		==== Example ====
	In the following example, the implementation in question supports 31 significant case-sensitive characters ~~inidentifi ers~~ that do not have external linkage.		In the following example, the implementation in question supports 31 significant case-sensitive characters inidentifiers that do not have external linkage.
	The identifier engine_exhaust_gas_temperature_local is compliant with this rule. Although it is not distinct from the identifier engine_exhaust_gas_temperature_raw, it is in a different scope. However, it is not compliant with Rule 5.3.		The identifier engine_exhaust_gas_temperature_local is compliant with this rule. Although it is not distinct from the identifier engine_exhaust_gas_temperature_raw, it is in a different scope. However, it is not compliant with Rule 5.3.

Line 320:		Line 320:
	If an identifier is declared in an inner scope but is not distinct from an identifier that already exists in an outer scope, then the inner-most declaration will “hide” the outer one. This may lead to developer confusion.		If an identifier is declared in an inner scope but is not distinct from an identifier that already exists in an outer scope, then the inner-most declaration will “hide” the outer one. This may lead to developer confusion.
	Note: An identifier declared in one name space does not hide an identifier declared in a different name space.		Note: An identifier declared in one name space does not hide an identifier declared in a different name space.
	The terms outer and inner scope are ~~defi ned~~ as follows:		The terms outer and inner scope are defined as follows:
	* Identifiers that have file scope can be considered as having the outermost scope;		* Identifiers that have file scope can be considered as having the outermost scope;
	* Identifiers that have block scope have a more inner scope;		* Identifiers that have block scope have a more inner scope;

Podhrmic: Some of MISRAC directives

2016-07-13T17:30:50Z

Some of MISRAC directives

Show changes

IHaveADrone: typo

2016-01-07T14:54:06Z

typo

← Older revision		Revision as of 08:54, 7 January 2016
Line 10:		Line 10:

	==[[DevGuide/CodeEditors\|Code Editing]]==		==[[DevGuide/CodeEditors\|Code Editing]]==
	How to setup your IDE for use with the ~~sourecode~~		How to setup your IDE for use with the source code

	==[[DevGuide/LearningToProgram\|Learning to Program]]==		==[[DevGuide/LearningToProgram\|Learning to Program]]==

AutumnLeaves: /* ControlTheory */

2016-01-06T23:45:09Z

ControlTheory

← Older revision		Revision as of 17:45, 6 January 2016
Line 67:		Line 67:

	==[[ControlTheory]]==		==[[ControlTheory]]==
	All [[ControlTheory\|information you are looking for about the harsh reality of ~~the~~ Control Theory]] needed to let your aircraft fly		All [[ControlTheory\|information you are looking for about the harsh reality of Control Theory]] needed to let your aircraft fly


	==[[Demystified/Altitude and Height\|Altitude and Height]]==		==[[Demystified/Altitude and Height\|Altitude and Height]]==

AutumnLeaves: /* USB-Serial */

2016-01-06T23:43:48Z

USB-Serial

← Older revision		Revision as of 17:43, 6 January 2016
Line 64:		Line 64:

	==[[DevGuide/USB-Serial\|USB-Serial]]==		==[[DevGuide/USB-Serial\|USB-Serial]]==
	Using an USB connection instead of ~~and~~ UART for use with telemetry		Using a USB connection instead of UART for use with telemetry

	==[[ControlTheory]]==		==[[ControlTheory]]==

AutumnLeaves: /* GDB OpenOCD Debug */

2016-01-06T23:43:09Z

GDB OpenOCD Debug

← Older revision		Revision as of 17:43, 6 January 2016
Line 61:		Line 61:

	==[[DevGuide/GDB_OpenOCD_Debug\|GDB OpenOCD Debug]]==		==[[DevGuide/GDB_OpenOCD_Debug\|GDB OpenOCD Debug]]==
	Using GDB or ~~OpenOcD~~ to directly flash and debug Hardware.		Using GDB or OpenOCD to directly flash and debug Hardware

	==[[DevGuide/USB-Serial\|USB-Serial]]==		==[[DevGuide/USB-Serial\|USB-Serial]]==

AutumnLeaves: /* Reference/bootloader */

2016-01-06T23:42:11Z

Reference/bootloader

← Older revision		Revision as of 17:42, 6 January 2016
Line 49:		Line 49:

	====[[Lpc21BootloaderUpload\|Upload Bootloader for LPC21xx]]====		====[[Lpc21BootloaderUpload\|Upload Bootloader for LPC21xx]]====
	How to [[[[Lpc21BootloaderUpload\|upload the Bootloader]] to a LPC2148 processor based AP board like the TWOG		How to [[[[Lpc21BootloaderUpload\|upload the Bootloader]] to a LPC2148 processor based Autopilot board like the TWOG

	===[[Luftboot\|Upload the luftboot bootloader]]===		===[[Luftboot\|Upload the luftboot bootloader]]===

← Older revision		Revision as of 17:42, 6 January 2016
Line 49:		Line 49:

	====[[Lpc21BootloaderUpload\|Upload Bootloader for LPC21xx]]====		====[[Lpc21BootloaderUpload\|Upload Bootloader for LPC21xx]]====
	How to [[[[Lpc21BootloaderUpload\|upload the Bootloader]] to a LPC2148 processor based AP board like the TWOG		How to [[[[Lpc21BootloaderUpload\|upload the Bootloader]] to a LPC2148 processor based Autopilot board like the TWOG

	===[[Luftboot\|Upload the luftboot bootloader]]===		===[[Luftboot\|Upload the luftboot bootloader]]===