Data transmission method and terminal

Abstract

The embodiments of the present application provide a data transmission method and a terminal. In the method, an aggregation and parsing chip is added between a system-on-chip and a low-speed slave device of a terminal, wherein the aggregation and parsing chip serves as a bridge for mounting the low-speed slave device to a high-speed bus, data in the system-on-chip to be transmitted to the low-speed slave device is first transmitted to the aggregation and parsing chip on the high-speed bus by means of a high-speed master device located in the system-on-chip, and then parsed by means of the aggregation and parsing chip and then transmitted to the low-speed slave device. This allows data to be transmitted at a lower rate between the low-speed slave device and the aggregation and parsing chip, while still maintaining high-speed data transmission between the high-speed master device and the aggregation and parsing chip. This enables increased efficiency when high-speed master devices transmit data to low-speed slave devices.

Description

Data transmission methods and terminals

[0001] This application claims priority to Chinese Patent Application No. 202411906945.X, filed on December 20, 2024, entitled "Data Transmission Method and Terminal", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of terminal and chip technology, and in particular to data transmission methods and terminals. Background Technology

[0003] The system-on-a-chip (SoC) of a terminal integrates a variety of computing and control function modules, which may include processing units such as application processor (AP), modem processor, graphics processing unit (GPU), and image signal processor (ISP).

[0004] A System-on-a-Chip (SoC) can transmit data with devices outside the SoC (referred to as external devices) based on communication components. These communication components include communication interfaces. There are various types of communication interfaces to meet specific communication needs, enabling the SoC to transmit data with external devices (such as sensors, displays, etc.). Common communication interfaces include inter-integrated circuit (I2C) interfaces and general-purpose input / output (GPIO) interfaces.

[0005] How to reasonably realize data transmission between the SoC and external devices is a question worth discussing. Summary of the Invention

[0006] This application provides a data transmission method and terminal for reasonably realizing data transmission between the SoC and external devices.

[0007] In a first aspect, this application provides a data transmission method, characterized in that it is applied to a terminal, the terminal having a system-on-a-chip (SoC) and peripheral chips. The SoC is connected to a high-speed bus via a high-speed master device, and the peripheral chips are connected to the high-speed bus via a high-speed slave device. The peripheral chips also include at least one low-speed master device, different low-speed master devices are connected to different low-speed buses, and at least one low-speed slave device is also connected to the low-speed bus to which one low-speed master device is connected. The data transmission rate on the high-speed bus is greater than the data transmission rate on the low-speed bus. The method includes: transmitting data through the high-speed... The master device sends first data to the peripheral chip on the high-speed bus, the first data being generated in the system-on-a-chip; the high-speed slave device receives the first data from the high-speed bus through the peripheral chip; the peripheral chip is controlled to parse the first data to obtain at least a first command, a first interface identifier for transmitting the first command, and first configuration information carried in the first data; the first command and the first configuration information are obtained through a first low-speed master device, the first low-speed master device being determined based on the first interface identifier; the first command is transmitted to the low-speed slave device on the first low-speed bus through the first low-speed master device according to the first configuration information.

[0008] In the above embodiments, the peripheral chip can be the aggregation parsing chip mentioned in the specification, and the first device can be an example of an external device mentioned in the specification. An aggregation parsing chip is added between the terminal's system-on-a-chip (SoC) and the low-speed slave device. This aggregation parsing chip can act as a bridge connecting the low-speed slave device to the high-speed bus. The first data that needs to be transmitted from the SoC to the low-speed slave device is first transmitted to the high-speed bus through the high-speed master device in the SoC, and then parsed by the aggregation parsing chip before being transmitted to the low-speed slave device. While allowing lower data transmission rates between the low-speed slave device and the aggregation parsing chip, a higher data transmission rate is still maintained between the high-speed master device and the aggregation parsing chip, improving the efficiency of data transmission from the high-speed master device to the low-speed slave device.

[0009] In conjunction with the first aspect, in some embodiments, the content obtained by the peripheral chip from parsing the first data also includes a second command carried in the first data, a second interface identifier for transmitting the second command, and second configuration information. The method further includes: obtaining the second command and the second configuration information through a second low-speed master device, the second low-speed master device being determined based on the second interface identifier; and transmitting the second command to a low-speed slave device on a second low-speed bus according to the second configuration information through the second low-speed master device.

[0010] In the above embodiments, a first data set aggregating multiple commands and their related information is allowed to be transmitted on the high-speed bus, and then parsed at the aggregation and parsing chip. Then, different commands are transmitted through their corresponding low-speed master devices, allowing multiple different commands to be transmitted simultaneously. This improves communication efficiency.

[0011] In conjunction with the first aspect, in some embodiments, the peripheral chip includes a transmit buffer connected to a low-speed master device, wherein different low-speed master devices are connected to different transmit buffers. It also includes a register mapping module that controls the peripheral chip to parse the first data. Specifically, this includes: determining a first low-speed master device through the high-speed slave device according to the first interface identifier; the first low-speed master device and the first interface identifier having a first mapping relationship; the first mapping relationship being recorded in the register mapping module; feeding back the first transmit buffer identifier of the first low-speed master device to the high-speed master device through the high-speed slave device; sending a third command to the high-speed slave device through the high-speed master device; the third command being used to write the first command and its configuration information into the transmit buffer connected to the first low-speed master device through the high-speed slave device; and obtaining the first command and its configuration information through the first low-speed master device specifically includes: reading the first command and its configuration information from the connected transmit buffer through the first low-speed master device.

[0012] In the above embodiments, since the data transmission rate of the high-speed master device on the high-speed bus is higher than that of the low-speed master device on the low-speed bus, there is a certain rate difference. Setting up a transmission buffer can help the low-speed master device cache the data to be transmitted and avoid data loss due to the rate difference.

[0013] In conjunction with the first aspect, in some embodiments, after the high-speed slave device feeds back the first transmit buffer identifier of the first low-speed master device to the high-speed master device, the method further includes: sending a fourth command to the high-speed slave device through the high-speed master device, the fourth command being used to obtain the remaining space of the transmit buffer indicated by the first transmit buffer identifier through the high-speed slave device; and sending a third command to the high-speed slave device through the high-speed master device, specifically including: sending the third command to the high-speed slave device through the high-speed master device when the remaining space is greater than a preset threshold.

[0014] In the above embodiments, data is written to the sending buffer only when there is remaining space, which can avoid data loss.

[0015] In conjunction with the first aspect, in some embodiments, the method further includes: sending first interrupt information and description information of the first interrupt information to the high-speed master device through the first high-speed slave device, the first interrupt information being generated by the first low-speed master device and used to provide feedback on: the first low-speed master device transmitting a first command to the low-speed slave device on the first low-speed bus according to the first configuration information; and processing the first interrupt information through the system-on-a-chip where the high-speed master device is located.

[0016] In the above embodiments, it is supported to use a low-speed master device to transmit interrupt information to a high-speed master device through a high-speed bus, without the need to set up an additional INT line for transmitting interrupt information.

[0017] In conjunction with the first aspect, in some embodiments, the system-on-a-chip also runs an interrupt handling module, which processes the first interrupt information through the system-on-a-chip where the high-speed master device resides. Specifically, this includes: reporting the first interrupt information and its description to the interrupt handling module through the high-speed master device; analyzing the interrupt type of the first interrupt information through the interrupt handling module; and, if the interrupt type of the first interrupt information indicates that the first command transmission has failed, sending a fifth command to the high-speed master device through the interrupt handling module. The fifth command carries the interface identifier of the first low-speed master device, and is used to control the first low-speed master device to retransmit the first command through the high-speed master device. The interface identifier carried in the fifth command is determined based on the description information of the first interrupt information.

[0018] In the above embodiments, the interrupt handling module includes a mechanism for processing interrupt information (generated by the low-speed master device), and the high-speed master device can respond to the interrupt information to notify the low-speed master device to resend, thereby increasing the probability of successful data transmission.

[0019] In conjunction with the first aspect, in some embodiments, the peripheral chip includes a receive buffer connected to a low-speed master device. Different low-speed master devices are connected to different receive buffers. When the first command is a read command, the method further includes: reading second data from the first low-speed slave device on the low-speed bus via the first low-speed master device; recording the second data and its description information in the first receive buffer connected to the first low-speed master device via the first low-speed master device; sending second interrupt information and its description information to the high-speed master device via the first high-speed slave device. The second interrupt information is generated by the first low-speed master device and is used to provide feedback on the first low-speed master device's reading of the second data; and processing the second interrupt information via the system-on-a-chip where the high-speed master device resides.

[0020] In the above embodiments, the second data is transmitted serially from the low-speed slave device to the receive buffer in the aggregation parsing chip via the low-speed bus. Since the transmission speed on the low-speed bus is relatively slow, it takes a certain amount of time for all the second data to be transmitted to the receive buffer. Therefore, the receive buffer serves as a temporary buffer. Before all the second data is transmitted to the receive buffer, other data can be transmitted on the high-speed bus, increasing transmission efficiency.

[0021] In conjunction with the first aspect, in some embodiments, the second interrupt information is processed by the system-on-a-chip (SoC) where the high-speed main device resides, specifically including: the high-speed main device reporting the second interrupt information and its description to the interrupt processing module; the interrupt processing module analyzing the interrupt type of the second interrupt information; if the interrupt type of the second interrupt information indicates that the first command was executed successfully and the first low-speed main device has completed data reading, the interrupt processing module sending a sixth command to the high-speed main device, the sixth command carrying the identifier of the first receive buffer, the sixth command being used to read the second data and its description from the first receive buffer by the high-speed main device; the identifier of the first receive buffer carried in the sixth command being determined based on the description of the second interrupt information; and the description of the second data being used by the SoC where the high-speed main device resides to process the second data.

[0022] In the above embodiment, the second data is transmitted serially from the low-speed slave device to the receive buffer in the aggregation parsing chip via the low-speed bus. Since the transmission speed on the low-speed bus is slow, it takes a certain amount of time for all the second data to be transmitted to the receive buffer, which serves as a temporary buffer. Once all the second data has arrived in the receive buffer, a second interrupt message is sent to the upper layer (interrupt handling module) to notify that the second data has been completely read from the low-speed slave device. Then, the upper layer sequentially reads the second data from the read buffer via the high-speed master device. The high-speed master device uses the high-speed bus for faster data transmission. This ensures the integrity of the second data while utilizing the fast transmission speed of the high-speed bus.

[0023] In conjunction with the first aspect, in some embodiments, the peripheral chip further includes at least one expansion interface, and the first data also carries a seventh command, a third interface identifier for transmitting the seventh command, and third configuration information. The method further includes: determining a first expansion interface through the high-speed slave device according to the third interface identifier, wherein the identifier of the first expansion interface and the third interface identifier have a second mapping relationship, and the second mapping relationship is recorded in the register mapping module; controlling the first expansion interface to transmit the seventh command through the high-speed slave device according to the third configuration information; the seventh command is transmitted to the device connected to the first expansion interface, and the first expansion interface and the device are connected through a non-bus type connection line.

[0024] In the above embodiments, the aforementioned low-speed master device implements data transmission through a bus-type communication interface. Here, the extended interface is a non-bus-type communication interface, indicating that the aggregation parsing chip has a variety of communication interface types, enabling various types of data transmission.

[0025] In conjunction with the first aspect, in some embodiments, the data transmission rate on the high-speed bus is greater than the data transmission rate on the non-bus-type connection line.

