doc: Add notes that vTaskStartScheduler() is called during startup

Closes https://github.com/espressif/esp-idf/issues/1457
This commit is contained in:
Angus Gratton
2021-03-12 11:55:05 +11:00
parent 8a39b5237d
commit 275743ab1c
3 changed files with 11 additions and 1 deletions

View File

@@ -1203,6 +1203,10 @@ BaseType_t xTaskResumeFromISR( TaskHandle_t xTaskToResume ) PRIVILEGED_FUNCTION;
/** /**
* Starts the real time kernel tick processing. * Starts the real time kernel tick processing.
* *
* NOTE: In ESP-IDF the scheduler is started automatically during
* application startup, vTaskStartScheduler() should not be called from
* ESP-IDF applications.
*
* After calling the kernel has control over which tasks are executed and when. * After calling the kernel has control over which tasks are executed and when.
* *
* See the demo application file main.c for an example of creating * See the demo application file main.c for an example of creating

View File

@@ -21,7 +21,7 @@ found via https://www.freertos.org/a00106.html
For information regarding features that are exclusive to ESP-IDF FreeRTOS, For information regarding features that are exclusive to ESP-IDF FreeRTOS,
see :doc:`ESP-IDF FreeRTOS Additions<../api-reference/system/freertos_additions>`. see :doc:`ESP-IDF FreeRTOS Additions<../api-reference/system/freertos_additions>`.
.. only:: esp32 .. only:: not CONFIG_FREERTOS_UNICORE
:ref:`tasks-and-task-creation`: Use :cpp:func:`xTaskCreatePinnedToCore` or :ref:`tasks-and-task-creation`: Use :cpp:func:`xTaskCreatePinnedToCore` or
:cpp:func:`xTaskCreateStaticPinnedToCore` to create tasks in ESP-IDF FreeRTOS. The :cpp:func:`xTaskCreateStaticPinnedToCore` to create tasks in ESP-IDF FreeRTOS. The
@@ -53,6 +53,8 @@ see :doc:`ESP-IDF FreeRTOS Additions<../api-reference/system/freertos_additions>
unaffected. If the other core attemps to take same mutex, it will spin until unaffected. If the other core attemps to take same mutex, it will spin until
the calling core has released the mutex by exiting the critical section. the calling core has released the mutex by exiting the critical section.
.. only:: esp32
:ref:`floating-points`: The ESP32 supports hardware acceleration of single :ref:`floating-points`: The ESP32 supports hardware acceleration of single
precision floating point arithmetic (``float``). However the use of hardware precision floating point arithmetic (``float``). However the use of hardware
acceleration leads to some behavioral restrictions in ESP-IDF FreeRTOS. acceleration leads to some behavioral restrictions in ESP-IDF FreeRTOS.
@@ -70,6 +72,9 @@ set in the project configuration (``idf.py menuconfig``) such as running ESP-IDF
Unicore (single core) Mode, or configuring the number of Thread Local Storage Pointers Unicore (single core) Mode, or configuring the number of Thread Local Storage Pointers
each task will have. each task will have.
It is not necessary to manually start the FreeRTOS scheduler by calling :cpp:func:`vTaskStartScheduler`. In ESP-IDF the
scheduler is started by the :doc:`startup` and is already running when the ``app_main`` function is called (see :ref:`app-main-task` for details).
.. _tasks-and-task-creation: .. _tasks-and-task-creation:
Tasks and Task Creation Tasks and Task Creation

View File

@@ -94,6 +94,7 @@ There are some possible issues with placement in IRAM, that may cause problems w
Note that knowing which data should be marked with ``DRAM_ATTR`` can be hard, the compiler will sometimes recognize that a variable or expression is constant (even if it is not marked ``const``) and optimize it into flash, unless it is marked with ``DRAM_ATTR``. Note that knowing which data should be marked with ``DRAM_ATTR`` can be hard, the compiler will sometimes recognize that a variable or expression is constant (even if it is not marked ``const``) and optimize it into flash, unless it is marked with ``DRAM_ATTR``.
* GCC optimizations that automatically generate jump tables or switch/case lookup tables place these tables in flash. There are two possible ways to resolve this issue: * GCC optimizations that automatically generate jump tables or switch/case lookup tables place these tables in flash. There are two possible ways to resolve this issue:
- Use a :doc:`linker script fragment <linker-script-generation>` to mark the entire source file as ``noflash`` - Use a :doc:`linker script fragment <linker-script-generation>` to mark the entire source file as ``noflash``
- Pass specific flags to the compiler to disable these optimizations in the relevant source files. For CMake, place the following in the component CMakeLists.txt file: - Pass specific flags to the compiler to disable these optimizations in the relevant source files. For CMake, place the following in the component CMakeLists.txt file: