Inter-chip thread communication method and system, electronic equipment and storage medium

Abstract

The invention discloses an inter-chip thread communication method and system, electronic equipment and a storage medium, and belongs to the technical field of computers. The inter-chip thread communication method is applied to a first chip, the first chip is connected with a second chip through a full duplex communication protocol, and in the scheme provided by the method, events are sent between the first chip and the second chip through a token packet, a data packet and a handshake packet. According to the method, initialization transformation, blocking interface transformation and non-blocking interface transformation are carried out on the RTOS kernel of the chip. According to the application, the universality of thread communication between chips can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, system, electronic device and storage medium for inter-chip thread communication. Background Technology

[0002] To meet the needs of specific application scenarios, a product may need to integrate two chips specifically designed for different application areas. The above design can maximize the performance advantages of each chip to adapt to different workloads.

[0003] For products with rich functionality and high software complexity, a Real-Time Operating System (RTOS) is typically deployed on the chip to simplify application development. A RTOS allows a product to consist of multiple application functional modules, each existing as an RTOS thread. These threads need to communicate with each other to collaborate and jointly build the overall functionality of the product. Since each thread may be assigned to different chips to execute based on its application characteristics, related technologies often design specific communication protocols for different application scenarios. When two chips need to communicate, the protocol content is understood according to the protocol definition to perform corresponding operations. However, the scope of application is narrow; once the application functionality is modified, the protocol content needs to be modified again.

[0004] Therefore, improving the versatility of inter-chip thread communication is a technical problem that needs to be solved by those skilled in the art. Summary of the Invention

[0005] The purpose of this application is to provide a method, system, electronic device, and storage medium for inter-chip thread communication, which can improve the versatility of inter-chip thread communication.

[0006] To address the aforementioned technical problems, this application provides an inter-chip thread communication method applied to a first chip, wherein the first chip is connected to a second chip via a full-duplex communication protocol, and the inter-chip thread communication method includes:

[0007] Determine the chip state of the first chip; wherein the chip state includes a first state and a second state, the first state being a state in which there is a transaction to be sent in the chip, and the second state being a state in which there is no transaction to be sent in the chip;

[0008] If the first chip is in the first state, it sends a first token packet to the second chip and receives a second token packet or a first padding packet sent by the second chip; wherein the first token packet, the second token packet and the first padding packet have the same sending parameters, including the sending time and the data length;

[0009] Send a first data packet to the second chip and receive a second data packet or a second padding packet sent by the second chip; wherein the sending parameters of the first data packet, the second data packet, and the second padding packet are the same;

[0010] Send a first handshake packet to the second chip and receive a second handshake packet or a third padding packet sent by the second chip; wherein the sending parameters of the first handshake packet, the second handshake packet and the third padding packet are the same.

[0011] Optionally, the RTOS kernel of the first chip includes a first virtual thread, and the RTOS kernel of the second chip includes a second virtual thread; there are corresponding ITC communication objects in the first chip and the second chip;

[0012] Correspondingly, it also includes:

[0013] When the first thread of the first chip calls the ITC communication object corresponding to the first target ID through the blocking interface, the ITC communication object A inside the first chip is obtained; wherein, the ITC communication object inside the first chip corresponding to the first target ID is the ITC communication object A, and the ITC communication object inside the second chip corresponding to the first target ID is the ITC communication object A'.

[0014] If the ITC communication object A cannot be obtained from the first chip, a blocking acquisition request transaction is initiated to the second chip based on the full-duplex communication protocol, so that the RTOS kernel of the second chip records that the second virtual thread is requesting the ITC communication object A' in a blocking manner;

[0015] If the second virtual thread successfully acquires the ITC communication object A', it initiates a successful acquisition transaction through full-duplex communication to notify the RTOS kernel of the first chip that it has successfully acquired the target ITC communication object, so that the RTOS kernel of the first chip can control the first virtual thread to release the ITC communication object A, and the first thread can acquire the ITC communication object A released by the first virtual thread.

[0016] Optionally, before the first thread acquires the ITC communication object A released by the first virtual thread, the method further includes:

[0017] If the second thread of the first chip releases the ITC communication object A, and the first thread acquires the ITC communication object A, then it initiates a cancellation acquisition request transaction to the second chip, so that the RTOS kernel of the second chip controls the second virtual thread to cancel the request for the ITC communication object A'.

[0018] Optional, also includes:

[0019] When the third thread of the first chip calls the ITC communication object corresponding to the second target ID through a non-blocking interface, the ITC communication object B inside the first chip is obtained; wherein, the ITC communication object inside the first chip corresponding to the second target ID is the ITC communication object B, and the ITC communication object inside the second chip corresponding to the second target ID is the ITC communication object B'.

[0020] If the ITC communication object B cannot be obtained from the first chip, a non-blocking acquisition request transaction is initiated to the second chip based on the full-duplex communication protocol, so that the RTOS kernel of the second chip controls the second virtual thread to request the ITC communication object B' in a non-blocking manner;

[0021] If the second virtual thread successfully acquires the ITC communication object B', it initiates a successful acquisition transaction through full-duplex communication to notify the RTOS kernel of the first chip that it has successfully acquired the target ITC communication object, so that the RTOS kernel of the first chip controls the first virtual thread to release the ITC communication object B, and the third thread acquires the ITC communication object B released by the first virtual thread.

[0022] If the second virtual thread fails to acquire the ITC communication object B', it controls the RTOS kernel of the first chip to return a failure message through a non-blocking interface so that the third thread can continue to execute other tasks.

[0023] Optionally, after determining the chip state of the first chip, the method further includes:

[0024] If the first chip is in the second state and the second chip is in the first state, then a fourth padding packet is sent to the second chip, and a second token packet sent by the second chip is received; wherein, the sending parameters of the fourth padding packet and the second token packet are the same;

[0025] Send a fifth padding packet to the second chip and receive a second data packet sent by the second chip; wherein the sending parameters of the fifth padding packet and the second data packet are the same;

[0026] A sixth padding packet is sent to the second chip, and a second handshake packet is received from the second chip; wherein the sending parameters of the sixth padding packet and the second handshake packet are the same.

[0027] Optionally, after determining the chip state of the first chip, the method further includes:

[0028] If both the first chip and the second chip are in the second state, a seventh padding packet is periodically sent to the second chip, and an eighth padding packet is periodically sent by the second chip; wherein the sending parameters of the seventh padding packet and the eighth padding packet are the same.

[0029] Optional, also includes:

[0030] Determine whether the first chip and the second chip were both in the second state when the last transaction was sent;

[0031] If not, the current transaction is sent according to the first rule; wherein the first rule is: the time interval between the sending time of the current transaction and the ending time of the previous transaction is equal to the first preset duration;

[0032] If so, the current transaction is sent according to the second rule; wherein the second rule is: the time interval between the sending time of the current transaction and the sending time of the previous transaction is equal to the second preset duration.

[0033] This application also provides an inter-chip thread communication system applied to a first chip, wherein the first chip is connected to a second chip via a full-duplex communication protocol, and the inter-chip thread communication system includes:

[0034] A state determination module is used to determine the chip state of the first chip; wherein the chip state includes a first state and a second state, the first state being a state in which there is a transaction to be sent in the chip, and the second state being a state in which there is no transaction to be sent in the chip;