[0026] In conjunction with the first aspect, in some embodiments, the communication protocols used when transmitting data on the high-speed bus include the Improved Integrated Circuit Interconnect (I3C) protocol or the System Power Management Interface (SPMI) protocol.

[0027] In conjunction with the first aspect, in some embodiments, the communication protocol used when transmitting data on the low-speed bus includes the integrated circuit I2C protocol.

[0028] In conjunction with the first aspect, in some embodiments, the extended interface includes at least one of a general purpose input / output (GPIO) interface and an analog-to-digital converter (ADC) interface.

[0029] In a second aspect, embodiments of this application provide a terminal, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the terminal to perform the method implemented in the first aspect.

[0030] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a terminal, cause the terminal to perform the method as implemented in the first aspect.

[0031] Fourthly, embodiments of this application provide a chip system applied to a terminal. The chip system includes one or more processors, which are used to invoke computer instructions to cause the terminal to perform the method as implemented in the first aspect.

[0032] Fifthly, embodiments of this application provide a computer program product containing instructions that, when run on a terminal, cause the terminal to execute the method as implemented in the first aspect.

[0033] It is understood that the terminal provided in the second aspect, the computer storage medium provided in the third aspect, the chip system provided in the fourth aspect, and the computer program product provided in the fifth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, other beneficial effects that can be achieved can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0034] Figure 1 illustrates an exemplary connection architecture diagram involving data transmission between the SoC in the terminal and external devices.

[0035] Figure 2 illustrates another exemplary connection architecture diagram involved in data transmission between the SoC in the terminal and external devices;

[0036] Figure 3 illustrates another exemplary connection architecture diagram involved in data transmission between the SoC in the terminal and external devices;

[0037] Figure 4 shows a comparative diagram of data transmission under different connection architectures;

[0038] Figure 5 illustrates a usage scenario of the data transmission method in an embodiment of this application;

[0039] Figure 6 shows another comparative diagram involving data transmission under different connection architectures;

[0040] Figure 7 shows an exemplary system structure block diagram for implementing the data transmission method in the embodiments of this application;

[0041] Figure 8 illustrates the interaction between modules in the system when data is transferred from external devices to the SoC;

[0042] Figure 9 shows a schematic diagram of the internal structure of the aggregation parsing chip;

[0043] Figure 10 shows another internal structure diagram of the aggregation parsing chip;

[0044] Figure 11 shows an exemplary flowchart of a terminal sending commands to external devices based on a aggregation parsing chip;

[0045] Figure 12 shows an exemplary flowchart of a terminal reading data from an external device based on a aggregation parsing chip;

[0046] Figure 13 is a schematic diagram of the structure of the terminal provided in the embodiment of this application. Detailed Implementation

[0047] Figure 1 illustrates an exemplary connection architecture for data transmission between a System-on-a-Chip (SoC) in a terminal and external devices. Figure 1 uses a foldable screen device as an example. The terminal shown in Figure 1 includes a main board, a sub-board, and a flexible printed circuit (FPC), denoted as FPC1, coupled between the main board and the sub-board. The SoC, with multiple communication interfaces, is located on the main board. Each communication interface on the SoC typically has at least one matching communication interface on an external device. The terminal can transmit data with external devices on the sub-board through the communication interfaces on the SoC. This includes: the terminal transmitting data through the SoC to a route (referred to as a connection line) connected to the communication interface on the SoC, and then transmitting the data through this connection line to the matching communication interface on the external device, thereby achieving data transmission between the SoC and the external device; and / or, the external device transmitting data to a connection line connected to its communication interface, and then transmitting the data through this connection line to the matching communication interface on the SoC, thereby achieving data transmission between the external device and the SoC.

[0048] Referring again to Figure 1, the connection line for data transmission originates from the SoC's communication interface, connects to FPC1 via a connector on the motherboard side, then connects from FPC1 to a connector on the sub-board side, and finally connects to a matching communication interface on an external device via a connector on the sub-board side. The connectors mentioned in this embodiment may include board-to-board connectors.

[0049] To meet the communication needs with multiple external devices in different application scenarios, a System-on-Chips (SoC) typically has many communication interfaces. Consequently, the number of connecting lines required on the Functional Printed Circuit (FPC) (referring to FPC1) also increases. This necessitates increasing the number of pins on the FPC to enhance the signal transmission capacity. Furthermore, the placement of different connecting lines on the FPC usually does not overlap. Therefore, the more communication interfaces on the SoC, the wider the required FPC becomes. This includes situations where, given a fixed width for a single FPC, more FPCs are needed, or, given a fixed number of FPCs, a wider individual FPC is required. This ensures that the connecting lines are properly positioned on the FPC, enabling data transmission between the SoC and external devices.

[0050] Based on the aforementioned content, it can be seen that the arrangement is consistent with that of FPC: when there are many communication interfaces on the SoC, a large number of connection lines also need to be arranged on the connectors (including connectors on the motherboard side and connectors on the sub-board side). When the number of connectors is fixed, a larger connector is required, or when the connector volume is fixed, a greater number of connectors is required.

[0051] It's important to note that the communication interfaces on a SoC can include bus-type communication interfaces, non-bus-type communication interfaces, or interfaces that can function as both. A bus-type interface is an interface that communicates based on a bus (a type of connection line). At least one master device and one slave device are located on the bus, connected to it via their respective bus-type interfaces to facilitate data transfer between them. The master device is responsible for issuing commands and determining which slave device should respond. A non-bus-type communication interface, on the other hand, does not have a master or slave device on its connection line (the non-bus connection line); it's a point-to-point connection (a non-bus-type communication interface matching that non-bus-type communication interface).

[0052] As shown in Figure 1, non-bus-type communication interfaces may include: general-purpose input / output (GPIO) interfaces (e.g., GPIO1, GPIO2) and analog-to-digital converter (ADC) interfaces (e.g., ADC1, ADC2). Bus-type interfaces may include: interfaces in an I2C master device (e.g., I2Cmaster1), serial peripheral interface (SPI) interfaces, and mobile industry processor interface (MIPI). Interfaces that can function as both bus-type and non-bus-type communication interfaces include: integrated circuit sound (I2S) interfaces and subscriber identity module (SIM) interfaces, etc.

[0053] Referring again to Figure 1, each communication interface in the SoC has a matching communication interface on an external device. For example, GPIO1, GPIO2, ADC1, and ADC2 in the SoC are matched with GPIO11, GPIO12, ADC11, and ADC12 on the external device, respectively. The interface in I2Cmaster1 matches the interfaces in I2Cslave11 and I2Cslave12. Matching two interfaces means that there is a connection line between the two interfaces for data transmission, enabling data transfer.

[0054] To reduce the number of signals transmitted by the FPC and connectors, and thus reduce the usage of FPCs and connectors, in some possible implementations, as shown in Figure 2, taking a device with a foldable screen as an example, a bare die (die 1 and die 2) can be added to both the motherboard and the sub-board. One die is used to convert the multiple data streams (from the SoC or external devices) received by the multiple low-speed communication interfaces on the die into a single high-speed differential signal. This high-speed differential signal is then transmitted through the connection line connected to the high-speed communication interface (denoted as high-speed communication interface 1) to one of the connectors (the connector closer to the die), and then sent to the FPC (e.g., FPC1). The terminal then transmits this high-speed differential signal through the FPC to the high-speed communication interface (denoted as high-speed communication interface 2) on the other die, which matches high-speed communication interface 1. The other die is used to recover multiple data streams from the high-speed differential signal, and then transmits these multiple data streams to the matching low-speed communication interfaces on the external device or SoC through the multiple low-speed communication interfaces on this other die. It should be noted that if the multiple data streams received on one of the aforementioned dies originate from the SoC, then the other die will transmit those multiple data streams to an external device.

[0055] Referring again to Figure 2, the aforementioned high-speed communication interface 1 and high-speed communication interface 2 can be peripheral component interconnect express (PCIe) interfaces. Besides PCIe interfaces, high-speed communication interfaces 1 and 2 can also be low-voltage differential signaling (LVDS) interfaces or serial deserializer (serDes) interfaces, etc.

[0056] As shown in Figure 2, the low-speed communication interfaces on the SoC that enable data transmission via high-speed communication interface 1 include, but are not limited to: GPIO interface, SPI interface, interface in I2C master (I2C interface), I2S interface, MIPI interface, etc. The die 2 contains low-speed communication interfaces that match each low-speed communication interface, including GPIO0, SPI0, interfaces in I2Cslave01 and I2Cslave02, I2S0, MIPI0, etc. The die 1 also contains low-speed communication interfaces that match each low-speed communication interface, including GPIO1, SPI1, interfaces in I2C master1, I2S1, MIPI1, etc. External devices also contain low-speed communication interfaces that match each low-speed communication interface, including GPIO11, SPI11, interfaces in I2Cslave11 and I2Cslave12, I2S11, MIPI11, etc. This can also be understood as the GPIO interface on the SoC being matched with GPIO0, GPIO1, and GPIO11 to transmit one channel of data. The matching relationship between other types of communication interfaces is similar to that of the GPIO interface, and will not be elaborated here.

[0057] This section uses the example of data transfer from the SoC to an external device to illustrate the data transmission process. This process includes: the GPIO0-MIPI0 communication interfaces on die 2 can be used to receive data from the matching communication interfaces on the SoC, and then the data is transmitted via communication interface PCIE1 to the matching communication interface PCIE11 on die 1. The process of data transfer from an external device to the SoC can be referred to the aforementioned descriptions, and will not be repeated here.

[0058] It should be noted that the terms "high-speed communication interface" and "low-speed communication interface" are relative. If the data transmission rate of a communication interface is lower than that of the high-speed communication interfaces on die 1 and die 2, it can be called a low-speed communication interface.

[0059] In the scheme shown in Figure 2, multiple signals passing through the connector and FPC1 are converted into a single high-speed differential signal. While this reduces the number of FPCs and connectors used, the scheme in Figure 2 adds two additional chips, die 1 and die 2, resulting in a larger footprint and hindering cost control.

[0060] To reduce the number of signals transmitted by the FPC and connectors, thereby reducing the usage of FPCs and connectors, and to avoid excessive chip footprint and cost increases, a data transmission method is proposed. Referring to Figure 3(1), this method, compared to the scheme shown in Figure 2, introduces only one die (called the aggregation and parsing chip) on the secondary board of the terminal, but does not introduce another die (die 2) on the main board of the terminal. Instead, a software aggregation and parsing module is added to the SoC to aggregate at least one data stream that requires transmission through at least one native communication interface (e.g., native I2C interface, native GPIO interface, etc.) to obtain one communication data stream (communication data 1, generated by the SoC), or to parse one communication data stream (communication data 2, generated by an external device) to obtain at least one data stream that requires transmission through at least one native communication interface. Here, native communication interfaces include communication interfaces that are allowed to be placed on the SoC but are not. In this method, the multiple native communication interfaces (such as native I2C interfaces, native GPIO interfaces, etc.) originally arranged on the SoC in Figure 1 are not arranged on the SoC. Instead, the aforementioned software aggregation and parsing module, high-speed master device (such as I3Cmaster), and aggregation and parsing chip are used. The SoC can be connected to a high-speed bus (a type of connection line) through this high-speed master device. The aggregation and parsing chip is also connected to the high-speed bus through an I3C slave (a type of high-speed slave device) matched with the I3Cmaster. The aggregation and parsing chip may also include multiple communication interfaces (called expansion interfaces), which are used to connect to external devices and perform data transmission with them. The expansion interfaces may include at least one of GPIO interfaces, I2C interfaces, or ADC interfaces. Among them, I3Cmaster can be referred to as the I3C master device.

