Latest News Items: FreeRTOS V8 released - FAT file system released - Tick suppression demo'ed SAM4L, RX100 & STM32L
 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs Books & Kits Visualisation Ecosystem Training Contact & Support




Last site update Jan 14 2014

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:

  • TickType_t
    If configUSE_16_BIT_TICKS is set to non-zero (true), then TickType_t is defined to be an unsigned 16-bit type. If configUSE_16_BIT_TICKS is set to zero (false), then TickType_t is defined to be an unsigned 32-b it type. See the customisation section of the API documentation for full information.

  • BaseType_t
    This is defined to be the most efficient, natural, type for the architecture. For example, on a 32-bit architecture BaseType_t will be defined to be a 32-bit type. On a 16-bit architecture BaseType_t will be defined to be a 16-bit type. If BaseType_t 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;







[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




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.