Battery charging and discharging driving framework implementation method based on HDF framework of OH system

Abstract

The invention discloses a battery charge and discharge driving framework implementation method based on an HDF framework of an OH system, and the method comprises the steps: defining a unified battery charge and discharge driving interface based on the HDF framework of the OpenHarmony system; two mechanisms of a battery charging and discharging driving module, a battery user mode driving service compatible kernel mode direct-through HDI and a sysfs file system are realized on a specific hardware platform; a battery management service layer is constructed, and accurate control over battery charging and discharging is achieved by calling a driving interface; based on a dynamic loading mechanism of an HDF framework, dynamic loading and unloading of a battery charging and discharging driving module are supported. According to the battery charging and discharging driving framework based on the OH system HDF framework, modularization, standardization and expandability of battery charging and discharging driving are achieved, the battery user mode driving service is compatible with an HDI mechanism and a sysfs mechanism, and the efficiency and safety of battery management are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of battery charge and discharge management, and in particular to a method for realizing a battery charge and discharge driving framework based on an OH (OpenHarmony) system HDF framework. Background Art

[0002] With the popularization of smart devices and the rapid development of battery technology, the performance and safety requirements of battery management systems are increasing. In the Linux system, the interface provided by `sysfs` can be used to obtain the properties of the battery, such as the files in the ` / sys / class / power_supply / battery / ` directory. These files contain various status information of the battery. By reading these files, the battery power, charging status, temperature and other data can be obtained, and the charging current can be adjusted based on this information. The existing battery charging and discharging driver framework is implemented by accessing the sysfs file system. Its underlying layer depends on the Linux system, which is difficult to expand and update, and lacks battery charging and discharging management. Therefore, it is of great practical application value to design an efficient, stable, easy to maintain and easy to manage battery charging and discharging driver framework that is compatible with both HDI (kernel state pass-through) and sysfs mechanisms. Summary of the invention

[0003] The present application provides a method for implementing a battery charge and discharge driver framework based on an OH system HDF framework, so as to solve the problems that the existing battery charge and discharge driver framework is implemented by accessing the sysfs file system, its underlying layer relies on the Linux system, is difficult to expand and update, and lacks battery charge and discharge management.

[0004] According to the first aspect, an embodiment provides a method for implementing a battery charging and discharging driving framework based on an OH system HDF framework, the method comprising:

[0005] Based on the OpenHarmony system HDF framework, a unified battery charging and discharging driver interface is defined;

[0006] Implement the battery charging and discharging driver module on a specific hardware platform. The battery user-mode driver service is compatible with both kernel-mode direct HDI and sysfs file system mechanisms.

[0007] Build a battery management service layer to achieve precise control of battery charging and discharging by calling the driver interface;

[0008] The dynamic loading mechanism based on the HDF framework supports dynamic loading and unloading of battery charging and discharging driver modules.

[0009] Furthermore, based on the OH system HDF driver framework, a unified battery charging and discharging driver interface is defined, including:

[0010] The basic operations of battery charging and discharging are defined through a unified driver interface, including initialization, charging control, discharging control, and status query.

[0011] Furthermore, based on the OH system HDF driver framework, a unified battery charging and discharging driver interface is defined, including:

[0012] Driver configuration information management: Organize source code in the form of HCS files, configure and record device driver information in the form of Key-Value, and decouple configuration information from driver code;

[0013] Provides a default implementation of the driver model based on the HDI interface, allowing developers to use the default implementation to quickly integrate and test battery-related drivers;

[0014] The interface supports three modes: mini, small and standard. Different modes correspond to different kernel state and user state implementations.

[0015] Furthermore, the battery charging and discharging driver module is implemented on a specific hardware platform. The battery user-mode driver service is compatible with the kernel-mode direct HDI and sysfs file system mechanisms, including:

[0016] Implement the battery charging and discharging driver module on a specific hardware platform, including hardware initialization, data interaction, and exception handling; HDI service release is based on the user-mode HDF driver framework UHDF.

[0017] Furthermore, the constructed battery management service layer specifically includes:

[0018] Driver interface module: The driver interface module is the core of the service layer and is responsible for interacting with the underlying hardware. By calling the driver interface, the service layer can realize battery charge and discharge control, status monitoring and information query. The module should support a normalized HDI interface to facilitate the adaptation of different types of batteries and charging and discharging equipment.

