Cross-platform real-time operating system abstraction layer interface

Abstract

The invention relates to the technical field of computers, and provides a cross-platform real-time operating system abstraction layer interface, which is characterized in that a standard library abstraction layer interface of a first real-time operating system and a user-defined abstraction layer interface of a second real-time operating system are uniformly packaged; the cross-platform real-time operation system abstraction layer interface comprises a uniform clock interface, a thread interface supporting real-time scheduling, a synchronous primitive interface supporting real-time characteristics and a cross-platform error processing mechanism; therefore, a unified clock interface, a unified thread scheduling strategy, a unified thread synchronization mechanism and a unified call error expression are provided for different real-time operating systems, the purpose that APIs of different real-time operating systems are integrated through a unified standard interface is achieved, consistent programming experience is provided for developers, the development cost is reduced, and the development efficiency is improved. And the portability and the compatibility of the codes are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, and in particular, relates to a cross-platform real-time operating system abstraction layer interface. BACKGROUND

[0002] In operating system programming, different operating systems and real-time frameworks provide their own unique APIs (Application Programming Interface), such as Xenomai3 and Xenomai4 as real-time operating system frameworks, which have APIs specifically optimized for real-time performance, while standard libraries provide general-purpose, cross-platform APIs. However, this diversity presents many challenges to developers:

[0003] 1) High development cost: Developers need to learn and use different APIs for different operating systems and frameworks, increasing learning costs and development cycles.

[0004] 2) Difficult code porting: When migrating code from one operating system or framework to another, due to API differences, extensive modifications and adjustments to the code are required, increasing the difficulty and risk of porting.

[0005] 3) Compatibility issues: Different APIs have differences in functionality and usage, which can cause compatibility issues in different environments, affecting system stability and reliability.

[0006] Therefore, a unified standard interface is needed to integrate the APIs of Xenomai3, Xenomai4, and standard libraries to solve the above technical problems. SUMMARY

[0007] Therefore, the embodiments of the present application provide a cross-platform real-time operating system abstraction layer interface to solve the problem of high development cost and low efficiency caused by different operating systems and real-time frameworks using their own unique APIs in the prior art.

[0008] In a first aspect, the embodiments of the present application provide a cross-platform real-time operating system abstraction layer interface, the real-time operating system at least including a first real-time operating system and a second real-time operating system, the first real-time operating system having a standard library abstraction layer interface, and the second real-time operating system having a custom abstraction layer interface.

[0009] The cross-platform real-time operating system abstraction layer interface includes:

[0010] A unified clock interface, which is obtained by uniformly encapsulating the standard clock interface of the first real-time operating system and the custom clock interface of the second real-time operating system, is used to provide a unified clock interface for different real-time operating systems.

[0011] The thread interface supporting real-time scheduling is obtained by uniformly encapsulating the standard thread interface of the first real-time operating system and the customized thread interface of the second real-time operating system, and is used to provide a unified thread scheduling strategy for different real-time operating systems.

[0012] The synchronization primitive interface supporting real-time features is obtained by uniformly encapsulating the standard synchronization primitive interface of the first real-time operating system and the customized synchronization primitive interface of the second real-time operating system, and is used to provide a unified thread synchronization mechanism for different real-time operating systems.

[0013] The cross-platform error handling mechanism is used to provide a unified call error representation for different real-time operating systems.

[0014] Compared with the prior art, the embodiment of the present application has the beneficial effects that: the embodiment of the present application uniformly encapsulates the standard library abstraction layer interface of the first real-time operating system and the customized abstraction layer interface of the second real-time operating system, obtains the cross-platform real-time operating system abstraction layer interface including the unified clock interface, the thread interface supporting real-time scheduling, the synchronization primitive interface supporting real-time features, and the cross-platform error handling mechanism, thereby providing a unified clock interface, a unified thread scheduling strategy, a unified thread synchronization mechanism, and a unified call error representation for different real-time operating systems, realizing the integration of APIs of different real-time operating systems using a unified standard interface, providing developers with consistent programming experience, reducing development cost, and improving the portability and compatibility of code. BRIEF DESCRIPTION OF DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort on the basis of these drawings.

[0016] Figure 1 is a structure diagram of a cross-platform real-time operating system abstraction layer interface provided by the embodiment of the present application.

[0017] Figure 2 is a structure diagram of functional modules included in the unified clock interface provided by the embodiment of the present application.

