Real-time kernel-oriented program real-time compiling method and device and storage medium

Abstract

The application provides a real-time kernel-oriented program real-time compiling method and device and storage medium. The method comprises the following steps: constructing and running an operating system with real-time kernel capability on a target hardware platform, determining a real-time interface library and a real-time device driver model of the operating system as a dependence for compiling and linking; performing real-time modification on a high-level language compiler and a runtime key library to generate a modified tool chain, wherein the real-time modification comprises introducing the real-time interface library into the construction and linking configuration of the runtime key library, incorporating interfaces and data structures of the real-time device driver model into the visible range of the runtime key library, and setting real-time constraints on concurrent scheduling and timer mechanism; and using the modified tool chain to compile application source code, introducing the real-time interface library in the linking stage, and obtaining a real-time application program running on the operating system. The application can realize real-time compiling without source code modification, unified interface adaptation, cross-architecture reuse and deterministic running.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus and storage medium for real-time program compilation for real-time kernels. Background Technology

[0002] Industrial IoT scenarios place high demands on the determinism and low jitter of edge software. A common approach is to implement the protocol stack, control, and drivers in low-level languages ​​such as C on systems with real-time kernels. While this approach can meet time constraints, it suffers from low development efficiency, high learning costs, and requires significant modifications to incompatible interfaces, clocks, and interrupt models when porting to different processor architectures or real-time operating systems.

[0003] The Go programming language, which has emerged in recent years, boasts advantages such as concise syntax, concurrency friendliness, and a rich ecosystem. It also has ample resources for industrial protocols and edge applications, significantly improving engineering efficiency. However, its native compiled artifacts are affected by runtime scheduling and garbage collection, and system calls and timing precision are constrained by the general-purpose kernel, making it difficult to directly meet hard real-time requirements. Xenomai provides a real-time interface library and device driver model, supporting deterministic scheduling and high-precision timing. However, existing technologies lack a systematic approach to compiling Go applications into real-time applications without modifying the source code at the toolchain and runtime levels. They also lack a unified solution for real-time interface mapping, device access adaptation, and cross-architecture reuse, resulting in insufficient efficiency in real-time development and porting, and fragmented deterministic assurance mechanisms. Summary of the Invention

[0004] In view of this, embodiments of this application provide a real-time program compilation method, apparatus and storage medium for real-time kernels, in order to solve the problems of low development and porting efficiency, difficulty in meeting deterministic real-time constraints without modifying the source code, and lack of a unified real-time interface and device access compilation and linking adaptation mechanism in the prior art.

[0005] A first aspect of this application provides a real-time compilation method for programs with a real-time kernel, comprising: building and running an operating system with real-time kernel capabilities on a target hardware platform; determining the real-time interface library and real-time device driver model of the operating system as dependencies for compilation and linking; performing real-time modifications on a high-level language compiler and runtime key libraries to generate a modified toolchain, wherein the real-time modifications include introducing a real-time interface library in the construction and linking configuration of the runtime key library, including the interfaces and data structures of the real-time device driver model in the visibility scope of the runtime key library, and setting real-time constraints on concurrent scheduling and timer mechanisms; compiling the application source code using the modified toolchain, introducing the real-time interface library in the linking stage, and obtaining a real-time application running on the operating system; wherein the runtime key library configures real-time key concurrent units during execution, the configuration including specifying the priority of underlying real-time tasks for the real-time key concurrent units, specifying processor affinity for the real-time key concurrent units, and performing restricted encapsulation of system calls that cause non-deterministic blocking; the configuration is integrated into the real-time application along with the runtime key library during the compilation and linking process.

[0006] A second aspect of this application provides a real-time program compilation apparatus for a real-time kernel, comprising: a construction module for building and running an operating system with real-time kernel capabilities on a target hardware platform, determining the real-time interface library and real-time device driver model of the operating system as dependencies for compilation and linking; a modification module for performing real-time modifications on a high-level language compiler and runtime key libraries to generate a modified toolchain, wherein the real-time modification includes introducing a real-time interface library in the construction and linking configuration of the runtime key library, including the interfaces and data structures of the real-time device driver model within the visibility scope of the runtime key library, and setting real-time constraints on concurrent scheduling and timer mechanisms; and a compilation module for compiling the application source code using the modified toolchain, introducing the real-time interface library during the linking stage, and obtaining a real-time application running on the operating system; wherein the runtime key library configures real-time key concurrent units during execution, the configuration including specifying the priority of underlying real-time tasks for the real-time key concurrent units, specifying processor affinity for the real-time key concurrent units, and restrictively encapsulating system calls that generate non-deterministic blocking; the configuration is integrated into the real-time application along with the runtime key library during the compilation and linking process.

[0007] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0008] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0009] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0010] This paper describes a method for developing and running an operating system with a real-time kernel on a target hardware platform. The real-time interface library and real-time device driver model of the operating system are identified as dependencies for compilation and linking. The high-level language compiler and runtime critical libraries are modified for real-time operation, generating a modified toolchain. This real-time modification includes introducing the real-time interface library into the construction and linking configuration of the runtime critical library, bringing the interfaces and data structures of the real-time device driver model into the visibility of the runtime critical library, and setting real-time constraints on concurrent scheduling and timer mechanisms. The modified toolchain is used to compile the application source code, introducing the real-time interface library during the linking stage to obtain a real-time application running on the operating system. During execution, the runtime critical library configures real-time critical concurrency units, including specifying the priority of underlying real-time tasks for each unit, specifying processor affinity, and encapsulating system calls that cause non-deterministic blocking. This configuration is integrated into the real-time application along with the runtime critical library during compilation and linking. This application enables real-time compilation without modifying the source code, unified interface adaptation, cross-architecture reuse, and deterministic execution. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart illustrating the real-time program compilation method for a real-time kernel provided in an embodiment of this application;

[0013] Figure 2 This is a schematic diagram of the structure of a real-time program compilation device for a real-time kernel provided in an embodiment of this application;

[0014] Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0015] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0016] The Industrial Internet of Things (IIoT) field has high requirements for software real-time performance. Components requiring high real-time performance can only be developed using low-level languages ​​like C. However, C language development presents the following problems:

[0017] 1. Low development efficiency and high learning cost, especially for low-level languages;

[0018] 2. When porting existing software source code to different system architectures or different real-time operating systems, some additional development and porting work is required, such as the need to make targeted design changes to non-POSIX interfaces used in the program.

[0019] Therefore, in general, existing real-time software development and porting methods suffer from low development efficiency.

[0020] Currently, Golang has the following advantages and disadvantages: Golang has an active community, many open-source projects related to industrial protocols and applications, high development efficiency, and low development cost, but programs developed and compiled from native Golang do not have real-time performance.

[0021] In view of the problems existing in the prior art, this application provides a real-time software compilation method based on Xenomai and Golang. This application will solve these problems by combining Xenomai and Golang, making the development and porting of real-time applications simple and efficient. This application provides a low-cost real-time software compilation method, making the development and porting of software simple and efficient.

[0022] The main technical concept of this application is briefly described below, with specific details as follows:

[0023] This application presents a method for adapting to the application ecosystem of a real-time operating system based on Xenomai, which can compile non-real-time applications developed in the Golang programming language into real-time applications and run them on the aforementioned real-time operating system.

[0024] This invention relates to building a real-time Linux operating system using Xenomai, employing both cobalt and mercury methods. The invention is effective for real-time operating systems built using either of these methods.

[0025] By using the native Go compilation toolchain and the gccgo or gc compiler, and modifying the compiler to integrate with the real-time API provided by the Xenomai framework, Go source code can be compiled into real-time applications.