[0019] Status monitoring module: responsible for real-time monitoring of the working status of the battery, including voltage, current, temperature, and charging status parameters; the module has an exception handling mechanism. When an abnormal status is detected, it can trigger an alarm in time and take corresponding measures to ensure the safe operation of the battery;

[0020] Charging management module: responsible for managing the battery charging process, including support for wired charging, wireless charging, and common fast charging protocols; the module can dynamically adjust the charging current and voltage according to different charging methods and protocols to ensure charging efficiency and safety;

[0021] Information query module: provides battery information query and reporting functions. Users can obtain the real-time status, historical data and fault information of the battery through the information query module. At the same time, the module supports data reporting, which is convenient for remote monitoring and management.

[0022] Charge and discharge control mechanism: The battery charge and discharge process is the core function of the battery management service layer, including:

[0023] Charging control: During the charging process, the service layer should dynamically adjust the charging current and voltage according to the battery status and charging protocol;

[0024] Discharge control: During the discharge process, the service layer should ensure that the battery discharges within a safe range to prevent over-discharge.

[0025] Furthermore, the constructed battery management service layer specifically includes:

[0026] Exception handling mechanism, including:

[0027] Abnormal detection: The service layer has real-time abnormal detection capabilities, which can monitor abnormal conditions including overcharging, over-discharging, and over-temperature of the battery, and record abnormal information in a timely manner;

[0028] Alarm mechanism: When an anomaly is detected, the service layer should immediately trigger the alarm mechanism, send an alarm message to the user, and record the details of the abnormal event for subsequent analysis;

[0029] Automatic protection: When an abnormality occurs, the service layer should be able to automatically take protective measures to ensure the safety of the battery.

[0030] Furthermore, the constructed battery management service layer specifically includes:

[0031] Normalized HDI interface support: In order to achieve the adaptation of different batteries and charging and discharging equipment, the service layer should provide a normalized HDI interface, specifically supporting the following functions:

[0032] Battery information query: supports users to query basic battery information, including model, capacity, and health status;

[0033] Status reporting: Supports reporting the real-time status of the battery to the cloud for remote monitoring and management;

[0034] Charge and discharge control: Supports battery charge and discharge control through the HDI interface to ensure flexibility and convenience of operation.

[0035] Furthermore, the battery management service layer is constructed, which specifically includes:

[0036] Lightweight component adaptation: When designing the battery management service layer, the lightweight of the system should be taken into consideration; the adaptation of lightweight components can be achieved by standardizing the mini, small and standard HDI interfaces;

[0037] Component selection: When selecting components, give priority to components with stable performance and low power consumption to ensure efficient operation of the system;

[0038] Resource management: Avoid waste of resources and improve system response speed and processing capacity through reasonable management of system resources.

[0039] Furthermore, the dynamic loading mechanism based on the HDF framework supports dynamic loading and unloading of the battery charging and discharging driver module, including:

[0040] Dynamic loading and static loading support: The HDF framework supports dynamic loading and static loading of driver modules, allowing the driver to be compiled and deployed independently of the framework code, eliminating the direct code dependency between the driver code and the framework;

[0041] On-demand dynamic loading: The HDF framework supports on-demand dynamic loading, which can avoid full loading of device drivers and effectively reduce the occupation of system resources;

[0042] Driver loading mode: HDF framework supports two loading modes, namely on-demand loading and sequential loading. On-demand loading allows the driver to be loaded by default during system startup, or dynamically loaded after the system is started; sequential loading allows the driver to be loaded according to the priority of the driver during system startup.

[0043] Driver service management: The HDF framework can centrally manage driver services. Developers can directly obtain driver-related services through the capability interface provided by the HDF framework.

[0044] Driver message mechanism: The HDF framework provides a unified driver message mechanism that supports user-mode applications to send messages to kernel-mode drivers, and also supports kernel-mode drivers to send messages to user-mode applications.

[0045] Componentized driver model: The HDF framework uses a componentized driver model as its core design idea, providing developers with more refined driver management and making driver development and deployment more standardized.

[0046] According to the second aspect, an embodiment provides a battery charging and discharging driving framework implementation system based on the OH system HDF framework, the system comprising:

[0047] The driver interface definition module is used to define a unified battery charging and discharging driver interface based on the OpenHarmony system HDF framework;

[0048] The driver implementation module is used to implement the battery charging and discharging driver module on a specific hardware platform. The battery user-mode driver service is compatible with both kernel-mode direct HDI and sysfs file system mechanisms.

