Method and apparatus for processing embedded device service

Abstract

This application discloses a method and apparatus for processing embedded device services. The method includes: during the compilation phase, generating a static instance description file based on a pre-configured system configuration file; based on the static instance description file, creating a target service instance for each service type of device service, and dynamically binding the target service instance to the underlying physical peripheral of the embedded device, creating concurrent and scheduling resources compatible with the target operating system of the embedded device; responding to asynchronous events generated by the underlying physical peripheral, obtaining raw hardware data generated by the underlying physical peripheral based on the target service instance, and parsing the raw hardware data into service data packets corresponding to the device service and possessing business semantics; responding to data acquisition instructions from the application layer, acquiring the service data packets, and running the device service on the target hardware platform. This application solves the technical problem of low reuse efficiency of embedded device services across different hardware platforms.

Description

Technical Field

[0001] This application relates to the field of embedded systems technology, and more specifically, to a method and apparatus for processing embedded device services. Background Technology

[0002] In current embedded systems, hardware abstraction is typically achieved by uniformly encapsulating low-level driver interfaces such as GPIO (General Purpose Input / Output), UART (Universal Asynchronous Receiver / Transmitter), and SPI (Serial Peripheral Interface). However, upper-level business functions (such as status indication, button detection, serial communication, etc.) still require repeated writing of device initialization logic, interrupt callback handling logic, message queue management logic, thread scheduling logic, etc., for specific business and different operating systems.

[0003] In other words, the service logic of embedded device services is heavily coupled with specific operating systems. This means that when migrating the same device service across different hardware platforms, upper-layer applications still need to repeatedly write code for specific business functions to apply the same device service to different hardware platforms. In other words, in traditional solutions, the application layer still needs to be aware of the processing details of asynchronous events in the underlying device driver layer and repeatedly develop based on these details, consuming a significant amount of time and manpower. This results in the technical problem of low reuse efficiency of embedded device services across different hardware platforms.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method and apparatus for processing embedded device services, so as to at least solve the technical problem of low reuse efficiency of embedded device services across different hardware platforms.

[0006] According to one aspect of the embodiments of this application, a method for processing embedded device services is provided, comprising: during the compilation phase, generating a static instance description file based on a pre-configured system configuration file, wherein the static instance description file includes the service type of the device service to be enabled on the target hardware platform, the device name of the underlying physical peripheral bound to it, and service running parameters; based on the static instance description file, creating a target service instance for each service type of the device service, and dynamically binding the target service instance to the underlying physical peripheral of the embedded device through a device adaptation layer, and creating concurrency and scheduling resources compatible with the target operating system of the embedded device through a kernel object adaptation layer; responding to an asynchronous event generated by the underlying physical peripheral, obtaining raw hardware data generated by the underlying physical peripheral based on the target service instance, and parsing the raw hardware data into a service data packet corresponding to the device service and having business semantics; responding to a data acquisition instruction from the application layer, obtaining the service data packet through a standardized service interface, and running the device service on the target hardware platform.

[0007] According to another aspect of the embodiments of this application, an embedded device service processing apparatus is also provided, comprising: a first processing unit, configured to generate a static instance description file based on a pre-configured system configuration file during the compilation phase, wherein the static instance description file includes the service type of the device service to be enabled on the target hardware platform, the device name of the bound underlying physical peripheral, and service running parameters; a creation unit, configured to create a target service instance for each service type of the device service based on the static instance description file, and dynamically bind the target service instance to the underlying physical peripheral of the embedded device through a device adaptation layer, and create concurrency and scheduling resources compatible with the target operating system of the embedded device through a kernel object adaptation layer; a first acquisition unit, configured to acquire the raw hardware data generated by the underlying physical peripheral based on the target service instance in response to an asynchronous event generated by the underlying physical peripheral, and parse the raw hardware data into a service data packet corresponding to the device service and having business semantics; and a second processing unit, configured to acquire the service data packet through a standardized service interface in response to a data acquisition instruction from the application layer, and run the device service on the target hardware platform.

[0008] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, which is used to execute the above-described embedded device service processing method when the electronic device is run.

[0009] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0010] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the processing method of the embedded device service through the computer program.

[0011] Using the embodiments provided in this application, a static instance description file (which can also be understood as a static service instance description table) is generated based on the system configuration file during compilation, solidifying the service logic of the device service and decoupling the service logic from the hardware platform. During runtime, the device adaptation layer uses the same abstract underlying peripheral access interface to shield the differences in device access across different hardware platforms, and the kernel object adaptation layer unifies the invocation of system resources such as threads and queues. Underlying asynchronous events are parsed into service data packets with the same business semantics, allowing the application layer to apply the device service to the corresponding hardware platform without needing to be aware of interrupt methods and protocol details, by directly calling the standardized service interface. In other words, by building a device adaptation layer and a kernel object adaptation layer between the underlying device driver layer and the application layer, the service logic is separated from the underlying hardware and system implementation, enabling the same device service to run on multiple platforms with a single development effort. This avoids redundant development and adaptation of the application layer when the same device service runs across platforms, improving the reuse efficiency of device services across hardware platforms. Attached Figure Description

[0012] The accompanying drawings, which are provided to further illustrate this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application.

[0013] Figure 1 This is an overall architecture diagram of an optional embedded device service processing method according to an embodiment of this application.

[0014] Figure 2 This is a flowchart of an optional embedded device service processing method according to an embodiment of this application.

[0015] Figure 3 This is an overall schematic diagram of an optional embedded device service processing method according to an embodiment of this application.

[0016] Figure 4 This is an overall flowchart of an optional configuration-compilation-running three-stage process according to an embodiment of this application.

[0017] Figure 5 This is a flowchart of an optional device service software migration according to an embodiment of this application.

[0018] Figure 6This is an overall flowchart of an optional embedded device service processing method according to an embodiment of this application.

[0019] Figure 7 This is a schematic diagram of an optional audio / video stream processing apparatus according to an embodiment of this application.

[0020] Figure 8 This is a schematic diagram of the structure of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0021] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0023] The technical solutions in this application will comply with legal regulations during implementation. When operating according to the technical solutions in the embodiments, the data used will not involve user privacy, ensuring that the operation process is compliant and legal while guaranteeing data security. In addition, when the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use, and processing of related data must comply with the relevant regulations and standards of the relevant countries or regions.

[0024] According to one aspect of the embodiments of this application, a method for processing embedded device services is provided. As an optional implementation, the above-described method for processing embedded device services may, but is not limited to, using... Figure 1 The overall structure diagram shown is used to implement this.

[0025] Specifically, such as Figure 1As shown, unlike traditional technical solutions, this embodiment constructs a service intermediary layer between the application layer and the underlying device driver layer. This service intermediary layer may, but is not limited to, include a device adaptation layer and a kernel object adaptation layer. The device adaptation layer is used to shield the differences in device models across different hardware platforms, ensuring that the service layer does not directly depend on the device object definition of a specific operating system. The device adaptation layer can also be abstracted into a unified set of interfaces, including device discovery, device opening, device closing, device read / write, device control, callback registration, user context binding, and interrupt or completion event reporting.

[0026] In RT-Thread (an open-source real-time operating system), the above interfaces can be mapped to the device framework; in FreeRTOS (Free Real-Time Operating System), Zephyr (a real-time operating system for IoT and embedded security scenarios), ThreadX (a commercial real-time operating system), or bare-metal environments, they can be mapped to the corresponding device management layer or a custom device table. In other words, by utilizing the above set of interfaces, the device adaptation layer shields the differences in device access interfaces across different operating systems or platforms, providing a unified device abstraction interface to the outside world.

[0027] The kernel object adaptation layer can, but is not limited to, shield the differences in concurrency and scheduling mechanisms between different real-time operating systems or bare-metal environments, and provide a unified runtime resource interface to the outside world, including but not limited to interfaces for thread / task creation, message queue creation and sending / receiving, mutexes / semaphores, event notification, software timers, delay interfaces, critical section protection, and bare-metal polling alternative execution mechanisms.

[0028] For bare-metal environments lacking a complete RTOS (Real-Time Operating System) kernel object, service platform reuse can be achieved through loops, timed interrupt scheduling, polling task dispatchers, alternative threads, and message queue execution mechanisms. Through these interfaces, the kernel object adaptation layer can shield the differences between different operating system kernel mechanisms.