[0026] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0027] Figure 1 This is a flowchart illustrating a real-time program compilation method for a real-time kernel provided in an embodiment of this application. For example... Figure 1 As shown, this real-time program compilation method for real-time kernels can specifically include:

[0028] S101 builds and runs an operating system with real-time kernel capabilities on the target hardware platform, and determines the real-time interface library and real-time device driver model of the operating system as dependencies for compilation and linking.

[0029] S102, real-time modifications are made to the high-level language compiler and runtime critical libraries to generate a modified toolchain. The real-time modifications include introducing a real-time interface library into the construction and linking configuration of the runtime critical library, bringing the interfaces and data structures of the real-time device driver model into the visibility of the runtime critical library, and setting real-time constraints on the concurrent scheduling and timer mechanisms.

[0030] S103 utilizes a modified toolchain to compile the application source code, introduces a real-time interface library during the linking phase, and obtains a real-time application running on the operating system. The runtime critical library configures the real-time critical concurrency units during execution. This configuration includes specifying the priority of the underlying real-time tasks for the real-time critical concurrency units, specifying processor affinity for the real-time critical concurrency units, and encapsulating system calls that cause non-deterministic blocking. This configuration is integrated into the real-time application along with the runtime critical library during the compilation and linking process.

[0031] In some embodiments, an operating system with real-time kernel capabilities is built and run on the target hardware platform, and the real-time interface library and real-time device driver model of the operating system are determined as dependencies for compilation and linking, including:

[0032] A collaborative kernel build method or a compatible build method based on a real-time framework generates and enables the runtime environment of the real-time kernel on the target hardware platform;

[0033] Install a real-time interface library that matches the operating environment and enable the device access interface based on the real-time device driver model.

[0034] Register the header files, binary and symbol information of the real-time interface library and the real-time device driver model as a compilation and linking dependency list, and set version identifiers for the compilation and linking dependency list;

[0035] The timing source, preemption and priority strategies, and device access channels are parameterized, and the parameterized settings are used as the interface configuration for the runtime critical library.

[0036] The system performs availability verification of the real-time interface library and device access interface in the runtime environment, and provides the link configuration and retrieval path that can be called by the compiler and toolchain.

[0037] Specifically, a runnable real-time kernel environment is generated on the target hardware platform using either a collaborative kernel build method or a compatible build method based on a real-time framework. The collaborative kernel build method involves loading the real-time domain kernel in parallel alongside the general-purpose kernel and establishing a dual-domain call path, allowing the real-time domain to take over the timing and scheduling critical paths. The compatible build method involves loading real-time extension patches into the general-purpose kernel and enabling preemption and high-precision timing. After the build is complete, the real-time kernel configuration file is selected in the bootloader. Upon startup, the real-time domain is confirmed to be active using the kernel identifier and clock source identifier, and the kernel build parameters are recorded for subsequent generation of the dependency list and version identifier.

[0038] Furthermore, install a real-time interface library compatible with the running environment and enable the device access interface based on the real-time device driver model within the running environment. The real-time interface library provides a user-space entry point for timing, scheduling, synchronization, and task management, while the real-time device driver model provides a unified channel for device nodes, control commands, and event notifications. After installation, corresponding files are generated in the system library directory and driver directory, and the necessary kernel modules are loaded, making the device nodes visible in user space.

[0039] Furthermore, the header files, binary files, and symbol information of the real-time interface library and the real-time device driver model are compiled and registered into a compilation and linking dependency list. The dependency list must include at least the library name, interface header file path, link name, symbol export summary, set of control command numbers for the driver model, and device node naming rules. A version identifier is assigned to this list, consisting of the kernel build parameters of the runtime environment, the real-time interface library version, the driver model version, and the target processor architecture information, serving as the basis for subsequent toolchain retrieval and link matching. The dependency list and version identifier are stored in text format in a system-searchable path, and their location is registered in the build configuration of key runtime libraries.

[0040] Furthermore, based on the real-time constraints of the target system, the timing source, preemption and priority strategies, and device access channels are parameterized to form an interface configuration that can be directly read by the runtime critical library. The timing source settings include parameters such as time base type, resolution, and maximum jitter threshold; the preemption and priority strategy settings include thread scheduling strategy, priority range, and priority inheritance switch; the processor affinity settings include affinity mask or processor set; and the device access channel settings include device node path, synchronization method, access timeout, and buffer management strategy. These parameterized settings establish a reference relationship with the dependency list, enabling the runtime critical library to select the corresponding parameter set based on the version identifier during the initialization phase.

[0041] Furthermore, availability checks are performed on the real-time interface library and device access interfaces in the runtime environment. The checks include whether library files can be linked, whether key symbols can be resolved, whether clock and timing services can be created, whether synchronization primitives can be initialized, whether device nodes can be opened and return valid handles, and whether event notifications can be subscribed to and canceled. Upon successful verification, an external linking configuration and retrieval path are generated. The external linking configuration includes the library retrieval path, linking order rules, symbol resolution priority, and compilation option templates. The retrieval path instructs the compiler and toolchain to locate the dependency list and parameterization configuration files during the build process. The linking configuration and retrieval path are bound to the aforementioned version identifier to ensure consistent retrieval and linking behavior across different processor architectures or different real-time interface library versions.

[0042] For example, in some sample scenarios, in an edge controller for industrial Ethernet slave testing, the target hardware platform is a multi-core processor. A collaborative kernel construction approach is used to generate a real-time kernel runtime environment and enable high-precision timing. The installed and enabled real-time interface library provides user-mode task creation, priority configuration, processor affinity settings, mutexes and semaphores, timers and event interfaces; the enabled real-time device driver model provides unified device nodes and control commands for the test port and timing acquisition card.

[0043] The dependency manifest registers library file paths, interface header file paths, exported symbol digests, and device node naming rules, and generates a version identifier containing kernel build parameters and library versions. In the parameterization settings, the time base is set to a high-precision clock, the scheduling policy is set to fixed priority, the priority range and inheritance policy are configured according to the real-time attributes of the application-side concurrent units, affinity is set to bind high-priority concurrent units to a specified processor set, and the device channel is set to non-blocking access with a pre-allocated circular buffer and access timeout configured.

[0044] After verification, the link configuration and retrieval path are output for the toolchain to directly reference during the compilation and linking stages. This allows runtime critical libraries to access the real-time interface library and real-time device driver model according to the dependency list and parameterized settings without modifying the application source code, thus achieving the compilation and linking dependency closed loop required for subsequent real-time application construction.

[0045] In some embodiments, the high-level language compiler and runtime key libraries are modified in real time to generate a modified toolchain, including:

[0046] In the construction and linking configuration of runtime critical libraries, a real-time interface library is introduced to establish a call mapping from timing, scheduling and synchronization-related calls to the real-time interface library;

[0047] Incorporate the interfaces and data structures of the real-time device driver model into the visibility of the runtime critical library, and set up a device access adaptation layer for user-mode calls;

[0048] Set real-time constraints for concurrent scheduling and timer mechanisms, including establishing priority binding relationships between real-time key concurrent units and corresponding real-time tasks, and setting processor affinity for real-time key concurrent units;

[0049] System calls that cause nondeterministic blocking are encapsulated in a restricted manner and replaced or bypassed with equivalent interfaces provided by the real-time interface library.

[0050] The timing and wake-up paths are configured in a unified manner so that the runtime critical libraries are pre-configured with the clock and timing services provided by the real-time interface library as the time base during compilation and linking;

[0051] The compiler options pre-configure parameter templates for linking the real-time interface library and its dependencies, and output a modified toolchain for compilation and linking.