[0049] The service layer building module is used to build the battery management service layer and realize the precise control of battery charging and discharging by calling the driver interface;

[0050] The loading and unloading module is used for the dynamic loading mechanism based on the HDF framework, supporting the dynamic loading and unloading of the battery charging and discharging driver module.

[0051] The present application provides a method for implementing a battery charge and discharge driver framework based on the OH system HDF framework. Based on the OpenHarmony system HDF framework, a unified battery charge and discharge driver interface is defined; the battery charge and discharge driver module is implemented on a specific hardware platform, and the battery user-state driver service is compatible with the two mechanisms of kernel-state direct pass-through HDI and sysfs file system; a battery management service layer is constructed to achieve precise control of battery charge and discharge by calling the driver interface; based on the dynamic loading mechanism of the HDF framework, dynamic loading and unloading of the battery charge and discharge driver module are supported. The battery charge and discharge driver framework based on the OH system HDF framework proposed in the present application realizes the modularization, standardization and scalability of battery charge and discharge drive. The battery user-state driver service is compatible with the two mechanisms of HDI (kernel-state direct pass-through) and sysfs ( / sys / class / power_supply / Battery), which improves the efficiency and safety of battery management. The framework can be applied to smart devices such as smartphones, tablets, wearable devices, etc. to improve the efficiency and safety of battery management. It has the following beneficial effects:

[0052] 1. Modular design: The battery charging and discharging drive is modularized to improve the maintainability and portability of the system.

[0053] 2. Standardized interface: defines a unified driver interface, reduces the complexity of system integration and improves development efficiency.

[0054] 3. Scalability: Through the dynamic loading mechanism of the HDF framework, it supports the addition of new driver modules to adapt to the upgrade and development of future battery technology.

[0055] 4. Enhanced security: Through the service layer design, real-time monitoring and exception handling of battery status are achieved, improving the safety of battery use.

[0056] 5. The battery user-mode driver service is compatible with the HDI (kernel-mode direct access) calling method. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Figure 1A flowchart of a method for implementing a battery charging and discharging driving framework based on an OH system HDF framework provided by an embodiment of the present invention;

[0058] Figure 2 A schematic diagram of the logical structure of a battery charging and discharging driving framework implementation system based on the OH system HDF framework provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0059] The present invention is further described in detail below by specific embodiments in conjunction with the accompanying drawings. Wherein similar elements in different embodiments adopt associated similar element numbers. In the following embodiments, many detailed descriptions are for making the present application better understood. However, those skilled in the art can easily recognize that some features can be omitted in different situations, or can be replaced by other elements, materials, methods. In some cases, some operations related to the present application are not shown or described in the specification, this is to avoid the core part of the present application being overwhelmed by too much description, and for those skilled in the art, it is not necessary to describe these related operations in detail, and they can fully understand the related operations according to the description in the specification and the general technical knowledge in the art.

[0060] In addition, the features, operations or characteristics described in the specification can be combined in any appropriate manner to form various implementations. At the same time, the steps or actions in the method description can also be interchanged or adjusted in a manner that is obvious to those skilled in the art. Therefore, the various sequences in the specification and the drawings are only for the purpose of clearly describing a certain embodiment and are not meant to be a required sequence, unless otherwise specified that a certain sequence must be followed.

[0061] The first embodiment of the present invention provides a battery charging and discharging driving framework implementation method based on the OH system HDF framework. Figure 1 Provide detailed explanation.

[0062] like Figure 1 As shown, in step S100, a unified battery charging and discharging driving interface is defined based on the OpenHarmony system HDF framework.

[0063] OpenHarmony is a full-scenario distributed operating system designed to achieve seamless collaboration and interoperability between different devices. It supports multiple device types, including smartphones, tablets, wearable devices, smart home devices, etc. The HDF (HarmonyOSDriver Foundation) driver framework provides driver developers with driver framework capabilities, including driver loading, driver service management, and driver message mechanism.

[0064] Driver interface definition: Based on the HDF framework (formally organizes source code driver interface, an important function of the driver framework is to provide a stable and unified hardware interface for the system), define a unified battery charging and discharging driver interface, driver configuration information management, organize source code in the form of HCS (HDF Configuration Source) files, configure and record device driver information in the form of Key-Value, and realize the decoupling of configuration information and driver code. Specific functions include initialization, charging control, discharge control, status query and other basic functions. Provide battery and charging and discharging driver models and frameworks to support battery-related driver models (such as charging IC, PMIC, battery) based on HDF to implement the management framework of battery-related driver models. Provide a default implementation of the driver model based on the HDI interface. Support mini / small / standard (kernel state and user state).

