WO2020068093A1 - Protocole de communication maître/esclave - Google Patents

Protocole de communication maître/esclave Download PDF

Info

Publication number
WO2020068093A1
WO2020068093A1 PCT/US2018/053275 US2018053275W WO2020068093A1 WO 2020068093 A1 WO2020068093 A1 WO 2020068093A1 US 2018053275 W US2018053275 W US 2018053275W WO 2020068093 A1 WO2020068093 A1 WO 2020068093A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
response
slave
master node
line
Prior art date
Application number
PCT/US2018/053275
Other languages
English (en)
Inventor
Nicola Baldo
David SORIANO FOSAS
Thieu X. Dang
Original Assignee
Hewlett-Packard Development Company, L.P.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett-Packard Development Company, L.P. filed Critical Hewlett-Packard Development Company, L.P.
Priority to PCT/US2018/053275 priority Critical patent/WO2020068093A1/fr
Publication of WO2020068093A1 publication Critical patent/WO2020068093A1/fr

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/42Loop networks
    • H04L12/423Loop networks with centralised control, e.g. polling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/403Bus networks with centralised control, e.g. polling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/4026Bus for use in automation systems

Definitions

  • Appliances such as 3D printers and large format printers, may include large numbers of sensors and actuators of many different kinds, such as temperature, pressure, humidity and presence sensors, encoders, motor drivers, fans, heaters, etc.
  • a controller such as a print engine, is to interface with all these devices in order to control processes, such as printing processes, appropriately.
  • FIG. 1 is a block diagram of a communication system according to an example
  • FIG. 2 is a more detailed block diagram of a communication system according to an example
  • Fig. 3 is a schematic diagram showing master node and a slave mode according to an example
  • Fig. 4A and 4B show examples of message formats for a read request and a response to the read request
  • Fig. 5A and 5B show examples of message formats for a write request and a response to the write request
  • Figs. 6 is a time diagram showing access timings of a communication protocol according to an example.
  • Fig. 7 is a flow chart of an example of a method of communicating between a master node and a slave node according to an example.
  • examples of the present disclosure relate to a master/slave communication protocol for realizing a low-cost network of slave devices, such as sensor/actuator devices, to be connected to a master device, such as a central engine in a 3D/large format printer.
  • a master device such as a central engine in a 3D/large format printer.
  • Other examples may be directed to other products in which communication between a number of slave devices and one master device is desired.
  • Examples of the present disclosure provide a low- latency, high bandwidth connectivity in such system and may scale up to very large numbers of devices.
  • devices for implementing the protocol may be realized using price competitive embedded microcontrollers, and hence may provide a very cost-effective solution.
  • Fig. 1 shows a schematic view of a communication system 10 comprising a master node 12 and slave nodes 14a, 14b, and 14c.
  • the master node 12 and the slave nodes 14a, 14b, 14c are coupled to each other in a daisy chain configuration.
  • the daisy chain configuration includes a request line 16 to transmit requests from the master node 12 to the slave nodes 14a, 14b, and 14c, and a response line 18 to transmit responses from the slave nodes 14a, 14b, and 14c to the master node.
  • the communication system 10 may comprise a different number of slave devices, such as a larger number or a lower number when compared to the three slave devices shown in Fig. 1.
  • the MSCP prompts the master node 12 to transmit a current request of a fixed frame length via the request line 16.
  • the MSCP prompts a slave node addressed in the current request to start transmission of a response of a fixed frame length via the response line within a predetermined time window from the end of the present request.
  • the MSCP prompts the master node to defer a start of transmission of a next request via the request line such that an end of the next request is after the end of the response.
  • daisy chain configuration is meant to define a configuration, in which a first slave node, i.e. slave node 14a, is coupled to the master node 12 via the request line 16 and the response line 18, and in which each subsequent slave node is coupled to the respective preceding slave node via the request line 16 and the response line 18.
  • the slave nodes are serially coupled to each other to form a chain.
  • the request line 16 may be regarded as being formed by all request line portions coupling the master node and the slave nodes of the daisy chain configuration to each other and the response line 18 may be regarded as being formed by all response line portions coupling the master node and the slave nodes of the daisy chain configuration to each other.
  • each node transmits data to the next node in the chain if appropriate.
  • master node 12 sends a request in which node 14b is addressed via request line 16 to node 14a, and node 14a forwards the request to node 14b since node 14a is not addressed in the request.
  • a response from node 14b to the master node 12 will then be sent from node 14b to node 14a and forwarded to master node 12 by node 14a.
  • Request line 16 and response line 18 represent unidirectional data lines, wherein the respective direction of data communication is indicated by arrows in Fig. 1.
  • Each of the master node and the slave nodes may be implemented in hardware using discrete modules and/or data processing components that are not limited to any particular hardware and machine-readable instruction configuration.
  • the nodes may be implemented using analogue and/or digital hardware components, such as application specific integrated circuits, field programmable gate arrays, digital signal processors, microprocessors and microcontrollers.
  • the nodes may be implemented in any computing or data processing environment including hardware components, such as processors and memory devices, and machine-readable instructions.
  • the machine- readable instructions may be stored in any appropriate memory and may be executed by the processor in order to achieve the functionalities and processes described herein. In some implementations, the functionalities are combined into a single data processing component.
  • the respective functionalities may be performed by a respective set of multiple data processing components.
  • the memory devices may store process instructions, machine-readable instructions, for providing the functionality and implementing the methods described herein.
  • the memory devices may include tangible machine-readable storage media.
  • Memory devices suitable for embodying these instructions and data include all forms of computer-readable memory, including, for example, semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices, magnetic disks such as internal hard disks and removable hard disks, magneto-optical disks, and ROM/RAM devices. Accordingly, in examples, the nodes may be implemented in hardware or in a combination of hardware and machine readable instructions to implement the communication protocol described herein.
  • Fig. 2 shows a more detailed schematic view of a communication system, wherein a master node 12 and two slave nodes 14a and 14b are shown. Again, a different number of slave nodes may be provided as indicated at 20 in Fig. 3.
  • the master node may comprise a master printed circuit assembly, PCA, 22 and a master integrated circuit, IC, 24.
  • a transmitting output TX of the master IC is coupled to a request line MOSI, Master Out Slave In, which represents an example of a request line 16.
  • a receiving input RX of the master node is coupled to a response line MISO, Master In Slave Out, which represents an example of a response line.
  • MISO Master In Slave Out
  • the direction of data transmission over the MOSI line and the MISO line are indicated in Fig. 2 by respective arrows.
  • Master node 12 may further include a transmission driver 26 and a receiving driver 28.
  • Each slave node may include a slave IC 30.
  • a receiving input RX of each slave node 14a, 14b is coupled to the request line MOSI and a transmission input TX of each slave node 14a, 14b is coupled to the response line MISO.
  • the request line MOSI is further coupled to a first input of an OR gate 32 and a disable output of each slave node 14a, 14b is coupled to the second input of the OR gate 32.
  • the output of the OR gate 32 is coupled to the MOSI line connecting the corresponding slave node to the next slave node. This allows the slave node to disable the request line MOSI to not forward the request to the next slave node using some previous request or condition.
  • the transmission output RX of slave IC 30 is coupled to a first input of an AND gate 34 and the MISO line coming from a preceding slave node is coupled to the second input of the AND gate 34 and the output of the AND gate 34 is coupled to the MISO line connecting the respective slave node to the next slave node.
  • idle levels of the MOSI line and the MISO line are low and OR gate 32 and AND gate 34 are used. In other examples, idle levels of the MOSI line and the MISO line may be high. In such examples, OR gate 32 may be replaced by an AND gate and AND gate 34 may be replaced by an OR gate.
  • a slave node N may raise or lower the disableNext signal after successful reception of a write register request addressed to the device N with a certain register address and value. Depending on the value of the disableNext signal subsequent transmissions by the master will be propagated by device N to device N+1 or will be blocked by device N, and, therefore, not propagated to device N+1 .
  • the OR gates 32 may be omitted.
  • a configuration line CONFIG may be provided between the master node 12 and the first slave node 14a and between respective adjacent slave nodes.
  • the configuration line may be used to communicate between the master node 12 and the slave nodes 14a, 14b control information useful to implement the communication protocol described herein.
  • the master node 12 will send requests via line MOSI, each request addressed to a specific one of the slave nodes.
  • Each slave node may have associated therewith a specific device identity, ID, and, therefore, may be addressed via a device ID in the request.
  • the addressed slave node will not forward the request to the next slave node in the chain but will transmit a response to the master node via line MISO. Transmission of requests and responses will take place according to the MSCP described herein.
  • each of the master node and the slave nodes comprises a UART interface, wherein a transmit output of the UART interface of the master node is coupled to the request line, a receive input of the UART interface of the master node is coupled to the receive line, transmit outputs of the slave nodes are coupled to the receive line, and receive inputs of the slave nodes are coupled to the transmit line.
  • the MSCP further comprises a medium access control, MAC, layer specification based on a master-slave paradigm, MAC/LC layer 44 in Fig. 3, wherein LC stands for link control.
  • this specification focuses on two types of request-response frame exchanges.
  • the MSCP supports two request types, read requests and write requests, resulting in corresponding read and write operations at the addressed slave node.
  • sensor and actuator use cases may be supported efficiently, while at the same time the design of the protocol may be kept simple and well-suited for hardware acceleration on the master side.
  • the medium access control specification aims at providing low latency while ensuring collision-free operation when multiple devices are sharing the same physical bus.
  • an MSCP Application Protocol Layer 46 may provide support for a device control protocol specification that defines procedures for device identification, initialization and remote upgrade. Such support may take place via a configuration line config and corresponding interfaces in the master node 12 and the slave node 14.
  • the MSCP may further provide support for application protocols aimed at supporting application-specific sensors and actuators, whose interaction with the central engine is in examples of the present disclosure the purpose of the MSCP protocol.
  • Corresponding application layers 48 are shown in Fig. 3. On the master side, application layer 48 comprises a MSCP master control application and master specific-purpose applications, and on the slave side, application layer 48 comprises a MSCP slave control application and slave specific-purpose applications.
  • the protocol layer stack architecture may further comprise a general-purpose input/output, GPIO.
  • the protocol layer stack architecture may further comprise a UART bootloader on the slave side and a UART bootloader client on the master side, such as a STM32 ® UART bootloader and a STM32 ® bootloader client.
  • the master/slave communication protocol may be implemented in the form of a set of machine readable instructions components for the master to communicate with the slave devices.
  • the master node may be a central engine of a printer and the slave nodes may provide access to sensors and actuators of the printer.
  • the master node may be a controller of an appliance and the slave nodes may be components of the appliance that provide information and/or components of the appliance that are controlled by the controller.
  • the master/slave communication protocol may be implemented in the form of a device machine readable instructions library to develop application-specific MSCP devices to be tailored to the features of different products.
  • the master/slave communication protocol may be implemented in the form of several application- specific MSCP device realizations.
  • the data communication path for implementing the MSCP comprises two physical lines, the MOSI line representing a request line, and the MISO line representing a response line.
  • the MOSI line On the master or host side, the MOSI line may be connected to an UART TX output and the MISO line may be connected to the UART RX input.
  • the MOSI line On each slave device, the MOSI line may be connected to the UART RX input and the MISO line to the UART TX output.
  • Interactions according to the MSCP are of the type master/slave, with the master sending a request on the MOSI line to a specific slave device and the intended slave device sending the response on the MISO line to the master.
  • just two transactions types are defined by the protocol, a read register request/response and a write register request/response.
  • the size, i.e. frame length or length, of each message is fixed and asymmetric between the request and the response.
  • the protocol prescribes that the requests are either a write register request having a fixed first frame length or a read register request having a fixed second frame length, and that a response to a write register request is a write register response having a third fixed frame length and that a response to a read register request is a read register response having a fourth fixed frame length.
  • the first frame length is larger than the second and third frame lengths and the fourth frame length is larger than the second and third frame lengths.
  • the first and fourth frame lengths are the same and the second and forth frame lengths are the same.
  • the frame length of the request is 3 bytes and the frame length of the response is 7 bytes.
  • the frame length of request is 7 bytes and the length of the response is 3 bytes.
  • the frame lengths may be adjusted as described above in order to maximize protocol throughput while maintaining protocol simplicity.
  • the MSCP prescribes that request messages, which are also simply called requests, have a specific format.
  • the requests transmitted according to the MSCP contain a request protocol header.
  • the request protocol header contains a field defining the intended receiver device, i.e. slave node.
  • the request protocol header may include the device identity, ID, of the slave node addressed by the request.
  • the request protocol header may include a register address for the requested transaction.
  • different address ranges may be defined for MSCP control registers and for application registers, and the request may include a register type indicator to indicate whether a MSCP control register or an application register is to be accessed.
  • the request includes a request type indicator to indicate the type of the request.
  • the requested transaction is a read transaction or a write transaction. In examples, no other transaction types are possible.
  • the register type indicator and/or the request type indicator may be included in the request header.
  • the requests may further include data fields. In examples, a request does not include data fields if the request is a read request and a request includes data fields, such as data fields of a length of four bytes, if the request is a write request.
  • the requests may further include a checksum, such as a checksum of 8 bits length. In examples, each request is followed by a break character, which may be a formed by a number of consecutive bits of the same value, such as a number of consecutive zero bits.
  • the MSCP prescribes that response messages, which are also simply called responses, have a specific format.
  • the responses include a response protocol header.
  • the response protocol header contains a field indicating the device ID of the slave device transmitting the response.
  • the header may include a status field containing status information on the slave device transmitting the response.
  • the response includes data fields, such as data fields of a length of 4 bytes.
  • the responses may include a checksum, such as a checksum of 8 bits length.
  • each response is followed by a break character, which may be formed by a number of consecutive bits of the same value, such as a number of consecutive zero bits.
  • the responses may include frame bits separating further information
  • a request type indicator comprises a bit RnW. If RnW has a first value, such as one, the request is a read request and if RnW has a different second value, such as zero, the request is a write request.
  • a register type indicator comprises a bit UnR.
  • UnR has a first value, such as one, the MSCP control register is to be accessed and if UnR has a different second value, such as zero, the application register is to be accessed.
  • the requests and responses comprise a checksum CRC, cyclic redundancy check, at the end thereof.
  • Each message is followed by a break character BREAK.
  • an attention bit ATTN may be inserted preceding the checksum.
  • the overall length of a read request plus the break character may be four characters.
  • Fig. 4B the overall length of a response to the read request plus the break character may be eight characters.
  • Fig. 5A the overall length of a write request plus the break character may be eight characters.
  • the overall length of a response to the write request plus the break character may be four characters.
  • Each character may include 1 byte.
  • the MSCP control registers may include control data used in implementing the MSCP.
  • the slave nodes comprise sensor nodes and actuator nodes.
  • each type of slave node i.e. receiver device, is expected to support a well-defined set of application registers, mapped to the sensors and actuators that are supported by the particular device type.
  • the master node such as a print engine, may retrieve sensor data and apply control actions on actuators by communicating with the slave nodes via the master/slave communication protocol described herein.
  • the MSCP disclosed herein is designed for providing low latency communications.
  • the allowed latencies may be as small as from tens to a few hundreds of microseconds and are enforceable on a per slave device basis.
  • the MSCP may be implemented with high speeds, such as up to 6Mbps or up to 9 Mbps, wherein Mbps stands for megabit per second. Higher protocol speeds are possible depending on cable length and signal integrity, wherein cable shielding and proper impedance construction may help increasing the maximum protocol speed.
  • the timing of requests/responses is accurately controlled in order to maximize the system throughput while at the same time avoiding collisions on the response line.
  • the master node determines the timing of a response sent by a slave node in response to a request.
  • the protocol described herein prescribes that a response type and size are univocally associated with each request type.
  • the master node sends a request to a slave node, the associated response type and size, and hence duration, are univocally determined by the request type.
  • the corresponding associations between request types, response types and sizes may be stored at each node, such as in respective MSCP control registers.
  • a slave node is allowed to transmit a response on the response line if it is able to decode the request correctly.
  • a slave node is the addressed slave node if the device ID in the request corresponds to the device ID of the slave node.
  • the addressed slave node then verifies the checksum and starts transmission of the response if the checksum is verified successfully.
  • the slave node does not start transmission of the response if the checksum is not verified successfully. No other device beside the slave node addressed in the request is allowed to transmit a response.
  • the MSCP described herein prescribes that the transmission of a response on the response line has to be finished after a fixed duration counting from the end of the request on the request line, which resulted in the response.
  • the slave node is to start transmission of the response to the current request within a predetermined time window from the end of the current request.
  • the fixed duration after which the response has to be finished is determined to allow enough time to transmit the response of the fixed length determined by the request type plus an adequate margin to account for worst case signal propagation and processing time tolerances at the slave node side.
  • the master node may expect receiving the response within a specific time window.
  • the master node will defer start of a next transmission on the request line for a time that is sufficient for the end of the next transmission to occur after the end of the response to the current request. Thus, collision of responses on the response line may be prevented.
  • FIG. 6 shows a time diagram of transmissions on the request line MOSI and the response line MISO according to an example.
  • a current request 100 starts a time t r£ and ends at a time t structuri n .
  • the current request 100 has a fixed length dM , ⁇ .
  • a response 102 to the current request 100 starts within a predetermined time window t from the end of the current request 100.
  • the response 102 starts at a time t £art and ends at a time
  • the response 102 has a fixed length 5s ,i .
  • the latest possible end of the response is given by the time window t plus the length 5s ,i .
  • a next request 104 starts at a time ends at a time and has a fixed length 5M, I +I.
  • a response 106 to the next request 104 starts within the time window t from the end of the next request at a time ends at a time and has a fixed length 5 s,>+i .
  • each request and each response has a fixed length depending on the transaction type, i.e. depending on the type of the request or the type of the response.
  • the master node is in a position to schedule transmission of the requests on the request lines such that the end of a next request is after the end of the response of a current request.
  • transmission of a response to the next request is started immediately after the end of the next request, it is ensured that the transmission of the response to the current request has already been finished when transmission of the response to the next request starts.
  • the possibility that two transmissions by different slave nodes overlap on the response line MISO and, therefore, collisions on the response line MISO may be prevented using the MSCP disclosed herein.
  • the master node starts transmission of a next request relative to the start of a current request upon expiration of a time that is equal to or larger than the length of the present request plus a predetermined time window plus the length of the response minus the length of the next request.
  • Examples of the present disclosure relate to appliances, such as printers, 3D printers and large format printers, which include large numbers of sensors and actuators of many different kinds, such as temperature, pressure, humidity and presence sensors, encoders, motor drivers, fans, heaters, etc.
  • the slave nodes are formed by sensors and actuators and the master node is formed by a controller, such as a printer controller.
  • the controller may receive sensor data from slave nodes representing sensors, and may send control data to slave nodes representing actuators,
  • the controller such as the printer controller, may interface with all these devices in order to control processes, such as printing processes, appropriately.
  • Examples of the present disclosure permit a low latency communication between a master node and a plurality of slave nodes.
  • Examples of the present disclosure provide a communication protocol permitting a high throughput.
  • Examples provide the communication protocol to be implemented using cost effective hardware components.
  • Examples permit the communication system to be scaled up to a large number of slave devices, such as hundreds of devices per printer. Examples permit keeping fast control loops within controllers of appliances, such as print engines of printers, while maintaining an architecture with slave nodes, such as sensors and actuators, scattered over the whole appliance.
  • Examples of the present disclosure relate to a communication system implementing the MSCP described herein.
  • a communication system comprises a master node and slave nodes, wherein the master node and the slave nodes are coupled to each other in a daisy chain configuration, the daisy chain configuration including a request line to transmit requests from the master node to the slave nodes, and a response line to transmit responses from the slave nodes to the master node.
  • the communication system comprises a master/slave communication protocol or is to implement a master/slave communication system to prompt: the master node to transmit a present request of a fixed frame length via the request line; a slave node addressed in the present request to start transmission of a response of a fixed frame length via the response line within a predetermined time window from the end of the present request; and the master node to defer a start of transmission of a next request via the request line such that an end of the next request is after the end of the response.
  • the master node is to defer the start of transmission of the next request relative to the start of the present request by a time that is equal to or larger than the length of the present request plus the predetermined time window plus the length of the response minus the length of the next request.
  • the protocol prescribes that the requests are either a write register request having a fixed first frame length or a read register request having a fixed second frame length, and that a response to a write register request is a write register response having a third fixed frame length and that a response to a read register request is a read register response having a fourth fixed frame length.
  • the first and fourth frame lengths are the same and the second and third frame lengths are the same.
  • the first and fourth frame lengths are larger than the second and third frame lengths.
  • the request includes a checksum and the slave addressed in the request is to verify the checksum, to start transmission of the response if the checksum is verified successfully and not to start transmission of the response if the checksum is not verified successfully.
  • the request line is connected to a universal asynchronous receiver transmitter, UART, transmission output at the master node and to a UART receiving input at each slave node, and wherein the response line is connected to a UART receiving input at the master node and to a UART transmission output at each slave node.
  • the slave nodes comprise at least one of sensor nodes and actuator nodes.
  • a printer comprises a communication system according to one of the first to eighth aspects, wherein the master node comprises a central controller of the printer and the slave nodes comprise sensors and actuators of the printer.
  • Examples of the present disclosure relate to a master node for a communication system.
  • a master node for a communication system implementing a master/slave communication protocol is provided.
  • the master node is to be coupled to slave nodes in a daisy chain configuration, the daisy chain configuration including a request line and a response line, the master/slave protocol prompting a slave node to start transmitting a response to a request from the master node within a predetermined time window from the end of the request.
  • the master node is to: transmit a present request of a fixed frame length via the request line; receive a response of a fixed frame length via the response line from a slave node addressed in the present request; and defer a start of transmission of a next request via the request line such that an end of the next request is after the end of the response.
  • the master node of the tenth aspect is to defer the start of transmission of the next request relative to the start of the present request by a time that is equal to or larger than the length of the present request plus the predetermined time window plus the length of the response minus the length of the next request
  • Examples of the present disclosure relate to a slave node for a communication system.
  • a slave node for a communication system implementing a master/slave communication protocol is provided.
  • the slave node is to be coupled to a master node and other slave nodes in a daisy chain configuration, the daisy chain configuration including a request line and a response line, the master/slave protocol prompting a slave node to start transmitting a response to a request within a predetermined time window from the end of the request.
  • the slave node is to: receive a request of a fixed frame length and addressing the slave node via the request line from the master node; verify a checksum in the request; start transmission of a response to the master node via the response line if the checksum is verified successfully; and not to start transmission of a response to the master node via the response line if the checksum is not verified successfully.
  • Fig. 7 shows a flow chart of an example of a method according to the present disclosure.
  • the method concerns communication between a master node and slave nodes in a communication system .
  • the master node and the slave nodes are coupled to each other in a daisy chain configuration, the daisy chain configuration including a request line to transmit requests from the master node to the slave nodes and a response line to transmit responses from the slave nodes to the master node.
  • the master node transmits a present request of a fixed frame length via the request line.
  • a slave node addressed in the present request starts transmission of a response of a fixed frame length via the response line within a predetermined time window from the end of the present request.
  • the master node defers start of transmission of a next request via the request line such that an end of the next request is after the end of the response. In other words, the master node is prompted to start transmission of the next request after expiration of a time period sufficient for the response to the present request to be finished before transmission of the next request ends.
  • the method comprises deferring the start of transmission of the next request relative to the start of the present request by a time that is equal to or larger than the length of the present request plus the predetermined time window plus the length of the response minus the length of the next request.
  • the method comprises transmitting, by the master node, write register requests to slave nodes representing actuator nodes, and transmitting, by the master node, read register requests to slave nodes representing sensor nodes.
  • Examples relate to a non-transitory machine-readable storage medium encoded with instructions executable by a processing resource of a computing device to perform methods described herein.
  • Examples described herein may be realized in the form of hardware, machine-readable instructions or a combination of hardware and machine- readable instructions. Any such machine-readable instructions may be stored in the form of volatile or non-volatile storage such as, for example, a storage device, such as a ROM, whether erasable or rewritable or not, or in the form of memory, such as, for example, RAM, memory chips, device or integrated circuits or an optically or magnetically readable medium, such as, for example, a CD, DVD, magnetic disk or magnetic tape.
  • the storage devices and storage media are examples of machine-readable storage, that are suitable for storing a program or programs that, when executed, implement examples described herein.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)