[0052] Specifically, firstly, a real-time interface library is introduced and a call mapping is established in the construction and linking configuration of key runtime libraries. For example, in a runtime environment with real-time kernel capabilities, the build script and linking configuration of libgo are modified to prioritize calls related to timing, scheduling, and synchronization to the Xenomai real-time interface library. For instance, in the cobalt mode, libcobalt is registered as a priority linking object, and a one-to-one mapping of "abstract interface → real-time implementation" is maintained in the runtime abstraction layer: time acquisition and timer creation are mapped to Xenomai clock and timer objects, thread creation, priority setting, and preemption control are mapped to the Xenomai task interface, and synchronization primitives such as mutexes, semaphores, and events are mapped to the Xenomai synchronization interface.

[0053] To ensure deterministic symbol resolution, the real-time interface library is placed before the generic implementation in the linking order, and the resolution priority of the real-time implementation is specified in the symbol aliasing strategy, thereby ensuring that the timing, scheduling and synchronization paths within the Go runtime are uniformly placed in the real-time domain.

[0054] Furthermore, RTDM interfaces and data structures are incorporated, and a device access adaptation layer is set up. For example, to enable user space to securely access real-time devices via runtime critical libraries, RTDM header files, type and constant declarations are introduced into libgo to complete symbol visibility and dependency registration. A "Device Access Adapter" layer is set up on top of libgo to provide unified interfaces for open / close, read / write, control (ioctl class), asynchronous event subscription and cancellation, etc. The adaptation layer maps device interrupts and event notifications to the event or timer wake-up mechanism provided by Xenomai, and waits with a configurable timeout. Device access operations that may cause unpredictable blocking are encapsulated in a restricted manner, providing non-blocking, timeout, and interruptible strategies, while combining priority inheritance options to avoid priority inversion.

[0055] For high-frequency data channels, the adaptation layer employs a pre-allocated ring buffer and a zero-copy / low-copy strategy, and performs alignment and boundary checks on cross-boundary data structures to reduce additional jitter between user space and kernel space. The adaptation layer also maintains a unified error / status code mapping, standardizing the error codes returned by RTDM into runtime-recognizable error domains, facilitating consistent processing by upper-layer Go business logic.

[0056] Furthermore, real-time constraints are set for concurrent scheduling and timer mechanisms. For example, a clear mapping and constraints are established between the Go runtime concurrency model (goroutines) and the underlying real-time tasks (RT tasks). First, the set of real-time attributes for "real-time key concurrent units" is registered in the runtime key library, including the priority of the corresponding RT task, scheduling policy (such as fixed priority preemption), CPU affinity, stack space configuration, and priority inheritance parameters.

[0057] When creating concurrent units, the runtime scheduling bridge layer generates corresponding real-time (RT) tasks and applies the aforementioned attributes. Goroutines with strict time limits are configured with higher priority and bound to a specified CPU set to reduce scheduling interference. General business goroutines are merged into non-real-time domain or low-priority RT tasks. For timing, timers are created using the Xenomai high-precision clock as a unified time base, supporting both one-shot and periodic timers. Expiration determination and wake-up are handled by the real-time domain. Event waiting and wake-up paths are uniformly mapped to real-time synchronization and timing interfaces to ensure consistency and controllable time consumption for waiting, wake-up, and timeout determination.

[0058] Furthermore, system calls that may cause non-deterministic blocking are subject to restricted encapsulation and bypassing. For example, for syscall paths that may lead to uncontrollable blocking (such as file system blocking, non-real-time network blocking, and generic sleep interfaces), a "restricted encapsulation" component is provided in the runtime critical library: one type uses an equivalent interface from the real-time interface library for replacement (such as replacing generic sleep with a real-time timer), and another type uses a bypass strategy to split the call into interruptible short holding segments and set timeout boundaries; for paths that cannot provide a real-time equivalent interface, they are uniformly pushed down to the non-real-time domain or a low-priority execution queue to avoid polluting the real-time critical path. This component rewrites the call at runtime through a policy table, which determines the call based on the dimensions of "call type - whether real-time equivalence exists - whether interruptibility / timeout is supported - whether pushing down is allowed".

[0059] Furthermore, a unified timing and wake-up path is established, using a real-time clock and timing service as the time base. For example, during the build phase, a "time base configuration" is pre-configured for critical runtime libraries, specifying that the clock and timer services provided by Xenomai are the sole source of timing and wake-up. All upper-level calls involving time acquisition, deadline calculation, timeout determination, and ticker / timer triggering are routed to the real-time clock object by the abstraction layer. In the wake-up path, real-time events or timer callbacks are uniformly used for goroutine wake-up to avoid jitter and latency uncertainties caused by general kernel ticks or non-real-time events. The time base configuration is checked against the version manifest during the initialization phase to ensure that the real-time interfaces loaded at runtime are consistent with the build-phase assumptions.

[0060] Furthermore, the compiler options pre-configure the link template and output the modified toolchain. For example, if gccgo is selected as the main compilation backend, the corresponding Go toolchain will have the link parameters, library search paths, linking order and symbol resolution priority rules pre-configured in the "Compiler Options Template" for the real-time interface library and its dependencies, and bound to the processor architecture identifier and version list.

[0061] When building an application, developers only need to specify the use of the modified toolchain. The toolchain will automatically import the libgo modification artifacts, Device Access Adapter, real-time interface library, and RTDM dependencies, generating a real-time application binary that can run on the Xenomai real-time kernel. Alternatively, the runtime and linker scripts can be modified within the native gc compiler chain based on equivalence principles, but additional handling of gc runtime affinity and symbol resolution details with the Xenomai interface is required.

[0062] In some example scenarios, taking industrial Ethernet slave simulation and fault injection applications as an example, the target system uses the Xenomai cobalt approach to build a real-time kernel. In the libgo build, libcobalt is listed as the primary linking library, with timing, scheduling, and synchronization paths mapped to the cobalt interface. After importing RTDM header files and constants, the Device Access Adapter provides open / read / write / control and event subscription interfaces, enabling user-space access to the simulated network card and timestamp acquisition card. Real-time attributes are registered for the "message time alignment" and "injection window control" goroutines, with high priority bound to CPU0 and CPU1, using a periodic timer to align window triggering. Restricted encapsulation is enabled for general sleep and blocking I / O calls, replacing sleep with a real-time timer and setting timeout and interruptibility policies for I / O. During compilation, a modified gccgo toolchain is selected, automatically loading the linking template and dependency list, and outputting the application binary running in the real-time kernel.

[0063] This embodiment achieves real-time interface mapping and adaptation for timing, scheduling, synchronization, and device access at the libgo level, and solidifies links and parameter templates in the toolchain, enabling real-time compilation and execution of Go source code without modification. This solution achieves controllable call path endpoints, configurable constraints on concurrency and timing, and restricted encapsulation of device access, which is beneficial for stable reuse in multi-architecture environments and maintaining end-to-end deterministic behavior boundaries.

[0064] In some embodiments, a real-time interface library is introduced into the construction and linking configuration of the runtime critical library, establishing a call mapping from timing, scheduling, and synchronization-related calls to the real-time interface library, including:

[0065] In the build script, set the header and library file search paths for the real-time interface library, and specify the linking order and symbol resolution priority of the real-time interface library and its dependencies in the linking options.

[0066] Set up a call adaptation layer in the runtime critical library to redirect the abstract interfaces of timing, scheduling and synchronization to the equivalent interfaces of the real-time interface library;

[0067] By using conditional compilation or linking aliases, the generic implementation can be replaced with the implementation provided by the real-time interface library;

