Charging data acquisition methods, devices, terminal equipment and storage media

Abstract

This application discloses a charging data acquisition method, apparatus, terminal device, and storage medium, relating to the field of terminal technology. The method includes: a first processor writing first data into shared memory shared by a first processor and a second processor, and sending a first trigger signal to the second processor; the second processor retrieving the first data from the shared memory according to the first trigger signal, retrieving charging data matching various charging data types based on the first data, and generating second data; writing the second data into the shared memory, and sending a second trigger signal to the first processor; the first processor retrieving the second data from the shared memory according to the second trigger signal, and obtaining the charging data. In the charging process of the terminal device of this application, the first processor directly retrieves the second data from the shared memory all at once, without needing to wake up the second processor for each type of charging data retrieved, thus reducing the number of times the second processor is woken up.

Description

Technical Field

[0001] This application relates to the field of terminal technology, specifically to a charging data acquisition method, apparatus, terminal device, and storage medium. Background Technology

[0002] With the continuous development of science and technology, people's pace of life is getting faster and faster. Most of the terminal devices used in daily life are powered by their own internal batteries, and these terminal devices are also equipped with the function of charging batteries.

[0003] Currently, in most terminal devices, battery charging is controlled by a microcontroller unit (MCU), which is an external MCU chip placed on a printed circuit board (PCB) to control battery charging. To save costs, some terminal devices remove the MCU chip and integrate the charging control logic into an analog digital signal processing (ADSP) chip. Each time data during the charging process needs to be accessed, the terminal device's central processing unit (CPU) needs to wake up the ADSP to obtain the relevant data from the fuel gauge.

[0004] In the above scheme, during the charging process of the terminal device, the terminal device needs to constantly wake up the ADSP to obtain data, which can easily lead to power consumption waste during the charging process. Summary of the Invention

[0005] This application provides a charging data acquisition method, apparatus, terminal device, and storage medium, which can reduce the number of ADSP wake-ups and reduce power consumption waste during battery charging in the terminal device. The technical solution is as follows:

[0006] On one hand, embodiments of this application provide a charging data acquisition method applied to a terminal device, the terminal device including a first processor and a second processor, the first processor being used to run an operating system, and the second processor being used to control the charging function, the method including:

[0007] The first processor writes first data into the shared memory of the first processor and the second processor, and sends a first trigger signal to the second processor. The first data includes one or more charging data types that the first processor needs to acquire.

[0008] The second processor retrieves the first data from the shared memory according to the first trigger signal, retrieves charging data matching each of the charging data types according to the first data, and generates second data according to the charging data;

[0009] The second processor writes the second data into the shared memory and sends a second trigger signal to the first processor;

[0010] The first processor retrieves the second data from the shared memory based on the second trigger signal, and obtains the charging data based on the second data.

[0011] On one hand, this application provides a charging data acquisition device applied to a terminal device. The terminal device includes a first processor and a second processor. The first processor is used to run an operating system, and the second processor is used to control the charging function. The device includes:

[0012] The first signal sending module is used for the first processor to write first data into the shared memory of the first processor and the second processor, and to send a first trigger signal to the second processor. The first data includes one or more charging data types that the first processor needs to acquire.

[0013] The first data generation module is used by the second processor to obtain the first data from the shared memory according to the first trigger signal, obtain charging data matching each of the charging data types according to the first data, and generate second data according to the charging data.

[0014] The second signal sending module is used for the second processor to write the second data into the shared memory and to send a second trigger signal to the first processor;

[0015] A charging data acquisition module is used by the first processor to acquire the second data from the shared memory according to the second trigger signal, and to obtain the charging data based on the second data.

[0016] On the other hand, embodiments of this application provide a terminal device, including a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, the processor enables the processor to implement the charging data acquisition method as described in one aspect above.

[0017] On the other hand, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the charging data acquisition method as described in one aspect above.

[0018] On the other hand, embodiments of this application provide a computer program product that, when run on a computer, causes the computer to execute the charging data acquisition method as described in one aspect above.

[0019] On the other hand, embodiments of this application provide an application publishing platform for publishing computer program products, wherein when the computer program product is run on a computer, the computer executes the charging data acquisition method as described in one aspect above.

[0020] The technical solutions provided in this application embodiment may include at least the following beneficial effects:

[0021] The terminal device includes a first processor running an operating system and a second processor controlling the charging function. The first processor writes first data, containing one or more types of charging data it needs to acquire, into a shared memory shared by the first and second processors, and sends a first trigger signal to the second processor. The second processor retrieves the first data from the shared memory based on the first trigger signal, acquires charging data matching each charging data type based on the first data, and generates second data based on the charging data. The second processor also writes the second data into the shared memory and sends a second trigger signal to the first processor. The first processor retrieves the second data from the shared memory based on the second trigger signal and obtains the charging data based on the second data. During the charging process, when the first processor needs to use charging data, it directly acquires the second data from the shared memory all at once, without waking up the second processor for each piece of charging data acquired, thus reducing the number of times the second processor is woken up and reducing wasted power consumption during the charging process. Attached Figure Description

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

[0023] Figure 1 This is a schematic diagram of the architecture for charging control of a terminal device according to an exemplary embodiment of this application;

[0024] Figure 2 This is a schematic diagram of the architecture for charging control of another terminal device according to an exemplary embodiment of this application;

[0025] Figure 3 This is a flowchart illustrating a charging data acquisition method according to an exemplary embodiment of this application;

[0026] Figure 4 This is a flowchart illustrating a charging data acquisition method according to an exemplary embodiment of this application;

[0027] Figure 5 This is a flowchart illustrating a charging data acquisition method according to an exemplary embodiment of this application;

[0028] Figure 6 This is a structural block diagram of a charging data acquisition device provided in an exemplary embodiment of this application;

[0029] Figure 7 This is a schematic diagram of the structure of a terminal device provided in an exemplary embodiment of this application. Detailed Implementation

[0030] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0031] In this article, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0032] The solution provided in this application can be used in real-world scenarios where people use terminals in their daily lives and applications are running on the terminals. To facilitate understanding, the application architecture involved in the embodiments of this application will be briefly introduced below.