[0029] In this embodiment, the service middleware layer is constructed using a unified service construction rule for all types of device services. For example, the compiler determines whether to enable the service, determines the service's capability combination and parameter set, creates a service instance at runtime, binds the underlying device through the device adaptation layer, creates runtime resources through the kernel object adaptation layer, maps underlying callbacks to the service instance, converts asynchronous events into service events (or service data packets), and exposes a unified service semantic interface (e.g., providing a unified service semantic interface for the application layer).

[0030] After being processed by the dual adaptation layers (device adaptation layer and kernel object adaptation layer) of the service middleware layer, the application layer directly calls service data packets with consistent business semantics, unified format and the same business functions through standardized service interfaces, thereby applying the device service to the corresponding hardware platform.

[0031] It is evident that by establishing a service middleware layer on top of the device driver layer, not only can the driver layer be reused, but also higher-level business service logic can be reused, reducing redundant development. Through the device adaptation layer and the kernel object adaptation layer, the service logic is decoupled from specific operating systems and device models, enabling migration across real-time operating systems or bare-metal environments. In other words, cross-platform operation is achieved through dual adaptation layers.

[0032] The technical solution presented in this application can be applied, but is not limited to, to embedded application scenarios where device function reusability, system portability, and development efficiency (i.e., resource consumption) are sensitive. Examples include manufacturers developing multiple models of medical monitoring equipment and industrial control system integration aimed at chip replacement.

[0033] To address this issue, this application proposes a method for processing embedded device services. Figure 2 This is a flowchart of an embedded device service processing method according to an embodiment of this application, which includes the following steps S202 to S208.

[0034] It should be noted that the embedded device service processing method shown in steps S202 to S208 can be executed by, but is not limited to, an electronic device. The electronic device can be, but is not limited to, a device that... Figure 1 The target terminal or server shown.

[0035] Step S202: During the compilation phase, a static instance description file is generated based on the pre-configured system configuration file. The static instance description file includes the service type of the device service to be enabled on the target hardware platform, the device name of the underlying physical peripheral device to be bound, and the service operation parameters.

[0036] Step S204: Based on the static instance description file, create a target service instance for each service type of the device service, and dynamically bind the target service instance to the underlying physical peripheral of the embedded device through the device adaptation layer. Create concurrent and scheduling resources compatible with the target operating system of the embedded device through the kernel object adaptation layer.

[0037] Step S206: In response to the asynchronous event generated by the underlying physical peripheral, based on the target service instance, obtain the raw hardware data generated by the underlying physical peripheral, and parse the raw hardware data into a service data packet that corresponds to the device service and has business semantics.

[0038] Step S208: In response to the data acquisition instruction from the application layer, the service data packet is acquired through the standardized service interface, and the device service is run on the target hardware platform.

[0039] To implement the above-mentioned embedded device service processing method, embodiments of this application provide a method such as... Figure 3 The overall structure diagram shown is as follows. Figure 3 Multiple modules or processing layers are illustrated. For example, the upper application layer only needs to call a unified service interface layer to achieve seamless migration across platforms and systems. The reason why the same service logic can be migrated across platforms is because a service layer or service middleware is introduced between the application layer and the device driver layer. The service middleware includes service registration and discovery, a device abstraction layer (device adaptation layer), and an operating system abstraction layer (kernel object adaptation layer). For an explanation of the device adaptation layer and the kernel object adaptation layer, please refer to the description in the above embodiments; it will not be repeated here.

[0040] After processing through a dual adaptation layer and asynchronous events, the underlying device events are converted into event data with the same business semantics, which can be understood as service data packets. For different hardware platforms, the data structure and business semantics of service data packets for the same device service are the same, but the underlying implementation differs. Applying service data packets to different hardware platforms enables the device service to run on those platforms.

[0041] The service instances mentioned above can be, but are not limited to, business service objects that are dynamically created during system runtime based on compile-time configuration, specifically bound to a physical device and occupying specific system resources, can be called by the application layer, and have a complete lifecycle.

[0042] The aforementioned system configuration files can be, but are not limited to, those pre-configured by the automated system through visual selections made by developers during the static building and trimming phases of the system. The detailed steps of the system static building and trimming are described below.

[0043] The aforementioned concurrency and scheduling resources include, but are not limited to, message queues, mutexes, and semaphores. The scheduling resources include dedicated task threads or polling scheduling mechanisms.

[0044] S11, interactive configuration and parameter capture.

[0045] Developers can visually select system capabilities using configuration tools (such as Kconfig menu configuration tool Menuofnig or other graphical configuration interfaces). The configuration tool captures the user's selection status for the target platform (such as specifying a specific chip model), target operating system, and target services to be enabled (such as serial port service, button service), and saves it as a structured system configuration file.

[0046] In this embodiment, the developer selects to enable the serial port service (enable_uart_service) and sets the parameters required by the uart_service_cfg_t structure, such as setting the receive buffer size to 1024 bytes, the receive message queue depth to 16, and setting the priority of the dedicated thread.

[0047] S12, cross-platform dependency binding and conditional compilation trimming.

[0048] The automated build script reads and parses the aforementioned system configuration files before compilation.

[0049] Regarding platform binding: The build script dynamically adjusts the header file include path of the source files based on the selected chip and system type, and adds specific underlying device adaptation layer (DAL) code and operating system abstraction layer (OSAL) code to the compilation tree.

