1. Coding standards
FreeRTOS's core source code follows the MISRA encoding standard guidelines. This standard is a little longer and you can buy it for a small amount on the official MISRA website. No standards will be copied here.
Projects whose source code of FreeRTOS does not comply with MISRA standards are as follows:
There are two API functions with multiple return points. The MISRA encoding standard mandates that a function should have a single return point at its end.
Pointer arithmetic operation. When creating tasks, in order to be compatible with 8, 16, 20, 24, and 32-bit buses, pointer arithmetic operation is inevitably used. The MISRA encoding standard mandates that pointer arithmetic operations can only be used on pointers to arrays or array elements.
By default, the tracking macro is an empty statement, so it does not comply with MISRA regulations. The MISRA encoding standard mandates that preprocessing instructions should be syntactically meaningful.
FreeRTOS can be compiled in many different compilers, some of which have more advanced features than their class. For this reason, FreeRTOS does not use any non-C language standard features or syntax. An exception is the header file. Include a file called in the folder FreeRTOS/Source/include. If your compiler does not provide a stdint type definition, you can rename the file to.
2. Naming rules
The RTOS kernel and sample program source code use the following rules:
1> Variables
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', and 'c' means 'char'
Variables of non-stdint types use prefix x, such as basic Type_t and TickType_t types, which are defined at the porting layer and are defined as the most efficient types that conform to the processor architecture;
Unsigned variables of non-stdint types use prefix ux, such as UbaseType_t (unsigned BaseType_t)
Variables of type size_t use the prefix x;
Enumerate type variables with prefix e
Pointer type variables are attached with the prefix p on the basis of type, for example, the prefix of the pointer variable to uint16_t is pus
Consistent with the MISRA guide, char type variables are only allowed to hold ASCII characters with prefixed c
Consistent with the MISRA guide, char* type variables are only allowed to point to ASCII strings, prefixed with pc
2> Function
The function prefix in the file scope is the prefix of the prvAPI function as their return type. When the return is empty, the prefix of the vAPI function name is the file name where the function is located. For example, vTaskThe Delete function is defined in, and the function returns empty.
3> Macro
The starting part of the name of the macro is part of the file name where the macro definition resides. for exampleconfigUSE_PREEMPTION is defined in the file. Except for the prefix, all remaining letters of the macro are capitalized, separated by underscores (’_’).
3. Data Type
Only data types defined by RTOS can be used, but there are exceptions, as shown below:
char: Consistent with the MISRA encoding standard guide, char type variables are only allowed to save ASCII characters char *: Consistent with the MISRA encoding standard guide, char * type variables are only allowed to point to ASCII strings. This can eliminate some compiler warnings when standard library functions expect a char* parameter; especially considering that some compilers treat char types as signed types, and some compilers treat char types as unsigned types.
There are three types that are defined in the transplant layer, they are:
TickType_t: If configUSE_16_BIT_TICKS is non-zero (condition is true), TickType_t is defined as an unsigned 16-bit type. If configUSE_16_BIT_TICKS is zero (condition is false), TickType_t is defined as an unsigned 32-bit type. Note: 32-bit architecture microprocessors should set configUSE_16_BIT_TICKS to zero.
BaseType_t: Defined as the most efficient data type in the microprocessor architecture. For example, on a 32-bit architecture processor, 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 a negative number error may occur.
UbaseType_t: This is an unsigned BaseType_t type
Style Guide
Indent: Indentation uses tab characters, one tab character equals 4 spaces.
Comment: The comment line does not exceed 80 columns, except for special cases. No C++ style double slash (//) comment
Layout: FreeRTOS's source code is designed to be as easy to view and read as possible. In the code fragment below, the first part shows the file layout and the second part shows the C code design format.
/* First, include the library file here... */
#include <>
/* ...and then the header file of FreeRTOS... */
#include ""
/* ...There are other header files immediately. */
#include ""
/* Then #defines, adding brackets in reasonable places. */
#define A_DEFINITION ( 1 )
/*
* Then comes the Static (inside the 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) are immediately followed, before the function body definition. */
static BaseType_t xMyVariable.
/* Each function has a line of dash at the end, leaving a line of blank space between the dash and the first function below. */
/*-----------------------------------------------------------*/
void vAFunction( void )
{
/* Function body is defined here, please be sure to wrap it in braces */
}
/*-----------------------------------------------------------*/
static UBaseType_t prvNextFunction( void )
{
/* Function body is defined here. */
}
/*-----------------------------------------------------------*/
/*
* Function names always occupy one row, including the return type. There is no space before the left bracket and there is a space after the left bracket.
* The naming of a parameter with a space after each parameter should be descriptive.
*/
void vAnExampleFunction( long lParameter1, unsigned short usParameter2 )
{
/* The variable declaration is not indented. */
uint8_t ucByte;
/* The code must be aligned. Braces occupy a single line. */
for( ucByte = 0U; ucByte < fileBUFFER_LENGTH; ucByte++ )
{
/* Indent again here. */
}
}
/*
* For, while, do, if structures have similar patterns. There are no spaces between these keywords and the opening brackets.
* There is a space after the left bracket, there is also a space before the closing bracket, and there is a space after each semicolon.
* One space before and after each operator. Use parentheses to clarify the priority of the operator. No 0 is allowed
* Numbers other than * (devil numbers) appear, if necessary, replace these numbers with constants that represent the meaning of the number or
* Macro definition.
*/
for( ucByte = 0U; ucByte < fileBUFFER_LENGTH; ucByte++ )
{
}
while( ucByte < fileBUFFER_LENGTH )
{
}
/*
* Due to the complexity of operator priority, we cannot trust ourselves to be alert to operator priority at all times.
* and can be used correctly, so for multiple expression operations, use brackets to clarify the priority order
*/
if( ( ucByte < fileBUFFER_LENGTH ) && ( ucByte != 0U ) )
{
ulResult = ( ( ulValue1 + ulValue2 ) - ulValue3 ) * ulValue4;
}
/* Conditional expressions must also be aligned like other codes. */
#if( configUSE_TRACE_FACILITY == 1 )
{
/* Add a counter for tracking to TCB. */
pxNewTCB->uxTCBNumber = uxTaskNumber;
}
#endif
/*Leave a space before and after square brackets*/
ucBuffer[ 0 ] = 0U;
ucBuffer[ fileBUFFER_LENGTH - 1U ] = 0U;The above is the detailed content of the FreeRTOS encoding standard and style guide. For more information about the FreeRTOS encoding standard style, please follow my other related articles!