[0035] The token packet transceiver module is used to send a first token packet to the second chip and receive a second token packet or a first padding packet sent by the second chip if the first chip is in the first state; wherein the first token packet, the second token packet and the first padding packet have the same transmission parameters, including the transmission time and the data length;

[0036] The data packet transceiver module is used to send a first data packet to the second chip and receive a second data packet or a second padding packet sent by the second chip; wherein the sending parameters of the first data packet, the second data packet, and the second padding packet are the same;

[0037] The handshake packet transceiver module is used to send a first handshake packet to the second chip and receive a second handshake packet or a third padding packet sent by the second chip; wherein the sending parameters of the first handshake packet, the second handshake packet and the third padding packet are the same.

[0038] This application also provides a storage medium storing a computer program thereon, wherein the computer program, when executed, implements the steps of the above-described inter-chip thread communication method.

[0039] This application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor, when calling the computer program in the memory, implements the steps of the above-described inter-chip thread communication method.

[0040] This application provides an inter-chip thread communication method applied to a first chip, wherein the first chip is connected to a second chip via a full-duplex communication protocol, and the inter-chip thread communication method includes:

[0041] Determine the chip state of the first chip; wherein the chip state includes a first state and a second state, the first state being a state in which there is a transaction to be sent in the chip, and the second state being a state in which there is no transaction to be sent in the chip;

[0042] If the first chip is in the first state, it sends a first token packet to the second chip and receives a second token packet or a first padding packet sent by the second chip; wherein the first token packet, the second token packet and the first padding packet have the same sending parameters, including the sending time and the data length;

[0043] Send a first data packet to the second chip and receive a second data packet or a second padding packet sent by the second chip; wherein the sending parameters of the first data packet, the second data packet, and the second padding packet are the same;

[0044] Send a first handshake packet to the second chip and receive a second handshake packet or a third padding packet sent by the second chip; wherein the sending parameters of the first handshake packet, the second handshake packet and the third padding packet are the same.

[0045] This application provides an inter-chip thread communication method. This method is applied to a first chip connected to a second chip via a full-duplex communication protocol. The method first determines the chip state of the first chip, including a first state with a transaction to be sent and a second state without a transaction to be sent, so as to adjust the communication behavior according to the chip state of the first chip. Specifically, during communication between the first and second chips, the transmission of transactions includes the transmission of token packets, data packets, and handshake packets. In this scheme, the first and second chips use the same transmission parameters (such as transmission time and data length) when sending different types of packets. This design reduces the complexity and uncertainty in the communication process, thereby improving the versatility of inter-chip threads. During communication, if one party has no data to send, it can send a padding packet to maintain the continuity of communication. This method makes the inter-chip thread communication process more flexible and stable, adapting to different communication needs. Therefore, this application can improve the versatility of inter-chip thread communication, and even if the application function is modified, the protocol does not need to be redesigned. This application also provides an inter-chip thread communication system, a storage medium, and an electronic device, which have the above-mentioned beneficial effects, and will not be elaborated further here. Attached Figure Description

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

[0047] Figure 1 A flowchart illustrating an inter-chip thread communication method provided in an embodiment of this application;

[0048] Figure 2 This is a schematic diagram of the structure of a token packet provided in an embodiment of this application;

[0049] Figure 3 This is a schematic diagram of the structure of a data packet provided in an embodiment of this application;

[0050] Figure 4 This is a schematic diagram of the structure of a handshake packet provided in an embodiment of this application;

[0051] Figure 5 A schematic diagram illustrating the principle of transmitting a single inter-chip transaction, provided as an embodiment of this application;

[0052] Figure 6 A schematic diagram illustrating the principle of transmitting multiple transactions between chips, provided in an embodiment of this application;

[0053] Figure 7A schematic diagram of the logical layout of a virtual thread and an inter-thread communication object in a chip, provided for an embodiment of this application;

[0054] Figure 8 This is a schematic diagram illustrating the principle of the first method for acquiring / reading ITC communication objects across chips, as provided in the embodiments of this application.

[0055] Figure 9 This is a schematic diagram illustrating the principle of the second method for acquiring / reading ITC communication objects across chips, as provided in an embodiment of this application.

[0056] Figure 10 This is a schematic diagram illustrating the principle of the third method for acquiring / reading ITC communication objects across chips, as provided in the embodiments of this application.

[0057] Figure 11 This is a schematic diagram illustrating the principle of the fourth method for acquiring / reading ITC communication objects across chips, as provided in the embodiments of this application.

[0058] Figure 12 This is a schematic diagram illustrating the principle of two chips accessing an external SPI Flash, provided as an embodiment of this application.

[0059] Figure 13 A schematic diagram illustrating the principle of two chips accessing a MOBUS slave station, provided in an embodiment of this application;

[0060] Figure 14 This is a schematic diagram of the structure of an inter-chip thread communication system provided in an embodiment of this application. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0062] Please see below. Figure 1 , Figure 1 This is a flowchart illustrating an inter-chip thread communication method provided in an embodiment of this application.

[0063] Specific steps may include:

[0064] S101: Determine the chip status of the first chip;

[0065] In this embodiment, the first chip can be applied to the second chip, which is connected to the first chip through a full-duplex communication protocol. The full-duplex communication protocol may include SPI (Serial Peripheral Interface), TCP (Transmission Control Protocol), UART (Universal Asynchronous Receiver / Transmitter), etc.

[0066] The chip state includes a first state and a second state. The first state indicates that there are pending transactions within the chip. When the chip has data or instructions that need to be sent to another chip, it is in the first state. In the first state, the chip prepares the data and waits for a suitable opportunity to send it. The second state indicates that there are no pending transactions within the chip. When there is no data or instructions that need to be sent, the chip is in the second state. In the second state, the chip may enter a low-power mode or continue to wait for new data or instructions to arrive. The pending transactions refer to communication tasks that need to be transmitted between the threads of the first chip and the threads of the second chip.

[0067] S102: If the first chip is in the first state, then send a first token packet to the second chip and receive a second token packet or a first padding packet sent by the second chip;

[0068] In this scheme, the transmission of a transaction can be broken down into three sub-steps: token packet transmission, data packet transmission, and handshake packet transmission. When the first chip is determined to be in the first state, a first token packet can be sent to the second chip according to the full-duplex communication protocol, while simultaneously receiving a second token packet or a first padding packet from the second chip. When the second chip is in the first state, this step receives the second token packet sent by the second chip; when the second chip is in the second state, this step receives the first padding packet sent by the second chip. The full-duplex communication protocol stipulates that the transmission parameters of the first token packet, the second token packet, and the first padding packet are the same, including the transmission time and data length. The aforementioned first padding packet is a packet repeatedly filled with fixed content (such as 0xFF).

[0069] S103: Send a first data packet to the second chip and receive a second data packet or a second padding packet sent by the second chip;

[0070] In step S102, after a certain delay, the first chip can send a first data packet to the second chip and simultaneously receive a second data packet or a second padding packet sent by the second chip. When the second chip is in the first state, this step receives the second data packet sent by the second chip; when the second chip is in the second state, this step receives the second padding packet sent by the second chip. The full-duplex communication protocol specifies that the sending parameters of the first data packet, the second data packet, and the second padding packet are the same. The aforementioned second padding packet is a packet repeatedly padded with fixed content (such as 0xFF). To ensure that the first data packet and the second data packet have the same data length, fixed content (such as 0xFF) can be padded to the end of the shorter data packet before sending them.

