blackbeard420/esp-idf
1
0
Fork 0
mirror of https://github.com/espressif/esp-idf synced 2025-03-12 02:29:10 -04:00
Code Issues Projects Releases Wiki Activity

Merge branch 'feature/kconfig_options_doc' into 'master'

Browse Source 
Generate documentation for Kconfig options

See merge request !1128
This commit is contained in:
Ivan Grokhotkov 2017-08-22 19:30:31 +08:00
commit 4781f806f4
16 changed files with 3650 additions and 62 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
components/esp32/Kconfig
View File

@ -253,6 +253,7 @@ choice CONSOLE_UART
default CONSOLE_UART_DEFAULT
help
Select whether to use UART for console output (through stdout and stderr).
- Default is to use UART0 on pins GPIO1(TX) and GPIO3(RX).
- If "Custom" is selected, UART0 or UART1 can be chosen,
and any pins can be selected.
@ -315,22 +316,17 @@ config ULP_COPROC_ENABLED
If this option is enabled, further coprocessor configuration will appear in the Components menu.
config ULP_COPROC_RESERVE_MEM
int "RTC slow memory reserved for coprocessor"
default 512
range 32 8192
depends on ULP_COPROC_ENABLED
int
prompt "RTC slow memory reserved for coprocessor" if ULP_COPROC_ENABLED
default 512 if ULP_COPROC_ENABLED
range 32 8192 if ULP_COPROC_ENABLED
default 0 if !ULP_COPROC_ENABLED
range 0 0 if !ULP_COPROC_ENABLED
help
Bytes of memory to reserve for ULP coprocessor firmware & data.
Data is reserved at the beginning of RTC slow memory.
# Set CONFIG_ULP_COPROC_RESERVE_MEM to 0 if ULP is disabled
config ULP_COPROC_RESERVE_MEM
int
default 0
depends on !ULP_COPROC_ENABLED
choice ESP32_PANIC
prompt "Panic handler behaviour"
default ESP32_PANIC_PRINT_REBOOT
@ -542,6 +538,7 @@ config ESP32_RTC_CLK_CAL_CYCLES
When this option is set to 0, clock calibration will not be performed at
startup, and approximate clock frequencies will be assumed:
- 150000 Hz if internal RC oscillator is used as clock source
- 32768 Hz if the 32k crystal oscillator is used
@ -568,8 +565,10 @@ choice ESP32_XTAL_FREQ_SEL
default ESP32_XTAL_FREQ_AUTO
help
ESP32 currently supports the following XTAL frequencies:
- 26 MHz
- 40 MHz
- 26 MHz
- 40 MHz
Startup code can automatically estimate XTAL frequency. This feature
uses the internal 8MHz oscillator as a reference. Because the internal
oscillator frequency is temperature dependent, it is not recommended
@ -591,8 +590,6 @@ config ESP32_XTAL_FREQ
default 40 if ESP32_XTAL_FREQ_40
default 26 if ESP32_XTAL_FREQ_26
endmenu
config NO_BLOBS
bool "No Binary Blobs"
depends on !BT_ENABLED
@ -601,6 +598,8 @@ config NO_BLOBS
If enabled, this disables the linking of binary libraries in the application build. Note
that after enabling this Wi-Fi/Bluetooth will not work.
endmenu
menu Wi-Fi
config SW_COEXIST_ENABLE

2
components/freertos/Kconfig
View File

