Merge branch 'master' into dev

.gitignore

@@ -1,5 +1,5 @@
 # ignore html dir for github pages
-/html
+/doc/html
 
 *.so
 *.[oa]
@@ -20,6 +20,13 @@
 
 *.aux
 
+# Eclipse IDE project files
+*.cproject
+*.project
+*.externalToolBuilders
+/build.properties
+/META-INF
+
 # Debian related files
 *.deb
 *.dsc

Doxyfile

@@ -25,19 +25,19 @@ DOXYFILE_ENCODING      = UTF-8
 # The PROJECT_NAME tag is a single word (or a sequence of words surrounded
 # by quotes) that should identify the project.
 
-PROJECT_NAME           = "Paparazzi UAV"
+PROJECT_NAME           = "Paparazzi UAS"
 
 # The PROJECT_NUMBER tag can be used to enter a project or revision number.
 # This could be handy for archiving the generated documentation or
 # if some version control system is used.
 
-PROJECT_NUMBER         = 3.5
+PROJECT_NUMBER         =
 
 # Using the PROJECT_BRIEF tag one can provide an optional one line description
 # for a project that appears at the top of each page and should give viewer
 # a quick idea about the purpose of the project. Keep the description short.
 
-PROJECT_BRIEF          = "Paparazzi is a free software Unmanned (Air) Vehicle System."
+PROJECT_BRIEF          = "Paparazzi is a free software Unmanned Aircraft System."
 
 # With the PROJECT_LOGO tag one can specify an logo or icon that is
 # included in the documentation. The maximum height of the logo should not
@@ -51,7 +51,7 @@ PROJECT_LOGO           = data/pictures/penguin_icon.png
 # If a relative path is entered, it will be relative to the location
 # where doxygen was started. If left blank the current directory will be used.
 
-OUTPUT_DIRECTORY       = html
+OUTPUT_DIRECTORY       = doc/html
 
 # If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
 # 4096 sub-directories (in 2 levels) under the output directory of each output
@@ -609,7 +609,7 @@ WARN_LOGFILE           =
 # directories like "/usr/src/myproject". Separate the files or directories
 # with spaces.
 
-INPUT                  = doc/mainpage.dox sw/airborne
+INPUT                  = doc/manual sw/airborne
 
 # This tag can be used to specify the character encoding of the source files
 # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is

conf/autopilot/subsystems/fixedwing/imu_analog.makefile

@@ -86,6 +86,10 @@ endif
 imu_srcs += $(SRC_SUBSYSTEMS)/imu.c
 imu_srcs += $(SRC_SUBSYSTEMS)/imu/imu_analog.c
 
+else ifeq ($(ARCH), stm32)
+
+$(error Not implemented for the stm32 yet... should be trivial, just do it...)
+
 endif
 
 # Keep CFLAGS/Srcs for imu in separate expression so we can assign it to other targets

doc/mainpage.dox

@@ -1,13 +0,0 @@
-/**
-\mainpage
-
-\section intro Introduction
-
-\subsection whatis What is Paparazzi
-
-Paparazzi is an attempt to develop a free software Unmanned (Air) Vehicle System.
- As of today the system is being used successfuly by a number of hobyists, universities and companies all over the world, on vehicle of various size ( 100g to 25Kg ) and of various nature ( fixed wing, rotorcrafts, boats and surface vehicles).
-
-
-
-*/

doc/manual/mainpage.dox

@@ -0,0 +1,29 @@
+/** @mainpage Paparazzi Developer's Guide
+
+Welcome to the Paparazzi Developer's Guide -- the developer's resource for
+learning about the internal architecture of the Paparazzi project. @par
+
+Developers that want to contribute to Paparazzi should read the following
+sections before starting work:
+
+- The @subpage styleguide provides rules that developers should
+  follow when writing new code for Paparazzi.
+
+@ref primer provide introductory materials for new developers on various
+specific topics.
+
+
+ */
+
+/** @page primer Paparazzi Technical Primers
+
+This pages lists Technical Primers available for Paparazzi Developers.
+They seek to provide information to pull novices up the learning curves
+associated with the fundamental technologies used by Paparazzi.
+
+- TODO
+
+
+Contributions or suggestions for new Technical Primers are welcome.
+
+ */

