 |
RT-Thread RTOS
An open source embedded real-time operating system
|
|
RT-Thread RTOS
An open source embedded real-time operating system
|
This chapter gives a brief introduction to the software architecture of the RT-Thread kernel, beginning with its composition and implementation. While also introducing RT-Thread kernel-related concepts for beginners.
After understanding this chapter, readers will have an elementary understanding of the RT Thread kernel and will be able to answer questions such as:
In the nutshell, this is only a brief introduction to software architecture decomposition and implementation of the real-time kernel. This will give understanding and concepts of how RT-Thread kernel works togther. After learning from this chapter, readers will have basic knowledge of each kernel components, system booting up proccesses, memory allocation and distrubtion, and methods of kernel configuration.
Kernel is the most basic and fundenmental part of an Operating System. Kernel service library and RT-Thread kernel libraries are interfacing between hardware and components/service layer. This includes the implementation of real-time kernel service library (rtservice.h/kservice.c) and other RT-Thread kernel libraries such as object management, thread management and scheduler, inter-thread communication management, clock management and memory management respectively. Below diagram is the core architecture diagram of the core kernel.
Implementation of core kernel libraries are similar to a small set of standard C runtime library and it can run independently. For example, Standard C library (C runtime library) provides "strcpy", "memcpy", "printf", "scanf" and other function implementations. RT-Thread kernel libraries also provide the function implementations which are mainly used by Core Kernel. However, to avoid name conflicts, specifically functions' names are preceded with rt_.
The built of the Kernel will be vary depending on the complier. For example, using GNU GCC compiler, it will use more implementation from the standard C library. Last but not least, the minimum resource requirements of the Kernel is 3KB ROM and 1.2KB RAM.
The Kernel object system can access and manage all of the kernel objects, such as:
Object management will be covered in detail in the chapter Object Management.
Thread is the smallest scheduling unit in the RT-Thread operating system. The thread scheduling algorithm is a Priority-based Full Preemptive Multi-Thread scheduling algorithm.
The system can support up to 256(0 - 255) thread priorities. For systems with tight resources, configurations with 8 or 32 thread priorities can be chosen(For example, STM32 has 32 thread priorities as per the default configuration). Lower numbers have a higher priority where 0 represents the highest priority furthermore the lowest priority(highest number) is reserved for idle threads.
RT-Thread supports the creation of multiple threads with the same priority. Threads having the same priority are scheduled with a Time Slice Rotation Scheduling algorithm so that each thread runs for the same amount of time.
The number of threads is bounded by the memory of the hardware platform and not the system.
Thread management will be covered in detail in the chapter Thread Management.
RT-Thread's Clock management is based upon a clock beat, which is the smallest clock unit in the RT-Thread operating system.
The RT-Thread timer provides two types of timer mechanisms:
The RT-Thread timer can be set to the HARD_TIMER or the SOFT_TIMER mode depending on the context in which the timeout function is executed.
The timer service is concluded using a timer timing callback i.e. a timeout function. The user can select the appropriate type of timer according to their real-time requirements for timing processing.
Timer will be explained further in the chapter Clock & Timer Management.
RT-Thread uses thread semaphores, mutexes, and event sets to achieve inter-thread synchronization.
Thread synchronizations happen through the acquisition and release of semaphore and mutexes.
The mutex uses priority inheritance to solve the common priority inversion problem in the real-time system. The thread synchronization mechanism allows threads to wait according to priorities or to acquire semaphores/mutexes following the First In First Out(FIFO) method.
Event sets are primarily used for synchronization between threads, they can achieve one-to-many and many-to-many synchronization. It allows OR trigger (independent synchronization) and AND trigger(associative synchronization) suitable for situations where threads are waiting for multiple events.
The concepts of semaphores, mutexes, and event sets are detailed in the chapter Inter-thread Synchronization.
RT-Thread supports communication mechanisms such as mailbox, message queue, etc. The mailbox's message length is fixed to 4 bytes. Whereas, message queue can receive messages in variable size and cache the messages in its own memory space.
Compared to a message queue, a mailbox is more efficient. The sending action of the mailbox and message queue can be safely used in an ISR (Interrupt Service Routine). The communication mechanism allows threads to wait by priority or to acquire by the First In First Out (FIFO) method.
The concept of mailbox and message queue will be explained in detail in the chapter Inter-thread Communication.
RT-Thread allows:
When the static memory pool has available memory, the time allocated to the memory block will be constant.
When the static memory pool is empty, the system will then request for suspending or blocking the thread of the memory block. The thread will abandon the request and return if the memory block is not obtained after waiting for a while, or the thread will abandon and return immediately. The waiting time depends on the waiting time parameter set when the memory block is applied. When other threads release the memory block to the memory pool, the system will wake up the thread if there are suspended threads waiting to be allocated of memory blocks.
Under circumstances of different system resources, the dynamic memory heap management module respectively provides memory management algorithms for small memory systems and SLAB memory management algorithms for large memory systems.
There is also a dynamic memory heap management called memheap, suitable for memory heaps in systems with multiple addresses that can be discontinuous. Using memheap, the user can "paste" multiple memory heaps together, letting them operate as if operating a memory heap.
The concept of memory management will be explained in the chapter Memory Management.
RT-Thread uses I2C, SPI, USB, UART, etc., as peripheral devices and is uniformly registered through the device. It realized a device management subsystem accessed by the name, and it can access hardware devices according to a unified API interface. On the device driver interface, depending on the characteristics of the embedded system, corresponding events can be attached to different devices. The driver notifies the upper application program when the device event is triggered.
The concept of I/O device management will be explained in the chapter I/O Device Framework.
The understanding of most codes usually starts from learning the startup process. We will firstly look for the source of the startup. Taking MDK-ARM as an example, the user program entry for MDK-ARM is the main() function located in the main.c file. The launching of the system starts from the assembly code startup_stm32f103xe.s, jumps to the C code, initializes the RT-Thread system function, and finally enters the user program entry main().
To complete the RT-Thread system function initialization before entering main(), we used the MDK extensions $Sub$$ and $Super$$. Users can add the prefix of $Sub$$ to main to make it a new function $Sub$$main.
$Sub$$main can call some functions to be added before main (here, RT-Thread system initialization function is added). Then, call $Super$$main to the main() function so that the user does not have to manage the system initialization before main().
For more information on the use of the $Sub$$ and $Super$$ extensions, see the ARM® Compiler v5.06 for μVision®armlink User Guide.
Let's take a look at this code defined in components.c:
Here, the $Sub$$main function simply calls the rtthread_startup() function. RT-Thread allows multiple platforms and multiple compilers, and the rtthread_startup() function is a uniform entry point specified by RT-Thread, so the $Sub$$main function only needs to call the rtthread_startup() function (RT-Thread compiled using compiler GNU GCC is an example where it jumps directly from the assembly startup code section to the rtthread_startup() function and starts the execution of the first C code).
The rtthread_startup() function can be found in the code of components.c, the startup process of RT-Thread is as shown below:
Code for the rtthread_startup() function is as follows:
This part of the startup code can be roughly divided into four parts:
Set the system clock in rt_hw_board_init() to provide heartbeat and serial port initialization for the system, bound to the system's input and output terminals to this serial port. Subsequent system operation information will be printed out from the serial port later.
The main() function is the user code entry for RT-Thread, and users can add their own applications to the main() function.
The general MCU contains storage space that includes the on-chip Flash and the on-chip RAM. RAM is equivalent to memory, and Flash is comparable to a hard disk. The compiler classifies a program into several parts stored in different memory areas of the MCU.
After the Keil project is compiled, there will be a prompt stating the occupied space by the corresponding program, for example:
The Program Size mentioned above contains the following sections:
After compiling the project, there will be a generated .map file that describes the size and address of each function. The last few lines of the file also illustrate the relationship between the above fields:
Before the program runs, the file entity needs to be flashed into the STM32 Flash, usually a bin or hex file. The burned file is called an executable image file. The left part in the figure below shows the memory distribution after the executable image file is flashed into STM32 which includes the RO and RW segments. The RO segment stores data of Code and RO-data, and the RW segment holds the data of RW-data. Since ZI-data is 0, it is not included in the image file.
STM32 is launched from Flash by default after power-on. After launching, RW-data (initialized global variable) the RW segment is transferred to RAM, but the RO segment is not transferred. Meaning the execution code of the CPU is read from the Flash. The ZI segment is allocated according to the ZI address and size is given by the compiler, and the RAM area is cleared.
The dynamic memory heap is unused RAM space, and the memory blocks requested and released by the application come from this space.
Like the following example:
The 128-byte memory space pointed by the msg_ptr pointer in the code is in the dynamic memory heap space.
Some global variables are stored in the RW segment and the ZI segment. The RW segment holds the global variable with the initial value (the global variable in the constant form is placed in the RO segment, which is a read-only property), and uninitialized global variable is stored in the ZI segment, as in the following example:
The sensor_value is stored in the ZI segment and is automatically initialized to zero after system startup (some library functions provided by the user program or compiler are initialized to zero). The sensor_inited variable is stored in the RW segment, and the sensor_enable is stored in the RO segment.
The automatic initialization mechanism means that the initialization function does not need to be called by explicit function. It only needs to be declared by macro definition at the function definition, and it will be executed during system startup.
For example, calling a macro definition in the serial port driver to inform the function that needs to be called to initialize the system. The code is as follows:
The last part of the sample code INIT_BOARD_EXPORT(rt_hw_usart_init) indicates that the automatic initialization function is used. In this way, rt_hw_usart_init() function is automatically called by the system, so where is it called?
In the system startup flowchart, there are two functions: rt_components_board_init() and rt_components_init(), subsequent functions inside the box with the underlying color represent functions that are automatically initialized, where:
INIT_BOARD_EXPORT(fn).INIT_PREV_EXPORT(fn).INIT_DEVICE_EXPORT(fn).INIT_COMPONENT_EXPORT(fn).INIT_ENV_EXPORT(fn).INIT_APP_EXPORT(fn).The rt_components_board_init() function executes earlier, mainly to initialize the relevant hardware environment. When this function is executed, it will traverse the initialization function table declared by INIT_BOARD_EXPORT(fn) and call each function.
The rt_components_init() function is called and executed in the main thread created after the operating system is running. At this time, the hardware environment and the operating system have been initialized and the application-related code can be executed. The rt_components_init() function will transverse through the remaining few initialization function tables declared by macros.
RT-Thread's automatic initialization mechanism uses a custom RTI symbol segment, it puts the function pointer that needs to be initialized at startup into this segment and forms an initialization function table which will be traversed during system startup. It calls the functions in the table to achieve the purpose of automatic initialization.
The macro interface definitions used to implement the automatic initialization function are described in the following table:
| Initialization sequence | Macro Interface | Description |
|---|---|---|
| 1 | INIT_BOARD_EXPORT(fn) | Very early initialization, the scheduler has not started yet. |
| 2 | INIT_PREV_EXPORT(fn) | Mainly used for pure software initialization, functions without too many dependencies |
| 3 | INIT_DEVICE_EXPORT(fn) | Peripheral driver initialization related, such as network card devices |
| 4 | INIT_COMPONENT_EXPORT(fn) | Component initialization, such as file system or LWIP |
| 5 | INIT_ENV_EXPORT(fn) | System environment initialization, such as mounting file systems |
| 6 | INIT_APP_EXPORT(fn) | Application initialization, such as application GUI |
Initialization function actively declares through these macro interfaces, such as INIT_BOARD_EXPORT(rt_hw_usart_init), the linker will automatically collect all the declared initialization functions, placed in the RTI symbol segment, the symbol segment is located in the RO segment of the memory distribution. All functions in this RTI symbol segment are automatically called when the system is initialized.
An important feature of RT-Thread is its high degree of tailorability, which allows for fine-tuning of the kernel and flexible removal of components.
Configuration is mainly done by modifying the file under project directory - rtconfig.h. User can conditionally compile the code by opening/closing the macro definition in the file, and finally achieve the purpose of system configuration and cropping, as follows:
（1）RT-Thread Kernel part
（2）Inter-thread synchronization and communication part, the objects that will be used in this part are semaphores, mutexes, events, mailboxes, message queues, signals, and so on.
（3）Memory Management Part
（4）Kernel Device Object
（5）Automatic Initialization Method
（6）FinSH
（7）About MCU
In practice, the system configuration file rtconfig.h is automatically generated by configuration tools and does not need to be changed manually.
Macro definitions are often used in RT-Thread. For example, some common macro definitions in the Keil compilation environment:
1）rt_inline, definition is as follows, static keyword is to make the function only available for use in the current file; inline means inline, after modification using static, the compiler is recommended to perform inline expansion when calling the function.
2）rt_used，definition is as follows, the purpose of this macro is to explain to the compiler that this code is useful, compilation needs to be saved even if it is not called in the function. For example, RT-Thread auto-initialization uses custom segments, using rt_used will retain custom code snippets.
3）RT_UNUSED，definition is as follows, indicates that a function or variable may not be used. This attribute prevents the compiler from generating warnings.
4）rt_weak，definition is as follows, often used to define functions, when linking the function, the compiler will link the function without the keyword prefix first and link the function modified by weak if it can't find those functions.
5）ALIGN(n)，definition is as follows, is used to align its stored address with n bytes when allocating an address space to an object. Here, n can be the power of 2. Byte alignment not only facilitates quick CPU access, but also save memory space if byte alignment is properly used.
6）RT_ALIGN(size,align)，definition is as follows, to increase size to a multiple of an integer defined by align. For example, RT_ALIGN(13,4) will return to 16.
1.9.1