@ -240,7 +240,7 @@ config ENABLE_STATIC_TASK_CLEAN_UP_HOOK
help
Enable this option to make FreeRTOS call the static task clean up hook when a task is deleted.
Bear in mind that if this option is enabled you will need to implement the following function:
Bear in mind that if this option is enabled you will need to implement the following function::
void vPortCleanUpTCB ( void *pxTCB ) {
// place clean up code here

14
components/mbedtls/Kconfig
View File

@ -160,13 +160,6 @@ config MBEDTLS_KEY_EXCHANGE_DHE_PSK
help
Enable to support Diffie-Hellman PSK (pre-shared-key) TLS authentication modes.
config MBEDTLS_KEY_EXCHANGE_DHE_PSK
bool "Enable DHE-PSK based ciphersuite modes"
depends on MBEDTLS_PSK_MODES
default y
help
Enable to support Diffie-Hellman PSK (pre-shared-key) TLS authentication modes.
config MBEDTLS_KEY_EXCHANGE_ECDHE_PSK
bool "Enable ECDHE-PSK based ciphersuite modes"
depends on MBEDTLS_PSK_MODES
@ -218,13 +211,6 @@ config MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA
help
Enable to support ciphersuites with prefix TLS-ECDHE-RSA-WITH-
config MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA
bool "Enable ECDHE-ECDSA based ciphersuite modes"
depends on MBEDTLS_KEY_EXCHANGE_ELLIPTIC_CURVE && MBEDTLS_ECDH_C && MBEDTLS_ECDSA_C
default y
help
Enable to support ciphersuites with prefix TLS-ECDHE-RSA-WITH-
config MBEDTLS_KEY_EXCHANGE_ECDH_ECDSA
bool "Enable ECDH-ECDSA based ciphersuite modes"
depends on MBEDTLS_KEY_EXCHANGE_ELLIPTIC_CURVE && MBEDTLS_ECDH_C && MBEDTLS_ECDSA_C

2
components/partition_table/Kconfig.projbuild
View File

@ -1,6 +1,6 @@
menu "Partition Table"
choice
choice PARTITION_TABLE_TYPE
prompt "Partition Table"
default PARTITION_TABLE_SINGLE_APP
help

8
components/spi_flash/Kconfig
View File

@ -5,9 +5,11 @@ config SPI_FLASH_ENABLE_COUNTERS
default 0
help
This option enables the following APIs:
spi_flash_reset_counters
spi_flash_dump_counters
spi_flash_get_counters
- spi_flash_reset_counters
- spi_flash_dump_counters
- spi_flash_get_counters
These APIs may be used to collect performance data for spi_flash APIs
and to help understand behaviour of libraries which use SPI flash.

12
docs/api-guides/app_trace.rst
View File

@ -30,7 +30,7 @@ The library supports two modes of operation:
**Post-mortem mode**. This is the default mode. The mode does not need interaction from the host side. In this mode tracing module does not check whether host has read all the data from *HW UP BUFFER* buffer and overwrites old data with the new ones. This mode is useful when only the latest trace data are interesting to the user, e.g. for analyzing program's behaviour just before the crash. Host can read the data later on upon user request, e.g. via special OpenOCD command in case of working via JTAG interface.
**Streaming mode.** Tracing module enters this mode when host connects to ESP32. In this mode before writing new data to *HW UP BUFFER* tracing module checks that there is enough space in it and if necessary waits for the host to read data and free enough memory. Maximum waiting time is controled via timeout values passed by users to corresponding API routines. So when application tries to write data to trace buffer using finite value of the maximum waiting time it is possible situation that this data will be dropped. Especially this is true for tracing from time critical code (ISRs, OS scheduler code etc.) when infinite timeouts can lead to system malfunction. In order to avoid loss of such critical data developers can enable additional data buffering via menuconfig option *Component config > Application Level Tracing > Size of the pending data buffer* (``CONFIG_ESP32_APPTRACE_PENDING_DATA_SIZE_MAX``). This macro specifies the size of data which can be buffered in above conditions. The option can also help to overcome situation when data transfer to the host is temporarily slowed down, e.g due to USB bus congestions etc. But it will not help when average bitrate of trace data stream exceeds HW interface capabilities.
**Streaming mode.** Tracing module enters this mode when host connects to ESP32. In this mode before writing new data to *HW UP BUFFER* tracing module checks that there is enough space in it and if necessary waits for the host to read data and free enough memory. Maximum waiting time is controled via timeout values passed by users to corresponding API routines. So when application tries to write data to trace buffer using finite value of the maximum waiting time it is possible situation that this data will be dropped. Especially this is true for tracing from time critical code (ISRs, OS scheduler code etc.) when infinite timeouts can lead to system malfunction. In order to avoid loss of such critical data developers can enable additional data buffering via menuconfig option :ref:`CONFIG_ESP32_APPTRACE_PENDING_DATA_SIZE_MAX`. This macro specifies the size of data which can be buffered in above conditions. The option can also help to overcome situation when data transfer to the host is temporarily slowed down, e.g due to USB bus congestions etc. But it will not help when average bitrate of trace data stream exceeds HW interface capabilities.
Configuration Options and Dependencies
@ -39,7 +39,7 @@ Configuration Options and Dependencies
Using of this feature depends on two components:
1. **Host side:** Application tracing is done over JTAG, so it needs OpenOCD to be set up and running on host machine. For instructions how to set it up, please, see :doc:`JTAG Debugging <../api-guides/jtag-debugging/index>` for details.
2. **Target side:** Application tracing functionality can be enabled by ``CONFIG_ESP32_APPTRACE_ENABLE`` macro via menuconfig. This option enables the module and makes tracing API available for users. Actually there is menu *Component config > Application Level Tracing* which allows selecting destination for the trace data (HW interface for transport). So choosing one of the destinations automatically enables ``CONFIG_ESP32_APPTRACE_ENABLE`` option.
2. **Target side:** Application tracing functionality can be enabled in menuconfig. *Component config > Application Level Tracing* menu allows selecting destination for the trace data (HW interface for transport). Choosing any of the destinations automatically enables ``CONFIG_ESP32_APPTRACE_ENABLE`` option.
.. note::
@ -47,8 +47,8 @@ Using of this feature depends on two components:
There are two additional menuconfig options not mentioned above:
1. *Component config > Application Level Tracing > Threshold for flushing last trace data to host on panic* (``CONFIG_ESP32_APPTRACE_POSTMORTEM_FLUSH_TRAX_THRESH``). This option is necessary due to the nature of working over JTAG. In that mode trace data are exposed to the host in 16KB blocks. In post-mortem mode when one block is filled it is exposed to the host and the previous one becomes unavailable. In other words trace data are overwritten in 16KB granularity. On panic the latest data from the current input block are exposed to host and host can read them for post-analysis. It can happen that system panic occurs when there are very small amount of data which are not exposed to the host yet. In this case the previous 16KB of collected data will be lost and host will see the latest, but very small piece of the trace. It can be insufficient to diagnose the problem. This menuconfig option allows avoiding such situations. It controls the threshold for flushing data in case of panic. For example user can decide that it needs not less then 512 bytes of the recent trace data, so if there is less then 512 bytes of pending data at the moment of panic they will not be flushed and will not overwrite previous 16KB. The option is only meaningful in post-mortem mode and when working over JTAG.
2. *Component config > Application Level Tracing > Timeout for flushing last trace data to host on panic* (``CONFIG_ESP32_APPTRACE_ONPANIC_HOST_FLUSH_TMO``). The option is only meaningful in streaming mode and controls the maximum time tracing module will wait for the host to read the last data in case of panic.
1. *Threshold for flushing last trace data to host on panic* (:ref:`CONFIG_ESP32_APPTRACE_POSTMORTEM_FLUSH_TRAX_THRESH`). This option is necessary due to the nature of working over JTAG. In that mode trace data are exposed to the host in 16KB blocks. In post-mortem mode when one block is filled it is exposed to the host and the previous one becomes unavailable. In other words trace data are overwritten in 16KB granularity. On panic the latest data from the current input block are exposed to host and host can read them for post-analysis. It can happen that system panic occurs when there are very small amount of data which are not exposed to the host yet. In this case the previous 16KB of collected data will be lost and host will see the latest, but very small piece of the trace. It can be insufficient to diagnose the problem. This menuconfig option allows avoiding such situations. It controls the threshold for flushing data in case of panic. For example user can decide that it needs not less then 512 bytes of the recent trace data, so if there is less then 512 bytes of pending data at the moment of panic they will not be flushed and will not overwrite previous 16KB. The option is only meaningful in post-mortem mode and when working over JTAG.
2. *Timeout for flushing last trace data to host on panic* (:ref:`CONFIG_ESP32_APPTRACE_ONPANIC_HOST_FLUSH_TMO`). The option is only meaningful in streaming mode and controls the maximum time tracing module will wait for the host to read the last data in case of panic.
How to use this library
@ -340,9 +340,9 @@ Another useful IDF feature built on top of application tracing library is the sy
How To Use It
"""""""""""""
Support for this feature is enabled by *Component config > Application Level Tracing > FreeRTOS SystemView Tracing* (``CONFIG_SYSVIEW_ENABLE``) menuconfig option. There are several other options enabled under the same menu:
Support for this feature is enabled by *Component config > Application Level Tracing > FreeRTOS SystemView Tracing* (:ref:`CONFIG_SYSVIEW_ENABLE`) menuconfig option. There are several other options enabled under the same menu:
1. *ESP32 timer to use as SystemView timestamp source* (``CONFIG_SYSVIEW_TS_SOURCE``) selects the source of timestamps for SystemView events. In single core mode timestamps are generated using ESP32 internal cycle counter running at maximum 240 Mhz (~4 ns granularity). In dual-core mode external timer working at 40Mhz is used, so timestamp granularity is 25 ns.
1. *ESP32 timer to use as SystemView timestamp source* (:ref:`CONFIG_SYSVIEW_TS_SOURCE`) selects the source of timestamps for SystemView events. In single core mode timestamps are generated using ESP32 internal cycle counter running at maximum 240 Mhz (~4 ns granularity). In dual-core mode external timer working at 40Mhz is used, so timestamp granularity is 25 ns.
2. Individually enabled or disabled collection of SystemView events (``CONFIG_SYSVIEW_EVT_XXX``):
- Trace Buffer Overflow Event

2
docs/api-guides/build-system.rst
View File

@ -568,6 +568,8 @@ is overridden then the component can instruct the linker to link other binaries
.. _GNU Make Manual: https://www.gnu.org/software/make/manual/make.html
.. _custom-sdkconfig-defaults:
Custom sdkconfig defaults
-------------------------

2
docs/api-guides/jtag-debugging/tips-and-quirks.rst
View File

@ -9,7 +9,7 @@ This section provides collection of all tips and quirks referred to from various
Breakpoints and watchpoints available
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ESP32 supports 2 hardware breakpoints. It also supports two watchpoints, so two variables can be watched for change or read by the GDB command ``watch myVariable``. Note that menuconfig option "Component config > FreeRTOS > Set a debug watchpoint as a stack overflow check" use the 2nd watchpoint and will not provide expected results, if you also try to use it within OpenOCD / GDB. See menuconfig's help for detailed description.
The ESP32 supports 2 hardware breakpoints. It also supports two watchpoints, so two variables can be watched for change or read by the GDB command ``watch myVariable``. Note that menuconfig option :ref:`CONFIG_FREERTOS_WATCHPOINT_END_OF_STACK` uses the 2nd watchpoint and will not provide expected results, if you also try to use it within OpenOCD / GDB. See menuconfig's help for detailed description.
.. _jtag-debugging-tip-where-breakpoints:

2
docs/api-guides/partition-tables.rst
View File

@ -107,7 +107,7 @@ When type is "data", the subtype field can be specified as ota (0), phy (1), nvs
- phy (1) is for storing PHY initialisation data. This allows PHY to be configured per-device, instead of in firmware.
- In the default configuration, the phy partition is not used and PHY initialisation data is compiled into the app itself. As such, this partition can be removed from the partition table to save space.
- To load PHY data from this partition, run ``make menuconfig`` and enable "Component Config" -> "PHY" -> "Use a partition to store PHY init data". You will also need to flash your devices with phy init data as the esp-idf build system does not do this automatically.
- To load PHY data from this partition, run ``make menuconfig`` and enable :ref:`CONFIG_ESP32_PHY_INIT_DATA_IN_PARTITION` option. You will also need to flash your devices with phy init data as the esp-idf build system does not do this automatically.
- nvs (2) is for the :doc:`Non-Volatile Storage (NVS) API <../api-reference/storage/nvs_flash>`.
- NVS is used to store per-device PHY calibration data (different to initialisation data).

26
docs/api-guides/wifi.rst
View File

@ -495,25 +495,13 @@ The scan type and other scan attributes are configured by esp_wifi_scan_start. T
| | in the table below. Here, min is short for scan |
| | time.active.min and max is short for scan_time.active.max. |
| | |
| | +----+----+------------------------------------------------+ |
| | | min| max| Description | |
| | +====+====+================================================+ |
| | | 0 | 0 | scan dwells on each channel for 120 ms. | |
| | | | | | |
| | +----+----+------------------------------------------------+ |
| | | >0 | 0 | scan dwells on each channel for 120 ms. | |
| | | | | | |
| | +----+----+------------------------------------------------+ |
| | | >0 | >0 | The minimum time the scan dwells on each | |
| | | | | channel is min milliseconds. If no AP is found | |
| | | | | during this time frame, the scan switches | |
| | | | | to the next channel; otherwise, the scan dwells| |
| | | | | on the channel for max milliseconds. | |
| | | | | | |
| | +----+----+------------------------------------------------+ |
| | | 0 | >0 | The scan dwells on each channel for max | |
| | | | | milliseconds. | |
| | +----+----+------------------------------------------------+ |
| | - min=0, max=0: scan dwells on each channel for 120 ms. |
| | - min>0, max=0: scan dwells on each channel for 120 ms. |
| | - min=0, max>0: scan dwells on each channel for ``max`` ms. |
| | - min>0, max>0: the minimum time the scan dwells on each |
| | channel is ``min`` ms. If no AP is found during this time |
| | frame, the scan switches to the next channel. Otherwise, |
| | the scan dwells on the channel for ``max`` ms. |
| | |
| | If you want to improve the performance of the |
| | the scan, you can try to modify these two parameters. |

1
docs/api-reference/index.rst
View File

@ -12,4 +12,5 @@ API Reference
Protocols <protocols/index>
Storage <storage/index>
System <system/index>
Configuration Options <kconfig>

28
docs/api-reference/kconfig.rst Normal file
View File

@ -0,0 +1,28 @@
Configuration Options
*********************
Introduction
============
ESP-IDF uses Kconfig_ system to provide a compile-time configuration mechanism. Kconfig is based around options of several types: integer, string, boolean. Kconfig files specify dependencies between options, default values of the options, the way the options are grouped together, etc.
Applications developers can use ``make menuconfig`` build target to edit components' configuration. This configuration is saved inside ``sdkconfig`` file in the project root directory. Based on ``sdkconfig``, application build targets will generate ``sdkconfig.h`` file in the build directory, and will make sdkconfig options available to component makefiles.
Using sdkconfig.defaults
========================
When updating ESP-IDF version, it is not uncommon to find that new Kconfig options are introduced. When this happens, application build targets will offer an interactive prompt to select values for the new options. New values are then written into ``sdkconfig`` file. To supress interactive prompts, applications can either define ``BATCH_BUILD`` environment variable, which will cause all prompts to be suppressed. This is the same effect as that of ``V`` or ``VERBOSE`` variables. Alternatively, ``defconfig`` build target can be used to update configuration for all new variables to the default values.
In some cases, such as when ``sdkconfig`` file is under revision control, the fact that ``sdkconfig`` file gets changed by the build system may be inconvenient. The build system offers a way to avoid this, in the form of ``sdkconfig.defaults`` file. This file is never touched by the build system, and must be created manually. It can contain all the options which matter for the given application. The format is the same as that of the ``sdkconfig`` file. Once ``sdkconfig.defaults`` is created, ``sdkconfig`` can be deleted and added to the ignore list of the revision control system (e.g. ``.gitignore`` file for git). Project build targets will automatically create ``sdkconfig`` file, populated with the settings from ``sdkconfig.defaults`` file, and the rest of the settings will be set to their default values. Note that when ``make defconfig`` is used, settings in sdkconfig will be overriden by the ones in ``sdkconfig.defaults``. For more information, see :ref:`custom-sdkconfig-defaults`.
Configuration Options Reference
===============================
Subsequent sections contain the list of available ESP-IDF options, automatically generated from Kconfig files. Note that depending on the options selected, some options listed here may not be visible by default in the interface of menuconfig.
By convention, all option names are upper case with underscores. When Kconfig generates sdkconfig and sdkconfig.h files, option names are prefixed with ``CONFIG_``. So if an option ``ENABLE_FOO`` is defined in a Kconfig file and selected in menuconfig, then sdkconfig and sdkconfig.h files will have ``CONFIG_ENABLE_FOO`` defined. In this reference, option names are also prefixed with ``CONFIG_``, same as in the source code.
.. include:: /_build/inc/kconfig.inc
.. _Kconfig: https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt

2
docs/conf.py
View File

@ -29,6 +29,8 @@ print "Calling Doxygen to generate latest XML files"
call('doxygen')
# Generate 'api_name.inc' files using the XML files by Doxygen
os.system("python gen-dxd.py")
# Generate 'kconfig.inc' file from components' Kconfig files
os.system("python gen-kconfig-doc.py > _build/inc/kconfig.inc")
# http://stackoverflow.com/questions/12772927/specifying-an-online-image-in-sphinx-restructuredtext-format
#

120
docs/gen-kconfig-doc.py Executable file
View File

@ -0,0 +1,120 @@
#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
# gen-kconfig-doc.py — generate Sphinx .rst file from Kconfig files
#
# This script iterates over Kconfig and Kconfig.projbuild files in
# ESP-IDF component directories, and outputs documentation for these options
# as ReST markup.
# For each option in Kconfig file (e.g. 'FOO'), CONFIG_FOO link target is
# generated, allowing options to be referenced in other documents
# (using :ref:`CONFIG_FOO`)
#
# This script uses kconfiglib library to do all the work of parsing Kconfig
# files: https://github.com/ulfalizer/Kconfiglib
#
# Copyright 2017 Espressif Systems (Shanghai) PTE LTD
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http:#www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
import os
import kconfiglib
# Indentation to be used in the generated file
INDENT = ' '
# Characters used when underlining section heading
HEADING_SYMBOLS = '#*=-^"+'
# Keep the heading level in sync with api-reference/kconfig.rst
INITIAL_HEADING_LEVEL = 2
MAX_HEADING_LEVEL = 5
OPTION_HEADING_LEVEL = 6
def print_menu_contents(title, items, heading_level, breadcrumbs):
if title:
print_section_heading(title, heading_level)
for entry in items:
if entry.is_menu():
if len(breadcrumbs) > 0:
new_breadcrumbs = breadcrumbs + ' > ' + entry.get_title()
else:
new_breadcrumbs = entry.get_title()
print_menu_contents(entry.get_title(), entry.get_items(),
min(heading_level + 1, MAX_HEADING_LEVEL),
new_breadcrumbs)
elif entry.is_choice():
print_choice(entry, breadcrumbs)
else:
if len(entry.get_prompts()) == 0:
# Skip entries which can never be visible
continue
# Currently this does not handle 'menuconfig' entires in any special way,
# as Kconfglib offers no way of recognizing them automatically.
print_option(entry, breadcrumbs)
# Trailing newline after every option
print
def print_choice(choice, breadcrumbs):
print_option(choice, breadcrumbs)
print
print '%sAvailable options:' % INDENT
for opt in choice.get_symbols():
# Format available options as a list
print '%s- %s' % (INDENT * 2, opt.name)
def print_section_heading(title, heading_level):
print title
print HEADING_SYMBOLS[heading_level] * len(title)
print
def print_option(opt, breadcrumbs):
# add link target so we can use :ref:`CONFIG_FOO`
print '.. _CONFIG_%s:' % opt.name
print
print_section_heading(opt.name, OPTION_HEADING_LEVEL)
if len(opt.prompts) > 0:
print '%s%s' % (INDENT, opt.prompts[0][0])
print
print '%s:emphasis:`Found in: %s`' % (INDENT, breadcrumbs)
print
if opt.get_help() is not None:
# Help text normally contains newlines, but spaces at the beginning of
# each line are stripped by kconfiglib. We need to re-indent the text
# to produce valid ReST.
print '%s%s' % (INDENT, opt.get_help().replace('\n', '\n%s' % INDENT))
def process_kconfig_file(kconfig_file, heading_level, breadcrumbs):
if os.path.exists(kconfig_file):
cfg = kconfiglib.Config(kconfig_file, print_warnings=True)
print_menu_contents(None, cfg.get_top_level_items(), heading_level, breadcrumbs)
def print_all_components():
heading_level = INITIAL_HEADING_LEVEL
# Currently this works only for IDF components.
# TODO: figure out if this can be re-used for documenting applications?
components_path = os.path.join(os.path.curdir, '..', 'components')
for component_name in os.listdir(components_path):
if component_name.startswith('.'):
continue # skip system thumbnail folders
kconfig_file_path = os.path.join(components_path, component_name, 'Kconfig')
process_kconfig_file(kconfig_file_path, heading_level, 'Component config')
process_kconfig_file(kconfig_file_path + '.projbuild', heading_level, '')
if __name__ == '__main__':
print_all_components()

2
docs/get-started/idf-monitor.rst
View File

@ -66,7 +66,7 @@ By default, if an esp-idf app crashes then the panic handler prints registers an
Optionally, the panic handler can be configured to run a serial "gdb stub" which can communicate with a gdb_ debugger program and allow memory to be read, variables and stack frames examined, etc. This is not as versatile as JTAG debugging, but no special hardware is required.
To enable the gdbstub, run ``make menuconfig`` and navigate to ``Component config`` -> ``ESP32-specific`` -> ``Panic handler behaviour``, then set the value to ``Invoke GDBStub``.
To enable the gdbstub, run ``make menuconfig`` and set :ref:`CONFIG_ESP32_PANIC` option to ``Invoke GDBStub``.
If this option is enabled and idf_monitor sees the gdb stub has loaded, it will automatically pause serial monitoring and run GDB with the correct arguments. After GDB exits, the board will be reset via the RTS serial line (if this is connected.)

3460
docs/kconfiglib.py Normal file
View File

File diff suppressed because it is too large Load Diff