Unified Driver Configuration Across Lightweight and Fullweight Platforms
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing driver configuration management systems for IoT devices with limited hardware resources face challenges in code architecture corruption, reduced maintainability, and increased reuse difficulty due to direct code modification for adapting to new platforms, which is not addressed by current frameworks like Device Tree Source (DTS) and Advanced Configuration and Power Interface (ACPI).
Innovation Solution
A unified configuration description syntax is used to generate configuration files in different formats (C language for lightweight devices and binary for fullweight devices) to decouple hardware-related configuration from driver implementation, ensuring high performance and flexibility across platforms.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If hardware-related configuration code is directly written in driver implementation code by using macro or constant, then the driver can be adapted to specific hardware platforms, but code architecture becomes corrupted and maintainability is reduced
Solution Approach 1:
The patent segments the driver code into two distinct parts: hardware-agnostic service function code and hardware-specific configuration code. This is achieved by introducing a separate configuration file format that stores hardware-related parameters (such as register addresses, interrupt numbers, memory mappings) independently from the driver implementation code. The configuration file uses a structured format with keys and values that can be parsed and applied to different hardware platforms without modifying the core driver logic.
Solution Approach 2:
The patent extracts hardware-related configuration code from the driver implementation code and places it into separate configuration files. These configuration files contain all hardware-specific parameters in a standardized format, allowing the driver to be configured for different platforms by simply changing the configuration file rather than modifying the source code. This extraction resolves the coupling between hardware specifics and driver logic.
2Adaptability or versatility
If driver code is copied and configuration code is modified to adapt to new platforms, then platform-specific requirements are met, but code reuse difficulty increases and maintainability is reduced
Solution Approach 1:
The patent creates a universal configuration file format that can serve multiple hardware platforms. The configuration files use a standardized structure with platform-independent keys and values that can be applied across different device types and architectures. This allows a single driver implementation to support multiple platforms by simply providing appropriate configuration files, eliminating the need for code copying and modification for each platform.
3Reliability
If hardware configuration and function code are coupled in driver implementation code, then the driver can be self-contained, but porting and configuration management become more difficult
Solution Approach 1:
The patent introduces configuration files as an intermediary layer between the hardware specifications and the driver implementation code. These configuration files act as a mediator that translates hardware-specific parameters into a format that the driver can consume. The driver reads configuration parameters from these files at runtime or compilation time, allowing easy porting to new platforms by simply providing new configuration files without changing the driver source code.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A driver configuration management method and apparatus, a medium, and a device are provided and applied to the field of communication technologies, so that driver configuration management can be implemented on limited hardware resources of a lightweight platform, and configuration management can support both the lightweight platform and a fullweight platform. Specifically, the method is applied to a management device (200) and includes: determining target information, where the target information is used to represent a computing capability of an electronic device (100a or 100b); converting, based on the target information, a configuration source file into a target configuration file that uses a target file format; and sending the target configuration file to the electronic device (100a or 100b). The method is specifically applied to a scenario in which the management device (200) generates and sends configuration files in different formats for electronic devices (100a and 100b) having different computing capabilities.