2015-02-27 17:29:23 -08:00
|
|
|
Writing sensor documentation {#documentation}
|
|
|
|
=====================
|
|
|
|
|
|
|
|
It is highly encouraged to provide at least some basic documentation for the
|
|
|
|
sensors that you want to add to UPM:
|
|
|
|
|
2015-03-06 17:45:02 -08:00
|
|
|
- If you don't add documentation, the code review will take very long and
|
|
|
|
your contribution could be rejected.
|
2015-02-27 17:29:23 -08:00
|
|
|
- Try to have no warnings in doxygen, this is generally fairly easy.
|
|
|
|
- Have the specific sensor manufacturer/model & version that you used, if you
|
|
|
|
support multiple versions please list.
|
2015-03-06 17:45:02 -08:00
|
|
|
- Simple comments do not need full stops.
|
|
|
|
- Stick to <80 chars per line even in comments.
|
|
|
|
- No text is allowed on the same line as the start or end of a comment /** */.
|
2015-02-27 17:29:23 -08:00
|
|
|
|
2015-03-06 17:45:02 -08:00
|
|
|
####The sensor block
|
2015-02-27 17:29:23 -08:00
|
|
|
|
2015-03-20 14:28:14 -07:00
|
|
|
This is added just before the class declaration in your header(.h) file and has
|
|
|
|
mandatory fields. For single sensor libraries, this block will actually
|
|
|
|
follow immediately after the library block. If you have multiple physical
|
|
|
|
sensors, add this to every one.
|
2015-03-06 17:45:02 -08:00
|
|
|
Here's an example (disregard the "@verbatim" tags in your actual code):
|
2015-02-27 17:29:23 -08:00
|
|
|
|
|
|
|
```
|
|
|
|
@verbatim
|
|
|
|
/**
|
2015-03-06 17:45:02 -08:00
|
|
|
* @library <lib-name>
|
2015-03-10 17:09:27 -07:00
|
|
|
* @sensor <chip-id>
|
|
|
|
* @comname <component-name>
|
|
|
|
* @altname <alt-name>
|
2015-06-23 10:50:26 -07:00
|
|
|
* @altid <alt-id>
|
2015-03-10 17:09:27 -07:00
|
|
|
* @type <component-category>
|
|
|
|
* @man <component-manufacturer>
|
2015-03-18 18:00:43 -07:00
|
|
|
* @web <component-weblinks>
|
2015-03-10 17:09:27 -07:00
|
|
|
* @con <connection-type>
|
2015-03-06 17:45:02 -08:00
|
|
|
* @kit <component-kit>
|
2015-02-27 17:29:23 -08:00
|
|
|
*
|
2015-03-06 17:45:02 -08:00
|
|
|
* @brief Short class/sensor description
|
|
|
|
*
|
|
|
|
* Then add a longer
|
|
|
|
* description here.
|
2015-02-27 17:29:23 -08:00
|
|
|
*
|
2015-03-06 17:45:02 -08:00
|
|
|
* @image html <component-img.jpeg>
|
|
|
|
* @snippet <example-name.cxx> Interesting
|
2015-02-27 17:29:23 -08:00
|
|
|
*/
|
|
|
|
@endverbatim
|
|
|
|
```
|
|
|
|
|
2015-03-10 17:09:27 -07:00
|
|
|
- `<lib-name>` When adding to an existing library this needs to match that
|
|
|
|
library's "@defgroup", otherwise this is a new library name, generally the
|
|
|
|
same as chip id. *Mandatory*
|
2015-03-06 17:45:02 -08:00
|
|
|
- `<chip-id>` Usually the chip number used by the sensor. When this is not
|
2016-02-01 15:36:37 -08:00
|
|
|
available or relevant, use a unique descriptor that makes sense. Must match
|
|
|
|
class name. *Mandatory*
|
|
|
|
- `<component-name>` A short name for your sensor, try to avoid including the
|
|
|
|
manufacturer's name here. *Mandatory*
|
|
|
|
- `<alt-name>` Alternative names that your sensor driver might have. This may
|
|
|
|
include manufacturer's name. *Optional*
|
2015-06-23 10:50:26 -07:00
|
|
|
- `<alt-id>` Alternative chip-ids that your sensor driver supports. *Optional*
|
2015-03-06 17:45:02 -08:00
|
|
|
- `<component-category>` Mention one or more categories the sensor fits in. Can
|
|
|
|
be 'other'. *Mandatory*
|
2015-03-10 17:09:27 -07:00
|
|
|
- `<component-manufacturer>` Sensor manufacturer. Can be 'generic'. *Mandatory*
|
2015-03-18 18:00:43 -07:00
|
|
|
- `<component-weblinks>` Links to vendors or data-sheets. *Optional*
|
2015-03-06 17:45:02 -08:00
|
|
|
- `<connection-type>` Specifies how does the sensor connect to the board
|
|
|
|
*Mandatory*
|
2015-03-10 17:09:27 -07:00
|
|
|
- `<component-kit>` Specifies if the sensor is part of a kit. *Optional*
|
2015-03-06 17:45:02 -08:00
|
|
|
|
|
|
|
Existing groups that can be used for the manufacturer, connection, category and
|
2016-09-19 19:21:13 -07:00
|
|
|
kit tags are found in the *src/groups.md* file.
|
2015-02-27 17:29:23 -08:00
|
|
|
|
|
|
|
Optionally, a small representative image can be placed in the "docs/images"
|
2015-03-06 17:45:02 -08:00
|
|
|
subfolder and linked with the "@image" tag.
|
|
|
|
**Please do not use existing, copyrighted images with your sensors!**
|
2015-02-27 17:29:23 -08:00
|
|
|
|
|
|
|
The example should have an 'Interesting' section which will be highlighted as
|
|
|
|
a code sample in doxygen. Everything in between such tags will show up in the
|
|
|
|
class documentation when "@snippet" is added at the end of a class docstring.
|
2015-03-06 17:45:02 -08:00
|
|
|
Tags use this format (in "example-name.cxx"):
|
2015-02-27 17:29:23 -08:00
|
|
|
|
|
|
|
```
|
|
|
|
@verbatim
|
|
|
|
//! [Interesting]
|
|
|
|
|
|
|
|
...example code here...
|
|
|
|
|
|
|
|
//! [Interesting]
|
|
|
|
@endverbatim
|
|
|
|
```
|
|
|
|
|
|
|
|
For more examples take a look at the existing headers in our github repository.
|
2015-03-06 17:45:02 -08:00
|
|
|
|
|
|
|
####The library block
|
|
|
|
|
|
|
|
New libraries must have the "@brief", "@defgroup" and "@ingroup" tags in one
|
|
|
|
block. This usually follows the namespace and it is common to have one sensor
|
|
|
|
per library.
|
|
|
|
|
|
|
|
You should end up with something like this:
|
|
|
|
|
|
|
|
```
|
|
|
|
@verbatim
|
|
|
|
/**
|
|
|
|
* @brief Short description for entire library
|
|
|
|
*
|
|
|
|
* Optional longer description.
|
|
|
|
*
|
|
|
|
* @defgroup <lib-name> libupm-<lib-name>
|
|
|
|
* @ingroup <manufacturer> <connection> <category> (<kit>)
|
|
|
|
*/
|
|
|
|
@endverbatim
|
|
|
|
```
|
|
|
|
|
|
|
|
In "@defgroup" use the same `<lib-name>` used in the sensor block. Multiple
|
|
|
|
sensors can be added to the same library this way.
|
|
|
|
For "@ingroup" add the same values as in the sensor block for manufacturer,
|
|
|
|
category, connection type and kit. If you have multiple classes or sensors
|
|
|
|
per library, only use the "@ingroup" tags that are common for all of them.
|