User Guide

(1)

FreeRTOS

User Guide

(2)

FreeRTOS: User Guide

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be aﬃliated with, connected to, or sponsored by Amazon.

(3)

What is FreeRTOS?

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.

FreeRTOS includes libraries for connectivity, security, and over-the-air (OTA) updates. FreeRTOS also includes demo applications that show FreeRTOS features on qualiﬁed boards.

FreeRTOS is an open-source project. You can download the source code, contribute changes or enhancements, or report issues on the GitHub site at https://github.com/FreeRTOS/FreeRTOS.

We release FreeRTOS code under the MIT open source license, so you can use it in commercial and personal projects.

We also welcome contributions to the FreeRTOS documentation (FreeRTOS User Guide, FreeRTOS Porting Guide, and FreeRTOS Qualiﬁcation Guide). To view the markdown source for the documentation, see https://github.com/awsdocs/aws-freertos-docs. It's released under the Creative Commons (CC BY-ND) license.

Downloading FreeRTOS source code

Download the latest FreeRTOS and Long Term Support (LTS) packages from the Downloads page on freertos.org.

FreeRTOS versioning

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 ﬁrst 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

FreeRTOS Long Term Support (LTS) releases receive security and critical bug ﬁxes (should any be necessary) for at least two years following their release. With this ongoing maintenance, you can

incorporate bug ﬁxes 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.

(9)

FreeRTOS Extended Maintenance Plan

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.

FreeRTOS Extended Maintenance Plan

AWS also oﬀers FreeRTOS Extended Maintenance Plan (EMP), which provides security patches and critical bug ﬁxes 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 notiﬁcations of upcoming patches on FreeRTOS libraries, so you can plan the deployment of security patches on your Internet of Things (IoT) devices.

To learn more about FreeRTOS EMP, see the Features page.

FreeRTOS architecture

FreeRTOS contains two types of repositories, single library repositories and package repositories. Each single library repository contains the source code for one library without any build projects or examples.

Package repositories contain multiple libraries, and can contain preconﬁgured projects that demonstrate the library’s use.

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 speciﬁc 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 speciﬁc libraries (such as the AWS IoT over-the-air update client) are in the AWS GitHub organization. The following diagram explains the structure.

FreeRTOS-qualiﬁed hardware platforms

The following hardware platforms are qualiﬁed for FreeRTOS:

2

(10)

Development workﬂow

• ATECC608A Zero Touch Provisioning Kit for AWS IoT

• Cypress CYW943907AEVAL1F Development Kit

• Cypress CY8CKIT-064S0S2-4343W Kit

• Espressif ESP32-DevKitC

• Espressif ESP-WROVER-KIT

• Espressif ESP-WROOM-32SE

• Espressif ESP32-S2-Saola-1

• Inﬁneon XMC4800 IoT Connectivity Kit

• Marvell MW320 AWS IoT Starter Kit

• MediaTek MT7697Hx Development Kit

• Microchip Curiosity PIC32MZEF Bundle

• Nordic nRF52840-DK

• NuMaker-IoT-M487

• NXP LPC54018 IoT Module

• OPTIGA Trust X Security Solution

• Renesas RX65N RSK IoT Module

• STMicroelectronicsSTM32L4 Discovery Kit IoT Node

• Texas Instruments CC3220SF-LAUNCHXL

• Microsoft Windows 7 or later, with at least a dual core and a hard-wired Ethernet connection

• Xilinx Avnet MicroZed Industrial IoT Kit

Qualiﬁed devices are also listed on the AWS Partner Device Catalog.

For information about qualifying a new device, see the FreeRTOS Qualiﬁcation Guide.

Development workﬂow

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.

(11)

Additional resources

These resources might be helpful to you.

• For additional FreeRTOS Documentation, see freertos.org.

• For questions about FreeRTOS for the FreeRTOS engineering team, you can open an issue on the FreeRTOS GitHub page.

• For technical questions about FreeRTOS, see the FreeRTOS Community Forums.

• For more information about connecting devices to AWS IoT, see Device Provisioning in the AWS IoT Core Developer Guide.

• For technical support for AWS, see AWS Support Center.

• For questions about AWS billing, account services, events, abuse, or other issues with AWS, see the Contact Us page.

4

(12)

FreeRTOS kernel scheduler

FreeRTOS kernel fundamentals

The FreeRTOS kernel is a real-time operating system that supports numerous architectures. It is ideal for building embedded microcontroller applications. It provides:

• A multitasking scheduler.

• Multiple memory allocation options (including the ability to create completely statically-allocated systems).

• Intertask coordination primitives, including task notiﬁcations, message queues, multiple types of semaphore, and stream and message buﬀers.

• Support for symmetric multiprocessing (SMP) on multi-core microcontrollers.

The FreeRTOS kernel never performs non-deterministic operations, such as walking a linked list, inside a critical section or interrupt. The FreeRTOS kernel includes an eﬃcient software timer implementation that does not use any CPU time unless a timer needs servicing. Blocked tasks do not require time- consuming periodic servicing. Direct-to-task notiﬁcations allow fast task signaling, with practically no RAM overhead. They can be used in most intertask and interrupt-to-task signaling scenarios.

The FreeRTOS kernel is designed to be small, simple, and easy to use. A typical RTOS kernel binary image is in the range of 4000 to 9000 bytes.

For the most up-to-date documentation about the FreeRTOS kernel, see FreeRTOS.org. FreeRTOS.org oﬀers a number of detailed tutorials and guides about using the FreeRTOS kernel, including a Quick Start Guide and the more in-depth Mastering the FreeRTOS Real Time Kernel.

FreeRTOS kernel scheduler

An embedded application that uses an RTOS can be structured as a set of independent tasks. Each task executes within its own context, with no dependency on other tasks. Only one task in the application is running at any point in time. The real-time RTOS scheduler determines when each task should run.

Each task is provided with its own stack. When a task is swapped out so another task can run, the task’s execution context is saved to the task stack so it can be restored when the same task is later swapped back in to resume its execution.