[0018] Figure 3 is a structure diagram of functional modules included in the synchronization primitive interface provided by the embodiment of the present application.

[0019] Figure 4is a structural schematic diagram of a functional module included in a thread interface provided by an embodiment of the present application.

[0020] Figure 5 is a flowchart of a method for determining task priorities and target scheduling strategies of threads provided by an embodiment of the present application.

[0021] Figure 6 is a system architecture diagram of an embodiment of the present application. DETAILED DESCRIPTION

[0022] In the following description, for the purpose of explanation and not limitation, specific details are set forth, such as particular system configurations, techniques, etc., in order to provide a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application can be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

[0023] A cross-platform real-time operating system abstraction layer interface according to an embodiment of the present application will be described in detail below with reference to the accompanying drawings.

[0024] As mentioned above, different operating systems and real-time frameworks provide their own unique APIs, and this diversity brings many challenges to developers, such as high development cost, difficult code porting, and poor compatibility.

[0025] In view of this, an embodiment of the present application provides a cross-platform real-time operating system abstraction layer interface, which unifies a standard library abstraction layer interface of a first real-time operating system and a custom abstraction layer interface of a second real-time operating system to obtain a cross-platform real-time operating system abstraction layer interface including a unified clock interface, a thread interface supporting real-time scheduling, a synchronization primitive interface supporting real-time features, and a cross-platform error handling mechanism, thereby providing a unified clock interface, a unified thread scheduling strategy, a unified thread synchronization mechanism, and a unified call error expression for different real-time operating systems, realizing integration of APIs of different real-time operating systems using a unified standard interface, providing developers with consistent programming experience, reducing development cost, and improving code portability and compatibility.

[0026] Figure 1 is a structural schematic diagram of a cross-platform real-time operating system abstraction layer interface provided by an embodiment of the present application. As shown in Figure 1 the cross-platform real-time operating system abstraction layer interface includes the following components:

[0027] a unified clock interface 101 unifiedly encapsulating a standard clock interface of the first real-time operating system and a custom clock interface of the second real-time operating system, for providing a unified clock interface for different real-time operating systems.

[0028] a thread interface 102 supporting real-time scheduling, the thread interface unifiedly encapsulating a standard thread interface of the first real-time operating system and a custom thread interface of the second real-time operating system, for providing a unified thread scheduling strategy for different real-time operating systems.

[0029] a synchronization primitive interface 103 supporting real-time features, the synchronization primitive interface unifiedly encapsulating a standard synchronization primitive interface of the first real-time operating system and a custom synchronization primitive interface of the second real-time operating system, for providing a unified thread synchronization mechanism for different real-time operating systems.

[0030] a cross-platform error handling mechanism 104, for providing a unified call error representation for different real-time operating systems.

[0031] In some embodiments of the present application, the abstraction layer interface of the cross-platform real-time operating system is a unified standard interface, for providing a unified standard interface for various different real-time operating systems. The real-time operating system can include a first real-time operating system and a second real-time operating system, the first real-time operating system having a standard library abstraction layer interface, and the second real-time operating system having a custom abstraction layer interface.

[0032] The first real-time operating system can include one or more different real-time operating systems, and the second real-time operating system can also include multiple different real-time operating systems. In an example, the second real-time operating system can include, for example, a Xenomai3 operating system and a Xenomai4 operating system.

[0033] In some embodiments, platform differentiation can be implemented through a trait mechanism, the first real-time operating system using a Rust native API, and the second real-time operating system using a custom dedicated API.

[0034] In some embodiments of the present application, the cross-platform real-time operating system abstraction layer interface can include a unified clock interface, which can be unifiedly encapsulated by a standard clock interface of the first real-time operating system and a custom clock interface of the second real-time operating system, and used to provide a unified clock interface for different real-time operating systems.

[0035] In an example, the Xenomai3 operating system and the Xenomai4 operating system do not include a native clock interface, and thus a custom clock interface is needed. The custom clock interface can be first written for these real-time operating systems, and then the custom clock interface is uniformly encapsulated with a standard clock interface of a standard library to obtain a uniform clock interface. When calling the clock interface, any real-time operating system only needs to call the uniform clock interface, and then determine the corresponding standard clock interface or custom clock interface in the uniform clock interface.