[0050] Regarding the trimming mechanism: The build script generates a global configuration macro header file (such as system_config.h) based on configuration parameters. During the compilation process, the compiler identifies pre-embedded conditional compilation directives in the code (such as #ifdefENABLE_UART_SERV) and directly removes unenabled service module code and related dependencies during the preprocessing stage, thereby achieving extreme trimming of firmware size without occupying any Flash and RAM resources.

[0051] S13, Automatic generation of static instance description tables.

[0052] During the compilation preprocessing stage, a pre-defined text processing script (such as Python) is built to call the system calls and iterates through the enabled service modules. A static service instance description table (i.e., an array of structures of type service_instance_t) is automatically generated. This description table records the name of each enabled service, the name of the physical device it depends on, and its standard operation interface pointer, serving as the sole basis for dynamic resource allocation after the system powers on.

[0053] The processing steps S11 to S13 above can be referred to Figure 6 Step S1 is shown.

[0054] After the system configuration file is set, the compilation phase begins. During this phase, the user-interactive configuration tool obtains the developer's configuration intent regarding the target hardware platform, operating system, and required device services. This includes which services to enable (such as serial port services and button services), the device name of the bound physical device, buffer size, thread priority, polling cycle, and other runtime parameters. This configuration information is parsed by the automated build system to generate a structured static instance description file. Essentially, this is a compile-time determined, immutable array of structures that records the metadata of each service to be instantiated.

[0055] It should be noted that by fixing the service runtime parameters during compilation, the service runtime parameters will not change during runtime. This is the basis for decoupling the service logic from the underlying operating system interface.

[0056] In this way, the unselected service modules and their dependent code are completely removed during the preprocessing stage, achieving extreme compression of firmware size, avoiding the waste of resources by invalid code at runtime, and providing compile-time guarantees for lightweight embedded systems.

[0057] Based on this static instance description file, during the startup initialization phase, the system sequentially creates independent target service instances for each service to be enabled. Each service instance not only contains the business logic (or service logic) state of the device service itself, but also dynamically binds to the underlying physical peripherals through the device adaptation layer. For example, it calls the device lookup interface to obtain the device handle corresponding to sensor_uart, and calls the open interface to complete hardware initialization; simultaneously, it creates concurrent resources compatible with the target operating system through the kernel object adaptation layer, such as allocating a dedicated thread for the service, creating a message queue for asynchronous event transmission, and establishing mutexes to ensure multi-task access safety. This process decouples the service logic from the underlying operating system interface. Regardless of the type of operating system or bare metal system of the target platform, the creation of service instances and resource requests are completed through a unified abstract interface, ensuring cross-platform portability.

[0058] When an asynchronous event occurs from the underlying physical peripheral (such as UART receiving data or button level changes), the device adaptation layer captures the raw hardware data in the interrupt context. However, it does not process the data directly but instead calls a dedicated callback function registered by the target service instance during initialization. This callback function performs only a quick operation in the interrupt context: writing the raw bytes into a circular buffer inside the target service instance and posting a lightweight wake-up event to the service's dedicated message queue through the kernel object adaptation layer. Then, the target service instance's dedicated thread is scheduled to run in the task context, reads and reassembles the raw hardware data from the buffer, and transforms it into a service data packet with clear business semantics according to a preset protocol (such as frame header verification, CRC verification, and protocol parsing), for example, a button press or complete data frame reception, thus masking underlying differences such as voltage polarity, interrupt triggering methods, and bus protocols.

[0059] When the application layer needs to obtain service results, it only needs to call the standardized service interface (such as read, write, control) provided by the target service instance. This interface is uniformly implemented internally by the service instance, which automatically handles resource locking, data reading, state synchronization, and other operations without requiring the application layer to concern itself with any underlying mechanisms. Ultimately, the entire service runs with completely consistent interfaces and behaviors across different hardware platforms and operating systems.

[0060] In other words, during the configuration phase, the hardware platform on which the device service runs and the device services to be enabled (such as serial port service, button service, etc.) are pre-defined, and a system configuration file is generated. Then, the service middleware layer automatically creates service instances, responds to asynchronous events, and converts hardware events into service events. This allows the application layer to directly call standardized service interfaces to apply the service to different hardware platforms, achieving the technical effect of "write once, deploy across multiple platforms".

[0061] In other words, the embodiments of this application are based on system configuration files and automatically rebuild service instances for different hardware platforms, dynamically instantiate static configurations, bind hardware data of physical devices with service logic, capture asynchronous events, and convert business semantics, thereby enabling the same device service to run on different hardware platforms.

[0062] Using the embodiments provided in this application, a static instance description file (which can also be understood as a static service instance description table) is generated based on the system configuration file during compilation, solidifying the service logic of the device service and decoupling the service logic from the hardware platform. During runtime, the device adaptation layer uses the same abstract underlying peripheral access interface to shield the differences in device access across different hardware platforms, and the kernel object adaptation layer unifies the invocation of system resources such as threads and queues. Underlying asynchronous events are parsed into service data packets with the same business semantics, allowing the application layer to apply the device service to the corresponding hardware platform without needing to be aware of interrupt methods and protocol details, by directly calling the standardized service interface. In other words, by building a device adaptation layer and a kernel object adaptation layer between the underlying device driver layer and the application layer, the service logic is separated from the underlying hardware and system implementation, enabling the same device service to run on multiple platforms with a single development effort. This avoids redundant development and adaptation of the application layer when the same device service runs across platforms, improving the reuse efficiency of device services across hardware platforms.

[0063] As an optional example, the creation of a target service instance for each service type of device service based on the static instance description file includes: generating an initialization service instance based on the static instance description file; matching the interrupt handling function pointer corresponding to the device name from the underlying driver list and pointing to the underlying device driver layer; reading buffer information from the system configuration file and dynamically allocating a circular buffer memory space for the initialization service instance according to the buffer size; reading thread parameters from the system configuration file and creating a dedicated service thread with independent scheduling attributes according to the thread priority and thread stack size, wherein the thread parameters include the thread priority and the thread stack size; and encapsulating the interrupt handling function pointer, the circular buffer memory space, and the dedicated service thread to obtain the encapsulated target service instance.

[0064] In this embodiment, the generated initial service instance is not an empty object, but rather a fully structured, initial-form service instance constructed based on each service entry predefined in the static instance description table. This initial service instance contains multiple structured variables, such as service name, target device name, buffer size, thread priority, and other key metadata, which serve as the basis for subsequent resource binding.

[0065] The aforementioned matching of the underlying interrupt handler pointer based on the device name essentially implements dynamic binding of the Device Adaptor Layer (DAL). In the RT-Thread system, the device name `sensor_uart` corresponds to the device object returned by `rt_device_find("sensor_uart")`; while in a bare-metal environment, this name may map to a specific structure in a global device array. Regardless of the underlying implementation, the service middleware layer obtains the device handle through the unified `device_find()` interface; then, through the callback registration mechanism in the device object, it captures its underlying interrupt handler (such as the UART receive interrupt function) and redirects it to the unified processing entry point of the service middleware layer, such as `uart_rx_adapter()`, thereby decoupling the interrupt event from the service context. At this point, the application layer does not need to be aware of which register triggered the interrupt.

[0066] The dynamic allocation of the circular buffer based on the buffer size described above is crucial to ensuring that asynchronous data is not lost. For example, if the configuration file specifies the receive buffer as 1024 bytes, the system will call malloc() or a static memory pool to allocate contiguous memory and initialize the circular buffer structure (including read / write pointers and full / empty flags). This buffer is dedicated to this service instance and is isolated from other serial port services.

[0067] The above-described method of creating a dedicated service thread based on thread parameters enables independent scheduling of the service. Thread priority indicates the service's response priority within the system, and a stack size of 2048 bytes ensures its ability to safely handle complex protocol parsing. This thread is not a shared, general-purpose task, but rather an execution container exclusive to this service. Its entry function points to the service's unique processing logic, guaranteeing the real-time performance and isolation of service event processing.

[0068] By encapsulating the interrupt handling function pointer, the circular buffer memory space, and the dedicated service thread, these scattered resources are abstracted into a single service object. The encapsulated target service instance no longer exposes underlying details, only providing unified interfaces such as `read()` and `write()`. When the application layer calls this, it doesn't need to worry about how interrupts are triggered, how buffers are managed, or when threads are woken up; these are all fixed by the service middleware layer during instantiation.

[0069] As an optional implementation, the above-described encapsulation of the interrupt handling function pointer, the circular buffer memory space, and the dedicated service thread to obtain the encapsulated target service instance includes: replacing the interrupt handling function pointer with a custom context function of the service intermediate layer through the callback setting interface of the device adaptation layer, wherein the service intermediate layer includes the device adaptation layer and the kernel object adaptation layer, the device adaptation layer is used to shield the interface differences of device access from different operating systems, and the kernel object adaptation layer is used to shield the concurrency and scheduling mechanisms of different operating systems; and encapsulating the custom context function, the circular buffer memory space, and the dedicated service thread to obtain the target service instance.

[0070] The process of creating the target service instance described above can be understood as dynamically instantiating static configuration and creating dedicated system call resources for the device service. The overall implementation process can be found in [reference needed]. Figure 6 The processing steps of the dynamic instantiation and resource binding phase in step S2 are as follows: S21 to S24.

[0071] Figure 6 The core of step S2 is to transform the static configuration into a runnable instance in memory and complete the binding of physical devices and service logic. The following description uses the serial port service initialization function serv_uart_init as an example to further describe the overall process of dynamic instantiation and resource binding.

[0072] S21, Device handle lookup and opening.

[0073] After the service object is instantiated, the service middleware layer calls the device adaptation layer (DAL) lookup interface (such as dal_uart_find), passes in the physical device name in the system configuration file (such as the target serial port name sensor_uart), matches the corresponding physical device handle in the underlying driver chain, and calls the open interface (such as open) to initialize the hardware peripheral.

[0074] In this context, a device handle can refer to, but is not limited to, a reference identifier returned uniformly by the device adaptation layer for identifying and operating a specific hardware device. Essentially, it is an opaque pointer or integer number. The application layer and service layer can only use the device handle through the standardized interface provided by the device adaptation layer without needing to understand its underlying hardware implementation or operating system kernel object structure.

[0075] S22, Multi-level caching mechanism initialization.

[0076] To ensure that asynchronous data is not lost, the system initializes (i.e. creates) multi-level circular buffers for the service object (such as the receive circular buffer rx_rb, the send circular buffer tx_rb, or the emergency send buffer (tx_urgent_rb), and allocates corresponding memory space for them.

[0077] S23, System concurrent resource creation.

[0078] The service middleware calls the OS Abstraction Layer (OSAL) interface to create dedicated system scheduling resources for the service, including mutexes (such as tx_mutex) for protecting concurrent access, message queues (such as rx_mq and tx_mq) for asynchronous event notification, and dedicated service processing threads with specific priorities (the entry function points to uart_tx_entry).

[0079] S24, Interrupt Callback Takeover and Service Registration.

[0080] By using the callback settings interfaces of the DAL (such as set_rx_callback and set_tx_callback), the pointers to the physical interrupt handling functions of the underlying hardware are replaced with custom context functions of the service middleware. Finally, the assembled target service instance (including service name, device handle, standard operation interface, etc.) is mounted into the global service registry (by calling service_register).

[0081] To achieve standardized management and cross-platform decoupled operation of embedded device services, after the service instance is dynamically initialized, the service name, bound device handle, unified operation interface pointer, and runtime context information contained in the service instance are uniformly registered in the system's pre-built global service registry. The global service registry is a static structure array automatically generated at compile time, used to centrally record the metadata information of all enabled services.

[0082] The purpose of performing the above mounting operation is to: (1) establish a logical mapping relationship between service entities and service access entry points, so that upper-layer applications or system modules do not need to be aware of the specific implementation path, initialization function or underlying device model of the service, and can dynamically obtain the corresponding service instance and its standard operation set through a unified interface only by the service name; (2) achieve complete decoupling between service calls and service implementation, eliminate the problem of tight coupling between modules caused by hard coding of service initialization functions in traditional embedded systems, and improve the modularity and maintainability of the system; (3) provide the system with a service resource directory that can be traversed and queried, support runtime service discovery, automated service dependency management, diagnosis and debugging and dynamic function expansion, and provide a structured data foundation for subsequent implementation of service hot-plugging, remote configuration or service upgrade; (4) serve as the basis for service lifecycle management, ensure the integrity and consistency of service initialization, and avoid runtime errors caused by unmet dependencies between device services.

[0083] In other words, the service name, device handle, and unified operation interface pointer contained in the initialized target service instance are mounted to the global service registry. The global service registry is a static structure array automatically generated during compilation based on configuration information. It is used for upper-layer applications to dynamically query and call the standard operation interface of the target service instance by service name, without depending on the specific implementation function of the service or the underlying device driver interface.

[0084] As an optional example, the above-described method of dynamically binding the target service instance to the underlying physical peripheral of the embedded device through a device adaptation layer includes: based on the device name, calling the device lookup interface provided by the device adaptation layer to obtain the device handle of the underlying physical peripheral that matches the device name; associating the context pointer of the target service instance with the device handle by calling the device binding interface provided by the device adaptation layer; and registering the callback function used to handle asynchronous events of the underlying physical peripheral to the device handle by calling the callback registration interface provided by the device adaptation layer, and enabling the callback function to access the local resources of the target service instance through the context pointer in an interrupt context.

[0085] In the cross-platform embedded service middleware architecture of this application, the key to decoupling service logic from hardware implementation lies in the dynamic binding between service instances and underlying physical peripherals. This process does not simply create a pointer reference, but rather constructs a service-semantic-oriented device-service association through standardized interfaces provided by the device adaptation layer. This allows the same service (such as a status indicator light) to run on different hardware platforms without modifying the underlying code of the service logic.

[0086] Specifically, based on the device names preset in the system configuration file, the unified device lookup interface of the device adaptation layer is invoked. This interface does not directly access hardware registers or bus addresses, but instead traverses all registered device handles in the system, locating the target device's metadata by matching the strings in the device handles. For example, in the RT-Thread system, this interface might traverse the device driver linked list; in a bare-metal system, it queries a predefined device registry. Regardless of the underlying device management mechanism, the upper layer only needs to pass in the parsed semantic name, without needing to know whether the device is a UART3, GPIO15, or SPI-controlled peripheral chip. This completely decouples service configuration from hardware topology, enabling on-demand naming and automatic matching.

[0087] Secondly, after obtaining the matching device handle, the device binding interface of the device adaptation layer is called to associate the context pointer of the target service instance (containing private data such as service status, circular buffer, timers, and task handles) with the device handle. This operation does not inject the service object into the device driver, but rather reserves a specific space in the device object for quickly locating the corresponding service instance when an interrupt callback occurs. For example, when a vibration service is bound to a PWM output channel, the private context field of the PWM device points to the structure of the vibration service, so that any subsequent callbacks triggered by the completion of the PWM cycle or changes in duty cycle can directly access the vibration intensity parameters and duration counter of the device service without needing a global lookup or passing redundant parameters.

[0088] Then, through the callback registration interface of the device adaptation layer, the general interrupt handling function preset by the service middleware layer is registered to the device handle. This callback function is a platform-independent bridge function that does not contain any hardware operation logic. It only retrieves the previously bound context pointer from the device handle through the device binding interface and then calls the event handling function inside the service instance. For example, when a UART receive interrupt is triggered, the callback function obtains a pointer to the serial port service instance from the device handle and then calls its internal uart_on_rx_data() function to complete the data stack push and message queue delivery. The entire process does not depend on the interrupt handling function signature or context structure of any specific RTOS, achieving the technical effects of portable callback logic and traceable context access.

[0089] As an optional example, the above-described creation of concurrency and scheduling resources compatible with the target operating system of the embedded device through the kernel object adaptation layer includes: based on the service running parameters, calling at least one of the thread creation interface, message queue creation interface, mutex creation interface, and delay interface provided by the kernel object adaptation layer to dynamically allocate independent concurrency and scheduling resources for the target service instance; wherein, the concurrency and scheduling resources include dedicated service threads, message queues for asynchronous event notification, mutexes for protecting shared data, and software timers for polling or timed scheduling.

[0090] In this embodiment, the service runtime parameters are derived from the compile-time configuration trimming module. For example, in the configuration tool, the developer specifies that the serial port service is enabled, the thread priority is 5, the stack size is 2KB, and the receive message queue depth is 16. These parameters are not hard-coded in the code, but are recognized by the compiler as structure data and injected into the service instance's initialization process. This parameter set determines which kernel resources need to be created subsequently. For example, if asynchronous receiving is configured, a message queue and a dedicated thread must be created; if polling mode is configured, no thread needs to be created, but a software timer needs to be enabled to periodically trigger polling checks.

[0091] The calls to the aforementioned kernel object adaptation layer are platform-independent. Taking the thread creation interface as an example, in RT-Thread systems, `os_thread_create()` in OSAL maps to `rt_thread_create()`; in FreeRTOS, it maps to `xTaskCreate()`; and in bare-metal systems, this interface might be rewritten as a static task function, scheduled for execution by the main loop according to priority. Its external interface is completely consistent, but its internal implementation varies depending on the platform. Similarly, message queues are kernel-level FIFO structures in RTOS, while in bare-metal systems they can be simulated using a circular buffer + flags + polling mechanism; the service layer does not need to be aware of the differences.

[0092] The aforementioned mutexes can be used, but are not limited to, to ensure the consistency of service states. When the application layer simultaneously calls read and write services, if the underlying buffer is shared, locking is required to prevent concurrent conflicts. OSAL's `os_mutex_create()` corresponds to a semaphore or mutex in an RTOS, and in bare metal, it can be replaced with critical section protection that disables interrupts, or by using atomic operation flags. This encapsulation allows the service layer code to be unconcerned about whether global interrupts are disabled.

[0093] The aforementioned software timer is used for non-interrupt-driven scheduling. In systems without an RTOS or with limited resources, if a service needs to periodically poll the sensor status, OSAL will register a timer callback, which will then schedule the corresponding service's poll() function to execute, thereby simulating the effect of a timed task and achieving semantics completely consistent with RTOS timers.

[0094] Based on the above analysis, it can be seen that configuration parameters determine requirements, OSAL automatically selects the most suitable underlying implementation based on the platform, threads are created for long-term execution, queues are created for event propagation, mutexes are created for data protection, and timers are created for periodic scheduling. These resources are completed once during service instantiation and bound to the context of the device service. The overall execution process is driven by system configuration, customizing a concurrent and scheduling execution environment compatible with its runtime environment for each enabled service instance, thereby achieving the goal of reusing services that can run on multiple platforms after being written once. The entire process does not require application layer intervention, shielding operating system differences and improving the efficiency of embedded service reuse and migration.

[0095] As an optional example, in response to an asynchronous event generated by the underlying physical peripheral, the above-described method, based on the target service instance, obtains the raw hardware data generated by the underlying physical peripheral and parses the raw hardware data into a service data packet corresponding to the device service and having business semantics. This includes: in an interrupt context, writing the raw hardware data carried by the asynchronous event into the circular buffer memory space of the target service instance through a callback function registered by the device adaptation layer; sending an event notification message to the message queue associated with the target service instance through the kernel object adaptation layer, so that the dedicated service thread of the target service instance is awakened by the operating system and enters the business processing state; and parsing the raw hardware data into the service data packet through the dedicated service thread.

[0096] like Figure 6 As shown in step S3, the core of the hardware physical event capture stage is to ensure fast entry and exit of interrupts and to achieve safe switching between physical context and thread context. The detailed processing is as follows: steps S31~S32.

[0097] S31, hardware interrupt level data push onto the stack.

[0098] Hardware interrupts can also be understood as physical interrupts, which are mainly triggered by external sensors sending data, thus activating the underlying chip's UART receive interrupt.

[0099] When an asynchronous event occurs in the underlying physical peripheral (such as a serial port receive interrupt), the DAL callback function that is being taken over is triggered in the interrupt context. To ensure high real-time performance, the callback function does not perform any business parsing, but simply writes the received raw data (such as a single byte) directly into the receive ring buffer created in step S22 of the above embodiment.

[0100] S32 asynchronous message delivery across contexts.

[0101] After the data is pushed onto the stack, the callback function immediately calls the OSAL message queue sending interface (such as mq_send) to send a wake-up event packet containing information such as the data length to the current service's receive message queue. Then, it immediately exits the interrupt service routine, returning control to the operating system's task scheduler.

[0102] The asynchronous event response and business semantic conversion mechanism in this embodiment is the core of achieving decoupling between underlying hardware fragmentation and upper-layer service unification. It mainly transforms the originally chaotic, real-time-critical, and platform-variable hardware interrupt behaviors into stable and semantically clear service data packets through three stages: rapid interrupt response, asynchronous event delivery, and thread-safe resolution. This allows the application layer to obtain complete business information simply by calling standardized interfaces, without needing to concern itself with underlying bus protocols, voltage levels, or DMA interrupt timing.

[0103] Specifically, minimal data capture is performed within the interrupt context. When an interrupt occurs from the underlying physical peripheral, the system triggers the underlying callback function registered by the device adaptation layer during initialization. This callback function does not perform protocol parsing, verify frame headers and trailers, allocate memory, or invoke any potentially blocking operations. It simply writes the byte of data sequentially into a ring buffer dedicated to the service instance. For example, a temperature and humidity sensor sends a 12-byte data packet via RS485. An interrupt is triggered every time a byte is received, but only that byte is pushed into the buffer each time, ensuring that system real-time performance is not affected. This design avoids response delays or priority inversions caused by handling complex logic within the interrupt.

[0104] Context-safe switching is achieved through message queues. After data is pushed into the circular buffer, the callback function immediately calls the `os_mq_send()` interface of the kernel object adapter layer to deliver a lightweight event packet to the message queue bound to the service. This event packet only contains the event type (e.g., "new data has arrived") and the data length, without carrying the original data itself. This operation is atomic, non-blocking, and can be safely executed in all RTOS and bare-metal scheduling models. After successful event delivery, the interrupt service routine immediately exits, and CPU (Central Processing Unit) control is returned to the operating system scheduler. At this time, the operating system detects that there are pending events in the message queue. If the dedicated thread for the service is in a suspended waiting state, it is immediately set to the ready state, completing a smooth transition from interrupt context to task context and avoiding the system risks caused by prolonged execution during interrupts.

[0105] Semantic reconstruction is performed in a dedicated task thread. The awakened service thread runs in a secure scheduling environment. It reads all received raw bytes in batches from the circular buffer and performs complex operations such as frame positioning, header and footer verification, and data decoding according to predefined service protocols (such as Modbus RTU or custom frame formats), ultimately assembling a semantically complete and clear service data packet. This data packet is no longer related to hardware details such as UART, DMA, and interrupt flags, but rather represents service data from sensor readings at the application layer. Subsequently, this data packet can be directly invoked by upper-layer applications through a service abstraction interface.

[0106] The above process ensures system real-time performance while isolating hardware complexity, so that the application layer no longer deals with a string of bytes or an interrupt flag, but with structured data with clear business meaning.

[0107] As an optional implementation, the above-mentioned process of parsing the raw hardware data into the service data packet through the dedicated service thread includes: reading the raw hardware data from the circular buffer memory space; performing frame parsing, verification, and semantic recognition on the raw hardware data according to a preset business protocol to obtain the service data packet with business semantics; and outputting the service data packet to the application layer by calling the standardized business interface of the target service instance, so as to realize the conversion from the underlying hardware event to the upper-layer business semantics.

[0108] like Figure 6 As shown in step S4, the core of the business semantic conversion and output stage is to shield the fragmented characteristics of the underlying hardware devices and provide a business data interface with a unified format to the upper layer. The detailed processing is as follows: steps S41~S42.

[0109] S41, dedicated thread or special thread wake-up and semantic reorganization.

[0110] The dedicated service thread suspended on the receive message queue is awakened by the OS (operating system) upon receiving the aforementioned wake-up event packet. Within a secure task context, this thread extracts raw hardware data (i.e., fragmented data) in batches from the receive circular buffer and assembles and parses the fragmented data into one or more data packets with clearly defined business semantics according to embedded business protocols (such as frame header / tail checksums, CRC checks, etc.).

[0111] S42, standardized business interface call.

[0112] When upper-layer applications need to obtain data or issue control commands, they do not need to directly access the underlying hardware or system queues. Instead, they call standardized interfaces such as read, write, or control through a unified set of standard operations abstracted in the service instance. The service middleware layer handles mutex locks internally within the interfaces to ensure thread safety during concurrent multi-task calls.

[0113] In this embodiment, raw hardware data is first read from the circular buffer memory space. This action occurs within the service thread's context, not the interrupt context. The aforementioned hardware interrupt only pushes data onto the stack, avoiding time-consuming operations within the interrupt. The service thread, after being awakened, reads the raw hardware data from the circular buffer in batches in a safe, non-preemptive manner. For example, for a serial port service, the underlying layer might receive 12 bytes of sensor data within 10 milliseconds, with each byte written sequentially to the circular buffer by an interrupt. The service thread does not process data byte by byte; instead, it reads all the valid data in the buffer at once, forming a continuous block of raw data, ensuring data integrity and improving processing efficiency.

[0114] Secondly, frame parsing, verification, and semantic recognition are performed according to a pre-defined business protocol. This protocol can be, but is not limited to, being fixed by the service instance during the initialization phase. It may include a start symbol, address field, function code, data field, CRC checksum, and end symbol. After reading the raw data, the service thread will search for frame boundaries, verify and check the data, and remove noise bytes according to the protocol specifications to identify whether the currently read data represents a temperature value or a successful command response. This process masks hardware differences; regardless of whether the underlying layer uses STM32's UART interrupt or bare-metal polling sampling, as long as the raw bytes conform to the protocol, the upper layer obtains consistent business semantics. In other words, the application layer does not need to be aware of voltage level polarity or the interrupt triggering method.

[0115] By outputting service data packets to the application layer through standardized business interfaces, a unified access paradigm is achieved. Regardless of whether the service is serial communication, key detection, or vibration alert, the application layer only needs to call the unified `service_read()` or `service_control()` interface, without needing to distinguish whether the underlying layer is an I2C sensor or a GPIO button. For example, when the application layer calls `serv_uart_read(buffer)`, the middleware layer internally performs protocol reassembly, copies the parsed complete data packet to the target buffer, and returns a success status code.

[0116] As an optional example, the above-mentioned generation of a static instance description file based on a pre-configured system configuration file includes: dynamically selecting matching device adaptation layer implementation code and kernel object adaptation layer implementation code based on the target hardware platform and the target operating system, and adding the device adaptation layer implementation code and the kernel object adaptation layer implementation code to the compilation dependency chain; generating a system configuration header file containing compile-time enabling macros based on the device service to be enabled and the service running parameters, wherein the compile-time enabling macros are used to control the conditional compilation of the business functions, sub-service capabilities and service running parameters of the device service; and traversing the enabled service items to automatically generate the static instance description file, wherein the static instance description file is a structured data table.

[0117] In this embodiment, the system configuration file is determined based on the results of manual selections (such as checkmarks) made by developers in the configuration tool. Specifically, developers visualize the selection of system capabilities using configuration tools (such as Kconfig menu configuration tool or other graphical configuration interfaces). The configuration tool captures the user's selection status for the target hardware platform (such as specifying a specific chip model), target operating system, and target services to be enabled (such as serial port service, button service), and saves it as a structured system configuration file.

[0118] Developers enable the serial port service and set the required parameters for the uart_service_cfg_t structure, such as setting the receive buffer size to 1024 bytes, the receive message queue depth to 16, and setting the priority of the dedicated thread.

[0119] The above method allows for the pre-determining of which service modules of the device service will be applied to a specified hardware platform. By configuring a pruning mechanism, service modules, sub-service capabilities, and parameters can be configured at compile time to achieve the goal of on-demand loading.

[0120] The above configuration pruning mechanism can be implemented through, but is not limited to, the configuration pruning module, including but not limited to, the configuration of the service master switch, sub-service enablement, device, reference level, input / output mode, thread priority, thread stack size, service polling cycle, buffer size, device category capability start, and service behavior parameters (which can also be understood as business behavior parameters).

[0121] The aforementioned generation of a system configuration header file containing compile-time enable macros, based on the device services to be enabled and their runtime parameters, is the core of achieving granular feature tailoring. For example, if the user only enables the button service and sets the long-press timeout to 2 seconds and the debouncing time to 10ms, the system build will generate `system_config.h`, which includes macro definitions such as `#define ENABLE_KEY_SERVICE1`, `#define KEY_LONG_PRESS_MS2000`, and `#define KEY_DEBOUNCE_MS10`. In the service source code, services that are not enabled are removed by the preprocessor, do not participate in compilation or linking, and do not occupy any memory. This static tailoring is superior to runtime on / off switching, avoiding the overhead of useless functions, variables, queues, and threads, and is suitable for medical embedded devices with extremely limited resources.

[0122] The above traversal of enabled services automatically generates a static instance description file (which can also be understood as a static service instance description table or static instance description table), forming the basis for seamless runtime initialization. This file is typically a global structure array. It is automatically generated by a Python script at compile time and records information such as the name of each enabled service, the bound physical device, and the service operation set pointer. After system power-on, the main initialization function only needs to traverse this table and call the unified `service_init()` function to automatically complete the entire initialization process, including device lookup, resource creation, and callback binding. This eliminates the need for developers to manually write redundant call code such as `serv_key_init()` and `serv_uart_init()`, improving system maintainability and scalability.

[0123] To more clearly understand the processing procedures of the configuration, compilation, and runtime phases described in the above embodiments, the following will combine... Figure 4 The configuration-compile-run three-stage architecture diagram shown below provides a further description of it.

[0124] S402, Configuration Description File.

[0125] During compilation, this includes, but is not limited to, configuring service module enablement, pins, OS type, hardware platform platform type, service instance buffers, and thread priorities.

[0126] In other words, during compilation, the target hardware platform is declared through the system configuration file, and the system automatically completes various adaptation configurations.

[0127] S404 generates a system configuration file by using a configuration tool or equivalent configurator to check the developer's selection status for the target hardware platform, operating system, and target device services that need to be enabled.

[0128] In terms of the trimming mechanism, S406 generates a global configuration macro header file based on configuration parameters; during the compilation process, by identifying the conditional compilation instructions embedded in the code, it directly extracts the unused service module code and related dependencies in the preprocessing stage, thereby achieving firmware size trimming.

[0129] S408, during the compilation preprocessing stage, automatically generates a static service instance description table by constructing a pre-built text processing script for system calls, traversing the aforementioned enabled service modules.

[0130] S410, after the trimming process in step S406 above, the trimmed target firmware is obtained.

[0131] S412, entering the system startup phase.

[0132] S414 executes the following sequentially during runtime: dynamic instantiation of static configuration files, binding service instances to underlying physical peripherals, interrupt callback takeover, and service registration.

[0133] For details, please refer to the description of step S2 in the above embodiments, which will not be repeated here.

[0134] S416, the application layer calls the unified service interface and applies the service data package after business semantic transformation to the target hardware platform.

[0135] As can be seen from the description of the above embodiments, the technical solutions of this application can be applied, but are not limited to, to the rapid construction, migration and reuse of embedded device services in different hardware platforms, different real-time operating systems or bare-metal environments.

[0136] The following is combined with Figure 5 The software migration process shown further describes the processing method for the aforementioned embedded device services.

[0137] S502, the target hardware platform has changed, mainly including changes in OS, MCU or BSP.

[0138] S504, Modify Configuration Description File, can also be understood as replacing the current system configuration file that matches the current hardware platform with the target system configuration file that matches the target hardware platform.

[0139] S506, replace the OS adapter and the device adapter.

[0140] That is, based on the replaced target system configuration file, a device adaptation layer and a kernel object adaptation layer that match the target hardware platform and the target operating system are built.

[0141] S508 uses a device adaptation layer to shield the differences in access between devices on different operating systems, and a kernel object adaptation layer to shield the differences between kernel objects on different operating systems, while keeping the service layer business logic (i.e., service logic) unchanged.

[0142] S510 obtains service data packets by instantiating and binding static configurations and resources, capturing asynchronous events, and converting business semantics based on the dual adaptation layers in the service middleware, and then recompiles them.

[0143] The migration can be completed by generating target platform firmware corresponding to the target hardware platform using S512.

[0144] As can be seen, the technical solution of this application performs the following processes in sequence: a service intermediate layer is established above the device driver layer; a device adaptation layer is established to shield the differences in device access across different operating systems; a kernel object adaptation layer is established to shield the differences in kernel objects across different operating systems; service modules, sub-service capabilities, and runtime parameters are selected and configured through a configuration system; service enable macros, parameter macros, and conditional compilation paths are generated during compilation based on the configuration results; various service instances are constructed based on a unified service abstract base class; during the service initialization phase, the underlying device is located and the association between service objects and device objects is established; the underlying device callbacks are mapped to the service object context; asynchronous events are processed through message queues, circular buffers, threads, timed scheduling, or polling mechanisms; and the underlying device events are converted into a unified service semantic interface for the application layer for output.

[0145] The overall solution described above includes at least a configuration trimming module, a device adaptation layer, a kernel object adaptation layer, a service abstract base class, a service instance construction module, and an asynchronous event scheduling module. The descriptions of the configuration trimming module, device adaptation layer, and kernel object adaptation layer can be found in the embodiments described above.

[0146] The service abstract base class is mainly used to define the service lifecycle and unified access semantics, including but not limited to initialization interface, configuration interface, start interface, stop interface, status read interface, status write interface, reset interface, and destruction interface.

[0147] The service instance building module mainly constructs service instances based on configuration parameters and service types, and completes parameter solidification, device binding, resource creation, callback access, default state establishment, and operation strategy selection.

[0148] The asynchronous event scheduling module mainly transforms underlying asynchronous events into a service-layer manageable event stream, including interrupt or callback reporting, data caching, message queue delivery, service thread processing, polling service processing, event priority scheduling, state machine driving, etc.

[0149] Compared with traditional solutions, the technical solution of this application has at least the following advantages:

[0150] (1) A service middleware layer is further established on top of the driver layer: Compared with the traditional solution that only reuses the driver layer, the technical solution of this application can reuse higher-level business service logic, reducing redundant development.

[0151] (2) Cross-platform operation through dual adaptation layers: By using the device adaptation layer and the kernel object adaptation layer, the service logic is decoupled from the specific operating system and device model, and migration across real-time operating systems or bare-metal environments is realized.

[0152] (3) Reduce resource consumption through compile-time trimming: Service modules, sub-capabilities and parameters are fixed during compile-time, reducing invalid code paths, reducing RAM / ROM consumption, and shortening the initialization path.

[0153] (4) Achieve unified conversion of underlying asynchronous events to service semantics: unify the conversion of interrupts, DMA completion, plug-in / plug-out events, and receive events into manageable service events, thereby reducing the complexity of the application layer.

[0154] (5) Support multiple underlying implementations of the same business semantics: For example, vibration service, status light service, button service, etc. can maintain a unified interface under different hardware implementations.

[0155] (6) Unified service lifecycle and construction rules: enable different service modules to have consistent initialization, configuration, start, stop, read, write, reset and destruction logic, which facilitates expansion and maintenance.

[0156] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0157] According to another aspect of the embodiments of this application, as follows is also provided Figure 7An embedded device service processing apparatus is shown, comprising: a first processing unit 702, configured to generate a static instance description file based on a pre-configured system configuration file during the compilation phase, wherein the static instance description file includes the service type of the device service to be enabled on the target hardware platform, the device name of the bound underlying physical peripheral, and service running parameters; a creation unit 704, configured to create a target service instance for each service type of the device service based on the static instance description file, and dynamically bind the target service instance to the underlying physical peripheral of the embedded device through a device adaptation layer, and create concurrency and scheduling resources compatible with the target operating system of the embedded device through a kernel object adaptation layer; a first acquisition unit 706, configured to acquire the raw hardware data generated by the underlying physical peripheral based on the target service instance in response to an asynchronous event generated by the underlying physical peripheral, and parse the raw hardware data into a service data packet corresponding to the device service and having business semantics; and a second processing unit 708, configured to acquire the service data packet through a standardized service interface in response to a data acquisition instruction from the application layer, and run the device service on the target hardware platform.

[0158] Optionally, the creation unit 704 includes: a first processing module, used to generate an initialization service instance based on the static instance description file, wherein the initialization service instance; a first matching module, used to match the interrupt handling function pointer corresponding to the device name from the underlying driver list and pointing to the underlying device driver layer; a first allocation module, used to read buffer information from the system configuration file and dynamically allocate a circular buffer memory space for the initialization service instance according to the buffer size; a second creation module, used to read thread parameters from the system configuration file and create a dedicated service thread with independent scheduling attributes according to the thread priority and thread stack size, wherein the thread parameters include the thread priority and the thread stack size; and an encapsulation module, used to encapsulate the interrupt handling function pointer, the circular buffer memory space, and the dedicated service thread to obtain the encapsulated target service instance.

[0159] Optionally, the above encapsulation module includes: a replacement submodule, used to replace the interrupt handling function pointer with a custom context function of the service intermediate layer through the callback setting interface of the device adaptation layer, wherein the service intermediate layer includes the device adaptation layer and the kernel object adaptation layer, the device adaptation layer is used to shield the interface differences of device access from different operating systems, and the kernel object adaptation layer is used to shield the concurrency and scheduling mechanisms of different operating systems; and an encapsulation submodule, used to encapsulate the custom context function, the circular buffer memory space, and the dedicated service thread to obtain the target service instance.

[0160] Optionally, the creation unit 704 includes: a second processing module, configured to, based on the device name, call the device lookup interface provided by the device adaptation layer to obtain the device handle of the underlying physical peripheral that matches the device name; an association module, configured to, by calling the device binding interface provided by the device adaptation layer, associate the context pointer of the target service instance with the device handle; and a third processing module, configured to, by calling the callback registration interface provided by the device adaptation layer, register the callback function for handling asynchronous events of the underlying physical peripheral to the device handle, and enable the callback function to access the local resources of the target service instance through the context pointer in the interrupt context.

[0161] Optionally, the creation unit 704 further includes: a calling module, configured to, based on the service running parameters, call at least one of the thread creation interface, message queue creation interface, mutex creation interface, and delay interface provided by the kernel object adaptation layer to dynamically allocate independent concurrency and scheduling resources for the target service instance; wherein the concurrency and scheduling resources include dedicated service threads, message queues for asynchronous event notifications, mutexes for protecting shared data, and software timers for polling or timed scheduling.

[0162] Optionally, the first acquisition unit 706 includes: a writing module, configured to write the original hardware data carried by the asynchronous event into the circular buffer memory space of the target service instance through a callback function registered by the device adaptation layer in an interrupt context; a sending module, configured to send an event notification message to the message queue associated with the target service instance through the kernel object adaptation layer, so that the dedicated service thread of the target service instance is awakened by the operating system and enters the business processing state; and a parsing module, configured to parse the original hardware data into the service data packet through the dedicated service thread.

[0163] Optionally, the above-mentioned parsing module includes: a reading submodule, used to read the original hardware data from the circular buffer memory space; a parsing submodule, used to perform frame parsing, verification and semantic recognition on the original hardware data according to a preset business protocol to obtain the service data packet with business semantics; and an output submodule, used to output the service data packet to the application layer by calling the standardized business interface of the target service instance, so as to realize the conversion from the underlying hardware event to the upper layer business semantics.

[0164] Optionally, the first processing unit 702 includes: a fourth processing module, configured to dynamically select matching device adaptation layer implementation code and kernel object adaptation layer implementation code based on the target hardware platform and the target operating system, and add the device adaptation layer implementation code and the kernel object adaptation layer implementation code to the compilation dependency chain; a fifth processing module, configured to generate a system configuration header file containing compile-time enabling macros based on the device service to be enabled and the service running parameters, wherein the compile-time enabling macros are used to control the conditional compilation of the business functions, sub-service capabilities and service running parameters of the device service; and a sixth processing module, configured to traverse the enabled service items and automatically generate the static instance description file, wherein the static instance description file is a structured data table.

[0165] It should be noted that the embodiments of the audio and video stream processing device here can refer to the embodiments of the embedded device service processing method described above, and will not be repeated here.

[0166] According to another aspect of the embodiments of this application, an electronic device for implementing the above-described embedded device service processing method is also provided. This electronic device may be... Figure 1 The target terminal or server is shown. This embodiment uses the electronic device as an example to illustrate the concept. Figure 8 As shown, the electronic device includes a memory 802 and a processor 804. The memory 802 stores a computer program, and the processor 804 is configured to execute the steps in any of the above method embodiments via the computer program.

[0167] Optionally, the aforementioned electronic device may be located in at least one of a plurality of network devices of the computer.

[0168] Optionally, the processor described above can be configured to perform the following steps via a computer program:

[0169] S1. During the compilation phase, a static instance description file is generated based on the pre-configured system configuration file. The static instance description file includes the service type of the device service to be enabled on the target hardware platform, the device name of the underlying physical peripheral device to be bound, and the service operation parameters.

[0170] S2, based on the static instance description file, create a target service instance for each service type of the device service, and dynamically bind the target service instance to the underlying physical peripheral of the embedded device through the device adaptation layer, and create concurrency and scheduling resources compatible with the target operating system of the embedded device through the kernel object adaptation layer.

[0171] S3, in response to the asynchronous event generated by the underlying physical peripheral, based on the target service instance, obtain the raw hardware data generated by the underlying physical peripheral, and parse the raw hardware data into a service data packet that corresponds to the device service and has business semantics.

[0172] S4, in response to the data acquisition command of the application layer, obtain the service data packet through the standardized service interface, and run the device service on the target hardware platform.

[0173] Alternatively, as those skilled in the art will understand, Figure 8 The structure shown is for illustrative purposes only. Figure 8 This does not limit the structure of the aforementioned electronic devices or electronic equipment. For example, electronic devices or electronic equipment may also include components that are more... Figure 8 The more or fewer components shown (such as network interfaces, etc.), or having the same Figure 8 The different configurations shown.

[0174] The memory 802 can be used to store software programs and modules, such as the program instructions / modules corresponding to the embedded device service processing method and apparatus in this embodiment. The processor 804 executes various functional applications and data processing by running the software programs and modules stored in the memory 802, thereby implementing the aforementioned embedded device service processing method. The memory 802 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 802 may further include memory remotely located relative to the processor 804, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, enterprise intranets, local area networks, mobile communication networks, and combinations thereof. Specifically, the memory 802 may be used, but is not limited to, to store static instance description files, service running parameters, and concurrency and scheduling resources. As an example, such as... Figure 8 As shown, the memory 802 may include, but is not limited to, the first processing unit 702, the creation unit 704, the first acquisition unit 706, and the second processing unit 708 in the processing device for the embedded device service. Furthermore, it may include, but is not limited to, other module units in the processing device for the embedded device service, which will not be elaborated upon in this example.

[0175] Optionally, the transmission device 806 described above is used to receive or send data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 806 includes a Network Interface Controller (NIC), which can be connected to other network devices and a router via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 806 is a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0176] In addition, the aforementioned electronic device also includes: a display 808 for displaying an interface for developers to select target hardware platforms and service modules; and a connection bus 810 for connecting various module components in the aforementioned electronic device.