To provide deterministic real-time behavior, the FreeRTOS tasks scheduler allows tasks to be assigned strict priorities. RTOS ensures the highest priority task that is able to execute is given processing time. This requires sharing processing time between tasks of equal priority if they are ready to run simultaneously. FreeRTOS also creates an idle task that executes only when no other tasks are ready to run.

Memory management

This section provides information about kernel memory allocation and application memory management.

Kernel memory allocation

The RTOS kernel needs RAM each time a task, queue, or other RTOS object is created. The RAM can be allocated:

(13)

Application memory management

• Statically at compile time.

• Dynamically from the RTOS heap by the RTOS API object creation functions.

When RTOS objects are created dynamically, using the standard C library malloc() and free() functions is not always appropriate for a number of reasons:

• They might not be available on embedded systems.

• They take up valuable code space.

• They are not typically thread-safe.

• They are not deterministic.

For these reasons, FreeRTOS keeps the memory allocation API in its portable layer. The portable layer is outside of the source ﬁles that implement the core RTOS functionality, so you can provide an application-speciﬁc implementation appropriate for the real-time system you're developing. When the RTOS kernel requires RAM, it calls pvPortMalloc() instead of malloc()(). When RAM is being freed, the RTOS kernel calls vPortFree() instead of free().

Application memory management

When applications need memory, they can allocate it from the FreeRTOS heap. FreeRTOS oﬀers several heap management schemes that range in complexity and features. You can also provide your own heap implementation.

The FreeRTOS kernel includes ﬁve heap implementations:

heap_1

Is the simplest implementation. Does not permit memory to be freed.

heap_2

Permits memory to be freed, but not does coalesce adjacent free blocks.

heap_3

Wraps the standard malloc() and free() for thread safety.

heap_4

Coalesces adjacent free blocks to avoid fragmentation. Includes an absolute address placement option.

heap_5

Is similar to heap_4. Can span the heap across multiple, non-adjacent memory areas.

Intertask coordination

This section contains information about FreeRTOS primitives.

Queues

Queues are the primary form of intertask communication. They can be used to send messages between tasks and between interrupts and tasks. In most cases, they are used as thread-safe, First In First Out (FIFO) buﬀers with new data being sent to the back of the queue. (Data can also be sent to the front

6

(14)

Semaphores and mutexes

of the queue.) Messages are sent through queues by copy, meaning the data (which can be a pointer to larger buﬀers) is itself copied into the queue rather than simply storing a reference to the data.

Queue APIs permit a block time to be speciﬁed. When a task attempts to read from an empty queue, the task is placed into the Blocked state until data becomes available on the queue or the block time elapses.

Tasks in the Blocked state do not consume any CPU time, allowing other tasks to run. Similarly, when a task attempts to write to a full queue, the task is placed into the Blocked state until space becomes available in the queue or the block time elapses. If more than one task blocks on the same queue, the task with the highest priority is unblocked ﬁrst.

Other FreeRTOS primitives, such as direct-to-task notifications and stream and message buffers, offer lightweight alternatives to queues in many common design scenarios.

Semaphores and mutexes

The FreeRTOS kernel provides binary semaphores, counting semaphores, and mutexes for both mutual exclusion and synchronization purposes.

Binary semaphores can only have two values. They are a good choice for implementing synchronization (either between tasks or between tasks and an interrupt). Counting semaphores take more than two values. They allow many tasks to share resources or perform more complex synchronization operations.

Mutexes are binary semaphores that include a priority inheritance mechanism. This means that if a high priority task blocks while attempting to obtain a mutex that is currently held by a lower priority task, the priority of the task holding the token is temporarily raised to that of the blocking task. This mechanism is designed to ensure the higher priority task is kept in the Blocked state for the shortest time possible, to minimize the priority inversion that has occurred.

Direct-to-task notiﬁcations

Task notifications allow tasks to interact with other tasks, and to synchronize with interrupt service routines (ISRs), without the need for a separate communication object like a semaphore. Each RTOS task has a 32-bit notification value that is used to store the content of the notification, if any. An RTOS task notification is an event sent directly to a task that can unblock the receiving task and optionally update the receiving task's notification value.

RTOS task notiﬁcations can be used as a faster and lightweight alternative to binary and counting semaphores and, in some cases, queues. Task notiﬁcations have both speed and RAM footprint

advantages over other FreeRTOS features that can be used to perform equivalent functionality. However, task notiﬁcations can only be used when there is only one task that can be the recipient of the event.

Stream buﬀers

Stream buffers allow a stream of bytes to be passed from an interrupt service routine to a task, or from one task to another. A byte stream can be of arbitrary length and does not necessarily have a beginning or an end. Any number of bytes can be written at one time, and any number of bytes can be read at one time. You enable stream buffer functionality by including the stream_buffer.c source file in your project.

Stream buffers assume there is only one task or interrupt that writes to the buffer (the writer), and only one task or interrupt that reads from the buffer (the reader). It is safe for the writer and reader to be different tasks or interrupt service routines, but it is not safe to have multiple writers or readers.

The stream buffer implementation uses direct-to-task notifications. Therefore, calling a stream buffer API that places the calling task into the Blocked state can change the calling task's notification state and value.

(15)

Message buﬀers

Sending data

xStreamBufferSend() is used to send data to a stream buﬀer in a task.

xStreamBufferSendFromISR() is used to send data to a stream buﬀer in an interrupt service routine (ISR).

xStreamBufferSend() allows a block time to be specified. If xStreamBufferSend() is called with a non-zero block time to write to a stream buffer and the buffer is full, the task is placed into the Blocked state until space becomes available or the block time expires.

sbSEND_COMPLETED() and sbSEND_COMPLETED_FROM_ISR() are macros that are called (internally, by the FreeRTOS API) when data is written to a stream buffer. It takes the handle of the stream buffer that was updated. Both of these macros check to see if there is a task blocked on the stream buffer waiting for data, and if so, removes the task from the Blocked state.