[0065] Initialization: Set initialization settings and default configurations, similar to the original version of the operating system reinstalled. When encountering BUGs or being unable to operate, you can perform partial initialization adjustments or restore to the most original version as an alternative emergency plan adjustment.

[0066] Charging control: The charging amount and charging method can be adjusted in a controllable manner through the interface configuration condition model, and a charging adjustment process can be generated to automatically adapt the charging method under specific charging environments and other scenarios.

[0067] Discharge control: Similar to the charge control scenario, the discharge mode and quantity can be configured when the charge adaptation scenario is in progress or after it ends.

[0068] Status query: You can view the current status and storage of the battery in real time, and perform charging and discharging operations based on the status. Upload the latest battery data to the system. After receiving the new data, the system will update the battery status, remaining power and other information. If a high temperature or low power alarm is received, the system can automatically trigger the relevant process to protect the battery and equipment from harm.

[0069] Development instance logic: Define unified interface protocols and data fields, access and be compatible with upper and lower data channels of different models of equipment and different usage environments, and ensure unified field recognition and precise correspondence at the bottom layer, so that the output data can accurately adapt to different hardware and environments.

[0070] like Figure 1 As shown, in step S200, a battery charging and discharging driver module is implemented on a specific hardware platform, and the battery user-mode driver service is compatible with two mechanisms: kernel-mode direct HDI and sysfs file system.

[0071] Driver module implementation: According to the specific hardware platform (including but not limited to handheld application-type smart devices, fixed or mobile smart computing computers and notebook tablets, electric-driven transportation, aerospace, diving tools, etc., various platforms controlled by auxiliary hardware in different market backgrounds, usage environments, developer agreements, etc.), the corresponding battery charging and discharging driver module is implemented (modules for different device types and scenarios need to be partially adjusted, and even the same device may have driver compatibility issues in different charging and discharging environments), including hardware initialization, data interaction, exception handling, etc. The battery user-state driver service is compatible with HDI (kernel-state direct pass-through) and sysfs ( / sys / class / power_supply / Battery) mechanisms. Two different adaptation mechanisms are developed to better solve the corresponding compatibility and connection problems.

[0072] HDI is a higher-level abstract interface for hardware functions. After the HDI interface definition is completed for various peripherals, it will only be changed under the compatibility rules of HDI, thus ensuring the stability of the interface. The specific driver implementation does not need to redefine the HDI interface, but only needs to be implemented on demand to access the system function.

[0073] HDI service publishing is based on UHDF (User HDF Driver Framework). The general service publishing implementation is as follows:

[0074] First, you need to add a UHDF driver to publish the IoService service. The IoService device service is the HDI service entity. The implementation method is the same as the KHDF driver.

[0075] int SampleDriverBind(struct HdfDeviceObject*deviceObject)

[0076] {

[0077] HDF_LOGE("SampleDriverBind enter!");

[0078] static struct IDeviceIoService testService={

[0079] .Dispatch = SampleServiceDispatch, / / Service callback interface

[0080] };

[0081] deviceObject->service=&testService;

[0082] return HDF_SUCCESS;

[0083] }

[0084] int SampleDriverInit(struct HdfDeviceObject*deviceObject)

[0085] {

[0086] HDF_LOGE("SampleDriverInit enter");

[0087] return HDF_SUCCESS;

[0088] }

[0089] void SampleDriverRelease(struct HdfDeviceObject*deviceObject)

[0090] {

[0091] HDF_LOGE("SampleDriverRelease enter");

[0092] return;

[0093] }

[0094] struct HdfDriverEntry g_sampleDriverEntry={

[0095] .moduleVersion=1,

[0096] .moduleName="sample_driver",

[0097] .Bind=SampleDriverBind,

[0098] .Init=SampleDriverInit,

[0099] .Release=SampleDriverRelease,

[0100] };

[0101] HDF_INIT(g_sampleDriverEntry);

[0102] When an HDI call is received, the service response interface "SampleServiceDispatch" will be called.

[0103] Client: caller object, not currently supported in user-mode drivers

[0104] cmdId: Call command word, used to distinguish the called API

[0105] Data: Call the input parameter serialization object. In the IPC call scenario, it is the C language encapsulation of the parcel object. The input parameter needs to be obtained from the data object using the serialization interface before use.

