WO2020068093A1

WO2020068093A1 - Master/slave communication protocol

Info

Publication number: WO2020068093A1
Application number: PCT/US2018/053275
Authority: WO
Inventors: Nicola Baldo; David SORIANO FOSAS; Thieu X. Dang
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2018-09-28
Filing date: 2018-09-28
Publication date: 2020-04-02
Anticipated expiration: 2021-03-28

Abstract

A communication system comprises a master node, slave nodes, and a master/slave communication protocol. The master node and the slave nodes are coupled to each other in a 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. According to the master/slave protocol, 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, and the master node defers 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.

Description

MASTER/SLAVE COMMUNICATION PROTOCOL

BACKGROUND

[0001]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.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Examples will now be described, by way of non-limiting examples, with reference to the accompanying drawings, in which:

[0003] Fig. 1 is a block diagram of a communication system according to an example;

[0004] Fig. 2 is a more detailed block diagram of a communication system according to an example;

[0005] Fig. 3 is a schematic diagram showing master node and a slave mode according to an example;

[0006] Fig. 4A and 4B show examples of message formats for a read request and a response to the read request; [0007] Fig. 5A and 5B show examples of message formats for a write request and a response to the write request;

[0008] Figs. 6 is a time diagram showing access timings of a communication protocol according to an example; and

[0009] 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.

DETAILED DESCRIPTION

[00010] Generally, 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. 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. In examples, devices for implementing the protocol may be realized using price competitive embedded microcontrollers, and hence may provide a very cost-effective solution.

[00011] Examples of the present disclosure provide a communication system in which such a master/slave communication protocol, MSCP, is implemented. 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. Generally, as indicated by the interruption and the dots in Fig. 1 , 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.

[00012] In examples, 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. Thus, examples permit a communication between the master node and the slave modes in a simple manner while conflicts on the response line may be prevented.

[00013] The term 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. Thus, 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. In the daisy chain configuration, each node transmits data to the next node in the chain if appropriate. For example, 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. [00014] 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. In other implementations, 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.

[00015] The terms master and slave are used herein to indicate that the master node is allowed to initiate communication and to transmit requests via the request line, while the slave nodes are not allowed to transmit responses via the response line without having received an associated request from the master. [00016] 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. 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.

[00017] 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. In the example shown, in each of slave nodes 14a, 14b, 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. In other examples, such a functionality may be implemented differently. In the example shown, 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.

[00018] In the above example, 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.

[00019] In examples, 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 . In examples, the OR gates 32 may be omitted.

[00020] As indicated in Fig. 2, 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.

[00021] In operation, 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. In examples, 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.

[00022] In examples, the master/slave communication protocol, MSCP, may be described using a layer structure as shown in Fig. 3. It may comprise a physical layer specification 40, based on top of a universal asynchronous receiver transmitter, UART, baseline 42. Thus, examples may enjoy hardware peripheral availability across a broadest set of microcontrollers possible, especially including the cost effective ones. Thus, in examples, 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.

[00023] In examples, 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. In examples, this specification focuses on two types of request-response frame exchanges. In examples, the MSCP supports two request types, read requests and write requests, resulting in corresponding read and write operations at the addressed slave node. Thus, in examples, 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. In addition, 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. [00024] On the master side, the protocol layer stack architecture may further comprise a general-purpose input/output, GPIO. In addition, 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.

[00025] In examples, 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. In examples, 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. Generally, 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. In examples, 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. In examples, the master/slave communication protocol may be implemented in the form of several application- specific MSCP device realizations.

[00026] In examples, 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. 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. On each slave device, the MOSI line may be connected to the UART RX input and the MISO line to the UART TX output.

[00027] 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. [00028] In examples, 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. In examples, 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. In examples, 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. In examples, the first and fourth frame lengths are the same and the second and forth frame lengths are the same. In examples, for read register transactions, the frame length of the request is 3 bytes and the frame length of the response is 7 bytes. In examples, for write register transactions, the frame length of request is 7 bytes and the length of the response is 3 bytes. In examples, the frame lengths may be adjusted as described above in order to maximize protocol throughput while maintaining protocol simplicity.

[00029] In examples, 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. In examples, the request protocol header may include the device identity, ID, of the slave node addressed by the request. In addition, the request protocol header may include a register address for the requested transaction. In examples, 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. In addition, the request includes a request type indicator to indicate the type of the request. In examples, 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. In examples, 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.

[00030] In examples, 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. In addition, the header may include a status field containing status information on the slave device transmitting the response. In case of a response to a read request, 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. In examples, 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

[00031] Examples of a request and a response in case of a read transaction are shown in Figures 4A and 4B and examples of a request and a response in case of a write transaction are shown in Figures 5A and 5B. The respective headers have a length of two bytes. As shown, frame bits may separate device ID and address fields in the protocol headers of the requests, and frame bits may separate device ID and status fields in the protocol headers of the responses. As shown in Figures 4A and 4B, 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. If 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. In the responses, an attention bit ATTN may be inserted preceding the checksum. According to Fig. 4A, the overall length of a read request plus the break character may be four characters. According to Fig. 4B, the overall length of a response to the read request plus the break character may be eight characters. According to Fig. 5A, the overall length of a write request plus the break character may be eight characters. According to Fig. 5B, the overall length of a response to the write request plus the break character may be four characters. Each character may include 1 byte.