You can change this default behavior by providing your own implementation of sbSEND_COMPLETED() in FreeRTOSConfig.h (p. 10). This is useful when a stream buﬀer is used to pass data between cores on a multicore processor. In that scenario, sbSEND_COMPLETED() can be implemented to generate an interrupt in the other CPU core, and the interrupt's service routine can then use the xStreamBufferSendCompletedFromISR() API to check, and if necessary unblock, a task that is waiting for the data.

Receiving data

xStreamBufferReceive() is used to read data from a stream buﬀer in a task.

xStreamBufferReceiveFromISR() is used to read data from a stream buﬀer in an interrupt service routine (ISR).

xStreamBufferReceive() allows a block time to be specified. If xStreamBufferReceive() is called with a non-zero block time to read from a stream buffer and the buffer is empty, the task is placed into the Blocked state until either a specified amount of data becomes available in the stream buffer, or the block time expires.

The amount of data that must be in the stream buffer before a task is unblocked is called the stream buffer's trigger level. A task blocked with a trigger level of 10 is unblocked when at least 10 bytes are written to the buffer or the task's block time expires. If a reading task's block time expires before the trigger level is reached, the task receives any data written to the buffer. The trigger level of a task must be set to a value between 1 and the size of the stream buffer. The trigger level of a stream buffer is set when xStreamBufferCreate() is called. It can be changed by calling xStreamBufferSetTriggerLevel().

sbRECEIVE_COMPLETED() and sbRECEIVE_COMPLETED_FROM_ISR() are macros that are called (internally, by the FreeRTOS API) when data is read from a stream buffer. The macros check to see if there is a task blocked on the stream buffer waiting for space to become available within the buffer, and if so, they remove the task from the Blocked state. You can change the default behavior of sbRECEIVE_COMPLETED() by providing an alternative implementation in FreeRTOSConfig.h (p. 10).

Message buﬀers

Message buffers allow variable-length discrete messages to be passed from an interrupt service routine to a task, or from one task to another. For example, messages of length 10, 20, and 123 bytes can all be written to, and read from, the same message buffer. A 10-byte message can only be read as a 10-byte message, not as individual bytes. Message buffers are built on top of stream buffer implementation. you can enable message buffer functionality by including the stream_buffer.c source file in your project.

Message buffers assume there is only one task or interrupt that writes to the buffer (the writer), and only one task or interrupt that reads from the buffer (the reader). It is safe for the writer and reader to be different tasks or interrupt service routines, but it is not safe to have multiple writers or readers.

8

(16)

Symmetric multiprocessing (SMP) support

The message buffer implementation uses direct-to-task notifications. Therefore, calling a stream buffer API that places the calling task into the Blocked state can change the calling task's notification state and value.

To enable message buffers to handle variable-sized messages, the length of each message is written into the message buffer before the message itself. The length is stored in a variable of type size_t, which is typically 4 bytes on a 32-byte architecture. Therefore, writing a 10-byte message into a message buffer actually consumes 14 bytes of buffer space. Likewise, writing a 100-byte message into a message buffer actually uses 104 bytes of buffer space.

Sending data

xMessageBufferSend() is used to send data to a message buﬀer from a task.

xMessageBufferSendFromISR() is used to send data to a message buﬀer from an interrupt service routine (ISR).

xMessageBufferSend() allows a block time to be specified. If xMessageBufferSend() is called with a non-zero block time to write to a message buffer and the buffer is full, the task is placed into the Blocked state until either space becomes available in the message buffer, or the block time expires.

sbSEND_COMPLETED() and sbSEND_COMPLETED_FROM_ISR() are macros that are called (internally, by the FreeRTOS API) when data is written to a stream buffer. It takes a single parameter, which is the handle of the stream buffer that was updated. Both of these macros check to see if there is a task blocked on the stream buffer waiting for data, and if so, they remove the task from the Blocked state.

You can change this default behavior by providing your own implementation of sbSEND_COMPLETED() in FreeRTOSConfig.h (p. 10). This is useful when a stream buﬀer is used to pass data between cores on a multicore processor. In that scenario, sbSEND_COMPLETED() can be implemented to generate an interrupt in the other CPU core, and the interrupt's service routine can then use the xStreamBufferSendCompletedFromISR() API to check, and if necessary unblock, a task that was waiting for the data.

Receiving data

xMessageBufferReceive() is used to read data from a message buﬀer in a task.

xMessageBufferReceiveFromISR() is used to read data from a message buﬀer in an interrupt service routine (ISR). xMessageBufferReceive() allows a block time to be speciﬁed. If

xMessageBufferReceive() is called with a non-zero block time to read from a message buﬀer and the buﬀer is empty, the task is placed into the Blocked state until either data becomes available, or the block time expires.

sbRECEIVE_COMPLETED() and sbRECEIVE_COMPLETED_FROM_ISR() are macros that are called (internally, by the FreeRTOS API) when data is read from a stream buffer. The macros check to see if there is a task blocked on the stream buffer waiting for space to become available within the buffer, and if so, they remove the task from the Blocked state. You can change the default behavior of sbRECEIVE_COMPLETED() by providing an alternative implementation in FreeRTOSConfig.h (p. 10).

Symmetric multiprocessing (SMP) support

SMP support in the FreeRTOS Kernel enables one instance of the FreeRTOS kernel to schedule tasks across multiple identical processor cores. The core architectures must be identical and share the same memory.

(17)

Modifying applications to use the FreeRTOS-SMP kernel

The FreeRTOS API remains substantially the same between single-core and SMP versions, except for these additional APIs. Therefore, an application written for the FreeRTOS single-core version should compile with the SMP version with minimal to no eﬀort. However, there might be some functional issues, because some assumptions that were true for single-core applications might no longer be true for multi- core applications.

One common assumption is that a lower priority task can't run while a higher priority task is running.

While this was true on a single-core system, it's no longer true for multi-core systems because multiple tasks can run simultaneously. If the application relies on relative task priorities to provide mutual exclusion, it might observe unexpected results in a multi-core environment.

One other common assumption is that ISRs can't run simultaneously with each other or with other tasks.

This is no longer true in a multi-core environment. The application writer needs to ensure proper mutual exclusion while accessing data shared between tasks and ISRs.

