WO2022017102A1 - 一种基于仲裁线的全双工spi通信方法 - Google Patents
一种基于仲裁线的全双工spi通信方法 Download PDFInfo
- Publication number
- WO2022017102A1 WO2022017102A1 PCT/CN2021/101480 CN2021101480W WO2022017102A1 WO 2022017102 A1 WO2022017102 A1 WO 2022017102A1 CN 2021101480 W CN2021101480 W CN 2021101480W WO 2022017102 A1 WO2022017102 A1 WO 2022017102A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- message
- communication
- data
- party
- message data
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
- G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
- G06F13/4291—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus using a clocked protocol
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L5/00—Arrangements affording multiple use of the transmission path
- H04L5/14—Two-way operation using the same type of signal, i.e. duplex
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
- G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
Definitions
- the invention relates to the technical field of automobile communication, in particular to a full-duplex SPI communication method based on an arbitration line.
- the multi-chip system solution has become a common electronic product design solution.
- the communication mode between chips is mainly on-board bus (UART, IIC, SPI, etc.).
- SPI Serial Peripheral Interface
- IIC IIC
- SPI Serial Peripheral Interface
- the scheme can realize limited full-duplex communication. In this communication scheme, only the master device can initiate communication actively, while the slave device cannot initiate communication actively, and can only wait for the master device to initiate communication and send data to the master device. This scheme has great limitations in transmission direction, communication flexibility and load capacity.
- the technical problem to be solved by the embodiments of the present invention is to provide a full-duplex SPI communication method based on an arbitration line, which is used to solve the existing SPI communication that has great limitations in transmission direction, communication flexibility and load capacity.
- the present invention provides a full-duplex SPI communication method based on an arbitration line, the method comprising:
- Step S11 the communication requesting party detects the first arbitration line corresponding to the communication requesting party and the second arbitration line corresponding to the communication responding party, when both the first arbitration line and the second arbitration line are at low potential , pull up the potential of the first arbitration line corresponding to the communication requesting party;
- Step S12 when the communication responder detects that the first arbitration line is at a high potential, it pulls up the potential of the second arbitration line;
- Step S13 when the communication requester detects that the second arbitration line is at a high potential, confirming that the communication responder is in a communicable state;
- Step S14 the communication requester and the communication responder send message header data to each other;
- Step S15 the communication requester and the communication responder send message body data to each other.
- the method before pulling up the potential of the second arbitration line, the method further includes:
- the communication responder detects that its own state is normal, and the own state includes a memory space and a communication state.
- step S14 also includes:
- the communication requester and the communication responder respectively obtain the transmission data length of the other party's message data from the message header data sent by the other party, and obtain the transmission data length of the other party's message data, and obtain the transmission data length of the other party's message data with a shorter transmission data length. Complement, so that the transmission data length of the message data of both parties is the same.
- step S13 includes:
- the communication requester When the communication requester is the host, the communication requester pulls down the potential of the chip select signal and sends a clock signal to the communication responder.
- the communication requesting party and the communication responding party obtain the transmission data length of each other's message data, and supplement the message data whose transmission data length of their own data message is shorter, so that the message data of both parties is completed.
- the data length is consistent, it also includes:
- the communication requester sends a chip select signal and a clock signal corresponding to the transmission data length of the complemented message data to the communication responder, and pulls down the potential of the first arbitration line.
- step S15 it also includes:
- the communication requester pulls up the potential of the chip select signal, and stops sending the clock signal to the communication responder;
- the communication responder pulls down the potential of the second arbitration line.
- step S13 also includes:
- the communication responder pulls down the potential of the chip select signal and sends a clock signal to the communication requester.
- the communication requesting party and the communication responding party obtain the transmission data length of each other's message data, and complement the message data whose transmission data length is shorter, so that the message data length of both parties is completed. After agreement also includes:
- the communication response sends a chip select signal and a clock signal corresponding to the transmission data length of the complemented message data to the communication requester, and pulls down the potential of the second arbitration line.
- step S15 it also includes:
- the communication responder pulls up the potential of the chip select signal, and stops sending the clock signal to the communication requester;
- the communication requester pulls down the potential of the second arbitration line.
- the communication requesting party and the communication responding party respectively obtain the transmission data length of the other party's message data from the message header data sent by the other party, and the transmission data length of their own is shorter.
- the message data is complemented, so that the transmission data length of the message data of both parties is consistent, including:
- the communication requester and the communication responder respectively obtain the message header data of the other party, and the message header data carries the transmission data length of the message data;
- the communication requester and the communication responder respectively compare the transmission data length of their own message data with the transmission data length of the other party's message data;
- Either party determines that the transmission data length of its own message data is shorter, and supplements the message data whose own transmission data length is shorter with preset characters, so that the transmission data lengths of the message data of both parties are consistent.
- the message header data includes a protocol type field, and the protocol type field is set to an event message type or a periodic message type;
- the party sending the message data completes the sending of the message data, it confirms that the message data is sent successfully, and the message data includes the message Header data and message body data;
- the party sending the message data starts the timer corresponding to the message data, and receives the received message within the preset timing time.
- the method also includes:
- the party sending the message data When the party sending the message data does not receive the message data within the preset time, the party receiving the message data replies with the acknowledgment message ACK, the party sending the message data resends the message data and start the timer again;
- the party sending the message data determines that the sending of the message data fails, and returns the failure information to the application layer of the party sending the message data through a callback function.
- the first arbitration line and the second arbitration line are provided for determining the working state, communication request and communication response of the master and the slave, so that the master can send the slave to the slave.
- Send message data, and the slave can send message data to the master.
- the problem of clock synchronization is solved by adjusting the length of the data message, so that the master and the slave can send data messages at the same time.
- the receiver confirms each character received, which improves the transmission efficiency of data packets; in addition, ACK is not required for periodic packets to confirm that the packet data is successfully sent, and ACK is used for important packets to confirm that the packet data is successfully sent. , which improves the transmission efficiency of data packets, and solves the problem that the existing SPI communication is limited in the transmission direction and the flexibility of communication.
- FIG. 1 is a flowchart of a full-duplex SPI communication method based on an arbitration line provided by an embodiment of the present invention.
- FIG. 2 is a hierarchical division of an SPI communication method provided by an embodiment of the present invention and an overall architecture relationship diagram of each component.
- FIG. 3 is a communication flowchart of a general message protocol with ACK provided by an embodiment of the present invention.
- FIG. 4 is a flowchart of general message protocol communication without ACK provided by an embodiment of the present invention.
- FIG. 5 is a flowchart of a full-duplex SPI communication method based on an arbitration line provided by an embodiment of the present invention.
- FIG. 6 is a flowchart of a full-duplex SPI communication method based on an arbitration line provided by an embodiment of the present invention.
- an embodiment of the present invention provides a full-duplex SPI communication method based on an arbitration line, and the method includes:
- Step S11 the communication requesting party detects the first arbitration line corresponding to the communication requesting party and the second arbitration line corresponding to the communication responding party, when both the first arbitration line and the second arbitration line are at low potential , pull up the potential of the first arbitration line.
- the existing four-wire SPI includes a host, one or more slaves, and four communication signal lines, which are a clock line (CLK), a chip select (CS), a host output signal line (MOSI), and a host input signal. line (MISO).
- CLK clock line
- CS chip select
- MOSI host output signal line
- MISO host input signal. line
- two SPI communication signal lines are added, which are the first arbitration line corresponding to the communication requester and the second arbitration line corresponding to the communication responder.
- first arbitration line When the first arbitration line is at a low level, it means The communication requester is in an idle state, and no data packets are being sent.
- second arbitration line When the second arbitration line is at a low potential, it means that the communication responder is in an idle state and no data packets are being sent; pulling up the potential of the first arbitration line is actually The above is that the communication requester initiates a communication request.
- the communication requester can be the host or the slave.
- the communication responder must be the slave; similarly, when the communication requester is the slave, then the communication requester is the slave. Must be the host.
- Step S12 when the communication responder detects that the first arbitration line is at a high potential, it pulls up the potential of the second arbitration line.
- the communication responder can confirm its own state, which includes the memory space and the communication state.
- the potential of the second arbitration line is described, and this step is equivalent to that the communication responder prepares to respond to the communication request of the communication requester.
- Step S13 When the communication requester detects that the second arbitration line is at a high level, it confirms that the communication responder is in a communicable state.
- step S13 also includes:
- the communication requestor pulls down the potential of the chip select signal and sends a clock signal to the communication responder;
- the communication responder pulls down the potential of the chip select signal and sends a clock signal to the communication requester.
- Pulling down the potential of the chip select signal indicates that the master selects the slave as a communication object, and the master sends a clock signal to the slave for clock synchronization.
- Step S14 the communication requester and the communication responder send message header data to each other.
- the host and the slave send message data bidirectionally, and divide the message data into message header data and message body data and send them separately.
- the host can learn the message data of the frame through the message header data.
- the slave does not need to respond to each byte transmission, which saves time and improves efficiency.
- the protocol types in Table 2 include event message types, large data transmission types, and periodic message types.
- Protocol Type (1B) Protocol Type (2B)
- the message data includes message header data and message body data
- the message header data includes a protocol type field
- the protocol type field is set to an event message type or a periodic message type.
- the party sending the data message starts the timer corresponding to the data message, and receives the received datagram within the preset timing time.
- One party of the message replies with an acknowledgment message ACK, determines that the message data is sent successfully and removes the message data from the sending queue.
- the application layer makes the selection.
- the important message data selection is set to the event message type
- the non-important or periodic message data selection is set to the periodic message type
- the periodic message type does not need to be confirmed by the confirmation message ACK. , which saves the time used for ACK of non-important packets.
- the step S14 also includes:
- the communication requester and the communication responder respectively obtain the transmission data length of the other party's message data from the message header data of the other party, and supplement the message data whose own transmission data length is shorter. , so that the transmission data length of the message data of both parties is consistent.
- the communication requesting party and the communication responding party respectively obtain the message header data of the other party, and the message header data carries the transmission data length of the message data;
- the communication requester and the communication responder respectively compare the transmission data length of their own message data with the transmission data length of the other party's message data;
- Either party determines that the transmission data length of its own message data is shorter, and supplements the message data whose own transmission data length is shorter with preset characters, so that the transmission data lengths of the message data of both parties are consistent.
- the counterparty of the communication requester refers to the communication responder
- the counterparty of the communication responder refers to the communication requester; either party determines that the transmission data length of its own message data is short, and uses 0x00 characters to match the message body data. Complement, so that the transmission data length of the message data of both parties is the same.
- the communication requester and the communication responder respectively obtain the transmission data length of the other party's message data from the message header data of the other party, and supplement the message data whose own transmission data length is shorter. , after making the transmission data length of the message data of both parties consistent, it also includes:
- the communication requester When the communication requester is the host, the communication requester sends a chip select signal and a clock signal corresponding to the transmission data length of the complemented message data to the communication responder, and pulls down the first arbitration line potential.
- the communication responder When the communication requester is a slave, the communication responder sends a chip select signal and a clock signal corresponding to the longer transmission data length of the complemented message data to the communication requester, and pulls down the The potential of the second arbitration line.
- Step S15 the communication requester and the communication responder send message body data to each other.
- step S15 it also includes:
- the communication requester When the communication requester is the host, the communication requester pulls up the potential of the chip select signal and stops sending the clock signal to the communication responder;
- the communication responder pulls down the potential of the second arbitration line.
- the communication responder pulls up the potential of the chip select signal, and stops sending the clock signal to the communication requester;
- the communication requester pulls down the potential of the second arbitration line.
- the message header data includes a protocol type field, and the protocol type field is set to an event message type or a periodic message type;
- the header data of the message sent by the communication requester or the communication responder includes the periodic message type
- the party sending the message data After the party sending the message data completes the sending of the message data, it confirms that the message data is sent successfully, and the message data includes the message Header data and message body data;
- the party sending the message data starts the timer corresponding to the message data, and receives the received message within the preset timing time.
- the method also includes:
- the party sending the message data When the party sending the message data does not receive the message data within the preset time, the party receiving the message data replies with the acknowledgment message ACK, the party sending the message data resends the message data and start the timer again;
- the party sending the message data determines that the sending of the message data fails, and returns the failure information to the application layer of the party sending the message data through a callback function.
- the above-mentioned communication method is based on the hierarchical division of the communication method and the overall structure of each component.
- the global control and adaptation layer includes: M11, application interaction interface; M12, application message management; M13 , SourceID management; M14, application callback and feedback management; M15, ACK &retransmission; M16, communication management protocol.
- Application interaction interface providing a unified calling interface to the outside world.
- the application is implemented through the provided interface: sending messages, setting message processing methods, configuring message priority, registering and managing message receiving callback functions, querying communication status, etc. operate.
- M12 application message management
- the application transmits the ID and type of the message to be sent into M12 through M11, and then M12 controls the module of the protocol layer to execute message transmission according to the relevant parameter setting information in the message.
- this module in order to distinguish each message, this module will provide a unique (at least within a period of time) serial number as a certificate for each message.
- the application layer sends a message, it will call this module to apply for the serial number in the process of assembling the message.
- This module generates a unique serial number according to the specified program, and then returns the serial number to the message assembly function.
- the value range of the sequence number should be large enough to ensure that the entire system can distinguish each different message according to the sequence number at a certain time, and avoid misoperation on messages sent at different times but with the same content.
- M14 Application callback and feedback management.
- the application binds the ID number and the callback function in pairs to the M14 through the interface provided by M11.
- the main function of M14 is to find the corresponding callback function according to the ID number, and send the ID message to the M14.
- the information generated during the transmission process (including sending failures, receiving packets, etc.) is returned to the application.
- the application can use the interface provided by M11 to operate the information saved in M14.
- the message protocol of this method provides two types of messages, namely periodic messages and event messages, and the formats are shown in Table 3 and Table 4.
- Periodic message refers to the message sent periodically by the sender, which is characterized by the fact that the receiver does not need to reply with an acknowledgment (ACK).
- ACK acknowledgment
- the sending is successful until the information is confirmed. Otherwise, the sender will re-send or fail to send.
- the specific process is as follows:
- the module After sending a frame of event message, the module starts a timer for the message, and then waits for the ACK message from the receiver for a period of time. If the ACK is received in time, it is determined that the message has been sent successfully, and the message will be removed from the sending queue; if the ACK is not received after the timeout, it is determined that the message has failed to be sent twice, and the message is resent and timed; After the retransmission reaches a certain number of times, it is determined that the message has failed to be sent, and the failure information is returned to the application through the callback function. After receiving a frame of event message, the receiver generates an ACK message and sends it out.
- the pairing of an event message and its ACK is achieved by relying on the message sequence number field of the message. After receiving the event message, the receiver takes out the value of the message sequence number field of the message, and fills it into the message sequence number field of the reply ACK. After receiving the ACK, the sender will compare the serial number. When the serial number is consistent with an event-type message in the sending queue, it is considered that the message has been sent successfully, and it will be removed from the sending queue.
- M16 communication management protocol, this module is responsible for receiving and sending heartbeat messages, as well as managing communication status.
- the communication management protocol specifically defines the format of the heartbeat message, see Table 5 below for details, query the connection state of the peer controller, and the logic of the communication state transition.
- the communication management protocol stipulates that in an embedded product with multi-core communication, the controller that assumes the role of "communication center" is set as the master of communication state management, and the others are set as slaves.
- the protocol also stipulates that in the entire communication network, there is only one master and one or more slaves.
- the communication management protocol mainly includes the following sub-modules: 1. Communication status management; 2. Periodic heartbeat management.
- the host sends a heartbeat message according to a fixed period, and after receiving the heartbeat message, the slave replies with a heartbeat message according to the protocol.
- the host will maintain a score table related to the communication quality of the slave, as the main basis for communication status management.
- the host After the host sends the heartbeat message, it will start the timer at the same time. If the heartbeat message from the slave is not received within the specified time, the specified score will be deducted from the communication quality score table; After the heartbeat message returned by the slave machine, a certain score will be added to the score table. In addition, when a message that needs to be confirmed does not get a timely and correct reply from the receiver, a deduction will occur; on the contrary, when the confirmation is successfully received, the score table will add points.
- the heartbeat message contains the version information of the software of the communication method running by the controller.
- the main functions of the protocol layer are to provide priority queue management for sending packets, packet header encapsulation and parsing when sending and receiving packets, CRC generation checksum, and packet receiving callback management.
- this module manages 3 message priority queues, namely high, medium and low, and the sending order is high->medium->low, that is, the messages in the high-priority queue will be sent first. Until there are no packets in the queue, there are no packets in the sending priority queue.
- the application layer configures the message priority through M11, and M12 transmits the priority parameter.
- This module configures the parameter through the message priority, and pushes the message into the corresponding priority queue. When the sending periodic task is executed, the packets are pushed into the underlying sending queue in the order of priority.
- the function of this module is to optimize the sending sequence of packets, provide priority sending of urgent packets, and reduce the impact of packet accumulation on the timeliness of application processing.
- the protocol layer After the protocol layer gets the packet data from the application layer, it will add a packet header field to the packet data before pushing it to the underlying driver, which is used for each packet and supplementary related information. After the protocol layer receives the message data from the protocol adaptation layer, it will parse the message body content according to the header field of the message, and pass the data with the header field removed to the application layer through callback.
- This module also has the function of keyword escaping. Because it is defined in the protocol that the header field of a message starts with a specific value as a sign that a message starts, the specific value is not allowed to be included in the entire message. In order to avoid specific values appearing in other places in the message, an escape algorithm needs to be defined to convert the specific values into other values. Taking 0x7e as an example, its escape process is:
- 0x7d ⁇ ——>0x7d is followed by a 0x01.
- the protocol layer performs escaping processing according to the actual packet situation to ensure the uniqueness of the packet header and the correct interpretation of the received packet.
- This module uses the standard CRC32 algorithm to calculate the CRC32 value of the message header and protocol layer message data, and send it to the opposite end together with the message; check whether the CRC32 value of the received message is correct. If the value of the CRC32 field of the received message is equal to the calculated value, the received message is correct. If they are not equal, it means that there is an error in the received packet, and the packet is discarded.
- the main function of this module is to prevent erroneous data from being uploaded to the upper layer due to accidents such as bus interference.
- M23 message reception callback The main function of this module is to return the message after parsing and verifying the message based on M22 and M23 to the global control and adaptation layer through callback.
- the main function of the interface adaptation layer is to isolate the variability of the underlying hardware interface and provide a unified hardware calling interface to the protocol layer. This layer is also the key to ensure that the method can adapt to various hardware platforms.
- the M41 communication handshake management is the key to realize the communication between the two parties to send data to each other on demand.
- the current communication status of the chip and the peer chip (idle, communicating and requesting communication status), quickly reach the communication sending status and send data.
- the party receiving the message data replies to the confirmation message ACK specifically including:
- the party receiving the data message receives that the message data includes the event message type, and takes out the value of the message sequence number field of the message data;
- the party receiving the message data fills the value of the message sequence number field of the message data into the message sequence number field of the acknowledgment message ACK, and sends the acknowledgment message to the party sending the message data ACK.
- the method also includes:
- the party sending the data message receives the acknowledgment message ACK, takes out the message sequence number field of the acknowledgment message ACK, and compares the message sequence number field of the acknowledgment message ACK with all message data in the sending queue. The message sequence number field is compared;
- the party that sends the data message determines that any message data is sent successfully, Move any of the packet data out of the sending queue.
- an embodiment of the present invention provides a full-duplex SPI communication method based on an arbitration line, and the method includes:
- the master detects that the arbitration line corresponding to the slave is at a high potential, and pulls up the potential of the arbitration line corresponding to the master.
- the slave detects that the arbitration line corresponding to the master is at a high level, and confirms that the master is in a communicable state.
- step S23 the slave confirms that the master is in a communicable state, and the slave is in a state of waiting for a chip select signal and a clock signal.
- the master pulls down the potential of the chip select signal and the potential of the arbitration line corresponding to the master, and sends the clock signal to the slave.
- the slave sends the packet header data to the host.
- the host receives the packet header data, confirms the packet transmission length, and sends a chip select signal and a clock signal corresponding to the packet transmission length to the slave.
- the slave sends the message data to the host in one direction, and sends the corresponding clock signal according to the message transmission length stored in the message header data of the slave.
- the slave sends header body data to the host.
- the data of the message sent by the slave to the host is also divided into the header data of the message and the data of the message body and sent successively, and the host does not need to respond to each byte of the message when receiving the message , only need to send the clock signal of the corresponding length. At the same time, during the receiving process, only after receiving the message signal of the specified length will it respond, which saves time and improves efficiency.
- an embodiment of the present invention provides a full-duplex SPI communication method based on an arbitration line, and the method includes:
- the host confirms that the slave is in a communicable state, pulls down the potential of the chip select signal, and sends a clock signal to the slave.
- the master sends the header data of the header to the slave.
- the host sends message body data to the slave.
- the slave device pulls down the potential of the second arbitration line after determining that the message data is successfully sent.
- the first arbitration line and the second arbitration line are provided for determining the working state, communication request and communication response of the master and the slave, so that the master can send message data to the slave, and the slave can send the master to the master.
- the problem of clock synchronization is solved by adjusting the length of the data message, so that the master and the slave can send data messages at the same time; and whether the master sends the data to the slave.
- the data message is divided into header data and message body data, and the receiver does not need to confirm each time, which improves the data Message transmission efficiency; in addition, ACK reply is not required for periodic messages to confirm that the message data is successfully sent, and ACK is used for important messages to confirm that the message data is successfully sent, which improves the efficiency of data message sending and solves the problem of existing SPI communication. In the transmission direction, the flexibility of communication is limited.
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Theoretical Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Communication Control (AREA)
Abstract
本发明提供一种基于仲裁线的全双工SPI通信方法,所述方法包括通讯请求方检测与通讯请求方对应的第一仲裁线和与通信应答方对应的第二仲裁线,当第一仲裁线和第二仲裁线均处于低电位时,拉高第一仲裁线的电位;通讯应答方检测到第一仲裁线处于高电位时,拉高第二仲裁线的电位;通讯请求方检测到第二仲裁线处于高电位时,确认通讯应答方处于可通信状态;双方互相发送报文头部数据;通讯请求方与通讯应答方互相发送报文正文数据。通过本发明,解决了现有SPI通信在传输方向、通讯的灵活性受到限制的问题。
Description
相关申请
本申请要求于2020年7月20日提交中国国家知识产权局、申请号为CN202010696265.5、发明名称为“一种基于仲裁线的全双工SPI通信方法”的中国专利申请的优先权,上述专利的全部内容通过引用结合在本申请中。
本发明涉及汽车通信技术领域,尤其涉及一种基于仲裁线的全双工SPI通信方法。
随着电子系统功能的不断强大,集成化程度不断提高,多芯片系统方案已经成为常见的电子产品设计方案。在多芯片系统方案中,芯片间通讯方式主要为板上总线(UART、IIC、SPI等)。而在汽车电子控制器领域,由于SPI(串行外设接口,Serial Peripheral Interface)通讯具有硬件结构简单,原理简明,具备全双工能力等特点,成为常用的一种总线通讯方式;四线SPI方案能实现有限制的全双工通讯,在这种通讯方案中,只有主设备能主动发起通讯,而从设备不能主动发起通讯,只能等待主设备发起通讯后向主设备发送数据。这种方案在传输方向、通讯的灵活性和载荷能力上都存在较大的限制。
发明内容
本发明实施例所要解决的技术问题在于,提供一种基于仲裁线的全双工SPI通信方法,用于解决现有SPI通信在传输方向、通讯的灵活性和载荷能力上都存在较大的限制的问题。
为解决上述技术问题,本发明提供一种基于仲裁线的全双工SPI通信方法,所述方法包括:
步骤S11、通讯请求方检测与所述通讯请求方对应的第一仲裁线和与通讯应答方对应的第二仲裁线,当所述第一仲裁线和所述第二仲裁线均处于低电位时,拉高所述通讯请求方对应的第一仲裁线的电位;
步骤S12、所述通讯应答方检测到所述第一仲裁线处于高电位时,拉高 所述第二仲裁线的电位;
步骤S13、所述通讯请求方检测到所述第二仲裁线处于高电位时,确认所述通讯应答方处于可通信状态;
步骤S14、所述通讯请求方与所述通讯应答方互相发送报文头部数据;
步骤S15、所述通讯请求方与所述通讯应答方互相发送报文正文数据。
进一步地,在所述步骤S12中,拉高与所述第二仲裁线的电位之前还包括:
所述通讯应答方检测自身状态正常,所述自身状态包括内存空间和通讯状态。
进一步地,所述步骤S14还包括:
所述通讯请求方与所述通讯应答方分别从对方发送的所述报文头部数据中获取对方的报文数据的传输数据长度,并对自身的传输数据长度较短的所述报文数据补齐,使得双方的报文数据的传输数据长度一致。
进一步地,所述步骤S13包括:
当所述通讯请求方为主机时,所述通讯请求方拉低片选信号的电位并向所述通讯应答方发送时钟信号。
进一步地,所述通讯请求方与通讯应答方获取对方的报文数据的传输数据长度,并对自身的数据报文的传输数据长度较短的所述报文数据补齐,使得双方的报文数据长度一致之后还包括:
所述通讯请求方向所述通讯应答方发送与补齐后的报文数据的传输数据长度对应的片选信号和时钟信号,并拉低所述第一仲裁线的电位。
进一步地,所述步骤S15之后还包括:
所述通讯请求方拉高片选信号的电位,并停止向所述通讯应答方发送时钟信号;
所述通讯应答方拉低所述第二仲裁线的电位。
进一步地,所述步骤S13还包括:
当所述通讯请求方为从机时,所述通讯应答方拉低片选信号的电位并向所述通讯请求方发送时钟信号。
进一步地,所述通讯请求方与所述通讯应答方获取对方的报文数据的传 输数据长度,并对自身的传输数据长度较短的所述报文数据补齐,使得双方的报文数据长度一致之后还包括:
所述通讯应答方向所述通讯请求方发送与补齐后的报文数据的传输数据长度对应的片选信号和时钟信号,并拉低所述第二仲裁线的电位。
进一步地,所述步骤S15之后还包括:
所述通讯应答方拉高片选信号的电位,并停止向所述通讯请求方发送时钟信号;
所述通讯请求方拉低所述第二仲裁线的电位。
进一步地,所述通讯请求方与所述通讯应答方分别从对方发送的所述报文头部数据中获取对方的报文数据的传输数据长度,并对自身的传输数据长度较短的所述报文数据补齐,使得双方的报文数据的传输数据长度一致具体包括:
所述通讯请求方与所述通讯应答方分别获取对方的报文头部数据,所述报文头部数据携带报文数据的传输数据长度;
所述通讯请求方与所述通讯应答方分别将自身的报文数据的传输数据长度和对方的报文数据的传输数据长度进行比较;
任意一方确定自身的报文数据的传输数据长度较短,将自身的传输数据长度较短的所述报文数据以预设字符进行补充,使得双方的报文数据的传输数据长度一致。
进一步地,所述报文头部数据包括协议类型字段,所述协议类型字段设置为事件消息类型或者周期消息类型;
当通讯请求方或者通讯应答方发送的报文头部数据包括周期消息类型,发送报文数据的一方完成所述报文数据发送后,确认报文数据发送成功,所述报文数据包括报文头部数据和报文正文数据;
当通讯请求方或者通讯应答方发送的报文头部数据包括事件消息类型,发送所述报文数据的一方启动所述报文数据对应的计时器,在预设计时时间内收到接收报文数据的一方回复确认消息ACK,发送所述报文数据的一方判定报文数据发送成功且将所述报文数据从发送队列中移除。
进一步地,所述方法还包括:
当发送所述报文数据的一方在所述预设时间内未收到所述接收报文数据的一方回复所述确认消息ACK,所述发送报文数据的一方重新发送所述报文数据并再次启动所述计时器;
当重发次数到达预设失败次数,发送所述报文数据的一方判定报文数据发送失败,并通过回调函数将失败信息返回给所述发送报文数据的一方的应用层。
实施本发明实施例,具有如下有益效果:通过本发明,提供了第一仲裁线和第二仲裁线用于判定主机和从机的工作状态、通讯请求和通讯应答,实现了主机可以向从机发送报文数据,以及从机可以向主机发送报文数据,在主机和从机同时发送数据时,通过调整数据报文长度来解决时钟同步的问题,达到了主机与从机同时发送数据报文;且无论是主机向从机发送数据报文,还是从机向主机发送数据报文,或者双向发送数据报文,都将数据报文分成了报文头部数据和报文正文数据,不需要接收方每接收一位字符都进行确认,提升了数据报文传输效率;另外对于周期性报文不需要ACK答复来确认报文数据发送成功,对于重要报文采用ACK来确认报文数据发送成功,提升了数据报文发送效率,解决现有SPI通信在传输方向、通讯的灵活性受到限制的问题。
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的基于仲裁线的全双工SPI通信方法的流程图。
图2是本发明实施例提供的SPI通信方法的层级划分和各组件的整体构架关系图。
图3是本发明实施例提供的有ACK的通用报文协议通信流程图。
图4是本发明实施例提供的无ACK的通用报文协议通信流程图。
图5是本发明实施例提供的基于仲裁线的全双工SPI通信方法的流程图。
图6是本发明实施例提供的基于仲裁线的全双工SPI通信方法的流程图。
以下各实施例的说明是参考附图,用以示例本发明可以用以实施的特定实施例。
如图1所示,本发明实施例提供了基于仲裁线的全双工SPI通信方法,所述方法包括:
步骤S11、通讯请求方检测与所述通讯请求方对应的第一仲裁线和与通讯应答方对应的第二仲裁线,当所述第一仲裁线和所述第二仲裁线均处于低电位时,拉高所述第一仲裁线的电位。
需要说明的是,现有四线SPI包括主机、一个或者多个从机以及四条通讯信号线,分别为时钟线(CLK)、片选(CS)、主机输出信号线(MOSI)、主机输入信号线(MISO)。
在本实施例中,增加了两条SPI通讯信号线,分别为与通讯请求方对应的第一仲裁线和与通讯应答方对应的第二仲裁线,当第一仲裁线位于低电位时,表示通讯请求方处于空闲状态,无数据报文正在发送,当第二仲裁线位于低电位时,表示通讯应答方处于空闲状态,无数据报文正在发送;拉高所述第一仲裁线的电位实际上是通讯请求方发起通讯请求。
还进一步要说明的是,通讯请求方可以是主机也可以是从机,当通讯请求方是主机时,那么通讯应答方必然是从机;同理通讯请求方是从机时,那么通讯请求方必然是主机。
步骤S12、所述通讯应答方检测到所述第一仲裁线处于高电位时,拉高所述第二仲裁线的电位。
需要说明的是,在拉高所述第二仲裁线的电位之前,通讯应答方可以确认自身状态,所述自身状态包括内存空间和通讯状态,当通讯应答方确认自身状态正常时,拉高所述第二仲裁线的电位,本步骤相当于通讯应答方准备应答通讯请求方的通讯请求。
步骤S13、所述通讯请求方检测到所述第二仲裁线处于高电位时,确认所述通讯应答方处于可通信状态。
需要说明的是,步骤S13中还包括:
当所述通讯请求方为主机时,所述通讯请求方拉低片选信号的电位并向 所述通讯应答方发送时钟信号;
当所述通讯请求方为从机时,所述通讯应答方拉低片选信号的电位并向所述通讯请求方发送时钟信号。
拉低片选信号的电位是表明主机选择该从机作为通讯对象,主机向从机发送时钟信号是进行时钟同步。
步骤S14、所述通讯请求方与所述通讯应答方互相发送报文头部数据。
在本实施例中,主机与从机双向发送报文数据,将报文数据分成报文头部数据和报文正文数据分开进行发送,主机通过报文头部数据可以获知该帧报文数据的具体传输长度,并发出对应所述传输长度的时钟信号,不需要从机对每个字节发送都进行响应,节省时间并能够提高效率。
参考表1的报文结构和表2的头部结构,在表2协议类型中包括事件消息类型、大数据传输类型和周期消息类型。
头部信息(4B) | Payload | CRC32(4B) |
表1
起始符(1B) | 协议类型(1B) | PDU长度(2B) |
表2
需要说明的是,报文数据包括报文头部数据和报文正文数据,报文头部数据包括协议类型字段,协议类型字段设置为事件消息类型或者周期消息类型,当所述通讯请求方或者所述通讯应答方发送的报文数据包含周期消息类型,发送数据报文的一方在完成报文数据发送后,确认报文数据发送成功;
当所述通讯请求方或者所述通讯应答方发送的报文数据包含事件消息类型,发送数据报文的一方启动所述数据报文对应的计时器,在预设计时时间内收到接收数据报文的一方回复确认消息ACK,判定所述报文数据发送成功且将所述报文数据从发送队列中移除。
根据实际需要,应用层来进行选择,重要的报文数据选择设置为事件消息类型,非重要的或者周期性的报文数据选择设置为周期消息类型,对于周期消息类型不需要确认消息ACK进行确认,节省了非重要报文ACK所使用的时间。
所述步骤S14还包括:
所述通讯请求方与所述通讯应答方分别从对方的所述报文头部数据中获取对方的报文数据的传输数据长度,对自身的传输数据长度较短的所述报文数据补齐,使得双方的报文数据的传输数据长度一致。
具体地,所述通讯请求方与所述通讯应答方分别获取对方的报文头部数据,所述报文头部数据携带报文数据的传输数据长度;
所述通讯请求方与所述通讯应答方分别将自身的报文数据的传输数据长度和对方的报文数据的传输数据长度进行比较;
任意一方确定自身的报文数据的传输数据长度较短,将自身的传输数据长度较短的所述报文数据以预设字符进行补充,使得双方的报文数据的传输数据长度一致。
需要说明的是,通讯请求方的对方是指通讯应答方,通讯应答方的对方是指通讯请求方;任意一方确定自身的报文数据的传输数据长度较短,用0x00字符对报文正文数据补齐,使得双方的报文数据的传输数据长度一致。
所述通讯请求方与所述通讯应答方分别从对方的所述报文头部数据中获取对方的报文数据的传输数据长度,对自身的传输数据长度较短的所述报文数据补齐,使得双方的报文数据的传输数据长度一致之后还包括:
当所述通讯请求方为主机时,所述通讯请求方向所述通讯应答方发送与补齐后的报文数据的传输数据长度对应的片选信号和时钟信号,并拉低所述第一仲裁线的电位。
当所述通讯请求方为从机时,所述通讯应答方向所述通讯请求方发送与补齐后的报文数据的传输数据长度较长对应的片选信号和时钟信号,并拉低所述第二仲裁线的电位。
步骤S15、所述通讯请求方与所述通讯应答方互相发送报文正文数据。
所述步骤S15之后还包括:
当所述通讯请求方为主机时,所述通讯请求方拉高片选信号的电位,并停止向所述通讯应答方发送时钟信号;
所述通讯应答方拉低所述第二仲裁线的电位。
当所述通讯请求方为从机时,所述通讯应答方拉高片选信号的电位,并停止向所述通讯请求方发送时钟信号;
所述通讯请求方拉低所述第二仲裁线的电位。
通过上述步骤,通讯请求方和通讯应答方完成数据报文发送后,分别将对应的仲裁线的电位拉低,都恢复到空闲状态,可以进行下一次发送。
进一步地,所述报文头部数据包括协议类型字段,所述协议类型字段设置为事件消息类型或者周期消息类型;
当通讯请求方或者通讯应答方发送的报文头部数据包括周期消息类型,发送报文数据的一方完成所述报文数据发送后,确认报文数据发送成功,所述报文数据包括报文头部数据和报文正文数据;
当通讯请求方或者通讯应答方发送的报文头部数据包括事件消息类型,发送所述报文数据的一方启动所述报文数据对应的计时器,在预设计时时间内收到接收报文数据的一方回复确认消息ACK,发送所述报文数据的一方判定报文数据发送成功且将所述报文数据从发送队列中移除。
进一步地,所述方法还包括:
当发送所述报文数据的一方在所述预设时间内未收到所述接收报文数据的一方回复所述确认消息ACK,所述发送报文数据的一方重新发送所述报文数据并再次启动所述计时器;
当重发次数到达预设失败次数,发送所述报文数据的一方判定报文数据发送失败,并通过回调函数将失败信息返回给所述发送报文数据的一方的应用层。
需要说明的是,通过多次重试的方式来提高成功的概率,同时通过限制失败次数来避免资源被过度浪费。
参考图2,上述通信方法是基于通信方法的层级划分和各组件的整体结构为基础的,在图2中全局控制和适配层包括:M11、应用交互接口;M12、应用报文管理;M13、SourceID管理;M14、应用回调和反馈管理;M15、ACK&重传;M16、通讯管理协议。
M11、应用交互接口,对外提供统一的调用接口,应用通过提供的接口实现:发送报文,设置报文的处理方式,配置报文优先级,注册和管理报文接收回调函数,查询通讯状态等操作。
M12、应用报文管理,应用通过M11,将需要发送报文的ID和类型传 进M12,然后M12根据报文中相关的参数设置信息控制协议层的模块执行报文传输。
M13、SourceID管理,为了区分每一条报文,本模块会对每一条报文提供一个唯一(至少一段时间内)序列号作为凭证。当应用层发送报文时,在组装报文的过程中会调用本模块申请序列号,本模块按照指定程序产生唯一的序列号,再将序列号返回给报文组装函数。
如前所述,序列号的取值范围应该足够大,以确保整个系统在一定时间能根据序列号区分每一条不同的报文,避免对不同时间发出但是内容一样的报文进行误操作。
M14、应用的回调和反馈管理,应用通过M11提供的接口,将ID号和回调函数成对绑定传进M14,M14的主要功能是根据ID号找到对应的回调函数,将该ID报文在传输过程中产生的信息(包括发送失败、接收报文等)返回给应用。同时应用可使用M11提供的接口对M14中保存的信息进行操作。
M15、ACK&重传,本方法报文协议提供两种类型报文,分别为周期型报文和事件型报文,其格式见表3和表4。
发送
序列号(2B) | 命令(2B) | 数据长度(2B) | 数据(0-64KB) |
回复
序列号(2B) | 长度(2B) | 数据(0-64KB) |
表3
字段说明:
序列号(2 Bytes) | 0-65535循环 |
命令(2 Bytes) | 8bits(命令组ID)+8bits(命令子ID) |
长度(2 Bytes) | 协议内数据长度 |
数据(0-64kB less protocol overhead) | 数据 |
表4
周期型报文是指发送方周期性发送的报文,其特点是不需要接收方回复确认信息(ACK);而事件型报文在被发送出去后,需要接收方回复确认信息并且发送方接收到确认信息后才算发送成功,否则发送方会进行重发或者发送失败处理,其具体过程如下:
当发送出一帧事件型报文后,本模块启动一个对于该报文的计时器,然后在一段时间内等待接收方回复的接收确认ACK信息。如果及时收到了ACK则判定该报文已发送成功,该条报文会被移出发送队列;如果超时未收到ACK则判定该报文本次发送失败,重新发送该条报文并计时;当重发到达一定次数后,则判定该条报文发送失败并通过回调函数将失败信息返回给应用。当收到一帧事件型报文后,接收方生成ACK报文,并发送出去。
一条事件型报文和它的ACK配对是依靠报文的报文序列号字段实现。接收方在收到事件型报文后,将报文的报文序列号字段的值取出,并装填进回复ACK的报文序列号字段。发送方接收到ACK后会对序列号进行对照,当其序列号与发送队列中某一条事件型报文一致时,认为该条报文已经发送成功,将其移出发送队列。
M16、通信管理协议,这个模块负责心跳报文的接收和发送,以及管理通信状态。通信管理协议专门定义心跳报文的格式,具体参见下面表5,查询对端控制器连接状态,以及通信状态转换的逻辑。通信管理协议规定,在一个多核通信的嵌入式产品中,承担“通信中枢”角色的控制器设定为通信状态管理的主机,其它的都设定为从机。协议还规定了在整个通讯网络中,有且只有一个主机,一个或多个从机。
发送心跳
序列号(2B) | 命令(1B) | 协议版本(1B) |
回复
序列号(2B) | 命令(1B) | 协议版本(1B) |
字段说明:
序列号(2 Bytes) | 0-65535循环 |
命令(1 Bytes) | 心跳 |
协议版本(1 Bytes) | 标准协议版本符号 |
表5
通信管理协议主要包含以下子模块:1、通信状态管理;2、周期心跳管理。
1、通信状态管理。
首先,主机按照固定周期发出一条心跳报文,从机在接收到心跳报文后按照协议约定,回复一条心跳报文。在通讯状态管理模块中,主机将维护与从机通讯质量相关的评分表,作为通讯状态管理的主要依据。
主机在发出心跳报文后,会同时启动计时器,若在指定时间内未收到从机的心跳报文,将在通讯质量评分表上扣除指定分值;反之,当在约定时间内收到从机回复的心跳报文后,就在评分表上增加一定的分值。此外,当一条需要确认的报文没有及时和正确地得到接收方的回复,则发生一次扣分;反之,当成功收到确认后,分值表加分。当发生多次扣分而分值低于一个阈值2后,判定与该从机的“降级为”连通且阻塞通信模式,即没有收到确认之前不会发送下一条报文;而分值低于一个阈值1后,判定通信断开,此时只有心跳报文发送,其余报文一律不发送。反之,在分值高于一个阈值1后,判定与该从机的通信连通且阻塞通信模式,在分数高于一个阈值2后,判定与该从机的通信连通且连续通信模式。从机也在其通信管理协议模块中维护同样的评分表,其过程与上述一致。
2、周期心跳管理。
如果是主机,不论当前通信状态如何,都按照固定周期,封装心跳报文并发送给协议层。心跳报文包含本控制器运行的本通信方法的软件的版本信息。
如果是从机,不论当前通信状态如何,在收到主机发来的心跳报文后,都要封装一条用于回应的心跳报文,将回应的心跳报文发送到协议层。
协议层的主要功能是提供发送报文优先级队列管理,收发报文时的报文头封装和解析、CRC生成校验和报文接收回调管理。
M21报文优先级管理,该模块管理着3个报文优先级队列,分别为高、中、低,发送顺序为高->中->低,即高优先级队列中报文会优先发送,直到队列中没有报文了在发送中优先级队列中的报文。应用层通过M11配置报文优先级,由M12传递优先级参数,本模块通过报文的优先级配置参数, 将该条报文压入对应优先级队列。发送周期任务执行时,按照优先级顺序将报文压入底层的发送队列。本模块的作用是优化报文发送顺序,提供紧急报文优先发送功能,减少报文堆积对应用处理时效性的影响。
M22报文头封装和解析,协议层拿到应用层的报文数据后,在推向底层驱动前会给报文数据增加报文头字段,用于区每一条报文和补充相关信息。协议层从协议适配层收到报文数据后,会根据报文的头字段解析报文正文内容,并把去除了头字段的数据通过回调传给应用层。
本模块还具有关键字转义的功能。因为协议中定义报文头字段以某一个特定值作为一条报文开始的标志,所以在整条报文中不允许再包含该特定值。为了避免报文其他位置出现特定值,需要定义转义算法,将出现特定值转换成其它值。以0x7e为例,其转义过程为:
假设使用0x7e作为报文起始标志,若其他位置出现0x7e,则要进行转义处理,转义规则定义如下:
0x7e<———>0x7d后紧跟一个0x02;
0x7d<———>0x7d后紧跟一个0x01。
协议层根据实际报文情况进行转义处理,确保报文头的唯一性,并保证正确解读接收报文。
M23CRC生成和校验。本模块使用标准的CRC32算法,对报文头和协议层报文数据计算出CRC32值,并与该条报文一起被发送至对端;校验收到报文的CRC32值是否正确。若接收报文的CRC32字段值,与计算的相等,则收到的报文正确无误。如果不相等,则说明接收到的报文有错误,丢弃该报文。本模块的主要作用是防止因总线干扰等意外造成的错误数据被上传至上层。
M23报文接收回调。本模块主要功能是将基于M22和M23对报文进行解析和校验后的报文通过回调方式返回给全局控制和适配层。
接口适配层的主要功能是隔绝底层硬件接口的多变性,向协议层提供统一的硬件调用接口。该层也是保证本方法能适配各种硬件平台的关键。
在硬件接口层中,M41通讯握手管理是实现通讯双方按需互发送数据的关键,其主要功能是通过对通讯状态仲裁线(第一仲裁线,第二仲裁线)的 状态进行判断,得知当前芯片和对端芯片的通讯状态(空闲、正在通讯以及请求通讯状态),迅速达成通讯发送状态,发送数据。
进一步地,所述接收报文数据的一方回复所述确认消息ACK具体包括:
所述接收数据报文的一方接收到所述报文数据包含所述事件消息类型,将所述报文数据的报文序列号字段的值取出;
所述接收报文数据的一方将所述报文数据的报文序列号字段的值装填进所述确认消息ACK的报文序列号字段,向所述发送报文数据的一方发送所述确认消息ACK。
进一步地,所述方法还包括:
所述发送数据报文的一方接收到所述确认消息ACK,将所述确认消息ACK的报文序列号字段取出,将所述确认消息ACK的报文序列号字段与发送队列中所有报文数据的报文序列号字段进行比较;
当所述确认消息ACK的报文序列号字段与发送队列中任一报文数据的所述报文序列号字段相同,所述发送数据报文的一方判定所述任一报文数据发送成功,将所述任一报文数据移出发送队列。
借助图3和图4,可以看到有ACK的通用报文协议通讯流程远比无ACK的通用报文协议通信流程要复杂,时间长,系统资源消耗多,对非重要消息采用无ACK方式,时间短且效率高。
如图5所示,本发明实施例提供了基于仲裁线的全双工SPI通信方法,所述方法包括:
S21、当从机检测到与主机对应的仲裁线和与从机对应的仲裁线均处于低电位时,拉高所述与从机对应的仲裁线的电位。
S22、所述主机检测到所述与从机对应的仲裁线位于高电位,拉高所述与主机对应的仲裁线的电位。
S23、所述从机检测到所述与主机对应的仲裁线位于高电位,确认所述主机处于可通信状态。
需要说明的是,步骤S23中从机确认主机处于可通信状态,所述从机处于等待片选信号和时钟信号状态。
S24、所述主机拉低所述片选信号的电位和所述与主机对应的仲裁线的 电位,向所述从机发送所述时钟信号。
S25、所述从机向所述主机发送报文头部数据。
S26、所述主机接收到所述报文头部数据,确认所述报文传输长度,向所述从机发送与所述报文传输长度对应的片选信号和时钟信号。
需要说明的是,本实施例中是从机单向向主机发送报文数据,根据从机的报文头部数据中存储的报文传输长度,发送对应时钟信号。
S27、所述从机向所述主机发送报头正文数据。
在本实施例中,从机向主机发送报文数据,也是分为报文头部数据和报文正文数据先后发送,主机在接收报文的时候不需要对报文的每一个字节进行响应,只需要发送对应长度的时钟信号。同时在接收过程中,当接收完指定长度的报文信号后才会进行响应,节省时间并能够提高效率。
S28、所述主机接收报文正文数据后,停止发送时钟信号并拉高片选信号的电位,同时所述从机确认本次报文数据发送成功,拉低所述第二仲裁线的电位。
如图6所示,本发明实施例提供了基于仲裁线的全双工SPI通信方法,所述方法包括:
S31、主机检测到与主机对应的仲裁线和与从机对应的仲裁线均处于低电位时,拉高与所述主机对应的仲裁线的电位。
S32、从机检测到与主机对应的仲裁线处于高电位时,拉高与所述丛机对应的仲裁线的电位。
S33、主机确认从机处于可通讯状态,拉低片选信号的电位并发送向从机发送时钟信号。
S34、所述主机向所述从机发送头报文头部数据。
S35、所述主机向所述从机发送报文正文数据。
S36、所述主机在报文数据发送成功后,停止发送所述时钟信号并拉高片选信号的电位。
S37、所述从机在确定报文数据发送成功,拉低所述第二仲裁线的电位。
通过本发明,提供了第一仲裁线和第二仲裁线用于判定主机和从机的工作状态、通讯请求和通讯应答,实现了主机可以向从机发送报文数据,以及 从机可以向主机发送报文数据,在主机和从机同时发送数据时,通过调整数据报文长度来解决时钟同步的问题,达到了主机与从机同时发送数据报文;且无论是主机向从机发送数据报文,还是从机向主机发送数据报文,或者双向发送数据报文,都将数据报文分成了报文头部数据和报文正文数据,不需要接收方每次都进行确认,提升了数据报文传输效率;另外对于周期性报文不需要ACK答复来确认报文数据发送成功,对于重要报文采用ACK来确认报文数据发送成功,提升了数据报文发送效率,解决现有SPI通信在传输方向、通讯的灵活性受到限制的问题。
以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明,不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干简单推演或替换,都应当视为属于本发明的保护范围。
Claims (12)
- 一种基于仲裁线的全双工SPI通信方法,其特征在于,所述方法包括:步骤S11、通讯请求方检测与所述通讯请求方对应的第一仲裁线和与通讯应答方对应的第二仲裁线,当所述第一仲裁线和所述第二仲裁线均处于低电位时,拉高所述第一仲裁线的电位;步骤S12、所述通讯应答方检测到所述第一仲裁线处于高电位时,拉高所述第二仲裁线的电位;步骤S13、所述通讯请求方检测到所述第二仲裁线处于高电位时,确认所述通讯应答方处于可通信状态;步骤S14、所述通讯请求方与所述通讯应答方互相发送报文头部数据;步骤S15、所述通讯请求方与所述通讯应答方互相发送报文正文数据。
- 如权利要求1所述方法,其特征在于,在所述步骤S12中,拉高与所述第二仲裁线的电位之前还包括:所述通讯应答方检测自身状态正常,所述自身状态包括内存空间和通讯状态。
- 如权利要求1所述方法,其特征在于,所述步骤S14还包括:所述通讯请求方与所述通讯应答方分别从对方发送的所述报文头部数据中获取对方的报文数据的传输数据长度,并对自身的传输数据长度较短的所述报文数据补齐,使得双方的报文数据的传输数据长度一致。
- 如权利要求3所述方法,其特征在于,所述步骤S13还包括:当所述通讯请求方为主机时,所述通讯请求方拉低片选信号的电位并向所述通讯应答方发送时钟信号。
- 如权利要求4所述方法,其特征在于,所述通讯请求方与所述通讯应答方获取对方的报文数据的传输数据长度,并对自身的传输数据长度较短的所述报文数据补齐,使得双方的报文数据长度一致之后还包括:所述通讯请求方向所述通讯应答方发送与补齐后的报文数据的传输数据长度对应的片选信号和时钟信号,并拉低所述第一仲裁线的电位。
- 如权利要求5所述方法,其特征在于,所述步骤S15之后还包括:所述通讯请求方拉高片选信号的电位,并停止向所述通讯应答方发送时 钟信号;所述通讯应答方拉低所述第二仲裁线的电位。
- 如权利要求3所述方法,其特征在于,所述步骤S13还包括:当所述通讯请求方为从机时,所述通讯应答方拉低片选信号的电位并向所述通讯请求方发送时钟信号。
- 如权利要求7所述方法,其特征在于,所述通讯请求方与所述通讯应答方获取对方的报文数据的传输数据长度,并对自身的传输数据长度较短的所述报文数据补齐,使得双方的报文数据长度一致之后还包括:所述通讯应答方向所述通讯请求方发送与补齐后的报文数据的传输数据长度对应的片选信号和时钟信号,并拉低所述第二仲裁线的电位。
- 如权利要求8所述方法,其特征在于,所述步骤S15之后还包括:所述通讯应答方拉高片选信号的电位,并停止向所述通讯请求方发送时钟信号;所述通讯请求方拉低所述第二仲裁线的电位。
- 如权利要求3所述方法,其特征在于,所述通讯请求方与所述通讯应答方分别从对方发送的所述报文头部数据中获取对方的报文数据的传输数据长度,并对自身的传输数据长度较短的所述报文数据补齐,使得双方的报文数据的传输数据长度一致具体包括:所述通讯请求方与所述通讯应答方分别获取对方的报文头部数据,所述报文头部数据携带报文数据的传输数据长度;所述通讯请求方与所述通讯应答方分别将自身的报文数据的传输数据长度和对方的报文数据的传输数据长度进行比较;任意一方确定自身的报文数据的传输数据长度较短,将自身的传输数据长度较短的所述报文数据以预设字符进行补充,使得双方的报文数据的传输数据长度一致。
- 如权利要求1所述方法,其特征在于,所述报文头部数据包括协议类型字段,所述协议类型字段设置为事件消息类型或者周期消息类型;当通讯请求方或者通讯应答方发送的报文头部数据包括周期消息类型,发送报文数据的一方完成所述报文数据发送后,确认报文数据发送成功,所 述报文数据包括报文头部数据和报文正文数据;当通讯请求方或者通讯应答方发送的报文头部数据包括事件消息类型,发送所述报文数据的一方启动所述报文数据对应的计时器,在预设计时时间内收到接收报文数据的一方回复确认消息ACK,发送所述报文数据的一方判定报文数据发送成功且将所述报文数据从发送队列中移除。
- 如权利要求11所述方法,其特征在于,所述方法还包括:当发送所述报文数据的一方在所述预设时间内未收到所述接收报文数据的一方回复所述确认消息ACK,所述发送报文数据的一方重新发送所述报文数据并再次启动所述计时器;当重发次数到达预设失败次数,发送所述报文数据的一方判定报文数据发送失败,并通过回调函数将失败信息返回给所述发送报文数据的一方的应用层。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/915,667 US20230119412A1 (en) | 2020-07-20 | 2021-06-22 | Arbitration line-based full-duplex spi communication method |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010696265.5A CN113965307A (zh) | 2020-07-20 | 2020-07-20 | 一种基于仲裁线的全双工spi通信方法 |
CN202010696265.5 | 2020-07-20 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2022017102A1 true WO2022017102A1 (zh) | 2022-01-27 |
Family
ID=79459413
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2021/101480 WO2022017102A1 (zh) | 2020-07-20 | 2021-06-22 | 一种基于仲裁线的全双工spi通信方法 |
Country Status (3)
Country | Link |
---|---|
US (1) | US20230119412A1 (zh) |
CN (1) | CN113965307A (zh) |
WO (1) | WO2022017102A1 (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114640703A (zh) * | 2022-03-14 | 2022-06-17 | 中国第一汽车股份有限公司 | 一种数据通信的方法、装置、电子设备及存储介质 |
CN115150308B (zh) * | 2022-07-19 | 2023-10-10 | 天翼云科技有限公司 | 一种流量统计方法和装置 |
CN116962112B (zh) * | 2023-09-20 | 2023-12-15 | 中国船舶集团有限公司第七〇七研究所 | 基于标准spi总线连接的双机全双工数据透明传输方法 |
CN118377746A (zh) * | 2024-04-29 | 2024-07-23 | 重庆赛力斯凤凰智创科技有限公司 | 基于iic协议的双向传输系统、方法及电子设备 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102819512A (zh) * | 2012-06-28 | 2012-12-12 | 惠州市德赛西威汽车电子有限公司 | 一种基于spi的全双工通信装置及其方法 |
EP3026569A1 (en) * | 2014-11-28 | 2016-06-01 | Gemalto Sa | A communication system with a frame based communication interface |
CN107967227A (zh) * | 2017-12-22 | 2018-04-27 | 苏州国芯科技有限公司 | 一种基于spi的通信方法及spi主机、spi从机 |
CN111130710A (zh) * | 2019-12-10 | 2020-05-08 | 常州新途软件有限公司 | 一种基于spi的双工通信方法 |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6058436A (en) * | 1997-06-16 | 2000-05-02 | Adaptec, Inc. | Quick arbitration and select (QAS) protocol in SCSI interface for configuring a current target device to assert a QAS message code during a message-in phase |
CN102508812B (zh) * | 2011-11-30 | 2013-09-04 | 上海大学 | 一种基于spi总线的双处理器通信方法 |
CN103548297A (zh) * | 2012-03-21 | 2014-01-29 | 华为技术有限公司 | 确认包的处理方法、设备及系统 |
US20150254198A1 (en) * | 2013-03-15 | 2015-09-10 | Google Inc. | Methods and apparatus related to bus arbitration within a multi-master system |
CN103744825A (zh) * | 2013-12-31 | 2014-04-23 | 北京中宇新泰科技发展有限公司 | 一种扩展兼容spi接口双向实时通讯方法 |
CN108073538B (zh) * | 2016-11-17 | 2020-01-07 | 英业达科技有限公司 | 集成电路总线仲裁控制系统 |
CN110881006B (zh) * | 2018-09-06 | 2021-02-23 | 华为技术有限公司 | 发送报文的方法、网络设备及计算机存储介质 |
CN110234124B (zh) * | 2019-04-19 | 2022-04-01 | 维沃移动通信(深圳)有限公司 | 信息传输方法及终端设备 |
CN110674065B (zh) * | 2019-10-09 | 2021-01-15 | 上海钧正网络科技有限公司 | 一种在总线上的竞争仲裁方法和系统 |
CN110990312B (zh) * | 2019-11-11 | 2021-01-22 | 无锡量子感知研究所 | 一种用于随钻探测中的芯片级数据通信方法 |
CN111193621B (zh) * | 2019-12-30 | 2022-09-23 | 上海锐伟电子科技有限公司 | 一种物联网rtos设备端与服务端保障数据通信的方法 |
-
2020
- 2020-07-20 CN CN202010696265.5A patent/CN113965307A/zh active Pending
-
2021
- 2021-06-22 US US17/915,667 patent/US20230119412A1/en active Pending
- 2021-06-22 WO PCT/CN2021/101480 patent/WO2022017102A1/zh active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102819512A (zh) * | 2012-06-28 | 2012-12-12 | 惠州市德赛西威汽车电子有限公司 | 一种基于spi的全双工通信装置及其方法 |
EP3026569A1 (en) * | 2014-11-28 | 2016-06-01 | Gemalto Sa | A communication system with a frame based communication interface |
CN107967227A (zh) * | 2017-12-22 | 2018-04-27 | 苏州国芯科技有限公司 | 一种基于spi的通信方法及spi主机、spi从机 |
CN111130710A (zh) * | 2019-12-10 | 2020-05-08 | 常州新途软件有限公司 | 一种基于spi的双工通信方法 |
Also Published As
Publication number | Publication date |
---|---|
US20230119412A1 (en) | 2023-04-20 |
CN113965307A (zh) | 2022-01-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2022017102A1 (zh) | 一种基于仲裁线的全双工spi通信方法 | |
US7733885B2 (en) | Extending access to a device in a limited connectivity network to devices residing outside the limited connectivity network | |
WO2021232681A1 (zh) | 耳机与充电盒的通信方法、充电盒、耳机及可读存储介质 | |
JP2010518753A (ja) | ネットワークにおけるレイヤ2マネージメントエンティティメッセージングフレームワーク | |
CN114422289B (zh) | 一种电动汽车can报文的传输方法及装置 | |
WO2023030336A1 (zh) | 数据传输方法、tsn节点和计算机可读存储介质 | |
WO2020063865A1 (zh) | Can电路结构及其车辆诊断设备 | |
CN110557321B (zh) | 一种信息传输方法、网络设备及终端 | |
WO2024045742A1 (zh) | 一种计算设备 | |
CN108173851B (zh) | 一种用于空间信息网络的高效多媒体传输方法 | |
CN114422288A (zh) | 基于Modbus协议的通讯系统 | |
CN112395237B (zh) | 一种至少两个控制器之间通信的方法及其系统 | |
CN114826812B (zh) | 一种rs485通信多主站的实现方法及系统 | |
CN108810000B (zh) | 一种生成序列化和反序列化api的方法及装置 | |
CN106850660B (zh) | 一种基于SocketCAN的SAE J1939传输协议的设计方法 | |
CN101345749B (zh) | 基于rts/cts机制的多跳无线网络拥塞控制方法 | |
US20050141555A1 (en) | Method for generating commands for network controller modules of peripheral devices | |
CN102681969B (zh) | 基于can总线的长帧数据传输方法 | |
KR100609493B1 (ko) | 복수의 센서 데이터를 하나의 캔 메시지로 전송하는 방법 | |
CN101094241B (zh) | 混合自动请求重传的传输方法及装置 | |
CN101950485B (zh) | 交通信号灯数字组网设备 | |
WO2024178923A1 (zh) | 基于spi的数据传输方法、芯片、控制器及存储介质 | |
WO2013026309A1 (zh) | 板间通信方法及装置 | |
EP4380244A1 (en) | Communication method and apparatus | |
CN110505641B (zh) | 利用全双工UART通信提高ZigBee主从通信轮询效率的方法及其协调器 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 21847267 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 21847267 Country of ref document: EP Kind code of ref document: A1 |