doc/manual/style.dox

@@ -0,0 +1,225 @@
+/** @page styleguide Style Guides
+
+The goals for each of these guides are:
+- to produce correct code that appears clean, consistent, and readable,
+- to allow developers to create patches that conform to a standard, and
+- to eliminate these issues as points of future contention.
+
+Some of these rules may be ignored in the spirit of these stated goals;
+however, such exceptions should be fairly rare.
+
+The following style guides describe a formatting, naming, and other
+conventions that should be followed when writing or changing the Papaprazzi
+code or documentation:
+
+- @subpage stylec
+- @subpage styledoxygen
+
+
+Feedback would be welcome to improve the Paparazzi guidelines.
+ */
+
+/** @page stylec C Style Guide
+
+This page contains guidelines for writing new C source code for the
+OpenOCD project.
+
+@section styleformat Formatting Guide
+
+- remove any trailing white space at the end of lines.
+- use 2 spaces for indentation; do NOT use tabs.
+- use Unix line endings ('\\n'); do NOT use DOS endings ('\\r\\n')
+- limit adjacent empty lines to at most two (2).
+- remove any trailing empty lines at the end of source files
+- do not "comment out" code from the tree; instead, one should either:
+  -# remove it entirely (git can retrieve the old version), or
+  -# use an @c \#if/\#endif block.
+
+@section stylenames Naming Rules
+
+- most identifiers must use lower-case letters (and digits) only.
+  - macros should use upper-case letters (and digits) only.
+
+@section styletypes Type Guidelines
+- use the types from \<inttypes.h\>:
+  - @c int8_t, @c int16_t, @c int32_t, or @c int64_t: signed types of specified size
+  - @c uint8_t, @c uint16_t, @c uint32_t, or @c uint64_t: unsigned types of specified size
+
+@section stylefunc Functions
+
+- static inline functions should be prefered over macros in most cases:
+@code
+/* do NOT define macro-like functions like this... */
+#define CUBE(x) ((x) * (x) * (x))
+/* instead, define the same expression using a C99 inline function */
+static inline int cube(int x) { return x * x * x; }
+@endcode
+- Functions should be declared static unless required by other modules
+  - define static functions before first usage to avoid forward declarations.
+- Functions should have no space between its name and its parameter list:
+@code
+int32_t f(int32_t x1, int32_t x2)
+{
+  ...
+  int32_t y = f(x1, x2 - x1);
+  ...
+}
+@endcode
+
+@section stylecpp Preprocessor directives
+- For conditional compilation use @c #if instead of @c #ifdef.
+Someone might write code like:
+@code
+#ifdef USE_FOO
+  bar();
+#endif
+@endcode
+Someone else might compile the code with turned-off foo info like:
+@verbatim
+ gcc stuff.c -DUSE_FOO=0
+@endverbatim
+So use @c #if not @c #ifdef to turn a feature on or off. This works fine, and does the right thing, even if USE_FOO is not defined at all (!)
+@code
+#if USE_FOO
+  bar();
+#endif
+@endcode
+- If you really need to test whether a symbol is defined or not, test it with the @c defined construct.
+
+ */
+
+/** @page styledoxygen Doxygen Style Guide
+
+The following sections provide guidelines for OpenOCD developers
+who wish to write Doxygen comments in the code or this manual.
+For an introduction to Doxygen documentation,
+see the @ref primerdoxygen.
+
+@section styledoxyblocks Doxygen Block Selection
+
+Several different types of Doxygen comments can be used; often,
+one style will be the most appropriate for a specific context.
+The following guidelines provide developers with heuristics for
+selecting an appropriate form and writing consistent documentation
+comments.
+
+-# use @c /// to for one-line documentation of instances.
+-# for documentation requiring multiple lines, use a "block" style:
+@verbatim
+/**
+ * First sentence is brief description.  Remaining text becomes
+ * the full description block, where "empty" lines start new paragraphs.
+ *
+ * One can make text appear in @a italics, @b bold, @c monospace, or
+ * in blocks such as the one in which this example appears in the Style
+ * Guide.  See the Doxygen Manual for the full list of commands.
+ *
+ * @param foo For a function, describe the parameters (e.g. @a foo).
+ * @returns The value(s) returned, or possible error conditions.
+ */
+@endverbatim
+  -# The block should start on the line following the opening @c /**.
+  -# The end of the block, \f$*/\f$, should also be on its own line.
+  -# Every line in the block should have a @c '*' in-line with its start:
+    - A leading space is required to align the @c '*' with the @c /** line.
+    - A single "empty" line should separate the function documentation
+      from the block of parameter and return value descriptions.
+    - Except to separate paragraphs of documentation, other extra
+      "empty" lines should be removed from the block.
+  -# Only single spaces should be used; do @b not add mid-line indentation.
+-# If the total line length will be less than 80 columns, then
+  - The <code> /**< description </code> form can be used on the same line for a detailed description.
+  - The <code>///< brief </code> form can be used for brief descriptions.
+  - This style should be used sparingly; the best use is for fields:
+@verbatim
+int field;  /**< detailed field description */
+int field2; ///< a brief description
+@endverbatim
+-# Every documented file should contain a block with @c \@file after the license header:
+@verbatim
+/**
+ * @file foo/bar/file.c
+ * Brief description of file.
+ *
+ * More detailed description of file.
+ */
+@endverbatim
+
+@section styledoxyall Doxygen Style Guide
+
+The following guidelines apply to all Doxygen comment blocks:
+
+-# Use the @c '\@cmd' form for all doxygen commands (do @b not use @c '\\cmd').
+-# It is not necessary to use @c \@brief since @c JAVADOC_AUTOBRIEF is enabled.
+  - The first line (until the first dot) is automatically treated as brief description.
+-# Use symbol names such that Doxygen automatically creates links:
+  -# @c function_name() can be used to reference functions
+    (e.g. ahrs_propagate()).
+  -# @c struct_name::member_name should be used to reference structure
+    fields in the documentation (e.g. @c Ahrs::body_rate).
+  -# URLS get converted to markup automatically, without any extra effort.
+  -# new pages can be linked into the heirarchy by using the @c \@subpage
+    command somewhere the page(s) under which they should be linked:
+  -# use @c \@ref in other contexts to create links to pages and sections.
+-# Use good Doxygen mark-up:
+  -# '\@a' (italics) should be used to reference parameters (e.g. <i>foo</i>).
+  -# '\@b' (bold) should be used to emphasizing <b>single</b> words.
+  -# '\@c' (monospace) should be used with <code>file names</code> and
+  <code>code symbols</code>, so they appear visually distinct from
+  surrounding text.
+  -# To mark-up multiple words, the HTML alternatives must be used.
+-# Two spaces should be used when nesting lists; do @b not use '\\t' in lists.
+-# Code examples provided in documentation must conform to the Style Guide.
+
+@section styledoxytext Doxygen Text Inputs
+
+In addition to the guidelines in the preceding sections, the following
+additional style guidelines should be considered when writing
+documentation as part of standalone text files:
+
+-# Text files must contain Doxygen at least one comment block:
+  -# Documentation should begin in the first column (except for nested lists).
+  -# Do NOT use the @c '*' convention that must be used in the source code.
+-# Each file should contain at least one @c \@page block.
+  -# Each new page should be listed as a \@subpage in the \@page block
+  of the page that should serve as its parent.
+  -# Large pages should be structure in parts using meaningful \@section
+  and \@subsection commands.
+-# Include a @c \@file block at the end of each Doxygen @c .dox file to
+  document its contents:
+  - Doxygen creates such pages for files automatically, but no content
+    will appear on them for those that only contain manual pages.
+  - The \@file block should provide useful meta-documentation to assist
+    techincal writers; typically, a list of the pages that it contains.
+  - For example, the @ref styleguide exists in @c doc/manual/style.dox,
+    which contains a reference back to itself.
+-# The \@file and \@page commands should begin on the same line as
+   the start of the Doxygen comment:
+@verbatim
+/** @page pagename Page Title
+
+Documentation for the page.
+
+ */
+/** @file
+
+This file contains the @ref pagename page.
+
+ */
+@endverbatim
+
+For an example, the Doxygen source for this Style Guide can be found in
+@c doc/manual/style.dox, alongside other parts of The Manual.
+
+ */
+
+/** @file
+
+This file contains the @ref styleguide pages.  The @ref styleguide pages
+include the following Style Guides for their respective code and
+documentation languages:
+
+- @ref stylec
+- @ref styledoxygen
+
+ */