Software timers

A software timer allows a function to be executed at a set time in the future. The function executed by the timer is called the timer’s callback function. The time between a timer being started and its callback function being executed is called the timer’s period. The FreeRTOS kernel provides an eﬃcient software timer implementation because:

• It does not execute timer callback functions from an interrupt context.

• It does not consume any processing time unless a timer has actually expired.

• It does not add any processing overhead to the tick interrupt.

• It does not walk any link list structures while interrupts are disabled.

Low power support

Like most embedded operating systems, the FreeRTOS kernel uses a hardware timer to generate periodic tick interrupts, which are used to measure time. The power saving of regular hardware timer implementations is limited by the necessity to periodically exit and then re-enter the low power state to process tick interrupts. If the frequency of the tick interrupt is too high, the energy and time consumed entering and exiting a low power state for every tick outweighs any potential power-saving gains for all but the lightest power-saving modes.

To address this limitation, FreeRTOS includes a tickless timer mode for low-power applications. The FreeRTOS tickless idle mode stops the periodic tick interrupt during idle periods (periods when there are no application tasks that are able to execute), and then makes a correcting adjustment to the RTOS tick count value when the tick interrupt is restarted. Stopping the tick interrupt allows the microcontroller to remain in a deep power-saving state until either an interrupt occurs, or it is time for the RTOS kernel to transition a task into the ready state.

Kernel conﬁguration

You can conﬁgure the FreeRTOS kernel for a speciﬁc board and application with the

FreeRTOSConfig.h header ﬁle. Every application built on the kernel must have a FreeRTOSConfig.h

10

(18)

FreeRTOSConfig.h

header ﬁle in its preprocessor include path. FreeRTOSConfig.h is application-speciﬁc and should be placed under an application directory, and not in one of the FreeRTOS kernel source code directories.

The FreeRTOSConfig.h ﬁles for the FreeRTOS demo and test applications are located at freertos/

vendors/vendor/boards/board/aws_demos/config_files/FreeRTOSConfig.h and

freertos/vendors/vendor/boards/board/aws_tests/config_files/FreeRTOSConfig.h.

For a list of the available conﬁguration parameters to specify in FreeRTOSConfig.h, see FreeRTOS.org.

(19)

Predeﬁned FreeRTOS conﬁgurations

FreeRTOS console

In the FreeRTOS console, you can conﬁgure and download a package that contains everything you need to write an application for your microcontroller-based devices:

• The FreeRTOS kernel.

• FreeRTOS libraries.

• Platform support libraries.

• Hardware drivers.

You can download a package with a predefined configuration, or you can create your own configuration by selecting your hardware platform and the libraries required for your application. These configurations are saved in AWS and are available for download at any time.

Predeﬁned FreeRTOS conﬁgurations

The predefined configurations make it possible for you to get started quickly with the supported use cases without thinking about which libraries are required. To use a predefined configuration, browse to the FreeRTOS console, find the configuration you want to use, and then choose Download.

You can also customize a predefined configuration if you want to change the FreeRTOS version, hardware platform, or libraries of the configuration. Customizing a predefined configuration creates a new custom configuration and does not overwrite the predefined configuration in the FreeRTOS console.

To create a custom configuration from a predefined configuration

1. Browse to the FreeRTOS console.

2. In the navigation pane, choose Software.

3. Under FreeRTOS Device Software, choose Conﬁgure download.

4. Choose the ellipsis (…) next to the predeﬁned conﬁguration that you want to customize, and then choose Customize.

5. On the Conﬁgure FreeRTOS Software page, choose the FreeRTOS version, hardware platform, and libraries, and give the new conﬁguration a name and a description.

6. At the bottom of the page, choose Create and download.

Custom FreeRTOS conﬁgurations

Custom conﬁgurations allow you to specify your hardware platform, integrated development platform (IDE), compiler, and only those RTOS libraries you require. This leaves more space on your devices for application code.

To create a custom conﬁguration

1. Browse to the FreeRTOS console and choose Create new.

2. Select the version of FreeRTOS that you want to use. The latest version is used by default.

3. On the New Software Conﬁguration page, choose Select a hardware platform, and choose one of the pre-qualiﬁed platforms.

12

(20)

Quick connect workﬂow

4. Choose the IDE and compiler you want use.

5. For the FreeRTOS libraries you require, choose Add Library. If you choose a library that requires another library, it is added for you. If you want to choose more libraries, choose Add another library.

6. In the Demo Projects section, enable one of the demo projects. This enables the demo in the project ﬁles.

7. In Name required, enter a name for your custom conﬁguration.

Note

Do not use any personally identiﬁable information in your custom conﬁguration name.

8. In Description, enter a description for your custom conﬁguration.

9. At the bottom of the page, choose Create and download.

To edit a custom conﬁguration

4. Choose the ellipsis (…) next to the conﬁguration you want to edit, and then choose Edit.

5. On the Conﬁgure FreeRTOS Software page, you can change your conﬁguration's FreeRTOS version, hardware platform, libraries, and description.

6. At the bottom of the page, choose Save and download.

To delete a custom conﬁguration

4. Choose the ellipsis (…) next to the conﬁguration you want to delete, and then choose Delete.

Quick connect workﬂow

The FreeRTOS console also includes the Quick Connect workflow option for all boards with predefined configurations. The Quick Connect workflow helps you configure and run FreeRTOS demo applications for AWS IoT and AWS IoT Greengrass. To get started, choose the Predefined configurations tab, find your board, choose Quick connect, and then follow the Quick Connect workflow steps.

Tagging conﬁgurations

You can apply tags to FreeRTOS configurations when you create or edit a configuration in the console. To apply tags to a configuration, navigate to the console. Under Tags, enter the name and value for the tag.

For more information about using tags to manage AWS IoT resources, see Using Tags with IAM Policies in the AWS IoT Developer Guide.

(21)

AWS IoT Device SDK for Embedded C

Note

This SDK is intended for use by experienced embedded-software developers.