[0071] S104: Send a first handshake packet to the second chip, and receive a second handshake packet or a third padding packet sent by the second chip;

[0072] In this process, after executing S103, the second chip can send a first handshake packet after a certain delay, and simultaneously receive either a second handshake packet or a third padding packet sent by the second chip. When the second chip is in the first state, this step receives the second handshake packet sent by the second chip; when the second chip is in the second state, this step receives the third padding packet sent by the second chip. The full-duplex communication protocol specifies that the transmission parameters of the first handshake packet, the second handshake packet, and the third padding packet are the same. The aforementioned third padding packet is a packet repeatedly filled with fixed content (such as 0xFF).

[0073] This embodiment applies to a first chip connected to a second chip via a full-duplex communication protocol. The method first determines the chip state of the first chip, including a first state with pending transactions and a second state without pending transactions, in order to adjust communication behavior based on the chip state. Specifically, during communication between the first and second chips, transaction transmission includes the transmission of token packets, data packets, and handshake packets. In this scheme, both the first and second chips use the same transmission parameters (such as transmission time and data length) when sending different types of packets. This design reduces the complexity and uncertainty of the communication process, thereby improving the versatility of inter-chip threads. During communication, if one party has no data to send, it can send a padding packet to maintain communication continuity. This method makes inter-chip thread communication more flexible and stable, adapting to different communication needs. Therefore, this embodiment improves the versatility of inter-chip thread communication, and even if application functions are modified, the protocol does not need to be redesigned.

[0074] As for Figure 1In a further description of the corresponding embodiment, after determining the chip state of the first chip, if the first chip is in the second state and the second chip is in the first state, the following operations can be performed:

[0075] Step A1: Send a fourth padding packet to the second chip and receive a second token packet sent by the second chip;

[0076] If the first chip is in the second state and the second chip is in the first state, it means that the first chip has no transactions to send to the second chip, while the second chip has transactions to send to the first chip. The first chip can send a fourth padding packet to the second chip and simultaneously receive a second token packet sent by the second chip. The full-duplex communication protocol stipulates that the sending parameters of the fourth padding packet and the second token packet are the same.

[0077] Step A2: Send the fifth padding packet to the second chip and receive the second data packet sent by the second chip;

[0078] After executing step A1, the first chip can send a fifth padding packet to the second chip after a certain delay, and at the same time receive the second data packet sent by the second chip; the full-duplex communication protocol stipulates that the sending parameters of the fifth padding packet and the second data packet are the same.

[0079] Step A3: Send the sixth padding packet to the second chip and receive the second handshake packet sent by the second chip;

[0080] After executing step A2, the first chip can send a sixth padding packet to the second chip after a certain delay, and at the same time receive the second handshake packet sent by the second chip; the full-duplex communication protocol stipulates that the sending parameters of the sixth padding packet and the second handshake packet are the same.

[0081] As for Figure 1 In a further description of the corresponding embodiment, after determining the chip state of the first chip, if both the first chip and the second chip are in the second state, it means that neither the first chip nor the second chip has any transactions to send to each other. At this time, the first chip can periodically send the seventh padding packet to the second chip and simultaneously receive the eighth padding packet periodically sent by the second chip. The full-duplex communication protocol stipulates that the sending parameters of the seventh padding packet and the eighth padding packet are the same.

[0082] As for Figure 1In a further description of the corresponding embodiment, the first chip can determine whether both the first chip and the second chip were in the second state when sending the previous transaction; if not, the current transaction is sent according to the first rule; wherein, the first rule is: the time interval between the sending time of the current transaction and the ending time of the previous transaction is equal to a first preset duration; if yes, the current transaction is sent according to the second rule; wherein, the second rule is: the time interval between the sending time of the current transaction and the sending time of the previous transaction is equal to a second preset duration.

[0083] In this embodiment, transactions containing only padding bytes can be referred to as Type II transactions, while all other transactions can be referred to as Type I transactions. Specifically, there are four scenarios when transferring transactions between chips:

[0084] Scenario 1: During the last transaction transmission, both the first chip and the second chip sent a first type of transaction;

[0085] Scenario 2: During the last transaction transmission, the first chip sent the first type of transaction, and the second chip sent the second type of transaction;

[0086] Scenario 3: During the last transaction transmission, the first chip sent a second type of transaction, and the second chip sent a first type of transaction;

[0087] Scenario 4: During the last transaction transmission, both the first chip and the second chip sent the second type of transaction.

[0088] This embodiment has the following two preset rules:

[0089] Rule 1: The interval between the time a transaction is sent and the time the previous transaction ends is equal to the first preset duration;

[0090] Rule 2: The interval between the time of transaction sending and the time of the previous transaction sending is equal to the second preset duration;

[0091] If the situation falls under conditions 1, 2, and 3, rule 1 above applies; if the situation falls under condition 4, rule 2 above applies.

[0092] This solution enables the first chip to precisely control the sending time of various data packets according to preset rules, ensuring that there is a sufficient time interval between the first token packet and the previous transaction, and that the token packet, data packet and handshake packet maintain a constant interval, thereby improving communication efficiency and stability.

[0093] As Figure 1In a further description of the corresponding embodiment, the RTOS kernel of the first chip includes a first virtual thread, and the RTOS kernel of the second chip includes a second virtual thread. The first and second virtual threads never transition to the ready or running state, and they do not have stack space. Corresponding ITC communication objects exist in the first and second chips; that is, if the first chip has an ITC communication object with ID i, then the second chip also has an ITC communication object with ID i; if the second chip has an ITC communication object with ID j, then the first chip also has an ITC communication object with ID j; the ITC communication objects with the same ID in the first and second chips are of the same type.

[0094] Accordingly, if the ITC communication object corresponding to the first target ID inside the first chip is ITC communication object A, and the ITC communication object corresponding to the first target ID inside the second chip is ITC communication object A', then the inter-chip thread communication process further includes the following steps:

[0095] Step B1: When the first thread of the first chip calls the ITC communication object corresponding to the first target ID through the blocking interface, obtain the ITC communication object A inside the first chip;

[0096] ITC (Inter-Thread Communication) refers to inter-thread communication.

[0097] Step B2: If the ITC communication object A cannot be obtained from the first chip, a blocking acquisition request transaction is initiated to the second chip based on the full-duplex communication protocol, so that the RTOS kernel of the second chip records that the second virtual thread is requesting the ITC communication object A' in a blocking manner;

[0098] In this process, the ITC communication object A is first obtained inside the first chip. If the ITC communication object A cannot be obtained inside the first chip (e.g., another thread has already obtained the ITC communication object A), a blocking acquisition request transaction can be initiated to the second chip based on the full-duplex communication protocol (i.e., sending the token packet, data packet and handshake packet corresponding to the blocking acquisition request transaction).

[0099] Upon receiving this blocking acquisition request, the second chip's RTOS kernel records that the second virtual thread is requesting the ITC communication object A' within the second chip in a blocking manner. This process utilizes the full-duplex communication protocol and the RTOS kernel's blocking acquisition mechanism to simulate inter-thread communication within the chip itself.

