Response messages in asynchronous communications

Abstract

The invention relates to response messages in asynchronous communications. The present disclosure describes an asynchronous communication system in which a responder node receives a frame of a message from a commander node and receives a request frame in a predetermined position related to the frame of the message. The responder node is configured to send a response to respond to the request frame, and in some examples, the responder node sends a response frame while the responder node receives the request frame from the commander node.

Description

Technical Field

[0001] This invention generally relates to communication systems, and more specifically to asynchronous data communication. Background Technology

[0002] In some applications, it is beneficial to employ relatively low-cost and / or low-power communication systems. Some low-cost and / or low-power communication systems employ asynchronous communication techniques, where a central clock signal is not shared among the nodes of the communication system. Instead, the nodes of the communication system are coupled via a common bus. A corresponding node in the communication system can be configured as a command node to send messages to other nodes as responder nodes (or more).

[0003] In some applications of asynchronous communication, one or more responder nodes may send a response message with an acknowledgment in response to a message from a command node. For example, such an acknowledgment may indicate to the command node whether the sent message was received by the responder node(s). In other examples, the command node may request that a request for data be sent as part of a message to the responder node(s).

[0004] In traditional asynchronous communication systems, responder nodes send response messages based on the timed intervals of (multiple) responder nodes. For example, once (multiple) responder nodes determine that the public bus is idle (no messages are being transmitted), and / or after other messages have already been transmitted by the responder nodes, (multiple) responder nodes can send a response message.

[0005] In some examples of traditional asynchronous communication systems, the scheduling of tasks and communication by corresponding nodes may require a large amount of computing power, which may increase the cost, complexity, and / or energy consumption of such systems. Summary of the Invention

[0006] This disclosure relates to improvements in asynchronous data communication, specifically enabling responses to be transmitted with reduced cost complexity and / or power consumption compared to conventional systems. For example, in some aspects, a method is described. This method includes: receiving one or more data frames of a message; receiving a request frame at a defined location associated with the one or more data frames of the message; and sending a response in response to the request frame.

[0007] As another example, in some aspects, a communication node is described. This communication node is configured to: receive one or more data frames of a message, receive a request frame at a defined location associated with the one or more data frames of the message, and send a response in response to the request frame.

[0008] As another example, in some aspects, a system is described. The system includes a command node and at least one responder node communicatively coupled to the command node via a common bus. The responder node is configured to: receive one or more data frames of a message from the command node, receive a request frame from the command node at a defined location associated with the one or more data frames of the message, and send a response to the command node in response to the request frame. Attached Figure Description

[0009] Figure 1A This is a block diagram depicting an example of an asynchronous communication system according to some embodiments.

[0010] Figure 1B This is a block diagram illustrating an example of an asynchronous communication system arranged to use full-duplex communication according to some embodiments.

[0011] Figure 2 This is a timing diagram depicting an example of a UART message that can be transmitted from a UART transmitter to a UART receiver according to some embodiments.

[0012] Figure 3 This is a block diagram depicting an example of a communication device according to some embodiments.

[0013] Figure 4A This is a timing diagram depicting an example of communication between a command node and one or more responder nodes according to some embodiments.

[0014] Figure 4B This is a timing diagram depicting an example of communication between a command node and one or more responder nodes according to some embodiments.

[0015] Figure 5 It is a timing diagram depicting a request frame sent from a command node to a responder node according to some embodiments, and a response frame generated by the responder node in response to the request frame.

[0016] Figure 6 This is a flowchart illustrating an example of a method for operating an asynchronous communication node according to some embodiments. Detailed Implementation

[0017] Figure 1A This is a block diagram illustrating an example of an asynchronous communication system 100 arranged to use half-duplex communication according to some embodiments. Figure 1A As shown, system 100 includes multiple communication nodes 110, 120, 120B that are communicationally coupled to a common bus 122. The multiple communication nodes 110, 120, 120B are configured to communicate asynchronously, that is, to communicate asynchronously based on a common bit rate without using a distributed clock signal.

[0018] In some examples, system 100 is configured to operate asynchronously, for example, according to the Universal Asynchronous Receiver / Transmitter (UART) protocol. According to the UART protocol, nodes 110, 120, and 120B each include a UART transmitter 111 and a UART receiver 113, configured to send and receive messages as data frames having a predefined number of data bits, respectively. The connections between the UART transmitter and UART receiver depicted in the figure illustrate the flow of information from transmitter to receiver. The physical implementation of these connections may include elements such as wires, connectors, wire joints, input stages, output stages, level shifters, logic gates, storage elements such as flip-flops or latches, and isolation elements such as inductors, capacitors, or optocouplers.

[0019] exist Figure 1A In the example, system 100 is configured to operate using a "half-duplex" communication scheme, in which the corresponding nodes 110, 120, and 120B of system 100 communicate in turn on the common bus 122. In the half-duplex communication scheme, only one node sends data to the other nodes at a time, and data transmitted by one node is received by the other nodes.

[0020] In a half-duplex communication scheme, depending on how system 100 is configured, a dominant bit can represent a low voltage level (logic 0) on the common bus 122 overriding a high voltage level (logic 1). In other examples, a dominant bit can represent a low voltage level (logic 0) on the common bus 122 overriding a high voltage level (logic 1).