[0106] Reply: Calls the parameter object, and the information that needs to be returned to the call is written into the serialized object.

[0107] Development instance logic: Based on the traditional software development underlying platform Linux and the existing Hongmeng Euler operating system that has been promoted in application, the adaptation mechanism of the driver part is mainly considered in these two parts.

[0108] like Figure 1 As shown, in step S300, a battery management service layer is constructed to achieve precise control of battery charging and discharging by calling a driver interface.

[0109] Service layer design: Build a battery management service layer, and achieve precise control of battery charging and discharging by calling the driver interface. At the same time, it provides status monitoring and exception handling mechanisms, and provides a normalized battery and charging and discharging equipment HDI interface to support battery information query and reporting. It supports wired charging, wireless charging, and common fast charging protocols. It supports Charger management, such as current and voltage settings, charging status settings, etc. It normalizes the mini / small / standard HDI interface to complete the adaptation of lightweight components.

[0110] ①Service layer architecture design:

[0111] The design of the battery management service layer should follow the principles of modularity and scalability to facilitate subsequent maintenance and functional expansion. The service layer mainly includes the following modules:

[0112] 1.1 Driver interface module

[0113] The driver interface module is the core of the service layer and is responsible for interacting with the underlying hardware. By calling the driver interface, the service layer can implement battery charge and discharge control, status monitoring, and information query. The module should support the normalized HDI (Hardware Device Interface) interface to facilitate the adaptation of different types of batteries and charging and discharging equipment.

[0114] 1.2 Condition Monitoring Module

[0115] The status monitoring module is responsible for real-time monitoring of the working status of the battery, including key parameters such as voltage, current, temperature, and charging status. The module should have an exception handling mechanism. When an abnormal status is detected, it can trigger an alarm in time and take corresponding measures to ensure the safe operation of the battery.

[0116] 1.3 Charging Management Module

[0117] The charging management module is responsible for managing the battery charging process, including support for wired charging, wireless charging, and common fast charging protocols. The module should be able to dynamically adjust the charging current and voltage according to different charging methods and protocols to ensure charging efficiency and safety.

[0118] 1.4 Information Query Module

[0119] The information query module provides the functions of querying and reporting battery information. Users can obtain the real-time status, historical data and fault information of the battery through this module. At the same time, the module should support data reporting to facilitate remote monitoring and management.

[0120] ②Charge and discharge control mechanism

[0121] The battery charging and discharging process is the core function of the battery management service layer. In order to achieve precise control of battery charging and discharging, the service layer needs to design a complete control mechanism.

[0122] 2.1 Charging Control

[0123] During the charging process, the service layer should dynamically adjust the charging current and voltage according to the battery status and charging protocol. Specific measures include:

[0124] Constant current charging: When the battery voltage is low, the constant current charging mode is used to ensure safe charging of the battery.

[0125] Constant voltage charging: When the battery voltage reaches the set value, it switches to constant voltage charging mode to prevent overcharging.

[0126] Temperature monitoring: Real-time monitoring of battery temperature to avoid safety hazards caused by over-temperature.

[0127] 2.2 Discharge control

[0128] During the discharge process, the service layer should ensure that the battery discharges within a safe range to prevent over-discharge. Specific measures include:

[0129] Current limit: Set the discharge current limit according to the rated discharge current of the battery to avoid overload.

[0130] Voltage monitoring: Real-time monitoring of battery voltage to ensure that the battery operates within a safe voltage range.

[0131] Status feedback: Provides real-time discharge status feedback to help users understand battery usage.

[0132] ③Exception handling mechanism

[0133] In the process of battery management, abnormal situations often occur, so it is very important to design a complete abnormality handling mechanism. This mechanism should include the following aspects:

[0134] 3.1 Anomaly Detection

[0135] The service layer should have real-time anomaly detection capabilities, be able to monitor abnormal conditions such as overcharging, over-discharging, and overheating of the battery, and record abnormal information in a timely manner.

[0136] 3.2 Alarm Mechanism

[0137] When an anomaly is detected, the service layer should immediately trigger the alarm mechanism, send an alarm message to the user, and record the details of the abnormal event for subsequent analysis.

[0138] 3.3 Automatic protection

[0139] When an abnormality occurs, the service layer should be able to automatically take protective measures, such as cutting off charging, limiting discharge, etc., to ensure the safety of the battery.

[0140] ④Normalized HDI interface support