[0100] Step B3: If the second virtual thread successfully acquires the ITC communication object A', it initiates a successful acquisition transaction through full-duplex communication to notify the RTOS kernel of the first chip that it has successfully acquired the target ITC communication object (i.e., ITC communication object A'), so that the RTOS kernel of the first chip controls the first virtual thread to release the ITC communication object A, thereby enabling the first thread to acquire the ITC communication object A released by the first virtual thread.

[0101] The role of the second virtual thread is to simulate the first chip, or in other words, to act as a proxy for the first chip within the second chip. When the second virtual thread acquires the ITC communication object A', it means that the second chip has allocated resources to the first chip. The first virtual thread within the first chip, acting as a proxy for the second chip, needs to release the ITC communication object A through this proxy to indicate that the first chip has received resources from the second chip.

[0102] Once the RTOS kernel of the second chip confirms that the second virtual thread has successfully acquired the ITC communication object A', the second virtual thread can notify the RTOS kernel of the first chip via a protocol to release the ITC communication object A through the first virtual thread. At this time, the RTOS kernel of the first chip will record a virtual "release" operation, indicating that the first virtual thread has released the ITC communication object A. As a feasible implementation, this embodiment can add an interface to the RTOS kernel to obtain ITC communication objects specifically used for inter-chip thread communication. After inputting the ID of the ITC communication object into this interface, the corresponding ITC communication object instance can be obtained. The ITC communication objects in the first chip and the second chip can be mapped one-to-one using the above interface. In the above process, the ITC communication object acquired by the first thread actually comes from inside the second chip, but in the first chip, the acquired ITC communication object is marked as coming from the first virtual thread. The above process simulates the thread communication between the two chips as inter-thread communication within the chip, improving communication efficiency and reducing communication complexity.

[0103] As a feasible implementation, if the second thread of the first chip releases the ITC communication object A before the first thread acquires it, and the first thread acquires the ITC communication object A, then a cancellation acquisition request transaction is initiated to the second chip, so that the RTOS kernel of the second chip controls the second virtual thread to cancel the request for the ITC communication object A'. This method allows priority control over the first thread's acquisition of this released internal ITC communication object of the chip.

[0104] Before initiating a blocking acquisition request transaction, this embodiment first attempts to obtain the ITC communication object corresponding to the target ID from the internal memory of the first chip. If the acquisition is successful within the first chip, the process ends and returns a success message. If the acquisition fails within the first chip, a blocking acquisition request transaction is initiated.

[0105] If the first thread obtains the ITC communication object corresponding to the target ID released by another thread from the first chip, and has not initiated a blocking acquisition request transaction, then there is no need to initiate a cancellation acquisition request transaction. If the first thread obtains the ITC communication object corresponding to the target ID released by another thread from the first chip, and has already initiated a blocking acquisition request transaction, then it needs to initiate a cancellation acquisition request transaction to notify the second chip to cancel the acquisition request.

[0106] As Figure 1 In a further description of the corresponding embodiment, if the ITC communication object corresponding to the second target ID inside the first chip is ITC communication object B, and the ITC communication object corresponding to the second target ID inside the second chip is ITC communication object B', then the inter-chip thread communication process further includes the following steps:

[0107] Step C1: When the third thread of the first chip calls the ITC communication object corresponding to the second target ID through the non-blocking interface, it first attempts to obtain the ITC communication object B inside the first chip.

[0108] Step C2: If the ITC communication object B cannot be obtained from the first chip, a non-blocking acquisition request transaction is initiated to the second chip based on the full-duplex communication protocol, so that the RTOS kernel of the second chip controls the second virtual thread to attempt to request the ITC communication object B' in a non-blocking manner;

[0109] In this process, the first attempt is made to obtain ITC communication object B within the first chip. If ITC communication object B cannot be obtained within the first chip (e.g., another thread has already obtained ITC communication object B), a non-blocking acquisition request transaction can be initiated to the second chip based on the full-duplex communication protocol (i.e., sending the token packet, data packet, and handshake packet corresponding to the non-blocking acquisition request transaction).

[0110] After receiving this non-blocking acquisition request, the RTOS kernel within the second chip controls a second virtual thread to attempt to request the ITC communication object B' within the second chip in a non-blocking manner. This process utilizes the full-duplex communication protocol and the RTOS kernel's non-blocking acquisition mechanism to simulate inter-thread communication within the chip itself, transforming the inter-chip communication between the two chips into inter-thread communication within the chip itself.

[0111] Step C3: If the second virtual thread successfully acquires the ITC communication object B', it initiates a successful acquisition transaction through full-duplex communication to notify the RTOS kernel of the first chip that it has successfully acquired the target ITC communication object (i.e., ITC communication object B'), so that the RTOS kernel of the first chip controls the first virtual thread to release the ITC communication object B, and the third thread acquires the ITC communication object B released by the first virtual thread.

[0112] Once the RTOS kernel of the second chip confirms that the second virtual thread has successfully acquired the ITC communication object B', the second virtual thread can notify the RTOS kernel of the first chip via a protocol to control the first virtual thread to release the ITC communication object B. At this time, the RTOS kernel of the first chip will record a virtual "release" operation, indicating that the first virtual thread has released the ITC communication object B. In the above process, the ITC communication object acquired by the third thread actually comes from the second chip, but in the first chip, the acquired ITC communication object is marked as coming from the ITC communication object released by the first virtual thread. The above process simulates the thread communication between the two chips as inter-thread communication within the chip, improving communication efficiency and reducing communication complexity.

[0113] In this application, the first thread, the second thread, and the third thread can transition to the ready and running states, and also have stack space, making them the actual operating units within the process.

[0114] Step C4: If the second virtual thread cannot obtain the ITC communication object B', then control the RTOS kernel of the first chip to return the failure information through the non-blocking interface so that the third thread can continue to execute other tasks.

[0115] Specifically, if the second virtual thread fails to acquire the ITC communication object B', it returns a failure message through a non-blocking interface. At this point, the third thread can be allowed to execute other tasks instead of continuously waiting for the ITC communication object to be acquired. This process simulates inter-chip communication as intra-chip inter-thread communication, improving communication efficiency and reducing communication complexity.

[0116] The process described in the above embodiments is illustrated below through examples in practical applications.

[0117] Challenges encountered during product development often stem from performance optimization requirements or chip design for specific application scenarios. In some cases, to meet these needs, a product may require integrating two microcontroller units (MCUs) specifically designed for different application areas, or combining an MCU with a digital signal processor (DSP). This design strategy aims to maximize the performance advantages of each chip to adapt to different workloads.

[0118] The aforementioned chips typically deploy a real-time operating system (RTOS). In practical applications, RTOS threads may be assigned to different chips for execution based on their application characteristics. To ensure seamless collaboration between threads on different chips, appropriate solutions need to be designed to enable effective communication between threads on two chips.

[0119] The solution for achieving inter-chip thread communication in related technologies is as follows: connect an inter-chip communication bus such as SPI or IIC between the two chips, design a special communication protocol for different application scenarios, and perform corresponding operations according to the protocol definition when the two chips need to communicate.