[0033] With the continuous development of science and technology, people are using terminal devices more and more in their daily lives. Terminal devices are powered by batteries, and when the battery power of a terminal device is low, it needs to be charged.

[0034] Currently, in most battery charging technologies, the charging process is controlled by an MCU chip. Please refer to [reference needed]. Figure 1 This illustrates a schematic diagram of the architecture for charging control of a terminal device according to an exemplary embodiment of this application. Figure 1As shown, the charging control architecture includes a central processing unit (CPU) 100, a microcontroller unit (MCU) 101, an analog digital signal processing chip (ADSP) 102, a fuel gauge 103, an adapter 104, and a power management IC (PMIC) 105.

[0035] The central processing unit (CPU) 100 of the terminal device typically runs an operating system, which includes a kernel layer 100a and a framework layer 100b. The CPU 100 is electrically connected to the fuel gauge 103 via an I2C bus (Inter-Integrated Circuit). The CPU 100 is also electrically connected to the PMIC 105 via a System Power Management Interface (SPMI) bus. The CPU 100 is also electrically connected to the MCU 101 via a general-purpose input / output (GPIO) port. The CPU 100 is electrically connected to the ADSP 102 via a GLINK bus. The MCU 101 is also electrically connected to the adapter 104.

[0036] In the above Figure 1 In the charging architecture shown, the charging logic control is typically implemented directly in the kernel layer of CPU 100. The kernel layer can operate and control PMIC 105, directly reading and writing to PMIC 105 via the SPMI bus. The upper-level logic control of the charging process is usually handled by a charging control thread. For example, a typical charging control thread can be implemented using the `oplus_chg_update_work` function, which performs data acquisition actions in four places, including: initializing the driver probe; generating plugin and plugout interrupts when the charger is inserted or removed; and acquiring data at fixed intervals when the interrupt identified during type identification is a preset type interrupt.

[0037] In the charging control thread, the CPU typically needs to read the battery level sensor's attributes (e.g., battery temperature, battery current, battery voltage, battery percentage, and remaining battery capacity), and calculate the battery's input current, cutoff voltage, cutoff current, and charging current under different conditions, writing them into the PMIC's registers. From the kernel layer, the power_supply_changed function can be used to send a battery state change event message to the framework layer. After receiving the event message, the framework layer will actively traverse each node containing charging data and obtain the charging data contained in these nodes.

[0038] To save on manufacturing costs, one solution in the related technology addresses the above... Figure 1 The architecture shown has been improved by removing the MCU chip. Please refer to [reference needed]. Figure 2 This illustrates a schematic diagram of the architecture for charging control of another terminal device according to an exemplary embodiment of this application. Figure 2 As shown, the charging control architecture includes a central processing unit (CPU) 200, an analog digital signal processing chip (ADSP) 201, a fuel gauge 202, a power management IC (PMIC) 203, an adapter 204, and a VOOCPHY module 205.

[0039] in, Figure 2 The charging logic is controlled and implemented by ADSP 201, which is similar to... Figure 1 The PMIC105 in the PMIC105 enables the ADSP 201 to detect when the charger is inserted and removed during charging, identify the type of charger, and send messages to the CPU 200 via the GLINK bus to inform it of the relevant charging status.

[0040] Optional, Figure 2 The structure of CPU 200 and Figure 1 The CPU 100 has a similar structure and runs an operating system, which also includes a kernel layer 200a and a framework layer 200b. The CPU 200 is electrically connected to the ADSP 201 via the GLINK bus. The ADSP 201 is electrically connected to the fuel gauge 202 via the I2C bus (Inter-Integrated Circuit). The ADSP 201 is also electrically connected to the PMIC 203 via the SPMI bus. The ADSP 201 is also electrically connected to the adapter 204 via GPIO.

[0041] Depend on Figure 2 As can be seen, the kernel layer in CPU 200 can no longer directly access the PMIC 203 registers related to charging and the USB universal bus interface. It needs to wake up ADSP 201 to perform the corresponding operations. For example, in a data read operation, CPU 200 sends a data retrieval request to ADSP 201 via the GLINK bus. ADSP 201 reads the corresponding data retrieval request, retrieves the data, stores it in shared memory, and then notifies CPU 201 to read the relevant data from shared memory. During this process, both read and write operations require waking up the ADSP 201 system.

[0042] Similar to the charging process described above, the charging logic needs to access charging data multiple times (e.g., when accessing data in the fuel gauge). Since the fuel gauge is mounted on the ADSP system, the CPU needs to access charging data in multiple places while executing the charging control thread to charge the device. Moreover, each access to charging data requires waking up the ADSP system, resulting in high power consumption of the terminal device during the charging process and wasted power during charging.

[0043] To reduce the number of ADSP wake-ups in terminal devices and lower the power consumption of the terminal devices during charging, this application provides a solution. In the above... Figure 2 Based on the charging control structure shown, by controlling the data transmission between the CPU and ADSP, the number of times the ADSP is woken up is reduced, thereby achieving the effect of saving power consumption.

[0044] Please refer to Figure 3 The diagram illustrates a flowchart of a charging data acquisition method according to an exemplary embodiment of this application. This method is applied in a terminal device, which includes a first processor and a second processor. The first processor runs an operating system, and the second processor controls the charging function, such as... Figure 3 As shown, the method includes the following steps:

[0045] Step 301: The first processor writes the first data into the shared memory of the first processor and the second processor, and sends a first trigger signal to the second processor. The first data includes one or more charging data types that the first processor needs to acquire.

[0046] Optionally, in the Android system, the first processor can be one of the above. Figure 2 The CPU in the middle, the second processor is the one mentioned above. Figure 2In the ADSP, the first processor can run an operating system, such as Android or iOS, while the ADSP can control the charging logic of the terminal device. Optionally, the shared memory between the first and second processors can be a memory within the terminal device, which can be read and written by either the first or second processor.