Abstract

Un système de communication comprend un nœud maître, des nœuds esclaves et un protocole de communication maître/esclave. Le nœud maître et les nœuds esclaves sont couplés l'un à l'autre dans une configuration en chaîne comprenant une ligne de requête pour transmettre des requêtes du nœud maître aux nœuds esclaves, et une ligne de réponse pour transmettre des réponses des nœuds esclaves au nœud maître. Selon le protocole maître/esclave, le nœud maître transmet une demande actuelle d'une longueur de trame fixe par l'intermédiaire de la ligne de demande, un nœud esclave adressé dans la présente demande commence la transmission d'une réponse d'une longueur de trame fixe par l'intermédiaire de la ligne de réponse à l'intérieur d'une fenêtre temporelle prédéterminée à partir de la fin de la présente demande, et le nœud maître déduit un début de transmission d'une requête suivante par l'intermédiaire de la ligne de requête de telle sorte qu'une fin de la requête suivante soit après la fin de la réponse.
PCT/US2018/053275 2018-09-28 2018-09-28 Protocole de communication maître/esclave WO2020068093A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2018/053275 WO2020068093A1 (fr) 2018-09-28 2018-09-28 Protocole de communication maître/esclave

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2018/053275 WO2020068093A1 (fr) 2018-09-28 2018-09-28 Protocole de communication maître/esclave