[0120] The protocol designs of the aforementioned technologies are characterized by complexity and high customization, resulting in a relatively narrow scope of application. Different protocols need to be designed for different application functions; once the application function is modified, the protocol content needs to be readjusted or modified accordingly. Furthermore, the programming of these technologies is complex; due to the high degree of customization, any change in application function requires a complete overhaul of the protocol content, necessitating modifications to both the application code and the protocol code.

[0121] To address the shortcomings of the aforementioned related technologies, this application provides a solution for multi-chip RTOS thread communication based on SPI. This solution proposes a protocol design and a method for modifying the RTOS kernel.

[0122] This embodiment designs a general inter-thread communication protocol that does not require redesigning even if application functionality is modified. The protocol design of this embodiment is described below:

[0123] In this embodiment, the underlying protocol for inter-chip RTOS thread communication is sampled from the SPI protocol, and the protocol is designed specifically for inter-thread communication. The SPI protocol designed in this embodiment includes the concepts of transactions and packets, with multiple packets forming different transactions. This embodiment also designs three types of packets: token packets, data packets, and handshake packets.

[0124] The token packet consists of 10 bytes. Byte 0 is always filled with 0x5A to indicate the start of the packet; Bytes 1 and 2 are always filled with 0x0A5F to indicate the start of a transaction; Byte 3 indicates different inter-thread communication (ITC) types, including queues, binary semaphores, semaphores, mutexes, recursive mutexes, and event groups (collectively referred to as ITC communication objects); Byte 4 indicates different operation types, including blocking acquire / read requests, canceled acquire / read requests, non-blocking acquire / read requests, successful read / acquire, and failed read / acquire; Bytes 5 and 6 indicate the ID of the operation object; Byte 7 indicates the length of the data in the following packet; Byte 8 is used for message verification, ranging from Bytes 3 to 7; Byte 9 is always filled with 0xA5 to indicate the end of the packet. See also... Figure 2 , Figure 2 This is a schematic diagram of the structure of a token packet provided in an embodiment of this application. Figure 2 The meanings of the characters in are as follows:

[0125] SOP indicates the start of a packet, with a fixed padding of 0x5A.

[0126] SOT indicates the start of a transaction, and is always filled with 0x0A5F.

[0127] The value of Type can be 0~5, where Type=0 represents a queue, Type=1 represents a binary semaphore, Type=2 represents a semaphore, Type=3 represents a mutex, Type=4 represents a recursive mutex, and Type=5 represents an event group.

[0128] The value of Opt can be from 0 to 4. Opt=0 indicates a blocking get / read request, Opt=1 indicates a canceled get / read request, Opt=2 indicates a non-blocking get / read request, Opt=3 indicates a successful read / get, and Opt=4 indicates a failed read / get.

[0129] ID represents the ID of the object being operated on;

[0130] Len indicates the length of the data in the data packet, which is in bytes;

[0131] CRC8 represents the checksum for Type, Opt, ID, and Len;

[0132] EOP indicates the end of the packet, and is filled with 0xA5.

[0133] The length of the data packet is determined by the length of the data being sent. In the data packet, Byte 0 is always filled with 0x5A to indicate the start of the packet; Bytes 1-n are used to fill in the data, the length of which is determined by Byte 7 of the token packet. The two bytes following the data are used for message verification, with the verification range being Bytes 1-n; the next byte is always filled with 0xA5 to indicate the end of the packet; there may be some additional padding bytes after the packet ends. See also... Figure 3 , Figure 3 This is a schematic diagram of the structure of a data packet provided in an embodiment of this application. Figure 3 The meanings of the characters in are as follows:

[0134] SOP indicates the start of a packet, with a fixed padding of 0x5A.

[0135] Data represents all the data in the transaction, and the length n of Data is equal to the Len field in the token packet;

[0136] CRC16 represents the checksum for Data;

[0137] EOP indicates the end of the packet, and is filled with 0xA5.

[0138] Padding represents a padding value of 0xFF. If the length of Data in the data packets sent between the two chips is equal, then there is no padding value. If the length of Data in the data packets sent between the two chips is not equal, then there may be padding value to make the length of the data packets sent by the two chips equal.

[0139] The handshake packet is fixed at 3 bytes in length. Byte 0 is always filled with 0x5A to indicate the start of the packet; Byte 1 indicates the data reception result; and Byte 2 is always filled with 0xA5 to indicate the end of the handshake. (See also...) Figure 4 , Figure 4 This is a schematic diagram of the structure of a handshake packet provided in an embodiment of this application. Figure 4 The meanings of the characters in are as follows:

[0140] SOP indicates the start of a packet, with a fixed padding of 0x5A.

[0141] ACK indicates the response result; ACK=0x78 indicates a correct response, and ACK=0x87 indicates an incorrect response.

[0142] EOP indicates the end of the packet, and is filled with 0xA5.

[0143] Transactions between chips include token packets, data packets, and handshake packets. In a two-chip communication architecture, one chip acts as the SPI master, and the other as the SPI slave. The SPI master sends a token packet to the SPI slave, while the SPI slave simultaneously sends its own token packet to the SPI master. Then, the SPI master sends a data packet to the SPI slave, and the SPI slave sends a data packet to the SPI master. If the data packet lengths are different, the shorter data packet is padded at the end to make the number of bytes sent equal. Finally, the SPI master sends a handshake packet to the SPI slave in response, and the SPI slave sends a handshake packet to the SPI master in response. Each packet is spaced 100 microseconds apart to facilitate packet parsing. To avoid the SPI communication rate affecting the real-time performance of the RTOS, an SPI communication rate of 10 Mbps or higher is required. Please refer to [link to relevant documentation]. Figure 5 , Figure 5 This diagram illustrates the principle of transmitting a single transaction between chips, as provided in an embodiment of this application. CS represents the Chip Select signal line, MOSI (Master Out Slave In) represents the master-slave input signal line, and MISO (Master In Slave Out) represents the master-slave output signal line. The diagram shows the transmission process of token packets, data packets, and handshake packets. The two chips transmit token packets, data packets, and handshake packets at the same time. Padding may be added after the data packets to maintain the same data length.

[0144] Please see Figure 6 , Figure 6 This is a schematic diagram of the principle of sending multiple transactions between chips provided in an embodiment of this application. When one side of the SPI master and slave has a transaction to send while the other side does not, the side that does not need to send a transaction fills the packet with all 0xFF bytes. In order to balance CPU utilization and ensure the real-time performance of the RTOS, when there are multiple transactions to be transmitted, the SPI master needs to insert a delay of 100 microseconds between each transaction. When the SPI master detects that neither the SPI master nor slave has a transaction to send, it initiates a transaction transmission of all padding bytes (0xFF) every 3 milliseconds.

[0145] It is evident that the above protocol design utilizes the characteristics of SPI to achieve bidirectional full-duplex transmission of transactions, and controls the data transmission interval to balance data real-time performance and CPU utilization.

[0146] In this embodiment, the modifications to the RTOS kernel include kernel initialization modifications, RTOS kernel blocking interface modifications, and RTOS kernel non-blocking interface modifications. By modifying the RTOS kernel, this embodiment can simulate the inter-thread communication method within the chip, making inter-chip thread communication almost indistinguishable from internal inter-thread communication for application developers. When modifying application functions, developers only need to focus on modifying the application code without worrying about the communication details, and it also facilitates access to external shared resources by both chips.

