Shulou(Shulou.com)06/01 Report--

This article mainly introduces the FreeRTOS coding standard and style is what the relevant knowledge, the content is detailed and easy to understand, simple and fast operation, with a certain reference value, I believe you will have something to gain after reading this FreeRTOS coding standard and style article, let's take a look at it.

1. Coding standard

The core source code of FreeRTOS follows the MISRA coding standard guide. This standard is a little longer, you can buy it on the official MISRA website for a small amount of money, and there is no longer any copy of the standard here.

Projects where the FreeRTOS source code does not conform to the MISRA standard are as follows:

There are two API functions that have multiple return points. The MISRA coding standard enforces that a function should have a single return point at the end of it.

Pointer arithmetic, when creating a task, it is inevitable to use pointer arithmetic in order to be compatible with 8, 16, 20, 24, 32-bit buses. The MISRA coding standard enforces that the arithmetic operation of pointers can only be used on pointers to arrays or array elements.

By default, trace macros are empty statements and therefore do not comply with MISRA regulations. The MISRA coding standard enforces that preprocessing instructions should be syntactically meaningful.

FreeRTOS can be compiled in many different compilers, some of which have more advanced features than others. For this reason, FreeRTOS does not use any features or syntax that are not standard in C. One exception is the header file stdint.h. Include a file called stdint.readme under the folder FreeRTOS/Source/include. If your compiler does not provide a stdint type definition, you can rename the stdint.readme file to stdint.h.

two。 Naming rules

The RTOS kernel and demo routine source code use the following rules:

1 > variable

Variables of type uint32_t use the prefix ul, where'u 'means' unsigned','l' 'means' long''

Variables of type uint16_t use the prefix us, where'u 'means' unsigned','s' 'means' short''

Variables of type uint8_t use the prefix uc, where'u 'means' unsigned','c' 'means' char''

Variables of non-stdint types use the prefix x, such as basic Type_t and TickType_t types, which are defined at the migration layer and are defined as the most efficient types that conform to the processor architecture

Unsigned variables of non-stdint type use the prefix ux, such as UbaseType_t (unsigned BaseType_t)

Variables of type size_t use the prefix x

Enumerated type variables use the prefix e

Pointer type variables add a prefix p to the type, for example, pointer variables pointing to uint16_t are prefixed with pus

Consistent with the MISRA guidelines, char type variables are only allowed to hold ASCII characters with a prefix of c

Consistent with the MISRA guidelines, char * type variables are only allowed to point to ASCII strings with a prefix of pc

2 > function

Functions in the file scope are prefixed with the return type of the prvAPI function, and when the return is empty, the prefix is the vAPI function name starting with the file name of the function. For example, the vTaskDelete function is defined in tasks.c, and the function returns null.

3 > Macro

The beginning of the name of a macro is part of the file name in which the macro definition is located. For example, configUSE_PREEMPTION is defined in the FreeRTOSConfig.h file. Except for the prefix, the remaining letters of the macro are all capitalized, separated by an underscore ('_') between the two words.

3 data types

Only data types defined by stdint.h and RTOS themselves can be used, but there are exceptions, as follows:

Char: consistent with MISRA coding standard guidelines, char type variables are only allowed to hold ASCII characters char *: consistent with MISRA coding standard guidelines, char * type variables are only allowed to point to ASCII strings. This eliminates some compiler warnings when a standard library function expects a char * parameter, especially considering that some compilers treat char types as signed types, while others treat char types as unsigned types.

There are three types that are defined in the migration layer. They are:

TickType_t: if configUSE_16_BIT_TICKS is non-zero (the condition is true), TickType_t is defined as an unsigned 16-bit type. If configUSE_16_BIT_TICKS is zero (the condition is false), TickType_t is defined as an unsigned 32-bit type. Note: microprocessors with 32-bit architecture should set configUSE_16_BIT_TICKS to zero. BaseType_t: defined as the most efficient data type for microprocessor architecture. For example, on 32-bit architecture processors, BaseType_t should be defined as a 32-bit type. On 16-bit architecture processors, BaseType_t should be defined as a 16-bit type. If BaseType_t is defined as char, be sure to use signed char for the return value of the function, otherwise it may cause a negative error. UbaseType_t: this is an unsigned BaseType_t type

3.4 style Guide

Indentation: indentation uses tabs, one tab equals 4 spaces. Comments: no more than 80 comment lines, except in special cases. No C++ style double slash (/ /) annotation layout: the FreeRTOS source code is designed to be as easy to view and read as possible. In the following code chip, the first part shows the file layout and the second part shows the C code design format.

/ * first include the library file here. * / # include / *. Then there is the header file of FreeRTOS. * / # include "FreeRTOS.h" / *. This is followed by other header files. * / # include "HardwareSpecifics.h" / * followed by # defines, add parentheses where appropriate. * / # define A_DEFINITION (1) / * * is followed by the Static (internal file) function prototype. * if the comment has multiple lines, refer to the comment style of this article-each line starts with'*'. * / static void prvAFunction (uint32_t ulParameter); / * File scope variables (used internally in this file) follow, before the function body is defined. * / static BaseType_t xMyVariable. / * there is a dash at the end of each function, leaving a blank space between the dash and the first function below. * / / *-- * / void vAFunction (void) {/ * function body is defined here Note that the * /} / *-* / static UBaseType_t prvNextFunction (void) {/ * function body is defined here in curly braces. The * /} / *-* / / * * function name is always on one line, including the return type. There is no space before the left parenthesis. There is a space after the left parenthesis. * the naming of a space parameter after each parameter should be descriptive. * / void vAnExampleFunction (long lParameter1, unsigned short usParameter2) {/ * variable declaration is not indented. The * / uint8_t ucByte; / * code should be aligned. Curly braces occupy a separate line. * / for (ucByte = 0U; ucByte

< fileBUFFER_LENGTH; ucByte++ ) { /* 这里再次缩进. */ } } /* * for、while、do、if结构具有相似的模式。这些关键字和左括号之间没有空格。 * 左括号之后有一个空格，右括号前面也有一个空格，每个分号后面有一个空格。 * 每个运算符的前后各一个空格。使用圆括号明确运算符的优先级。不允许有0 * 以外的数字（魔鬼数）出现，必要时将这些数字换成能表示出数字含义的常量或 * 宏定义。 */ for( ucByte = 0U; ucByte < fileBUFFER_LENGTH; ucByte++ ) { } while( ucByte < fileBUFFER_LENGTH ) { } /* * 由于运算符优先级的复杂性，我们不能相信自己对运算符优先级时刻保持警惕 * 并能正确的使用，因此对于多个表达式运算时，使用括号明确优先级顺序 */ if( ( ucByte < fileBUFFER_LENGTH ) && ( ucByte != 0U ) ) { ulResult = ( ( ulValue1 + ulValue2 ) - ulValue3 ) * ulValue4; } /* 条件表达式也要像其它代码那样对齐。 */ #if( configUSE_TRACE_FACILITY == 1 ) { /* 向TCB增加一个用于跟踪的计数器. */ pxNewTCB->

UxTCBNumber = uxTaskNumber;} # endif / * leave a space before and after square brackets * / ucBuffer [0] = 0U; ucBuffer [fileBUFFER_LENGTH-1U] = 0U. This is the end of the article on "what is the coding standard and style of FreeRTOS". Thank you for reading! I believe that everyone has a certain understanding of the knowledge of "what is the FreeRTOS coding standard and style". If you want to learn more knowledge, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.