sw/airborne/boards/booz_1.0.h

@@ -91,11 +91,14 @@
 #endif
 
 /* battery */
+/* allow to define ADC_CHANNEL_VSUPPLY in the airframe file*/
+#ifndef ADC_CHANNEL_VSUPPLY
 #define ADC_CHANNEL_VSUPPLY AdcBank0(2)
 #ifndef USE_AD0
 #define USE_AD0
 #endif
 #define USE_AD0_2
+#endif
 
 #define DefaultVoltageOfAdc(adc) (0.0183*adc)
 

sw/airborne/boards/hb_1.1.h

@@ -114,11 +114,14 @@
 #define USE_AD1_4
 #endif
 
+/* allow to define ADC_CHANNEL_VSUPPLY in the airframe file*/
+#ifndef ADC_CHANNEL_VSUPPLY
 #define ADC_CHANNEL_VSUPPLY AdcBank1(6)
 #ifndef USE_AD1
 #define USE_AD1
 #endif
 #define USE_AD1_6
+#endif
 
 
 #define DefaultVoltageOfAdc(adc) (0.032362123*adc)

sw/airborne/boards/lisa_l_1.0.h

@@ -24,7 +24,10 @@
 
 
 /* PA0 - ADC0 */
+/* allow to define ADC_CHANNEL_VSUPPLY in the airframe file*/
+#ifndef ADC_CHANNEL_VSUPPLY
 #define ADC_CHANNEL_VSUPPLY 2