[0147] The kernel initialization modifications are as follows:

[0148] During kernel initialization, a virtual thread is created. This thread simulates an external chip and holds the ITC communication object acquired by another chip. This virtual thread never transitions to the ready or running state and has no stack space. Kernel initialization requires the creation of dedicated ITC communication objects for inter-chip thread communication. These objects are organized as arrays, with array indices corresponding to object IDs. See also... Figure 7 , Figure 7 This embodiment illustrates the logical layout of a virtual thread and inter-thread communication object within a chip, as provided in this application. Chip 1 and Chip 2 are connected by a chip select signal line CS, a clock signal line CLK, a master-slave input / output signal line MOSI, and a master-slave output / output signal line MISO. Both Chip 1 and Chip 2 internally include virtual threads and ITC communication objects. The ITC communication objects are organized in array form, including queues, binary semaphores, semaphores, event groups, mutexes, and recursive mutexes. ID0, ID1, ID2…, ID(n-1), and IDn represent the identifiers of the ITC communication objects. Objects of the same type and ID correspond one-to-one between the two chips. This embodiment can also add an interface to the RTOS kernel to obtain a dedicated ITC communication object for inter-chip thread communication. This interface returns an instance of an RTOS kernel ITC communication object by inputting an object ID.

[0149] The RTOS kernel blocking interface has been modified as follows:

[0150] When a thread in chip 1 calls the blocking interface to acquire / read an ITC communication object, it first attempts to acquire / read from within the chip. If the acquisition / read fails internally, the RTOS kernel uses the SPI communication protocol to initiate a blocking acquire / read request transaction to chip 2. After receiving the transaction, the RTOS kernel in chip 2 records that the virtual thread is requesting to acquire / read the ITC communication object. Please refer to [link to relevant documentation]. Figure 8 , Figure 8This is a schematic diagram illustrating the principle of the first cross-chip acquisition / reading of ITC communication objects provided in this application embodiment. The diagram shows that: other threads of chip 1 block to acquire ITC communication objects from the RTOS kernel of chip 1. The RTOS kernel of chip 1 notifies SPI to initiate communication so that chip 1 can send a blocking acquisition / reading request via SPI communication. After receiving the blocking acquisition / reading request via SPI communication, the RTOS kernel of chip 2 can return response information and record that the virtual thread is requesting to acquire / read the object. Chip 2 may also include other threads.

[0151] When another thread in chip 2 releases / sends the corresponding ITC communication object, and it is successfully acquired by a virtual thread in chip 2, the RTOS kernel uses the SPI communication protocol to notify chip 2 that the reading / acquisition of the ITC communication object was successful. Chip 1 records that the virtual thread released / sent the ITC communication object. When the ITC communication object released / sent by the virtual thread is read / acquired by another thread, the blocking function of that other thread returns successfully. Please refer to [link to relevant documentation]. Figure 9 , Figure 9 This is a schematic diagram illustrating the principle of the second cross-chip acquisition / reading of ITC communication objects provided in this application embodiment. The diagram shows that after other threads of chip 2 release / send the ITC communication object, the RTOS kernel of chip 2 records that the ITC object has been acquired / read by the virtual thread and notifies chip 1 of the successful acquisition / reading via SPI communication. Chip 1 returns response information via SPI communication. The RTOS of chip 1 records that the virtual thread releases / sends the ITC communication object. Other threads of chip 1 successfully acquire / read the object and perform the operation of returning from the blocking function.

[0152] When another thread 2 in chip 1 is blocked from acquiring an ITC communication object, and another thread 1 in chip 1 releases / sends the corresponding ITC communication object, which is then successfully acquired by thread 2, the RTOS kernel will initiate a cancellation of the acquisition / read transaction via the SPI protocol, notifying chip 2 that chip 1 will no longer request the ITC communication object. Please refer to [link to relevant documentation]. Figure 10 , Figure 10This is a schematic diagram illustrating the principle of the third cross-chip acquisition / reading of ITC communication objects provided in this application embodiment. The diagram shows: another thread 2 of chip 1 blocks the acquisition of the ITC communication object from the RTOS kernel of chip 1. The RTOS kernel of chip 1 notifies the SPI to initiate communication so that chip 1 can send a blocking acquisition / reading request via SPI communication. After receiving the blocking acquisition / reading request via SPI communication, the RTOS kernel of chip 2 can return a response message and record that the virtual thread is requesting to acquire / read the ITC communication object. Chip 2 may also include other threads. If another thread 1 in chip 1 releases / sends the ITC communication object and informs the RTOS kernel, and the other thread 2 in chip 1 successfully acquires / reads the ITC communication object and performs a kernel interface return operation, the RTOS kernel of chip 1 notifies the SPI to initiate communication so that chip 1 can cancel the acquisition / reading request via SPI communication. After receiving the cancellation request via SPI communication, the RTOS kernel of chip 2 can return a response message and record that the virtual thread has canceled the request to acquire / read the ITC communication object.

[0153] The RTOS kernel non-blocking interface has been modified as follows:

[0154] When a thread in chip 1 calls the non-blocking interface to acquire / read an ITC communication object, it first attempts to acquire / read it internally. If the internal acquisition / read fails, the RTOS kernel initiates a non-blocking acquire / read request transaction to chip 2 using the SPI communication protocol. After receiving the transaction, the RTOS kernel of chip 2 checks whether the corresponding ITC communication object has resources that can be read / acquired, and returns the result to chip 1 via the SPI protocol. The RTOS kernel of chip 1 then returns the result to the thread that called the interface. Please refer to [link to relevant documentation]. Figure 11 , Figure 11 This is a schematic diagram illustrating the principle of the fourth cross-chip acquisition / reading of ITC communication objects provided in this application embodiment. The diagram shows: other threads of chip 1 acquire the ITC communication object non-blockingly from the RTOS kernel of chip 1. The RTOS kernel of chip 1 notifies the SPI to initiate communication, so that chip 1 can send a non-blocking acquisition / reading request via SPI communication. After receiving the non-blocking acquisition / reading request via SPI communication, the RTOS kernel of chip 2 can return response information and record that a virtual thread is attempting to acquire / read the ITC communication object non-blockingly. Chip 2 also includes other threads. The RTOS kernel of chip 2 can return the non-blocking acquisition / reading result. If the acquisition / reading is successful, it records that the virtual thread has acquired / read the ITC communication object. If the ITC communication object is successfully read / acquired, chip 1 records that the virtual thread has released / sent the ITC communication object, and other threads execute non-blocking function return operations.

[0155] The communication protocol designed in this embodiment is used to simulate inter-thread communication and is independent of specific applications. Even if application functionality is modified, the protocol does not need to be adjusted. This embodiment modifies the RTOS kernel to simulate inter-thread communication between two chips as inter-thread communication within the chip. Application developers can write code using methods for inter-thread communication within the chip, simplifying programming. After modification, it can very easily handle situations where two chips access shared external resources.