[0141] In order to achieve the adaptation of different batteries and charging and discharging equipment, the service layer should provide a normalized HDI interface. This interface should support the following functions:

[0142] Battery information query: supports users to query basic battery information, such as model, capacity, health status, etc.

[0143] Status reporting: Supports reporting the real-time status of the battery to the cloud for remote monitoring and management.

[0144] Charge and discharge control: Supports battery charge and discharge control through the HDI interface to ensure flexibility and convenience of operation.

[0145] ⑤Lightweight component adaptation

[0146] When designing the battery management service layer, the lightweight of the system should be taken into consideration. By standardizing the mini, small, and standard HDI interfaces, it is possible to adapt to lightweight components, reduce system complexity, and improve operating efficiency.

[0147] 5.1 Component Selection

[0148] When selecting components, priority should be given to parts with stable performance and low power consumption to ensure efficient operation of the system.

[0149] 5.2 Resource Management

[0150] By rationally managing system resources, we can avoid waste of resources and improve the system's response speed and processing capabilities.

[0151] Development instance logic: belongs to the management design of the application layer. It determines the corresponding charging and discharging control by defining different trigger nodes, and puts as many uncertain factors as possible in the scenario into the node trigger conditions, and saves the use case.

[0152] like Figure 1 As shown, in step S400, the dynamic loading mechanism based on the HDF framework supports dynamic loading and unloading of the battery charging and discharging driving module.

[0153] Framework scalability: Through the dynamic loading mechanism of the HDF framework, it supports dynamic loading and unloading of driver modules, facilitating future upgrades and expansions of battery technology.

[0154] The extensibility of the HDF framework is mainly reflected in its dynamic loading mechanism, which allows dynamic loading and unloading of driver modules, thus facilitating future upgrades and expansions of battery technology. The following are several key points of the HDF framework dynamic loading mechanism:

[0155] Dynamic loading and static loading support: The HDF framework supports dynamic loading and static loading of drivers, which means that the driver code can be compiled and deployed independently of the framework code, eliminating the direct code dependency between the driver code and the framework.

[0156] On-demand dynamic loading: The HDF framework supports on-demand dynamic loading, which can avoid full loading of device drivers and effectively reduce system resource usage.

[0157] Driver loading mode: HDF framework supports two loading modes, namely on-demand loading and sequential loading. On-demand loading allows the driver to be loaded by default during system startup, or dynamically loaded after the system is started; sequential loading allows the driver to be loaded according to the priority of the driver during system startup.

[0158] Driver service management: The HDF framework can centrally manage driver services. Developers can directly obtain driver-related services through the capability interface provided by the HDF framework.

[0159] Driver message mechanism: The HDF framework provides a unified driver message mechanism that supports user-mode applications to send messages to kernel-mode drivers, and also supports kernel-mode drivers to send messages to user-mode applications.

[0160] Componentized driver model: The HDF framework uses a componentized driver model as its core design idea, providing developers with more refined driver management and making driver development and deployment more standardized.

[0161] Through these mechanisms, the HDF framework can adapt to future upgrades and expansions of battery technology, allowing developers to more flexibly manage and update driver modules to adapt to new hardware and technical requirements.

[0162] Development example logic: Load and unload drivers and devices independently, consider implementing in a modular and structured manner, and respond to current driver behavior in the most efficient way under specific scenarios. For example, in fast charging mode, all driver conversions are mainly based on meeting fast charging conditions, and factors that may affect the current loading method are suspended or paused.

[0163] The present invention can realize the battery charge and discharge drive framework based on the HDF framework and the specific driver on the HDF framework system, and finally realize the battery charge and discharge drive framework based on the OH system HDF framework through compilation and integration. The framework can be applied to smart devices such as smart phones, tablet computers, wearable devices, etc. to improve the efficiency and safety of battery management.

[0164] Corresponding to the above-disclosed method for realizing a battery charging and discharging driving framework based on an OH system HDF framework, an embodiment of the present invention further discloses a battery charging and discharging driving framework realization system based on an OH system HDF framework, such as Figure 2 As shown, it specifically includes:

[0165] The driver interface definition module is used to define a unified battery charging and discharging driver interface based on the OpenHarmony system HDF framework;

[0166] The driver implementation module is used to implement the battery charging and discharging driver module on a specific hardware platform. The battery user-mode driver service is compatible with both kernel-mode direct HDI and sysfs file system mechanisms.

