Application layer communication method and system based on SPI bus and storage medium
By defining a frame structure and acknowledgment mechanism on the SPI bus, the problems of poor interconnectivity and low reliability of the SPI bus are solved, achieving efficient and reliable data transmission and priority processing, which is suitable for the automotive electronics field.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-22
- Publication Date
- 2026-04-14
AI Technical Summary
The traditional standard SPI bus lacks high-level communication protocols, resulting in poor interoperability and low reliability.
An application-layer communication method based on the SPI bus is designed, defining frame header, payload header, data payload, and fast channel data fields. It adopts a local rolling counter sequence number and acknowledgment mechanism, and performs protocol frame verification and continuity checks through the reverse SPI channel to achieve reliable transmission and priority processing.
It improves R&D efficiency, reduces communication costs, enhances interoperability and reliability, supports rapid transmission of high-priority data, and ensures data integrity and real-time performance.
Smart Images

Figure CN121864879A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of communication technology, and in particular to an application-layer communication method, system, and storage medium based on the SPI bus. Background Technology
[0002] SPI is a high-speed, full-duplex, synchronous communication bus protocol commonly used for data transmission between microcontrollers and various peripherals, and also frequently used as a communication method between chips. A standard SPI consists of four signal lines (SCLK, MOSI, MISO, SS / CS), with a strict master-slave structure. Only the master device can generate the clock signal to control data transmission; slave devices cannot actively initiate transmissions. In practical applications, GPIO is often added to achieve coordinated control through interrupt notifications, ensuring the integrity of each data frame.
[0003] SPI is merely a "bit transmission channel" without a unified communication protocol, resulting in a wide variety of implementations. If developers could operate under a unified SPI protocol, interoperability between different manufacturers based on SPI communication could be achieved, significantly improving R&D and production efficiency.
[0004] In summary, the traditional standard SPI bus lacks high-level communication protocols, resulting in poor interoperability and low reliability. Summary of the Invention
[0005] In view of this, the purpose of the present invention is to provide an application layer communication method, system and storage medium based on SPI bus, so as to alleviate the technical problems of poor interconnectivity and low reliability caused by the lack of high-level communication protocols in the traditional standard SPI bus.
[0006] In a first aspect, the present invention provides an application-layer communication method based on an SPI bus for transmitting data between master and slave devices, the method comprising: The sending end encapsulates the application data to be sent into a protocol frame, wherein the protocol frame includes: a frame header, a payload header, a data payload, and a fast channel data field. In the payload header, the sending end assigns a local rolling counter sequence number to the protocol frame that needs to be reliably transmitted and marks it as requiring confirmation. The transmitting end sends the encapsulated protocol frame via the SPI bus; The receiving end receives the protocol frame on the SPI bus and performs verification on the protocol frame and a continuity check on the local rolling counter sequence number; The receiving end sends an acknowledgment message to the sending end through the reverse SPI channel based on the checksum and continuity check results. The acknowledgment message includes the peer rolling counter and the acknowledgment status. The receiving end reassembles the application data in the protocol frames that have been successfully verified and have consecutive local rolling counter sequence numbers, and submits them to the upper-layer application.
[0007] Furthermore, the frame header includes: a version number, frame description information, and a cyclic redundancy check code; The payload header includes: local rolling counter sequence number, peer rolling counter sequence number, acknowledgment field, local data number, peer data number, data type, payload length, total number of frames, and current frame number.
[0008] Furthermore, the frame description information includes bits used to indicate whether fast channel data exists; The fast channel data is a reserved field of a preset length in the protocol frame, used to transmit short messages with a length less than or equal to the preset length, and the transmission priority of the short messages is higher than that of ordinary data payloads.
[0009] Furthermore, acknowledgment information is sent to the transmitting end via the reverse SPI channel, including: If the protocol frame verification fails, the verification error is marked in the confirmation information, and the local rolling counter sequence number of the last correctly received frame is carried. If a discontinuous local rolling counter sequence number is detected, the frame is marked as lost in the confirmation message, along with the expected next LRC sequence number. The sending end decides whether to retransmit or resend the specified protocol frame based on the received confirmation information, and the retransmitted protocol frame is assigned a new local rolling counter sequence number.
[0010] Furthermore, if the length of the application data exceeds the capacity of a single frame data payload, the sending end will fragment the application data into multiple protocol frames and set the total number of frames and the current frame number in the payload header; the receiving end will reassemble the data payloads of the multiple received protocol frames into complete application data according to the total number of frames and the current frame number.
[0011] Furthermore, the bits used to indicate fast channel data in the frame description information are combinations of multiple bits, the values of which are used to indicate multiple different attributes of the protocol frame at the same time.
[0012] Furthermore, the confirmation field includes the following functional areas: Send function area: contains bits indicating whether this frame requires acknowledgment, and bits indicating whether this frame is a retransmission frame; Confirmation Function Area: Contains bits indicating whether the frame contains confirmation information, bits indicating the verification result of the confirmed frame, bits indicating that the confirmed frame has a verification error, and bits indicating that the frame is lost.
[0013] In a second aspect, the present invention also provides an application layer communication system based on an SPI bus for implementing any of the methods described in the first aspect, wherein the system includes a master device and a slave device connected in communication.
[0014] Furthermore, the system is applied in the field of automotive electronics.
[0015] Thirdly, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the method described in the first aspect.
[0016] This invention provides an application layer communication method based on an SPI bus for transmitting data between master and slave devices. The method includes: a transmitting end encapsulating application data to be transmitted into a protocol frame, wherein the protocol frame includes a frame header, a payload header, a data payload, and a fast channel data field. In the payload header, the transmitting end assigns a local rolling counter sequence number to the protocol frame requiring reliable transmission and marks it as needing acknowledgment; the transmitting end transmits the encapsulated protocol frame via the SPI bus; the receiving end receives the protocol frame on the SPI bus and performs verification and a continuity check on the local rolling counter sequence number; based on the verification and continuity check results, the receiving end sends acknowledgment information to the transmitting end via a reverse SPI channel, wherein the acknowledgment information includes the peer's rolling counter and acknowledgment status; the receiving end reassembles the application data in the protocol frame with successfully verified and continuous local rolling counter sequence numbers and submits it to the upper-layer application. As can be seen from the above description, the application layer communication method based on the SPI bus of the present invention defines a complete application layer communication protocol stack, which can improve R&D efficiency, reduce communication costs, and has good interoperability. In addition, it performs verification and continuity checks on protocol frames, resulting in good reliability. This alleviates the technical problem of poor interoperability and low reliability caused by the lack of high-level communication protocols in the traditional standard SPI bus. Attached Figure Description
[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0018] Figure 1 A flowchart illustrating an application layer communication method based on the SPI bus provided in an embodiment of the present invention. Detailed Implementation
[0019] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0020] The traditional standard SPI bus lacks high-level communication protocols, resulting in poor interoperability and low reliability.
[0021] Based on this, the application layer communication method based on the SPI bus of the present invention defines a complete application layer communication protocol stack, which can improve R&D efficiency, reduce communication costs, have good interoperability, and perform verification and continuity checks on protocol frames, thus ensuring high reliability.
[0022] To facilitate understanding of this embodiment, a detailed description of an application layer communication method based on the SPI bus disclosed in this embodiment of the invention will be provided first.
[0023] Example 1: According to an embodiment of the present invention, an embodiment of an application layer communication method based on an SPI bus is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0024] Figure 1 This is a flowchart of an application layer communication method based on an SPI bus according to an embodiment of the present invention, such as... Figure 1 As shown, the method for transferring data between master and slave devices includes the following steps: In step S102, the sending end encapsulates the application data to be sent into a protocol frame, wherein the protocol frame includes: frame header, payload header, data payload and fast channel data field. In the payload header, the sending end assigns a local rolling counter sequence number to the protocol frame that needs to be reliably transmitted and marks it as needing acknowledgment. Step S104: The transmitting end sends the encapsulated protocol frame via the SPI bus; Step S106: The receiving end receives the protocol frame on the SPI bus and performs verification on the protocol frame and a continuity check on the local rolling counter sequence number. In step S108, the receiving end sends an acknowledgment message to the sending end through the reverse SPI channel based on the checksum continuity check result. The acknowledgment message includes the peer rolling counter and the acknowledgment status. In step S110, the receiving end reassembles the application data in the protocol frames that have been successfully verified and have consecutive local rolling counter sequence numbers, and submits them to the upper-layer application.
[0025] Specifically, one-to-one communication between two chips is the best practice for the method of this invention. This invention designs a communication protocol for SPI as an inter-chip communication channel and provides application instructions for the protocol. The protocol design uses a tracking strategy based on sequence numbers and data types, an acknowledgment and retransmission mechanism based on a rolling counter, and a fast channel for short messages (express data tunnel). In actual production, it supports mixed transmission of different data types, corresponding to a priority queue in specific practice; similar to reliable transmission like TCP.
[0026] Tracking strategy: Each piece of data is assigned a sequence number (SN) upon transmission. Each type of data has its own independent data type, and both the sending and receiving ends track and process the data throughout the transmission process. During transmission, the data may be split into multiple blocks (each data transmission in SPI is defined as a frame, and the block division is based on the maximum payload of the frame). For multi-frame data, the protocol stack implementation will send the data frame by frame, and the receiving end will accurately merge the frame payloads according to the data frame number until the entire data has been received.
[0027] Confirmation and resend mechanism: Each data frame is assigned an incrementing rolling counter to track that frame. Data that needs to be transmitted reliably (ensuring complete and accurate transmission) will be retransmitted if a frame check error occurs. Frame loss (rolling counter skipping) will require retransmission.
[0028] Express data tunnel: The Express data field in each frame forms a fast channel for short messages (6 bytes or less). This is especially useful when large amounts of data are queued for transmission, as short messages can be delivered quickly during the transmission process. Short messages do not support retransmission.
[0029] SPI's "high speed" is relatively slow compared to Ethernet, and even with the assistance of GPIO, it's difficult to achieve a very high bandwidth. If data accumulates, all data needs to be queued. For short and urgent data, such as instructions, queuing can severely impact real-time performance, especially in cross-chip communication like in autonomous driving. Although short messages are small, they still occupy a single frame, and most transmitted data does not fill the entire frame's data payload. Therefore, express data tunnels achieve a good balance, improving short message transmission efficiency while saving bandwidth.
[0030] Agreement: 1. The length of data transmitted in each SPI transmission is usually fixed. However, in actual production, DMA or FIFO modes are often used to assist in transmission, so this length is also limited by the width of the DMA and FIFO. We define each transmitted data as a frame of data in the SPI protocol, and the maximum length of each data exchange is defined as the frame length.
[0031] 2. Let N represent the frame length.
[0032] 3. The maximum length of a single data entry supported by the protocol is the frame payload (N - sizeof(frame_header) - sizeof(express_data)) * 255. In practical applications, this may be much smaller. Larger data needs to be split and combined at the application layer (not the protocol stack layer).
[0033] The specific structure of the protocol frame will be explained in the following text, and will not be repeated here.
[0034] This invention provides an application layer communication method based on an SPI bus for transmitting data between master and slave devices. The method includes: a transmitting end encapsulating application data to be transmitted into a protocol frame, wherein the protocol frame includes a frame header, a payload header, a data payload, and a fast channel data field. In the payload header, the transmitting end assigns a local rolling counter sequence number to the protocol frame requiring reliable transmission and marks it as needing acknowledgment; the transmitting end transmits the encapsulated protocol frame via the SPI bus; the receiving end receives the protocol frame on the SPI bus and performs verification and a continuity check on the local rolling counter sequence number; based on the verification and continuity check results, the receiving end sends acknowledgment information to the transmitting end via a reverse SPI channel, wherein the acknowledgment information includes the peer's rolling counter and acknowledgment status; the receiving end reassembles the application data in the protocol frame with successfully verified and continuous local rolling counter sequence numbers and submits it to the upper-layer application. As can be seen from the above description, the application layer communication method based on the SPI bus of the present invention defines a complete application layer communication protocol stack, which can improve R&D efficiency, reduce communication costs, and has good interoperability. In addition, it performs verification and continuity checks on protocol frames, resulting in good reliability. This alleviates the technical problem of poor interoperability and low reliability caused by the lack of high-level communication protocols in the traditional standard SPI bus.
[0035] In an optional embodiment of the present invention, the frame header includes: a version number, frame description information, and a cyclic redundancy check code; The payload header includes: local rolling counter sequence number, peer rolling counter sequence number, acknowledgment field, local data number, peer data number, data type, payload length, total number of frames, and current frame number.
[0036] In an optional embodiment of the present invention, the frame description information includes bits used to indicate whether fast channel data is present; The fast channel data is a reserved field of preset length in the protocol frame, used to transmit short messages with a length less than or equal to the preset length, and the transmission priority of the short message is higher than that of the ordinary data payload.
[0037] In an optional embodiment of the present invention, sending acknowledgment information to the transmitting end via the reverse SPI channel specifically includes the following steps: (1) If the protocol frame verification fails, mark the verification error in the confirmation message and carry the local rolling counter sequence number of the last correctly received frame; (2) If the local rolling counter sequence number is not continuous, mark the frame as lost in the confirmation message and carry the expected next LRC sequence number; (3) The sending end decides whether to retransmit or resend the specified protocol frame based on the received confirmation information, and the retransmitted protocol frame is assigned a new local rolling counter sequence number.
[0038] In an optional embodiment of the present invention, if the length of the application data exceeds the capacity of a single frame data payload, the sending end fragments the application data into multiple protocol frames and sets the total number of frames and the current frame number in the payload header; the receiving end reassembles the data payloads of the multiple received protocol frames into complete application data according to the total number of frames and the current frame number.
[0039] In an optional embodiment of the present invention, the bits used to indicate fast channel data in the frame description information are a combination of multiple bits, the values of which are used to indicate multiple different attributes of the protocol frame at the same time.
[0040] In an optional embodiment of the present invention, the confirmation field includes the following functional areas: Send function area: contains bits indicating whether this frame requires acknowledgment, and bits indicating whether this frame is a retransmission frame; Confirmation Function Area: Contains bits indicating whether the frame contains confirmation information, bits indicating the verification result of the confirmed frame, bits indicating that the confirmed frame has a verification error, and bits indicating that the frame is lost.
[0041] Specifically, the definition of the frame structure of the protocol frame is explained below: Frame structure (top-level structure): (B = byte, 1B means occupying 1 byte, 4B means occupying four bytes).
[0042]
[0043] 1. Frame header (4B)
[0044] Version, version number 1~255; Frame description:
[0045] CRC16: As a checksum for the entire frame, the sender first fills in zeros and then fills the corresponding result into the corresponding position after the calculation. The receiver first copies and saves it, then fills in zeros, calculates it in the same way, and then compares whether the saved value is consistent.
[0046] 2. Business Data (N-10B) Section The business data is the express data remaining after removing the frame header and frame trailer. It is further divided into two parts: the payload header and the payload.
[0047]
[0048] Payload header
[0049] 1) LRC (local rolling counter), local rolling counter The rolling counter is a sequential numbering system for frames during transmission, ranging from 0 to 255, and is used cyclically.
[0050] The LRC is the frame number of each frame sent by the receiver. The receiver stores the last received LRC. If the latest received LRC is not consecutive and a jump occurs, it indicates that a frame has been lost. The receiver needs to inform the sender in subsequent frames sent by the receiver.
[0051] The receiving end will verify the entire frame. If the verification fails, it will also need to inform the other end in the subsequent frame.
[0052] The RC is always looping, and even when retransmitting an erroneous frame, a new RC will be used instead of the old one.
[0053] Combined with the Confirmation field (send function area), when bit0 is 1, it indicates that this frame needs to be confirmed; when bit1 is 1, it indicates that this frame is a retransmission frame.
[0054] 2)PRC (peer rolling counter), peer rolling counter The PRC field is filled in when confirming the result of sending a frame to the other end, and it needs to be used in conjunction with the Confirmation field (the confirmation function area in the table below).
[0055] When bit2 is 1, it indicates that the corresponding frame number (RC) sent by the other end has been acknowledged. A result of bit3 of 1 indicates that the check is correct, and 0 indicates an error. Since it is a whole frame check, the case of 0 is almost impossible to occur unless the received size is incorrect.
[0056] When a verification error occurs, since the verification is performed on the entire frame, the LRC obtained at this time cannot guarantee its correctness. Therefore, the RC+1 of the last received correct frame should be entered into the PRC. Confirmation bit 4 should be filled with 1.
[0057] Frame loss is determined based on the continuity of LRC. Once frame loss is confirmed, when notifying the other end, the PRC is filled with RC+1 of the last received frame, and Confirmation bit 5 is filled with 1.
[0058] In the confirmation message, skipped frames and misread frames are handled first. The results of frame loss and checksum errors must be communicated to the sender, regardless of whether the transmission is reliable or not, because it is impossible to determine at this point whether the lost or misread frame is a data frame that needs to be reliably transmitted.
[0059] 3) Confirmation, confirmation field
[0060] 4) LSN (local serial number), local data number (0~32767) The Local Serial Number and Data Type together determine the data being transmitted, and the RC is used to mark the corresponding data frame being transmitted.
[0061] 5) PSN (peer serial number), peer data number (0~32767) Peer Serial Number and Data Type together determine the data that the peer is sending, i.e., the data being received. RC is used to mark the corresponding data frame.
[0062] 6) Data Type: Data type defined at the business level. 7) Payload Size: The size of the data in this frame. 8) Total Frames: This data is divided into a total of how many frames? 9) Current Frame Number Payload Data section 3. Express data Express data is data with a size of 6 bytes or less, such as control commands and status data, and is sent using an express data tunnel.
[0063] The consensus at the protocol level of this invention can improve R&D efficiency and reduce communication costs; it supports priority data, enabling high-priority data to be transmitted efficiently (interrupting the transmission of low-priority data, as there is only one channel in this scenario); it supports fast channels, allowing urgent data such as instructions to be transmitted at the fastest speed; the confirmation and retransmission mechanism based on a rolling counter can ensure that data is transmitted accurately; any third party can implement it according to the protocol, and it can ultimately be integrated across enterprises and teams.
[0064] This invention defines an application-level communication protocol based on SPI, which can significantly improve the speed of R&D, the reliability, security and efficiency of data exchange in chip-to-chip communication in the automotive field; this invention proposes to support the data priority protocol in two ways (high and low priority and express data tunnel), which can effectively improve the response speed of important data; this invention proposes an RC-based acknowledgment and retransmission mechanism to realize retransmission at the frame level, thereby improving communication efficiency.
[0065] The core design of this invention is a layered protocol frame structure. This structure is meticulously designed, overlaying rich control information onto standard SPI data bits. Its design follows the classic layered approach of communication protocols. Physical layer: Based on the standard SPI bus.
[0066] Data Link Layer (Protocol Layer): The core innovation of this invention is that it defines four parts in the SPI frame: frame header, payload header, data payload, and fast channel, which realizes the reliability, orderliness, and priority of data transmission.
[0067] Key mechanisms: reliability, priority, and fast track.
[0068] Reliable transmission mechanism (based on Rolling Counter) Problem: Standard SPI does not guarantee reliable data delivery.
[0069] Solution: Sequence Number (LRC / PRC): Each data frame has a local rolling counter (LRC, 0-255) used to identify the order of frames. The receiver determines whether a frame has been lost by checking the continuity of the LRC.
[0070] Confirmation and Retransmission (Confirmation field): The receiver confirms successful frame reception or requests retransmission to the sender through the PRC (Peer Rolling Counter) and the ACK / NACK information in the Confirmation field.
[0071] CRC check: Each frame has a CRC16 check to ensure data integrity.
[0072] Results: It achieves reliable transmission similar to TCP, ensuring that data is not lost, not misread, and not out of order.
[0073] Data Priority and Express Data Tunnel Mechanism Problem: Long data packet transmissions can block urgent short commands, resulting in poor real-time performance.
[0074] Solution: Priority marker (frame description field): Data can be marked as high or low priority.
[0075] Express Data Field: A fixed 6 bytes are reserved in each SPI frame as an "emergency channel" dedicated to transmitting short, urgent messages (such as control commands). Even if a long data packet is currently being transmitted, the short message can "jump the queue" and be sent immediately in the next frame.
[0076] Effect: It greatly improves the real-time response capability of emergency commands and avoids the problem of "blockage at the head of the queue".
[0077] Workflow: Sending and Receiving Sender: 1. Application data is sent to the protocol stack.
[0078] 2. The protocol stack determines whether to put the data into the normal payload (which may require framing) or the fast channel based on the data size and urgency.
[0079] 3. Assign an LRC sequence number to the frame and set flags such as data type and whether acknowledgment is required.
[0080] 4. Calculate the CRC and send it out via the SPI bus.
[0081] Receiver: 1. Receive SPI data and verify the CRC. If an error is found, request a retransmission via the acknowledgment mechanism.
[0082] 2. Check LRC continuity; if frame loss is found, request a retransmission.
[0083] 3. Based on the Confirmation field, send an acknowledgment message (ACK / NACK) to the sender.
[0084] 4. Reassemble the fragmented long message based on the "current frame number" and "total number of frames".
[0085] 5. Submit the reconstructed complete data or fast-track data to the upper-layer application.
[0086] The inventive points are as follows: 1. Invention Point 1: A unified application layer protocol framework for the SPI bus that integrates reliable transmission and fast channel. Technical problems solved: Standard SPI is only a bit stream channel with no reliability or priority guarantee, which makes it difficult for devices from different manufacturers to interconnect and results in low R&D efficiency.
[0087] Technical approach: A complete frame structure was designed, integrating the rolling counter (LRC / PRC), confirmation retransmission mechanism (Confirmation field), CRC check, data fragmentation and reassembly, and a fixed reserved fast channel (Express Data) into each SPI transmission.
[0088] Technical benefits: A reliable, orderly, and priority-supporting communication link is built on a simple SPI physical layer, providing a unified communication standard for devices from different manufacturers, achieving "plug and play" and greatly improving development efficiency.
[0089] 2. Invention Point Two: Fast Track Mechanism Based on Fixed Reserved Fields The technical problem solved: SPI communication bandwidth is limited, and the transmission of long data packets will seriously block urgent short instructions, affecting the real-time performance of the system.
[0090] Technical approach: A fixed area (e.g., 6 bytes) is designated as the Express Data field within each SPI frame, dedicated to transmitting short messages. This channel is transmitted in parallel with the main data payload and has the highest priority.
[0091] Technical effect: It enables the instant transmission of emergency commands without waiting for long data packets to complete, greatly reducing the delay of critical commands, and is particularly suitable for scenarios with extremely high real-time requirements, such as autonomous driving.
[0092] 3. Invention Point Three: Lightweight Acknowledgment Retransmission and Flow Control Mechanism Based on Rolling Counter Technical problem to be solved: Traditional solutions lack efficient and simple error recovery mechanisms.
[0093] Technical approach: Each frame is numbered using an 8-bit rolling counter (LRC / PRC), and rich confirmation information (such as ACK, NACK, frame loss notification) is carried through the Confirmation field. When an error is detected, the old data frame is retransmitted using a new rolling counter.
[0094] Technical benefits: It achieves lightweight and highly efficient error recovery and flow control. Compared to complex protocols, it has minimal overhead and a rapid response, perfectly matching the characteristics of SPI, a medium-speed, overhead-sensitive bus.
[0095] Example 2: This invention also provides an application layer communication system based on an SPI bus for implementing any of the methods described in Embodiment 1. The system includes a master device and a slave device connected in communication.
[0096] Optionally, this system can be applied to the field of automotive electronics.
[0097] The system provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment.
[0098] Corresponding to the above-described application layer communication method based on the SPI bus, this application embodiment also provides a computer-readable storage medium storing machine-executable instructions. When the machine-executable instructions are called and run by a processor, the machine-executable instructions cause the processor to perform the steps of the above-described application layer communication method based on the SPI bus.
[0099] The application layer communication system based on the SPI bus provided in this application embodiment can be specific hardware on the device or software or firmware installed on the device. The device provided in this application embodiment has the same implementation principle and technical effects as the foregoing method embodiments. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the foregoing method embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.
[0100] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.
[0101] For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0102] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0103] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0104] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the application layer communication method based on the SPI bus described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0105] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.
[0106] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, 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. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.
Claims
1. An application layer communication method based on SPI bus, characterized in that, The method for transferring data between master and slave devices includes: The sending end encapsulates the application data to be sent into a protocol frame, wherein the protocol frame includes: a frame header, a payload header, a data payload, and a fast channel data field. In the payload header, the sending end assigns a local rolling counter sequence number to the protocol frame that needs to be reliably transmitted and marks it as requiring confirmation. The transmitting end sends the encapsulated protocol frame via the SPI bus; The receiving end receives the protocol frame on the SPI bus and performs verification on the protocol frame and a continuity check on the local rolling counter sequence number; The receiving end sends an acknowledgment message to the sending end through the reverse SPI channel based on the checksum and continuity check results. The acknowledgment message includes the peer rolling counter and the acknowledgment status. The receiving end reassembles the application data in the protocol frames that have been successfully verified and have consecutive local rolling counter sequence numbers, and submits them to the upper-layer application.
2. The method according to claim 1, characterized in that, The frame header includes: version number, frame description information, and cyclic redundancy check code; The payload header includes: local rolling counter sequence number, peer rolling counter sequence number, acknowledgment field, local data number, peer data number, data type, payload length, total number of frames, and current frame number.
3. The method according to claim 2, characterized in that, The frame description information includes bits used to indicate whether fast channel data exists; The fast channel data is a reserved field of a preset length in the protocol frame, used to transmit short messages with a length less than or equal to the preset length, and the transmission priority of the short messages is higher than that of ordinary data payloads.
4. The method according to claim 1, characterized in that, Sending acknowledgment information to the transmitting end via the reverse SPI channel, including: If the protocol frame verification fails, the verification error is marked in the confirmation information, and the local rolling counter sequence number of the last correctly received frame is carried. If a discontinuous local rolling counter sequence number is detected, the frame is marked as lost in the confirmation message, along with the expected next LRC sequence number. The sending end decides whether to retransmit or resend the specified protocol frame based on the received confirmation information, and the retransmitted protocol frame is assigned a new local rolling counter sequence number.
5. The method according to claim 1, characterized in that, If the length of the application data exceeds the capacity of a single frame data payload, the sending end will fragment the application data into multiple protocol frames and set the total number of frames and the current frame number in the payload header; the receiving end will reassemble the data payloads of the multiple received protocol frames into complete application data according to the total number of frames and the current frame number.
6. The method according to claim 3, characterized in that, The bits used to indicate fast channel data in the frame description information are combinations of multiple bits, and their values are used to indicate multiple different attributes of the protocol frame at the same time.
7. The method according to claim 2, characterized in that, The confirmation field includes the following functional areas: Send function area: contains bits indicating whether this frame requires acknowledgment, and bits indicating whether this frame is a retransmission frame; Confirmation Function Area: Contains bits indicating whether the frame contains confirmation information, bits indicating the verification result of the confirmed frame, bits indicating that the confirmed frame has a verification error, and bits indicating that the frame is lost.
8. An application layer communication system based on SPI bus, characterized in that, For implementing the method as described in any one of claims 1 to 7, the system includes a master device and a slave device with a communication connection.
9. The system according to claim 8, characterized in that, The system is applied in the field of automotive electronics.
10. A computer-readable storage medium storing a computer program thereon, characterized in that, The computer program is executed by the processor to perform the method of any one of claims 1 to 7.