[0177] In other embodiments, the target terminal or server described above can be a node in a distributed system. This distributed system can be a blockchain system, formed by connecting multiple nodes through network communication. The nodes can form a point-to-point network, and any type of computing device, such as a server or target terminal, can become a node in the blockchain system by joining this point-to-point network.

[0178] According to another aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the processing method of the embedded device service provided in various optional implementations of the above-described server verification processing, wherein the computer program is configured to execute the steps in any of the above-described method embodiments at runtime.

[0179] Optionally, in this embodiment, the computer-readable storage medium described above may be configured to store a computer program for performing the following steps:

[0180] S1. During the compilation phase, a static instance description file is generated based on the pre-configured system configuration file. The static instance description file includes the service type of the device service to be enabled on the target hardware platform, the device name of the underlying physical peripheral device to be bound, and the service operation parameters.

[0181] S2, based on the static instance description file, create a target service instance for each service type of the device service, and dynamically bind the target service instance to the underlying physical peripheral of the embedded device through the device adaptation layer, and create concurrency and scheduling resources compatible with the target operating system of the embedded device through the kernel object adaptation layer.

[0182] S3, in response to the asynchronous event generated by the underlying physical peripheral, based on the target service instance, obtain the raw hardware data generated by the underlying physical peripheral, and parse the raw hardware data into a service data packet that corresponds to the device service and has business semantics.