[0167] The service layer building module is used to build the battery management service layer and realize the precise control of battery charging and discharging by calling the driver interface;

[0168] The loading and unloading module is used for the dynamic loading mechanism based on the HDF framework, supporting the dynamic loading and unloading of the battery charging and discharging driver module.

[0169] It should be noted that for the detailed description of a battery charging and discharging driving framework implementation system based on the OH system HDF framework provided in an embodiment of the present invention, reference can be made to the relevant description of a battery charging and discharging driving framework implementation method based on the OH system HDF framework provided in an embodiment of the present application, which will not be repeated here.

[0170] Those skilled in the art will appreciate that all or part of the functions of the various methods in the above-mentioned embodiments can be implemented by hardware or by computer programs. When all or part of the functions in the above-mentioned embodiments are implemented by computer programs, the program can be stored in a computer-readable storage medium, and the storage medium can include: read-only memory, random access memory, disk, optical disk, hard disk, etc., and the program is executed by a computer to implement the above-mentioned functions. For example, the program is stored in the memory of the device, and when the program in the memory is executed by the processor, all or part of the above-mentioned functions can be implemented. In addition, when all or part of the functions in the above-mentioned embodiments are implemented by computer programs, the program can also be stored in a storage medium such as a server, another computer, disk, optical disk, flash disk or mobile hard disk, and can be downloaded or copied and saved in the memory of the local device, or the system of the local device is updated, and when the program in the memory is executed by the processor, all or part of the functions in the above-mentioned embodiments can be implemented.

[0171] The above specific examples are used to illustrate the present invention, which is only used to help understand the present invention and is not intended to limit the present invention. For those skilled in the art, according to the concept of the present invention, some simple deductions, modifications or substitutions can be made.

Claims

1. A method for implementing a battery charging and discharging driving framework based on an OH system HDF framework, characterized in that: The method comprises: Based on the OpenHarmony system HDF framework, a unified battery charging and discharging driver interface is defined; Implement the battery charging and discharging driver module on a specific hardware platform. The battery user-mode driver service is compatible with both kernel-mode direct HDI and sysfs file system mechanisms. Build a battery management service layer to achieve precise control of battery charging and discharging by calling the driver interface; The dynamic loading mechanism based on the HDF framework supports dynamic loading and unloading of battery charging and discharging driver modules.

2. A method for implementing a battery charging and discharging driving framework based on an OH system HDF framework as claimed in claim 1, characterized in that: Based on the OH system HDF driver framework, a unified battery charging and discharging driver interface is defined, including: The basic operations of battery charging and discharging are defined through a unified driver interface, including initialization, charging control, discharging control, and status query.

3. A method for implementing a battery charging and discharging driving framework based on an OH system HDF framework as claimed in claim 2, characterized in that: Based on the OH system HDF driver framework, a unified battery charging and discharging driver interface is defined, including: Driver configuration information management: Organize source code in the form of HCS files, configure and record device driver information in the form of Key-Value, and decouple configuration information from driver code; Provides a default implementation of the driver model based on the HDI interface, allowing developers to use the default implementation to quickly integrate and test battery-related drivers; The interface supports three modes: mini, small and standard. Different modes correspond to different kernel state and user state implementations.

4. A method for implementing a battery charging and discharging driving framework based on an OH system HDF framework as claimed in claim 1, characterized in that: Implement the battery charging and discharging driver module on a specific hardware platform. The battery user-mode driver service is compatible with the kernel-mode direct HDI and sysfs file system mechanisms, including: Implement the battery charging and discharging driver module on a specific hardware platform, including hardware initialization, data interaction, and exception handling; HDI service release is based on the user-mode HDF driver framework UHDF.

5. The method for implementing a battery charging and discharging driving framework based on an OH system HDF framework as claimed in claim 1, characterized in that: The battery management service layer constructed includes: Driver interface module: The driver interface module is the core of the service layer and is responsible for interacting with the underlying hardware. By calling the driver interface, the service layer can realize battery charge and discharge control, status monitoring and information query. The module should support a normalized HDI interface to facilitate the adaptation of different types of batteries and charging and discharging equipment. Status monitoring module: responsible for real-time monitoring of the working status of the battery, including voltage, current, temperature, and charging status parameters; the module has an exception handling mechanism. When an abnormal status is detected, it can trigger an alarm in time and take corresponding measures to ensure the safe operation of the battery; Charging management module: responsible for managing the battery charging process, including support for wired charging, wireless charging, and common fast charging protocols; the module can dynamically adjust the charging current and voltage according to different charging methods and protocols to ensure charging efficiency and safety; Information query module: provides battery information query and reporting functions. Users can obtain the real-time status, historical data and fault information of the battery through the information query module. At the same time, the module supports data reporting, which is convenient for remote monitoring and management. Charge and discharge control mechanism: The battery charge and discharge process is the core function of the battery management service layer, including: Charging control: During the charging process, the service layer should dynamically adjust the charging current and voltage according to the battery status and charging protocol; Discharge control: During the discharge process, the service layer should ensure that the battery is discharged within a safe range to prevent over-discharge.

