Why do we need to tailor the system and how to?

*01*

Why do we need to tailor the system?

When designing an embedded RTOS system, we are looking for a simple and controllable system, so that we can have a clear mind when making a plan.

The essential characteristics of the embedded system are as follows:

• Application-centric
• Low power, small size, and low cost
• Software or hardware is tailorable

These issues should be considered fully in the process of designing embedded products, so when implementing them, we should focus not only on the system-level but also on the demands of business logic.

• Application field
• Research and development cycle
• System complexity
• Chip Resource (ROM and RAM)
• Firmware size requirements
• Start-up speed requirements

From the perspective of embedded system architecture, it is necessary to conform to the principle of high cohesion and low coupling as developers often need to adapt the different peripherals and components during the embedded system development process. Different needs require different changes so that software architecture is needed for adapting different changes, an embedded system architecture designed by high cohesion and low coupling principle is more scalable and more stable.

For bare-metal development, system tailor means reducing or optimizing business logic in a poll operation.

For Linux, system tailoring is to remove unnecessary components or peripherals, as well as tools, to reduce unused system functions, even in the bootloader.

For RTOS, system tailoring can reduce unnecessary component initialization or IPC initialization by removing the functionality. For example, if the project only needs critical IPCs such as signals, mailboxes, then message queues and events do not have to be initialized. In this way, you can shrink the code size and remove unnecessary initialization processes. Besides, by reducing the size of firmware, the start-up time of the system is also shortened, which improves the efficiency of the whole system.

02

RT-Thread is highly tailorable:

RT-Thread was born in 2006. It is an open-source, neutral, and community-based IoT OS.

RT-Thread is mainly written in C language, easy to understand, and supports quickly porting to a variety of mainstream MCUs and module chips. RT-Thread applies the object-oriented method to the real-time system design, which helps to build the system with elegant code, clear architecture, high modularization, and great tailorability.

RT-Thread has a Standard version and Nano version.

For resource-constrained microcontroller (MCU) systems, developers can tailor a Nano kernel that requires only 3KB Flash, 1.2KB RAM through the easy-to-use tools.

For resource-rich IoT devices, RT-Thread Standard version is recommended, which enables intuitive and fast modular tailoring through the online package management tools and system configuration tools, and the standard version can seamlessly import a wealth of software package, to achieve android-like graphical interface and touch sliding effects, smart voice interaction effects and other more complex functions.

The full version of RT-Thread has full functionality but accordingly, as the functionality increases, the resource footprint is also increasing, which is not very friendly for small resource platforms. But as RT-Thread has high tailorability, it is still easy to be used on the platforms with the small resource by tailoring the full version through the env tool provided by RT-Thread, which is shown in the following image:

*03*

*Tailoring*

Resource is tailorable

The resources here refer to both hardware resources and software resources. Hardware resources are basically chosen at the time of design, and it gets finally determined after the reasonable planning and design of the software are done. It includes the allocation of relevant pins, power-up timing, operating rationality, as well as the requirements of power consumption, peripheral situation, pre-software development debugging, post-factory testing. Software developers take advantage of these specified hardware resources to complete the details of the software-level planning. A good hardware design makes the configured product more stable and reliable.

When running RT-Thread, we need to check the hardware’s ROM resources and RAM resources at the beginning of the design to evaluate whether the resources are reasonable to run an RTOS.

For example, the RT-Thread Nano version uses very little RAM and ROM. It needs only 1 KB RAM and 4KB ROM to support the semaphore and mailbox features, and run two threads (main thread + idle threads).

For applications that require a large amount of RAM and ROM, reasonable use of each resource is a good habit. First of all, let’s analyze the use and tailoring of RT-Thread memory.

1.Heap Space

Generally, there is a macro definition of the heap size in the board.h of the specific BSP:

1#define RT_HW_HEAP_BEGIN    (void*)&__bss_end2#define RT_HW_HEAP_END      (void*)(RT_HW_HEAP_BEGIN + 64 * 1024 * 1024)

When designing the system, we need to evaluate the heap space required by the system. Memory management is allocated and released on the memory heap. For scenarios where memory resources are abundant in the chip, large heap space can be allocated for memory management, so that memory usage is more reasonable. For scenarios where memory resources in the chip are relatively limited, try not to use dynamic memory management, the static memory is more appropriate.

The heap space is generally used by allocating memory or creating threads and IPCs dynamically. If we create all the threads and IPCs and only use the static memory, the heap management mechanism could be removed. This is the typical situation in RT-Thread Nano.

2.Thread Stack Space

The stack space allocation is determined according to the complexity of the tasks, for the complex tasks handled in a thread, and the function spent more local variables, as well as the function calling connection is more complex, then the thread needs to be allocated with large stack space, while the task in the thread is relatively simple and the local variables are less used, then the thread can be allocated with a smaller stack space.

The stack is used to store the context of a thread, the size of which must be specified when creating a thread:

Where the size of the stack is generally affected by the firmware function call depth and the required resources. Generally, the maximum value is given at the beginning of development.

If you want to reduce it, here are three methods:

• Run the system for a while and adjust the stack space by the list_thread command.

• In Microcontroller Development Kit (MDK), you can view the Static Call Graph for the image file to see the usage of the stack.

Calculate the depth of the largest stack by checking the Function calling connection file, as shown above.

•Manual calculation

Evaluate the local variable and the call relationship in each function, which needs to be calculated manually. Manual calculations can only approximate the size of the stack because when calling a function, the parameter values of the function and the local variables are pressed into the stack space. To calculate the size of the current thread stack, you need to add up the parameters of the current thread function, the size of the local variables, and the parameters and local variable sizes of the called function. Therefore, we should select the maximum stack space required in the function execution branch as the minimum stack space that needs to be allocated in the thread.

Kernel is tailorable

RT-Thread is composited of is components and kernel. Let’s start with the kernel tailoring, which can be observed through the RT-Thread env tool:

1. Inter-thread communication mechanism

Tailor according to the features or components commonly used in our system.

1. Memory Management

Choose different memory management strategies depending on the specific situation.

1. Kernel Device

Console related configuration.

Components are tailorable

The components help us design specific business logic more efficiently.

• Set the stack space and the priority of the main thread
• Check whether to use the C++
• The configuration of shell-related operations
• Device Virtual File System
• Device-driven framework
• POSIX Interfaces
• Network
• Tools

These tailoring needs to be considered when designing your application.

By using RT-Thread in embedded systems, the complexity of system design would be significantly reduced when implementing up-level applications. However, to make RT-Thread small and efficient, developers have to configure and cut the system according to their needs. The RT-Thread projects are configured and built via the scons tool, which explores Kconfig and SConscripts files to decide how to construct the final products. So, it’s necessary to understand their syntax and principles for users to make the whole system extensible and scalable. Specific instructions about RT-Thread Env and scons, please refer to HERE.

更多