[0068] The synchronization primitives are mapped to the synchronization interfaces provided by the real-time interface library. Thread creation, priority configuration, and processor affinity settings are mapped to the task and scheduling interfaces provided by the real-time interface library. Timing and timer creation are mapped to the clock and timing interfaces provided by the real-time interface library.

[0069] Specifically, firstly, the build and linking retrieval paths and priorities are determined. For example, after enabling the real-time kernel runtime environment, the libgo build script is configured with the header and library file retrieval paths for the real-time interface library. The header file retrieval path points to the Xenomai user-space interface directory, and the library file retrieval path points to the system library directory containing libcobalt and its dependencies. The linking options determine the linking order strategy, placing the real-time interface library before the generic implementation. The symbol resolution priority is explicitly defined as following the rule of "real-time implementation first, generic implementation fallback," and this priority is bound to the dependency manifest as a versioned linking strategy to ensure consistent resolution behavior across different CPU architectures and versions.

[0070] Furthermore, the settings and abstract interfaces of the call adapter layer are redirected. For example, a "Call Adapter Layer" is added inside the runtime critical library. The abstract interfaces facing libgo only retain the semantic constraints of timing, scheduling, and synchronization, while the concrete implementations are redirected to equivalent interfaces in Xenomai. Timer-related abstract interfaces are uniformly routed to Xenomai clock and timer objects, scheduling-related abstract interfaces are uniformly routed to Xenomai task creation and scheduling strategy settings, and synchronization-related abstract interfaces are uniformly routed to mutexes, semaphores, and events provided by Xenomai. The adapter layer maintains a mapping table of "abstract interfaces—real-time implementations," which, together with the linking strategy, ensures runtime path stability.

[0071] Furthermore, conditional compilation and linking aliases are used for coordinated replacement. For example, considering the need for toolchain reuse across different target environments, the adaptation layer uses a combination of conditional compilation macros and linking aliases to replace the implementation. When a live interface library is detected to exist and its version matches, the "live implementation" branch is enabled; otherwise, it reverts to the "generic implementation." Linking aliases are used to bind abstract interfaces to symbols in the live implementation without changing the names of upper-level symbols, thus avoiding any modifications on the upper-level caller side. This strategy is coupled with version identifiers in the dependency manifest to avoid linking inconsistencies caused by symbol drift.

[0072] Furthermore, the mapping of synchronization, task, and timing interfaces is refined. For example, regarding synchronization primitives, mutex, semaphore, and event primitives are registered in the adaptation layer as direct mappings to the Xenomai synchronization interface, maintaining semantic consistency in creation, locking, unlocking, waiting, notification, and destruction. A wait overload based on timeout parameters is added in the adaptation layer to adapt to interruptible waiting in the real-time domain. Regarding tasks and scheduling, thread creation, priority configuration, and CPU affinity are uniformly encapsulated in the adaptation layer as combined calls of `task create`, `priority set`, and `affinity set`. Priority and affinity parameters are derived from the real-time attribute set registered in the runtime key library and are distributed once in the creation path, avoiding window jitter introduced by subsequent modifications. Regarding timing and periodicity, time acquisition, deadline calculation, and one-shot and periodic timer creation are uniformly mapped to `clock` and `timer` services. Timer expiration callbacks trigger the wake-up of upper-layer concurrent units in the adaptation layer, with the real-time domain handling expiration determination and wake-up notification, avoiding the intervention of the general tick path.

[0073] Furthermore, for implementation examples of fault injection applications, such as in industrial Ethernet slave station simulation and fault injection scenarios, the application includes three types of real-time concurrent units: "message time alignment," "injection window control," and "sampling timestamp alignment." During construction, the libgo script sets the include lookup to point to the Xenomai user-space header file directory, and the library lookup to point to the library directory containing libcobalt, with a clear linking order prioritizing libcobalt. The adaptation layer redirects common timing abstractions such as sleep, usleep, and nanosleep to Xenomai timers, pthread-related creation and priority settings to task interfaces, pthread mutexes and semaphores to Xenomai mutexes and semaphores, and event notifications to Xenomai events.

[0074] In some examples, a periodic timer is set for the "message time alignment" concurrent unit, with the period and deadline derived from the upper-level configuration; a high-priority task is set for the "injection window control" concurrent unit and bound to CPU0 and CPU1 to reduce scheduling migration; and event-based interruptible waiting is enabled for the "sampling timestamp alignment" concurrent unit, with timeout parameters and error codes uniformly converted by the adaptation layer to ensure consistent error handling on the Go side in the upper-layer logic.

[0075] This embodiment achieves a stable mapping of timing, scheduling, and synchronization paths to the real-time interface library by establishing retrieval paths and parsing priorities during the build and link phases, setting up a Call Adapter Layer within the runtime key library, and coordinating replacement with conditional compilation and linking aliases. This implementation ensures that timing and wake-up use the Xenomai clock and timer as the sole time base, thread and priority configuration use the task interface as the unified entry point, and synchronization primitives use the real-time interface as the endpoint. Thus, without modifying the upper-layer Go source code, it provides configurable priority and affinity settings, interruptible and timeout-controlled waiting behavior, and consistent error semantics for real-time concurrent units, facilitating reuse in multi-architecture environments and maintaining the deterministic boundaries of end-to-end paths.

[0076] In some embodiments, the interfaces and data structures of the real-time device driver model are brought into the visibility of the runtime critical library, and a device access adaptation layer is set up for user-mode invocation, including:

[0077] In the build configuration of the runtime critical library, the header files, type definitions and constant declarations of the real-time device driver model are introduced to complete symbol visibility and dependency registration;

[0078] A device access adaptation layer is established in the runtime critical library to provide a unified device access interface for user space;

[0079] The device interrupt and event notification are mapped to the event and timer interfaces provided by the real-time interface library, and wake-up and waiting are performed in user space with configurable timeouts.

[0080] Establish a mapping between error codes and status codes for device access, and unify the encoding returned by the real-time device driver model into the error representation of the runtime key library;

[0081] Generate a configuration manifest and link identifier for the device access adaptation layer, so that the configuration manifest and link identifier are referenced by the toolchain during compilation and linking and integrated with the real-time application.

[0082] Specifically, the introduction and registration of real-time device driver model interfaces and data structures involves, for example, adding RTDM header files and type declarations to the visible scope during the runtime critical library build configuration. The header files include user-mode prototype declarations for RTDM devices' open / close, read / write, and ioctl functions, as well as event notification-related structures. Type definitions cover device handle types, control command number sets, and buffer descriptor structures for low-copy access. Constant declarations cover device node naming rules, error code prefixes, and event masks. After completing the above introduction, the include path, library path, and symbol export digest are recorded in the dependency registration, and this registration is bound to the version ID to ensure resolvability and consistency during subsequent linking.

[0083] Furthermore, the Device Access Adapter (DAP) layer is established with a unified interface. For example, a DAP is set up in the runtime key library above libgo, providing a unified set of device access interfaces to user space, including device opening / closing, data reading / writing, control command submission (equivalent to ioctl semantics), parameter querying (get param), and asynchronous event subscription / unsubscription. The DAP exposes stable call prototypes and error domains externally, and internally selects the specific implementation matching Xenomai RTDM based on the dependency list. To meet high-frequency scenarios, the DAP supports pre-allocated ring buffers, alignment control, and low-copy / zero-copy strategies. Through buffer descriptors, the data exchange path between user space and kernel space is converged into a fixed mapping and recycling process, reducing additional copying and lock contention.