6. A method for implementing a battery charging and discharging driving framework based on an OH system HDF framework as claimed in claim 1, characterized in that: The battery management service layer constructed also includes: Exception handling mechanism, including: Abnormal detection: The service layer has real-time abnormal detection capabilities, which can monitor abnormal conditions including overcharging, over-discharging, and over-temperature of the battery, and record abnormal information in a timely manner; Alarm mechanism: When an anomaly is detected, the service layer should immediately trigger the alarm mechanism, send an alarm message to the user, and record the details of the abnormal event for subsequent analysis; Automatic protection: When an abnormality occurs, the service layer should be able to automatically take protective measures to ensure the safety of the battery.

7. A method for implementing a battery charging and discharging driving framework based on an OH system HDF framework as claimed in claim 1, characterized in that: The battery management service layer constructed also includes: Normalized HDI interface support: In order to achieve the adaptation of different batteries and charging and discharging equipment, the service layer should provide a normalized HDI interface, specifically supporting the following functions: Battery information query: supports users to query basic battery information, including model, capacity, and health status; Status reporting: Supports reporting the real-time status of the battery to the cloud for remote monitoring and management; Charge and discharge control: Supports battery charge and discharge control through the HDI interface to ensure flexibility and convenience of operation.

8. A method for implementing a battery charging and discharging driving framework based on an OH system HDF framework as claimed in claim 1, characterized in that: Constructing the battery management service layer, including: Lightweight component adaptation: When designing the battery management service layer, the lightweight of the system should be taken into consideration; the adaptation of lightweight components can be achieved by standardizing the mini, small and standard HDI interfaces; Component selection: When selecting components, give priority to components with stable performance and low power consumption to ensure efficient operation of the system; Resource management: Avoid waste of resources and improve system response speed and processing capacity through reasonable management of system resources.

9. A method for implementing a battery charging and discharging driving framework based on an OH system HDF framework as claimed in claim 1, characterized in that: The dynamic loading mechanism based on the HDF framework supports dynamic loading and unloading of battery charging and discharging driver modules, including: Dynamic loading and static loading support: The HDF framework supports dynamic loading and static loading of driver modules, allowing the driver to be compiled and deployed independently of the framework code, eliminating the direct code dependency between the driver code and the framework; On-demand dynamic loading: The HDF framework supports on-demand dynamic loading, which can avoid full loading of device drivers and effectively reduce the occupation of system resources; Driver loading mode: HDF framework supports two loading modes, namely on-demand loading and sequential loading. On-demand loading allows the driver to be loaded by default during system startup, or dynamically loaded after the system is started; sequential loading allows the driver to be loaded according to the priority of the driver during system startup. Driver service management: The HDF framework can centrally manage driver services. Developers can directly obtain driver-related services through the capability interface provided by the HDF framework. Driver message mechanism: The HDF framework provides a unified driver message mechanism that supports user-mode applications to send messages to kernel-mode drivers, and also supports kernel-mode drivers to send messages to user-mode applications. Componentized driver model: The HDF framework uses a componentized driver model as its core design idea, providing developers with more refined driver management and making driver development and deployment more standardized.

10. A battery charging and discharging driving framework implementation system based on the OH system HDF framework, characterized in that: The system comprises: The driver interface definition module is used to define a unified battery charging and discharging driver interface based on the OpenHarmony system HDF framework; The driver implementation module is used to implement the battery charging and discharging driver module on a specific hardware platform. The battery user-mode driver service is compatible with both kernel-mode direct HDI and sysfs file system mechanisms. The service layer building module is used to build the battery management service layer and realize the precise control of battery charging and discharging by calling the driver interface; The loading and unloading module is used for the dynamic loading mechanism based on the HDF framework, supporting the dynamic loading and unloading of the battery charging and discharging driver module.

Images