[0047] Optionally, the first processor can generate first data and write it into the shared memory of the first and second processors. The first data includes one or more charging data types that the first processor needs to acquire. Optionally, the first processor packages one or more charging data types it needs to acquire and writes the generated data packet as the first data into the shared memory of the first and second processors. The charging data types may include battery temperature, battery current, battery voltage, battery percentage, remaining battery capacity, input current, cutoff voltage, cutoff current, and charging current, etc. The battery percentage refers to the percentage of the battery's remaining capacity relative to its total capacity, and the remaining battery capacity refers to the amount of charge required to fully charge the battery.

[0048] Optionally, after the first processor writes the first data into the shared memory, it can send a first trigger signal to the second processor. This first trigger signal is used to trigger the second processor to read the first data from the shared memory. For example, in the above... Figure 2 In this context, the first trigger signal can be the GLINK interrupt signal between the CPU and the ADSP. After the CPU writes the first data into the shared memory, it can send a GLINK interrupt signal to the ADSP.

[0049] Step 302: The second processor retrieves first data from the shared memory according to the first trigger signal, retrieves charging data that matches each charging data type according to the first data, and generates second data according to the charging data.

[0050] Optionally, after receiving the first trigger signal, the second processor retrieves the corresponding first data from the shared memory based on the first trigger signal, and obtains charging data matching each charging data type in the first data, and generates second data based on the charging data. For example, if the charging data types include the battery temperature in the fuel gauge, the second processor obtains the battery temperature from each charging data type through the first data, and obtains the battery temperature from the fuel gauge through the I2C bus. Finally, the second processor packages each charging data and its corresponding charging data type to obtain the second data.

[0051] Optionally, the first data can contain multiple charging data types. The second processor can acquire all the matching charging data types and generate second data based on these charging data types, thus returning all the charging data as a whole to the shared memory. For example, when the charging data types include the battery temperature from the fuel gauge, the second processor acquires other charging data types besides the battery temperature from the first data, such as battery current, battery voltage, cutoff voltage, and cutoff current. In addition to acquiring the battery temperature, battery current, and battery voltage from the fuel gauge through the I2C bus, the second processor also acquires the cutoff voltage and cutoff current through the PMIC register, generates second data based on each charging data type, and returns the second data containing all the charging data types at once.

[0052] Step 303: The second processor writes the second data into the shared memory and sends a second trigger signal to the first processor.

[0053] Optionally, the second processor writes the second data it generates to the shared memory and sends a second trigger signal to the first processor. Similarly, the second trigger signal is used to trigger the second processor to read the first data from the shared memory. For example, in the above... Figure 2 In this context, the second trigger signal can be the GLINK interrupt signal between the CPU and the ADSP. That is, after the ADSP writes the second data into the shared memory, it can send a GLINK interrupt signal to the CPU to notify the CPU to read the data written by the ADSP from the shared memory.

[0054] Step 304: The first processor retrieves the second data from the shared memory according to the second trigger signal, and obtains the charging data based on the second data.

[0055] Optionally, after receiving the second trigger signal, the first processor retrieves the second data written by the second processor from the shared memory, parses the second data, and extracts the corresponding charging data for each charging data type. For example, if the first processor previously included charging data types such as battery temperature and battery current in the first data, and the second processor included charging data of 12 degrees Celsius and 3 milliamps for the corresponding battery temperature and battery current in the second data, then the charging data obtained by the first processor would also include 12 degrees Celsius and 3 milliamps.

[0056] In summary, the terminal device includes a first processor running an operating system and a second processor controlling the charging function. The first processor writes first data, containing one or more charging data types it needs to acquire, into a shared memory shared by the first and second processors, and sends a first trigger signal to the second processor. The second processor retrieves the first data from the shared memory based on the first trigger signal, acquires charging data matching each charging data type based on the first data, and generates second data based on the charging data. The second processor also writes the second data into the shared memory and sends a second trigger signal to the first processor. The first processor retrieves the second data from the shared memory based on the second trigger signal and obtains the charging data based on the second data. During the charging process, when the first processor needs to use charging data, it directly acquires the second data from the shared memory all at once, without waking up the second processor for each type of charging data acquired, thus reducing the number of times the second processor is woken up and reducing wasted power consumption during the charging process.

[0057] Please refer to Figure 4 The diagram illustrates a flowchart of a charging data acquisition method according to an exemplary embodiment of this application. This method is applied in a terminal device, which includes a first processor and a second processor. The first processor runs an operating system, and the second processor controls the charging function, such as... Figure 4 As shown, the method includes the following steps:

[0058] Step 401: The first processor generates first data according to the agreed data format, which includes at least one of the following fields: communication message type, maximum number of bytes in the data packet, module identifier, signal identifier, and the type of charging data to be acquired.

[0059] The module identifier is used to represent the identity information of the sending end, and the signal identifier is used to represent the operation performed by the receiving end.

[0060] Optionally, when the first processor of the terminal device needs to obtain charging data type information, it can generate first data based on an agreed-upon data format. This agreed-upon data format can be pre-set by developers or maintenance personnel in the first processor or application. For example, the agreed-upon data format may include communication message type, maximum data packet size, module identifier, signal identifier, and the charging data type to be obtained.

[0061] The communication message type can refer to the message type of the interactive messages sent between two processors, such as those mentioned above. Figure 2The first processor is the CPU, and the second processor is the ADSP. The communication message type can be the GLINK message type transmitted between the CPU and the ADSP. Optionally, the GLINK message type can be represented by `req_msg.hdr.type`, typically including two types: `TYPE_REQ_RESP` and `TYPE_NOTIFICATION`. `TYPE_REQ_RESP` is a message type that requires a response from the receiver to the sender. `TYPE_NOTIFICATION` is a message type that does not require a response from the receiver to the sender. Optionally, in this application, developers or operations personnel can set the communication message type to the default type that requires a response (e.g., `TYPE_REQ_RESP`).

[0062] Optionally, on Android devices, the GLINK message type that needs to be responded to can be OEM_OPCODE_READ_BUFFER, which is the value of req_msg.hdr.opcode. Alternatively, the GLINK message type can also be a battery attribute setting type: BC_BATTERY_STATUS_SET, or a battery attribute retrieval type: BC_BATTERY_STATUS_GET, etc., which will not be listed here.

