How2Doc.txt 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281
  1. Rules for CMSIS API Function documentation
  2. ===========================================
  3. This document describes how to generate Doxygen-style documentation for middleware "Components".
  4. It explains how the Doxygen documentation under "Reference" is provided in header (*.h),
  5. text (*.txt), template (*.c), and config files.
  6. Folder structure:
  7. .\MW\component\Include *.h files
  8. .\MW\component\Template *.c user code templates
  9. .\MW\component\Config *.c or *.h config files
  10. .\MW\Doc\component *.txt files
  11. .\MW\Doc\component\images graphic files used by *.txt files
  12. Files: Middleware components have the following files that are used to generate the API documentation:
  13. - *.h files: one or more header files which expose data types and functions (the API). Doxygen uses the *.h files
  14. that are in .\MW\component\include folder.
  15. - *.txt files: documentation files that group functions and explain overall the API. Each *.h file should have a *.txt
  16. file with the same name, i.e. rl_usb.h => rl_usb.txt; a exception is permitted when a template is used to explain
  17. API functions.
  18. - *.c templates: show the usage of some middleware functionality and may be included in the Doxygen documentation.
  19. *.c templates with '%Instance%' are copied to .\MW\Doc\component and '%Instance%' is replaced with 'n', otherwise
  20. Doxygen uses the *.c templates in folder .\MW\component\Template. If a template is used in documentation
  21. the related *.txt file has the same name as the template, i.e. USBD_User_HID.c => USBD_User_HID.txt.
  22. - *.c or *.h config files should be self-explaining using <i> tags. config files will not be replicated
  23. in Doxygen *.txt files, but the high-level usage will be explained. The impact of parameters to middleware
  24. needs therefore be part of the config files.
  25. Source files (*.c and *.h) should NOT use <TAB> character. Instead of <TAB> <space> characters are used.
  26. API Documentation in .\Include\*.h files
  27. ----------------------------------------
  28. Example:
  29. The following snippet shows a sample documentation (correct). In general functions are grouped and
  30. a short descriptive line is added before a group of functions. In case that functions are only
  31. relevant for the documentation (i.e. available in multiple instances), they are included in
  32. #ifdef __DOXYGEN__ / #endif sections.
  33. {code}
  34. /// \brief Called during \ref USBD_Initialize to initialize the USB Device class.
  35. /// \return none
  36. extern void USBD_HIDn_Initialize (void);
  37. // ==== USB Host Human Interface Device Functions ====
  38. /// \brief Get status of the Human Interface Device.
  39. /// \param[in] index instance index of HID.
  40. /// \return true device is configured and initialized.
  41. /// \return false device not ready.
  42. extern bool USBH_HID_GetStatus (uint8_t index);
  43. /// \brief Read data received from Human Interface Device.
  44. /// \param[in] index instance index of HID.
  45. /// \param[out] ptr_data data to be read.
  46. /// \return value >= 0 number of bytes read.
  47. /// \return value -1 communication error.
  48. extern int USBH_HID_Read (uint8_t index, uint8_t *ptr_data);
  49. /// \brief Write data to Human Interface Device.
  50. /// \param[in] index instance index of HID.
  51. /// \param[in] ptr_data data to be written.
  52. /// \param[in] data_len number of data bytes to be written.
  53. /// \return number of bytes written.
  54. extern int USBH_HID_Write (uint8_t index, uint8_t *ptr_data, uint16_t data_len);
  55. /// \brief Get last error that happened on the Human Interface Device.
  56. /// \param[in] index instance index of HID.
  57. /// \return error code.
  58. extern uint32_t USBH_HID_GetLastError (uint8_t index);
  59. /// \brief Retrieve state change since last call of HID Mouse.
  60. /// \param[in] index instance index of HID.
  61. /// \param[out] button pointer to variable that receives button state.
  62. /// \param[out] x pointer to variable that receives x position change.
  63. /// \param[out] y pointer to variable that receives y position change.
  64. /// \param[out] wheel pointer to variable that receives wheel change.
  65. /// \return true state change since last call.
  66. /// \return false no state change since last call.
  67. extern bool USBH_HID_GetMouseData (uint8_t index, uint8_t *button, int8_t *x, int8_t *y, int8_t *wheel);
  68. // ==== USB Device Human Interface Device Functions ====
  69. #ifdef __DOXYGEN__
  70. // following functions are available for each instance of a HID class.
  71. // generic prefix USBD_HIDn is USBD_HID0 for HID class instance 0.
  72. /// \brief Prepare HID report data to be sent.
  73. /// \param[in] rtype Report type
  74. /// - HID_REPORT_INPUT = Input report requested.
  75. /// - HID_REPORT_FEATURE = Feature report requested.
  76. /// \param[in] rid Report ID (0 if only one report exists)
  77. /// \param[out] buf Buffer for report data to be sent.
  78. /// \param[in] req Request type
  79. /// - USBD_HID_REQ_EP_CTRL = Control endpoint request.
  80. /// - USBD_HID_REQ_PERIOD_UPDATE = Idle period expiration request.
  81. /// - USBD_HID_REQ_EP_INT = Previously sent report on interrupt endpoint request.
  82. /// \return value >= 0 number of data bytes prepared
  83. /// \return value < 0 error code
  84. int32_t USBD_HIDn_GetReport (uint8_t rtype, uint8_t rid, uint8_t *buf, uint8_t req);
  85. {code}
  86. This section contains things that should be NOT DONE:
  87. /// \brief Prepares HID report data to be sent
  88. *** NO '.' to terminate brief documentation.
  89. /// \brief Prepares HID report data to be sent.
  90. *** NO 's' after a verb in brief documentation.
  91. /// \brief Retrieve a state change since last call of the HID Mouse.
  92. *** NO 'a' or 'the' in brief text.
  93. /// \return true when state change since last call, false otherwise.
  94. *** Confusing return statement, separate into two lines (looks also better):
  95. /// \return
  96. /// - true = when state change since last call
  97. /// - false = otherwise.
  98. /// \return 0 no communication error.
  99. /// \return - 1 communication error.
  100. *** Confusing, may generate a bullet point, use instead "value" in front of plain numbers, correct is:
  101. /// \return value 0 no communication error.
  102. /// \return value -1 communication error.
  103. /// \param[in] req Request type:
  104. /// USBD_HID_REQ_EP_CTRL = Control endpoint request.
  105. /// USBD_HID_REQ_PERIOD_UPDATE = Idle period expiration request.
  106. /// USBD_HID_REQ_EP_INT = Previously sent report on interrupt endpoint request.
  107. *** Missing '-' in front of parameter details => hard to read in documentation.
  108. /// \param[in] stat error status and line states
  109. /// - bit 6 - bOverRun
  110. /// - bit 5 - bParity
  111. *** Missing ':' after states and bit numbers, correct is:
  112. /// \param[in] stat error status and line states:
  113. /// - bit 6: bOverRun
  114. /// - bit 5: bParity
  115. /// \param[in] ptr_data pointer to data buffer where information is written.
  116. *** Wrong, should be param[out].
  117. *** Redundant: a data buffer is always a pointer, better is:
  118. /// \param[out] ptr_data data buffer that receives information.
  119. /// \fn bool USBH_HID_GetStatus (uint8_t index);
  120. /// \brief Get status of the Human Interface Device.
  121. /// \param[in] index instance index of HID.
  122. /// \return true device is configured and initialized.
  123. /// \return false device not ready.
  124. extern bool USBH_HID_GetStatus (uint8_t index);
  125. Wrong: \fn not needed
  126. /* USB Host Speed constants */
  127. enum {
  128. USBH_LS = 0, /* Low speed */
  129. USBH_FS, /* Full speed */
  130. USBH_HS /* High speed */
  131. };
  132. Wrong, should be Doxygen style. Correct is:
  133. /// USB Host Speed constants
  134. enum {
  135. USBH_LS = 0, ///< Low speed
  136. USBH_FS, ///< Full speed
  137. USBH_HS ///< High speed
  138. };
  139. typedef struct { ///< Hw Endpoint settings structure
  140. osThreadId thread_id; ///< Thread ID of thread that uses URB
  141. USBH_URB urb; ///< URB used for endpoint communication} USBH_EP;
  142. Wrong: '/// comment' before 'struct {'
  143. Bad: repeat of Thread ID and URB does not add value; avoid abbreviations like 'Hw'
  144. Better is:
  145. /// Hardware Endpoint Settings for communication functions
  146. typedef struct {
  147. osThreadId thread_id; ///< thread using USB Request Block (urb)
  148. USBH_URB urb; ///< USB Request Block for endpoint communication
  149. API Documentation in *.txt files
  150. --------------------------------
  151. A *.txt file that relates to a *.h contains:
  152. - Functional group assignments using \defgroup along with \brief description
  153. - Under \details an overview description for each functional group (should contain a useful code example)
  154. - For each function in the header file a detailed description
  155. IMPORTANT:
  156. Text *.txt files that document the user API of a component are located in .\MW\Doc\component.
  157. Only for *.h files that provide user API, there is exactly one text file with the same name.
  158. Defines/Functions that are internally used by a Component have no *.txt file.
  159. Example:
  160. .\MW\component\Include\rl_usb.h => .\MW\Doc\component\rl_usb.txt
  161. The file documents each function that is exposed in *.h header file (and only those functions).
  162. In case that functions are described in other files (i.e. USB Class Templates) there is a reference.
  163. Functional Group assignments uses this syntax:
  164. ---------------------------
  165. /**
  166. \defgroup a group definition
  167. [\ingroup] optionally within a group
  168. \brief brief description of the group
  169. \details
  170. description
  171. */
  172. /**
  173. \addtogroup a group definition
  174. @{
  175. */
  176. Below \addtogroup the documentation for related functions is provided. This section
  177. ends with @}
  178. Function documentation uses this syntax:
  179. --------
  180. /**
  181. \fn functionName( args )
  182. \details
  183. [\note]
  184. [<b>Code Example</b>
  185. \code | \snippet]
  186. */
  187. See rl_usb.txt for examples
  188. No ';' at the end of the function declaration. Otherwise function description gets ignored.
  189. Comments in doxygen code blocks should be marked with // and not /* ... */, which leads to errors.
  190. -------------------------------------------------------
  191. Example: Wrong:
  192. \code
  193. void ftp_server_notify (uint8_t event) {
  194. /* Notify the user application about events in FTP server.*/
  195. ...
  196. }
  197. \endcode
  198. Example: correct:
  199. \code
  200. void ftp_server_notify (uint8_t event) {
  201. // Notify the user application about events in FTP server.
  202. ...
  203. }
  204. \endcode
  205. Cross references (between components)
  206. -------------------------------------
  207. Within a single component (same .dxy configuration) one can easily created cross references.
  208. Known symbol names are automatically assumed as a reference by Doxygen. Pages, sections and
  209. subsections can be referenced using "\ref" notation.
  210. Cross references do not work between different components, though. Doxygen offers the possibility
  211. to import so called tags (symbol and section names) from an another external documentation.
  212. Unfortunately this creates output that crashes the MDK DoxyIndex importer. Hence cross references
  213. needs to be placed manually using <a href="[url]">...</a> notation, for the time being.