Freertos Aws Ota

0 views

Skip to first unread message

Jonelle Rycroft

unread,

Aug 3, 2024, 4:18:04 PM8/3/24

to hunringlighmas

The reason I'm asking this is because I am currently looking at freertos and it has an option called ENABLE_FPU, does this mean that I have to enable this to use the FPU at all even if I dont use freertos or does it just let freertos use the FPU and if so, if I am using freertos should I enable it.

The FPU is a coprocessor, it must be explicitly enabled in code, typically in Reset_Handler or SystemInit(), otherwise the execution of FPU instructions, including push/pop at function prologue/epilogue code (ie float code in main() ), will cause a Hard Fault

You probably don't need to tell FreeRTOS you're using it if you have everything in a single thread of execution, and the context doesn't need preserving, but if you don't think you can maintain containment of the code, or you pull in other libraries or code with different expectations, probably safer to have the RTOS be aware.

Thank you that was extremely helpful, I've had a project I've been working on that involves a lot of floating point math so I just saw this config setting that said enable fpu so I thought maybe my project was just doing it in software instead of using the fpu, thus running slower but it seem in cubeide that it is enabled by default. This has cleared up a lot for me.

Thank you, just trying to learn RTOS at the moment and saw this config setting and thought that one of my other projects that didnt use RTOS maybe wasnt using the FPU but it is enabled by default in the project properties.

Did you figure out what those define mean ? As for I am aware , The RTOS compilation fails whenever I shift the compiler flag to not use FPU. So I assumed stm adoption of FreeRTOS has some part of code dependent on FPU.

Developed in partnership with the world's leading chip companies over a 15-year period, and now downloaded every 170 seconds, FreeRTOS is a market-leading real-time operating system (RTOS) for microcontrollers and small microprocessors. Distributed freely under the MIT open source license, FreeRTOS includes a kernel and a growing set of libraries suitable for use across all industry sectors. FreeRTOS is built with an emphasis on reliability and ease of use.

We also welcome contributions to the FreeRTOS documentation (FreeRTOS User Guide, FreeRTOS Porting Guide, and FreeRTOS Qualification Guide). To view the markdown source for the documentation, see -freertos-docs. It's released under the Creative Commons (CC BY-ND) license.

Individual libraries use x.y.z style version numbers, similar to semantic versioning. x is the major version number, y the minor version number, and starting from 2022, z is a patch number. Before 2022, z was a point release number, which required the first LTS libraries to have a patch number of the form "x.y.z LTS Patch 2".

Library packages use yyyymm.x style date stamp version numbers. yyyy is the year, mm the month, and x an optional sequence number showing the release order within the month. In the case of the LTS package, x is a sequential patch number for that LTS release. The individual libraries contained in a package are whatever the latest version of that library was on that date. For the LTS package, it's the latest patch version of the LTS libraries originally released as an LTS version on that date.

FreeRTOS Long Term Support (LTS) releases receive security and critical bug fixes (should any be necessary) for at least two years following their release. With this ongoing maintenance, you can incorporate bug fixes throughout a development and deployment cycle without the expensive disruption of updating to new major versions of FreeRTOS libraries.

With FreeRTOS LTS, you get the complete set of libraries needed to build secure connected IoT and embedded products. LTS helps reduce maintenance and testing costs associated with updating libraries on your devices already in production.

FreeRTOS LTS includes the FreeRTOS kernel and IoT libraries: FreeRTOS+TCP, coreMQTT, coreHTTP, corePKCS11, coreJSON, AWS IoT OTA, AWS IoT Jobs, AWS IoT Device Defender, and AWS IoT Device Shadow. For more information, see the FreeRTOS LTS libraries.

AWS also offers FreeRTOS Extended Maintenance Plan (EMP), which provides security patches and critical bug fixes on your chosen FreeRTOS Long Term Support (LTS) version for up to ten additional years. With FreeRTOS EMP, your FreeRTOS based long-lived devices can rely on a version that has feature stability and receives security updates for years. You receive timely notifications of upcoming patches on FreeRTOS libraries, so you can plan the deployment of security patches on your Internet of Things (IoT) devices.

While package repositories contain multiple libraries, they don't contain copies of those libraries. Instead, package repositories reference the libraries they contain as git submodules. Using submodules ensures that there is a single source of truth for each individual library.

The individual library git repositories are split between two GitHub organizations. Repositories containing FreeRTOS specific libraries (such as FreeRTOS+TCP) or generic libraries (such as coreMQTT, which is cloud agnostic because it works with any MQTT broker) are in the FreeRTOS GitHub organization. Repositories containing AWS IoT specific libraries (such as the AWS IoT over-the-air update client) are in the AWS GitHub organization. The following diagram explains the structure.

You start development by downloading FreeRTOS. You unzip the package and import it into your IDE. You can then develop an application on your selected hardware platform and manufacture and deploy these devices using the development process appropriate for your device. Deployed devices can connect to the AWS IoT service or AWS IoT Greengrass as part of a complete IoT solution.

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.

A couple of years ago, my company contracted with an agency to create firmware for our device to talk to IoT services. The device is based on an ESP32 chip and I know the firmware developer used Amazon FreeRTOS. The agency is no longer available, but I have their source code and I need to be able to build it so I can modify it. Unfortunately, firmware is not my ususal area of expertise.

When I reach step 3c under MacOS, the script runs for a while but then crashes with a very long error message. I believe the root cause of the problem is "Error compiing Cython file". Actually there are several such errors. The first one reads, "Cannot convert 'ev_watcher *' to Python object".