+#endif
 #define DefaultVoltageOfAdc(adc) (0.0059*adc)
 /* Onboard ADCs */
 #define BOARD_ADC_CHANNEL_1 ADC_Channel_8

sw/airborne/boards/lisa_m_1.0.h

@@ -30,8 +30,10 @@
 #define IMU_ACC_DRDY_GPIO             GPIOB
 #define IMU_ACC_DRDY_GPIO_PORTSOURCE  GPIO_PortSourceGPIOB
 
-
+/* allow to define ADC_CHANNEL_VSUPPLY in the airframe file*/
+#ifndef ADC_CHANNEL_VSUPPLY
 #define ADC_CHANNEL_VSUPPLY 2
+#endif
 #define DefaultVoltageOfAdc(adc) (0.00485*adc)
 
 /* Onboard ADCs */

sw/airborne/boards/navgo_1.0.h

@@ -43,11 +43,14 @@
 /* ADC */
 
 /* battery */
+/* allow to define ADC_CHANNEL_VSUPPLY in the airframe file*/
+#ifndef ADC_CHANNEL_VSUPPLY
 #define ADC_CHANNEL_VSUPPLY AdcBank1(3)
 #ifndef USE_AD1
 #define USE_AD1
 #endif
 #define USE_AD1_3
+#endif
 
 #define DefaultVoltageOfAdc(adc) (0.01837*adc)
 

sw/airborne/boards/tiny_0.99.h

@@ -116,11 +116,14 @@
 #define USE_AD1_2
 #endif
 
+/* allow to define ADC_CHANNEL_VSUPPLY in the airframe file*/
+#ifndef ADC_CHANNEL_VSUPPLY
 #define ADC_CHANNEL_VSUPPLY AdcBank1(6)
 #ifndef USE_AD1
 #define USE_AD1
 #endif
 #define USE_AD1_6
+#endif
 
 #define DefaultVoltageOfAdc(adc) (0.01787109375*adc)
 

sw/airborne/boards/tiny_1.1.h

@@ -124,11 +124,14 @@
 #define USE_AD1_5
 #endif
 
+/* allow to define ADC_CHANNEL_VSUPPLY in the airframe file*/
+#ifndef ADC_CHANNEL_VSUPPLY
 #define ADC_CHANNEL_VSUPPLY AdcBank1(6)
 #ifndef USE_AD1
 #define USE_AD1
 #endif
 #define USE_AD1_6
+#endif
 
 #define DefaultVoltageOfAdc(adc) (0.01787109375*adc)
 

sw/airborne/boards/tiny_2.0.h