[0183] S4, in response to the data acquisition command of the application layer, obtain the service data packet through the standardized service interface, and run the device service on the target hardware platform.

[0184] Optionally, in embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0185] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the target terminal. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0186] The sequence numbers of the embodiments in this application are merely for description and do not represent the superiority or inferiority of the embodiments. If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods in the various embodiments of this application.

[0187] In the above embodiments of this application, the descriptions of each embodiment have their own emphasis. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. It should be understood that the disclosed client can be implemented in other ways in the several embodiments provided in this application. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0188] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the various embodiments of this application 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 units described above can be implemented in hardware or as software functional units.

[0189] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for processing embedded device services, characterized in that, include: During the compilation phase, a static instance description file is generated based on the pre-configured system configuration file. The static instance description file includes the service type of the device service to be enabled on the target hardware platform, the device name of the underlying physical peripheral to be bound, and the service operation parameters. Based on the static instance description file, a target service instance is created for each service type of the device service, and the target service instance is dynamically bound to the underlying physical peripheral of the embedded device through the device adaptation layer. Concurrency and scheduling resources compatible with the target operating system of the embedded device are created through the kernel object adaptation layer. In response to the asynchronous event generated by the underlying physical peripheral, based on the target service instance, the raw hardware data generated by the underlying physical peripheral is obtained, and the raw hardware data is parsed into a service data packet that corresponds to the device service and has business semantics; In response to the data acquisition command from the application layer, the service data packet is obtained through a standardized service interface, and the device service is run on the target hardware platform.