[0061] In this embodiment, the data transmitted from the SoC to an external device may include commands (e.g., read commands, write commands, or control commands). The data transmitted from the external device to the SoC may include interrupt information, response data to commands, etc.

[0062] This explanation uses expansion interfaces 1 and 2 as an example. The process of the terminal transmitting data to external devices through the SoC includes: the high-speed master device sending communication data 1 to the aggregation parsing chip on the high-speed bus. Based on the aggregation parsing chip, the high-speed slave device receives communication data 1 from the high-speed bus. Then, the terminal parses the communication data 1 through the aggregation parsing chip, obtaining at least command 1, interface identifier 1 for transmitting command 1, and configuration information 1 carried in the communication data 1. The aggregation parsing chip then controls expansion interface 1 to transmit command 1 according to the configuration information 1. This command 1 is transmitted to the external device (external device 1) connected to expansion interface 1, and the external device receives command 1 through a communication interface that matches expansion interface 1. Expansion interface 1 matches interface identifier 1, while expansion interface 2 does not match interface identifier 1. As shown in Figure 3, when the expansion interface 1 is the interface in GPIO1, GPIO2, I2Cmaster1, ADC1, and ADC2, the communication interfaces in the external devices that match the expansion interface 1 are GPIO11 and GPIO12 in the touch device, the interface in I2Cslave11 in the display device, the interface in I2Cslave12 in the sensor device, ADC11 in the sensor device, and ADC12 in the audio device.

[0063] In some possible cases, when the terminal parses communication data 1 through the aggregation parsing chip, the content obtained also includes: command 2 carried in communication data 1, interface identifier 2 used to transmit command 2, and configuration information 2. The terminal can control the expansion interface 2 to transmit command 2 according to the configuration information 2 through the aggregation parsing chip. This command 2 is transmitted to the external device (external device 2) connected to the expansion interface 2. The expansion interface 2 is determined based on the interface identifier 2.

[0064] Interface identifier 1 and interface identifier 2 are determined by the software aggregation parsing module. The determination process and the description of the software aggregation parsing module can be found in the following description of the relevant content in Figure 7, which will not be described here.

[0065] Taking expansion interfaces 1 and 2 as an example, the process of the terminal transmitting data to the SoC through an external device includes: the terminal controlling the aggregation parsing chip to transmit communication data 2 to the high-speed bus through the high-speed slave device. Communication data 2 may include some or all of the following information aggregated by the aggregation parsing chip: response data 1 plus its description, and response data 2 plus its description. Response data 1 is sent to expansion interface 1 in response to command 1 from external device 1. Response data 2 is sent to expansion interface 2 in response to command 2 from external device 2. Then, the terminal controls the high-speed master device to receive communication data 2 from the high-speed bus, and then processes the communication data 2 through the SoC where the high-speed master device resides.

[0066] It should be noted that the aforementioned communication data 1 and communication data 2 are merely illustrative examples, and in practice, other information may be included. For instance, communication data 1 may include more commands. In addition to response data to commands, communication data 2 may include interrupt information, or it may include at least one response data and one interrupt message. Interrupt information includes information actively sent to the SoC by the interface supporting interrupts, and does not need to be generated by responding to commands sent by the SoC. For example, when a user presses a volume control button, the terminal can send an interrupt message to the SoC through the communication interface associated with the volume control button. This interrupt message is used to notify the SoC that a user operation has occurred on the volume control button.

[0067] Referring again to Figure 3(1), the high-speed bus starts from the high-speed master device (e.g., I3C master), connects to FPC1 via the connector on the motherboard side, and then connects from FPC1 to the connector on the slave board side. It then connects to the high-speed slave device (e.g., I3C slave) in the peripheral chip via the connector on the slave board side. Multiple signals passing through the connector and FPC1 are converted into a single signal (a signal used for communication data 1 or communication data 2), which reduces the number of FPCs and connectors used.

[0068] It should be noted that in the embodiments of this application, when the terminal is a device with a foldable screen, the FPC is usually set at the hinge of the foldable screen, and the FPC in this case is a through-hing FPC. For example, the FPC1 shown in Figure 3 (1) above is a through-hing FPC.

[0069] It should also be noted that the terminal shown in Figure 3(1) is a device with a foldable screen. The data transmission method can also be implemented when the terminal is a device with a non-foldable screen. As shown in Figure 3(2), when the terminal is a device with a non-foldable screen, the SoC is also arranged on the motherboard. However, the aggregation parsing chip is arranged on a small board, not a sub-board. The motherboard and the small board are coupled through a flexible printed circuit board (called FPC2). At this time, the high-speed bus starts from the high-speed master device (e.g., I3Cmaster) on the SoC and connects to the high-speed slave device (e.g., I3Cslave) in the aggregation parsing chip through FPC2. Generally speaking, when arranging the sub-board in a terminal with a foldable screen, the mechanical movement and stress during folding need to be considered, while when arranging the small board in a terminal with a non-foldable screen, the mechanical movement and stress during folding do not need to be considered, and only the basic connection and module fixation need to be ensured. Therefore, after using FPC to connect the small board and the motherboard, the motherboard side and the small board side in a terminal with a non-foldable screen do not need to be arranged with board-to-board connectors. After using the data transmission method provided in the embodiments of this application, the amount of FPC used can still be reduced. The arrangement of hardware and software modules involved in implementing the data transmission method in the SoC and aggregation parsing chip shown in Figure 3(2) can be the same as that in Figure 3(1), and will not be repeated here. For example, the SoC shown in Figure 3(2) also has a software aggregation parsing module, and the relevant content of data transmission between the SoC and external devices can be referred to the aforementioned description of the relevant content in Figure 3(1).

[0070] It should be noted that in the data transmission method provided in this application embodiment, the data transmission rate of the high-speed bus between the high-speed master device and the high-speed slave device is greater than the data transmission rate on connection line 1. Here, connection line 1 includes the connection lines between the other communication interfaces (expansion interfaces) in the aggregation parsing chip (excluding the high-speed slave device) and external devices. In this way, the communication data transmitted on the high-speed bus can aggregate the data to be transmitted by more communication interfaces. The data transmission rate on connection line 1 can be affected by the type of communication interface on connection line 1. It can be seen that the type of high-speed master device and high-speed slave device affects the type of expansion interface; different types of high-speed buses result in different types of expansion interfaces that can be included in the aggregation parsing chip.

[0071] The types of high-speed master and high-speed slave devices are determined based on the communication protocol used when transmitting data between them. For example, when the communication protocol between the high-speed master and high-speed slave devices shown in Figure 3 is the I3C communication protocol, both the high-speed master and high-speed slave devices are I3C type devices. The communication interfaces in both the high-speed master and high-speed slave devices are I3C interfaces, and the high-speed bus is an I3C bus. In this case, the expansion interface types on the aggregation parsing chip can include GPIO, I2C, ADC, etc., so that the data transmission rate of the connection line is lower than the data transmission rate of the I3C bus. When the expansion interface types include GPIO, I2C, ADC, etc., in addition to I3C type high-speed master and high-speed slave devices, other types of high-speed master and high-speed slave devices can also meet the requirements. For example, the master device (SPMI master device) and slave device (SPMI slave device) in the System Power Management Interface (SPMI) protocol. In this case, the high-speed bus is an SPMI bus.

[0072] In some possible implementations, the communication protocol between the high-speed master and high-speed slave devices can also use the I2C protocol. In this case, the high-speed master device is called the I2C master, the high-speed slave device is called the I2C slave, and the high-speed bus is the I2C bus. Extended interface types can include GPIO. However, the I2C protocol does not support internal interrupts; that is, data transmitted on the high-speed bus does not include interrupt information actively transmitted from the high-speed slave device to the high-speed master device. If interrupt information needs to be transmitted, an additional INT (interrupt) line needs to be added to the high-speed bus to transmit the interrupt signal. Furthermore, the interrupt information reported by the I2C slave to the I2C master is coarse-grained. This interrupt information only informs the I2C master that an external device has undergone a state change or an event has occurred, but it does not know which external device caused the interrupt. Therefore, the I2C master needs to poll the registers of each external device via the I2C bus to determine which external device's state change caused the interrupt. This polling process can take hundreds of microseconds to several milliseconds, impacting system functionality.

[0073] The I3C and SPMI protocols support in-band interrupts (IBI). This means that data transmission on the high-speed bus between a high-speed master and a high-speed slave device can include interrupt information actively transmitted from the high-speed slave device to the high-speed master device, without the need for an INT line as in the I2C protocol. Furthermore, the I3C and SPMI protocols have improved the interrupt mechanism, eliminating the need for polling by the master device. The interrupt information received by the I3C master and SPMI master from the high-speed slave device carries descriptive information about the interrupt, which can be used to determine which external device caused the interrupt.

[0074] In addition, the high-speed communication interface 1 in die 1 and the high-speed communication interface 2 in die 2 shown in Figure 2 use a high-speed differential bus (a type of connection line) to realize data transmission. The power consumption is relatively high when the two chips transmit data, which affects the battery life of the terminal.

[0075] Figure 4 can be derived by comparing Figures 1 and 3. As shown in Figure 4, the native communication interfaces that are supposed to be located on the SoC (such as the I2C interface, GPIO interface, and ADC interface mentioned in Figure 1) are not located on the SoC, but rather the expansion interfaces corresponding to each native communication interface are located in the aggregation parsing chip. These expansion interfaces replace the native communication interfaces and connect to various external devices (including Device 1, Device 2, etc.), enabling data transmission between the external devices and the SoC. Data transmission between the external devices and the SoC also involves the software aggregation parsing module, a high-speed master device (e.g., I3Cmaster), and high-speed slave devices (e.g., I3Cslave) connected to the high-speed master device via a high-speed bus. The high-speed slave devices, the expansion interfaces, and their related functional logic are encapsulated in the aggregation parsing chip. Because the number of communication interfaces on the SoC is reduced, the size of the SoC can be reduced.

[0076] Figure 5 illustrates a usage example of the data transmission method in this application embodiment. This example can be applied in scenarios where the I3C protocol is compatible with the I2C protocol, solving the problem of reduced communication efficiency caused by I2C protocol compatibility. The I3C protocol maintains compatibility with the I2C protocol while improving performance and functionality. Therefore, the I3C master and the I3C bus can act as the I2C master and the I2C bus, respectively, supporting the I2C slave to act as a slave device of the I3C master, just like the I3C slave. As shown in Figure 5 (1), in this scenario, at least one I3C master and at least one I2C slave and I3C slave can be connected to the I3C bus (including the I3C data and I3C clock lines). The I3C master can control and manage the I2C slave on the I3C bus, realizing data transmission between the I3C master and the I2C slave. However, the data transfer rate when the I3C master acts as an I2C master and transmits data to an I2C slave is still the rate specified in the I2C protocol. Only when the I3C master transmits data to an I3C slave does it use the rates specified in the I3C protocol. Typically, the rates specified in the I3C protocol include: 12.5MHz in single data rate (SDR) mode, 25MHz in double data rate (DDR) mode, and even higher than 25MHz in high data rate (HDR) mode. The rates specified in the I2C protocol typically include: 100K, 400K, and 1MHz. Therefore, the rates specified in the I2C protocol are much lower than those specified in the I3C protocol. Furthermore, the I3C protocol is a serial communication protocol. To avoid signal collisions, only one communication (including command sending and response) is allowed between the I3C master and a single slave device (I3C slave or I2C slave) at a time on the I3C bus. For example, after an I3C master issues a command on the I3C bus, all slave devices on the I3C bus will receive the command, but only the target slave device will respond. The next command must wait for the currently transmitting command to complete its transmission before it can be sent to the I3C bus; otherwise, an error will occur. In this context, using the I3C master as the I2C master to transmit data with I2C slaves on an I3C bus with I2C slaves connected will severely degrade communication efficiency.