[0021] exist Figure 1A In the example, node 110 is configured as a command node, and nodes 120A and 120B are configured as responder nodes. In some examples, message 130 sent by command node 110 may include request frame 150, which indicates that response 160 should be sent by at least one of the nodes(s) 120A and 120B that acknowledge whether message 130 has been received.

[0022] Figure 1B This is a block diagram depicting an example of an asynchronous communication system 100 arranged to use full-duplex communication according to some embodiments. Figure 1B In the example, the transmitter UART TX 111' of the command node 110' is connected to the receiver UART RX 113' of the responder node 120 via a first connection. The transmitter UART TX 111' of the responder node 120' is connected to the receiver UART RX 113' of the command node 110 via a second connection. Using separate connections allows frames to be transmitted in parallel on both connections without the risk of data collisions or data corruption.

[0023] Figure 2 This is a timing diagram illustrating an example of a UART message 130 that can be transmitted from a UART transmitter 111 to a UART receiver 113 according to some embodiments. Message 230 can be, for example, transmitted by... Figure 1A In the example shown, the UART transmitter 111 of the command node 110 sends message 230 to one or more responder nodes 120A, 120B. In other examples, message 230 may be sent by nodes configured as responder nodes 120A, 120B to command node 110 and / or other responder nodes of system 100.

[0024] exist Figure 2 In the example, message 130 includes multiple UART frames 240A and 240B. According to... Figure 2 For example, system 100 is configured such that the dominant bit has a low voltage level (logic 0) and the recessive bit has a high voltage level (logic 1). In other examples not depicted, the dominant bit has a high voltage level (logic 1) and the recessive bit has a low voltage level (logic 0). According to Figure 2 For example, message 230 includes two frames 240A and 240B, each frame having a predetermined number of bits. Figure 2 In this example, there are eight frames. In other examples, the message may include a larger, predetermined number of N frames. As a non-limiting example, if implemented according to the Local Interconnect Network (LIN) protocol, message 130 may include eight frames, each consisting of eight data bits (bytes).

[0025] like Figure 2 As shown, the corresponding bits of frames 240A and 240B are separated by a bit length of 1 bit. Figure 2 The black dots in the text represent the time it takes for each bit of frames 240A and 240B to be sampled by one or more UART receivers 113 based on the bit length of the received message 230.