The AWS IoT Device SDK for Embedded C (C-SDK) is a collection of C source ﬁles under the MIT open source license that can be used in embedded applications to securely connect IoT devices to AWS IoT Core. It includes an MQTT client, HTTP client, JSON Parser, and AWS IoT Device Shadow, AWS IoT Jobs, AWS IoT Fleet Provisioning, and AWS IoT Device Defender libraries. This SDK is distributed in source form and can be built into customer ﬁrmware along with application code, other libraries, and an operating system (OS) of your choice.

The AWS IoT Device SDK for Embedded C is generally targeted at resource constrained devices that require an optimized C language runtime. You can use the SDK on any operating system and host it on any processor type (for example, MCUs and MPUs). However, if your devices have suﬃcient memory and processing resources, we recommend that you use one of the higher order AWS IoT Device SDKs.

For more information, see the following:

• AWS IoT Device SDK for Embedded C

• AWS IoT Device SDK for Embedded C on GitHub

• AWS IoT Device SDK for Embedded C Readme

• AWS IoT Device SDK for Embedded C Samples

14

(22)

FreeRTOS demo application

Getting Started with FreeRTOS

This Getting Started with FreeRTOS tutorial shows you how to download and conﬁgure FreeRTOS on a host machine, and then compile and run a simple demo application on a qualiﬁed microcontroller board.

Throughout this tutorial, we assume that you are familiar with AWS IoT and the AWS IoT console. If not, we recommend that you complete the AWS IoT Getting Started tutorial before you continue.

Topics:

• FreeRTOS demo application (p. 15)

• First steps (p. 15)

• First steps with the console Quick Connect workﬂow (p. 21)

• Troubleshooting getting started (p. 22)

• Using CMake with FreeRTOS (p. 23)

• Developer-mode key provisioning (p. 30)

• Board-speciﬁc getting started guides (p. 32)

FreeRTOS demo application

The demo application in this tutorial is the coreMQTT Agent demo deﬁned in the freertos/demos/

coreMQTT_Agent/mqtt_agent_task.c ﬁle. It uses the coreMQTT library (p. 216) to connect to the AWS Cloud and then periodically publish messages to an MQTT topic hosted by the AWS IoT MQTT broker.

Only a single FreeRTOS demo application can run at a time. When you build a FreeRTOS demo project, the ﬁrst demo enabled in the freertos/vendors/vendor/boards/board/aws_demos/

config_files/aws_demo_config.h header ﬁle is the application that runs. For this tutorial, you do not need to enable or disable any demos. The coreMQTT Agent demo is enabled by default.

For more information about the demo applications included with FreeRTOS, see FreeRTOS demos (p. 234).

First steps

To get started using FreeRTOS with AWS IoT, you must have an AWS account, an IAM user with permission to access AWS IoT and FreeRTOS cloud services. You also must download FreeRTOS and conﬁgure your board's FreeRTOS demo project to work with AWS IoT. The following sections walk you through these requirements.

Note

• If you're using the Espressif ESP32-DevKitC, ESP-WROVER-KIT, or the ESP32-WROOM-32SE, skip these steps and go to Getting started with the Espressif ESP32-DevKitC and the ESP- WROVER-KIT (p. 48).

• If you're using the Nordic nRF52840-DK, skip these steps and go to Getting started with the Nordic nRF52840-DK (p. 109).

• To quickly connect your board to the AWS Cloud, you can follow the First steps with the console Quick Connect workﬂow (p. 21) instead of the steps shown here.

(23)

Setting up your AWS account and permissions

1.Setting up your AWS account and permissions (p. 16) 2.Registering your MCU board with AWS IoT (p. 16) 3.Downloading FreeRTOS (p. 18)

4.Conﬁguring the FreeRTOS demos (p. 19)

Setting up your AWS account and permissions

To create an AWS account, see Create and Activate an AWS Account.

To add an IAM user to your AWS account, see IAM User Guide. To grant your IAM user account access to AWS IoT and FreeRTOS, attach the following IAM policies to your IAM user account:

• AmazonFreeRTOSFullAccess

• AWSIoTFullAccess

To attach the AmazonFreeRTOSFullAccess policy to your IAM user

1. Browse to the IAM console, and from the navigation pane, choose Users.

2. Enter your user name in the search text box, and then choose it from the list.

3. Choose Add permissions.

4. Choose Attach existing policies directly.

5. In the search box, enter AmazonFreeRTOSFullAccess, choose it from the list, and then choose Next: Review.

To attach the AWSIoTFullAccess policy to your IAM user

5. In the search box, enter AWSIoTFullAccess, choose it from the list, and then choose Next: Review.

For more information about IAM and user accounts, see IAM User Guide.

For more information about policies, see IAM Permissions and Policies.

After you set up your AWS account and permissions, you can continue to Registering your MCU board with AWS IoT (p. 16) or to the Quick Connect workﬂow in the FreeRTOS console.

Registering your MCU board with AWS IoT

Your board must be registered with AWS IoT to communicate with the AWS Cloud. To register your board with AWS IoT, you must have:

An AWS IoT policy

The AWS IoT policy grants your device permissions to access AWS IoT resources. It is stored on the AWS Cloud.

16

(24)

Registering your MCU board with AWS IoT

An AWS IoT thing

An AWS IoT thing allows you to manage your devices in AWS IoT. It is stored on the AWS Cloud.

A private key and X.509 certiﬁcate

The private key and certiﬁcate allow your device to authenticate with AWS IoT.

To register your board, follow the procedures below.

To create an AWS IoT policy

1. To create an IAM policy, you must know your AWS Region and AWS account number.

To ﬁnd your AWS account number, open the AWS Management Console, locate and expand the menu beneath your account name in the upper-right corner, and choose My Account. Your account ID is displayed under Account Settings.

To ﬁnd the AWS region for your AWS account, use the AWS Command Line Interface. To install the AWS CLI, follow the instructions in the AWS Command Line Interface User Guide. After you install the AWS CLI, open a command prompt window and enter the following command:

aws iot describe-endpoint --endpoint-type=iot:Data-ATS

The output should look like this:

{ "endpointAddress": "xxxxxxxxxxxxxx.iot.us-west-2.amazonaws.com"

}