[0063] Optionally, in this application, the maximum number of bytes in the data packet can be the maximum number of bytes allowed in this transmission. That is, the total number of bytes contained in the generated data packet. For example, in a terminal device of an Android system, the maximum number of bytes in the data packet in the above-mentioned agreed data format can be represented by reg_msg.data_size. By setting this charging data type, the total number of bytes occupied by the charging data read by the ADSP at one time can be controlled to not exceed this number, flexibly adjusting the shared memory. Optionally, the maximum number of bytes in the data packet can also be pre-calculated by the CPU and used in the process of generating the first data.

[0064] Optionally, the module identifier in the agreed data format can represent the identity information of the sending end. For example, when the first processor sends a message to the second processor through the GLINK bus, the sending end of the message is the first processor. In the agreed data format, the module identifier is represented by the owner. When the second processor receives the message and finds that the owner is the first processor, it can know that the first processor has come to access the data.

[0065] Optionally, the signal identifiers in the agreed-upon data format can represent the operations performed by the receiving end. For example, when the first processor sends a message to the second processor via the GLINK bus, the receiving end of the message is the second processor. In the agreed-upon data format, the signal identifier is represented by an opcode. When the second processor receives the message and obtains the opcode, it can determine that it needs to perform the operation corresponding to the opcode. Optionally, different opcodes correspond to different operations. For example, opcode_1 corresponds to the operation of reading data from the PMIC, while opcode_2 corresponds to the operation of reading data from the fuel gauge, etc.

[0066] Optionally, the charging data types that need to be obtained in the agreed data format can be represented by data. That is, the charging data types that the first processor needs to obtain during the generation of the first data are represented by data. After the second processor learns these charging data types, it can obtain the charging data corresponding to the charging data types and also return it through data. Optionally, the first data may include multiple charging data types that the first processor needs to obtain. For example, data contains various member variables data_buffer, where each member variable data_buffer corresponds to a different charging data type. data_buffer[0] can represent battery voltage, data_buffer[1] can represent battery temperature, etc.

[0067] In one possible implementation, the first processor generates the first data according to the aforementioned agreed data format as follows: Struct{owner; type; opcode; data; size;}; The first variable is the module identifier, the second variable is the communication message type, the third variable is the signal identifier, the fourth variable is the charging data type to be acquired, and the fifth variable is the maximum number of bytes in the data packet. This application does not impose any restrictions on the order of variables in the generated data packet.

[0068] Step 402: The first processor writes the first data into the shared memory of the first processor and the second processor, and sends the first trigger signal to the second processor.

[0069] Optionally, the first processor writes the generated first data into shared memory and sends a first trigger signal to notify the second processor to retrieve the generated first data from the shared memory. Optionally, in the architecture of the Android terminal device described above, the first processor is a CPU, and the second processor is an ADSP. The CPU can prepare the generated first data using the `oem_battery_chg_write` function and write it into the shared memory between the CPU and the ADSP using `pmic_glink_write`. After the CPU writes the generated first data into the shared memory, it can send an interrupt to the ADSP via the GLINK bus; the first trigger signal is this interrupt signal.

[0070] Step 403: The second processor retrieves first data from the shared memory according to the first trigger signal, retrieves charging data matching each charging data type according to the first data, and generates second data according to the charging data.

[0071] Optionally, after receiving the first trigger signal, the second processor determines that it needs to retrieve the first data from the shared memory based on the first trigger signal. For example, after the ADSP receives an interrupt sent by the CPU via GLINK, it needs to retrieve the first data from the shared memory.

[0072] Optionally, the second processor may also parse the first data according to the agreed data format to obtain the first parsing result; if the first parsing result contains a target signal identifier, then according to the various charging data types contained in the parsing result, the charging data matching the various charging data types contained in the parsing result is obtained, wherein the target signal identifier is used to characterize the operation of the receiving end to retrieve the data written by the sending end from the shared memory.

[0073] For example, after receiving an interrupt from the CPU via GLINK, the ADSP retrieves the first data written by the CPU from shared memory and parses it according to the data format agreed upon by the CPU and ADSP to obtain the first parsing result. That is, the agreed-upon data format is similar to the data format used to generate the first data, including: communication message type, maximum number of bytes in the data packet, module identifier, signal identifier, and the type of charging data to be obtained. If the first data generated by the CPU is: `Struct{owner; type; opcode; data; size;}`, the ADSP will also parse the first data according to the same structure.

[0074] If the first parsing result contains a target signal identifier, then charging data matching the charging data types contained in the parsing result is obtained. Optionally, the target signal identifier can represent the operation of the receiving end retrieving data written by the sending end from shared memory. In this application, when the target signal identifier opcode = OEM_OPCODE_READ_BUFFER, it indicates that the CPU is accessing the charging data in the ADSP, and the ADSP needs to perform the operation of retrieving the first data written by the CPU from shared memory.

[0075] Optionally, ADSP can obtain various charging data types from the parsing results, acquire charging data matching each charging data type according to each data_buffer member variable, and directly match them to form a data_buffer member variable containing charging data. For example, data_buffer[0] can represent battery voltage, data_buffer[1] can represent battery temperature, and data_buffer[2] can represent input current. ADSP acquires the values ​​of battery voltage and battery temperature through the I2C bus, and also reads the input current of the register through the SPMI bus. When generating the second data, the acquired charging data is added to the corresponding data_buffer member variable.

[0076] In one possible implementation, the ADSP can also delete the first data in the shared memory; then, according to a pre-defined data format, package the various charging data types with the acquired charging data matching each charging data type to generate the second data. That is, after retrieving the first data from the shared memory, the ADSP can erase the area in the shared memory that stores the first data, freeing up the shared memory space, and then package the charging data matching each charging data type obtained above to generate the second data. Optionally, the generation method of the second data can refer to the generation method of the first data; its internal structure contains the same pre-defined data format, which will not be elaborated here.

[0077] Step 404: The second processor writes the second data into the shared memory and sends a second trigger signal to the first processor.

[0078] Optionally, the second processor can rewrite the generated second data into the shared memory and notify the first processor to retrieve the second data by sending a second trigger signal.