Publications (1)

Publication Number Publication Date
WO2020068093A1 true WO2020068093A1 (fr) 2020-04-02

Family

ID=69950115

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2018/053275 WO2020068093A1 (fr) 2018-09-28 2018-09-28 Protocole de communication maître/esclave

Country Status (1)

Country Link
WO (1) WO2020068093A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116208289A (zh) * 2023-04-28 2023-06-02 北京邮电大学 基于白盒交换机的时间同步方法、装置及电子设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1443708A2 (fr) * 2001-05-30 2004-08-04 Lg Electronics Inc. Système de commande de réseau pour appareils domestiques
US20060104396A1 (en) * 2004-10-21 2006-05-18 Hewlett-Packard Development Company, L.P. Serial bus system
US20080013473A1 (en) * 2006-05-19 2008-01-17 Widefi, Inc. Wireless repeater with master/slave configuration
US20100169526A1 (en) * 2008-12-30 2010-07-01 Kim Chan-Woo Slave and communicating method between a master and the same

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1443708A2 (fr) * 2001-05-30 2004-08-04 Lg Electronics Inc. Système de commande de réseau pour appareils domestiques
US20060104396A1 (en) * 2004-10-21 2006-05-18 Hewlett-Packard Development Company, L.P. Serial bus system
US20080013473A1 (en) * 2006-05-19 2008-01-17 Widefi, Inc. Wireless repeater with master/slave configuration
US20100169526A1 (en) * 2008-12-30 2010-07-01 Kim Chan-Woo Slave and communicating method between a master and the same

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116208289A (zh) * 2023-04-28 2023-06-02 北京邮电大学 基于白盒交换机的时间同步方法、装置及电子设备
CN116208289B (zh) * 2023-04-28 2023-07-21 北京邮电大学 基于白盒交换机的时间同步方法、装置及电子设备