[0156] After adopting the above scheme, when any two chips need to access an external SPI Flash (a non-volatile memory chip based on the Serial Peripheral Interface protocol) simultaneously, connect the SPI interfaces of both chips to the SPI Flash chip and configure the pins to open-drain output, using pull-up resistors to pull them up to the power supply. When the two chips access the SPI Flash chip, a dedicated mutex for inter-chip thread communication is used to achieve mutual exclusion. Please refer to [link to relevant documentation]. Figure 12 , Figure 12 This is a schematic diagram of the principle of two chips accessing an external SPI Flash according to an embodiment of this application. The diagram shows chip 1, chip 2, SPI Flash chip, chip select signal line CS, clock signal line CLK, master output / slave input signal line MOSI and master input / slave output signal line MISO.

[0157] After adopting the above scheme, if both chips act as MODBUS (a serial communication protocol) masters and need to access the same MODBUS slave, connecting the 485 buses of the two chips together and using a mutex specifically for inter-chip thread communication to achieve mutual exclusion access to the 485 bus will allow two MODBUS masters to access the same MODBUS slave on a single bus. Please refer to [link to relevant documentation]. Figure 13 , Figure 13 This is a schematic diagram illustrating the principle of two chips accessing a MOBUS slave station according to an embodiment of this application. The diagram shows chip 1, chip 2, MOBUS slave station 1, MOBUS slave station 2, ..., MOBUS slave station n.

[0158] Please see Figure 14 , Figure 14 This is a schematic diagram of an inter-chip thread communication system provided in an embodiment of this application; the system can be applied to a first chip, which is connected to a second chip via a full-duplex communication protocol. The inter-chip thread communication system includes:

[0159] The status determination module 1401 is used to determine the chip status of the first chip; wherein the chip status includes a first status and a second status, the first status is that there is a transaction to be sent in the chip, and the second status is that there is no transaction to be sent in the chip;

[0160] The token packet transceiver module 1402 is used to send a first token packet to the second chip and receive a second token packet or a first padding packet sent by the second chip if the first chip is in the first state; wherein the first token packet, the second token packet and the first padding packet have the same sending parameters, including the sending time and the data length;

[0161] The data packet transceiver module 1403 is used to send a first data packet to the second chip and receive a second data packet or a second padding packet sent by the second chip; wherein the sending parameters of the first data packet, the second data packet, and the second padding packet are the same;

[0162] The handshake packet transceiver module 1404 is used to send a first handshake packet to the second chip and receive a second handshake packet or a third padding packet sent by the second chip; wherein the sending parameters of the first handshake packet, the second handshake packet and the third padding packet are the same.

[0163] This embodiment applies to a first chip connected to a second chip via a full-duplex communication protocol. The method first determines the chip state of the first chip, including a first state with pending transactions and a second state without pending transactions, in order to adjust communication behavior based on the chip state. Specifically, during communication between the first and second chips, transaction transmission includes the transmission of token packets, data packets, and handshake packets. In this scheme, both the first and second chips use the same transmission parameters (such as transmission time and data length) when sending different types of packets. This design reduces the complexity and uncertainty of the communication process, thereby improving the versatility of inter-chip threads. During communication, if one party has no data to send, it can send a padding packet to maintain communication continuity. This method makes inter-chip thread communication more flexible and stable, adapting to different communication needs. Therefore, this embodiment improves the versatility of inter-chip thread communication, and even if application functions are modified, the protocol does not need to be redesigned.

[0164] Furthermore, the RTOS kernel of the first chip includes a first virtual thread, and the RTOS kernel of the second chip includes a second virtual thread; there are corresponding ITC communication objects in the first chip and the second chip;

[0165] Correspondingly, it also includes:

[0166] The blocking interface call module is used to obtain the ITC communication object A inside the first chip when the first thread of the first chip calls the ITC communication object corresponding to the first target ID through the blocking interface; wherein, the ITC communication object inside the first chip corresponding to the first target ID is the ITC communication object A, and the ITC communication object inside the second chip corresponding to the first target ID is the ITC communication object A'; it is also used to initiate a blocking acquisition request transaction to the second chip based on the full-duplex communication protocol if the ITC communication object A cannot be obtained from the first chip, so that the RTOS kernel of the second chip records that the second virtual thread is requesting the ITC communication object A' in a blocking manner; it is also used to initiate an acquisition success transaction through full-duplex communication to notify the RTOS kernel of the first chip of the successful acquisition of the target ITC communication object if the second virtual thread successfully acquires the ITC communication object A', so that the RTOS kernel of the first chip controls the first virtual thread to release the ITC communication object A, and the first thread acquires the ITC communication object A released by the first virtual thread.

[0167] Furthermore, it also includes:

[0168] The request cancellation module is used to initiate a cancellation acquisition request transaction to the second chip before the first thread acquires the ITC communication object A released by the first virtual thread. If the second thread of the first chip releases the ITC communication object A and the first thread acquires the ITC communication object A, the module will cause the RTOS kernel of the second chip to control the second virtual thread to cancel the request for the ITC communication object A'.

[0169] Furthermore, it also includes:

[0170] The non-blocking interface call module is used to obtain the ITC communication object B inside the first chip when the third thread of the first chip calls the ITC communication object corresponding to the second target ID through a non-blocking interface; wherein, the ITC communication object inside the first chip corresponding to the second target ID is the ITC communication object B, and the ITC communication object inside the second chip corresponding to the second target ID is the ITC communication object B'; it is also used to initiate a non-blocking acquisition request transaction to the second chip based on the full-duplex communication protocol if the ITC communication object B cannot be obtained from the first chip, so that the RTOS kernel of the second chip controls the second virtual thread to obtain the ITC communication object B' through the non-blocking interface. The method is as follows: The method requests the ITC communication object B' via a blocking mechanism; if the second virtual thread successfully acquires the ITC communication object B', it initiates a successful acquisition transaction via full-duplex communication to notify the RTOS kernel of the first chip of the successful acquisition of the target ITC communication object, so that the RTOS kernel of the first chip controls the first virtual thread to release the ITC communication object B, and the third thread acquires the ITC communication object B released by the first virtual thread; if the second virtual thread fails to acquire the ITC communication object B', it controls the RTOS kernel of the first chip to return an acquisition failure message through a non-blocking interface, so that the third thread can continue to execute other tasks.

[0171] Furthermore, it also includes:

[0172] The token packet transceiver module 1402 is further configured to send a fourth padding packet to the second chip and receive a second token packet sent by the second chip if the first chip is in the second state and the second chip is in the first state; wherein the sending parameters of the fourth padding packet and the second token packet are the same;

[0173] The data packet transceiver module 1403 is also used to send a fifth padding packet to the second chip and receive a second data packet sent by the second chip; wherein the sending parameters of the fifth padding packet and the second data packet are the same;

[0174] The handshake packet transceiver module 1404 is also used to send a sixth padding packet to the second chip and receive a second handshake packet sent by the second chip; wherein the sending parameters of the sixth padding packet and the second handshake packet are the same.

[0175] Furthermore, it also includes:

[0176] The fill packet transceiver module is used to, after determining the chip state of the first chip, if both the first chip and the second chip are in the second state, periodically send a seventh fill packet to the second chip and receive an eighth fill packet periodically sent by the second chip; wherein the transmission parameters of the seventh fill packet and the eighth fill packet are the same.

[0177] Furthermore, it also includes:

[0178] The transmission time control module is used to determine whether the first chip and the second chip were both in the second state when transmitting the previous transaction; if not, the current transaction is transmitted according to the first rule; wherein the first rule is: the time interval between the transmission time of the current transaction and the end time of the previous transaction is equal to a first preset duration; if yes, the current transaction is transmitted according to the second rule; wherein the second rule is: the time interval between the transmission time of the current transaction and the transmission time of the previous transaction is equal to a second preset duration.

[0179] Since the embodiments of the system part correspond to the embodiments of the method part, please refer to the description of the embodiments of the method part for the embodiments of the system part, and they will not be repeated here.

[0180] This application also provides a storage medium on which a computer program is stored, which, when executed, can perform the steps provided in the above embodiments. The storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0181] This application also provides an electronic device that may include a memory and a processor. The memory stores a computer program, and when the processor calls the computer program in the memory, it can implement the steps provided in the above embodiments. Of course, the electronic device may also include various network interfaces, power supplies, and other components.

[0182] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to the method section. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

[0183] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A method for inter-chip thread communication, characterized in that, Applied to a first chip, which is connected to a second chip via a full-duplex communication protocol, the inter-chip thread communication method includes: Determine the chip state of the first chip; wherein the chip state includes a first state and a second state, the first state being a state in which there is a transaction to be sent in the chip, and the second state being a state in which there is no transaction to be sent in the chip; If the first chip is in the first state, it sends a first token packet to the second chip and receives a second token packet or a first padding packet sent by the second chip; wherein the first token packet, the second token packet and the first padding packet have the same sending parameters, including the sending time and the data length; Send a first data packet to the second chip and receive a second data packet or a second padding packet sent by the second chip; wherein the sending parameters of the first data packet, the second data packet, and the second padding packet are the same; Send a first handshake packet to the second chip and receive a second handshake packet or a third padding packet sent by the second chip; wherein the sending parameters of the first handshake packet, the second handshake packet and the third padding packet are the same.

2. The inter-chip thread communication method according to claim 1, characterized in that, The RTOS kernel of the first chip includes a first virtual thread, and the RTOS kernel of the second chip includes a second virtual thread; there are corresponding ITC communication objects in the first chip and the second chip; Correspondingly, it also includes: When the first thread of the first chip calls the ITC communication object corresponding to the first target ID through the blocking interface, the ITC communication object A inside the first chip is obtained; wherein, the ITC communication object inside the first chip corresponding to the first target ID is the ITC communication object A, and the ITC communication object inside the second chip corresponding to the first target ID is the ITC communication object A'. If the ITC communication object A cannot be obtained from the first chip, a blocking acquisition request transaction is initiated to the second chip based on the full-duplex communication protocol, so that the RTOS kernel of the second chip records that the second virtual thread is requesting the ITC communication object A' in a blocking manner; If the second virtual thread successfully acquires the ITC communication object A', it initiates a successful acquisition transaction through full-duplex communication to notify the RTOS kernel of the first chip that it has successfully acquired the target ITC communication object, so that the RTOS kernel of the first chip can control the first virtual thread to release the ITC communication object A, and the first thread can acquire the ITC communication object A released by the first virtual thread.

3. The inter-chip thread communication method according to claim 2, characterized in that, Before the first thread acquires the ITC communication object A released by the first virtual thread, the method further includes: If the second thread of the first chip releases the ITC communication object A, and the first thread acquires the ITC communication object A, then it initiates a cancellation acquisition request transaction to the second chip, so that the RTOS kernel of the second chip controls the second virtual thread to cancel the request for the ITC communication object A'.

4. The inter-chip thread communication method according to claim 2, characterized in that, Also includes: When the third thread of the first chip calls the ITC communication object corresponding to the second target ID through a non-blocking interface, the ITC communication object B inside the first chip is obtained; wherein, the ITC communication object inside the first chip corresponding to the second target ID is the ITC communication object B, and the ITC communication object inside the second chip corresponding to the second target ID is the ITC communication object B'. If the ITC communication object B cannot be obtained from the first chip, a non-blocking acquisition request transaction is initiated to the second chip based on the full-duplex communication protocol, so that the RTOS kernel of the second chip controls the second virtual thread to request the ITC communication object B' in a non-blocking manner; If the second virtual thread successfully acquires the ITC communication object B', it initiates a successful acquisition transaction through full-duplex communication to notify the RTOS kernel of the first chip that it has successfully acquired the target ITC communication object, so that the RTOS kernel of the first chip controls the first virtual thread to release the ITC communication object B, and the third thread acquires the ITC communication object B released by the first virtual thread. If the second virtual thread fails to acquire the ITC communication object B', it controls the RTOS kernel of the first chip to return a failure message through a non-blocking interface so that the third thread can continue to execute other tasks.

5. The inter-chip thread communication method according to claim 1, characterized in that, After determining the chip state of the first chip, the process also includes: If the first chip is in the second state and the second chip is in the first state, then a fourth padding packet is sent to the second chip, and a second token packet sent by the second chip is received; wherein, the sending parameters of the fourth padding packet and the second token packet are the same; Send a fifth padding packet to the second chip and receive a second data packet sent by the second chip; wherein the sending parameters of the fifth padding packet and the second data packet are the same; A sixth padding packet is sent to the second chip, and a second handshake packet is received from the second chip; wherein the sending parameters of the sixth padding packet and the second handshake packet are the same.

6. The inter-chip thread communication method according to claim 1, characterized in that, After determining the chip state of the first chip, the process also includes: If both the first chip and the second chip are in the second state, a seventh padding packet is periodically sent to the second chip, and an eighth padding packet is periodically sent by the second chip; wherein the sending parameters of the seventh padding packet and the eighth padding packet are the same.

7. The inter-chip thread communication method according to claim 1, characterized in that, Also includes: Determine whether the first chip and the second chip were both in the second state when the last transaction was sent; If not, the current transaction is sent according to the first rule; wherein the first rule is: the time interval between the sending time of the current transaction and the ending time of the previous transaction is equal to the first preset duration; If so, the current transaction is sent according to the second rule; wherein the second rule is: the time interval between the sending time of the current transaction and the sending time of the previous transaction is equal to the second preset duration.

8. An inter-chip thread communication system, characterized in that, The inter-chip thread communication system is applied to a first chip, which is connected to a second chip via a full-duplex communication protocol. A state determination module is used to determine the chip state of the first chip; wherein the chip state includes a first state and a second state, the first state being a state in which there is a transaction to be sent in the chip, and the second state being a state in which there is no transaction to be sent in the chip; The token packet transceiver module is used to send a first token packet to the second chip and receive a second token packet or a first padding packet sent by the second chip if the first chip is in the first state; wherein the first token packet, the second token packet and the first padding packet have the same transmission parameters, including the transmission time and the data length; The data packet transceiver module is used to send a first data packet to the second chip and receive a second data packet or a second padding packet sent by the second chip; wherein the sending parameters of the first data packet, the second data packet, and the second padding packet are the same; The handshake packet transceiver module is used to send a first handshake packet to the second chip and receive a second handshake packet or a third padding packet sent by the second chip; wherein the sending parameters of the first handshake packet, the second handshake packet and the third padding packet are the same.

9. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program, and the processor, when calling the computer program in the memory, implements the steps of the inter-chip thread communication method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores computer-executable instructions, which, when loaded and executed by a processor, implement the steps of the inter-chip thread communication method as described in any one of claims 1 to 7.

Images