A d1-h based rt-thread resident system
By residing RT-Thread within the BIOS program of D1-H, providing a unified service interface and interface encapsulation, the programming difficulty and portability issues of RTOS application development are resolved, achieving efficient compilation and application portability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SUZHOU UNIV
- Filing Date
- 2023-02-06
- Publication Date
- 2026-06-23
Smart Images
Figure CN116107629B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of chip technology, and in particular to an RT-THREAD resident system based on D1-H. Background Technology
[0002] Real-time Operating Systems (RTOS) are often used in the development of multi-threaded embedded systems. However, there are still many problems in developing RTOS applications: (1) Different types of RTOS have inconsistent architectures, resulting in a high programming threshold; (2) There are many types of embedded terminals, making RTOS porting difficult. In addition, when hardware is replaced or software is migrated, the application needs to be adjusted to achieve compatibility, which is costly; (3) RTOS is bound to user programs, affecting compilation efficiency, and the kernel program may be accidentally modified, affecting system stability and anti-interference capabilities. If the machine code of RTOS can be physically isolated from user programs without affecting the user programs' use of the services provided by RTOS, the programming difficulty can be reduced and the compilation time of user programs can be saved. Summary of the Invention
[0003] In view of this, the purpose of this application is to propose an RT-THREAD residency system based on D1-H, which can specifically solve the existing problems.
[0004] To achieve the above objectives, this application proposes a D1-H-based RT-THREAD residency system, comprising:
[0005] The user module and the BIOS module include a hardware abstraction layer, an RTOS layer, and an API layer. The RTOS layer includes the RT-Thread kernel.
[0006] Furthermore, the RTOS layer also includes a thread management unit, a synchronization and communication unit, a clock management unit, and a memory management unit.
[0007] Furthermore, the hardware abstraction layer includes driver construction, software components, and a BootLoader unit.
[0008] Furthermore, the API layer includes driver component interfaces, software component interfaces, and RTOS service call interfaces.
[0009] Furthermore, the RTOS layer uses a RISC-V timer as the time tick, and context switching is implemented directly in the task switching function without using software interrupts.
[0010] Furthermore, in the system, the service functions provided by the RT-Thread kernel are placed in the API table of the BIOS program, i.e., the array ComponentFun. The User program redefines the service functions so that the User program can call the service functions provided by RT-Thread Heihe.
[0011] Furthermore, create the Os_Self_API.h header file in the User program to place the redefined RT-Thread prototype functions, related data types, and structures;
[0012] In Os_United_API.c, the service functions are encapsulated again to form a unified interface, which is then stored in Os_United_API.h.
[0013] Furthermore, the startup process of the RT-Thread kernel includes:
[0014] (1) Initialization of related resources: First, initialize the board-level hardware, including the time tick and heap space; second, initialize the delay blocking list; finally, initialize the scheduler, first initialize the thread ready list to be empty, and then initialize the current thread control block pointer to be empty;
[0015] (2) Creating the main thread and idle thread: The main thread is used to create various application threads; the idle thread has the lowest priority by default and will be executed when there are no user threads available for execution in the kernel.
[0016] (3) Start the scheduler: When the scheduler starts, it finds the highest priority thread from the thread ready list and puts it into operation.
[0017] In summary, the advantages of this application and the user experience it brings are: it can lower the programming threshold, improve the portability of applications and increase compilation speed; it analyzes the startup process after RT-Thread residency and designs a residency test experiment with synchronization and communication as examples, and the test results prove the feasibility of RT-Thread residency. Attached Figure Description
[0018] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments disclosed in this application and should not be construed as limiting the scope of this application.
[0019] Figure 1 A schematic diagram of the structure of a D1-H-based RT-THREAD resident system according to an embodiment of this application is shown.
[0020] Figure 2 A flowchart illustrating the startup process after RT-Thread resides according to an embodiment of this application is shown.
[0021] Figure 3 The diagram shows the test results of the synchronization and communication functions after RT-Thread resides according to an embodiment of this application.
[0022] Figure 4 A schematic diagram of the structure of an electronic device provided in one embodiment of this application is shown.
[0023] Figure 5 A schematic diagram of a storage medium provided in one embodiment of this application is shown. Detailed Implementation
[0024] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.
[0025] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.
[0026] RT-Thread is an open-source real-time operating system primarily developed by the Chinese open-source community (versions 3.1.0 and earlier are licensed under the GPLv2+ license, while versions 3.1.0 and later are licensed under the Apache License 2.0). The RT-Thread operating system is not merely a single real-time operating system kernel; it is also a complete application system, encompassing various components related to real-time and embedded systems: the TCP / IP protocol stack, libc interface, graphical user interface, etc.
[0027] This application relies on the GEC architecture, residing RT-Thread within D1-H. Specifically, RT-Thread is embedded in the D1-H underlying layer along with the BIOS program. Simultaneously, the BIOS program provides a unified service call interface to the User program, shielding it from the different service interfaces of various RTOSs. This lowers the programming threshold and improves application portability. Furthermore, because RT-Thread resides in the D1-H underlying layer, it requires no multiple compilations; only the User program needs to be compiled, thus reducing the compilation time of the User program. The block diagram of RT-Thread residing is shown below. Figure 1As shown, it includes: a User module and a BIOS module. The BIOS module includes a Hardware Abstraction Layer (HAL), an RTOS layer, and an API layer. The RTOS layer includes the RT-Thread kernel, a thread management unit, a synchronization and communication unit, a clock management unit, and a memory management unit. The Hardware Abstraction Layer includes driver components, software components, and a BootLoader. The API layer includes driver component interfaces, software component interfaces, and RTOS service call interfaces.
[0028] 1. Analysis and Implementation of Key Points for RT-Thread Residentialization
[0029] Under the GEC architecture, RT-Thread can be ported to the BIOS program and embedded in the hardware's non-volatile memory. The BIOS program provides the service interface for RT-Thread, achieving effective isolation between the system layer and the user layer. The following is an analysis of the key technical aspects of RT-Thread residency.
[0030] (1) The division between Flash and RAM. The premise of RT-Thread residing is to ensure that there are no conflicts with the User program on Flash and RAM. Otherwise, it may cause problems such as code overlap and variable out-of-bounds, resulting in mutual interference.
[0031] (2) Inheritance of System Interrupts. Scheduling is one of the main responsibilities of an RTOS and is the foundation of multithreaded concurrency. After an RT-Thread resides, it needs to maintain the stable operation of the scheduler in the User program. The BIOS and the User program are two independent projects with their own interrupt vector tables. Therefore, the User program must inherit the specific system interrupts that the scheduler depends on for operation, so that the scheduler can work normally after residing. Generally, RTOS scheduling is based on time ticks and combined with software interrupts to complete thread scheduling. However, for D1-H, only the RISC-V timer is used as the time tick, and context switching is directly implemented in the task switching function without using software interrupts. Therefore, the D1-H User program only needs to inherit the BIOS timer interrupt.
[0032] (3) RT-Thread Service Function Calls. After RT-Thread resides, there are no RT-Thread service function implementations in the User program, so the corresponding service interface cannot be called. The service functions provided by RT-Thread are placed in the API table of the BIOS program, i.e., the array ComponentFun, and then redefined by the User program, so that the User program can call the service functions provided by RT-Thread. In addition, RT-Thread defines its own unique data types and related structures, such as rt_int8_t and mutex structures, so they also need to be placed in the User program. For this purpose, the Os_Self_API.h header file is created in the User program to place the redefined RT-Thread prototype functions and related data types and structures. Since the service function forms implemented by different RTOSs are not the same, in order to improve the portability of applications under different RTOSs, the service functions are encapsulated again in Os_United_API.c to form a unified interface and stored in Os_United_API.h. This application encapsulates the commonly used service functions of RT-Thread, as shown in Table 1.
[0033] Table 1 Commonly Used Service Functions of RT-Thread
[0034]
[0035]
[0036] 2RT-Thread startup process after resident
[0037] After RT-Thread resides in D1-H, the process from chip power-on reset to RT-Thread task scheduling involves three stages: BIOS boot, BIOS jump to User, and RT-Thread startup from User. This process can be used... Figure 2 Briefly stated.
[0038] The main tasks of the RT-Thread startup process are:
[0039] (1) Initialization of related resources. First, the board-level hardware is initialized, mainly the time tick and heap space; second, the delay blocking list is initialized, which is a global list of threads that manage delay waiting; finally, the scheduler is initialized, first by initializing the thread ready list to be empty, and then by initializing the current thread control block pointer to be empty.
[0040] (2) Create the main thread and the idle thread. The main thread is used to create various application threads, and it will eventually shut down on its own. The idle thread has the lowest priority by default. It will be executed when there are no user threads available for execution in the kernel, thus keeping the CPU running.
[0041] (3) Start the scheduler. When the scheduler starts, it will find the highest priority thread from the thread ready list and run it.
[0042] 3RT-Thread Residential Test
[0043] The RT-Thread residency test mainly focuses on testing four synchronization and communication methods between threads: events, mutexes, semaphores, and message queues. (1) Events. Interruption and thread communication are achieved through events: when a frame of data is received by the serial port, the red light thread is controlled to turn the red light on and off. (2) Mutexes. Exclusive access to resources by threads is achieved through mutexes: a single-color light mutex is designed so that only one of the three threads (red, yellow, and green) is lit at any given time, without mixing colors. (3) Semaphores. Three threads are designed to request two semaphores, and the relevant information when the threads request, wait for, and release semaphores is printed through the serial port. (4) Message queues. Messages are passed between threads through message queues: whenever the serial port receives a byte, a complete message is placed in the message queue, and the message queue receiving thread retrieves messages from the message queue every second and prints the messages through the serial port. The test results are as follows. Figure 3 As shown in (a) to (d), the test results show that RT-Thread can start and run normally after being hosted, and the basic functions such as thread creation, scheduling, delay, synchronization and communication are normal, which can meet the basic multi-threaded development requirements and verify the feasibility of the hosted system.
[0044] This application also provides an electronic device corresponding to the D1-H-based RT-THREAD resident system provided in the foregoing embodiments, for executing the D1-H-based RT-THREAD resident system. This application does not limit the scope of the embodiments.
[0045] Please refer to Figure 4 This illustrates a schematic diagram of an electronic device provided by some embodiments of this application. For example... Figure 4 As shown, the electronic device 20 includes: a processor 200, a memory 201, a bus 202, and a communication interface 203. The processor 200, the communication interface 203, and the memory 201 are connected via the bus 202. The memory 201 stores a computer program that can run on the processor 200. When the processor 200 runs the computer program, it executes the RT-THREAD resident system based on DI-H provided in any of the foregoing embodiments of this application.
[0046] The memory 201 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 203 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network.
[0047] Bus 202 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. Memory 201 is used to store programs. After receiving execution instructions, processor 200 executes the programs. The RT-THREAD resident system based on D1-H disclosed in any of the foregoing embodiments of this application can be applied to processor 200, or implemented by processor 200.
[0048] The processor 200 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 200 or by instructions in software form. The processor 200 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 201. The processor 200 reads the information in memory 201 and, in conjunction with its hardware, completes the steps of the above method.
[0049] The electronic device provided in this application embodiment and the RT-THREAD resident system based on D1-H provided in this application embodiment are based on the same inventive concept and have the same beneficial effects as the methods they adopt, operate or implement.
[0050] This application also provides a computer-readable storage medium corresponding to the D1-H-based RT-THREAD resident system provided in the foregoing embodiments. Please refer to... Figure 5 The computer-readable storage medium shown is an optical disc 30, on which a computer program (i.e., a program product) is stored. When the computer program is run by a processor, it executes the RT-THREAD resident system based on D1-H provided in any of the foregoing embodiments.
[0051] It should be noted that examples of the computer-readable storage medium may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.
[0052] The computer-readable storage medium provided in the above embodiments of this application and the RT-THREAD resident system based on D1-H provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.
[0053] It should be noted that:
[0054] The algorithms and displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, this application is not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages is for the purpose of disclosing the best mode of implementation of this application.
[0055] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.
[0056] Similarly, it should be understood that, in order to simplify this application and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of this application, various features of this application are sometimes grouped together into a single embodiment, figure, or description thereof. However, this method of disclosure should not be construed as reflecting an intention that the claimed application requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.
[0057] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.
[0058] Furthermore, those skilled in the art will understand that although some embodiments described herein include certain features but not others included in other embodiments, combinations of features from different embodiments are intended to be within the scope of this application and form different embodiments. For example, in the following claims, any of the claimed embodiments can be used in any combination.
[0059] The various component embodiments of this application can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components in the virtual machine creation system according to the embodiments of this application. This application can also be implemented as a device or system program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such an implementation of this application can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.
[0060] It should be noted that the above embodiments are illustrative of this application and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several systems, several of these systems may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.
[0061] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope disclosed in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A D1-H-based RT-THREAD resident system, characterized in that, include: The user module and the BIOS module, wherein the BIOS module includes a hardware abstraction layer, an RTOS layer, and an API layer, and the RTOS layer includes the RT-Thread kernel; The RTOS layer uses a RISC-V timer as the time tick, and context switching is implemented directly in the task switching function without using software interrupts. In the system, the service functions provided by the RT-Thread kernel are placed in the API table of the BIOS program, i.e., the array ComponentFun. The User program redefines the service functions so that the User program can call the service functions provided by RT-Thread Heihe. The startup process of the RT-Thread kernel includes: (1) Initialization of related resources: First, initialize the board-level hardware, including the time tick and heap space; second, initialize the delay blocking list; finally, initialize the scheduler, first initialize the thread ready list to be empty, and then initialize the current thread control block pointer to be empty; (2) Creating the main thread and idle thread: The main thread is used to create various application threads; the idle thread has the lowest priority by default and will be executed when there are no user threads available to execute in the kernel. (3) Start the scheduler: When the scheduler starts, it finds the highest priority thread from the thread ready list and puts it into operation.
2. The system according to claim 1, characterized in that, The RTOS layer also includes a thread management unit, a synchronization and communication unit, a clock management unit, and a memory management unit.
3. The system according to claim 1, characterized in that, The hardware abstraction layer includes driver construction, software components, and a BootLoader unit.
4. The system according to claim 1, characterized in that, The API layer includes driver component interfaces, software component interfaces, and RTOS service call interfaces.
5. The system according to claim 1, characterized in that, In the User program, create the Os_Self_API.h header file to place the redefined RT-Thread prototype functions, related data types, and structures. In Os_United_API.c, the service functions are encapsulated again to form a unified interface, which is then stored in Os_United_API.h.
6. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor runs the computer program to implement the system as described in any one of claims 1-5.
7. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by a processor to implement the system as described in any one of claims 1-5.