2. The method according to claim 1, characterized in that, The step of creating a target service instance for each service type of the device service based on the static instance description file includes: Based on the static instance description file, an initialization service instance is generated, wherein the initialization service instance; Based on the device name, match the corresponding interrupt handling function pointer from the underlying driver list that points to the underlying device driver layer; Read buffer information from the system configuration file and dynamically allocate a circular buffer memory space for the initialization service instance based on the buffer size; Thread parameters are read from the system configuration file, and a dedicated service thread with independent scheduling attributes is created based on the thread priority and the thread stack size. The thread parameters include the thread priority and the thread stack size. The interrupt handling function pointer, the circular buffer memory space, and the dedicated service thread are encapsulated to obtain the encapsulated target service instance.

3. The method according to claim 2, characterized in that, The process of encapsulating the interrupt handler function pointer, the circular buffer memory space, and the dedicated service thread to obtain the encapsulated target service instance includes: By using the callback setting interface of the device adaptation layer, the interrupt handling function pointer is replaced with a custom context function of the service middleware layer. The service middleware layer includes the device adaptation layer and the kernel object adaptation layer. The device adaptation layer is used to shield the interface differences of device access for different operating systems, and the kernel object adaptation layer is used to shield the concurrency and scheduling mechanisms of different operating systems. The custom context function, the circular buffer memory space, and the dedicated service thread are encapsulated to obtain the target service instance.