[0077] The data transmission method described in this application embodiment can maintain high-speed communication of the I3C protocol while simultaneously enabling communication between the I3C master and I2C slave via the I3C bus. As shown in Figures 5(1) and 5(2), some or all of the I2C slaves connected to the I3C bus and managed by the I3C master in the terminal are coupled to the aggregation parsing chip. The I2C slaves coupled to the aggregation parsing chip are connected to the I2C master in the aggregation parsing chip via the I2C bus (including I2C data lines and I2C clock lines). An I2C master can manage and control at least one I2C slave connected to the same I2C bus as the I2C master. Each I2C master in the aggregation parsing chip can realize data transmission between each I2C slave and the I3C master through the I3C slaves in the aggregation parsing chip.

[0078] The process of data transmission from the I3C master to the I2C slave includes: the terminal sending communication data a to the aggregation parsing chip via the I3C master on the I3C bus (including the I3C data line and the I3C clock line). The I3C slave receives the communication data a via the aggregation parsing chip. The terminal controls the aggregation parsing chip to parse the communication data a, obtaining the command a, the interface identifier a used to transmit the command a, and the configuration information a carried in the communication data a. Then, the terminal obtains the command a and the configuration information a via the target low-speed master device 1. The target low-speed master device 1 then transmits the command a to the I2C slave on the I2C bus it is connected to according to the configuration information a. Here, the configuration information a can be used to specify the I2C slave that responds to the command a. The target low-speed master device 1 is determined based on the interface identifier a. The identifier of the I2C interface in the target low-speed master device 1 is the same as the interface identifier a. As shown in Figure 5 (2), the target low-speed master device 1 can be at least one I2C master in the aggregation parsing chip, such as I2C master1 or I2C master2. The I2C slave can be placed in an external device, while the I3C master is placed on the SoC. This process means that the SoC can transmit data to the external device through the aggregation parsing chip. This can be understood as an implementation method when the extended interface involved in Figure 3 above is the I2C interface in the I2C master.

[0079] Communication data 'a' originates from the SoC and can be obtained by the SoC aggregating at least one data stream that needs to be sent via the native communication interface through a software aggregation and parsing module. Besides the aforementioned command 'a', the interface identifier 'a' used to transmit command 'a', and configuration information 'a', the content obtained during parsing communication data 'a' may also include: the command 'b' carried in communication data 'a', the interface identifier 'b' used to transmit command 'b', and configuration information 'b'. The process of data transmission from the I3C master to the I2C slave also includes: the terminal obtaining command 'b' and configuration information 'b' through the target I2C master 02. Then, the target low-speed master device 2 transmits command 'b' to the I2C slave on its connected I2C bus according to the configuration information 'b'. Here, configuration information 'b' can be used to specify the I2C slave responding to command 'b'. The target low-speed master device 2 is determined based on the interface identifier 'b'. The identifier of the I2C interface in the target low-speed master device 2 is the same as the interface identifier 'b'.

[0080] The process of data transmission from the I2C slave to the I3C master includes: the terminal transmitting communication data b from the I2C slave via the I2C bus to the I2C master on the I2C bus; then, based on the I2C master, the communication data b is transmitted from the I2C slave to the I3C bus, and finally reaches the I3C master. The I2C slave is located in an external device, and the I3C master is located on the SoC. This process means that the external device can transmit data to the SoC through the aggregation and parsing chip. This can be understood as one implementation method when the extended interface involved in Figure 3 is the I2C interface in the I2C master. The communication data b can include data sent by at least one external device to the I3C master via the I2C slave. After the data arrives at the I3C master, the software aggregation and parsing module in the SoC can process the communication data b.

[0081] In some possible cases, different I2C masters can be connected to different I2C buses. Different I2C slaves can be connected to different I2C buses. This allows different I2C masters to manage different I2C slaves, improving management efficiency. For example, the I2C masters shown in Figure 5(2) include I2C master1 and I2C master2. The I2C bus of I2C master1 (referred to as I2C bus 1) includes I2C data line 1 and I2C clock line 1, and at least one I2C slave (e.g., I2C slave11, I2C slave12) can be connected to I2C bus 1. The I2C bus of I2C master2 (referred to as I2C bus 2) includes I2C data line 2 and I2C clock line 2, and at least one I2C slave (e.g., I2C slave21, I2C slave22) can be connected to I2C bus 2.

[0082] As shown in Figure 6, after improving the scenario shown in Figure 5(1) using the example shown in Figure 5(2), the I3C master can quickly transmit command a to an I2C slave on the I3C bus without waiting for the I2C master of that I2C slave to return feedback (an interrupt) regarding the completion of command a transmission. The I3C master can then transmit command b to another I2C slave. After command a and command b arrive at the aggregation parsing chip, they can be cached in the aggregation parsing chip, waiting for the relevant I2C master to obtain them and then transmit them to the I2C bus, and then to the target slave device. Before the improvement, when the method shown in Figure 5(1) is adopted, after transmitting command a to an I2C slave using the I3C bus as the I2C bus, it is necessary to wait for the I2C slave to return feedback (an interrupt) regarding the completion of command a transmission before the I3C master can transmit command b to another I2C slave using the I2C bus. The I3C master only transmits the next command via the I2C bus after waiting for feedback (an interrupt) from the other I2C slave indicating that command 'b' has been transmitted successfully. Therefore, the improved version allows communication between the I3C master and I2C slave via the I3C bus while maintaining high-speed communication of the I3C protocol. This means that external devices with I2C slaves can then achieve high-speed communication with a SoC that has an I3C master. Furthermore, the introduction of the aggregation parsing chip reduces the amount of FPC used in the terminal.

[0083] It should be noted that in the connection architecture shown in Figure 5(2), I3Cmaster can represent a high-speed master device, and I2Cmaster can represent a master device with a lower transmission rate than the high-speed master device (low-speed master device). I3Cmaster can also be extended to other high-speed master devices (e.g., SPMImaster), and I2Cmaster can also be extended to other low-speed slave devices. This application embodiment does not limit this. The slave device connected to the high-speed master device is called a high-speed slave device, and the slave device connected to the low-speed master device is called a low-speed slave device. After the master device changes, the slave device also changes accordingly. For example, after the high-speed master device changes from I3Cmaster to SPMImaster, I3Cslave changes to SPMIslave.

[0084] Figure 7 shows an exemplary system structure block diagram for implementing the data transmission method in the embodiments of this application.

[0085] A layered architecture divides the system into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the system is divided into five layers, from top to bottom: application layer, framework layer, hardware abstraction layer, kernel layer, and hardware layer.

[0086] The application layer can include a series of application packages. As shown in Figure 7, an application package can include applications (also referred to as applications) such as music applications, video applications, and calling applications.

[0087] The framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. The application framework layer includes some predefined functions.

[0088] The Hardware Abstraction Layer (HAL) sits between the framework layer and the kernel layer, bridging the communication between the two layers. For example, this HAL may include touch HAL, display HAL, audio HAL, sensor HAL, charging HAL, and camera HAL, respectively. These HALs are used to translate upper-level commands from the touch framework layer, display framework layer, audio framework layer, sensor framework layer, charging framework layer, and camera framework layer into commands that can be parsed by the corresponding device drivers in the kernel layer. For instance, the touch HAL translates upper-level commands from the touch framework layer into commands that the touch driver can parse.

[0089] The kernel layer is the layer between hardware and software. At a minimum, the kernel layer contains device drivers (also called hardware drivers) for each external device (referred to as a device) to ensure that these external devices function properly. Examples include touch drivers, display drivers, audio drivers, sensor drivers, charging drivers, and camera drivers.

[0090] High-level commands generated by the upper-layer application are transformed layer by layer by relevant modules in the framework layer and HAL layer before being transmitted to the respective device drivers. The device drivers then convert the commands into commands that can control the hardware to execute. For example, when a user clicks the camera control in the camera application, the camera application responds to this click by generating a high-level command for "taking a picture" (which the camera driver cannot parse). This command is then transformed by the camera framework layer in the framework layer and the camera HAL layer in the HAL layer. The camera HAL then transmits the transformed command (which the camera driver can understand) to the camera driver. The camera driver receives the transformed command, controls the camera to take a picture, and then transmits the image data from the camera back to the upper-layer camera application.

[0091] The following describes in detail the process of transmitting commands from the SoC to external devices based on Figure 7.

[0092] When there are many communication interface types in the external device that match the native communication interface on the SoC, each device driver is also used to determine which type of communication interface (the native communication interface on the SoC) the command (the command of the control device) needs to be transmitted to the external device. See Figure 7 (1), the command that needs to be transmitted through the native GPIO communication interface is called the GPIO command, the command that needs to be transmitted through the native I2C communication interface is called the I2C command, and the command that needs to be transmitted through the native ADC communication interface is called the ADC command. Commands that need to be transmitted through other types of native common interfaces can be referred to in this description, and will not be repeated here.

[0093] Then, the commands can be transmitted to the target external device through the kernel-level software aggregation and parsing module. This software aggregation and parsing module is a detailed example of the one mentioned in Figure 3. This module can include drivers for various native interfaces (referred to as native interface drivers), including the GPIO framework core, I2C framework core, and ADC framework core. It can also include corresponding extended interface drivers, such as extended GPIO drivers, extended I2C drivers, and extended ADC drivers. Additionally, it includes an interrupt handling module and high-speed device extension drivers.

[0094] As shown in Figure 7(2), the GPIO framework core, I2C framework core, and ADC framework core in the software aggregation and parsing module are used to select the native communication interface for sending GPIO commands, I2C commands, and ADC commands to external devices, and to generate the configuration information for each native communication interface. For example, the GPIO framework core is used to select the native GPIO interface for sending GPIO commands and to determine the configuration information of the native GPIO interface. The I2C framework core is used to select the native I2C interface for sending I2C commands and to determine the configuration information of the native I2C interface. The ADC framework core is used to select the native ADC interface for sending ADC commands and to determine the configuration information of the native ADC interface.

[0095] It should be noted that selecting the native I2C interface for sending I2C commands means: identifying the specific native I2C interface on the SoC used to send I2C commands and generating an identifier for that native I2C interface. This identifier, along with the configuration information of the native I2C interface and the I2C commands, will be transmitted from the I2C framework core (equivalent to the native I2C driver) to the I2C extension driver. The descriptions of the native GPIO interface selected for sending GPIO commands in the GPIO framework core (equivalent to the native GPIO driver) and the native ADC interface selected for sending ADC commands in the ADC framework core (equivalent to the native ADC driver) are the same as those for selecting the native I2C interface for sending I2C commands; simply replace I2C with GPIO or ADC. Further details are omitted here.

