|
|||||||
 
|
|
FreeRTOS Sponsors
|
|
| Get seen by 1000s of embedded engineers a month | |
|
|
|
|
|
|
|
|
|
Coding Standard and Style Guide
[Getting Started]
On this page:
Coding Standard
The core FreeRTOS source files (those that are common to all ports) conform, predominantly, to the MISRA (Motor Industry Software Reliability Association) guidelines. Deviations from the MISRA standard are listed below:-
Two API functions have more than one exit point. A deviation was permitted
in these limited cases for reasons of critical efficiency.
-
Standard C data types are used, rather than their typedef'ed equivalents.
This is necessary when calling library functions from so many
different compilers (that use different prototypes). All ports have been
verified to ensure the number of bytes used by each data type is correct
for the source code, and as expected. The MISRA rules stating that int
and unqualified char types are not used has not been relaxed.
-
When creating tasks, the source code manipulates memory addresses to
locate the start and end addresses of the stack allocated to the created
task. The code has to work for all the architectures to which FreeRTOS
has been ported - which includes architectures with 8, 16, 20, 24 and 32-bit
busses. This inevitably requires some pointer arithmetic. When pointer
arithmetic is used, the arithmetic result is pragmatically checked for
correctness.
-
The trace macros are, by default, empty, so do not generate any code.
Therefore, MISRA compliance checking is performed with dummy macro
definitions.
Naming Conventions
The RTOS kernel and demo application source code use the following conventions:- Variables
- Variables of type char are prefixed c
- Variables of type short are prefixed s
- Variables of type long are prefixed l
- Enumerated variables are prefixed e
- Other types (e.g. structs) are prefixed x
- Pointers have an additional prefixed p, for example a pointer to a short will have prefix ps
- Unsigned variables have an additional prefixed u, for example an unsigned short will have prefix us, and a pointer to an unsigned short will have prefix pus.
- Functions
- File private functions are prefixed with prv
- API functions are prefixed with their return type, as per the convention defined for variables
- Function names start with the file in which they are defined. For example vTaskDelete is defined in tasks.c, and has a void return type.
- Macros
- Macros are pre-fixed with the file in which they are defined. The pre-fix is lower case. For example, configUSE_PREEMPTION is defined in FreeRTOSConifg.h.
- Other than the pre-fix, macros are written in all upper case, and use an underscore to separate words.
Data Types
Currently, standard data types can be used, with the following exceptions and rules:-
char types
FreeRTOS is compiled with a lot of different tools - some of which default to using signed char types, and some of which default to using unsigned char types. Therefore, unqualified char types are not permitted. For example, using unsigned char and signed char is permitted, while simply using char is not permitted. -
int types
Plain integer types (int), whether signed or unsigned, must never be used. Use long or short instead. -
floating point types
float and double types are not used in the RTOS kernel (although they are used in demo applications).
There are two types that are defined for each port. These are:
-
portTickType
If configUSE_16_BIT_TICKS is set to non-zero (true), then portTickType is defined to be an unsigned 16-bit type. If configUSE_16_BIT_TICKS is set to zero (false), then portTickType is defined to be an unsigned 32-b it type. See the customisation section of the API documentation for full information. -
portBASE_TYPE
This is defined to be the most efficient, natural, type for the architecture. For example, on a 32-bit architecture portBASE_TYPE will be defined to be a 32-bit type. On a 16-bit architecture portBASE_TYPE will be defined to be a 16-bit type. If portBASE_TYPE is define to char then particular care must be taken to ensure signed chars are used for function return values that can be negative to indicate an error.
Style Guide
-
Indentation
Tab characters are used to indent. One tab equals four spaces. -
Comments
Comments never pass column 80, unless they follow, and describe, a parameter.C++ style double slash (//) comments are not used.
-
Layout
The FreeRTOS source code lay out is designed to be as easy to view and read as possible. The layout is described in the code snippets below.
/* Function names are always written on a single line, including the return
type. As always, there is no space before the opening parenthesis. There
is a space after an opening parenthesis. There is a space before a closing
parenthesis. There is a space after each comma. Parameters are given
verbose, descriptive names (unlike this example!). The opening and closing
curly brackets appear on their own lines, lined up underneath each other. */
void vAnExampleFunction( long lParameter1, unsigned short usParameter2 )
{
/* Code is indented. Curly brackets are always on their own lines
and lined up underneath each other. */
for( ucByte = 0U; ucByte < fileBUFFER_LENGTH; ucByte++ )
{
/* Indent again. */
}
}
/* For, while, do and if constructs follow a similar pattern. There is no
space before the opening parenthesis. There is a space after an opening
parenthesis. There is a space before a closing parenthesis. There is a
space after each semicolon (if there are any). There are spaces before and
after each operator. No reliance is placed on operator precedence -
parenthesis are always used to make precedence explicit. Magic numbers,
other than zero, are always replaced with a constant or #defined constant.
The opening and closing curly brackets appear on their own lines. */
for( ucByte = 0U; ucByte < fileBUFFER_LENGTH; ucByte++ )
{
}
while( ucByte < fileBUFFER_LENGTH )
{
}
if( ( ucByte < fileBUFFER_LENGTH ) && ( ucByte != 0U ) )
{
}
/* Conditional compilations are laid out and indented as per any other code. */
#if( configUSE_TRACE_FACILITY == 1 )
{
/* Add a counter into the TCB for tracing only. */
pxNewTCB->uxTCBNumber = uxTaskNumber;
}
#endif
A space is placed after an opening square bracket, and before a closing
square bracket.
ucBuffer[ 0 ] = 0U;
ucBuffer[ fileBUFFER_LENGTH - 1U ] = 0U;
Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2013 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.