[0079] In one possible implementation, for the above parsing process, after receiving an interrupt from the CPU, the ADSP can parse the first data from shared memory according to the agreed data format using the `pmic_glink_dequeue_rx_data` function. When the parsed opcode = `OEM_OPCODE_READ_BUFFER`, it indicates that the CPU needs to access charging data. The ADSP needs to read the corresponding charging data type from the first data, obtain the charging data matching the charging type, add it to the member variable of `data_buffer`, and finally generate the second data containing the charging data. Then, the generated second data is copied to shared memory via `pmic_glink_tx`, and an interrupt is sent to the CPU via GLINK. That is, the second trigger signal can be an interrupt signal sent by the ADSP to the CPU via the GLINK bus.

[0080] Step 405: The first processor retrieves the second data from the shared memory according to the second trigger signal, and obtains the charging data based on the second data.

[0081] Optionally, the first processor continues to parse the second data according to the agreed data format to obtain the second parsing result; if the second parsing result contains a target signal identifier, the charging data that matches each charging data type in the second data is obtained according to each charging data type in the second data.

[0082] That is, if the second parsing result contains a target signal identifier, then charging data matching the charging data types contained in the parsing result is obtained. Optionally, the target signal identifier can represent the operation of the receiving end to retrieve data written by the sending end from shared memory. Taking the first processor as a CPU and the second processor as an ADSP as an example, in this application, when the target signal identifier opcode = OEM_OPCODE_READ_BUFFER, it indicates that the CPU needs to retrieve the second data written by the ADSP from shared memory. After receiving the interrupt sent by the ADSP, the CPU parses the second data according to the agreed data format for generating the first data. If the second data contains the target signal identifier, the data_buffer data in the second data is extracted to obtain the charging data in the data_buffer member variable. The charging data that needs to be accessed in each place in the subsequent charging control thread can be directly obtained from the data in the data_buffer member variable without waking up the ADSP multiple times.

[0083] Step 406: The first processor determines the battery state. If a change in battery state is detected, a state change information is generated to indicate that the battery state of the terminal has changed.

[0084] Optionally, after obtaining the charging data, the first processor can compare it with the charging data obtained in the previous charging control thread to determine whether the corresponding battery state has changed. For example, the battery state can indicate changes in battery temperature, battery capacity, or battery charging current. For instance, after obtaining the charging data, the first processor calculates the cutoff voltage to be 4 mA and the battery temperature to be 12 degrees Celsius. If this differs from the data obtained in the previous charging control thread, it can be determined that the battery state has changed.

[0085] Optionally, if the battery state changes, the first processor can generate state change information accordingly, thereby indicating that the terminal's battery state has changed. Optionally, in this application, the Android system terminal device can generate state change information (event message) through the kernel layer in the CPU.

[0086] Step 407: The first processor reports the status change information to the battery management module according to the preset reporting method.

[0087] Optionally, the first processor reports the generated status change information to the battery management module according to a preset reporting method.

[0088] Optionally, the preset reporting method includes any one of the following: when the terminal device is electrically connected to the charger, the status change information is reported to the battery management module periodically according to a first time interval; when the battery level of the terminal device changes, the status change information is reported to the battery management module; when the terminal device is electrically disconnected from the charger, the status change information is reported to the battery management module; the status change information is reported to the battery management module periodically according to a second time interval, where the second time interval is longer than the first time interval.

[0089] For example, the first processor can also detect whether it is electrically connected to the charger. If the charger is always electrically connected to the terminal device, the first processor can periodically report the received state change information to the battery management module at a rate of once every 5 seconds. Optionally, in the terminal device, the battery management module can be implemented in the application framework layer. Alternatively, the CPU can periodically report the received state change information from the kernel layer to the application framework layer at a rate of once every 5 seconds.

[0090] Optionally, the first processor can also detect whether the battery level of the terminal device has changed. When the battery level of the terminal device changes, it reports the state change information to the battery management module. That is, when the battery level changes, the generated state change information is reported to the battery management module. Similarly, this can also be replaced by the CPU detecting a change in the battery level of the terminal device and reporting the obtained state change information from the kernel layer to the application framework layer.

[0091] Optionally, the first processor can also report the state change information to the battery management module when it detects that the terminal device has lost its electrical connection with the charger. That is, when the terminal device loses its electrical connection with the charger, the generated state change information is reported to the battery management module. Similarly, this can also be replaced by the CPU detecting that the terminal device has lost its electrical connection with the charger and reporting the obtained state change information from the kernel layer to the application framework layer.

[0092] Optionally, the first processor can also report according to the default period of the counter. For example, if the default period is 30 seconds, the first processor can periodically report the obtained state change information to the battery management module every 30 seconds. Optionally, in the terminal device, the battery management module can be implemented in the application framework layer. Alternatively, it can be replaced by the CPU periodically reporting the obtained state change information from the kernel layer to the application framework layer every 30 seconds.

[0093] In one possible implementation, the aforementioned state change information carries a source identifier. The first processor can also detect whether the source identifier is a Universal Serial Bus (USB) identifier. When the source identifier is a USB identifier, the first processor accesses the second processor to obtain charging data corresponding to the USB interface. Optionally, the source identifier can include a battery or a USB interface. If the first processor detects that the source identifier in the state change information is a USB identifier, it can continue to access the second processor to obtain charging data corresponding to the USB interface. If the first processor detects that the source identifier in the state change information is a battery, it can choose not to access the charging data corresponding to the USB interface. Optionally, the charging data corresponding to the USB interface can be charging data under the OTG node attributes, such as the charging data corresponding to the OTG_online or OTG_ccoritation nodes.

[0094] In one possible implementation, when the power management module needs to obtain static attribute data corresponding to the battery, the first processor reports the static attribute data from the second data to the power management module. The static attribute data includes any one of the battery's cutoff voltage, cutoff current, and charging current. Optionally, in this embodiment, the battery's static attribute data is also reported through nodes. When reporting values ​​in a node, the same attribute data obtained from the data_buffer in the charging control thread is used. For example, when the static attribute data includes the battery's cutoff voltage, when the first processor obtains and reports the battery's cutoff voltage, it obtains the battery's cutoff voltage from the charging data obtained from the charging control thread, thus avoiding directly waking up the ADSP and reducing the number of times the ADSP needs to be woken up.