[0096] The configuration information of a native communication interface (such as a native I2C interface, native GPIO interface, native ADC interface, etc.) is used to control the native communication interface to send device commands (such as I2C commands, GPIO commands, ADC commands) to the communication interface (located in the external device) that matches the native communication interface. After the external device responds to the device command, control of the external device is achieved.

[0097] Different types of native communication interfaces have different configuration information: the I2C interface adopts a bus-type communication protocol, requiring the destination device address and destination register address of the command to be included in the native I2C interface configuration information. It also needs to include the I2C bus transmission rate and the command read / write type. The destination device address indicates the target external device responding to the command and specifies which register in the target external device is involved in the command response. The command read / write type indicates whether the I2C command to be transmitted is a read command or a write command. A write command is used to send data or control instructions to the slave device. A read command is used to read data from the slave device. If the master device writes a read command, data can be read from the slave device; therefore, reading data also involves writing a read command, which can be understood as "write before reading (write read command)". A detailed description of this process can be found in Figure 8 below and will not be elaborated here. The configuration information of the native GPIO interface can include information such as the input / output direction of the native GPIO interface. The output is used to control the GPIO interface to send GPIO commands to external devices, including the output type (e.g., push-pull or open-drain). Figure 7 shows the output. Inputs are used to control the GPIO interface to receive signals from external devices, including interrupt triggering methods (such as rising edge triggering interrupt or falling edge triggering interrupt). An ADC interface is a device used to convert analog signals into digital signals. Typically, the configuration information of a native ADC interface can carry sampling parameters that control the ADC interface to convert analog signals into digital signals: conversion accuracy, sampling rate, etc.

[0098] When the native communication interface on the SOC is not omitted, the native interface driver can control the native communication interface to transmit device commands to external devices according to the configuration information to control the external devices. However, as shown in Figure 3 above, in the data transmission method provided in this application embodiment, the native communication interface on the SOC has been omitted, and the actual communication interface for transmitting device commands to external devices is the extended interface in the aggregation parsing chip. Therefore, as shown in Figure 7 (3), the extended interface driver corresponding to each native interface driver is introduced here. It is used to map the native communication interface selected by the native interface driver to the extended interface in the aggregation parsing chip that can send device commands. Because the control methods of different interfaces may be different, it is also necessary to modify the configuration information for the native communication interface to the configuration information for the extended interface in order to control the extended interface to transmit device commands to the target external device. For bus-type communication interfaces such as I2C extended interfaces, the configuration information of the extended interface can also carry a command ID, which is a command identifier (ID) generated by the extended I2C driver based on the I2C command. A command ID corresponding to an I2C command is used to uniquely identify the I2C command. In the event of an I2C command transmission error, the command ID can be carried in the interrupt information so that the interrupt handling module can analyze the erroneous device command. In this embodiment, the command ID is optional. The use of the command ID can be referred to the descriptions of command IDs in Figures 8, 11, and 12 below, which will not be elaborated here.

[0099] For example, an extended GPIO driver can be used to obtain GPIO commands from the GPIO framework core, send GPIO commands to the identifier of the native GPIO interface of an external device, and the configuration information of the native GPIO interface. This extended GPIO driver contains a mapping relationship between the native GPIO interface and extended interface 1. This mapping relationship can be used to determine the extended interface 1 of the native GPIO interface (determine the identifier of extended interface 1) and the configuration information of extended interface 1. The extended GPIO driver is also used to transmit GPIO commands, the identifier of extended interface 1, and the configuration information of extended interface 1 to the high-speed device extended driver.

[0100] The extended I2C driver can be used to obtain I2C commands from the I2C framework core, send I2C commands to external devices, and retrieve the identifier of the native I2C interface, as well as the configuration information (including command ID) of the native I2C interface. This extended I2C driver contains a mapping relationship between the native I2C interface and extended interface 2. This mapping relationship can be used to determine the extended interface 1 of the native I2C interface (determining the identifier of extended interface 1) and the configuration information of extended interface 2. The extended I2C driver is also used to transmit I2C commands, the identifier of extended interface 2, and the configuration information (including command ID) of extended interface 2 to the high-speed device extended driver.

[0101] The extended ADC driver can be used to obtain ADC commands from the ADC framework core, send ADC commands to external devices, and access the identifier and configuration information of the native ADC interface. This extended ADC driver contains a mapping relationship between the native ADC interface and extended interface 3. This mapping relationship can be used to determine the extended interface 3 of the native ADC interface (determine the identifier of extended interface 3) and the configuration information of extended interface 3. The extended ADC driver is also used to transmit ADC commands, the identifier of extended interface 3, and the configuration information of extended interface 3 to the high-speed device extended driver.

[0102] As shown in Figure 7 (4), the high-speed device extension driver is used to aggregate at least one device command and its corresponding related content (such as the extension interface and configuration information for transmitting the device command) to obtain communication data 1. Here, if the high-speed device extension driver receives different device commands and their corresponding related content at the same time, then communication data 1 may include the different device commands and their corresponding related content. If the high-speed device extension driver receives only one device command and its corresponding related content at a time, then communication data 1 may include that device command and its corresponding related content.

[0103] This explanation uses communication data 1, which includes GPIO commands, I2C commands, and ADC commands, along with their corresponding content, as an example.

[0104] The high-speed device extension driver acts as an I3C device, encapsulating communication data (1) into I3C signals and transmitting them to the high-speed device's native driver. This native driver can be understood as the driver for a high-speed master device (e.g., an I3C master), used to send communication data (1) and control commands to the master device. The master device controls its communication interface according to the control commands, enabling the master device to transmit communication data (1) through the aggregation parsing chip on the high-speed bus. Here, the high-speed bus originates from the high-speed master device's communication interface, passes through connectors and other devices, and then transmits the data to the aggregation parsing chip. The data is transmitted to the communication interface of the high-speed slave device within the aggregation parsing chip.

[0105] As shown in Figure 7 (5), the aggregation parsing chip parses the communication data 1 and transmits device commands through the configuration information corresponding to each expansion interface. For example, it transmits GPIO commands to external devices through expansion interface 1, I2C commands to external devices through expansion interface 2, and ADC commands to external devices through expansion interface 3. For details on the device commands transmitted by the aggregation parsing chip, please refer to the descriptions of the relevant content in Figures 9 and 11 below, which will not be described here.

[0106] It should be noted that the aggregation and parsing process of GPIO commands, I2C commands, and ADC commands shown in Figure 7 describes a single GPIO command, a single I2C command, and a single ADC command. In reality, a single aggregation and parsing of device commands can include at least one device command, which can be at least one GPIO command, at least one I2C command, at least one ADC command, or a combination of different types of device commands. Different device commands can originate from different device drivers.

[0107] The above content illustrates that although the data transmission method involved in this application omits the arrangement of some native communication interfaces (such as GPIO interface, I2C interface, ADC interface, etc.) on the SoC, the calling method of some software modules (such as GPIO framework core, I2C framework core, ADC framework core, etc.) corresponding to these native communication interfaces is not omitted or changed.

[0108] The following describes in detail the process of transmitting commands from external devices to the SoC based on Figure 8.

[0109] The system structure shown in Figure 8 is the same as that shown in Figure 7. The functions of each module in the system will not be described here.

[0110] As shown in Figure 8(1), the data transmitted from each external device to the SOC may include at least one of the following: information transmitted through the GPIO interface of the external device (which may be referred to as GPIO data to be transmitted), data transmitted through the I2C interface of the external device (I2C data), data transmitted through the ADC interface of the external device (ADC data), and interrupt information sent through the low-speed master device (e.g., I2C master) in the aggregation parsing chip (I2C interrupt information). Since the GPIO interface can be configured to transmit interrupt information or to transmit data (referred to as GPIO data, non-interrupt information), a GPIO data to be transmitted may include GPIO interrupt information or GPIO data. Among them, the data transmitted by external devices such as I2C data, ADC data, and GPIO data may be referred to as device data. Different device data may come from different external devices or from the same external device, and this embodiment does not limit this.

[0111] The aggregation parsing chip aggregates communication data 2 based on at least one piece of device data and / or interrupt information. This communication data 2 includes at least one of the following: I2C data and its corresponding description information (e.g., information length, device address, register address, and command ID), I2C interrupt information and its corresponding description information (e.g., I2C master and command ID), GPIO interrupt information and / or GPIO data and its corresponding description information (e.g., expansion interface, ADC data and its corresponding expansion interface). Here, when GPIO interrupt information and GPIO data coexist, the objects generating the GPIO interrupt information and GPIO data are different. Differences include: GPIO interfaces in different external devices, or different GPIO interfaces in the same external device. For example, if Figure 8 is viewed as a schematic diagram of module interaction after transmitting device commands to various external devices in Figure 7, the communication data 2 includes information obtained by the aggregation parsing chip aggregating some or all of the following: device data 1 plus its description information, interrupt information 1, and its description information. Device data 1 may include GPIO data or I2C data (e.g., denoted as I2C data 1). Here, GPIO data can be data sent from external devices to expansion interface 1.

[0112] In some possible cases, where the I2C command (referred to as I2C command 1) involved in Figure 7 is a read command, an example of I2C data 1 can be data transmitted to extension interface 2 (e.g., the I2C interface in I2Cmaster 1) after the target external device responds to the I2C command. This is used to request data to be read from the target register of the target external device (I2C data 1).

[0113] As shown in Figure 8 (2), the control aggregation parsing chip transmits communication data 2 on the high-speed bus through the high-speed slave device. This communication data 2 can be received by the high-speed master device and processed by the SoC. The processing includes: the high-speed master device transmits the communication data 2 to the high-speed device extension driver through the high-speed device native driver. The high-speed device extension driver parses the communication data 2 and transmits the device data and interrupt information and their corresponding description information to the corresponding extension interface driver, including one or more of the following: as shown in Figure 8 (3), GPIO data and the corresponding extension interface (a kind of description information) are sent to the extension GPIO driver, and GPIO interrupt information and the corresponding extension interface (a kind of description information) are sent to the extension GPIO driver. The extension interface corresponding to the GPIO data (or GPIO interrupt information) is the identifier of the extension interface, indicating the source of the GPIO data (or GPIO interrupt information) (from which external device), and the identifier of the extension interface corresponds to the external device that sent the GPIO data (or GPIO interrupt information). The ADC data and the corresponding extension interface (a kind of description information) are sent to the extension ADC driver. The extended interface corresponding to the ADC data is its identifier, indicating the source of the ADC data (from which external device). There is a correspondence between this extended interface identifier and the external device sending the ADC data. The I2C data, along with its corresponding device address and register address, is transmitted to the extended I2C driver. The device address and register address can be used to determine the source of the I2C data (specifically, from which register in the external device). The I2C interrupt information, its corresponding I2C master, and command ID are transmitted to the extended I2C driver. The I2C master corresponding to the I2C interrupt information can be understood as its identifier, used to determine which I2C master the interrupt information originated from. The device address, register address, I2C master identifier, and interface identifier can all be collectively referred to as the device identifier. In some cases, the I2C master identifier can be the identifier of the interface within the I2C master.

[0114] An example of an I2C interrupt message is that it can be generated by I2Cmaster2. Here, the I2C interrupt message can be used to provide feedback on the execution status of I2C command 2 (not shown in Figure 7), such as whether the transmission was successful or failed. I2C command 2 is sent to the external device connected to the expansion interface 4 on the aggregation parsing chip. In some possible implementations, I2C command 2 can be considered as another I2C command carried in the communication data 1 in Figure 7.