[0036] In some embodiments of the present application, the cross-platform real-time operating system abstraction layer interface can include a thread interface supporting real-time scheduling, which is uniformly encapsulated by a standard thread interface of a first real-time operating system and a custom thread interface of a second real-time operating system, and is used to provide a uniform thread scheduling strategy for different real-time operating systems.

[0037] In an example, the Xenomai3 operating system and the Xenomai4 operating system do not include a native thread interface, and thus a custom thread interface is needed. The custom thread interface can be first written for these real-time operating systems, and then the custom thread interface is uniformly encapsulated with a standard thread interface of a standard library to obtain a uniform thread interface. When calling the thread interface, any real-time operating system only needs to call the uniform thread interface, and then determine the corresponding standard thread interface or custom thread interface in the uniform thread interface.

[0038] In some embodiments of the present application, the cross-platform real-time operating system abstraction layer interface can include a synchronization primitive interface supporting real-time features, which is uniformly encapsulated by a standard synchronization primitive interface of a first real-time operating system and a custom synchronization primitive interface of a second real-time operating system, and is used to provide a uniform thread synchronization mechanism for different real-time operating systems.

[0039] In an example, the Xenomai3 operating system and the Xenomai4 operating system do not include a native synchronization primitive interface, and thus a custom synchronization primitive interface is needed. The custom synchronization primitive interface can be first written for these real-time operating systems, and then the custom synchronization primitive interface is uniformly encapsulated with a standard synchronization primitive interface of a standard library to obtain a uniform synchronization primitive interface. When calling the synchronization primitive interface, any real-time operating system only needs to call the uniform synchronization primitive interface, and then determine the corresponding standard synchronization primitive interface or custom synchronization primitive interface in the uniform synchronization primitive interface.

[0040] In some embodiments of the present application, the cross-platform real-time operating system abstraction layer interface can further include a cross-platform error handling mechanism, which is used to provide a uniform call error representation for different real-time operating systems.

[0041] That is, the cross-platform real-time operating system abstraction layer interface can also provide a unified call error representation for different real-time operating systems, thereby achieving cross-platform error handling and providing work efficiency.

[0042] According to the technical scheme provided in the embodiments of the present application, by uniformly encapsulating the standard library abstraction layer interface of the first real-time operating system and the custom abstraction layer interface of the second real-time operating system, a cross-platform real-time operating system abstraction layer interface including a unified clock interface, a thread interface supporting real-time scheduling, a synchronization primitive interface supporting real-time features, and a cross-platform error handling mechanism is obtained, thereby providing a unified clock interface, a unified thread scheduling strategy, a unified thread synchronization mechanism, and a unified call error expression for different real-time operating systems, realizing the integration of APIs of different real-time operating systems using a unified standard interface, providing developers with consistent programming experience, reducing development costs, and improving the portability and compatibility of the code.

[0043] Figure 2 is a structural schematic diagram of the functional modules included in the unified clock interface provided in the embodiments of the present application. As shown in Figure 2 , the unified clock interface includes the following components:

[0044] A time point abstraction 201 is configured to provide a time point acquisition method, a time interval calculation method, and an anti-overflow time calculation method for each real-time operating system.

[0045] A time interval abstraction 202 is configured to provide an anti-overflow time interval calculation method for each real-time operating system.

[0046] A clock source abstraction 203 is configured to provide at least one of a monotonic clock and a system clock for each real-time operating system.

[0047] A sleep interface 204 is configured to provide at least one of a relative time sleep interface and an absolute time sleep interface for each real-time operating system.

[0048] In some embodiments of the present application, the time point abstraction can be configured to provide a time point acquisition method and a time interval calculation method for each real-time operating system, and the time point abstraction can be implemented using an Instant method.

[0049] Further, many time processing libraries in the related art do not have a perfect overflow checking mechanism when performing time addition and subtraction operations. When performing time calculation, overflow may occur, which can cause undefined behavior of the program, such as calculating an incorrect timestamp, affecting the stability and accuracy of the system. Therefore, the time point abstraction provided in the embodiments of the present application can also provide an anti-overflow time calculation method for each real-time operating system.

[0050] In an example, overflow checks can be performed at runtime by the checked_add and checked_sub methods to avoid problems caused by overflow.

[0051] In some embodiments of the present application, the time interval calculation method can include at least one of the duration_since, checked_duration_since, saturating_duration_since and elapsed methods. The various time measurement methods can be adapted to different application scenarios.