4. The method according to claim 1, characterized in that, The dynamic binding of the target service instance to the underlying physical peripheral of the embedded device through the device adaptation layer includes: Based on the device name, the device lookup interface provided by the device adaptation layer is invoked to obtain the device handle of the underlying physical peripheral that matches the device name; By calling the device binding interface provided by the device adaptation layer, the context pointer of the target service instance is associated with the device handle; By calling the callback registration interface provided by the device adaptation layer, the callback function used to handle the asynchronous events of the underlying physical peripheral is registered to the device handle, and the callback function accesses the local resources of the target service instance through the context pointer in the interrupt context.

5. The method according to claim 1, characterized in that, The creation of concurrent and scheduling resources compatible with the target operating system of the embedded device through the kernel object adaptation layer includes: Based on the service running parameters, at least one of the thread creation interface, message queue creation interface, mutex creation interface, and delay interface provided by the kernel object adaptation layer is invoked to dynamically allocate independent concurrency and scheduling resources for the target service instance; The concurrency and scheduling resources include dedicated service threads, message queues for asynchronous event notifications, mutexes for protecting shared data, and software timers for polling or timed scheduling.

6. The method according to claim 1, characterized in that, In response to the asynchronous event generated by the underlying physical peripheral, based on the target service instance, the raw hardware data generated by the underlying physical peripheral is obtained, and the raw hardware data is parsed into a service data packet corresponding to the device service and having business semantics, including: In the interrupt context, the original hardware data carried by the asynchronous event is written into the circular buffer memory space of the target service instance through the callback function registered by the device adaptation layer; Through the kernel object adaptation layer, an event notification message is sent to the message queue associated with the target service instance, so that the dedicated service thread of the target service instance is awakened by the operating system and enters the business processing state. The dedicated service thread parses the raw hardware data into the service data packet.

