You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/en/api-reference/system/app_image_format.rst
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -62,7 +62,7 @@ You can also see the information on segments in the IDF logs while your applicat
62
62
63
63
For more details on the type of memory segments and their address ranges, see *{IDF_TARGET_NAME} Technical Reference Manual* > *System and Memory* > *Embedded Memory* [`PDF <{IDF_TARGET_TRM_EN_URL}#sysmem>`__].
64
64
65
-
.. only:: esp32s2
65
+
.. only:: esp32s2 or esp32c3
66
66
67
67
For more details on the type of memory segments and their address ranges, see *{IDF_TARGET_NAME} Technical Reference Manual* > *System and Memory* > *Internal Memory* [`PDF <{IDF_TARGET_TRM_EN_URL}#sysmem>`__].
Copy file name to clipboardExpand all lines: docs/en/api-reference/system/console.rst
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -19,9 +19,9 @@ Line editing
19
19
20
20
Line editing feature lets users compose commands by typing them, erasing symbols using 'backspace' key, navigating within the command using left/right keys, navigating to previously typed commands using up/down keys, and performing autocompletion using 'tab' key.
21
21
22
-
.. note::
22
+
.. note::
23
23
24
-
This feature relies on ANSI escape sequence support in the terminal application. As such, serial monitors which display raw UART data can not be used together with the line editing library. If you see ``[6n`` or similar escape sequence when running :example:`system/console` example instead of a command prompt (e.g. ``esp> ``), it means that the serial monitor does not support escape sequences. Programs which are known to work are GNU screen, minicom, and idf_monitor.py (which can be invoked using ``idf.py monitor`` from project directory).
24
+
This feature relies on ANSI escape sequence support in the terminal application. As such, serial monitors which display raw UART data can not be used together with the line editing library. If you see ``[6n`` or similar escape sequence when running :example:`system/console` example instead of a command prompt (e.g. ``esp>`` ), it means that the serial monitor does not support escape sequences. Programs which are known to work are GNU screen, minicom, and idf_monitor.py (which can be invoked using ``idf.py monitor`` from project directory).
25
25
26
26
Here is an overview of functions provided by `linenoise`_ library.
To establish a basic REPL environment, ``console`` component provides several useful APIs, combining those functions described above.
150
150
151
-
In a typical application, you only need to call :cpp:func:`esp_console_new_repl_uart` to initialize the REPL environment based on UART device, including driver install, basic console configuration, spawning a thread to do REPL task and register several useful commands (e.g. `help`).
151
+
In a typical application, you only need to call :cpp:func:`esp_console_new_repl_uart` to initialize the REPL environment based on UART device, including driver install, basic console configuration, spawning a thread to do REPL task and register several useful commands (e.g. `help`).
152
152
153
153
After that, you can register your own commands with :cpp:func:`esp_console_cmd_register`. The REPL environment keeps in init state until you call :cpp:func:`esp_console_start_repl`.
Copy file name to clipboardExpand all lines: docs/en/api-reference/system/esp_pthread.rst
+3-2Lines changed: 3 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -5,6 +5,7 @@ Overview
5
5
--------
6
6
7
7
This module offers Espressif specific extensions to the pthread library that can be used to influence the behaviour of pthreads. Currently the following configuration can be tuned:
8
+
8
9
* Stack size of the pthreads
9
10
* Priority of the created pthreads
10
11
* Inheriting this configuration across threads
@@ -35,9 +36,9 @@ Example to tune the stack size of the pthread:
35
36
The API can also be used for inheriting the settings across threads. For example:
36
37
37
38
.. code-block:: c
38
-
39
+
39
40
void * my_thread2(void * p)
40
-
{
41
+
{
41
42
/* This thread will inherit the stack size of 4K */
Copy file name to clipboardExpand all lines: docs/en/api-reference/system/esp_timer.rst
+10-6Lines changed: 10 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -15,13 +15,17 @@ An interrupt level of the handler depends on the :ref:`CONFIG_ESP_TIMER_INTERRUP
15
15
16
16
``esp_timer`` set of APIs provides one-shot and periodic timers, microsecond time resolution, and 64-bit range.
17
17
18
-
Internally, ``esp_timer`` uses a 64-bit hardware timer:ref:`CONFIG_ESP_TIMER_IMPL`:
18
+
Internally, ``esp_timer`` uses a 64-bit hardware timer, where the implemention depends on :ref:`CONFIG_ESP_TIMER_IMPL`. Available options are:
19
19
20
-
- LAC timer (ESP32)
21
-
- (legacy) FRC2 timer (ESP32)
22
-
- SYSTIMER for (ESP32-S2)
20
+
.. list::
23
21
24
-
.. note: The FRC2 is a legacy option for ESP32 until v4.2, a 32-bit hardware timer was used. Starting at v4.2, use the new LAC timer option instead, it has a simpler implementation, and has smaller run time overhead because software handling of timer overflow is not needed.
22
+
:esp32: - LAC timer
23
+
:esp32: - (legacy) FRC2 timer
24
+
:not esp32: - SYSTIMER
25
+
26
+
.. only:: esp32
27
+
28
+
.. note:: The FRC2 is a legacy option for ESP32 until v4.2, a 32-bit hardware timer was used. Starting at v4.2, use the new LAC timer option instead, it has a simpler implementation, and has smaller run time overhead because software handling of timer overflow is not needed.
25
29
26
30
Timer callbacks can dispatched by two methods:
27
31
@@ -59,7 +63,7 @@ Callback functions
59
63
60
64
.. note: Keep the callback functions as short as possible otherwise it will affect all timers.
61
65
62
-
Timer callbacks which are processed by ``ESP_TIMER_ISR`` method should not have inside the context switch call - ``portYIELD_FROM_ISR()`` instead of this use the :cpp:func:`esp_timer_isr_dispatch_need_yield` function.
66
+
Timer callbacks which are processed by ``ESP_TIMER_ISR`` method should not call the context switch call - ``portYIELD_FROM_ISR()``, instead of this you should use the :cpp:func:`esp_timer_isr_dispatch_need_yield` function.
63
67
The context switch will be done after all ISR dispatch timers have been processed, if required by the system.
Copy file name to clipboardExpand all lines: docs/en/api-reference/system/intr_alloc.rst
+40-36Lines changed: 40 additions & 36 deletions
Original file line number
Diff line number
Diff line change
@@ -6,17 +6,19 @@ Overview
6
6
7
7
.. only:: esp32
8
8
9
-
The {IDF_TARGET_NAME} has two cores, with 32 interrupts each. Each interrupt has a certain priority level, most (but not all) interrupts are connected
10
-
to the interrupt mux. Because there are more interrupt sources than interrupts, sometimes it makes sense to share an interrupt in
11
-
multiple drivers. The esp_intr_alloc abstraction exists to hide all these implementation details.
9
+
The {IDF_TARGET_NAME} has two cores, with 32 interrupts each. Each interrupt has a certain priority level, most (but not all) interrupts are connected to the interrupt mux.
12
10
13
11
.. only:: esp32s2
14
12
15
-
The {IDF_TARGET_NAME} has one core, with 32 interrupts. Each interrupt has a certain priority level, most (but not all) interrupts are connected
16
-
to the interrupt mux. Because there are more interrupt sources than interrupts, sometimes it makes sense to share an interrupt in
17
-
multiple drivers. The esp_intr_alloc abstraction exists to hide all these implementation details.
13
+
The {IDF_TARGET_NAME} has one core, with 32 interrupts. Each interrupt has a certain priority level, most (but not all) interrupts are connected to the interrupt mux.
18
14
19
-
A driver can allocate an interrupt for a certain peripheral by calling esp_intr_alloc (or esp_intr_alloc_sintrstatus). It can use
15
+
.. only:: esp32c3
16
+
17
+
The {IDF_TARGET_NAME} has one core, with 31 interrupts. Each interrupt has a programmable priority level.
18
+
19
+
Because there are more interrupt sources than interrupts, sometimes it makes sense to share an interrupt in multiple drivers. The :cpp:func:`esp_intr_alloc` abstraction exists to hide all these implementation details.
20
+
21
+
A driver can allocate an interrupt for a certain peripheral by calling :cpp:func:`esp_intr_alloc` (or :cpp:func:`esp_intr_alloc_intrstatus`). It can use
20
22
the flags passed to this function to set the type of interrupt allocated, specifying a specific level or trigger method. The
21
23
interrupt allocation code will then find an applicable interrupt, use the interrupt mux to hook it up to the peripheral, and
22
24
install the given interrupt handler and ISR to it.
@@ -37,48 +39,50 @@ interrupt for DevA is still pending, but because the int line never went low (De
37
39
even when the int for DevB was cleared) the interrupt is never serviced.)
38
40
39
41
40
-
Multicore issues
41
-
----------------
42
+
.. only:: CONFIG_IDF_TARGET_ARCH_XTENSA
43
+
44
+
Multicore issues
45
+
----------------
42
46
43
-
Peripherals that can generate interrupts can be divided in two types:
47
+
Peripherals that can generate interrupts can be divided in two types:
44
48
45
-
- External peripherals, within the {IDF_TARGET_NAME} but outside the Xtensa cores themselves. Most {IDF_TARGET_NAME} peripherals are of this type.
46
-
- Internal peripherals, part of the Xtensa CPU cores themselves.
49
+
- External peripherals, within the {IDF_TARGET_NAME} but outside the Xtensa cores themselves. Most {IDF_TARGET_NAME} peripherals are of this type.
50
+
- Internal peripherals, part of the Xtensa CPU cores themselves.
47
51
48
-
Interrupt handling differs slightly between these two types of peripherals.
52
+
Interrupt handling differs slightly between these two types of peripherals.
49
53
50
-
Internal peripheral interrupts
51
-
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
54
+
Internal peripheral interrupts
55
+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
52
56
53
-
Each Xtensa CPU core has its own set of six internal peripherals:
57
+
Each Xtensa CPU core has its own set of six internal peripherals:
54
58
55
-
- Three timer comparators
56
-
- A performance monitor
57
-
- Two software interrupts.
59
+
- Three timer comparators
60
+
- A performance monitor
61
+
- Two software interrupts.
58
62
59
-
Internal interrupt sources are defined in esp_intr_alloc.h as ``ETS_INTERNAL_*_INTR_SOURCE``.
63
+
Internal interrupt sources are defined in esp_intr_alloc.h as ``ETS_INTERNAL_*_INTR_SOURCE``.
60
64
61
-
These peripherals can only be configured from the core they are associated with. When generating an interrupt,
62
-
the interrupt they generate is hard-wired to their associated core; it's not possible to have e.g. an internal
63
-
timer comparator of one core generate an interrupt on another core. That is why these sources can only be managed
64
-
using a task running on that specific core. Internal interrupt sources are still allocatable using esp_intr_alloc
65
-
as normal, but they cannot be shared and will always have a fixed interrupt level (namely, the one associated in
66
-
hardware with the peripheral).
65
+
These peripherals can only be configured from the core they are associated with. When generating an interrupt,
66
+
the interrupt they generate is hard-wired to their associated core; it's not possible to have e.g. an internal
67
+
timer comparator of one core generate an interrupt on another core. That is why these sources can only be managed
68
+
using a task running on that specific core. Internal interrupt sources are still allocatable using esp_intr_alloc
69
+
as normal, but they cannot be shared and will always have a fixed interrupt level (namely, the one associated in
70
+
hardware with the peripheral).
67
71
68
-
External Peripheral Interrupts
69
-
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
72
+
External Peripheral Interrupts
73
+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
70
74
71
-
The remaining interrupt sources are from external peripherals. These are defined in soc/soc.h as ``ETS_*_INTR_SOURCE``.
75
+
The remaining interrupt sources are from external peripherals. These are defined in soc/soc.h as ``ETS_*_INTR_SOURCE``.
72
76
73
-
Non-internal interrupt slots in both CPU cores are wired to an interrupt multiplexer, which can be used to
74
-
route any external interrupt source to any of these interrupt slots.
77
+
Non-internal interrupt slots in both CPU cores are wired to an interrupt multiplexer, which can be used to
78
+
route any external interrupt source to any of these interrupt slots.
75
79
76
-
- Allocating an external interrupt will always allocate it on the core that does the allocation.
77
-
- Freeing an external interrupt must always happen on the same core it was allocated on.
78
-
- Disabling and enabling external interrupts from another core is allowed.
79
-
- Multiple external interrupt sources can share an interrupt slot by passing ``ESP_INTR_FLAG_SHARED`` as a flag to esp_intr_alloc().
80
+
- Allocating an external interrupt will always allocate it on the core that does the allocation.
81
+
- Freeing an external interrupt must always happen on the same core it was allocated on.
82
+
- Disabling and enabling external interrupts from another core is allowed.
83
+
- Multiple external interrupt sources can share an interrupt slot by passing ``ESP_INTR_FLAG_SHARED`` as a flag to esp_intr_alloc().
80
84
81
-
Care should be taken when calling esp_intr_alloc() from a task which is not pinned to a core. During task switching, these tasks can migrate between cores. Therefore it is impossible to tell which CPU the interrupt is allocated on, which makes it difficult to free the interrupt handle and may also cause debugging difficulties. It is advised to use xTaskCreatePinnedToCore() with a specific CoreID argument to create tasks that will allocate interrupts. In the case of internal interrupt sources, this is required.
85
+
Care should be taken when calling esp_intr_alloc() from a task which is not pinned to a core. During task switching, these tasks can migrate between cores. Therefore it is impossible to tell which CPU the interrupt is allocated on, which makes it difficult to free the interrupt handle and may also cause debugging difficulties. It is advised to use xTaskCreatePinnedToCore() with a specific CoreID argument to create tasks that will allocate interrupts. In the case of internal interrupt sources, this is required.
0 commit comments