[0115] As shown in Figure 8 (4), the extended GPIO driver is used to map the extended interface corresponding to GPIO data (or GPIO interrupt information) to the native GPIO interface. Specifically, the identifier of the corresponding native GPIO interface on the SoC is determined by the identifier of the extended interface corresponding to the GPIO data (or GPIO interrupt information). The native GPIO interface and the extended interface corresponding to the GPIO data (or GPIO interrupt information) both correspond to the same external device. Then, the GPIO data and its corresponding native GPIO interface (represented in the form of an interface identifier) ​​are transmitted to the GPIO framework core. The GPIO interrupt information and its corresponding native GPIO interface are transmitted to the interrupt handling module. After receiving the GPIO interrupt information, the interrupt handling module can generate a handling strategy for the GPIO interrupt and then send it to the GPIO framework core, which then feeds back the handling strategy to the upper layer.

[0116] The extended I2C driver is used to transmit I2C data and its corresponding device address and register address to the I2C framework core. It transmits I2C interrupt information and its corresponding I2C master (represented by an I2C master identifier) ​​and command ID to the interrupt handling module. The interrupt handling module can generate a handling strategy for the I2C interrupt. This strategy is then sent to the I2C framework core, which feeds it back to the upper layer; alternatively, it can be sent to the I3C master device, which responds to the strategy. The handling process for this I2C interrupt can be referred to in the following descriptions of Figures 11 and 12, which will not be elaborated here.

[0117] The extended ADC driver maps the extended interface corresponding to ADC data to the native ADC interface. Specifically, it determines the identifier of the corresponding native ADC interface on the SoC by using the identifier of the extended interface corresponding to the ADC data. Both the native ADC interface and the extended interface corresponding to the ADC data correspond to the same external device.

[0118] As shown in Figure 8 (5), the GPIO core framework can determine the external device corresponding to the native GPIO interface based on the native GPIO interface (interface identifier) ​​corresponding to the GPIO data (or GPIO interrupt), and then transmit the GPIO data (or GPIO interrupt) to the driver of the corresponding external device so that the driver of the external device can further process the GPIO data (or GPIO interrupt).

[0119] The I2C core framework can determine the external device transmitting the I2C data based on the corresponding device address and register address. It then transmits the I2C data to the driver of the corresponding external device, allowing the driver to further process the I2C data.

[0120] The ADC core framework can determine the external device corresponding to the native ADC interface based on the native ADC interface (interface identifier) ​​corresponding to the ADC data (or ADC interrupt), and then transmit the ADC data (or ADC interrupt) to the driver of the corresponding external device so that the driver of the external device can further process the ADC data (or ADC interrupt).

[0121] It should be noted that the communication data b mentioned in Figure 5 may include data sent by at least one external device to a high-speed master device (e.g., an I2C slave) via a low-speed slave device (e.g., an I3C master). After the data arrives at the high-speed master device, the software aggregation and parsing module in the SoC where the high-speed master device resides can process the communication data b. In the case where the low-speed master device is an I2C master, the communication data b here can be the I2C data mentioned in Figure 8, or it can be understood as an example of communication data 2.

[0122] It should also be noted that, as shown in Figures 7 and 8, the native communication interfaces (such as the SPI interface) that are not omitted on the SoC can still be used to transmit data with external devices through their corresponding interface framework core (such as the SPI framework core) and the connection lines (such as the SPI bus) connected to the native communication interfaces.

[0123] It should also be noted that the aggregation parsing chip can be debugged before the terminal leaves the factory to ensure its functionality. As shown in Figures 7 and 8, one debugging node is controlled at the high-speed device expansion driver. The high-speed device expansion driver outputs preset communication data. If the external device does not receive the command carried in the preset communication data, it can be determined that there is a problem with the aggregation parsing chip, requiring repair. If the external device receives the command carried in the preset communication data, it can be determined that the aggregation parsing chip meets the requirements.

[0124] The following description, based on Figure 9, illustrates the process by which the aggregation parsing chip sends commands to external devices through the extended interface.

[0125] Because high-speed master devices (e.g., I3C master) transmit data at a higher rate on high-speed buses (e.g., I3C bus) than low-speed master devices (e.g., I2C master) transmit data on low-speed buses (e.g., I2C bus), a transmit first-in-first-out (TXFIFO) buffer, or simply transmit buffer, is also provided in the aggregation parsing chip in the data transmission method proposed in this application embodiment to avoid data loss.

[0126] The aggregation parsing chip also includes a register mapping module, which records mapping relationships and provides feedback on the status of registers in external devices. These mapping relationships include the correspondence between expansion interfaces and external devices, and the correspondence between low-speed master devices and expansion interfaces.

[0127] Figure 9 can be seen as a detailed example of Figure 5 above. In Figure 9, the communication data received by the terminal through the aggregation parsing chip based on the high-speed slave device (e.g., I3C slave) can be the communication data a involved in Figure 5 above. The content obtained by parsing the communication data a through the aggregation parsing chip can include: command a, interface identifier a for transmitting command a, and configuration information a, and / or, command b, interface identifier b for transmitting command b, and configuration information b. In the case where the low-speed master device is an I2C master, command a and command b here can be the I2C commands involved in Figure 7 above. Combining the aforementioned related content (e.g., Figure 7), it can also be understood that communication data a is an example of communication data 1. Communication data a includes commands (e.g., I2C commands) that need to be transmitted through the extended interface in the low-speed master device, but does not include commands such as GPIO commands and ADC commands transmitted on non-bus-type connections.

[0128] The process of parsing communication data 'a' using the aggregation parsing chip can include: the terminal, through a high-speed slave device (e.g., an I3C slave), determines the target low-speed master device 1 according to the interface identifier 'a' (the identifier of the extended interface used to transmit command 'a'). A mapping relationship exists between the target low-speed master device 1 and the interface identifier 'a' (denoted as mapping relationship 1). This mapping relationship 1 is recorded in the register mapping module. The terminal can obtain this mapping relationship from the register mapping module through the high-speed slave device. Then, the terminal, through the high-speed slave device, feeds back the transmit buffer identifier of the target low-speed master device 1 (denoted as transmit buffer identifier 1) to the high-speed master device (e.g., an I3C master). The mapping relationship between this transmit buffer identifier and the target low-speed master device 1 is recorded in the register mapping module. Finally, the high-speed master device sends command 'c' to the high-speed slave device. Command 'c' is used by the high-speed slave device to write command 'a' and its configuration information into the transmit buffer (transmit buffer 1) of the target low-speed master device 1.

[0129] Subsequently, the command 'a' and its configuration information recorded in the transmit buffer 1 can be read by the target low-speed master device 1, and then the command 'a' can be sent to the external device on the low-speed bus (e.g., I2C bus) connected to the target low-speed master device 1 through the configuration information of command 'a'. The command 'a' can be received and responded to by the target external device through the low-speed slave device. Here, the target low-speed master device 1 can be I2C master devices such as I2Cmaster1, I2Cmaster2, and I2Cmaster3 shown in Figure 9. Different low-speed master devices (e.g., I2C master) can be connected to different low-speed buses (e.g., I2C buses). The low-speed slave devices (e.g., I2C slaves) connected to different low-speed buses are different. For example, the I2C bus of I2Cmaster1 (called I2C bus 1) includes I2C data line 1 and I2C clock line 1, and at least one I2C slave (e.g., I2Cslave11, I2Cslave12) can be connected to I2C bus 1. The descriptions of I2Cmaster2, I2Cmaster3, and their connected low-speed buses and low-speed slave devices on the low-speed buses in the diagram can be found in the description of I2Cmaster1, and will not be repeated here.

[0130] To prevent the transmit buffer from overflowing due to insufficient memory when writing data, after the terminal feeds back the transmit buffer identifier (denoted as transmit buffer identifier 1) of the target low-speed master device 1 to the high-speed master device (e.g., I3C master) through the high-speed slave device, the terminal can send command d to the high-speed slave device (e.g., I3C slave) through the high-speed master device. This command d is used to obtain the remaining space of the transmit buffer (transmit buffer 1) indicated by transmit buffer identifier 1 through the high-speed slave device. Only when the remaining space is greater than a preset threshold will the terminal send command c to the high-speed slave device through the high-speed master device. A detailed description of this process can be found in the description of steps S101, S102a, and S102b in Figure 11 below, which will not be repeated here.

[0131] When a high-speed master device (e.g., an I3C master) supports internal interrupts, even a low-speed master device (e.g., an I2C master) that does not support interrupts can still report interrupt information through the high-speed master device and the high-speed bus. For example, let's take the aforementioned target low-speed master device 1 as an example. After a low-speed slave device on the low-speed bus connected to the target low-speed master device 1 sends command 'a', it can generate interrupt information (denoted as interrupt information 'a'). This interrupt information 'a' can be used to report whether the target low-speed master device 1 successfully transmitted command 'a' to the target external device. Then, the terminal can transmit interrupt information 'a' and its description to the high-speed master device through a high-speed slave device (e.g., an I3C slave). The terminal then processes the interrupt information through the SoC where the high-speed master device resides. This processing includes: the terminal reporting interrupt information 'a' and its description to the interrupt handling module through the high-speed master device; the interrupt handling module analyzing the interrupt type of interrupt information 'a'; and, if the interrupt type of interrupt information 'a' indicates that command 'a' failed to be transmitted, the interrupt handling module sending command 'e' to the high-speed master device. Command e carries the interface identifier of the target low-speed master device 1. Command e is used to control the target low-speed master device 1 to retransmit command a through the high-speed master device. The interface identifier carried in command e is determined based on the description information of interrupt information a. It should be noted that, in some possible cases, interrupt information a carries the code number corresponding to the interrupt type, and the correspondence between the code number and the interrupt type is recorded in the interrupt handling module. Different interrupt types correspond to different code numbers. Interrupt types can include transmission success, transmission failure, or transmission timeout, etc., and this embodiment does not limit this.

[0132] It should be noted that the foregoing description focuses on the aggregation parsing chip parsing communication data a to obtain command a and its related content. The process by which the aggregation parsing chip parses communication data a to obtain other content (e.g., command b) and its related content can be referred to the description of the relevant content in Figure 9, and will not be repeated here in this embodiment. For example, the process by which the aggregation parsing chip parses and obtains command b, the interface identifier b used to transmit command b, and configuration information b, and records command b and its configuration information b into the transmission buffer connected to the target low-speed master device (denoted as target low-speed master device 2), can be referred to the description here.

[0133] It should also be noted that Figure 9 illustrates an example using an I3C bus (including I3C data lines and I3C clock lines) as the high-speed bus and an I2C bus (including I2C data lines and I2C clock lines) as the low-speed bus. Other types of buses can also be used; please refer to the foregoing descriptions for details. This application does not limit the specific type of bus used.

[0134] The following description, based on Figure 9, illustrates the process by which the aggregation parsing chip transmits interrupt information and data from external devices (device data) through the extended interface.

[0135] Because high-speed master devices (e.g., I3C master) transmit data at a higher rate on high-speed buses (e.g., I3C bus) than low-speed master devices (e.g., I2C master) transmit data on low-speed buses (e.g., I2C bus), in order to improve transmission efficiency, the data transmission method proposed in this application embodiment also includes a receive first-in-first-out (RXFIFO) buffer (hereinafter referred to as the transmit buffer) connected to the I2C master in the aggregation parsing chip.

