uC/OS and FreeRTOS both follow the MISRA C coding standard and support PC-Lint static checking. Both official documents explain this.

Tip:

The MISRA C standard refers to the automotive C language development standard. You can refer to the article shared earlier: What is the MISRA C: 2012 Standard?

1. uC/OS

2. FreeRTOS

FreeRTOS also clearly states that it adopts the MISRA C coding standard, but does not support standards after C99, and supports PC-Lint static checking.

FreeRTOS has a lot of explanations (comments) in its source code that may cause exceptions in PC-Lint static checking, which is not present in uC/OS source code.

For example:

The configuration files (also known as “trimming” files) for both RTOS have somewhat similar content and are categorized.

However, uC/OS’s classification and comments are more user-friendly and easier for beginners to understand.

1. uC/OS

The configuration file for uC/OS is usually: os_cfg.h

2. FreeRTOS

FreeRTOS configuration file is usually: FreeRTOSConfig.h

The content of the headers for both RTOS is somewhat similar, just one is centered and the other is left-aligned.

1. uC/OS

Includes RTOS version, copyright statement, open-source protocol statement, etc.:

2. FreeRTOS

Includes RTOS version, copyright statement, open-source protocol statement, website, etc., similar to uC/OS.

The naming rules for both RTOS differ significantly, but both conform to conventional code naming rules.

1. File Names

FreeRTOS is more straightforward, which may be due to a lack of long-term planning during naming, and has continued to be used for compatibility. (This is more likely to cause file name conflicts)

2. Macros

Both have similarities: underscores separate uppercase letters, but prefixes differ.

For example, for the “configuration file“: uC/OS starts with【OS_CFG_】, while FreeRTOS starts with【config】.

3. Data Types

uC/OS-defined data types are relatively more common and more suitable for beginners.

FreeRTOS-defined data types are more “systematic,” suitable for experienced users, and relatively less friendly for beginners.

4. Function Names

Both are somewhat similar, differing prefixes, and are distinguished by 【uppercase letters at the beginning】.

For example, the function name for creating tasks:

FreeRTOS’s prefixes are described officially as follows:

• Static (static) functions are prefixed with prv, for example: prvIdleTask function.

• API functions are prefixed with their return type, with void types prefixed with v as a suffix. For example: vTaskDelete function.

// /* */ are the two most common ways to comment, but these two RTOS mainly use 【/* */】 comments.

The position of comments is also important, usually one line above the code or at the end of the code line (after the code).

Here, it is important to note that FreeRTOS does not have reliable comment functions for parameters, return values, etc.

Taking the “create task” function as an example:

Of course, the function comment information for FreeRTOS is described in detail in the manual.

Both RTOS use the same indentation method, which is 4 spaces:

Here, it is important to remember not to mix tabs and spaces, otherwise the code will be a mess. (This often occurs in many beginners or junior engineers, and the code is simply unbearable to look at）

Different fields have different abbreviations. There are also some common abbreviations in RTOS, such as:

That’s all for this article. The above only lists some typical coding styles; for more details, you can take some time to study on your own.

———— END ————

Follow the public account reply “Join Group” to join the technical exchange group according to the rules, reply “1024” to see more content.