[0095] Step 408: The battery management module adjusts the target display information based on the status change information.

[0096] Optionally, the battery management module adjusts the corresponding target display information in the user interface (UI) based on the status change information. For example, if the status change information is a change in the battery percentage, the battery management module can adjust the battery percentage displayed in the user interface accordingly. For instance, if the battery percentage changes from 22.34% to 22.35%, the battery management module can adjust the battery percentage displayed in the UI to change from 22.34% to 22.35%. Optionally, the target display information can also be other charging data, which will not be elaborated here.

[0097] Step 409: The first processor detects the transmission success flag value, which is used to indicate whether the first processor has successfully acquired each charging data in the second data.

[0098] Optionally, in this application, since the GLINK message type set is a message type that requires a response, after step 402 above, it is also possible to determine whether the transmission success flag value rc has been received. If the transmission success flag value rc = 0, it means that the first processor has successfully obtained each charging data in the second data; otherwise, it means that the first processor has failed to successfully obtain each charging data in the second data.

[0099] Step 410: When the transmission success flag indicates that the first processor has successfully obtained each charging data in the second data, the first processor ends the process of obtaining each charging data.

[0100] That is, when rc = 0, the process of acquiring each charging data ends; when rc is not equal to 0, a timeout mechanism is used to wait for rc to become 0. For example, if there is a problem with the GLINK communication link, or the ADSP takes too long to prepare the data, the GLINK interrupt may not be sent to the first processor for a long time, causing the first processor to enter the timeout mechanism. Within the timeout mechanism, this application reserves 500 milliseconds. If rc becomes 0 within 500 milliseconds, the process of acquiring each charging data ends.

[0101] In summary, the terminal device includes a first processor running an operating system and a second processor controlling the charging function. The first processor writes first data, containing one or more charging data types it needs to acquire, into a shared memory shared by the first and second processors, and sends a first trigger signal to the second processor. The second processor retrieves the first data from the shared memory based on the first trigger signal, acquires charging data matching each charging data type based on the first data, and generates second data based on the charging data. The second processor also writes the second data into the shared memory and sends a second trigger signal to the first processor. The first processor retrieves the second data from the shared memory based on the second trigger signal and obtains the charging data based on the second data. During the charging process, when the first processor needs to use charging data, it directly acquires the second data from the shared memory all at once, without waking up the second processor for each type of charging data acquired, thus reducing the number of times the second processor is woken up and reducing wasted power consumption during the charging process.

[0102] In addition, this application embodiment reports the status change information to the battery management module through a preset reporting method. The battery management module adjusts the target display information according to the status change information. The preset reporting method is conditional reporting, which reduces the number of times status change information is reported, conforms to the actual reporting situation, and improves the adaptability of charging control.

[0103] In addition, the status change information in this application embodiment carries a source identifier. By detecting whether the source identifier is a Universal Serial Bus (USB) identifier, when the source identifier is a USB identifier, the first processor accesses the charging data corresponding to the USB interface, thereby reducing the number of times the first processor accesses the data node, reducing the number of times the ADSP is woken up, and saving power consumption.

[0104] In one possible implementation, taking the Android system as an example, the function for the aforementioned single-batch data transmission in the terminal device is denoted as oplus_chg_get_props_from_adsp_by_buffer. Please refer to [reference needed]. Figure 5This document illustrates a flowchart of a charging data acquisition method according to an exemplary embodiment of this application. The method is applied in a terminal device, which includes a CPU and an ADSP, such as... Figure 5 As shown, the method includes the following steps:

[0105] Step 501: The CPU starts executing the charging control thread and calls the oplus_chg_get_props_from_adsp_by_buffer function to retrieve the charging data that the CPU needs to obtain from the ADSP all at once.

[0106] Step 502: Detect whether the adapter connected to the ADSP is a fast charging adapter.

[0107] If yes, proceed to step 503; otherwise, proceed to step 504.

[0108] Step 503: Display charging data via animation.

[0109] Step 504 involves reporting logic via power_supply.

[0110] The underlying layer reports an event to the system, which informs the underlying layer that there is information that needs to be updated, and the system begins to read the information from the underlying layer.

[0111] Step 505: Determine which preset condition the terminal device belongs to.

[0112] Optionally, the preset conditions are as described above. Figure 4 The descriptions in the embodiments will not be repeated here.

[0113] Step 506: Report the status change information according to the preset conditions.

[0114] Step 507: The application framework layer receives the state change information.

[0115] Step 508: When the source of the state change information is a USB identifier, access the charging data corresponding to the USB interface.

[0116] Optionally, the execution details in steps 506 to 508 can be referred to the descriptions in steps 406 to 409 above, and will not be repeated here.

[0117] In summary, the terminal device includes a CPU and an ADSP. The CPU executes the charging control thread and acquires the charging data required by the CPU in the ADSP all at once. When the charger is a fast charging adapter, the UI changes are displayed in a timely manner. When reporting status change information in subsequent reports, the reports are made according to preset conditions, which reduces the number of reported status change information, makes the actual reporting situation more consistent, improves the adaptability of charging control, and saves power consumption.

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

[0119] Please refer to Figure 6 This diagram illustrates a structural block diagram of a charging data acquisition device provided in an exemplary embodiment of this application. The charging data acquisition device 600 can be used in the aforementioned terminal device, which includes a first processor and a second processor. The first processor runs an operating system, and the second processor controls the charging function to execute... Figure 3 , Figure 4 ,or Figure 5 The steps in the method provided in the illustrated embodiment are all or part of the steps performed by the terminal device. The charging data acquisition device 600 may include the following modules:

[0120] The first signal sending module 601 is used for the first processor to write first data into the shared memory of the first processor and the second processor, and to send a first trigger signal to the second processor. The first data includes one or more charging data types that the first processor needs to acquire.

[0121] The first data generation module 602 is used for the second processor to obtain the first data from the shared memory according to the first trigger signal, obtain charging data matching each of the charging data types according to the first data, and generate second data according to the charging data;