In this example, the region is us-west-2.

2. Browse to the AWS IoT console.

3. In the navigation pane, choose Secure, choose Policies, and then choose Create.

4. Enter a name to identify your policy.

5. In the Add statements section, choose Advanced mode. Copy and paste the following JSON into the policy editor window. Replace aws-region and aws-account with your AWS Region and account ID.

{ "Version": "2012-10-17", "Statement": [

{

"Effect": "Allow", "Action": "iot:Connect",

"Resource":"arn:aws:iot:aws-region:aws-account-id:*"

}, {

"Effect": "Allow", "Action": "iot:Publish",

"Resource": "arn:aws:iot:aws-region:aws-account-id:*"

}, {

"Effect": "Allow",

"Action": "iot:Subscribe",

}, {

"Effect": "Allow", "Action": "iot:Receive",

(25)

Downloading FreeRTOS

} ] }

This policy grants the following permissions:

iot:Connect

Grants your device the permission to connect to the AWS IoT message broker with any client ID.

iot:Publish

Grants your device the permission to publish an MQTT message on any MQTT topic.

iot:Subscribe

Grants your device the permission to subscribe to any MQTT topic ﬁlter.

iot:Receive

Grants your device the permission to receive messages from the AWS IoT message broker on any MQTT topic.

6. Choose Create.

To create an IoT thing, private key, and certiﬁcate for your device

2. In the navigation pane, choose Manage, and then choose Things.

3. If you do not have any IoT things registered in your account, the You don't have any things yet page is displayed. If you see this page, choose Register a thing. Otherwise, choose Create.

4. On the Creating AWS IoT things page, choose Create a single thing.

5. On the Add your device to the thing registry page, enter a name for your thing, and then choose Next.

6. On the Add a certificate for your thing page, under One-click certificate creation, choose Create certificate.

7. Download your private key and certiﬁcate by choosing the Download links for each.

8. Choose Activate to activate your certiﬁcate. Certiﬁcates must be activated prior to use.

9. Choose Attach a policy to attach a policy to your certiﬁcate that grants your device access to AWS IoT operations.

10. Choose the policy you just created and choose Register thing.

After your board is registered with AWS IoT, you can continue to Downloading FreeRTOS (p. 18).

Downloading FreeRTOS

You can download FreeRTOS from the FreeRTOS console or from the FreeRTOS GitHub repository.

Note

If you're getting started with the Cypress CYW954907AEVAL1F or CYW943907AEVAL1F development kits, you must download FreeRTOS from GitHub. See the README.md ﬁle for instructions. Conﬁgurations of FreeRTOS for these boards aren't currently available from the FreeRTOS console.

To download FreeRTOS from the FreeRTOS console

1. Sign in to the FreeRTOS console.

18

(26)

Conﬁguring the FreeRTOS demos

2. Under Predefined configurations, find Connect to AWS IoT- Platform, and then choose Download.

3. Unzip the downloaded ﬁle to a directory, and copy the directory path.

Important

• In this topic, the path to the FreeRTOS download directory is referred to as freertos.

• Space characters in the freertos path can cause build failures. When you clone or copy the repository, make sure the path you that create doesn't contain space characters.

• The maximum length of a ﬁle path on Microsoft Windows is 260 characters. Long FreeRTOS download directory paths can cause build failures.

• Because the source code may contain symbolic links, if you're using Windows to extract the archive, you may have to:

• Enable Developer Mode or,

• Use a console that is elevated as administrator.

In this way, Windows can properly create symbolic links when it extracts the archive.

Otherwise, symbolic links will be written as normal ﬁles that contain the paths of the symbolic links as text or are empty. For more information, see the blog entry Symlinks in Windows 10!.

If you use Git under Windows, you must enable Developer Mode or you must:

• Set core.symlinks to true with the following command:

git config --global core.symlinks true

• Use a console that is elevated as administrator whenever you use a git command that writes to the system (for example, git pull, git clone, and git submodule update --init --recursive).

After you download FreeRTOS, you can continue to Conﬁguring the FreeRTOS demos (p. 19).

Conﬁguring the FreeRTOS demos

You must edit some conﬁguration ﬁles in your FreeRTOS directory before you can compile and run any demos on your board.

To conﬁgure your AWS IoT endpoint

You must provide FreeRTOS with your AWS IoT endpoint so the application running on your board can send requests to the correct endpoint.

2. In the left navigation pane, choose Settings.

Your AWS IoT endpoint is displayed in Device data endpoint. It should look like 1234567890123- ats.iot.us-east-1.amazonaws.com. Make a note of this endpoint.

3. In the navigation pane, choose Manage, and then choose Things.

Your device should have an AWS IoT thing name. Make a note of this name.

4. Open demos/include/aws_clientcredential.h.

5. Specify values for the following constants:

(27)

Conﬁguring the FreeRTOS demos

• #define clientcredentialIOT_THING_NAME "The AWS IoT thing name of your board"

To conﬁgure your Wi-Fi

If your board is connecting to the internet across a Wi-Fi connection, you must provide FreeRTOS with Wi-Fi credentials to connect to the network. If your board does not support Wi-Fi, you can skip these steps.

1. demos/include/aws_clientcredential.h.

2. Specify values for the following #define constants:

• #define clientcredentialWIFI_SSID "The SSID for your Wi-Fi network"

• #define clientcredentialWIFI_PASSWORD "The password for your Wi-Fi network"

• #define clientcredentialWIFI_SECURITY The security type of your Wi-Fi network

Valid security types are:

• eWiFiSecurityOpen (Open, no security)

• eWiFiSecurityWEP (WEP security)

• eWiFiSecurityWPA (WPA security)

• eWiFiSecurityWPA2 (WPA2 security)

To format your AWS IoT credentials

FreeRTOS must have the AWS IoT certiﬁcate and private keys associated with your registered thing and its permissions policies to successfully communicate with AWS IoT on behalf of your device.

Note

