RT-Thread RTOS | Overview and its Components

1st April 2020 Harshvardhan Mishra

In this article we discuss RT-Thread RTOS. RT-Thread open-source real-time operating system provides developers with a wealth of components, making it easy to deploy on different hardware platforms and business scenarios and to achieve one-time programming, permanent to use. This article is going to introduce the features of these components.

How components can help to speed up the development process when using RTOS?

Do you need components when you’re working on a real-time operating system? The components such as FinSH console, virtual file system, utest framework, dynamic module, socket abstraction layer, AT component, POSIX interface, Ulog log, power management, or network framework, etc.

FinSH Console

FinSH is a command-line component of RT-Thread that provides a set of operating interfaces that users can call on the command line, primarily for debugging or viewing system information. It can communicate with the PC using serial port/ Ethernet / USB, etc.

Function:

FinSH is a shell terminal under an embedded platform. With a shell, it is like building a bridge between the developer and the computer, the developer can easily access to the operation of the system and operate the system through the command control system.
Especially in the debugging phase, with the shell, developers can locate the issue faster, also can use the shell to call test functions, change the parameters of the test function, reduce the number of code burning, shorten the development time of the project.
FinSH supports permission verification, the system will do the permission verification after startup, only passed the permission verification, will turn on the FinSH function, improve the security of system input.
FinSH supports features such as auto-replenishment, viewing historical commands, and more

Virtual File System

A file system is a set of abstract data types that implements the storage, hierarchical organization, access, and retrieval of data. It is a mechanism for providing underlying data access to users. Files are usually the basic units stored in a file system, that is, data is organized in a single file. When there are a lot of files, it will lead to numerous files, and it is difficult to classify and rename them. And the folder exists as a container for multiple files.
DFS is a virtual file system component provided by RT-Thread. Its full name is Device File System which is a device virtual file system. The name of the file system uses a style similar to UNIX files and folders. The directory structure is as follows:

In RT-Thread DFS, the file system has a uniform root directory, which is represented by /. The f1.bin file in the root directory is represented by /f1.bin, and the /f1.bin directory in the 2019 directory is represented by /data/2019/f1.bin. That is, the partition symbol of the directory is /, which is exactly the same as UNIX/Linux, and is different from Windows (the \ is used as the separator of the directory on the Windows operating system).

The main features of the RT-Thread DFS component are:

Provides a unified POSIX file and directory operations interface for applications: read, write, poll/select, and more.
Supports multiple types of file systems, such as FatFS, RomFS, DevFS, etc., and provides management of common files, device files, and network file descriptors.
Supports multiple types of storage devices such as SD Card, SPI Flash, Nand Flash, etc.

The hierarchical structure of DFS is shown in the following figure, which is mainly divided into a POSIX interface layer, a virtual file system layer and a device abstraction layer.

utest Framework

utest (unit test) is a unit testing framework developed by RT-Thread. The original intention of designing utest is to make it easier for RT-Thread developers to write test programs using a unified framework interface for unit testing, coverage testing, and integration testing.

Dynamic Module: dlmodule

The dynamic module provides a mechanism for dynamically loading program modules for RT-Thread. Because it is also compiled independently of the kernel, it is more flexible to use. In terms of implementation, this is a mechanism to separate the kernel from the dynamic modules. Through this mechanism, the kernel and dynamic modules can be compiled separately, and at runtime, the compiled dynamic modules are loaded into the kernel through the module loader in the kernel.

In the dynamic module of RT-Thread, two formats are currently supported:

* .mo is an executable dynamic module that is suffixed with .mo when compiled; it can be loaded, and a main thread is automatically created in the system to execute main() function in this dynamic module; at the same time, main(int argc, char**argv) can also accept arguments on the command line.
* .so is a dynamic library compiled with .so as a suffix; it can be loaded and resided in memory, and some set of functions is used by other programs (code or dynamic modules in the kernel).

SAL (Socket abstraction layer)

In order to adapt to more network protocol stack types and avoid the system’s dependence on a single network protocol stack, the RT-Thread system provides a SAL (Socket Abstraction Layer) components that implement different network protocol stacks or network implementations. The abstraction of the interface provides a set of standard BSD Socket APIs to the upper layer so that developers only need to care about and use the network interface provided by the network application layer, without concern for the underlying specific network protocol stack type and implementation, which greatly improves the system’s compatibility makes it easy for developers to complete protocol stack adaptation and network-related development. Main features of the SAL component are as follows:

Abstract and unified multiple network protocol stack interfaces;
Provide Socket-level TLS encrypted transport feature;
Support standard BSD Socket APIs；
Unified FD management for easy operation of network functions using read/write poll/select；SAL Network Framework

The SAL network framework of RT-Thread is mainly shown in the following structure:

AT Component

In the Age of the Internet of Things, there is a wide variety of network AT modules, and for easy to develop, the RT-Thread abstraction implements the AT framework, which can be operated through the BSD socket standard interface.

The AT component is based on the implementation of the AT Server and AT Client of the RT-Thread system. The component completes the AT command transmission, command format and parameter judgment, command response, response data reception, response data parsing, URC data processing, etc. Command data interaction process.

Through the AT component, the device can use the serial port to connect to other devices to send and receive parsed data. It can be used as an AT Server to allow other devices or even the computer to connect to complete the response of sending data. It can also start the CLI mode in the local shell to enable the device to support AT Server and AT Client at the same time. Server and AT Client features, this mode is mostly used for device development and debugging.

AT component resource usage:

AT Client: 4.6K ROM and 2.0K RAM；

AT Server: 4.0K ROM and 2.5K RAM；

AT CLI: 1.5K ROM and almost no RAM is used.

Overall, the AT component resources are extremely small, making them ideal for use in embedded devices with limited resources. The AT component code is primarily located in rt-thread/components/net/at/. The main functions include:

Main Functions of AT Server:

Basic commands: Implement a variety of common basic commands (ATE, ATZ, etc.);
Command compatibility: The command supports ignoring case and improving command compatibility;
Command detection: The command supports custom parameter expressions and implements the self-detection of received command parameters.
Command registration: Provides a simple way to add user-defined commands, similar to the way the finsh/msh command is added;
Debug mode: Provides AT Server CLI command-line interaction mode, mainly used for device debugging.

Main Functions of AT Client:

URC data processing: The complete URC data processing method;
Data analysis: Supports the analysis of custom response data, and facilitates the acquisition of relevant information in the response data;
Debug mode: Provides AT Client CLI command-line interaction mode, mainly used for device debugging.

Main Functions of AT Socket:
As an extension of AT Client function, it uses AT command to send and receive as the basis, implements the standard BSD Socket API, completes the data sending and receiving function, and enables users to complete device networking and data communication through AT commands.

Multi-client support: The AT component currently supports multiple clients running simultaneously.

POSIX Interface

Using the POSIX API interface in RT-Thread includes several parts: libc (for example, newlib), filesystem, pthread, and so on. Need to open the relevant options in rtconfig.h:

#define RT_USING_LIBC
#define RT_USING_DFS
#define RT_USING_DFS_DEVFS
#define RT_USING_PTHREADS

RT-Thread implements most of the functions and constants of Pthreads, defined in the pthread.h, mqueue.h, semaphore.h, and sched.h header files according to the POSIX standard. Pthreads is a sublibrary of libc, and Pthreads in RT-Thread is based on the encapsulation of RT-Thread kernel functions, making them POSIX compliant.

Ulog log

Ulog is a very simple and easy to use C/C++ log component. The first letter u stands for μ, which means micro. It can achieve the lowest ROM<1K, RAM<0.2K resource usage. Ulog is not only small in size, but also has very comprehensive functions. Its design concept refers to another C/C++ open source log library: EasyLogger (referred to as elog), and has made many improvements in terms of functions and performance. The main features are as follows:

The backend of the log output is diversified and can support, for example, serial port, network, file, flash memory and other backend forms.
The log output is designed to be thread-safe and supports asynchronous output mode.
The logging system is highly reliable and is still available in complex environments such as interrupted ISRs and Hardfault.
The log supports runtime/compilation time to set the output level.
The log content supports global filtering by keyword and label.
The APIs and log formats are compatible with linux syslog.
Support for dumping debug data to the log in hex format.
Compatible with rtdbg (RTT’s early log header file) and EasyLogger’s log output API.

The following figure shows the ulog log component architecture diagram:

Power Management: PM

In the initial stage of product development, the first consideration is to complete the development of product functions as soon as possible. After the function of the product is gradually improved, it is necessary to add the power management (PM) function. To meet this need for IoT, RT-Thread provides power management components. The idea of power management components is to be as transparent as possible, making it easier for products to add low power functions.

RT-Thread’s PM components adopt a layered design idea, separating architecture and chip-related parts, and extracting common parts as the core. While providing a common interface to the upper layer, it also makes it easier for the bottom driver to adapt components.

The main features of RT-Thread PM components are as follows:

It manages power consumption based on mode, dynamically adjusts working mode in idle time, and supports multiple levels of sleeping.

Transparent to applications, components automatically complete power management at the bottom layer.

It supports dynamic frequency conversion in running mode and updates the frequency configuration of equipment automatically according to the mode to ensure normal operation in different running modes.
Support equipment power management, automatically manage device suspending and resuming according to the mode, ensure correct suspending and resuming in different sleep mode.
Optional sleep time compensation is supported to make OS Tick dependent applications transparent.
Provide the device interface to the upper layer. If the devfs component is opened, it can also be accessed through the file system interface.

Network Framework

In order to support various network protocol stacks, RT-Thread has developed a SAL component, the full name of the Socket abstraction layer. RT-Thread can seamlessly access various protocol stacks, including several commonly used TCP/IP protocol stack, such as the LwIP protocol stack commonly used in embedded development and the AT Socket protocol stack component developed by RT-Thread, which complete the conversion of data from the network layer to the transport layer.

The main features of the RT-Thread network framework are as follows:

Support for standard network sockets BSD Socket API, support for poll/select
Abstract, unified multiple network protocol stack interfaces
Support various physical network cards, network communication module hardware
The resource occupancy of the SAL(socket abstraction layer) component is small: ROM 2.8K and RAM 0.6K.

RT-Thread’s network framework adopts a layered design with four layers, each layer has different responsibilities. The following figure shows the RT-Thread network framework structure:

Those functional components are modularly designed to be loosely coupled with the OS core and can be tailored or extended through a graphical IDE. And its modular design allows for high internal cohesion inside the components and low coupling between components.

Useful links :

website: https://www.rt-thread.io/

Github: https://github.com/RT-Thread

Twitter: https://twitter.com/rt_thread

Medium: https://medium.com/@rt_thread

This is a sponsered post of RT-Thread by cathy.

Thanks for Reading this article. If you want to get your sponsored posts published on IoTbyHVM.ooo, contact us via email : iotbyhvm@gmail.com