[0136] In Figure 9, the process of a low-speed slave device (e.g., an I2C slave) transmitting information to a high-speed master device (I3C master) via a converged parsing chip can include: the terminal acquiring device data 1 (e.g., I2C data) from the low-speed slave device 1 via the low-speed master device 1 connected to the low-speed master device 1 on the low-speed bus. The low-speed master device 1 then records the device data 1 and its description information in the receive buffer (receive buffer 1) connected to it. Finally, the high-speed slave device (e.g., an I3C slave) sends interrupt information 2 and its description information to the high-speed master device (e.g., an I3C master). Interrupt information 2 is generated by the low-speed master device 1 and serves as feedback on the status of the low-speed master device 1 reading device data.

[0137] Subsequently, the terminal can process interrupt information 2 through the SoC where the high-speed master device resides. This process includes: the terminal reporting interrupt information 2 and its description to the interrupt handling module through the high-speed master device (e.g., I3Cmaster). The interrupt handling module analyzes the interrupt type of interrupt information 2. If the interrupt type of interrupt information 2 indicates that the read command was executed successfully and the low-speed master device 1 has completed data reading, the interrupt handling module sends command f to the high-speed master device. Command f carries the identifier of receive buffer 1 and is used by the high-speed master device to read device data 1 and its description from receive buffer 1. The identifier of receive buffer 1 carried in command f is determined by the description of interrupt information 2, and the description of device data 1 is used by the SoC where the high-speed master device resides to process the second data.

[0138] It should be noted that the low-speed master device 1 mentioned above can be the target low-speed master device 1 mentioned above, and the device data 1 can be the data read by the target low-speed master device 1 from the target external device through command a (here, read command).

[0139] It should also be noted that, based on the foregoing, when sending device data 1, if there are other information (device data or interrupt information) that needs to be sent, the aggregation parsing chip can aggregate device data 1 and other information that needs to be sent and their description information, and then transmit them together to the high-speed master device. For a description of this process, please refer to the description of the relevant content in Figure 8 above, which will not be repeated here.

[0140] Figure 9 can be seen as an example of (2) in Figure 5 above, illustrating the case where at least one low-speed master device (e.g., I2C master) is arranged in the aggregation parsing chip, and the expansion interface is an interface in the low-speed master device (e.g., I2C interface). In some possible cases, as shown in Figure 10, based on Figure 9, the expansion interface in the aggregation parsing chip can be arranged with at least one non-bus type communication interface in addition to the bus type communication interface in the low-speed master device. For example, the GPIO interface and / or ADC interface mentioned above. Here, the amount of data transmitted by the GPIO interface and ADC interface in a single transmission is usually small, so there is no need to set up additional transmit buffers and receive buffers for the GPIO interface and ADC interface. For example, after the register mapping module determines that the data needs to be transmitted through the GPIO interface, it can be sent to the GPIO interface to realize the transmission, without the need for buffering through the transmit buffer.

[0141] The following is an exemplary flowchart based on Figure 11, illustrating how a terminal sends commands to external devices using an aggregation parsing chip.

[0142] Figure 11 illustrates this process using the high-speed master device as I3Cmaster and the expansion interface in the aggregation parsing chip as the I2C interface in I2Cmaster. The commands sent here can be command a mentioned in Figure 9, the I2C command mentioned in Figure 7, etc. A description of this process can be found in steps S101-S107 below.

[0143] S101.I3Cmaster obtains the remaining storage space of the target TXFIFO.

[0144] The target TXFIFO here can be regarded as the aforementioned transmit buffer 1. The process of determining transmit buffer 1 can be referred to the description of the relevant content in Figure 9 above, which will not be repeated here.

[0145] If the remaining storage space is insufficient, the I3C master executes step S102a, reporting interrupt 11 (an example of an interrupt message) to the interrupt handling module to notify it that the TX FIFO space is insufficient. For a description of this interrupt handling module, please refer to the relevant content in Figure 8 above; it will not be repeated here.

[0146] Interrupt 11 here can be understood as the interrupt information sent by the I3C master to the interrupt handling module through the internal interrupt mechanism.

[0147] The interrupt handling module analyzes the interrupt type indicated by interrupt 11 and determines that interrupt 11 indicates insufficient TX FIFO space. It can then notify the I3C master to execute S101 again after time t. Upon receiving this notification, the I3C master starts timing and executes S101 again after time t.

[0148] If there is sufficient remaining storage space, the I3C master executes step S102b, writing the I2C command and its corresponding configuration information to the target TXFIFO via the I3C slave. Here, an example of the I2C command and its corresponding configuration information can be command a and its corresponding configuration information as shown in Figure 7 above.

[0149] Table 1 shows an example of how TXFIFO records I2C commands and their configuration information.

[0150] Table 1

[0151] As shown in Table 1, command 'a' is recorded in the TXFIFO as data (including data1 to datd-n2), and its configuration information is recorded adjacent to it in the TXFIFO. Besides command 'a' and its configuration information, the TXFIFO can also record other commands and their configuration information. The TXFIFO follows a first-in, first-out (FIFO) principle. For example, data with smaller TXFIFO data numbers can be read by the I2C master first. The process of the I2C master reading data from the TXFIFO can be referred to step S103.

[0152] S103. The target I2C master reads the I2C commands and their corresponding configuration information from the target TX FIFO.

[0153] The target I2C master here is the I2C master that is connected to the target TXFIFO.

[0154] Let's take command 'a' as an example of an I2C command. The target I2C master first reads the configuration information of command 'a', then reads the subsequent data, until it reads the configuration information of the next command (which is not read in this case), at which point the reading of command 'a' and its configuration information is complete.

[0155] S104. The target I2C master writes I2C commands to the target I2C slave based on the configuration information.

[0156] The target I2C master controls its I2C interface to transmit I2C commands to I2C slaves connected to the I2C bus based on the configuration information of the I2C commands. Although all I2C slaves connected to the I2C bus can receive the I2C command, only the I2C slave (the target I2C slave) whose device address is the same as the device address in the configuration information (the target device address) will respond to the I2C command.

[0157] If the target I2C slave receives the I2C command, it will return a response to the target I2C master. If a response exists, the I2C master determines that the write was successful; otherwise, the I2C master determines that the write failed.

[0158] In the event of a write failure, the following steps S105a, S106, and S107 are executed to handle the write failure.

[0159] The S105a.I2C master reports interrupt 12 to the interrupt handling module via the I3C master to notify the interrupt handling module of a write failure.

[0160] The interrupt handling module analyzes the interrupt type indicated by interrupt 12 (an example of I2C interrupt information). If interrupt 12 indicates a write failure, the interrupt handling module executes step S106, notifying the I3C master to handle the write failure and providing a decision for handling the write failure (e.g., reboot or rewrite). See step S107. Interrupt 12 carries the command ID of the I2C command, which the interrupt handling module uses to analyze which command the interrupt refers to, facilitating how to handle the interrupt and generating a decision. For example, if the command ID is the command ID of command a, and the interrupt type is write failure, the interrupt handling module can determine that command a failed to write. Further decisions are generated based on the type of command a. For example, if command a is a write command, then rewriting is determined, etc.

[0161] S107. The I3C master notifies the I2C master to restart or rewrite.

[0162] The restart notification here includes the I3C master sending a restart command to the I2C master, and after the I2C master restarts, it continues to send I2C commands to the I2C slave.

[0163] This notification rewrite includes the I3C master sending a name again to the I2C master, so that the I2C master can send I2C commands to the I2C slave again.

[0164] If the write operation is successful, the I2C master executes step S105b.

[0165] The S105b.I2C master reports interrupt 13 to the interrupt handling module via the I3C master to notify the interrupt handling module that the write is complete.

[0166] Here, the I2C master uses the internal interrupt mechanism in the I3C protocol to notify the interrupt handling module that the write operation is complete. After receiving interrupt 13, the interrupt handling module can control the I3C master to transmit subsequent read or write commands.

[0167] The following is an exemplary flowchart based on Figure 12, illustrating how a terminal reads data from an external device using a converged parsing chip.

[0168] Figure 12 illustrates this using the high-speed master device I3Cmaster and the expansion interface in the aggregation parsing chip I2Cmaster's I2C interface as an example. The data read here can be the device data 1 mentioned in the relevant content of Figure 9 above. The description of this process can be found in steps S101-S205 below.

[0169] It should be noted that to read data from an external device, a read command must first be written to that external device via the I2C master. This read command indicates which register of the external device needs to be read from. The process of writing a read command to an external device via the I2C master can be referred to the aforementioned description of steps S101-S106, with appropriate modifications. For example, the I2C command can be replaced with a read command. Specifically, refer to the following descriptions of steps S101, S102a, S102b1, S1031, S1041, S105a, S106, and S107.

[0170] S101.I3Cmaster obtains the remaining storage space of the target TXFIFO.

[0171] If the remaining storage space is insufficient, the I3Cmaster executes step S102a to report interrupt 11 to the interrupt handling module, which is used to notify the interrupt handling module that the TX FIFO space is insufficient.

[0172] If there is sufficient remaining storage space, the I3C master executes step S102b1, which uses the I3C slave to write the read command and its corresponding configuration information to the target TXFIFO.

[0173] An example of writing a read command to the TX FIFO can be found in Table 2 below.

[0174] Table 2

[0175] In Table 2, the read length P represents the length of data that the target external device needs to return from the register address specified by the read command. Device address + read command represents the address of the target external device from which the data is read.

[0176] S1031. The target I2C master reads the read command and its corresponding configuration information from the target TX FIFO.

[0177] S1041. The target I2C master writes the read command to the target I2C slave based on the configuration information.

[0178] If the target I2C slave receives a read command, it will return a response to the target I2C master. If a response exists, the I2C master determines that the read command was successfully written; otherwise, the I2C master determines that the read command failed.

[0179] In the event of a write failure, the following steps S105a, S106, and S107 are executed to handle the write failure.

[0180] The S105a.I2C master reports interrupt 12 to the interrupt handling module via the I3C master to notify the interrupt handling module of a write failure.

[0181] The interrupt handling module analyzes the interrupt type indicated by interrupt 12, determines that interrupt 12 indicates that when a write failure occurs, it executes step S106, notifies the I3C master to handle the write failure, and notifies the decision to handle the write failure (e.g., restart or rewrite), see step S107.

[0182] S107. The I3C master notifies the I2C master to restart or rewrite.

[0183] It should be noted that steps S101, S102a, S102b1, S1031, S1041, S105a, S106, and S107 are not described in detail here. You can refer to steps S101, S102a, S102b, S103, S104, S105a, S106, and S107 in Figure 11 above and modify them accordingly. For example, you can change the I2C command to a read command.

[0184] If the read command is successfully written, then the following steps S201-S205 are executed to read data from the target external device.

[0185] S201. The target I2C master reads data from the target I2C slave.

[0186] The target I2C slave is the I2C slave of the target external device indicated in the read command. The device address of this target external device is the same as the device address carried in the read command.

[0187] In response to a read command, the target I2C slave transmits data to the target I2C master via the I2C bus to which the target I2C master is connected. This enables the target I2C master to read the data.

[0188] S202. The target I2C master records the read data and its description information in the target RX FIFO.

[0189] Table 3 shows an example of RXFIFO recorded data.

[0190] Table 3

