Documentation and download available at https://www.FreeRTOS.org/
Changes between FreeRTOS V10.5.0 and FreeRTOS V10.5.1 released November 16 2022
+ Updating the version in the manifest.yml file to be accurate.
Changes between FreeRTOS V10.4.6 and FreeRTOS V10.5.0 released September 16 2022
+ ARMv7-M and ARMv8-M MPU ports: It was possible for a third party that
already independently gained the ability to execute injected code to
read from or write to arbitrary addresses by passing a negative argument
as the xIndex parameter to pvTaskGetThreadLocalStoragePointer() or
vTaskSetThreadLocalStoragePointer respectively. A check has been added to
ensure that passing a negative argument as the xIndex parameter does not
cause arbitrary read or write.
We thank Certibit Consulting, LLC for reporting this issue.
+ ARMv7-M and ARMv8-M MPU ports: It was possible for an unprivileged task
to invoke any function with privilege by passing it as a parameter to
MPU_xTaskCreate, MPU_xTaskCreateStatic, MPU_xTimerCreate,
MPU_xTimerCreateStatic, or MPU_xTimerPendFunctionCall. MPU_xTaskCreate
and MPU_xTaskCreateStatic have been updated to only allow creation of
unprivileged tasks. MPU_xTimerCreate, MPU_xTimerCreateStatic and
MPU_xTimerPendFunctionCall APIs have been removed.
We thank Huazhong University of Science and Technology for reporting
this issue.
+ ARMv7-M and ARMv8-M MPU ports: It was possible for a third party that
already independently gained the ability to execute injected code to
achieve further privilege escalation by branching directly inside a
FreeRTOS MPU API wrapper function with a manually crafted stack frame.
The local stack variable `xRunningPrivileged` has been removed so that
a manually crafted stack frame cannot be used for privilege escalation
by branching directly inside a FreeRTOS MPU API wrapper.
We thank Certibit Consulting, LLC, Huazhong University of Science and
Technology and the SecLab team at Northeastern University for reporting
this issue.
+ ARMv7-M MPU ports: It was possible to configure overlapping memory
protection unit (MPU) regions such that an unprivileged task could access
privileged data. The kernel now uses highest numbered MPU regions for
kernel protections to prevent such MPU configurations.
We thank the SecLab team at Northeastern University for reporting this
issue.
+ Add support for ARM Cortex-M55.
+ Add support for ARM Cortex-M85. Contributed by @gbrtth.
+ Add vectored mode interrupt support to the RISC-V port.
+ Add support for RV32E extension (Embedded Profile) in RISC-V GCC port.
Contributed by @Limoto.
+ Heap improvements:
- Add a check to heap_2 to track if a memory block is allocated to
the application or not. The MSB of the size field is used for this
purpose. The same check already exists in heap_4 and heap_5. This
check prevents double free errors.
- Add a new flag configHEAP_CLEAR_MEMORY_ON_FREE to heap_2, heap_4
and heap_5. If the flag is set in FreeRTOSConfig.h then memory freed using
vPortFree() is automatically cleared to zero.
- Add a new API pvPortCalloc to heap_2, heap_4 and heap_5 which has the same
signature as the standard library calloc function.
- Update the pointer types to portPOINTER_SIZE_TYPE. Contributed by
@Octaviarius.
+ Add the ability to override send and receive completed callbacks for each
instance of a stream buffer or message buffer. Earlier there could be
one send and one receive callback for all instances of stream and message
buffers. Having separate callbacks per instance allows different message
and stream buffers to be used differently - for example, some for inter core
communication and others for same core communication.
The feature can be controlled by setting the configuration option
configUSE_SB_COMPLETED_CALLBACK in FreeRTOSConfig.h. When the option is set to 1,
APIs xStreamBufferCreateWithCallback() or xStreamBufferCreateStaticWithCallback()
(and likewise APIs for message buffer) can be used to create a stream buffer
or message buffer instance with application provided callback overrides. When
the option is set to 0, then the default callbacks as defined by
sbSEND_COMPLETED() and sbRECEIVE_COMPLETED() macros are invoked. To maintain
backwards compatibility, configUSE_SB_COMPLETED_CALLBACK defaults to 0. The
functionality is currently not supported for MPU enabled ports.
+ Generalize the FreeRTOS's Thread Local Storage (TLS) support so that it
is not tied to newlib and can be used with other c-runtime libraries also.
The default behavior for newlib support is kept same for backward
compatibility.
+ Add support to build and link FreeRTOS using CMake build system. Contributed
by @yhsb2k.
+ Add support to generate Software Bill of Materials (SBOM) for every release.
+ Add support for 16 MPU regions to the GCC Cortex-M33 ports.
+ Add ARM Cortex-M7 r0p0/r0p1 Errata 837070 workaround to ARM CM4 MPU ports.
The application writer needs to define configENABLE_ERRATA_837070_WORKAROUND
when using CM4 MPU ports on a Cortex-M7 r0p0/r0p1 core.
+ Add configSYSTICK_CLOCK_HZ to Cortex-M0 ports. This is needed to support
the case when the SysTick timer is not clocked from the same source as the CPU.
+ Add hardware stack protection support to MicroBlazeV9 port. This ensures that
the CPU immediately raises Stack Protection Violation exception as soon as any
task violates its stack limits. Contributed by @uecasm.
+ Introduce the configUSE_MINI_LIST_ITEM configuration option. When this
option is set to 1, ListItem_t and MiniLitItem_t remain separate types.
However, when configUSE_MINI_LIST_ITEM == 0, MiniLitItem_t and ListItem_t
are both typedefs of the same struct xLIST_ITEM. This addresses some issues
observed when strict-aliasing and link time optimization are enabled.
To maintain backwards compatibility, configUSE_MINI_LIST_ITEM defaults to 1.
+ Simplify prvInitialiseNewTask to memset newly allocated TCB structures
to zero, and remove code that set individual structure members to zero.
+ Add prototype for prvPortYieldFromISR to the POSIX port so that it builds
without any warning with -Wmissing-prototypes compiler option.
+ Add top of stack and end of stack to the task info report obtained using
vTaskGetInfo(). Contributed by @shreyasbharath.
+ Add a cap to the cRxLock and cTxLock members of the queue data structure.
These locks count the number items received and sent to the queue while
the queue was locked. These are later used to unblock tasks waiting on
the queue when the queue is unlocked. This PR caps the values of the
cRxLock and cTxLock to the number of tasks in the system because we cannot
unblock more tasks than there are in the system. Note that the same assert
could still be triggered is the application creates more than 127 tasks.
+ Changed uxAutoReload parameter in timer functions to xAutoReload. The
type is now BaseType_t. This matches the type of pdTRUE and pdFALSE.
The new function xTimerGetAutoReload() provides the auto-reload state as
a BaseType_t. The legacy function uxTimerGetAutoReload is retained with the
original UBaseType_t return value.
+ Fix support for user implementations of tickless idle that call
vTaskStepTick() with xExpectedIdleTime ticks to step. The new code
ensures xTickCount reaches xNextTaskUnblockTime inside xTaskIncrementTick()
instead of inside vTaskStepTick(). This fixes the typical case where a task
wakes up one tick late and a rare case assertion failure when xTickCount\
rolls over. Contributed by @jefftenney.
+ Fix deadlock in event groups when pvPortMalloc and vPortFree functions
are protected with a mutex. Contributed by @
STM32G474 CMAKE VSCODE FREERTOS 导入
需积分: 0 175 浏览量
更新于2024-05-04
收藏 34.36MB ZIP 举报
STM32G474是一款基于ARM Cortex-M4内核的微控制器,由意法半导体(STMicroelectronics)生产。这款芯片拥有强大的处理能力和丰富的外设接口,常用于嵌入式系统开发,尤其是在实时操作系统(RTOS)的支持下,能够实现复杂的多任务控制。
CMake是一个跨平台的构建系统,它允许开发者编写平台无关的构建脚本,可以生成针对不同IDE或构建工具的项目文件。在STM32G474的开发中,CMake可以帮助我们管理和构建项目,使得代码可以在Visual Studio Code(VSCODE)这样的编辑器中方便地调试和编译。
Visual Studio Code是一款非常流行的源代码编辑器,支持多种语言和插件。通过安装特定的C/C++扩展以及STM32相关的插件,VSCODE可以成为一个强大的STM32开发环境,提供语法高亮、代码自动完成、错误检查等功能,并且可以与CMake集成,实现项目的构建和调试。
FreeRTOS是一个轻量级的开源RTOS,专门设计用于资源有限的微控制器。它提供了任务调度、信号量、互斥锁、定时器等核心功能,使得开发者可以在STM32G474上实现多任务并行执行,有效管理系统的资源和时间响应。
在STM32G474上导入CMake、VSCODE和FreeRTOS的过程大致如下:
1. **环境准备**:确保已经安装了GCC ARM编译器、OpenOCD(用于JTAG/SWD调试)和Git。同时,需要在VSCODE中安装C/C++扩展,以及如`cmake-tools`、`arm-none-eabi-gcc`等支持STM32开发的相关插件。
2. **创建工程**:使用CMake编写`CMakeLists.txt`文件,定义项目的基本配置,如源代码目录、编译选项、链接库等。确保为FreeRTOS添加了必要的依赖和路径。
3. **配置FreeRTOS**:下载并集成FreeRTOS库到项目中,根据STM32G474的特性配置FreeRTOS的内核参数,如堆大小、任务数量等。
4. **设置启动文件**:为STM32G474编写或使用已有的启动文件,如`startup_stm32g474xx.s`,初始化堆栈、中断向量表等。
5. **编写应用程序**:根据需求编写FreeRTOS任务,每个任务是一个独立的函数,通过`xTaskCreate()`创建并添加到任务队列。
6. **配置VSCODE**:在VSCODE中配置CMake的生成器(例如,为GNU Make或Ninja),指定交叉编译工具链路径,设置调试配置,例如GDB服务器为OpenOCD。
7. **构建和调试**:运行CMake的`generate`命令生成项目文件,然后使用VSCODE的`build`任务进行编译。完成编译后,通过`debug`任务连接硬件进行调试。
8. **Moto Control**:如果`moto_control`是项目的一部分,那么它可能是一个电机控制的模块或者应用,涉及电机驱动、PID控制等相关算法。这部分代码需要与FreeRTOS的任务调度机制相结合,确保电机控制的实时性和稳定性。
在实际开发过程中,还需要关注内存管理、中断服务程序、功耗优化等问题。同时,理解FreeRTOS的内核概念,如任务、信号量、队列等,对于编写高效、可靠的STM32G474程序至关重要。通过CMake和VSCODE的结合使用,开发者可以享受到现代开发工具带来的便利,提高开发效率和代码质量。
JoYER_cc
- 粉丝: 119
- 资源: 1
最新资源
- UnsupportedClassVersionError(解决方案).md
- DOMUpdateError解决办法.md
- VerifyError(解决方案).md
- BlockingIOError.md
- NextTickError解决办法.md
- NSKeyValueCodingError如何解决.md
- ZipException(解决方案).md
- BrokenPipeError.md
- SSRHydrationError解决办法.md
- NSArgumentException如何解决.md
- NSConditionException如何解决.md
- JarException(解决方案).md
- ChildProcessError.md
- NSApplicationError如何解决.md
- DataFormatException(解决方案).md
- SSRRenderingError解决办法.md