[0026] like Figure 2 As shown, in order to transmit a message, when the common bus 122 is in the IDLE state (recessively representing logic high (1)), the UART transmitter 111 begins outputting the first frame 240A of message 230 by outputting the Start of Frame (SOF) bit on the common bus 122. The SOF bit can have a dominant voltage level (i.e., in Figure 2 In the example, it is logic low (0) and signals (multiple) UART receivers 113 that frame 240A will be transmitted. After the SOF bit, the UART transmitter 111 sequentially outputs eight data bits D0-D7, each data bit indicating whether the bit of the transmitted message 230 is dominant (logic high (1)) or recessive (logic low (0)).

[0027] Following the output data bits D0-D7, UART transmitter 111 outputs at least one STOP bit (in an example not depicted, message 130 may include one or more other STOP bits), which may have a recessive voltage level (in...). Figure 2 In the example, logic low (1) is used to signal that communication of frame 240A has ended. After (multiple) STOP bits are transmitted, the public bus 122 returns to the IDLE state (i.e., with a recessive voltage level).

[0028] At some point when at least one STOP bit is output, the UART transmitter 111 similarly outputs frames of message 230, such as in Figure 2 The UART transmitter 111 outputs a dominant SOF bit, followed by multiple data bits D0-D7, and then at least one stop bit indicating that the transmission of frame 240B has ended. The UART transmitter 111 continues to output the same data. Figure 2 The message 130 is not depicted in any other frames until the last frame of the message has been transmitted. Based on the non-limiting example of the LIN protocol referenced above, a UART transmitter can send messages consisting of 8 data frames each.

[0029] According to traditional asynchronous protocols, a command node can request a response by including signals, which are one or more bits of a message indicating whether acknowledgment of receipt or data should be sent by (or more) responder nodes in response. In response to such a signal, a responder node, at a time specified by the responder node (e.g., after the command node has completed its transmission), will respond via... Figure 2 The diagram illustrates a conventional UART message transmission response. In a conventional asynchronous communication system, the responder node sends a response after the command node has completed transmitting the message. In this case, the conventional responder node acknowledges by sending at least one frame to end the message transmission. To avoid conflicts between transmitting nodes in a conventional asynchronous communication system, the command node and (multiple) responder nodes check if the bus is idle before initiating frame transmission. Once the start of a frame is detected on the bus by a conventional communication node, it can refrain from initiating frame transmission and wait until the bus is idle again.

[0030] As an example of such a response, a legacy responder node may send a response when the responder node determines that the public bus is IDLE and therefore available for data transmission, and / or when a legacy responder node schedules a response (which may be unknown to the legacy command node). In some examples, a legacy command node may be forced to wait until an acknowledgment has been received from the responder node before performing other tasks (such as transmitting other messages). In some examples, a legacy asynchronous protocol command node may use a timeout mechanism to stop waiting for a response from the responder node, for example, to avoid waiting too long for the responder node to send a response. Changing the command node's operations between transmitting, waiting for a response, checking for a timeout, and then starting to transmit the next message can increase the need for computational power. Changing the responder node's operations between receiving a message, waiting for the bus to become idle, sending the requested data and / or receiving an acknowledgment, and then preparing to receive another message can increase the complexity of the circuit. In a particular example, if a response from the responder node is expected between two or more messages sent by the command node, the transmission of a message sequence by the legacy command node may increase the need for computational power.

[0031] In some examples, asynchronous communication can be implemented with many nodes, such as ten, twenty, or even more. In some examples of traditional asynchronous systems, coordinating changes between sending and receiving messages can require significant computational power to efficiently manage data transfer between the data storage location and the UART transmitter and receiver, especially for fast data transfers. In some examples, the required computational power may increase the cost, power usage, and / or complexity of implementing asynchronous communication.

[0032] exist Figure 1A The depicted system 100 is configured to handle message reception and / or data request acknowledgments in a unique manner, enabling asynchronous communication to have reduced complexity, cost, and / or power consumption compared to conventional systems. Figure 1A As shown, the command node 110 is configured to send a message 130 with an associated request frame 150 to (multiple) responder nodes 120A and 120B. The request frame 150 signals to (multiple) responder nodes 120A and 120B that a response 160 should be sent by (multiple) responder nodes 120A and 120B. The response 160 may indicate whether message 130 was received by (multiple) responder nodes 120A and 120B. In some examples, in response to the request frame 150, the request frame 150 may also request data, and the reception of the request frame 150 may also confirm that message 130 was received by (multiple) responder nodes 120A and 120B.

[0033] In some examples, if a request at a predetermined location associated with the position of the frame in message 130 is received by responder nodes(s) 120A, 120B, then request frame 150 may signal to responder nodes(s) 120A, 120B that confirmation of message reception and / or data has been requested.

[0034] For example, request frame 150 can be a frame of a message, and the position of a frame relative to other frames of the message identifies the frame as request frame 150. For example, based on the order of request frames received by responder nodes 120A and 120B, request frame 150 can be identified by responder nodes 120A and 120B as a request frame relative to a data frame. As a non-limiting example, both the command node and the responder node can be programmed to identify the fourth frame of each message, the second frame, the first frame, and / or the last frame of each message as a request frame in each message 130.

[0035] As another example, within a predetermined time after responder nodes 120A and 120B receive the last data frame of the message, i.e., before the master node 110 typically begins sending another message (e.g., another data frame of another message after the completion of message transmission), acknowledgment of message reception and / or data has been requested in an additional frame of data.

[0036] In some examples, the command node 110 may introduce a request frame 150 at a defined location in or after message 130, which instructs the requesting responder nodes(s) 120A, 120B when to send a response 160. For example, the responder nodes(s) 120A, 120B may send the response 160 during the time period defined by the request frame 150. Compared to conventional responder nodes, the responder nodes(s) 120A, 120B can use the Start of Frame (SOF) bit of the received request frame 150 to begin transmitting the response 160, instead of waiting for the bus to be idle. In one embodiment, the command node 110 sends the request frame 150 with recessive data bits followed by a dominant SOF bit. For example, if the responder nodes(s) 120A, 120B detect the start of the frame (e.g., the Start of Frame “SOF” bit) and send the response 160 at the same time that the master node 110 sends the request frame 150. In some examples, the position of the request frame 150 in message 130 is known by the relevant communication node, and multiple responder nodes 120A and 120B send response 160 in response to the start of frame (SOF) bit of the request frame 150, and send response 160 at the same time as the bit (i.e., the recessive bit) of the request frame 150 is output by the master node 110.

[0037] Despite Figure 1ANot described in the text, but in some examples, the response 160 sent by (multiple) responder nodes 120 can be related to... Figure 2 The response frame depicted is similar to the UART data frame described herein and includes an SOF bit, followed by multiple data bits. In some such examples, the response frame includes multiple acknowledgment bits following the SOF bit, acknowledging whether the message was successfully received by the responder nodes 120A and 120B. In other examples, such a response includes data bits, for example, to transmit information such as sensor data or other information requested by the command node 110.

[0038] exist Figure 1A The system 100 described herein offers significant advantages over conventional asynchronous communication systems. For example, system 100 allows responses from responder nodes 120A and 120B to be sent at a time specified by the command node 110 sending message 130. This allows system 100 to be implemented with reduced cost and / or complexity, and / or reduced energy consumption compared to conventional asynchronous communication systems. For instance, in some applications, system 100 can be implemented with less computational power dedicated to message passing scheduling than conventional systems because the transmitter of the command node can remain in transmitting mode and does not need to be shut down and / or idle while receiving data from the responder node. In half-duplex and full-duplex modes, if the command node controls the transmission of response frames through the responder node, the command node can be constructed in a more efficient manner because the total timing and the number of frames transmitted are always controlled by the command node.

[0039] Figure 3 It is a description of the use of some embodiments as in Figure 1A The diagram shows an example of a communication device 301 for the command node 110 in the asynchronous communication system 100 depicted. In some examples, device 301 may be configured to send messages to responder nodes via a common bus 122.

[0040] like Figure 3 As shown, device 301 includes a UART transmitter 311, a UART receiver 313, a data flow control module 316, and a data movement engine 317. (As...) Figure 3 As shown, the data movement engine 317 is coupled to the data memory 318 via the data bus 370, which can store one or more transmitted messages arranged as shown in the image. Figure 2The data frames 240A and 240B depicted herein. Data movement engine 317 may include a direct memory access (DMA) controller or other device configured to copy data from one memory to another. Data flow control module 316 may include any combination of hardware circuitry and / or executable software instructions configured to control data flow and / or message passing associated with device 301.

[0041] UART transmitter 311 is coupled to transmit buffer 312 to store, for example, in Figure 2 The example shows the data bits. Data memory 318 can have a significantly larger storage capacity than transmit buffer 312, which can store bits of one or more UART frames for one or more messages to be transmitted. To transmit a message, data movement engine 317 transfers data bits to transmit buffer 312, and UART transmitter 311 transmits data bits in frames by first outputting an SOF bit, followed by the data bits, and then at least one STOP bit indicating that a frame has been transmitted. When there is space in transmit buffer 312, UART transmitter 311 sends a transmit interrupt signal to data flow control module 316. Based on the transmit interrupt signal, data flow control module 316 can cause data movement engine 317 to transfer additional bits from data memory 318 to transmit buffer 312 for output via common bus 122.

[0042] UART receiver 313 stores data bits received via common bus 122 in receive buffer 314. Data movement engine 317 transfers data bits from receive buffer 314 to data memory 318. Once UART receiver 313 has stored a predetermined number of data bits (i.e., a predetermined number of frames) in receive buffer 314, UART receiver 313 generates a receive interrupt to indicate that the stored data bits can be transferred to data memory 318. As a non-limiting example, when four UART frames comprising 32 data bits are stored in receive buffer 314, UART receiver 313 may send a receive interrupt signal.

[0043] In some examples of conventional UART devices, significant computing power may need to periodically interact with the data flow control module 316 (i.e., via corresponding transmit and receive interrupts) to schedule message transfers between the command node 110 and the responder nodes 120A, 120B. In some examples, device 301 is uniquely configured to signal request frames 150 to the responder nodes(s), which cause the responder nodes(s) 120A, 120B(s) to send responses 160 without requiring significant CPU resources.

[0044] In an example of a conventional asynchronous communication protocol, the command node (e.g., a UART master node), and its conventional data flow control module, transmit a limited number of transmit data words to a Tx buffer, resulting in the transmission of a limited number of UART frames, such as the master node portion of a message. The conventional data flow control module can be forced to wait for a limited number of received UART frames to be received by the UART receiver, for example, indicated by an Rx interrupt, before moving the next transmit data word to the Tx buffer. The received data may represent a response to a message previously sent by the command node. The data of the received frames is moved from the Rx buffer to the data memory via a data movement engine. The number of transmit data words moved to the Tx buffer and the number of UART frames to be received from the responder node to complete message transmission can be determined in the data flow control unit. This can lead to increased area or workload, especially if different sizes (e.g., different numbers of frames) of message sequences (combined command node and responder node messages) must be transmitted.

[0045] Refer again Figure 1A The workload of processing message sequences from master node 110 and / or (multiple) response nodes 120A, 120B to response node 120, or from master node 110 to (multiple) response nodes 120A, 120B, can be significantly reduced. According to Figure 1A For example, command node 110 can send a request frame 150, which triggers an immediate response 160 emitted by responder nodes(s) 120A, 120B. In some examples, the number of additional request frames 150 sent by command node 110 may be equal to the number of frames expected from responder nodes 120A, 120B for that message. In some examples, command node 110 sends as many frames per message as it receives. According to... Figure 1A In the system 100 depicted, the command node 110 may not need to wait to receive a limited number of responder node frames (e.g., as responses) before it can begin sending a new message. In some examples, the message duration is not increased by additional request frames 150. In some examples, the number of additional request frames 150 is equal to the expected number of responses 160 to complete the message. In some examples, a new message can be started immediately after the last frame of a previous message from the command node 110 has been sent.

[0046] Figure 4 is a timing diagram depicting an example of communication between a command node 110 and one or more responder nodes 120 according to some embodiments. In the example of Figure 4, the command node 110 is operable to send message 430 to the responder node(s) 120 and request a response from the responder node 120, the response acknowledging that message 430 has been received and / or including the data requested by the command node 110.

[0047] according to Figure 4A For example, message 430 includes multiple N frames 440A-440C, each frame including information about... Figure 2 As described above, multiple data bits. In some examples, message 430 includes more than one frame. For example, message 430 may include 2, 4, 6, 8, 10, 12, or even more frames. Each frame in frames 440A-440C may include the same number of data bits. As a non-limiting example, each frame in N frames may include 8 data bits, i.e., one byte of data. In other examples, N frames may include more or fewer data bits. For example, N frames may include 9 bits. N frames 440A-440C can serve as... Figure 2 The UART frames 240A and 240B depicted in the text are transmitted.

[0048] In order to transmit message 430 to responder node 120, command node 110 sends each data frame: first frame 1 440A, then frame 2 440B, then other frames not depicted in Figure 4, and so on, until the last (Nth) frame 440C is sent, completing the transmission of message 730.

[0049] according to Figure 4A For example, the command node 110 is configured to request acknowledgment from the responder node 120 by sending a frame of message 440B of message 430 as a request frame 450, indicating whether message 430 or a frame of message 430 (including one or more of a plurality of N frames) was received centrally or individually by the responder node 120.

[0050] exist Figure 4A In the example, the command node 110 sends a request frame 450 at a defined position relative to the other frames 440A and 440C depicted in message 430, such as at the second frame position in message 430. Although Figure 4 shows a request frame at the middle or second position of message 430, other frames of message 430 can be used as request frame 450, including the first frame 440A of message 430, the last frame 440C of message 430, or if message 430 includes more than the first frame 440A of message 430. Figure 4B The additional frames depicted in the example are any frames between the first frame 440A and the last frame 440C.

[0051] According to the example in Figure 4, responder node 120 is configured to identify whether command node 110 requests acknowledgment of message 430 based on the receipt of a request frame 450 at a defined position associated with other frames in N frames of message 430. For example, responder node 120 may identify whether a request frame 450 at a defined position associated with other frames (e.g., at the second frame position of a message comprising 6 frames) has been received. In some examples, responder nodes are programmed to identify the request frame 450 at the same position associated with other frames for each message received by command node 110.

[0052] In some examples, the command node 110 is configured to send multiple frames 440A-440C of message 430 as request frames 450, each frame being configured to request that one or more previous frames of an acknowledgment message be received and / or request data from responder nodes(s) 120. For example, the command node 110 may be configured to send request frames 450 every M frames of a message. As a non-limiting example, for a message with 15 frames, the command node 110 may send request frames 450 every five frames of the message.

[0053] Commander node 110 can send a sequence of request frames 450 to control the start of each responder node frame via individual request frames. Multiple responder nodes 120 can initiate the transmission of a position-specific response 460 within message 230; for example, a first request frame of message 230 can trigger the transmission of a response frame from first responder node 120A, and a second request frame of message 230 can trigger the transmission of a response 450 from second responder node 120B. In another example, the first request frame 450 of message 230 can trigger the transmission of a first response from responder node 120A, and the second request frame of message 230 can trigger the transmission of a second response from responder node 120B. In yet another example, request frame 450 can trigger the transmission of responses 460 from several responder nodes. In this case, a dominant data level of one responder node can override a recessive data level of another responder node in a response 460 received by commander node 110.

[0054] In some examples, responder node 120 is configured to send response 160 as in Figure 4A The example shows response frame 460. According to this example, response frame 460 includes a data frame, like in... Figure 2 The examples depict UART frames 240A and 240B. In some examples, responder node 120 sends a response frame 460 within a time period 458 defined by request frame 450. For example, as... Figure 4AAs shown, while the command node 110 is sending a request frame 450 (which is at the same time that the command node 110 is sending a message 430), the responder node 120 can send a response frame 460.

[0055] Figure 4B This is a timing diagram depicting an example of communication between a command node 110 and one or more responder nodes 120 according to some embodiments. Figure 4B In the example, the command node 110 is operable to send message 730 to the responder node 120 and request from the responder node 120 an acknowledgment that message 730 has been received and / or a response including the data requested by the command node 110.

[0056] according to Figure 4B For example, message 430 includes multiple N frames 740A-740C, each frame including information about... Figure 2 As described above, multiple data bits. In some examples, message 730 includes more than one frame. For example, the message may include 2, 4, 6, 8, 10, 12, or even more frames. Each frame in frames 740A-740C may include the same number of data bits. As a non-limiting example, each frame in N frames may include 8 data bits, i.e., one byte of data. In other examples, N frames may include more or fewer data bits. For example, N frames may include 9 bits. N frames 740A-740C can serve as... Figure 2 The UART frames 240A and 240B depicted in the text are transmitted.

[0057] To transmit message 730 to responder node 120, command node 110 sends each data frame: first frame 1 740A, then frame 2 740B, and then... Figure 4B Other frames not depicted in the text, etc., until the last (Nth) frame 740C is sent, completing the transmission of message 430.

[0058] according to Figure 4B For example, the command node 110 is configured to request an acknowledgment from the responder node 120, the acknowledgment indicating whether a message 430 comprising multiple N frames has been received by the responder node 120 and / or whether it has been sent via a method similar to... Figure 2 The data frames 240A and 240B of message 730 depicted in the text are used as request frames 450 to request data.

[0059] exist Figure 4BIn the example, the command node 110 sends a request frame 750 at a defined position associated with N frames 740A-740C of message 730, for example, after frame N of message 730 (e.g., at the STOP bit of the last (Nth) frame 440C of message 730). Figure 4B (not shown in the image) after (e.g., as shown in the image). Figure 4B As shown, the command node 110 can send a request frame 750 within a predetermined time 780 after the end 732 of the command portion of message 730 (e.g., sent at...). Figure 2 The SOF bits of UART 240A and 240B are shown. In some examples, the predetermined time 780 is less than the time that the command node 110 typically pauses between messages (between the last frame of the sent message and the first frame of the next message).

[0060] according to Figure 4B For example, responder node 120 is configured to identify whether command node 110 has requested acknowledgment of message 730 based on whether a request frame 750 at a defined position associated with N frames of received message 730 has been received. For instance, responder node 120 may identify whether request frame 750 (e.g., the SOF bit of request frame 750) was received within a predetermined time 780 after the end 732 of message 730. In some examples, if no other frame (e.g., no SOF bit) is received within the predetermined time 780, responder node 120 does not identify a request to acknowledge receipt of message 730 and does not send any response.

[0061] In some examples, when responder node 120 identifies the request frame 750 described above, responder node 120 sends a response as in Figure 4B The example shows response frame 760. According to this example, response frame 760 includes a data frame, like in... Figure 2 The examples depict UART frames 240A and 240B. In some examples, responder node 120 sends a response frame 760 within a time period 758 defined by the request frame 750. For example, as... Figure 4B As shown, while the command node 110 is sending a request frame 750, the responder node 120 can send a response frame 760.

[0062] Figure 5 This is a timing diagram depicting an example of a request frame 550 sent from a command node 110 to a responder node 120 according to some embodiments, and a response frame 560 generated by the responder node 120 in response to the request frame 550. In some examples, the request frame 560 is used as... Figure 4A In the example shown, message frame 730 is sent. In other examples, request frame 560 is sent. Figure 4B The frames 440A-440C of message 430 shown in the example are then sent.

[0063] according to Figure 5 For example, to request a response from responder node 120, command node 110 sends a request frame 550 at a predefined location. In some examples, the request frame contains data bits not intended to be interpreted by the responder node. These bits are transmitted by the command node to avoid stopping transmission and are held within the timing sequence of its frame transmission. One solution for such bits is to transmit them at an implicit level, as they are negated by any dominant level transmitted by the responder node. In these examples, the dominant SOF bits transmitted by the command node are the only bits in the request frame considered by the responder node. Like in... Figure 2 The message 230 depicted in the image includes multiple frames 240A, 240B, and a request frame 550 that includes a dominant level followed by a predetermined number of data bits (in...). Figure 5 The SOF bit in the example (8 bits) is 552. Figure 5 In the example, a predetermined number of data bits 554 are IDLE (recessive) data bits. In other examples, not all data bits are IDLE (recessive). For example, at least some of the predetermined number of data bits 554 are dominant bits.

[0064] For example Figure 5 As shown, (multiple) responder nodes 120 can send responses at the time specified by the request frame 550. Figure 5 As depicted, the response frame 560 includes a dominant SOF bit, followed by a plurality of acknowledgment bits 566 configured to acknowledge to the command node 110 whether a message or frame has been received by the command node 110 from the responder node 120. Figure 5 In one example, acknowledgment bit 566 includes three of the eight data bits in acknowledgment response frame 560. In other examples, response frame 560 includes more or fewer acknowledgment bits 566 arranged in the same or different positions in response frame 550. Figure 5 As shown, response frame 560 may include an IDLE (recessive) bit 564 following acknowledgment bit 566. In some examples, the first responder node may be configured to send a dominant level at the first bit position after receiving the SOF of the request frame, while the second responder node is configured to send a dominant level at the second bit position of the same request frame.

[0065] In other examples, response frame 560 may not be included. Figure 5The acknowledgment bit 566 is shown. For example, the command node 110 may send a request frame 550 indicating that data should be sent in response to a previous request for data, such as in a previous message or frame. According to this example, one or more bits of the response frame 560 may include data bits with dominant or recessive values ​​to represent the data requested by the command node 110.

[0066] exist Figure 5 In the example, (multiple) responder nodes 120 send response frames 560 during a time period 558 defined by request frame 550. For example, as Figure 5 As shown, while at least some bits of the IDLE bit 554 of the request frame 550 are being sent by the command node 110 to the responder node 120, the responder node(s) 120 sends the acknowledgment bit 566 of the response frame 560. In some examples, the acknowledgment bit 566 is a dominant data bit that overrides the IDLE bit of the request frame 550. In other examples, the acknowledgment bit is a recessive bit that remains recessive on the common bus 122. Still in other examples, the response frame 560 does not include an acknowledgment bit and instead includes dominant and / or recessive data bits indicating data requested by the command node 110.

[0067] In some examples, system 100 can be configured to send response frame 560 in different ways. For example, system 100 can be configured such that responder node(s) 120 actively signal a positive acknowledgment each time message 530 is successfully received by responder node 120. According to these examples, command node 110 is configured to mark the successful transmission of message 530 if a response frame 560 including an explicit acknowledgment bit 566 (or data bits) covering the IDLE bit 554 of the request frame 550 is received on public bus 122 during time period 558. According to these examples, command node 110 is configured to mark the message transmission as a failure and retransmit message 530 if the response frame 560 is not received during time period 558, or if the response frame 560 includes a implicit acknowledgment bit 566 that does not cover the IDLE bit of the acknowledgment request frame 550 during time period 558.

[0068] In other examples, system 100 is configured such that responder nodes(s) 120 proactively signal a negative acknowledgment each time message 530 is not correctly received by responder node 120, i.e., when a transmission failure or data corruption of message 530 has been detected. According to these examples, if a response frame 560, including an explicit acknowledgment bit 566 (or data bits) covering the IDLE bit of request frame 550, is received during time period 558, then command node 110 identifies a transmission failure. According to these examples, command node 110 is configured to identify a successful message transmission if a response frame 560, including a implicit acknowledgment bit 566 not covering the IDLE bit of request frame 550, is received during time period 558, or if the response frame 560 is not received during time period 558.

[0069] Regardless of how system 100 is configured, command node 110 can take measures to mitigate identified transmission failures. For example, if a transmission failure is identified, command node 110 can resend message 530 to responder node(s) 120.

[0070] Figure 6 This is a flowchart illustrating an example of a method for operating an asynchronous communication node according to some embodiments. For example... Figure 6 As shown, in step 601, the method includes receiving one or more data frames 440A-440C of message 230. Data frames 440A-440C may include a start-of-frame (SOF) bit 542, followed by a predetermined number of data bits 544, which may be dominant or recessive bits.

[0071] like Figure 6 As shown, in step 602, the method further includes: receiving a request frame 450 at a defined position associated with data frames 440A-440C of message 430. In some examples, the method further includes: receiving the request frame 450 within a predetermined time 480 after receiving the last data frame of message 430. In other examples, the method further includes: receiving the request frame 450 within a predetermined time 480 after receiving the last data frame of message 430.

[0072] like Figure 6As shown, in step 603, the method further includes sending a response 160 in response to request frame 150. Response 160 may acknowledge whether a message or frame has been received, and / or may include data. In some examples, the method further includes sending response 160 during a time period defined by request frame 150. In some examples, the method further includes sending response 160 simultaneously with receiving request frame 150 (i.e., simultaneously with master node 110 sending request frame 150). In some examples, the method further includes sending a response in response to detecting SOF bit 552 of request frame 150. In some examples, the response is response frame 460, which includes acknowledgment bit 566 followed by multiple IDLE bits 564. In some examples, the multiple acknowledgment bits 566 are dominant bits that override the IDLE (recessive) bits 554 of request frame 450. In other examples, the multiple acknowledgment bits 566 are recessive bits that do not override the IDLE bit 554 of request frame 550. In some other examples, response frame 460 does not include acknowledgment bit 566, and instead includes explicit and implicit data bits indicating data requested by the command node 100. In some examples, the response indicates whether a message or a message frame has been received. In some examples, the response includes the requested data.

[0073] In some examples, the data frames 440A-440C of message 430, request frame 450, and response frame 460 are Universal Asynchronous Receiver / Transmitter (UART) frames, which include, for example, a Start of Frame (SOF) bit followed by a predetermined number of data bits.

[0074] Terms and Conditions

[0075] Clause 1. A method comprising: receiving one or more data frames of a message; receiving a request frame at a defined location associated with the one or more data frames of the message; and sending a response in response to the request frame.

[0076] Clause 2. The method according to Clause 1 further includes: receiving request frames as frames of a message in a predetermined order within the message.

[0077] Clause 3. The method according to any one of Clauses 1 and 2 further includes: receiving a request frame within a predetermined time period after the last data frame of the received message.

[0078] Clause 4. The method according to any one of Clauses 1-3 further includes: sending a response at the same time as receiving the request frame.

[0079] Clause 5. The method according to any one of Clauses 1-4 further includes: sending a response during a time period defined by the request frame.

[0080] Clause 6. The method according to any one of Clauses 1-5 further includes: sending a response in response to the SOF bit of the request frame.

[0081] Clause 7. The method according to any one of Clauses 1-6, wherein sending a response comprises: sending a response frame.

[0082] Clause 8. The method according to Clause 7, wherein the response frame includes a start-of-frame bit followed by a plurality of acknowledgment bits.

[0083] Clause 9. The method described in Clause 8, wherein multiple acknowledgment bits are dominant bits.

[0084] Clause 10. The method described in Clause 8, wherein a plurality of acknowledgment bits are recessive bits.

[0085] Clause 11. The method according to any one of Clauses 1-10, wherein the response indicates whether a message or a frame of a message has been received.

[0086] Clause 12. The method according to any one of Clauses 1-11, wherein the response includes the requested data.

[0087] Clause 13. A communication node configured to: receive one or more frames of a message; receive a request frame at a defined location associated with one or more data frames of the message; and send a response in response to the request frame.

[0088] Clause 14. The communication node as described in Clause 13, wherein the communication node is further configured to receive request frames as frames of a message in a predetermined order within the message.

[0089] Clause 15. A communication node according to any one of Clauses 13 and 14, wherein the communication node is further configured to receive a request frame within a predetermined time after the last data frame of the received message.

[0090] Clause 16. A communication node according to any one of Clauses 13-15, wherein the communication node is further configured to send a response while receiving a request frame.

[0091] Clause 17. A communication node according to any one of Clauses 13-16, wherein the communication node is further configured to send a response during a time period defined by the request frame.

[0092] Clause 18. A communication node according to any one of Clauses 13-17, wherein the communication node is further configured to send a response in response to the SOF bit of a request frame.

[0093] Clause 19. A communication node according to any one of Clauses 13-18, wherein the communication node is further configured to: send a response as a response frame.

[0094] Clause 20. A communication node as described in Clause 19, wherein a response frame includes a start-of-frame bit followed by a plurality of acknowledgment bits.

[0095] Clause 21. A communication node as described in Clause 20, wherein a plurality of acknowledgment bits are dominant bits.

[0096] Clause 22. A communication node as described in Clause 20, wherein a plurality of acknowledgment bits are recessive bits.

[0097] Clause 23. A communication node pursuant to any one of Clauses 13-22, wherein a response indicates whether a message or a frame of a message has been received.

[0098] Clause 24. A communication node pursuant to any one of Clauses 13-23, wherein the response includes the requested data.

[0099] Clause 25. A communication system comprising: a command node; at least one responder node communicatively coupled to the command node, wherein the responder node is configured to: receive one or more frames of a message from the command node; receive a request frame from the command node at a defined location associated with the one or more frames of the message; and send a response to the command node in response to the request frame.

[0100] Clause 26. The system according to Clause 25, wherein the responder node is further configured to send a response during a time period defined by the request frame.

[0101] Clause 27. The system according to any one of Clauses 25 and 26, wherein the responder node is further configured to send a response in response to the SOF bit of the request frame.

[0102] Clause 28. The system according to any one of Clauses 25-27, wherein the responder node is further configured to send a response while receiving a request frame.

[0103] Although the invention has been described with reference to illustrative embodiments, this description is not intended to be construed as limiting. Various modifications and combinations of the illustrative embodiments, as well as other embodiments of the invention, will be apparent to those skilled in the art based on the description. Therefore, the appended claims are intended to cover any such modifications or embodiments.

Claims

1. A method comprising: receiving one or more data frames of a message; receiving a request frame at a defined location relative to the one or more data frames of the message; and sending a response in response to the request frame.

2. The method of claim 1, further comprising: receiving the request frame as a frame of the message in a predetermined order within the message.

3. The method of claim 1, further comprising: receiving the request frame within a predetermined time after receiving a last data frame of the message.

4. The method of claim 1, further comprising: sending the response concurrently with receiving the request frame.

5. The method of claim 1, further comprising: sending the response during a time period defined by the request frame.

6. The method of claim 1, further comprising: sending the response in response to a SOF bit of the request frame.

7. A method comprising:

7. The method of claim 1, wherein sending the response comprises: sending a request frame at a defined location relative to one or more frames of a message; and receiving a response in response to the request frame.

8. The method of claim 7, wherein the response frame comprises a start of frame bit followed by a plurality of acknowledgement bits.

9. The method of claim 8, wherein the plurality of acknowledgement bits are explicit bits.

10. The method of claim 8, wherein the plurality of acknowledgement bits are implicit bits.

11. The method of claim 1, wherein the response indicates whether the message or the frames of the message were received.

12. The method of claim 1, wherein the response comprises requested data.

13. A communication node configured to: receive one or more frames of a message; receive a request frame at a defined location relative to the one or more frames of the message; and send a response in response to the request frame.

14. The communication node of claim 13, wherein the communication node is further configured to: receive the request frame as a frame of the message in a predetermined order within the message.

15. The communication node of claim 13, wherein the communication node is further configured to: receive the request frame within a predetermined time after receiving a last data frame of the message.

16. The communication node of claim 13, wherein the communication node is further configured to: send the response concurrently with receiving the request frame.

17. The communication node of claim 13, wherein the communication node is further configured to: send the response during a time period defined by the request frame.

18. The communication node of claim 13, wherein the communication node is further configured to: send the response in response to a SOF bit of the request frame.

19. The communication node of claim 13, wherein the communication node is further configured to: send the response as a response frame.

20. The communication node of claim 19, wherein the response frame comprises a start of frame bit followed by a plurality of acknowledgement bits.

21. The communication node of claim 20, wherein the plurality of acknowledgement bits are explicit bits.

22. The communication node of claim 20, wherein the plurality of acknowledgement bits are implicit bits.

23. The communication node of claim 13, wherein the response indicates whether the message or the frame of the message was received.

24. The communication node of claim 13, wherein the response comprises requested data.

25. A communication system comprising: a commander node; and at least one responder node communicatively coupled to the commander node, wherein the responder node is configured to: receive one or more frames of a message from the commander node; receive a request frame from the commander node at a defined location related to the one or more frames of the message; and send a response to the commander node in response to the request frame.

26. The system of claim 25, wherein the responder node is further configured to: send the response during a time period defined by the request frame.

27. The system of claim 25, wherein the responder node is further configured to: send the response in response to a SOF bit of the request frame.

28. The system of claim 25, wherein the responder node is further configured to: send the response at the same time as the request frame is received. ​

Images