[0052] In some embodiments of the present application, the time interval abstraction can be used to provide an anti-overflow time interval calculation method for each real-time operating system. The time interval abstraction can be implemented using the Duration method.

[0053] In related technologies, when calculating the time difference, some implementation schemes can simply return an error code or throw an exception without providing detailed error information, making it difficult for developers to handle according to specific circumstances. Therefore, the time point abstraction provided in the embodiments of the present application can also be configured to return a SystemTimeError if the target time is later than the current time when calculating the time difference, and provide the Duration method to obtain the time difference that caused the error, facilitating developers to handle specifically.

[0054] In some embodiments of the present application, the clock source abstraction can be used to provide at least one of a monotonic clock and a system clock for each real-time operating system, and the sleep interface can be used to provide at least one of a relative time sleep interface and an absolute time sleep interface for each real-time operating system.

[0055] An example of the unified clock interface provided in the embodiments of the present application is shown in the following code:

[0056]

[0057]

[0058] It can be understood that, in addition to being implemented by the Rust language, the code can also be implemented by the C language.

[0059] Figure 3 FIG. 1 is a structural diagram of a function module included in the synchronization primitive interface provided in the embodiments of the present application. As shown in the figure, the synchronization primitive interface includes the following components: Figure 3

[0060] The mutex 301 and the read-write lock 302 are used to provide a unified read-write synchronization mechanism for threads in each real-time operating system. ​

[0061] a condition variable interface 303 configured to provide a uniform condition synchronization mechanism for threads in each real-time operating system.

[0062] a barrier interface 304 configured to provide a uniform concurrency synchronization mechanism for threads in each real-time operating system.

[0063] a one-time initialization interface 305 configured to provide a uniform initialization synchronization mechanism for threads in each real-time operating system.

[0064] In some embodiments of the present application, the synchronization primitive interface can be configured with a mutex (Mutex) and a read-write lock (RwLock) to provide a uniform read-write synchronization mechanism for threads in each real-time operating system, a condition variable interface to provide a uniform condition synchronization mechanism for threads in each real-time operating system, and a barrier interface to provide a uniform concurrency synchronization mechanism for threads in each real-time operating system. The Mutex can be configured as an RAII lock protection type to ensure automatic release of the lock.

[0065] In some embodiments, the read-write lock at least includes try_read and try_write implementation methods.

[0066] On the other hand, to ensure that each code block implementing the uniform interface is executed only once in a multi-threaded environment, the synchronization primitive interface can also be configured with a one-time initialization interface to provide a uniform initialization synchronization mechanism for threads in each real-time operating system.

[0067] In some embodiments of the present application, the synchronization primitive interface can also be configured with a lock creation mechanism and a lock destruction mechanism, where the lock creation mechanism can be implemented based on the new_unsized method, and the lock destruction mechanism can be implemented based on the into_inner method, which allows the read-write lock to be acquired without blocking, improving concurrency performance.

[0068] In some embodiments of the present application, the synchronization primitive interface can also be configured with a lock creation mechanism and a lock destruction mechanism, thereby implementing dynamic lock management. In an example, the lock creation mechanism can be implemented based on the new_unsized method to facilitate handling of dynamically sized locks, and the lock destruction mechanism can be implemented based on the into_inner method to facilitate resource release.

[0069] In some embodiments of the present application, the synchronization primitive interface can also be configured with a lock poisoning processing mechanism, which at least includes a PoisonError error type and a TryLockError error type to provide explicit error handling for lock poisoning situations and enhance the robustness of the system.

[0070] An exemplary code implementation of the synchronization primitive interface provided by the embodiments of the present application is shown as follows:

[0071]

[0072]

[0073] The parallelism degree obtained by the abstraction layer interface in the related art is inaccurate in thread management, and the thread management library obtains the parallelism degree of the system through fixed configuration or simple system call, without considering the dynamic change of system resources, so that the obtained parallelism degree is inaccurate, affecting the scheduling of threads and resource utilization.

[0074] Therefore, the embodiments of the present application can obtain the available parallelism degree of the system through the available_parallelism method, and dynamically adjust according to the change of system resources, so as to improve the scheduling efficiency of threads and resource utilization. Meanwhile, the Builder mode can be used to create threads, and the name, stack size, CPU affinity, scheduling policy and other parameters of the threads can be conveniently set, so that the creation and management process of threads is simplified.