To configure your AWS IoT credentials, you must have the private key and certificate that you downloaded from the AWS IoT console when you registered your device. After you have registered your device as an AWS IoT thing, you can retrieve device certificates from the AWS IoT console, but you cannot retrieve private keys.

FreeRTOS is a C language project, and the certiﬁcate and private key must be specially formatted to be added to the project.

1. In a browser window, open tools/certificate_configuration/

CertificateConfigurator.html.

2. Under Certiﬁcate PEM ﬁle, choose the ID-certificate.pem.crt that you downloaded from the AWS IoT console.

3. Under Private Key PEM ﬁle, choose the ID-private.pem.key that you downloaded from the AWS IoT console.

4. Choose Generate and save aws_clientcredential_keys.h, and then save the ﬁle in demos/include.

This overwrites the existing ﬁle in the directory.

Note

The certiﬁcate and private key are hard-coded for demonstration purposes only.

Production-level applications should store these ﬁles in a secure location.

After you configure FreeRTOS, you can continue to the Getting Started guide for your board to set up your platform's hardware and its software development environment, and then compile and run the demo on your board. For board-specific instructions, see the Board-specific getting started

20

(28)

First steps with Quick Connect

guides (p. 32). The demo application that is used in the Getting Started tutorial is the coreMQTT Mutual Authentication demo, which is located at demos/coreMQTT/mqtt_demo_mutual_auth.c.

First steps with the console Quick Connect workﬂow

Note

Conﬁgurations of FreeRTOS are currently not available on the FreeRTOS console for the following boards:

To get started using FreeRTOS with AWS IoT, you must have an AWS account, and an IAM user with permission to access AWS IoT and FreeRTOS cloud services. Then you can use the Quick Connect workﬂow in the FreeRTOS console to download FreeRTOS, conﬁgure the FreeRTOS demos for your board, and register your board with AWS IoT so it can communicate with the AWS Cloud. The following sections walk you through these requirements.

1.Set up your AWS account and permissions (p. 21)

2.Download and conﬁgure FreeRTOS and register your MCU board with AWS IoT (p. 22)

Set up your AWS account and permissions

To create an AWS account, see Create and Activate an AWS Account.

To add an IAM user to your AWS account, see IAM User Guide. To grant your IAM user account access to AWS IoT and FreeRTOS, attach the following IAM policies to your IAM user account:

• AmazonFreeRTOSFullAccess

• AWSIoTFullAccess

To attach the AmazonFreeRTOSFullAccess policy to your IAM user

5. In the search box, enter AmazonFreeRTOSFullAccess, choose it from the list, and then choose Next: Review.

To attach the AWSIoTFullAccess policy to your IAM user

(29)

Download and conﬁgure FreeRTOS and register your MCU board with AWS IoT

5. In the search box, enter AWSIoTFullAccess, choose it from the list, and then choose Next: Review.

For more information about IAM and user accounts, see IAM User Guide.

For more information about policies, see IAM Permissions and Policies.

Download and conﬁgure FreeRTOS and register your MCU board with AWS IoT

Open the FreeRTOS console and choose the Quick Connect workflow for your MCU board. This will download FreeRTOS, configure the FreeRTOS demos, and register your board with AWS IoT so it can communicate with the AWS Cloud. The Quick Connect workflow will create the following:

An AWS IoT policy

The AWS IoT policy grants your device permissions to access AWS IoT resources. It is stored on the AWS Cloud.

An AWS IoT thing

An AWS IoT thing allows you to manage your devices in AWS IoT. It is stored on the AWS Cloud.

A private key and X.509 certiﬁcate

The private key and certiﬁcate allow your device to authenticate with AWS IoT.

After you configure FreeRTOS, you can continue to the Getting Started guide for your board to compile and run the FreeRTOS demo. For board-specific instructions, see the Board-specific getting started guides (p. 32). The demo application that is used in the Getting Started tutorial is the coreMQTT Agent demo, which is located at demos/coreMQTT_Agent/mqtt_agent_task.c.

Troubleshooting getting started

The following topics can help you troubleshoot issues that you encounter while getting started with FreeRTOS:

Topics

• General getting started troubleshooting tips (p. 22)

• Installing a terminal emulator (p. 23)

For board-speciﬁc troubleshooting, see the Getting Started with FreeRTOS (p. 15) guide for your board.

General getting started troubleshooting tips

No messages appear in the AWS IoT console after I run the Hello World demo project. What do I do?

Try the following:

1. Open a terminal window to view the logging output of the sample. This can help you determine what is going wrong.

2. Check that your network credentials are valid.

22

(30)

Installing a terminal emulator

The logs shown in my terminal when running a demo are truncated. How can I increase their length?

Increase the value of configLOGGING_MAX_MESSAGE_LENGTH to 255 in the FreeRTOSconfig.h ﬁle for the demo you are running:

#define configLOGGING_MAX_MESSAGE_LENGTH 255

Installing a terminal emulator

A terminal emulator can help you diagnose problems or verify that your device code is running properly.

There are a variety of terminal emulators available for Windows, macOS, and Linux.

You must connect your board to your computer before you attempt to establish a serial connection to your board with a terminal emulator.

Use the following settings to conﬁgure your terminal emulator:

Terminal Setting Value

BAUD rate 115200

Data 8 bit

Parity none

Stop 1 bit

Flow control none

Finding your board's serial port

If you do not know your board's serial port, you can issue one of the following commands from the command line or terminal to return the serial ports for all devices connected to your host computer:

Windows

chgport

Linux

ls /dev/tty*

macOS

ls /dev/cu.*

Using CMake with FreeRTOS

You can use CMake to generate project build ﬁles from FreeRTOS application source code, and to build and run the source code.

(31)

Prerequisites

You can also use an IDE to edit, debug, compile, flash, and run code on FreeRTOS-qualified devices. Each board-specific Getting Started guide includes instructions for setting up the IDE for a particular platform.

If you prefer working without an IDE, you can use other third-party code editing and debugging tools for developing and debugging your code, and then use CMake to build and run the applications.

The following boards support CMake:

• Espressif ESP32-DevKitC

• Espressif ESP-WROVER-KIT