[0084] Furthermore, the real-time mapping and timeout waiting for device interrupts and event notifications are handled. For example, device-side interrupts and event notifications are uniformly mapped to the event and timer interfaces provided by the Xenomai real-time interface library. The adaptation layer establishes a one-to-one correspondence between event sources and user-space waiting points when subscribing to events. All waiting operations use the real-time clock and timer service as the time base, supporting waiting and waking in configurable timeout and interruptible modes. For devices requiring periodic data collection, the adaptation layer can use a periodic timer to trigger the user-space fetch cycle, avoiding the jitter introduced by the general kernel tick. In high-priority event channels, the adaptation layer routes wake-up notifications to tasks registered as real-time critical concurrent units, ensuring that wake-up and subsequent processing are completed within the same priority domain, reducing the probability of priority inversion.

[0085] Furthermore, a unified mapping between error codes and status codes is implemented. For example, the adapter layer maintains an error code mapping table (errormap), uniformly mapping the error codes returned by RTDM to the error domains of runtime critical libraries, including standardized representations such as device busy, invalid parameter, timeout, interrupted, and unavailable. For scenarios requiring the transmission of low-level details, the adapter layer retains the raw error value field (raw errno) in the unified error domain for upper-layer diagnosis. Regarding status codes, the adapter layer abstracts and hierarchizes device status information, forming states such as device ready, not ready, degraded, and closed, and exposes extended status words as needed to carry device self-description fields.

[0086] Furthermore, the generation and integration of configuration manifests and link identifiers are handled as follows: After the adapter layer is built, it generates a device access configuration manifest and link identifiers. The configuration manifest records the interface family (interface name, parameter conventions), dependent library names, symbol resolution priority, device node wildcard rules, and buffer strategy set; the link identifier records the architecture type (e.g., x86_64, aarch64), real-time interface library version, RTDM interface version, and symbol digest. Both are automatically referenced by the modified toolchain during the compilation and linking phases. The toolchain imports libcobalt and RTDM-related objects according to the search path and linking order in the manifest, and binds the adapter layer symbols to the upper-layer calling symbols, thereby stably integrating device access capabilities and real-time interfaces into the target binary.

[0087] For example, in some sample scenarios, such as industrial Ethernet slave simulation and fault injection applications, the system runs in a Xenomai environment using cobalt. Through dependency registration, RTDM header files and constants are brought into the libgo visibility scope, and the Device Access Adapter provides open / read / write / control and event subscribe interfaces. Device channels are established for the "timestamp acquisition card" and the "injection port network card" respectively. The acquisition card channel uses a ring buffer and low-copy strategy, while the write channel uses a pre-allocated alignment buffer to reduce jitter. Event notifications are mapped to Xenomaievent, and packet arrival and time window expiration are triggered by a combination of periodic timer and event. Waiting calls uniformly carry a timeout parameter. For error handling, device busy and timeout are uniformly mapped to standard error fields, while raw errno is retained for easy diagnosis. Finally, during the compilation and linking stages, the toolchain automatically imports libcobalt and RTDM dependencies according to the configuration manifest, completes the symbol binding between the adaptation layer and the upper-layer calls, and outputs the target program that can run in the real-time kernel.

[0088] This embodiment achieves a stable, controllable, and low-jitter access path for real-time devices from user space by introducing RTDM interfaces and data structures into the runtime key library, establishing a Device AccessAdapter with corresponding real-time mapping of events and timers, unifying error codes and status codes, and generating configuration lists and link identifiers that can be automatically referenced by the toolchain. While ensuring consistency between the Xenomai time base and priority domain, upper-layer Go services can call the unified interface to complete device operations without modifying the source code, thereby improving portability and reusability efficiency and stably constraining the deterministic boundaries of the device interaction link.

[0089] In some embodiments, setting real-time constraints for the concurrent scheduling and timer mechanism includes establishing priority binding relationships between real-time key concurrent units and corresponding real-time tasks, and setting processor affinity for real-time key concurrent units, including:

[0090] Register real-time attributes for real-time critical concurrent units in the runtime critical library, and generate corresponding real-time tasks according to the real-time attributes when creating real-time critical concurrent units;

[0091] Set processor affinity for real-time critical concurrent units in the form of affinity masks or processor sets, and adopt affinity configuration in task creation and migration control;

[0092] Based on the clock and timing services provided by the real-time interface library, timers are created for real-time key concurrent units. The timers include single-time timing and periodic timing, and expiration determination and wake-up are performed using a unified time base.

[0093] The event wait, wake-up, and timeout handling associated with concurrent units are mapped to the synchronization and timing interfaces provided by the real-time interface library, and the real-time attributes, affinity configurations, and timer parameters are recorded in the configuration manifest of the runtime key library so that they can be pre-configured and integrated with the real-time application during compilation and linking.

[0094] Specifically, firstly, real-time attribute registration and real-time task generation are performed. For example, a "real-time attribute registry" is set up in the runtime critical library to register attribute entries for each real-time critical concurrent unit, including priority, policy (fixed priority with preemptibility), cpu_affinity (affinity mask or processor set), stack_size, and inherit_priority switch. After registration, the runtime scheduling bridge layer synchronously generates the corresponding RT task when creating the concurrent unit and applies priority, policy, and cpu_affinity all at once, avoiding window jitter caused by creating and then modifying the task. The attribute registry is persisted in the form of a text list and associated with version identifiers and processor architecture identifiers for reference during subsequent compilation and linking stages.

[0095] Furthermore, processor affinity settings and migration control are implemented. For example, affinity policies are described using a `cpu_affinity` mask or set. For instance, on a quad-core platform, high-priority concurrent units are bound to `{CPU0, CPU1}`, and secondary concurrent units are bound to `{CPU2}`. The runtime critical library calls the Xenomai task interface in the RT task creation path to complete affinity settings and enables the "disable cross-domain migration" flag in migration control, unless an explicit rebinding request occurs, to reduce the impact of context switching and cache mismatch on the real-time path. For scenarios requiring isolation between interrupts and user-mode processing, high-priority concurrent units are further coordinated with interrupt affinity configurations, ensuring that interrupt service threads and their subsequent processing chains are placed within the same processor set.

[0096] Furthermore, timer configurations under a unified time base are implemented. For example, using the Xenomai real-time clock as the sole time base, the runtime critical library creates two types of timers: one-shot and periodic, for real-time critical concurrent units. One-shot timers are used for single-deadline triggering, while periodic timers are used for periodic wake-ups and window alignment. Timer creation parameters include initial expiration time, period, jitter threshold, and timeout strategy, all derived from the property registry or higher-level configuration file. Expiration determination and wake-up are handled by the real-time domain, with the adaptation layer triggering goroutine wake-ups in callbacks to ensure the wake-up path does not pass through the general tick. For scenarios requiring sub-millisecond alignment, high-precision periods and fast reset strategies can be set in the properties to perform phase correction when period drift exceeds the threshold.

[0097] Furthermore, event waiting, wake-up, and timeout mappings are implemented. For example, the runtime critical library maps event waiting and wake-up to the Xenomai synchronization and timing interfaces. The waiting point is carried by an event or semaphore, both with a timeout parameter. For calls requiring interruptible waiting, the interruptible flag is set, and a timeout or interrupt code in a unified error domain is returned when an interrupt or timeout occurs. Wake-up operations are triggered by real-time domain events or timer callbacks, avoiding delegation of wake-up to non-real-time queues. Different timeout and retry strategies can be configured for different concurrency units in the property registry. For example, critical path concurrency units can use short timeouts and fast fallbacks, while non-critical path concurrency units can use longer timeouts to reduce unnecessary retries.

