A stream batching buffer only unblocks a waiting reader when the number of bytes in the buffer becomes strictly greater than its trigger level (prvBytesInBufferMeetTriggerLevel), unlike a plain stream/message buffer which unblocks when the byte count is greater than or equal to the trigger level. The maximum number of bytes any of these buffers can ever hold is one less than their internal length (a full/empty ring buffer ambiguity). The trigger-level validation in xStreamBufferGenericCreate(), xStreamBufferGenericCreateStatic() and xStreamBufferSetTriggerLevel() did not account for this difference: it accepted a trigger level equal to the buffer's maximum achievable occupancy for batching buffers too. Once such a trigger level was set, the buffer could never satisfy its own wake predicate, so a reader blocked in xStreamBufferReceive() would hang forever even after the buffer was completely filled. Add a batching-buffer-specific bound at all three validation sites so the trigger level is rejected (via configASSERT, or pdFALSE from xStreamBufferSetTriggerLevel) when it can never be exceeded. Plain stream and message buffers are unaffected. Verified by compiling the affected tasks.c/list.c/stream_buffer.c against the POSIX/GCC simulator port and running real FreeRTOS tasks: before the fix, a batching buffer created with xStreamBatchingBufferCreate(25, 25) hangs a reader forever even when the writer fills all 25 bytes; after the fix, the same call is rejected by configASSERT at creation time, while the correct boundary (trigger = 24) and plain stream/message buffers keep working exactly as before. Signed-off-by: 94xhn <94xhn1@gmail.com> Signed-off-by: 94xhn <87560781+94xhn@users.noreply.github.com> |
||
|---|---|---|
| .github | ||
| examples | ||
| include | ||
| portable | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitmodules | ||
| CMakeLists.txt | ||
| croutine.c | ||
| cspell.config.yaml | ||
| event_groups.c | ||
| GitHub-FreeRTOS-Kernel-Home.url | ||
| History.txt | ||
| LICENSE.md | ||
| list.c | ||
| manifest.yml | ||
| MISRA.md | ||
| queue.c | ||
| Quick_Start_Guide.url | ||
| README.md | ||
| stream_buffer.c | ||
| tasks.c | ||
| timers.c | ||
Getting started
This repository contains FreeRTOS kernel source/header files and kernel
ports only. This repository is referenced as a submodule in
FreeRTOS/FreeRTOS
repository, which contains pre-configured demo application projects under
FreeRTOS/Demo directory.
The easiest way to use FreeRTOS is to start with one of the pre-configured demo application projects. That way you will have the correct FreeRTOS source files included, and the correct include paths configured. Once a demo application is building and executing you can remove the demo application files, and start to add in your own application source files. See the FreeRTOS Kernel Quick Start Guide for detailed instructions and other useful links.
Additionally, for FreeRTOS kernel feature information refer to the Developer Documentation, and API Reference.
Also for contributing and creating a Pull Request please refer to the instructions here.
FreeRTOS-Kernel V11.1.0 source code is part of the FreeRTOS 202406.00 LTS release.
Getting help
If you have any questions or need assistance troubleshooting your FreeRTOS project, we have an active community that can help on the FreeRTOS Community Support Forum.
To consume FreeRTOS-Kernel
Consume with CMake
If using CMake, it is recommended to use this repository using FetchContent.
Add the following into your project's main or a subdirectory's CMakeLists.txt:
- Define the source and version/tag you want to use:
FetchContent_Declare( freertos_kernel
GIT_REPOSITORY https://github.com/FreeRTOS/FreeRTOS-Kernel.git
GIT_TAG main #Note: Best practice to use specific git-hash or tagged version
)
In case you prefer to add it as a git submodule, do:
git submodule add https://github.com/FreeRTOS/FreeRTOS-Kernel.git <path of the submodule>
git submodule update --init
- Add a freertos_config library (typically an INTERFACE library) The following assumes the directory structure:
include/FreeRTOSConfig.h
add_library(freertos_config INTERFACE)
target_include_directories(freertos_config SYSTEM
INTERFACE
include
)
target_compile_definitions(freertos_config
INTERFACE
projCOVERAGE_TEST=0
)
In case you installed FreeRTOS-Kernel as a submodule, you will have to add it as a subdirectory:
add_subdirectory(${FREERTOS_PATH})
- Configure the FreeRTOS-Kernel and make it available
- this particular example supports a native and cross-compiled build option.
set( FREERTOS_HEAP "4" CACHE STRING "" FORCE)
# Select the native compile PORT
set( FREERTOS_PORT "GCC_POSIX" CACHE STRING "" FORCE)
# Select the cross-compile PORT
if (CMAKE_CROSSCOMPILING)
set(FREERTOS_PORT "GCC_ARM_CA9" CACHE STRING "" FORCE)
endif()
FetchContent_MakeAvailable(freertos_kernel)
- In case of cross compilation, you should also add the following to
freertos_config:
target_compile_definitions(freertos_config INTERFACE ${definitions})
target_compile_options(freertos_config INTERFACE ${options})
Consuming stand-alone - Cloning this repository
To clone using HTTPS:
git clone https://github.com/FreeRTOS/FreeRTOS-Kernel.git
Using SSH:
git clone git@github.com:FreeRTOS/FreeRTOS-Kernel.git
Repository structure
-
The root of this repository contains the three files that are common to every port - list.c, queue.c and tasks.c. The kernel is contained within these three files. croutine.c implements the optional co-routine functionality - which is normally only used on very memory limited systems.
-
The
./portabledirectory contains the files that are specific to a particular microcontroller and/or compiler. See the readme file in the./portabledirectory for more information. -
The
./includedirectory contains the real time kernel header files. -
The
./examples/template_configurationdirectory contains a sampleFreeRTOSConfig.hto help jumpstart a new project. See the FreeRTOSConfig.h file for instructions.
Code Formatting
FreeRTOS files are formatted using the "uncrustify" tool. The configuration file used by uncrustify can be found in the FreeRTOS/CI-CD-GitHub-Actions's uncrustify.cfg file.
Line Endings
File checked into the FreeRTOS-Kernel repository use unix-style LF line endings for the best compatibility with git.
For optimal compatibility with Microsoft Windows tools, it is best to enable the git autocrlf feature. You can enable this setting for the current repository using the following command:
git config core.autocrlf true
Git History Optimizations
Some commits in this repository perform large refactors which touch many lines
and lead to unwanted behavior when using the git blame command. You can
configure git to ignore the list of large refactor commits in this repository
with the following command:
git config blame.ignoreRevsFile .git-blame-ignore-revs
Spelling and Formatting
We recommend using Visual Studio Code,
commonly referred to as VSCode, when working on the FreeRTOS-Kernel.
The FreeRTOS-Kernel also uses cSpell as part of its
spelling check. The config file for which can be found at cspell.config.yaml
There is additionally a
cSpell plugin for VSCode
that can be used as well.
.cSpellWords.txt contains words that are not
traditionally found in an English dictionary. It is used by the spellchecker
to verify the various jargon, variable names, and other odd words used in the
FreeRTOS code base are correct. If your pull request fails to pass the spelling
and you believe this is a mistake, then add the word to
.cSpellWords.txt. When adding a word please
then sort the list, which can be done by running the bash command:
sort -u .cSpellWords.txt -o .cSpellWords.txt
Note that only the FreeRTOS-Kernel Source Files, include,
portable/MemMang, and portable/Common
files are checked for proper spelling, and formatting at this time.
Third Party Tools
Visit this link for detailed information about third-party tools with FreeRTOS support.