firmware-base/scripts/docs.md

3.4 KiB

Context

  • ESP-32, Platform.io, C17
  • avoidance of std
  • industrial application, using Modbus-485

Instructions

  • Generate documentation for a given component in a new Markdown file located at ./docs/<component-name>.md.
  • The documentation is intended for an Astro static site generator.
  • Include frontmatter in the Markdown file with title, description, and keywords fields.
  • You will be provided with the content of the component's header file (e.g., src/<component-name>.h).
  • You must also open and refer to the corresponding C++ source file located at src/<component-name>.cpp.
  • Do not open or access any other files, specifically src/Component.cpp !!!
  • Ensure the generated Markdown adheres to standard linting rules.
  • When using a tool to write the documentation file, ensure the file content is base64 encoded and provide the relative path to the file.
  • The generated Markdown document must follow the specific layout provided below.
  • The component's C++ source file will contain an example of how it is constructed and mounted; use this as a basis for the "Example" section in the documentation.
  • To read files, use the read_file tool, JSON payload : {"path":"relative path"}

Layout

The Markdown document must adhere to the following structure:


COMPONENT NAME

Path: relative/path/to/component-name.cpp (as a Markdown link)

Revision History: Add a file revision entry in the header to track modifications. For the initial documentation, use "Initial documentation". Skip this if a revision history already exists !

A short description of the component.

REQUIREMENTS

Detail the hardware pins and software dependencies required by the component.

FEATURES

List the key features and functionalities of the component.

DEPENDENCIES

  • Provide a list of dependencies as Markdown formatted links.
  • Include a minimal Mermaid diagram illustrating the dependencies. The diagram node names should not contain braces or brackets.

BEHAVIOUR

  • Include a minimal Mermaid diagram illustrating the component's behaviour or state machine. The diagram node names should not contain braces or brackets.

TODOS

PERFORMANCE

Outline any performance considerations or areas for future optimization.

SECURITY

Describe potential security vulnerabilities or hardening measures.

COMPLIANCE

Note any compliance standards or requirements relevant to the component.

RECOMMENDATIONS

Provide any recommendations for using or extending the component.

EXAMPLE

This section should illustrate how the component is constructed and mounted. Refer to the component's C++ source file for an example. A general example structure is:

#ifdef PIN_LED_FEEDBACK_0 ledFeedback_0 = new LEDFeedback( this, // owner PIN_LED_FEEDBACK_0, // pin LED_PIXEL_COUNT_0, // pixelCount ID_LED_FEEDBACK_0, // id LED_FEEDBACK_0_MB_ADDR // modbusAddress ); if (ledFeedback_0) { components.push_back(ledFeedback_0); Log.infoln(F("LEDFeedback_0 initialized. Pin:%d, Count:%d, ID:%d, MB:%d"), PIN_LED_FEEDBACK_0, LED_PIXEL_COUNT_0, ID_LED_FEEDBACK_0, LED_FEEDBACK_0_MB_ADDR); } else { Log.errorln(F("LEDFeedback_0 initialization failed.")); } #endif

References

${DOXYGEN_PLACEHOLDER}

${VENDOR_PLACEHOLDER}