[0122] The second signal sending module 603 is used for the second processor to write the second data into the shared memory and send a second trigger signal to the first processor;

[0123] The charging data acquisition module 604 is used by the first processor to acquire the second data from the shared memory according to the second trigger signal, and to obtain the charging data according to the second data.

[0124] Optionally, the device further includes:

[0125] The second data generation module is used by the first signal sending module 601 to generate first data according to an agreed data format before the first processor writes the first data into the shared memory of the first processor and the second processor and sends the first trigger signal to the second processor. The agreed data format includes at least one of the following fields: communication message type, maximum number of bytes in the data packet, module identifier, signal identifier, and charging data type to be acquired.

[0126] The module identifier is used to represent the identity information of the sending end, and the signal identifier is used to represent the operation performed by the receiving end.

[0127] Optionally, the first data generation module 602 is further used for:

[0128] The second processor parses the first data according to the agreed data format to obtain a first parsing result;

[0129] If the first parsing result contains a target signal identifier, then according to each charging data type contained in the parsing result, charging data matching each charging data type contained in the parsing result is obtained, wherein the target signal identifier is used to characterize the operation of the receiving end to retrieve the data written by the sending end from the shared memory.

[0130] Optionally, the first data generation module 602 is further used for:

[0131] Delete the first data from the shared memory;

[0132] According to the agreed data format, each of the charging data types is packaged with the acquired charging data that matches each of the charging data types to generate the second data.

[0133] Optionally, the charging data acquisition module 604 includes:

[0134] The first parsing unit is used by the first processor to parse the second data according to the agreed data format to obtain a second parsing result;

[0135] The first acquisition unit is configured to, if the second parsing result contains the target signal identifier, acquire the charging data in the second data that matches each of the charging data types in the second data.

[0136] Optionally, the device further includes:

[0137] The first detection module is used to detect a transmission success flag value after the first processor writes the first data into the shared memory of the first processor and the second processor. The transmission success flag value is used to indicate whether the first processor has successfully obtained each of the charging data in the second data.

[0138] The process termination module is used to terminate the process of acquiring each charging data when the transmission success flag value indicates that the first processor has successfully acquired each of the charging data in the second data.

[0139] Optionally, the device further includes:

[0140] The status information generation module is used to determine the battery status of the battery after the first processor obtains the charging data from the shared memory according to the second trigger signal. If a change in the battery status is detected, status change information is generated to indicate that the battery status of the terminal has changed.

[0141] The information reporting module is used by the first processor to report the status change information to the battery management module according to a preset reporting method.

[0142] An information adjustment module is used by the battery management module to adjust the target display information according to the status change information.

[0143] Optionally, the preset reporting method includes any one of the following:

[0144] When the terminal device is electrically connected to the charger, it periodically reports the status change information to the battery management module at a first time interval.

[0145] When the battery level of the terminal device changes, the status change information is reported to the battery management module;

[0146] When the terminal device disconnects from the charger, it reports the status change information to the battery management module.

[0147] The state change information is reported to the battery management module periodically according to a second time interval, where the second time interval is longer than the first time interval.

[0148] Optionally, the status change information carries a source identifier, and the device further includes:

[0149] The second detection module is used to detect whether the source identifier is a Universal Serial Bus (USB) identifier after the first processor reports the state change information to the battery management module according to a preset reporting method.

[0150] The first access module is configured to allow the first processor to access the second processor to obtain charging data corresponding to the USB interface when the source identifier is the USB identifier.

[0151] Optionally, the device further includes:

[0152] The static data acquisition module is used to, after the first processor reports the state change information to the battery management module according to a preset reporting method, when the power management module needs to obtain the static attribute data corresponding to the battery, the first processor reports the static attribute data in the second data to the power management module. The static attribute data includes any one of the battery's cutoff voltage, cutoff current, and charging current.

[0153] In summary, the terminal device includes a first processor running an operating system and a second processor controlling the charging function. The first processor writes first data, containing one or more charging data types it needs to acquire, into a shared memory shared by the first and second processors, and sends a first trigger signal to the second processor. The second processor retrieves the first data from the shared memory based on the first trigger signal, acquires charging data matching each charging data type based on the first data, and generates second data based on the charging data. The second processor also writes the second data into the shared memory and sends a second trigger signal to the first processor. The first processor retrieves the second data from the shared memory based on the second trigger signal and obtains the charging data based on the second data. During the charging process, when the first processor needs to use charging data, it directly acquires the second data from the shared memory all at once, without waking up the second processor for each type of charging data acquired, thus reducing the number of times the second processor is woken up and reducing wasted power consumption during the charging process.

[0154] Figure 7 This is a schematic diagram of the structure of a terminal device provided in an exemplary embodiment of this application. For example... Figure 7 As shown, the terminal device 700 includes a Central Processing Unit (CPU) 701, a system memory 704 including Random Access Memory (RAM) 702 and Read Only Memory (ROM) 703, and a system bus 705 connecting the system memory 704 and the CPU 701. The terminal device 700 also includes a Basic Input / Output System (I / O System) 708 to facilitate information transfer between various devices within the computer, and a mass storage device 707 for storing the operating system 712, application programs 713, and other program modules 714.

[0155] The basic input / output system 706 includes a display 708 for displaying information and an input device 709 for user input, such as a mouse or keyboard. Both the display 708 and the input device 709 are connected to the central processing unit 701 via an input / output controller 710 connected to the system bus 705. The basic input / output system 706 may also include the input / output controller 710 for receiving and processing input from multiple other devices such as a keyboard, mouse, or electronic stylus. Similarly, the input / output controller 710 also provides output to a display screen, printer, or other types of output devices.

[0156] The mass storage device 707 is connected to the central processing unit 701 via a mass storage controller (not shown) connected to the system bus 705. The mass storage device 707 and its associated computer-readable media provide non-volatile storage for the terminal device 700. That is, the mass storage device 707 may include computer-readable media (not shown) such as a hard disk or a CD-ROM (Compact Disc Read-Only Memory) drive.

