Freertos Documentation Pdf
Kathleen Denson
FreeRTOS is an open source RTOS (real-time operating system) kernel that is integrated into ESP-IDF as a component. Thus, all ESP-IDF applications and many ESP-IDF components are written based on FreeRTOS. The FreeRTOS kernel is ported to all architectures (i.e., Xtensa and RISC-V) available of ESP chips.
Furthermore, ESP-IDF provides different implementations of FreeRTOS in order to support SMP (Symmetric Multiprocessing) on multi-core ESP chips. This document provides an overview of the FreeRTOS component, the different FreeRTOS implementations offered by ESP-IDF, and the common aspects across all implementations.
The official FreeRTOS (henceforth referred to as Vanilla FreeRTOS) is a single-core RTOS. In order to support the various multi-core ESP targets, ESP-IDF supports different FreeRTOS implementations as listed below:
ESP-IDF FreeRTOS is a FreeRTOS implementation based on Vanilla FreeRTOS v10.5.1, but contains significant modifications to support SMP. ESP-IDF FreeRTOS only supports two cores at most (i.e., dual core SMP), but is more optimized for this scenario by design. For more details regarding ESP-IDF FreeRTOS and its modifications, please refer to the FreeRTOS (IDF) document.
Amazon SMP FreeRTOS is an SMP implementation of FreeRTOS that is officially supported by Amazon. Amazon SMP FreeRTOS is able to support N-cores (i.e., more than two cores). Amazon SMP FreeRTOS can be enabled via the CONFIG_FREERTOS_SMP option. For more details regarding Amazon SMP FreeRTOS, please refer to the official Amazon SMP FreeRTOS documentation.
Vanilla FreeRTOS requires that ports and applications configure the kernel by adding various #define config... macro definitions to the FreeRTOSConfig.h header file. Vanilla FreeRTOS supports a list of kernel configuration options which allow various kernel behaviors and features to be enabled or disabled.
However, for all FreeRTOS ports in ESP-IDF, the FreeRTOSConfig.h header file is considered private and must not be modified by users. A large number of kernel configuration options in FreeRTOSConfig.h are hard-coded as they are either required/not supported by ESP-IDF. All kernel configuration options that are configurable by the user are exposed via menuconfig under Component Config/FreeRTOS/Kernel.
CONFIG_FREERTOS_UNICORE runs FreeRTOS only on Core 0. Note that this is not equivalent to running Vanilla FreeRTOS. Furthermore, this option may affect behavior of components other than freertos. For more details regarding the effects of running FreeRTOS on a single core, refer to Single-Core Mode (if using ESP-IDF FreeRTOS) or the official Amazon SMP FreeRTOS documentation. Alternatively, users can also search for occurrences of CONFIG_FREERTOS_UNICORE in the ESP-IDF components.
All other FreeRTOS related configuration options that are not part of the kernel configuration are exposed via menuconfig under Component Config/FreeRTOS/Port. These options configure aspects such as:
Unlike Vanilla FreeRTOS, users of FreeRTOS in ESP-IDF must never call vTaskStartScheduler() and vTaskEndScheduler(). Instead, ESP-IDF starts FreeRTOS automatically. Users must define a void app_main(void) function which acts as the entry point for user's application and is automatically invoked on ESP-IDF startup.
Vanilla FreeRTOS provides its own selection of heap implementations. However, ESP-IDF already implements its own heap (see Heap Memory Allocation), thus ESP-IDF does not make use of the heap implementations provided by Vanilla FreeRTOS. All FreeRTOS ports in ESP-IDF map FreeRTOS memory allocation or free calls (e.g., pvPortMalloc() and pvPortFree()) to ESP-IDF heap API (i.e., heap_caps_malloc() and heap_caps_free()). However, the FreeRTOS ports ensure that all dynamic memory allocated by FreeRTOS is placed in internal memory.
2. with CCSv5.1 when you create a new project it seems to generate an empty 'main.c'.
this conflicts with the 'main()' function in HalCoGen's sys_main.c.
I just excluded sys_main.c from the ccs build to get around this.
All the above issues/confusions are caused due to the help file, ( Old snapshots were not replaced).
The help file is been fixed already and you will not face any of above issue with version 3.00.00 that is planned for Mid Dec 2011.
If the help files are already fixed, then maybe you can make them available as an update or post them somewhere, rather than wait to the 15th. This is a case where the functionality is already released just not documented.
Thanks Anthony,
For RM and TMS570LS3x family we have seperate RTOS blinky example in the HALCoGen Install folder ( ..\Texas Instruments\Hercules\HALCoGen\v2.11\examples\RM48x )..
I agree it would be better with latest help file, This will be resolved as early as possible.
We will look for a better place to put the documentation update, Also will see whether an autoupdate can be rolled out with documentaiton update.
Best Regards
Prathap
So, if the only queue-writing task is running on Core 0 and the only queue-reading task is running on Core 1, must the queue be locked with a common mutex while each of these tasks is doing its thing?
I couldn't find an explicit comment in the docs that you don't need mutexes, but this thread answers it, for example: Question: Safe to send structures to a queue from multiple tasks without mutex? - FreeRTOS
Note that having one task that reads and another that writes in general does require some form of synchronization, if not locks or mutexes then at least atomic variables.
In this case, the FreeRTOS kernel just handles it for you.
OK, thanks. That's pretty much what I figured. My only doubt was because the "vanilla FreeRTOS" documentation seems to assume a single-core environment while ESP32 has two cores. Good to know that the ESP32 port takes this into account with regard to queue management.
Synchronization in a single-core system with preemptive scheduling isn't all that different from a multiprocessor environment, in both cases, you need mutexes/critical sections and atomic variables (although you don't need actual memory barriers on a single core, you still need to prevent the compiler from reordering your reads/writes to shared data). There are of course some differences, especially if you're writing the kernel/scheduler, but from user space it doesn't matter too much in most cases.
A final remark: given that the FreeRTOS Queue uses locks to allow any number of threads to access the queue at the same time, you might want to use a lock-free alternative if you have a single producer and a single consumer. This is important if performance of the queue is an issue, locks can slow things down significantly. You could Google for "SPSC queue" or "lock-free queue", for example. IIRC, Boost has one, and so does Folly.
Today I need to work with heap4.c Memory Management Scheme and I need to change a lot of thing in the original FreeRTOS embedded in the Arduino Framework. Then I think that it will be better in the near future, to work with the FreeRTOS download from FreeRTOS.org.
You can just start calling into FreeRTOS functions directly without having to start FreeRTOS, because the Arduino core already starts it for you. In fact, it runs setup() and loop() already in a FreeRTOS task.
The reason that I am looking for a way to install FreeRTOS, it is the version that comes with Adafruit_nRF52_Arduino is old in Memory Management, only one heap treatment: Adafruit_nRF52_Arduino/cores/nRF5/freertos at master adafruit/Adafruit_nRF52_Arduino GitHub
The FreeRTOS kernel was originally developed by Richard Barry around 2003, and was later developed and maintained by Richard's company, Real Time Engineers Ltd. FreeRTOS was a runaway success, and in 2017 Real Time Engineers Ltd. passed stewardship of the FreeRTOS project to Amazon Web Services (AWS). Richard continues to work on FreeRTOS as part of an AWS team.
Note about FreeRTOS+: The FreeRTOS website supports an ecosystem of add-on products/components that are referred to as FreeRTOS+. This ecosystem is separate from, and unrelated to, the Xilinx ecosystem support described on this page. So, for example, the FreeRTOS+TCP product should not be confused with the Xilinx ecosystem solution that leverages FreeRTOS and lwip. Additionally, several examples of FreeRTOS+ products running on Xilinx devices exist and these should not be interpreted as examples of how Xilinx supports FreeRTOS but, rather, examples of community driven contributions.
Standalone library consist of boot code, vectors, basic IO APIs, light weight print functions, MMU/MPU APIs. and cache APIs Driver deals with the hardware through direct hardware interface implemented in standalone Library. Direct hardware interface is typically implemented as macros and constants, and it is designed such that developer can create a small applications or create a custom device driver using it. FreeRTOS kernel uses few of the APIs available in Xilinx standalone library
Add new parameter entry into entry into ThirdParty/bsp/freertos_xilinx/data/freertos_xilinx.mld. Let us say you need to add new parameter "foo" of type "int" under kernel_features category, entry in mld file will be as given below,
Read newly added parameter from ThirdParty/bsp/freertos_xilinx/data/freertos_xilinx.mld and export it to FreeRTOSConfig.h in the form of constants. Code to do so can be found at end of "generate" proc inThirdParty/bsp/freertos_xilinx/data/freertos_xilinx.tcl. It needs to be added after below code snippet,
FreeRTOS applications can be debugged in the Xilinx IDE (SDK or Vitis) as normal standalone applications. So, for example, you can step through or break on task code but information about OS/task context is not provided by the IDE.
For task-aware debugging the IDE supports tracing with the System Trace Macrocell (STM) that became available as of ZynqUS+ devices (see UG1416 for details). The results of doing an STM trace will provide detailed task information in a manner that is less invasive, and therefore preferred over, using traditional FreeRTOS trace hooks. For architectures that do not have the STM (e.g. Zynq-7000 and MicroBlaze) 3rd party tools can be used to do task-aware debugging. For example, users have reported success with Percepio Tracealyzer for both Zynq-7000 and MicroBlaze using the FreeRTOS trace hooks.
64591212e2