[0098] Furthermore, the configuration manifest is integrated with the toolchain. For example, after building, the runtime critical library outputs a "scheduling and timing configuration manifest," recording the priority, policy, cpu_affinity, timer type and parameters, timeout policy, and error code mapping for each concurrent unit. The modified toolchain (gccgo + modified libgo) automatically references this manifest during the compilation and linking stages, solidifying the symbol resolution rules, linking order, and time base constraints into the target binary, eliminating the need for manual configuration on the deployment side. If the processor architecture changes, the toolchain loads the corresponding manifest and linking template based on the architecture identifier, maintaining consistency in attribute interpretation.

[0099] For example, in some sample scenarios, in industrial Ethernet slave simulation and fault injection applications, three types of real-time key concurrent units are defined: "message time alignment," "injection window control," and "sampling timestamp alignment." "Message time alignment" is registered with the highest priority, a fixed-priority preemptible policy, `cpu_affinity` set to `{CPU0, CPU1}`, and a `periodic` timer, with the period and deadline derived from the higher-level configuration. "Injection window control" is registered with the second-highest priority and placed alongside "message time alignment" within `{CPU0, CPU1}` to reduce cross-core migration. "Sampling timestamp alignment" is registered with a medium priority and bound to `{CPU2}`, waiting for the event + timeout to be used; if the timeout exceeds a threshold, a unified error domain timeout code is returned. These attributes are issued all at once when the RT task is created, and Xenomai handles scheduling, timing, and synchronization. The configuration manifest of runtime key libraries and the toolchain linking template are automatically loaded during the compilation phase, ultimately outputting the target program running on the Xenomai (cobalt) real-time kernel.

[0100] This embodiment establishes a one-to-one mapping of "goroutine → RT task" within the runtime key library, constrains the scheduling domain with cpu_affinity, unifies the time base with real-time clock and timer, implements interruptible waiting and waking with timeout using event / semaphore, and solidifies all attributes into the configuration list and toolchain. This ensures that the landing point, priority, and affinity of concurrency and timing paths remain consistent between the build and runtime phases. Upper-layer Go services can obtain configurable, reusable, and jitter-controlled real-time execution behavior without modifying the source code.

[0101] In some embodiments, the application source code is compiled using a modified toolchain, and a real-time interface library is introduced during the linking phase to obtain a real-time application running on the operating system, including:

[0102] At the compilation entry point, select the modified compiler and load the preset parameter templates and linker scripts;

[0103] During the compilation process, the configuration list of runtime key libraries and device access adaptation layers is referenced, and the header file paths, library file paths and symbol resolution rules recorded therein are included in the compilation and linking scope;

[0104] During the linking phase, the real-time interface library and its dependencies are linked in a preset order, and the call mappings related to timing, scheduling, and synchronization in the configuration list are merged.

[0105] Generate an executable file or loadable target containing runtime critical libraries and device access adaptation layers, and output the corresponding symbol table and link identifier;

[0106] For different processor architectures, the same compilation and linking process is completed by calling the matching modified toolchain, and the built modified toolchain and parameter templates are reused under the same processor architecture.

[0107] Specifically, firstly, the compilation entry point and parameter template are loaded. For example, after the real-time kernel runtime environment on the target host is ready, a modified compiler is selected as the compilation entry point, namely the Go toolchain with gccgo as the backend, and pre-defined "parameter templates and link scripts" are loaded. The parameter template records the include path, library path, link order, symbol resolution priority, and time base and scheduling policy constraints associated with the version ID. After loading, the compilation entry point presents the same usage as the native gobuild externally, but internally it uses the modified libgo and Xenomai real-time interface libraries (such as libcobalt) as default dependencies.

[0108] Furthermore, the configuration manifests of runtime critical libraries and the device access adapter layer are referenced. For example, during the compilation phase, the toolchain automatically reads the configuration manifests of runtime critical libraries and the Device Access Adapter, incorporating the header paths, library paths, and symbol resolution rules recorded therein into the compilation and linking scope. The configuration manifest also contains call mappings from abstract interfaces to real-time implementations, such as mapping entries for interfaces like time acquisition, timer creation, event waiting, semaphore notification, task creation, and priority setting. To ensure consistency, the entries in the manifest are bound to processor architecture identifiers (e.g., x86_64 or aarch64) and Xenomai interface versions to avoid path divergence and symbol drift in different environments.

[0109] Furthermore, the linking phase order and resolution priority are merged. For example, upon entering the linking phase, the toolchain incorporates the real-time interface library and its dependent libraries into the symbol resolution process of the executable file or loadable target according to a preset order. The preset order follows the principle of "real-time implementation first, general implementation fallback," placing libcobalt before general system libraries; simultaneously, it merges the call mappings related to timers (timer / clock), tasks (task / priority / affinity), and synchronization (mutex / semaphore / event) in the configuration manifest. To ensure runtime path stability, the linker sets aliases in necessary locations to maintain the upper-level call symbol names unchanged, while resolving the implementation to real-time interface symbols. For a small number of system calls that do not provide a real-time equivalent implementation, the linking phase maintains the general implementation and bypasses or sinks it to the non-real-time domain at runtime through a strategy table.

[0110] Furthermore, artifacts, symbol tables, and link tags are generated and output. For example, after linking, the toolchain generates an executable or loadable object containing runtime key libraries and a Device Access Adapter, and simultaneously outputs the corresponding symbol table and link tag. The symbol table is used during the deployment and diagnostic phases to verify whether key symbols are correctly resolved to the real-time implementation; the link tag records the processor architecture, Xenomai interface version, dependency library digest, and build timestamp for subsequent reproduction builds and cross-environment consistency verification. Artifacts retain manifest and tag files during packaging, enabling target devices to quickly confirm the completeness of the dependency loop through a three-step process of "manifest verification—symbol detection—minimum runtime verification" before deployment.

[0111] Furthermore, cross-processor architecture toolchain reuse is possible. For example, for different processor architectures, a matching modified toolchain can be invoked to execute the same compilation and linking process. Taking x86_64 and aarch64 as examples, the two toolchains share the same configuration manifest template and invocation mapping rules, but the dependency paths, machine instruction sets, and linker details are handled by their respective parameter templates and linker scripts. For target devices with the same processor architecture, the already built modified toolchain and parameter templates can be directly reused, achieving rapid build and distribution with "no source code modification, universal scripts, and reusable configurations".

[0112] For example, in some sample scenarios, in industrial Ethernet slave simulation and fault injection applications, developers use a modified gccgo toolchain as the compilation entry point, loading parameter templates and linking scripts bound to cobalt. During compilation, the configuration manifests of runtime key libraries and Device Access Adapters are read, automatically incorporating libgo modification artifacts, libcobalt, and RTDM-related objects. During the linking phase, symbols such as time, timer, event, semaphore, task, priority, and affinity are parsed in a "real-time priority" order, and the call mappings are merged, so that time and timer are uniformly included in the Xenomai clock and timing service, and task and priority / affinity are uniformly included in the Xenomai task and scheduling interface. The final output is an executable file containing a symbol table and linker identifiers. In deployment verification, symbol detection confirms that key symbols have been resolved to real-time implementations, and minimal runtime verification confirms that the periodic timer and event wake-up behavior is consistent with the manifest configuration.

[0113] This embodiment completes an end-to-end build loop from source code to real-time artifacts by loading parameter templates and linker scripts at the compilation entry point, referencing configuration manifests during compilation, solidifying the "real-time priority" resolution order and merging call mappings during linking, generating symbol tables and linker identifiers at the output stage, and reusing the modified toolchain in multi-architecture scenarios. This embodiment enables applications to stably obtain a real-time running path with Xenomai clock / timer as the time base, task / priority / affinity as the scheduling entry point, and mutex / semaphore / event as the synchronization endpoint without modifying the Go source code, facilitating rapid portability and large-scale distribution.