[0075] Figure 4 is a structural schematic diagram of the functional modules included in the thread interface provided by the embodiments of the present application. As shown in Figure 4 , the thread interface includes the following components:

[0076] The scheduling policy 401 is configured to provide different scheduling policies for each real-time operating system.

[0077] The thread builder 402 is configured to build threads in each real-time operating system, and the threads are at least configured with a task priority and a target scheduling policy, the target scheduling policy is one of the scheduling policies, and the target scheduling policy is determined based on at least the task priority.

[0078] In some embodiments of the present application, the thread interface can include a thread builder and a scheduling policy, the scheduling policy can include a FIFO (First In First Out) scheduling policy and a RR (Round Robin) scheduling policy for the Xenomai real-time operating system, and can also include other scheduling policies, which are not limited here.

[0079] The thread constructor can be used to construct threads in real-time operating systems. When constructing threads, the improved available_parallelism method can be used to dynamically obtain and adjust the parallelism of each thread, thereby reducing the dependence of system implementation and adapting to changes in system resources. In an example, at least the task priority and target scheduling strategy of the thread are configured, and the task priority and target scheduling strategy can be adjusted in real time according to changes in system resources, or can also be adjusted in real time according to changes in the task demand corresponding to the thread, thereby improving the performance and resource utilization of the system.

[0080] In some embodiments, the value range of the task priority can be set to 0 to 99, and the higher the value, the higher the priority.

[0081] An example of the code implementation of the thread interface provided by the embodiments of the present application is as follows:

[0082]

[0083]

[0084] Figure 5 is a flowchart of the method for determining the task priority and target scheduling strategy of each thread provided by the embodiments of the present application. As shown in Figure 5 , the method comprises the following steps:

[0085] In step S501, the real-time requirement is determined based on at least the task execution time and task deadline of the target thread.

[0086] In step S502, the load condition of the real-time operating system in which the target thread is located is obtained.

[0087] In step S503, the task priority of the target thread is determined in real time based on the real-time requirement and the load condition.

[0088] In step S504, the target scheduling strategy of the target thread is determined based on at least the real-time determined task priority.

[0089] The target thread is any thread in the real-time operating system.

[0090] In some embodiments of the present application, the real-time requirement can be first determined based on parameters such as the task execution time and task deadline of the target thread. Then the load condition of the real-time operating system in which the target thread is located is obtained, including CPU utilization, memory usage, etc. Next, the task priority of the target thread is determined in real time based on the real-time requirement and the load condition, and the task priority is adjusted in real time. Finally, the target scheduling strategy of the target thread is determined according to the real-time determined task priority.

[0091] That is, the task real-time evaluation module, the system load detection module, the priority adjustment module and the scheduling module can be configured in the real-time operating system, the task real-time evaluation module evaluates the real-time requirement of each task, the system load detection module monitors the load condition of the system in real time, the priority adjustment module dynamically adjusts the priority of the task according to the evaluation result and the load condition, and the scheduling module schedules the task according to the adjusted priority.

[0092] In a specific implementation, the task real-time evaluation module, the system load detection module, the priority adjustment module and the scheduling module can be initialized first. Then the task real-time evaluation module evaluates the real-time requirement of each task, and the system load detection module monitors the load condition of the system in real time. The priority adjustment module dynamically adjusts the priority of the task according to the evaluation result and the load condition, and the scheduling module schedules the task according to the adjusted priority. The above evaluation and adjustment steps are repeated until the system stops running.

[0093] In some embodiments of the present application, the thread interface can also be used to provide an independent log thread for each log instance. Among them, the log path of each log thread can be configured in a zero heap allocation manner. Each log thread can be configured to support at least one backend output, and the log output characteristics can be configured. In addition, each log thread can be configured to support a global initialization mode.

[0094] That is, a thread-safe asynchronous design can be introduced to provide an independent log thread for each log instance, realize non-blocking writing, and improve the performance of log writing, especially in high-concurrency scenarios.

[0095] ArrayString can also be used to complete log formatting, implement full-stack operation, and thus realize zero-heap allocation of log paths, avoiding the performance overhead and memory fragmentation problems caused by heap allocation.

[0096] Each log thread can be configured to support at least one backend output, including but not limited to stdout (with color), file (supporting conversion / compression / max retention days and pieces), syslog (supporting custom Facility), and various backend outputs to meet the log recording needs of different scenarios.