• Inﬁneon XMC4800 IoT Connectivity Kit

• Microchip Curiosity PIC32MZEF Bundle

• Nordic nRF52840 DK Development kit

• STMicroelectronicsSTM32L4 Discovery Kit IoT Node

• Texas Instruments CC3220SF-LAUNCHXL

• Microsoft Windows Simulator

See the topics below for more information about using CMake with FreeRTOS.

Topics

• Prerequisites (p. 24)

• Developing FreeRTOS applications with third-party code editors and debugging tools (p. 25)

• Building FreeRTOS with CMake (p. 25)

Prerequisites

Make sure that your host machine meets the following prerequisites before continuing:

• Your device's compilation toolchain must support the machine's operating system. CMake supports all versions of Windows, macOS, and Linux

Windows subsystem for Linux (WSL) is not supported. Use native CMake on Windows machines.

• You must have CMake version 3.13 or higher installed.

You can download the binary distribution of CMake from CMake.org.

Note

If you download the binary distribution of CMake, make sure that you add the CMake executable to the PATH environment variable before you using CMake from command line.

You can also download and install CMake using a package manager, like homebrew on macOS, and scoop or chocolatey on Windows.

Note

The CMake package versions provided in the package managers for many Linux distributions are out-of-date. If your distribution's package manager does not provide the latest version of CMake, you can try alternative package managers, like linuxbrew or nix.

• You must have a compatible native build system.

CMake can target many native build systems, including GNU Make or Ninja. Both Make and Ninja can be installed with package managers on Linux, macOS and Windows. If you are using Make on

24

(32)

Developing FreeRTOS applications with third- party code editors and debugging tools

Windows, you can install a standalone version from Equation, or you can install MinGW, which bundles make.

Note

The Make executable in MinGW is called mingw32-make.exe, instead of make.exe.

We recommend that you use Ninja, as it is faster than Make and also provides native support to all desktop operating systems.

Developing FreeRTOS applications with third-party code editors and debugging tools

You can use a code editor and a debugging extension or a third-party debugging tool to develop applications for FreeRTOS.

If, for example, you use Visual Studio Code as your code editor, you can install the Cortex-Debug VS Code extension as a debugger. When you ﬁnish developing your application, you can invoke the CMake command-line tool to build your project from within VS Code. For more information about using CMake to build FreeRTOS applications, see Building FreeRTOS with CMake (p. 25).

For debugging, you can provide a VS Code with debug conﬁguration similar to the following:

"configurations": [ {

"name": "Cortex Debug", "cwd": "${workspaceRoot}",

"executable": "./build/st/stm32l475_discovery/aws_demos.elf", "request": "launch",

"type": "cortex-debug", "servertype": "stutil"

} ]

Building FreeRTOS with CMake

CMake targets your host operating system as the target system by default. To use it for cross compiling, CMake requires a toolchain file, which specifies the compiler that you want to use. In FreeRTOS, we provide default toolchain files in freertos/tools/cmake/toolchains. The way to provide this file to CMake depends on whether you’re using the CMake command line interface or GUI. For more details, follow the Generating build files (CMake command-line tool) (p. 26) instructions below. For more information about cross-compiling in CMake, see CrossCompiling in the official CMake wiki.

To build a CMake-based project

1. Run CMake to generate the build ﬁles for a native build system, like Make or Ninja.

You can use either the CMake command-line tool or the CMake GUI to generate the build ﬁles for your native build system.

For information about generating FreeRTOS build files, see Generating build files (CMake command- line tool) (p. 26) and Generating build files (CMake GUI) (p. 27).

2. Invoke the native build system to make the project into an executable.

For information about making FreeRTOS build ﬁles, see Building FreeRTOS from generated build ﬁles (p. 29).

User Guide

FreeRTOS

User Guide

FreeRTOS: User Guide

Table of Contents

What is FreeRTOS?

Downloading FreeRTOS source code

FreeRTOS versioning

FreeRTOS Long Term Support

FreeRTOS Extended Maintenance Plan

FreeRTOS architecture

FreeRTOS-qualiﬁed hardware platforms

Development workﬂow

Additional resources

FreeRTOS kernel fundamentals

FreeRTOS kernel scheduler

Memory management

Kernel memory allocation

Application memory management

Intertask coordination

Queues

Semaphores and mutexes

Direct-to-task notiﬁcations

Stream buﬀers

Sending data

Receiving data

Message buﬀers

Sending data

Receiving data

Symmetric multiprocessing (SMP) support

Modifying applications to use the FreeRTOS-SMP kernel

Software timers

Low power support

Kernel conﬁguration

FreeRTOS console

Predeﬁned FreeRTOS conﬁgurations

To create a custom configuration from a predefined configuration

Custom FreeRTOS conﬁgurations

To create a custom conﬁguration

Note

To edit a custom conﬁguration

To delete a custom conﬁguration

Quick connect workﬂow

Tagging conﬁgurations

AWS IoT Device SDK for Embedded C

Note

Getting Started with FreeRTOS

FreeRTOS demo application

First steps

Note

Setting up your AWS account and permissions

To attach the AmazonFreeRTOSFullAccess policy to your IAM user

To attach the AWSIoTFullAccess policy to your IAM user

Registering your MCU board with AWS IoT

To create an AWS IoT policy

To create an IoT thing, private key, and certiﬁcate for your device

Downloading FreeRTOS

Note

To download FreeRTOS from the FreeRTOS console

Important

Conﬁguring the FreeRTOS demos

To conﬁgure your AWS IoT endpoint

To conﬁgure your Wi-Fi

To format your AWS IoT credentials

Note

Note

First steps with the console Quick Connect workﬂow

Note

Set up your AWS account and permissions

To attach the AmazonFreeRTOSFullAccess policy to your IAM user

To attach the AWSIoTFullAccess policy to your IAM user

Download and conﬁgure FreeRTOS and register your MCU board with AWS IoT

Troubleshooting getting started

General getting started troubleshooting tips

Installing a terminal emulator

Finding your board's serial port

Using CMake with FreeRTOS

Prerequisites

Note

Note