Similar Documents

Publication Publication Date Title
JP5723062B2 (ja) メモリの大きさに対して調整される直列データ伝送のための方法及び装置
CN107835040B (zh) 一种基于蓝牙的数据通讯的方法、设备及存储介质
US20070239900A1 (en) Universal serial bus (USB) extension
US8595400B2 (en) Programmable controller using master-slave communication
CN105512081B (zh) 用于以可转换的数据速率进行串行数据传输的方法和装置
US5696911A (en) Arrangement for eliminating malfunction and/or permitting high-speed transmission in a serial bus connection, and transmitter and receiver units linked to the latter
CN110312233A (zh) 控制器局域网(can)装置和用于操作can装置的方法
TWI582609B (zh) 用於在遠端節點和本地節點之間執行遠端記憶體存取(rma)資料傳輸的方法和設備
US20090286489A1 (en) Wireless Communications Between Wired Devices with Adaptive Data Rates
US10230656B2 (en) Method and apparatus for controlling message over heterogeneous network
US11546187B2 (en) Large packet daisy chain serial bus
WO2005046146A1 (fr) Procede, systeme et programme pour l'etablissement d'un paquet
WO2020068093A1 (fr) Protocole de communication maître/esclave
CN111752881A (zh) 一种模块间通信方法及系统
US11715337B2 (en) Controller diagnostic device and method thereof
JP7210867B2 (ja) 確認パケット伝送方法および通信デバイス
WO2020068095A1 (fr) Communication maître/esclave
CN114003544A (zh) 一种控制芯片、工作量证明系统和传输方法
US11876640B2 (en) User station for a serial bus system, and method for transferring data with manipulation protection in a serial bus system
WO1992013414A1 (fr) Systeme de transmission de paquets et procede utilisant a la fois un bus de donnees et des lignes de commande specialisees
CN114946160B (zh) 用于在自动化系统的参与者之间的数据通信的方法
US20020013805A1 (en) LogNet: a low cost, high reliability network for embedded systems
JP3922326B2 (ja) 非同期データ通信方法
CN114928377B (zh) 降低usb数据透传带宽的输出传输方法、装置及设备
US8291143B1 (en) Single line communication

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: 18935118

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: 18935118

Country of ref document: EP

Kind code of ref document: A1