[0097] At the same time, the log output characteristics can be set to configuration. For example, the extensibility of log output can be realized through an extensible LogOutput Trait, making it easy for developers to customize their own log backend.

[0098] In addition, each log thread can also be configured to support a global initialization mode, including supporting a global logger initialization utility definition mode to facilitate developers to perform unified log management.

[0099] In some embodiments of the present application, the second real-time operating system can include a Xenomai operating system. At this time, the unified clock interface uses the clock_gettime(CLOCK_MONOTONIC) function of the Xenomai operating system to obtain a high-precision time point, the synchronization primitive interface is configured to enable the priority inheritance mechanism of the Xenomai operating system to prevent priority inversion. In addition, the scheduling strategy at least includes a first-in-first-out scheduling strategy and a round-robin scheduling strategy, and the first-in-first-out scheduling strategy and the round-robin scheduling strategy are used to schedule threads in the Xenomai operating system.

[0100] In the related art, there can be a large amount of repeated code in different projects or modules, which increases the code maintenance cost and the risk of error. In addition, the configuration files of some projects are scattered in different directories, lack unified management, and are prone to cause inconsistent configuration problems.

[0101] Therefore, the cross-platform real-time operating system abstraction layer interface in the embodiments of the present application can be implemented using a code reuse mechanism. Through modular design and code reuse, the code structure is optimized, code duplication is eliminated, modular design and code reuse mechanisms are adopted, and the maintainability and scalability of the code are improved. At the same time, the configuration file management can also be unified. By centrally managing related configuration files, the problem of inconsistent configuration is avoided, and the development efficiency and code quality are improved.

[0102] In other embodiments, the timer operation of the abstraction layer interface can also be configured.

[0103] For example, the use flexibility of the timer in different thread environments can be improved by eliminating the restriction that the wait method only supports use in the evl thread. For another example, the zero-length or more flexible start condition of the timer can be supported by relaxing the start condition of the timer to meet the needs of different scenarios.

[0104] The technical solution of the embodiments of the present application provides a unified standard interface based on Xenomai3, Xenomai4 and standard library API. By abstracting and encapsulating the APIs of different operating systems and frameworks, a consistent programming interface is provided for developers to achieve seamless business development, reduce development costs, and improve the portability and compatibility of the code.

[0105] Figure 6 is a system architecture diagram of the embodiments of the present application. As Figure 6As shown, the standard thread interface, clock interface, synchronization primitive interface, event interface and monitoring interface can be configured in a platform using a standard library, i.e., a first real-time operating system, the custom thread interface, clock interface, synchronization primitive interface, event interface and monitoring interface are configured in Xenomai3 and Xenomai4 platforms respectively, and then the interfaces are uniformly encapsulated at the operating system layer and provided to the user in the form of a uniform standard interface.

[0106] The technical scheme provided in the embodiments of the present application can provide a cross-platform real-time operating system abstraction layer interface. The abstraction layer interface mainly revolves around thread management and timers. In terms of thread management, the Builder mode is used to create threads, and parameters such as thread name, stack size, CPU affinity, scheduling strategy and the like can be set. In terms of timer operation, a Timer structure is provided, which has functions such as starting, waiting, canceling and checking status. Each real-time operating system can implement the related API functions by calling the unified abstraction layer interface, thereby reducing the development complexity and cost and improving the development efficiency.

[0107] All the optional technical schemes described above can be combined to form optional embodiments of the present application, and will not be described again here.

[0108] It should be understood that the size of the serial number of each step in the above embodiments does not mean the order of execution, and the execution order of each process should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0109] The above embodiments are only used to illustrate the technical scheme of the present application, but not to limit it; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical scheme recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical scheme deviate from the spirit and scope of the technical scheme of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A cross-platform real-time operating system abstraction layer interface, comprising: The real-time operating systems include at least a first real-time operating system and a second real-time operating system, the first real-time operating system having a standard library abstraction layer interface, and the second real-time operating system having a custom abstraction layer interface; The cross-platform real-time operating system abstraction layer interface includes: a unified clock interface, which is unifiedly encapsulated by a standard clock interface of the first real-time operating system and a custom clock interface of the second real-time operating system, and is used to provide a unified clock interface for different real-time operating systems; a thread interface supporting real-time scheduling, which is unifiedly encapsulated by a standard thread interface of the first real-time operating system and a custom thread interface of the second real-time operating system, and is used to provide a unified thread scheduling strategy for different real-time operating systems; a synchronization primitive interface supporting real-time features, which is unifiedly encapsulated by a standard synchronization primitive interface of the first real-time operating system and a custom synchronization primitive interface of the second real-time operating system, and is used to provide a unified thread synchronization mechanism for different real-time operating systems; a cross-platform error handling mechanism, which is used to provide a unified call error representation for different real-time operating systems.