[0157] The computer-readable medium may include computer storage media and communication media. Computer storage media include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include RAM, ROM, EPROM (Erasable Programmable Read Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other solid-state storage technologies, CD-ROM, DVD (Digital Video Disc) or other optical storage, magnetic tape cassettes, magnetic tape, disk storage, or other magnetic storage devices. Of course, those skilled in the art will recognize that the computer storage media are not limited to the above-mentioned types. The system memory 704 and the mass storage device 707 described above can be collectively referred to as memory.

[0158] Terminal device 700 can be connected to the Internet or other network devices via network interface unit 711 connected to the system bus 705.

[0159] The memory also includes one or more programs stored in the memory. The central processing unit 701 executes the one or more programs to implement all or part of the steps performed by the terminal device in the methods provided in the above embodiments of this application.

[0160] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0161] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., Digital Video Disc (DVD)), or a semiconductor medium (e.g., Solid State Disk (SSD)).

[0162] It should be noted that the steps performed by the pixel module and the terminal in the charging data acquisition method provided in the above embodiments are only illustrative examples. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the device and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0163] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable storage medium or transmitted as one or more instructions or code on a computer-readable storage medium. Computer-readable storage media include computer storage media and communication media, wherein communication media include any medium that facilitates the transmission of a computer program from one place to another. Storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0164] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for acquiring charging data, characterized in that, Applied to a terminal device, the terminal device including a first processor and a second processor, the first processor being used to run an operating system, and the second processor being used to control a charging function, the method includes: The first processor writes first data into the shared memory of the first processor and the second processor, and sends a first trigger signal to the second processor. The first data includes one or more charging data types that the first processor needs to acquire. The second processor retrieves the first data from the shared memory according to the first trigger signal, retrieves charging data matching each of the charging data types according to the first data, and generates second data according to the charging data; The second processor writes the second data into the shared memory and sends a second trigger signal to the first processor; The first processor retrieves the second data from the shared memory based on the second trigger signal, and obtains the charging data based on the second data.

2. The method according to claim 1, characterized in that, Before the first processor writes the first data into the shared memory of the first processor and the second processor, and sends the first trigger signal to the second processor, the method further includes: The first processor generates first data according to an agreed data format, which includes at least one field among: communication message type, maximum number of bytes in data packet and module identifier, signal identifier and charging data type to be acquired; The module identifier is used to represent the identity information of the sending end, and the signal identifier is used to represent the operation performed by the receiving end.

3. The method according to claim 2, characterized in that, The step of obtaining charging data matching each of the charging data types based on the first data includes: The second processor parses the first data according to the agreed data format to obtain a first parsing result; If the first parsing result contains a target signal identifier, then according to each charging data type contained in the first parsing result, charging data matching each charging data type contained in the parsing result is obtained, wherein the target signal identifier is used to characterize the operation of the receiving end to retrieve the data written by the sending end from the shared memory.

4. The method according to claim 2, characterized in that, The step of generating second data based on the charging data includes: Delete the first data from the shared memory; According to the agreed data format, each of the charging data types is packaged with the acquired charging data that matches each of the charging data types to generate the second data.

5. The method according to claim 4, characterized in that, The first processor retrieves the charging data from the shared memory according to the second trigger signal, including: The first processor parses the second data according to the agreed data format to obtain a second parsing result; If the second parsing result contains a target signal identifier, then according to each of the charging data types in the second data, obtain the charging data in the second data that matches each of the charging data types.

6. The method according to claim 1, characterized in that, After the first processor writes the first data into the shared memory of the first processor and the second processor, the method further includes: The first processor detects a transmission success flag value, which indicates whether the first processor has successfully acquired each of the charging data in the second data. When the transmission success flag indicates that the first processor has successfully acquired each of the charging data in the second data, the first processor ends the process of acquiring each of the charging data.

7. The method according to any one of claims 1 to 6, characterized in that, After the first processor retrieves the charging data from the shared memory according to the second trigger signal, the process further includes: The first processor determines the battery state of the battery. If a change in the battery state is detected, it generates state change information, which is used to indicate that the battery state of the terminal has changed. The first processor reports the status change information to the battery management module according to a preset reporting method; The battery management module adjusts the target display information based on the status change information.

8. The method according to claim 7, characterized in that, The preset reporting method includes any one of the following: When the terminal device is electrically connected to the charger, it periodically reports the status change information to the battery management module at a first time interval. When the battery level of the terminal device changes, the status change information is reported to the battery management module; When the terminal device disconnects from the charger, it reports the status change information to the battery management module. The state change information is reported to the battery management module periodically according to a second time interval, where the second time interval is longer than the first time interval.

9. The method according to claim 7, characterized in that, The status change information carries a source identifier. After the first processor reports the status change information to the battery management module according to a preset reporting method, the following is also included: The first processor detects whether the source identifier is a Universal Serial Bus (USB) identifier; When the source identifier is the USB identifier, the first processor accesses the second processor to obtain charging data corresponding to the USB interface.

10. The method according to claim 7, characterized in that, After the first processor reports the state change information to the battery management module according to a preset reporting method, the method further includes: When the battery management module needs to obtain the static attribute data corresponding to the battery, the first processor reports the static attribute data in the second data to the battery management module; the static attribute data includes any one of the battery's cutoff voltage, cutoff current, and charging current.

11. A charging data acquisition device, characterized in that, Applied to a terminal device, the terminal device including a first processor and a second processor, the first processor being used to run an operating system, and the second processor being used to control a charging function, the device comprising: The first signal sending module is used for the first processor to write first data into the shared memory of the first processor and the second processor, and to send a first trigger signal to the second processor. The first data includes one or more charging data types that the first processor needs to acquire. The first data generation module is used by the second processor to obtain the first data from the shared memory according to the first trigger signal, obtain charging data matching each of the charging data types according to the first data, and generate second data according to the charging data. The second signal sending module is used for the second processor to write the second data into the shared memory and to send a second trigger signal to the first processor; A charging data acquisition module is used by the first processor to acquire the second data from the shared memory according to the second trigger signal, and to obtain the charging data based on the second data.

12. A terminal device, characterized in that, The device includes a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor causes the processor to implement the charging data acquisition method as described in any one of claims 1 to 10.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the charging data acquisition method as described in any one of claims 1 to 10.

Images