[0114] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0115] Figure 2 This is a schematic diagram of the structure of a real-time program compilation device for a real-time kernel provided in an embodiment of this application. Figure 2 As shown, this real-time program compilation device for a real-time kernel includes:

[0116] Module 201 is used to build and run an operating system with real-time kernel capabilities on the target hardware platform, and to determine the real-time interface library and real-time device driver model of the operating system as dependencies for compilation and linking.

[0117] Modification module 202 is used to perform real-time modification of the high-level language compiler and runtime key library to generate a modified toolchain. The real-time modification includes introducing a real-time interface library in the construction and linking configuration of the runtime key library, bringing the interface and data structure of the real-time device driver model into the visibility of the runtime key library, and setting real-time constraints on the concurrent scheduling and timer mechanism.

[0118] The compilation module 203 is used to compile the application source code using a modified toolchain, introduce a real-time interface library during the linking stage, and obtain a real-time application running on the operating system. The runtime critical library configures the real-time critical concurrency units during execution. The configuration includes specifying the priority of the underlying real-time tasks for the real-time critical concurrency units, specifying the processor affinity for the real-time critical concurrency units, and restricting the encapsulation of system calls that cause non-deterministic blocking. The configuration is integrated into the real-time application along with the runtime critical library during the compilation and linking process.

[0119] In some embodiments, Figure 2 The build module 201 generates and enables the runtime environment of the real-time kernel on the target hardware platform using a collaborative kernel build method or a compatible build method based on the real-time framework; installs the real-time interface library that matches the runtime environment and enables the device access interface based on the real-time device driver model; registers the header files, binary and symbol information of the real-time interface library and the real-time device driver model as a compilation and linking dependency list, and sets version identifiers for the compilation and linking dependency list; parameterizes the timing source, preemption and priority strategy and device access channel, so that the parameterization settings serve as the interface configuration of the runtime key library; completes the availability verification of the real-time interface library and device access interface in the runtime environment, and provides the link configuration and retrieval path that can be called by the compiler and toolchain.

[0120] In some embodiments, Figure 2 The modified module 202 introduces a real-time interface library in the construction and linking configuration of the runtime critical library, establishing a call mapping from timing, scheduling, and synchronization-related calls to the real-time interface library; it incorporates the interfaces and data structures of the real-time device driver model into the visibility of the runtime critical library and sets up a device access adaptation layer for user-mode calls; it sets real-time constraints on the concurrent scheduling and timer mechanisms, including establishing priority binding relationships between real-time critical concurrent units and corresponding real-time tasks, and setting processor affinity for real-time critical concurrent units; it encapsulates system calls that generate non-deterministic blocking in a restricted manner and replaces or bypasses them with equivalent interfaces provided by the real-time interface library; it uniformly configures the timing and wake-up paths so that the runtime critical library is pre-set to use the clock and timing services provided by the real-time interface library as the time base during compilation and linking; it pre-sets the parameter templates for linking the real-time interface library and its dependencies in the compiler options, and outputs the modified toolchain for compilation and linking.

[0121] In some embodiments, Figure 2 The modification module 202 sets the header and library file search paths for the real-time interface library in the build script, and specifies the linking order and symbol resolution priority of the real-time interface library and its dependencies in the linking options; it sets a call adaptation layer in the runtime key library to redirect the abstract interfaces of timing, scheduling and synchronization to the equivalent interfaces of the real-time interface library; it replaces the general implementation with the implementation provided by the real-time interface library through conditional compilation or link aliases; it maps synchronization primitives to the synchronization interfaces provided by the real-time interface library, maps thread creation, priority configuration and processor affinity settings to the task and scheduling interfaces provided by the real-time interface library, and maps timing and timer creation to the clock and timing interfaces provided by the real-time interface library.

[0122] In some embodiments, Figure 2 The modification module 202 introduces the header files, type definitions, and constant declarations of the real-time device driver model into the construction configuration of the runtime critical library, completing symbol visibility and dependency registration; it establishes a device access adaptation layer in the runtime critical library, providing a unified device access interface for user space; it maps device interrupts and event notifications to event and timer interfaces provided by the real-time interface library, and wakes up and waits in user space with configurable timeouts; it establishes a mapping between device access error codes and status codes, unifying the encoding returned by the real-time device driver model to the error representation of the runtime critical library; and it generates a configuration manifest and linker for the device access adaptation layer, so that the configuration manifest and linker are referenced by the toolchain during compilation and linking and integrated with the real-time application.

[0123] In some embodiments, Figure 2 The modification module 202 registers real-time attributes for real-time critical concurrent units in the runtime critical library, and generates corresponding real-time tasks according to the real-time attributes when creating real-time critical concurrent units; it sets processor affinity for real-time critical concurrent units in the form of affinity masks or processor sets, and adopts affinity configuration in task creation and migration control; based on the clock and timing services provided by the real-time interface library, it creates timers for real-time critical concurrent units, including single-time timing and periodic timing, and uses a unified time base for expiration judgment and wake-up; it maps the event waiting, wake-up and timeout handling associated with concurrent units to the synchronization and timing interfaces provided by the real-time interface library, and records real-time attributes, affinity configuration and timer parameters in the configuration list of the runtime critical library, so as to pre-configure and integrate with real-time applications during compilation and linking.

[0124] In some embodiments, Figure 2The compilation module 203 selects a modified compiler at the compilation entry point and loads pre-set parameter templates and linking scripts. During the compilation process, it references the configuration manifests of runtime key libraries and device access adaptation layers, incorporating the header file paths, library file paths, and symbol resolution rules recorded therein into the compilation and linking scope. During the linking phase, it links the real-time interface library and dependent libraries in a preset order and merges the call mappings related to timing, scheduling, and synchronization in the configuration manifest. It generates an executable file or loadable target containing runtime key libraries and device access adaptation layers, and outputs the corresponding symbol table and link identifier. For different processor architectures, it calls the matching modified toolchain to complete the same compilation and linking process, and reuses the built modified toolchain and parameter templates under the same processor architecture.

[0125] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0126] Figure 3 This is a schematic diagram of the electronic device 3 provided in an embodiment of this application. Figure 3 As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various device embodiments described above.

[0127] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or different components.

[0128] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0129] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 3. The memory 302 can also include both internal and external storage units of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device.