7. The method according to claim 6, characterized in that, The process of parsing the raw hardware data into the service data packet via the dedicated service thread includes: Read the raw hardware data from the circular buffer memory space; According to the preset business protocol, the original hardware data is subjected to frame parsing, verification and semantic recognition to obtain the service data packet with business semantics; By calling the standardized business interface of the target service instance, the service data packet is output to the application layer to realize the conversion from the underlying hardware event to the upper-layer business semantics.

8. The method according to any one of claims 1 to 7, characterized in that, The generation of static instance description files based on pre-configured system configuration files includes: Based on the target hardware platform and the target operating system, dynamically select matching device adaptation layer implementation code and kernel object adaptation layer implementation code, and add the device adaptation layer implementation code and the kernel object adaptation layer implementation code to the compilation dependency chain; Based on the device service to be enabled and the service operation parameters, a system configuration header file containing compile-time enable macros is generated, wherein the compile-time enable macros are used to control the business functions, sub-service capabilities and conditional compilation of the service operation parameters of the device service; The enabled services are traversed, and the static instance description file is automatically generated, wherein the static instance description file is a structured data table.

9. A processing apparatus for embedded device services, characterized in that, include: The first processing unit is used to generate a static instance description file based on a pre-configured system configuration file during the compilation phase. The static instance description file includes the service type of the device service to be enabled on the target hardware platform, the device name of the underlying physical peripheral device to be bound, and the service operation parameters. The creation unit is used to create a target service instance for each service type of the device service based on the static instance description file, and dynamically bind the target service instance to the underlying physical peripheral of the embedded device through the device adaptation layer, and create concurrent and scheduling resources compatible with the target operating system of the embedded device through the kernel object adaptation layer. The first acquisition unit is used to respond to the asynchronous event generated by the underlying physical peripheral device, acquire the original hardware data generated by the underlying physical peripheral device based on the target service instance, and parse the original hardware data into a service data packet that corresponds to the device service and has business semantics. The second processing unit is used to respond to the data acquisition command of the application layer, acquire the service data packet through the standardized service interface, and run the device service on the target hardware platform.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program can be executed by a terminal device or computer at runtime as described in any one of claims 1 to 8.

11. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to perform the method as described in any one of claims 1 to 8 through the computer program.

Images