LevelX provides NAND and NOR flash wear leveling facilities to embedded applications. Since both NAND and NOR flash memory can only be erased a finite number of times, it’s critical to distribute the flash memory use evenly. This is typically called wear leveling and is the purpose behind LevelX. LevelX presents to the user an array of logical sectors that are mapped to physical flash memory inside of LevelX. Applications may use LevelX in conjunction with FileX or may read/write logical sectors directly. LevelX is designed for fault tolerance. Flash updates are performed in a multiple-step process that can be interrupted in each step. LevelX automatically recovers to the optimal state during the next operation.
Azure RTOS LevelX as part of Azure RTOS has been integrated to the semiconductor's SDKs and development environment. You can develop using the tools of choice from STMicroelectronics, NXP, Renesas and Microchip.
See Overview of Azure RTOS LevelX for the high-level overview, and all documentation and APIs can be found in: Azure RTOS LevelX documentation.
.
├── cmake # CMakeList files for building the project
├── common # Core LevelX files
├── samples # Sample codes
├── LICENSE.txt # License terms
├── LICENSE-HARDWARE.txt # Licensed hardware from semiconductors
├── CONTRIBUTING.md # Contribution guidance
└── SECURITY.md # Microsoft repo security guidance
The master branch has the most recent code with all new features and bug fixes. It does not represent the latest General Availability (GA) release of the library. Each official release (preview or GA) will be tagged to mark the commit and push it into the Github releases tab, e.g. v6.2-rel
.
When you see xx-xx-xxxx, 6.x or x.x in function header, this means the file is not officially released yet. They will be updated in the next release. See example below.
/**************************************************************************/
/* */
/* FUNCTION RELEASE */
/* */
/* _tx_initialize_low_level Cortex-M23/GNU */
/* 6.x */
/* AUTHOR */
/* */
/* Scott Larson, Microsoft Corporation */
/* */
/* DESCRIPTION */
/* */
/* This function is responsible for any low-level processor */
/* initialization, including setting up interrupt vectors, setting */
/* up a periodic timer interrupt source, saving the system stack */
/* pointer for use in ISR processing later, and finding the first */
/* available RAM memory address for tx_application_define. */
/* */
/* INPUT */
/* */
/* None */
/* */
/* OUTPUT */
/* */
/* None */
/* */
/* CALLS */
/* */
/* None */
/* */
/* CALLED BY */
/* */
/* _tx_initialize_kernel_enter ThreadX entry function */
/* */
/* RELEASE HISTORY */
/* */
/* DATE NAME DESCRIPTION */
/* */
/* 09-30-2020 Scott Larson Initial Version 6.1 */
/* xx-xx-xxxx Scott Larson Include tx_user.h, */
/* resulting in version 6.x */
/* */
/**************************************************************************/
The main components of Azure RTOS are each provided in their own repository, but there are dependencies between them, as shown in the following graph. This is important to understand when setting up your builds.
You will have to take the dependency graph above into account when building anything other than ThreadX itself.
Instruction for building the LevelX as static library using Arm GNU Toolchain and CMake. If you are using toolchain and IDE from semiconductor, you might follow its own instructions to use Azure RTOS components as explained in the Getting Started section.
-
Install the following tools:
- CMake version 3.0 or later
- Arm GNU Toolchain for arm-none-eabi
- Ninja
-
Build the ThreadX library as the dependency.
-
Cloning the repo.
$ git clone --recursive https://github.com/azure-rtos/levelx.git
-
Define the features and addons you need in
lx_user.h
and build together with the component source code. You can refer tolx_user_sample.h
as an example. -
Building as a static library
Each component of Azure RTOS comes with a composable CMake-based build system that supports many different MCUs and host systems. Integrating any of these components into your device app code is as simple as adding a git submodule and then including it in your build using the CMake
add_subdirectory()
.While the typical usage pattern is to include LevelX into your device code source tree to be built & linked with your code, you can compile this project as a standalone static library to confirm your build is set up correctly.
An example of building the library for Cortex-M4:
$ cmake -Bbuild -GNinja -DCMAKE_TOOLCHAIN_FILE=cmake/cortex_m4.cmake . $ cmake --build ./build
Professional support plans are available from Microsoft. For community support and others, see the Resources section below.
License terms for using Azure RTOS are defined in the LICENSE.txt file of this repo. Please refer to this file for all definitive licensing information. No additional license fees are required for deploying Azure RTOS on hardware defined in the LICENSED-HARDWARE.txt file. If you are using hardware not listed in the file or having licensing questions in general, please contact Microsoft directly at https://aka.ms/azrtos-license.
The following are references to additional Azure RTOS resources:
- Product introduction and white papers: https://azure.com/rtos
- General technical questions: https://aka.ms/QnA/azure-rtos
- Product issues and bugs, or feature requests: https://github.com/azure-rtos/levelx/issues
- Licensing and sales questions: https://aka.ms/azrtos-license
- Product roadmap and support policy: https://aka.ms/azrtos/lts
- Blogs and videos: http://msiotblog.com and https://aka.ms/iotshow
- Azure RTOS TraceX Installer: https://aka.ms/azrtos-tracex-installer
You can also check previous questions or ask new ones on StackOverflow using the azure-rtos
and levelx
tags.
Azure RTOS provides OEMs with components to secure communication and to create code and data isolation using underlying MCU/MPU hardware protection mechanisms. It is ultimately the responsibility of the device builder to ensure the device fully meets the evolving security requirements associated with its specific use case.
Please follow the instructions provided in the CONTRIBUTING.md for the corresponding repository.