[0130] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0131] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which may be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0132] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A real-time program compilation method for a real-time kernel, characterized in that, include: An operating system with real-time kernel capabilities is built and run on the target hardware platform, and the real-time interface library and real-time device driver model of the operating system are determined as dependencies for compilation and linking. The high-level language compiler and runtime key library are modified in real time to generate a modified toolchain. The real-time modification includes introducing the real-time interface library into the construction and linking configuration of the runtime key library, bringing the interface and data structure of the real-time device driver model into the visibility of the runtime key library, and setting real-time constraints on the concurrent scheduling and timer mechanism. The modified toolchain is used to compile the application source code, and the real-time interface library is introduced during the linking stage to obtain a real-time application that runs on the operating system. The runtime critical library configures real-time critical concurrency units during execution. The configuration includes specifying the priority of the underlying real-time tasks for the real-time critical concurrency units, specifying the processor affinity for the real-time critical concurrency units, and encapsulating system calls that cause non-deterministic blocking in a restricted manner. The configuration is integrated into the real-time application along with the runtime critical library during the compilation and linking process. The real-time modification of high-level language compilers and key runtime libraries to generate a modified toolchain includes: The real-time interface library is introduced into the construction and linking configuration of the runtime critical library, and a call mapping from timing, scheduling and synchronization related calls to the real-time interface library is established. The interfaces and data structures of the real-time device driver model are included in the visibility scope of the runtime key library, and a device access adaptation layer is set up for user-mode calls. Real-time constraints are set for the concurrent scheduling and timer mechanism, including establishing priority binding relationships between real-time key concurrent units and corresponding real-time tasks, and setting processor affinity for the real-time key concurrent units; System calls that cause nondeterministic blocking are encapsulated in a restricted manner and replaced or bypassed with equivalent interfaces provided by the real-time interface library. The timing and wake-up paths are configured uniformly so that the runtime key libraries are pre-configured with the clock and timing services provided by the real-time interface library as the time base during compilation and linking; The compiler options pre-configure the parameter templates for linking the real-time interface library and its dependencies, and output a modified toolchain for compilation and linking.

2. The method according to claim 1, characterized in that, The process of building and running an operating system with real-time kernel capabilities on the target hardware platform, and determining the real-time interface library and real-time device driver model of the operating system as dependencies for compilation and linking, includes: The collaborative kernel construction method or compatible construction method based on the real-time framework generates and enables the runtime environment of the real-time kernel on the target hardware platform; Install a real-time interface library that matches the operating environment and enable the device access interface based on the real-time device driver model. The header files, binary data, and symbol information of the real-time interface library and the real-time device driver model are registered as a compilation and linking dependency list, and a version identifier is set for the compilation and linking dependency list; The timing source, preemption and priority strategies, and device access channels are parameterized, and the parameterization settings are used as the interface configuration of the runtime critical library. The availability of the real-time interface library and device access interface is verified in the runtime environment, and the link configuration and retrieval path that can be called by the compiler and toolchain are provided to the outside world.

3. The method according to claim 1, characterized in that, The real-time interface library is introduced into the construction and linking configuration of the runtime key library, and a call mapping from timing, scheduling, and synchronization-related calls to the real-time interface library is established, including: In the build script, set the header file and library file search path of the real-time interface library, and specify the linking order and symbol resolution priority of the real-time interface library and its dependencies in the linking options; In the runtime critical library, a call adaptation layer is set up to redirect the abstract interfaces of timing, scheduling and synchronization to the equivalent interfaces of the real-time interface library; The generic implementation can be replaced with the implementation provided by the real-time interface library by means of conditional compilation or linking aliases; Synchronization primitives are mapped to the synchronization interfaces provided by the real-time interface library; thread creation, priority configuration, and processor affinity settings are mapped to the task and scheduling interfaces provided by the real-time interface library; and timing and timer creation are mapped to the clock and timer interfaces provided by the real-time interface library.

4. The method according to claim 1, characterized in that, The step of incorporating the interfaces and data structures of the real-time device driver model into the visibility scope of the runtime key library, and setting up a device access adaptation layer for user-mode invocation, includes: In the build configuration of the runtime critical library, the header files, type definitions and constant declarations of the real-time device driver model are included to complete symbol visibility and dependency registration; A device access adaptation layer is established in the runtime critical library to provide a unified device access interface for user space; The device interruption and event notification are mapped to the event and timing interfaces provided by the real-time interface library, and wake-up and waiting are performed in user space with configurable timeouts. Establish a mapping between error codes and status codes for device access, and unify the encoding returned by the real-time device driver model into the error representation of the runtime key library; Generate a configuration manifest and link identifier for the device access adaptation layer, so that the configuration manifest and link identifier are referenced by the toolchain during compilation and linking and integrated with the real-time application.

5. The method according to claim 1, characterized in that, The real-time constraints set for the concurrent scheduling and timer mechanism include establishing priority binding relationships between key real-time concurrent units and corresponding real-time tasks, and setting processor affinity for the key real-time concurrent units, including: Register real-time attributes for real-time critical concurrent units in the runtime critical library, and generate corresponding real-time tasks according to the real-time attributes when creating real-time critical concurrent units; Set processor affinity for real-time critical concurrent units in the form of affinity masks or processor sets, and adopt affinity configuration in task creation and migration control; Based on the clock and timing services provided by the real-time interface library, timers are created for real-time key concurrent units. The timers include single-time timing and periodic timing, and expiration determination and wake-up are performed using a unified time base. The event wait, wake-up, and timeout handling associated with concurrent units are mapped to the synchronization and timing interfaces provided by the real-time interface library, and the real-time attributes, affinity configurations, and timer parameters are recorded in the configuration manifest of the runtime key library so that they can be pre-configured and integrated with the real-time application during compilation and linking.

6. The method according to claim 1, characterized in that, The process of compiling the application source code using the modified toolchain, and introducing the real-time interface library during the linking phase to obtain a real-time application running on the operating system includes: At the compilation entry point, select the modified compiler and load the preset parameter templates and linker scripts; During the compilation process, the configuration list of the runtime key library and device access adaptation layer is referenced, and the header file path, library file path and symbol resolution rules recorded therein are included in the compilation and linking scope; During the linking phase, the real-time interface library and its dependent libraries are linked in a preset order, and the call mappings related to timing, scheduling, and synchronization in the configuration list are merged. Generate an executable file or loadable target containing the aforementioned runtime key libraries and device access adaptation layer, and output the corresponding symbol table and link identifier; For different processor architectures, the same compilation and linking process is completed by calling the matching modified toolchain, and the built modified toolchain and parameter templates are reused under the same processor architecture.

7. A real-time program compilation device for a real-time kernel, characterized in that, include: The building module is used to build and run an operating system with real-time kernel capabilities on the target hardware platform, and to determine the real-time interface library and real-time device driver model of the operating system as dependencies for compilation and linking. The modification module is used to perform real-time modification of the high-level language compiler and runtime key library to generate a modified toolchain. The real-time modification includes introducing the real-time interface library in the construction and linking configuration of the runtime key library, bringing the interface and data structure of the real-time device driver model into the visibility of the runtime key library, and setting real-time constraints on the concurrent scheduling and timer mechanism. A compilation module is used to compile the application source code using the modified toolchain, and to introduce the real-time interface library during the linking stage to obtain a real-time application running on the operating system. The runtime critical library configures real-time critical concurrency units during execution. This configuration includes specifying the priority of underlying real-time tasks for the real-time critical concurrency units, specifying processor affinity for the real-time critical concurrency units, and encapsulating system calls that cause non-deterministic blocking. This configuration is integrated into the real-time application along with the runtime critical library during the compilation and linking process. The modification module is used to introduce the real-time interface library into the construction and linking configuration of the runtime critical library, establish a call mapping from timing, scheduling, and synchronization-related calls to the real-time interface library; include the interfaces and data structures of the real-time device driver model within the visibility scope of the runtime critical library, and set a device access adaptation layer for user-mode calls; set real-time constraints on the concurrent scheduling and timer mechanisms, including establishing priority binding relationships between real-time critical concurrent units and corresponding real-time tasks, and setting processor affinity for the real-time critical concurrent units; encapsulate system calls that generate non-deterministic blocking in a restricted manner, and replace or bypass them with equivalent interfaces provided by the real-time interface library; uniformly configure the timing and wake-up paths so that the runtime critical library is pre-set to use the clock and timing services provided by the real-time interface library as the time base during compilation and linking; pre-set the parameter templates for linking the real-time interface library and its dependencies in the compiler options, and output the modified toolchain for compilation and linking.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 6.

Images