@@ -122,11 +122,14 @@
 #define USE_AD1_3
 #endif
 
+/* allow to define ADC_CHANNEL_VSUPPLY in the airframe file*/
+#ifndef ADC_CHANNEL_VSUPPLY
 #define ADC_CHANNEL_VSUPPLY AdcBank1(5)
 #ifndef USE_AD1
 #define USE_AD1
 #endif
 #define USE_AD1_5
+#endif
 
 
 #ifndef VoltageOfAdc

sw/airborne/boards/tiny_2.1.h

@@ -148,11 +148,14 @@
 #define USE_AD1_3
 #endif
 
+/* allow to define ADC_CHANNEL_VSUPPLY in the airframe file*/
+#ifndef ADC_CHANNEL_VSUPPLY
 #define ADC_CHANNEL_VSUPPLY AdcBank1(5)
 #ifndef USE_AD1
 #define USE_AD1
 #endif
 #define USE_AD1_5
+#endif
 
 
 #define DefaultVoltageOfAdc(adc) (0.01787109375*adc)

sw/airborne/boards/tiny_sim.h

@@ -122,11 +122,14 @@
 #endif
 
 /* #define ADC_3 AdcBank1(7) Used for VSUPPLY */
+/* allow to define ADC_CHANNEL_VSUPPLY in the airframe file*/
+#ifndef ADC_CHANNEL_VSUPPLY
 #define ADC_CHANNEL_VSUPPLY AdcBank1(7)
 #ifndef USE_AD1
 #define USE_AD1
 #endif
 #define USE_AD1_7
+#endif
 
 
 #define DefaultVoltageOfAdc(adc) (0.01787109375*adc)

sw/airborne/boards/umarim_1.0.h

@@ -78,11 +78,14 @@
 
 
 /* battery */
+/* allow to define ADC_CHANNEL_VSUPPLY in the airframe file*/
+#ifndef ADC_CHANNEL_VSUPPLY
 #define ADC_CHANNEL_VSUPPLY AdcBank0(2)
 #ifndef USE_AD0
 #define USE_AD0
 #endif
 #define USE_AD0_2
+#endif
 
 #define DefaultVoltageOfAdc(adc) (0.0247*adc)
 

sw/airborne/led.h

@@ -23,7 +23,7 @@
  */
 
 /** \file led.h
- *  \brief arch independant LED (Light Emitting Diodes) API
+ *  \brief arch independent LED (Light Emitting Diodes) API
  *
  *
  */

sw/airborne/mcu.h

@@ -23,7 +23,7 @@
  */
 
 /** \file mcu.h
- *  \brief arch independant mcu ( Micro Controller Unit ) utilities
+ *  \brief arch independent mcu ( Micro Controller Unit ) utilities
  */
 
 #ifndef MCU_H

sw/airborne/mcu_periph/adc.h

@@ -23,7 +23,7 @@
  */
 
 /** \file adc.h
- *  \brief arch independant ADC (Analog to Digital Converter) API
+ *  \brief arch independent ADC (Analog to Digital Converter) API
  *
  * Facility to store last values in a circular buffer for a specific
  *   channel:

sw/airborne/mcu_periph/spi.h

@@ -23,7 +23,7 @@
  */
 
 /** \file mcu_periph/spi.h
- * \brief arch independant SPI (Serial Peripheral Interface) API */
+ * \brief arch independent SPI (Serial Peripheral Interface) API */
 
 
 #ifndef SPI_H

sw/airborne/mcu_periph/uart.h

@@ -23,7 +23,7 @@
  */
 
 /** \file mcu_periph/uart.h
- *  \brief arch independant UART (Universal Asynchronous Receiver/Transmitter) API
+ *  \brief arch independent UART (Universal Asynchronous Receiver/Transmitter) API
  *
  */
 

sw/airborne/mcu_periph/usb_serial.h

@@ -23,7 +23,7 @@
  */
 
 /** \file usb_serial.h
- *  \brief arch independant USB API
+ *  \brief arch independent USB API
  *
  */
 

sw/airborne/sys_time.h

@@ -23,7 +23,7 @@
  */
 
 /*
- *\brief architecture independant timing functions
+ *\brief architecture independent timing functions
  *
  */