5d056010455613d7cfda28f27da26573000773fd - third_party/github/FreeRTOS/FreeRTOS-Kernel

commit	5d056010455613d7cfda28f27da26573000773fd	[log] [tgz]
author	Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>	Thu Feb 23 09:37:42 2023 +0530
committer	GitHub <noreply@github.com>	Thu Feb 23 09:37:42 2023 +0530
tree	fa27cde2d47bed16ebfd8cfdb8919484c195a0f4
parent	ba1deb54e8fb76b8325c8ca9fe44abd5daed8ddf [diff]

Fix build failure introduced in PR #597 (#629)

The PR #597 introduced a new config option configTICK_TYPE_WIDTH_IN_BITS
which can be defined to one of the following:
* TICK_TYPE_WIDTH_16_BITS - Tick type is 16 bit wide.
* TICK_TYPE_WIDTH_32_BITS - Tick type is 32 bit wide.
* TICK_TYPE_WIDTH_64_BITS - Tick type is 64 bit wide.

Earlier we supported 16 and 32 bit width for tick type which was
controlled using the config option configUSE_16_BIT_TICKS. The PR
tried to maintain backward compatibility by honoring
configUSE_16_BIT_TICKS. The backward compatibility did not work as
expected though, as the macro configTICK_TYPE_WIDTH_IN_BITS was used
before it was defined. This PR addresses it by ensuring that the macro
configTICK_TYPE_WIDTH_IN_BITS is defined before it is used.

Testing
1. configUSE_16_BIT_TICKS is defined to 0.

Source (function xTaskIncrementTick in tasks.c):
```
const TickType_t xConstTickCount = xTickCount + ( TickType_t ) 1;
```

Assembly:
```
109e:       4b50            ldr     r3, [pc, #320]  ; (11e0 <xTaskIncrementTick+0x150>)
10a0:       f8d3 4134       ldr.w   r4, [r3, #308]  ; 0x134
10a4:       3401            adds    r4, #1
10a6:       f8c3 4134       str.w   r4, [r3, #308]  ; 0x134
```

It is clear from assembly that the tick type is 32 bit.

2. configUSE_16_BIT_TICKS is defined to 1.

Source (function xTaskIncrementTick in tasks.c):
```
const TickType_t xConstTickCount = xTickCount + ( TickType_t ) 1;
```

Assembly:
```
10e2:       4b53            ldr     r3, [pc, #332]  ; (1230 <xTaskIncrementTick+0x15c>)
10e4:       f8b3 4134       ldrh.w  r4, [r3, #308]  ; 0x134
10e8:       b2a4            uxth    r4, r4
10ea:       3401            adds    r4, #1
10ec:       b2a4            uxth    r4, r4
10ee:       f8a3 4134       strh.w  r4, [r3, #308]  ; 0x134
```

It is clear from assembly that the tick type is 16 bit.

3. configTICK_TYPE_WIDTH_IN_BITS is defined to TICK_TYPE_WIDTH_16_BITS.

Source (function xTaskIncrementTick in tasks.c):
```
const TickType_t xConstTickCount = xTickCount + ( TickType_t ) 1;
```

Assembly:
```
10e2:       4b53            ldr     r3, [pc, #332]  ; (1230 <xTaskIncrementTick+0x15c>)
10e4:       f8b3 4134       ldrh.w  r4, [r3, #308]  ; 0x134
10e8:       b2a4            uxth    r4, r4
10ea:       3401            adds    r4, #1
10ec:       b2a4            uxth    r4, r4
10ee:       f8a3 4134       strh.w  r4, [r3, #308]  ; 0x134
```

It is clear from assembly that the tick type is 16 bit.

4. configTICK_TYPE_WIDTH_IN_BITS is defined to TICK_TYPE_WIDTH_32_BITS.

Source (function xTaskIncrementTick in tasks.c):
```
const TickType_t xConstTickCount = xTickCount + ( TickType_t ) 1;
```

Assembly:
```
109e:       4b50            ldr     r3, [pc, #320]  ; (11e0 <xTaskIncrementTick+0x150>)
10a0:       f8d3 4134       ldr.w   r4, [r3, #308]  ; 0x134
10a4:       3401            adds    r4, #1
10a6:       f8c3 4134       str.w   r4, [r3, #308]  ; 0x134
```

It is clear from assembly that the tick type is 32 bit.

5. configTICK_TYPE_WIDTH_IN_BITS is defined to TICK_TYPE_WIDTH_64_BITS.

```
 #error configTICK_TYPE_WIDTH_IN_BITS set to unsupported tick type width.
```

The testing was done for GCC/ARM_CM3 port which does not support 64 bit
tick type.

6. Neither configUSE_16_BIT_TICKS nor configTICK_TYPE_WIDTH_IN_BITS
defined.

```
 #error Missing definition:  One of configUSE_16_BIT_TICKS and
 configTICK_TYPE_WIDTH_IN_BITS must be defined in FreeRTOSConfig.h.
 See the Configuration section of the FreeRTOS API documentation for
 details.
```

7. Both configUSE_16_BIT_TICKS and configTICK_TYPE_WIDTH_IN_BITS defined.

```
 #error Only one of configUSE_16_BIT_TICKS and
 configTICK_TYPE_WIDTH_IN_BITS must be defined in FreeRTOSConfig.h.
 See the Configuration section of the FreeRTOS API documentation for
 details.
```

Related issue - https://github.com/FreeRTOS/FreeRTOS-Kernel/issues/628

Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>

include/FreeRTOS.h[diff]

1 file changed

tree: fa27cde2d47bed16ebfd8cfdb8919484c195a0f4

README.md

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.

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
)

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
)

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)

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.
The ./portable directory contains the files that are specific to a particular microcontroller and/or compiler. See the readme file in the ./portable directory for more information.
The ./include directory contains the real time kernel header files.

Code Formatting

FreeRTOS files are formatted using the “uncrustify” tool. The configuration file used by uncrustify can be found in the .github/uncrustify.cfg file.

Line Endings

File checked into the FreeRTOS-Kernel repository use unix-style LF line endings for the best compatbility with git.

For optmial compatibility with Microsoft Windows tools, it is best to enable the git autocrlf feature. You can eanble 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 followig command:

git config blame.ignoreRevsFile .git-blame-ignore-revs

Spelling

lexicon.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. If your pull request fails to pass the spelling and you believe this is a mistake, then add the word to lexicon.txt. Note that only the FreeRTOS Kernel source files are checked for proper spelling, the portable section is ignored.