[00032] The MSCP control registers may include control data used in implementing the MSCP. In examples, the slave nodes comprise sensor nodes and actuator nodes. In such examples, 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. By sending appropriate read register requests and write register requests, 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.

[00033] In examples, the MSCP disclosed herein is designed for providing low latency communications. In examples, 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. In examples, 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. [00034] In examples, 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. In examples, the master node determines the timing of a response sent by a slave node in response to a request. To be more specific, the protocol described herein prescribes that a response type and size are univocally associated with each request type. Thus, when 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.

[00035] In examples, 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.

[00036] 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. To this end, 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. Thus, 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.

[00037] 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„ⁿ . 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. In the example shown, the response 102 starts at a time t ^£art and ends at a time The response 102 has a fixed length 5s_,i. Thus, 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.

[00038] As described above, 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. Thus, 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. Thus, even if 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. Thus, 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.

[00039] Using the notations of Fig. 6, the overlap of transmissions by different slave nodes on the response line may be avoided when the following two inequalities hold:

[00040] Thus, in examples, 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.

[00041] 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. In such examples, the slave nodes are formed by sensors and actuators and the master node is formed by a controller, such as a printer controller. Using the MSCP described herein, the controller may receive sensor data from slave nodes representing sensors, and may send control data to slave nodes representing actuators, Thus the controller, such as the printer controller, may interface with all these devices in order to control processes, such as printing processes, appropriately.

[00042] 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. [00043] Examples of the present disclosure relate to a communication system implementing the MSCP described herein. According to a first aspect, 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.

[00044] According to a second aspect, in the communication system of the first aspect 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.

[00045] According to a third aspect, in the communication system of the first or second aspect, 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. [00046] According to a fourth aspect, in the communication system of the third aspect, the first and fourth frame lengths are the same and the second and third frame lengths are the same.

[00047] According to a fifth aspect, in the communication system of the fourth aspect, the first and fourth frame lengths are larger than the second and third frame lengths.

[00048] According to a sixth aspect, in the communication system of the first to fifth aspects, 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.

[00049] According to a seventh aspect, in the communication system of one of the first to sixth aspects, 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.

[00050] According to an eight aspect, in the communication system of one of the first to seventh aspects, the slave nodes comprise at least one of sensor nodes and actuator nodes.

[00051] According to a ninth aspect, 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.

[00052] Examples of the present disclosure relate to a master node for a communication system. According to a tenth aspect, 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. According to an eleventh aspect, 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

[00053] Examples of the present disclosure relate to a slave node for a communication system. According to a twelfth aspect, 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.

[00054] Examples of the present disclosure relate to a method using the MSCP described herein. 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. At 200, the master node transmits a present request of a fixed frame length via the request line. At 202, 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. At 204, 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. In examples, 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. In examples, 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.

[00055] 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.

[00056] 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.

[00057] All of the features disclosed in the specification including any accompanying claims, abstract and drawings, and/or all the features of any method or progress described may be combined in any combination including any claim combination, except combinations where at least some of such features are mutually exclusive. In addition, features disclosed in connection with a system may, at the same time, present features of a corresponding method, and vice versa.

[00058] Each feature disclosed in the specification including any accompanying claims, abstract and drawings may be replaced by other features serving the same, equivalent or a similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example of a generic series of equivalent or similar features.

[00059] The foregoing has described the principles, examples and modes of operation. However, the teachings herein are not be construed as being limited to the particular examples described. The above-described examples are to be regarded as illustrative rather than restrictive, and it is to be appreciated that variations may be made in those examples by workers skilled in the art without departing from the scope of the following claims.

Claims

Claims What is claimed is:

1. A communication system comprising:

a master node,

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, a master/slave communication protocol 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.

2. The communication system of claim 1 , wherein 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.

3. The communication system of claim 1 , wherein 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.

4. The communication system of claim 3, wherein the first and fourth frame lengths are the same and the second and third frame lengths are the same.

5. The communication system of claim 4, wherein the first and fourth frame lengths are larger than the second and third frame lengths.

6. The communication system of claim 1 , wherein the request includes a checksum and wherein 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.

7. The communication system of claim 1 , wherein 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.

8. The communication system of claim 1 , wherein the slave nodes comprise at least one of sensor nodes and actuator nodes.

9. A printer comprising a communication system of claim 8, wherein the master node comprises a central controller of the printer and the slave nodes comprise sensors and actuators of the printer.

10. A master node for a communication system implementing a master/slave communication protocol, the master node 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 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.

1 1. The master node of claim 10, wherein 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

12. A slave node for a communication system implementing a

master/slave communication protocol, the slave node 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 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.

13. A method of communicating between a master node and slave nodes in a communication system, 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 method comprising:

transmitting, by the master node, a present request of a fixed frame length via the request line;

starting, by a slave node addressed in the present request, 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;

deferring, by the master node, 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.

14. The method of claim 13, wherein start of transmission of the next request relative to the start of the present request is deferred 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.

15. The method of claim 13, comprising 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.