[0191] In Table 3, the read length P is used to control the I3C master to read data of length p (data1-data-P) from the RXFIFO in step S205 below. The command ID is used by the target I2C master to generate interrupt information when the read command fails. This interrupt information indicates that the read command failed and carries the command ID. After receiving the interrupt information, the interrupt handling module can determine the failed read command based on the command ID and report the read command failure to the upper layer that sent the read command in order to handle the read command failure.

[0192] It should be noted that in some possible implementations, to prevent write overflow in the RX FIFO, it is also necessary to check the remaining memory space in the RX FIFO. Step S202 is only executed if it is determined that there is sufficient remaining memory space in the RX FIFO. The process of checking whether there is sufficient remaining memory space in the RX FIFO is similar to the aforementioned process of checking whether there is sufficient remaining memory space in the TX FIFO, and can be adapted accordingly, for example, by changing TX to RX. This embodiment will not be elaborated further.

[0193] S203. The target I2C master reports interrupt 21 to the interrupt handling module through the I3C master, which is used to notify the interrupt handling module that the read command has been completed.

[0194] The interrupt handling module determines the interrupt type as read command completion based on interrupt 21 (an example of I2C interrupt information). Interrupt 21 must carry the identifier of the target I2C master that completed the read command. This allows the interrupt handling module to notify the I2C master to read data from the RXFIFO connected to the target I2C master, as shown in step S204 below.

[0195] S204. The interrupt handling module notifies the I3C master to read data from the target RX FIFO.

[0196] The I3C master reads data from the target RX FIFO. This process includes: the I3C master reading the target length of device data and the corresponding partial or complete descriptive information (such as device address, register address, etc.) from the target RX FIFO through the I3C slave.

[0197] S205.I3Cmaster reports interrupt 22 to the interrupt handling module to notify the interrupt handling module that the data reading is complete.

[0198] After receiving interrupt 22, the interrupt handling module can control the I3C master to transmit subsequent read or write commands.

[0199] The following describes an exemplary terminal provided in the embodiments of this application.

[0200] Figure 13 is a schematic diagram of the structure of the terminal provided in the embodiment of this application.

[0201] The following describes the embodiment using a terminal as an example. It should be understood that the terminal may have more or fewer components than those shown in Figure 13, may combine two or more components, or may have different component configurations. The various components shown in Figure 13 can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0202] The terminal may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0203] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the terminal. In other embodiments of this application, the terminal may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0204] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0205] The controller can serve as the nerve center and command center of the terminal. Based on the instruction opcode and timing signals, the controller generates operation control signals to control the fetching and execution of instructions.

[0206] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0207] Processor 100 can also be considered as the aforementioned SoC.

[0208] The terminal in this embodiment may also include an aggregation parsing chip. For details regarding the connection between the SoC and the aggregation parsing chip, as well as the data transmission involved, please refer to the foregoing description of the relevant content in Figure 3; further details will not be repeated here.

[0209] In this embodiment of the application, the processor 110 can call computer instructions stored in the internal memory 121 to cause the terminal to execute the data transmission method in this embodiment of the application.

[0210] It should be noted that the GPIO data shown in Figure 8 is a single GPIO data point; in reality, it may include more GPIO data points. The same applies to other device data (such as I2C data, ADC data) and interrupt information; please refer to the aforementioned descriptions, which will not be repeated here.

[0211] This application also provides a chip system, which includes at least one processor for implementing the functions involved in the terminal execution method in any of the above embodiments.

[0212] In one possible design, the chip system also includes a memory for storing program instructions and data, which may be located within or outside the processor.

[0213] The chip system can consist of chips or include chips and other discrete components.

[0214] Optionally, the chip system may contain one or more processors. These processors can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor, implemented by reading software code stored in memory.

[0215] Optionally, the chip system may contain one or more memories. These memories may be integrated with the processor or separated from it; this application does not limit the specific implementation.

[0216] For example, the memory can be a non-transient processor, such as a read-only memory (ROM), which can be integrated on the same chip as the processor or set on different chips. This application does not specifically limit the type of memory or the way the memory and processor are set.

[0217] This application also provides a computer program product, the computer program product comprising: a computer program (also referred to as code or instructions), which, when the computer program is run, causes a computer to perform the method executed by the terminal in any of the above embodiments.

[0218] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is run, it causes the computer to perform the method executed by the terminal in any of the above embodiments.

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

[0220] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0221] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items.

[0222] The terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0223] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. 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 can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can 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) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0224] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A data transmission method, characterized in that, The method is applied to a terminal, which has a system-on-a-chip (SoC) and peripheral chips. The SoC is connected to a high-speed bus via a high-speed master device, and the peripheral chips are connected to the high-speed bus via high-speed slave devices. Each peripheral chip also includes at least one low-speed master device. Different low-speed master devices are connected to different low-speed buses. At least one low-speed slave device is also connected to a low-speed bus to which a low-speed master device is connected. The data transmission rate on the high-speed bus is greater than the data transmission rate on the low-speed bus. The method includes: The high-speed host device sends first data to the peripheral chip on the high-speed bus, and the first data is generated in the system-on-a-chip. The high-speed slave device receives the first data from the high-speed bus through the peripheral chip; The peripheral chip is controlled to parse the first data to obtain at least the first command carried in the first data, the first interface identifier for transmitting the first command, and the first configuration information. The first command and the first configuration information are obtained through the first low-speed master device, which is determined based on the first interface identifier; The first low-speed master device transmits the first command to the low-speed slave device on the first low-speed bus according to the first configuration information.

2. The method according to claim 1, characterized in that, The peripheral chip obtains the following content by parsing the first data: a second command carried in the first data, a second interface identifier for transmitting the second command, and second configuration information. The method further includes: The second command and the second configuration information are obtained through the second low-speed master device, which is determined based on the second interface identifier; The second low-speed master device transmits the second command to the low-speed slave device on the second low-speed bus according to the second configuration information.

3. The method according to claim 2, characterized in that, The peripheral chip includes a transmit buffer connected to a low-speed master device. Different low-speed master devices connect to different transmit buffers. It also includes a register mapping module that controls the peripheral chip to parse the first data, specifically including: The high-speed slave device determines the first low-speed master device according to the first interface identifier, and the first low-speed master device has a first mapping relationship with the first interface identifier; the first mapping relationship is recorded in the register mapping module. The high-speed slave device feeds back the first transmit buffer identifier of the first low-speed master device to the high-speed master device. The high-speed master device sends a third command to the high-speed slave device, the third command being used by the high-speed slave device to write the first command and its configuration information into the transmit buffer connected to the first low-speed master device. Obtaining the first command and the first configuration information through the first low-speed master device specifically includes: The first command and the first configuration information are read from the connected transmit buffer by the first low-speed master device.

4. The method according to claim 3, characterized in that, After the high-speed slave device feeds back the first transmit buffer identifier of the first low-speed master device to the high-speed master device, the method further includes: The high-speed master device sends a fourth command to the high-speed slave device, the fourth command being used to obtain the remaining space of the transmission buffer area indicated by the first transmission buffer area identifier through the high-speed slave device; Sending a third command from the high-speed master device to the high-speed slave device specifically includes: If the remaining space is greater than a preset threshold, the third command is sent from the high-speed master device to the high-speed slave device.

5. The method according to claim 3 or 4, characterized in that, The method further includes: The first high-speed slave device sends a first interrupt information and a description of the first interrupt information to the high-speed master device. The first interrupt information is generated by the first low-speed master device and is used to provide feedback on the situation where the first low-speed master device transmits a first command to the low-speed slave device on the first low-speed bus according to the first configuration information. The first interrupt information is processed by the system-on-a-chip (SoC) where the high-speed main device is located.

6. The method according to claim 5, characterized in that, The system-on-a-chip also runs an interrupt handling module, which processes the first interrupt information through the system-on-a-chip where the high-speed main device is located, specifically including: The high-speed master device reports the first interrupt information and its description to the interrupt handling module. The interrupt handling module analyzes the interrupt type of the first interrupt information; If the interrupt type of the first interrupt information indicates that the first command transmission failed, the interrupt handling module sends a fifth command to the high-speed master device. The fifth command carries the interface identifier of the first low-speed master device. The fifth command is used to control the first low-speed master device to retransmit the first command through the high-speed master device. The interface identifier carried in the fifth command is determined based on the description information of the first interrupt information.

7. The method according to any one of claims 3-6, characterized in that, The peripheral chip includes a receive buffer connected to a low-speed master device. Different low-speed master devices are connected to different receive buffers. When the first command is a read command, the method further includes: The first low-speed master device reads the second data from the first low-speed slave device on the low-speed bus; The first low-speed master device records the second data and its description information in the first receiving buffer connected to the first low-speed master device. The first high-speed slave device sends a second interrupt information and a description of the second interrupt information to the high-speed master device. The second interrupt information is generated by the first low-speed master device and is used to provide feedback on the first low-speed master device's reading of the second data. The second interrupt information is processed by the system-on-a-chip (SoC) where the high-speed main device is located.

8. The method according to claim 7, characterized in that, The second interrupt information is processed by the system-on-a-chip (SoC) where the high-speed main device is located, specifically including: The high-speed master device reports the second interrupt information and its description to the interrupt handling module. The interrupt handling module analyzes the interrupt type of the second interrupt information. When the interrupt type of the second interrupt information indicates that the first command was executed successfully and the first low-speed master device has completed data reading, a sixth command is sent to the high-speed master device through the interrupt handling module. The sixth command carries the identifier of the first receive buffer and is used to read the second data and the description information of the second data from the first receive buffer through the high-speed master device. The identifier of the first receive buffer carried in the sixth command is determined based on the description information of the second interrupt information. The description information of the second data is used by the system-on-a-chip where the high-speed master device is located to process the second data.

9. The method according to claim 8, characterized in that, The peripheral chip also has at least one expansion interface, and the first data also carries a seventh command, a third interface identifier for transmitting the seventh command, and third configuration information. The method further includes: The high-speed slave device determines the first extended interface according to the third interface identifier. The identifier of the first extended interface and the third interface identifier have a second mapping relationship, and the second mapping relationship is recorded in the register mapping module. The high-speed slave device controls the first expansion interface to transmit the seventh command according to the third configuration information; the seventh command is transmitted to the device connected to the first expansion interface, and the first expansion interface and the device are connected through a non-bus type connection cable.

10. The method according to claim 9, characterized in that, The data transmission rate on the high-speed bus is greater than the data transmission rate on the non-bus-type connection line.

11. The method according to any one of claims 1-10, characterized in that, The communication protocols used for data transmission on the high-speed bus include the Improved Integrated Circuit Interconnect (I3C) protocol or the System Power Management Interface (SPMI) protocol.

12. The method according to any one of claims 1-11, characterized in that, The communication protocol used for data transmission on the low-speed bus includes the integrated circuit I2C protocol.

13. The method according to any one of claims 1-12, characterized in that, The expansion interface includes at least one of a general purpose input / output (GPIO) interface and an analog-to-digital converter (ADC) interface.

14. A terminal, characterized in that, include: One or more processors and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the terminal to perform the method as described in any one of claims 1-13.

15. A computer-readable storage medium comprising computer instructions, characterized in that, When the computer instructions are executed on the terminal, the terminal causes the terminal to perform the method as described in any one of claims 1-13.

16. A chip system applied to a terminal, characterized in that, The chip system includes one or more processors, which are used to invoke computer instructions to cause the terminal to perform the method as described in any one of claims 1-13.

17. A computer program product containing instructions, characterized in that, When the computer program product is run on a terminal, the terminal performs the method as described in any one of claims 1-13.

Images