Quick Understanding of FreeRTOS Code Standards

Follow “Engineer Advancement Notes” and select “Star Public Account” to progress together!

[Introduction] Some friends feel that the FreeRTOS kernel code looks unfamiliar and are not used to its coding style. This article will outline its coding standards to improve the efficiency of reading its code. The code is based on FreeRTOS V10.4.3.

FreeRTOS Code Structure

Quick Understanding of FreeRTOS Code Standards

The kernel code files are very few and concise:

  • croutine.c/croutine.h: Coroutines, which are more efficient on 8-bit/16-bit platforms, while tasks are recommended on 32-bit platforms.
  • event_groups.c/event_groups.h: As the name suggests, this is the implementation of event groups.
  • heap_x.c: Kernel heap implementation. FreeRTOS provides five heap managers from heap_1.c to heap_5.c, each with its own advantages and disadvantages, which need to be selected based on the application.
  • list.c/list.h: Linked list implementation, mainly providing data structure algorithm support for the scheduler, such as task linked lists.
  • port.c/portmacro.h: Hardware-related portable abstraction layer, mainly including SysTick interrupts, context switching, and interrupt management. The specific implementation largely depends on the platform (microcontroller architecture and compiler toolchain). Typically implemented in assembly language.
  • queue.c/queue.h/semphr.h: Implementation of semaphores and mutexes.
  • tasks.c/task.h: Task manager implementation.
  • timers.c/timers.h: Software timer implementation.
  • FreeRTOS.h: Compilation configuration file used to summarize all source file compilation options.
  • FreeRTOSConfig.h: FreeRTOS kernel configuration, Tick clock, and IRQ interrupt configuration.

Next, let’s organize the relevant coding standards, which are specifically reflected in the coding of the above files.

Variables

Variables have strict prefix identifiers for variable type attributes:

  • c – char type variable
  • s – short type variable
  • l – long type variable
  • x – portBASE_TYPE defined in portmacro.h, a type definition for portability
  • u – unsigned integer
  • p – pointer

For example:

//x indicates portBASE_TYPE, u indicates unsigned type
PRIVILEGED_DATA static volatile TickType_t xTickCount = ( TickType_t ) configINITIAL_TICK_COUNT;
PRIVILEGED_DATA static volatile UBaseType_t uxTopReadyPriority = tskIDLE_PRIORITY;

//For example in list.h
struct xLIST_ITEM
{
    configLIST_VOLATILE TickType_t xItemValue;
    //Pointers start with p
    struct xLIST_ITEM * configLIST_VOLATILE pxNext; 
    struct xLIST_ITEM * configLIST_VOLATILE pxPrevious; 
    void * pvOwner; 
    struct xLIST * configLIST_VOLATILE pxContainer; 
};

For the basic data types in C, portable type definitions are made:

#define portCHAR          char
#define portFLOAT         float
#define portDOUBLE        double
#define portLONG          long
#define portSHORT         short
#define portSTACK_TYPE    uint32_t
#define portBASE_TYPE     long

Functions

Quick Understanding of FreeRTOS Code Standards

Prefixes:

  • v: void, no return type
  • x: returns portBASE_TYPE
  • prv: private function, used within the module
//ux indicates unsigned portBASE_TYPE return value
//List indicates the file to which this function belongs
//Remove function name
UBaseType_t uxListRemove( ListItem_t * const pxItemToRemove ) PRIVILEGED_FUNCTION;

//Another example, prv indicates a module internal function
static TickType_t prvGetNextExpireTime( BaseType_t * const pxListWasEmpty ) PRIVILEGED_FUNCTION;

Macros

Defines the file to which the macro belongs, i.e., in which file it is defined:

  • port: for example, portMAX_DELAY in portable.h
  • task: for example, task_ENTER_CRITICAL in task.h
  • pd: for example, pdTRUE defined in projdefs.h
  • config: for example, configUSE_PREEMPTION defined in FreeRTOSConfig.h
  • err: for example, errQUEUE_FULL defined in projdefs.h

As for whether such strict coding standards are worth advocating, it is subjective. Personally, I prefer the Linux coding style, and I feel that overly complex coding standards can sometimes be frustrating in actual development.

— END —

Collection | [Open Source] Embedded IoT Application Development

Collection | Embedded Linux Application Development

Collection | Embedded Linux Development Environment Setup

Collection | IoT BLE Bare-Metal Program Development

Collection | IoT BLE Application Development

Collection | RT-Thread Learning Notes

Collection | RT-Thread & Bear-Pi Development Notes Series

Follow and reply with [Technical Document] to download all collections’ PDF documents

Leave a Comment