2. The cross-platform real-time operating system abstraction layer interface of claim 1, wherein, The unified clock interface includes at least a time point abstraction, a time interval abstraction, a clock source abstraction, and a sleep interface; the time point abstraction is used to provide a time point acquisition method, a time interval calculation method, and an anti-overflow time calculation method for each real-time operating system; the time interval abstraction is used to provide an anti-overflow time interval calculation method for each real-time operating system; the clock source abstraction is used to provide at least one of a monotonic clock and a system clock for each real-time operating system; the sleep interface is used to provide at least one of a relative time sleep interface and an absolute time sleep interface for each real-time operating system.

3. The cross-platform real-time operating system abstraction layer interface of claim 2, wherein, The time interval calculation method includes at least one of duration_since, checked_duration_since, saturating_duration_since, and elapsed methods.

4. The cross-platform real-time operating system abstraction layer interface of claim 1, wherein, The synchronization primitive interface includes at least a mutex, a read-write lock, a condition variable interface, a barrier interface, and a one-time initialization interface; the mutex and the read-write lock provide a unified read-write synchronization mechanism for threads in each real-time operating system; the condition variable interface provides a unified condition synchronization mechanism for threads in each real-time operating system; the barrier interface provides a unified concurrent synchronization mechanism for threads in each real-time operating system; the one-time initialization interface provides a unified initialization synchronization mechanism for threads in each real-time operating system.

5. The cross-platform real-time operating system abstraction layer interface of claim 4, wherein, The read-write lock includes at least try_read and try_write implementation methods; the synchronization primitive interface further includes a lock creation mechanism and a lock destruction mechanism, the lock creation mechanism is implemented based on a new_unsized method, and the lock destruction mechanism is implemented based on an into_inner method; The synchronization primitive interface further comprises a lock poisoning processing mechanism, which comprises at least a PoisonError error type and a TryLockError error type.

6. The cross-platform real-time operating system abstraction layer interface of claim 1, wherein, The thread interface comprises at least a thread constructor and a scheduling policy; The thread constructor is configured to construct threads in each real-time operating system, and each thread is configured with at least a task priority and a target scheduling policy, the target scheduling policy being one of the scheduling policies, and the target scheduling policy being determined based on at least the task priority.

7. The cross-platform real-time operating system abstraction layer interface of claim 6, wherein, The task priority and the target scheduling policy of each thread are determined in the following manner: The real-time requirement is determined based on at least a task execution time and a task deadline of a target thread; The load condition of the real-time operating system in which the target thread is located is obtained; The task priority of the target thread is determined in real time based on the real-time requirement and the load condition; The target scheduling policy of the target thread is determined based on at least the task priority determined in real time; The target thread is any thread in each real-time operating system.

8. The cross-platform real-time operating system abstraction layer interface of claim 6, wherein, The thread interface is further configured to provide an independent log thread for each log instance; The log path of each log thread is configured using zero heap allocation; Each log thread is configured to support at least one backend output, and the log output characteristics are configurable; Each log thread is configured to support a global initialization mode.

9. The cross-platform real-time operating system abstraction layer interface of claim 1, wherein, The second real-time operating system comprises a Xenomai operating system; The unified clock interface is configured to obtain a high-precision time point using a clock_gettime(CLOCK_MONOTONIC) function of the Xenomai operating system; The synchronization primitive interface is configured to enable a priority inheritance mechanism in the Xenomai operating system to prevent priority inversion; The scheduling policy comprises at least a first-in-first-out scheduling policy and a round-robin scheduling policy, which are used to schedule threads in the Xenomai operating system.

10. The cross-platform real-time operating system abstraction layer interface according to any one of claims 1 to 9, wherein, The cross-platform real-time operating system abstraction layer interface is implemented using a code reuse mechanism.

Images