WO2020068095A1 - Communication maître/esclave - Google Patents

Communication maître/esclave Download PDF

Info

Publication number
WO2020068095A1
WO2020068095A1 PCT/US2018/053287 US2018053287W WO2020068095A1 WO 2020068095 A1 WO2020068095 A1 WO 2020068095A1 US 2018053287 W US2018053287 W US 2018053287W WO 2020068095 A1 WO2020068095 A1 WO 2020068095A1
Authority
WO
WIPO (PCT)
Prior art keywords
frame
request
response
incoming
node
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/US2018/053287
Other languages
English (en)
Inventor
Thieu X. Dang
David SORIANO FOSAS
Nicola Baldo
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Development Co LP
Original Assignee
Hewlett Packard Development Co LP
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 Co LP filed Critical Hewlett Packard Development Co LP
Priority to PCT/US2018/053287 priority Critical patent/WO2020068095A1/fr
Publication of WO2020068095A1 publication Critical patent/WO2020068095A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/42—Loop networks
    • H04L12/423—Loop networks with centralised control, e.g. polling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/403—Bus networks with centralised control, e.g. polling

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 a break character according to an example
  • FIG. 7 is a schematic view of an example of a node interface
  • FIG. 8 is a flow chart of an example of a method of communicating in a communication system
  • Fig. 9 is a flow chart of an example of features of a master/slave communication at a slave node side.
  • Fig. 10 is a flow chart of an example of features of a master/slave communication at a master node side.
  • examples of the present disclosure relate to master/slave communication and aspects of master/slave communication between a master node and slave nodes in a communication system using a master/slave communication protocol, MSCP.
  • Examples relate to a communication system designed for networks of sensors and actuators that is robust to communication errors and machine readable instruction errors.
  • the communication system is targeted at large networks of low cost devices provided with limited computational resources.
  • the error resilience and robustness characteristics of the communication system are designed to maintain a good trade-off with the communication efficiency of the master/slave communication protocol used.
  • examples of the present disclosure may 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.
  • Examples of the present disclosure are designed for a complex appliance or product, such as a 3D printer, which is composed of a variety of sensor and actuator devices which are controlled by a central engine.
  • a complex appliance or product such as a 3D printer
  • the interaction between the central engine and the sensors and actuators has to be successful and timely, so that the engine may perform its internal routines using up-to-date sensorial input and perform the intended actuation with the proper timing.
  • causes of errors may possibly hinder the interaction of the central engine, the master node, with sensor and actuator devices, the slave nodes.
  • Such causes may be communication errors due to noise and interference, malfunctions of the slave nodes, e.g., due to a machine readable instruction error, or due to unexpected latencies in the device readable instructions.
  • a further cause may be a malfunction of the central engine, e.g., a hang in the central engine when executing machine readably instructions.
  • an error resilient communication system that may satisfactorily address such causes of error, and that may be implemented on low cost devices with limited computational capabilities, but also supporting high communication bandwidth.
  • an electrical communication interface using universal asynchronous serial communication, UART is used to implement the MSCP.
  • the MSCP provides a resilient and efficient communication protocol that may work on top of a UART electrical interface and tackle the aforementioned types of errors.
  • Examples of the present disclosure may be implemented using a master/slave communication protocol, MSCP.
  • a host, master node communicates with the devices, slave nodes, with read requests and write requests to specific registers, which provide the interface for the master node to interact with the slave nodes, which may comprise sensors and actuators.
  • the MSCP may be transported over a full duplex UART physical interface.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 1C 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 using 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 fixed third frame length and that a response to a read register request is a read register response having a fixed fourth 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 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.
  • 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 may prescribe 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.
  • collision of responses on the response line may be prevented.
  • Examples of the present disclosure may be implemented using the MSCP protocol described and may comprise some or all features thereof. Examples of the present disclosure are directed to features making a master/slave communication error resilient.
  • Examples of the present disclosure provide a communication system comprising 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 request frames from the master node to the slave nodes and a response line to transmit response frames from the slave nodes to the master node.
  • Each node comprises a hardware interface to receive an incoming frame, wherein the hardware interface detects an end of the incoming frame using a break character.
  • Each node checks whether the incoming frame has a correct frame length, to further process the incoming frame if the incoming frame has the correct frame length, and not to further process the incoming frame if the incoming frame does not have the correct frame length.
  • Examples of the present disclosure provide a slave node for a communication system comprising a master node and slave nodes coupled to each other in a daisy chain configuration, the daisy chain configuration including a request line to transmit request frames from the master node to the slave nodes and a response line to transmit response frames from the slave nodes to the master node.
  • the slave node comprises a hardware interface to receive an incoming request frame, wherein the hardware interface detects an end of the incoming frame using a break character.
  • the slave node checks whether the incoming request frame has a correct frame length, further processes the incoming frame if the incoming frame has the correct frame length, and does not further process the incoming frame if the request frame does not have the correct frame length.
  • Examples of the present disclosure provide a master node for a communication system comprising the master node and a plurality of slave nodes coupled to each other in a daisy chain configuration, the daisy chain configuration including a request line to transmit request frames from the master node to the slave nodes and a response line to transmit response frames from the slave nodes to the master node.
  • the master node comprises a hardware interface to receive an incoming response frame.
  • the hardware interface detects an end of the incoming frame using a break character.
  • the master node checks whether an incoming response frame has a correct frame length, further processes the incoming response frame if the incoming response frame has the correct frame length, and does not further process the incoming response frame if the response frame does not have the correct frame length.
  • the correct frame length is the fixed frame length associated with a respective response or request.
  • the correct frame length may include frame lengths of both, a write request and a read request, while, at the master side, the correct frame length may include a single frame length, namely the frame length of the response type associated with the sent request.
  • Examples of the present disclosure use frames having a fixed frame length and further processing of a frame depends on whether an incoming frame has the correct fixed frame length or not. If the frame dos not have the correct frame length it is assumed that there is a form error and, therefore, the frame is not further processed. Thus, superfluous processing and the workload associated therewith may be avoided.
  • the frame length may be determined in an easy manner using the break character.
  • the break character may be formed by a number of at least ten bits having the same level different from an idle level of the request line and the response line so that it may be detected easily. In examples, if the idle level is high, the break character has a number of at least ten low bits.
  • further processing an incoming frame includes validating a checksum of the frame and any processing following the validation, such as sending the frame to a link layer for further processing.
  • working load associated with validating the checksum and with any further processing may be avoided if the incoming frame does not have the correct frame length.
  • further processing the incoming frame by a slave node comprises sending a response to the master node if the incoming frame is addressed to that slave node, and forwarding the incoming frame to the next stage of the daisy chain if the incoming frame is not addressed to that slave node.
  • This further processing is not performed if an incoming frame has the wrong frame length.
  • superfluous working load may be avoided in an addressed slave node and in all slave nodes in the daisy chain downstream of a slave node detecting a wrong frame length.
  • each request type and each response type has an associated frame length.
  • detection whether an incoming frame has been received properly may be done in an easy manner by detecting whether the incoming frame has the correct frame length.
  • the request types are a read request and a write request and the response types are a read response and a write response.
  • the frame length of a write request is larger than the frame length of a read request, and the frame length of a read response is larger than the frame length of a write response.
  • a read request may have a first fixed frame length, such as three bytes
  • a write request may have a second fixed frame length, such as 7 bytes
  • a read response may have a third fixed frame length, such as 7 bytes
  • a write response may have a fourth fixed frame length, such as 3 bytes.
  • the frame lengths may be adjusted according to the type of the frame so that the requests and responses may be kept as short as possible.
  • the hardware interface is to transfer the incoming frame to a memory using direct memory access, DMA. This permits the incoming frame to be received in a fail-safe manner.
  • the master node is to retransmit a request frame once or N times and wherein the master node is to increase a count in a header of this request frame every time the request frame is retransmitted.
  • the master node is to retransmit the request frame upon expiration of a timeout since transmitting the request frame without receiving a response on the response line, and/or if the incoming frame does not have the fixed frame length, and/or if a checksum in the incoming frame is not validated successfully.
  • recovery from errors may be achieved in case an incoming frame is not received properly by the master node or one of the slave nodes. If an incoming frame is not received by an addressed slave node properly, the slave node will not transmit a response in time and this will be recognized by the master node which is then retransmitting the frame.
  • each slave node comprises a hardware timer and the slave node addressed in a request transmits a response within a predetermined time window using the hardware timer.
  • transmitting the response in time if the request frame is received properly may be ensured.
  • Examples of the present disclosure provide an appliance, such as a printer, 3D printer or larger format printer, comprising a communication system of the present disclosure, wherein the master node comprises a central controller of the appliance and the slave nodes comprise sensors and actuators of the appliance.
  • the sensors and actuators may be of many different kinds, such as temperature, pressure, humidity and presence sensors, encoders, motor drivers, fans, and heaters.
  • the slave nodes are formed by sensors and actuators and the master node is formed by a controller, such as a printer controller.
  • the protocol such as the MSCP described herein, specifies that each frame transmission is terminated by a break character.
  • the break character comprises a predetermined bit sequence detectable by the node receiving the frame.
  • the break character is a sequence of at least 10 low bits.
  • Fig. 6 shows a schematic view of an end of a frame, i.e., two last characters 100 of a frame, followed by a break character 102.
  • Each character comprises a start bit, eight information bits, and a stop bit.
  • the break character 102 comprises at least 10 low bits, i.e., zero bits. Since the idle level of UART is high, the break character is the most robust signal that may be sent over UART because of its low-frequency nature. Additionally, the break character may automatically be detected by UART hardware peripherals and may cause a restart in the UART physical layer synchronization, i.e., the process of looking for the start bit of a new frame.
  • the detection of the end of the frame may be robust as it is using a robust symbol.
  • the detection of the end of the frame may be hardware driven, leveraging the functionality of UART HW peripherals, and thus not exposed to logical or timing errors in non-hardware driven approaches.
  • direct memory access, DMA may be easily employed for the frame reception process without non-hardware driven reception which due to its stringent timing requirements is error prone.
  • FIG. 7 shows a schematic view of components of the master node 12 and the slave nodes 14, which are involved in break character detection and direct memory access.
  • Each node comprises a hardware interface 1 10.
  • Hardware interface 1 10 comprises a receiving input RX, a break character detection circuit 1 12 and a reception buffer 1 14.
  • the reception buffer is coupled to a memory 1 18 of a microcontroller 116 for DMA.
  • An input of break character detection circuit 1 12 is coupled to input RX and an output of break character detection circuit 1 12 is coupled to microcontroller 1 16.
  • the communication protocol such as the MSCP described above, may be implemented using microcontroller 1 16.
  • Hardware interface 1 10 may be implemented by a UART hardware peripheral and reception buffer 1 18 may be a one- byte reception buffer of the UART hardware peripheral.
  • the break character detection circuit 1 12 is a hardware circuit and triggers a hardware signal at its output when detecting a break character to notify microcontroller 1 16 when a break character is seen on a line coupled to input RX.
  • One possible implementation to realize this trigger is to implement the output of the break character detection circuit 1 12 as a binary output. Circuit 1 12 switches the binary output to a high level whenever the input thereof stays low for at least ten consecutive low bits and switches the output back to a low level when the input thereof switches to a high level.
  • each frame is terminated with a break character the system may be implemented with low computational complexity on microcontroller 1 16 that has hardware support for break character detection and for reception of data, such as UART data, via DMA.
  • DMA may be used to continuously transfer data from reception buffer 1 14 to memory 1 18 of microcontroller 1 14 implementing the communication protocol.
  • DMA is normally running to receive incoming frame data.
  • the hardware break character detection signal at the output of break character detection circuit 1 12 interrupts microcontroller 1 16 which in turn stops the DMA transfer and runs machine readable instructions that process the received frame.
  • the frame length of the received message may be derived from the DMA byte count when stopping the DMA transfer.
  • microcontroller 1 14 is relieved from interacting with the hardware interface, such as the UART peripheral, until all the content of the incoming frame is available in the microcontroller memory 1 18. Additionally, the microcontroller 1 16 may process data from its memory very quickly, thereby allowing fast response times.
  • all communications take place in the form of a request/response transaction, where the master node sends the request and the slave node provides the response.
  • the protocol may keep things simple by having a fixed frame size for the requests and the response. In examples, two combinations of frame sizes are allowed, break character not included:
  • READ TRANSFER the request is 3- byte long and the response is 7- byte long
  • WRITE TRANSFER the request is 7- byte long and the response is 3- byte long.
  • examples allow for a robust reception process on both the slave node side and the master node side since both accept as a valid frame one that matches a valid frame length and do not further process others. This permits many cases of bad frame reception due to electrical or hardware issues to be filtered out.
  • the frame contains a checksum field to validate the integrity of the data.
  • the checksum field may be a CRC, cyclic redundancy check, field.
  • a one-byte CRC-8 value may be included as the last byte in the frame, right before the break character.
  • CRC-8 allows to detect up to two non-consecutive data bit errors or up to seven consecutive data bit errors in a frame.
  • CRC-8 may be efficiently implemented using machine readable instructions doing a lookup operation and a bitwise XOR operation per each byte in the frame.
  • use of an 8-bit length checksum may limit the per-frame checksum overhead. Thus, using such a checksum is efficient for a communication protocol which uses short but frequent messages and which is focused on low-end microcontrollers with reduced computational capabilities.
  • Examples of the present disclosure further permit communication error recovery.
  • the master node may detect that a communication error occurred in a transaction by the lack of a successfully received response. The master node may thus perform a retransmission of the unacknowledged request. In doing so, care is to be taken at the slave node side to detect and discard possible duplicate transmission requests, which may occur when the request is successfully received at the slave node side but the response is not successfully received at the master node side.
  • the master node includes in the header of the request a retransmission counter that increments with each retransmission. The slave node may therefore store a copy of the last successfully received request frame, and discard any new request that is identical to the previous and has a larger retransmission count.
  • the master node may proactively send N repetitions of the same request message to the slave nodes.
  • the slave node may discard duplicate requests using the previously mentioned mechanism.
  • This repetition scheme may be effective in having a predictable bandwidth requirement and latency, which may make it more suitable when it comes to network dimensioning.
  • the master node implementation is stateless, and hence may be efficiently implemented on hardware such as FPGAs.
  • the MSCP prescribes a specified response time to be respected by each slave node.
  • the response time is defined as the time duration between the end of the break character corresponding to a request frame as seen by a slave node on the request line and the beginning of the response frame transmission by the same slave node on the response line.
  • compliance with the specified response time may be realized in the slave node as follows. Whenever a request frame is correctly received by its intended slave node, the slave node in question starts a hardware timer set to the value of the response time. Then the slave node proceeds to perform the operations related to the received request. When completed, it generates the response frame and sets a flag identifying the response frame as ready for transmission. When the response timer elapses, a routine is invoked which checks the response frame ready flag. If the flag is set, the response is transmitted and the transaction is considered as ended successfully from the slave node side. On the other hand, if due to an error in machine readable instructions or due to unexpected computational latency the response flag is not set by the time the timer elapses, the response is not set, and a timeout error is registered on the slave node side.
  • the communication protocol may provide control of the watchdog on the slave nodes. While the master node appeases the watchdog, the slave node is assured of connectivity with the master node.
  • Control of the watchdog service on the slave node may comprise two registers, a watchdog enable register and a watchdog timeout register.
  • the watchdog timeout register is used to query and set the timeout value of the watchdog on the slave node.
  • the watchdog enable register is used to enable, disable, and appease the watchdog.
  • Examples of the present disclosure provide a method of communicating in a communication system as described herein.
  • Fig. 8 shows a flowchart of such a method.
  • an incoming frame is received and an end of the incoming frame is detected by the hardware interface using a break character.
  • the node checks whether the incoming frame has a fixed frame length. If the incoming frame has the fixed frame length, the frame is further processed and if the incoming frame does not have the fixed frame length, the incoming frame is not further processed, 204.
  • Examples of the present disclosure provide a communication system as described including a master node and slave nodes. Examples of the present disclosure provide a master node to be used in such a communication system and examples of the present disclosure provide a slave node to be used in such a communication system. Examples of functionalities of a slave node are now described referring to the flow chart of Fig. 9, and examples of functionalities of a master node are now described referring to the flow chart in Fig. 10.
  • each slave node is to perform a reception process as shown in Fig. 9.
  • the break character is received on the request line.
  • the break character indicates the end of a frame and, therefore, at 302, receiving DMA is stopped.
  • it is checked whether the received frame has one of valid fixed frame lengths, which, in examples, may be a frame length of 3 bytes or 7 bytes. If the received frame does not have the fixed frame length of 3 byte or 7 bytes, but any other frame length, a form error is recognized, 306. If the received frame has a frame length of 3 byte, the frame is a read request, 308, and if the received frame has a frame length of 7 byte, the frame is a write request, 310.
  • the CRC value of the frame is fetched from the third byte, 312, and in case of a write request, the CRC value of the frame is fetched from the seventh byte, 314.
  • a new CRC value is calculated from the frame, such as from all bytes except for the CRC value of the frame.
  • the receiving DMA Upon recognizing a form error at 306 the receiving DMA is started again and the reception process ends at 324. Upon recognizing a CRC error at 322 the receiving DMA is started again and the reception process ends at 324. Upon sending the frame to the link layer, the receiving DMA is started again at 322 and the reception process ends at 324.
  • each master node is to perform a process as shown in Fig. 10.
  • the master node sends a read request or a write request on the request line. Corresponding transmissions may be requested by upper layers of the master node.
  • a retransmission counter R is set to 0.
  • the read request or the write request is sent on the request line, such as the MOSI line shown in Fig. 2.
  • a timeout is started.
  • the receiving DMA stops.
  • the retransmission counter R is increased by one at 414.
  • the retransmission counter is compared to a threshold Rlimit and it is checked at 416 whether the retransmission counter exceeds the threshold Rlimit. If the retransmission counter does not exceed the threshold, retransmission of the frame takes place at 404. In the retransmission, the increased retransmission counter is included in the frame.
  • the received frame After stopping the receiving DMA at 412, it is determined whether the received frame has the correct frame length at 418. To be more specific, it is determined whether the DMA byte count matches the response size for the transmitted request. If not, a form error is recognized at 420. If it is determined that the received frame has the correct frame length at 418, the CRC value is fetched from the frame at 422. In examples, the CRC value is fetched from the last byte of the frame, i.e. the byte preceding the break character. At 424 a new CRC value is calculated using the received frame, such as using all bytes of the frame except for the CRC value of the frame. At 426 it is checked whether the CRC value of the frame and the new CRC value match.
  • the receiving DMA is started at 432 and the process ends at 434.
  • Recognizing a form error at 420 or a CRC error at 428 means that the response was not received successfully.
  • the receiving DMA is restarted at 436.
  • the process jumps to 414 and the retransmission counter is increased by 1. The increased retransmission counter is again compared to the threshold Rlimit.
  • examples of the present disclosure permit communication between a master node and slave nodes in an easy manner while maintaining the possibility of recognizing errors and recovering from errors.
  • examples permit reduction of workload upon recognizing that a received frame does not have the correct frame length.
  • 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

La présente invention concerne un système de communication comprenant un noeud maître et des nœuds esclaves, le noeud maître et les nœuds esclaves étant couplés l'un à l'autre dans une configuration en guirlande, la configuration en guirlande comprenant une ligne de demande pour transmettre des trames de demande du noeud maître aux nœuds esclaves et une ligne de réponse pour transmettre des trames de réponse des nœuds esclaves au noeud maître. Chaque noeud comprend une interface matérielle pour recevoir une trame entrante. L'interface matérielle détecte une extrémité de la trame entrante à l'aide d'un caractère de rupture. Chaque noeud vérifie si la trame entrante a une longueur de trame correcte, traite en outre la trame entrante si la trame entrante a la longueur de trame correcte, et ne traite pas davantage la trame entrante si la trame entrante n'a pas la longueur de trame correcte.
PCT/US2018/053287 2018-09-28 2018-09-28 Communication maître/esclave Ceased WO2020068095A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2018/053287 WO2020068095A1 (fr) 2018-09-28 2018-09-28 Communication maître/esclave

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2018/053287 WO2020068095A1 (fr) 2018-09-28 2018-09-28 Communication maître/esclave

Publications (1)

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

Family

ID=69953276

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2018/053287 Ceased WO2020068095A1 (fr) 2018-09-28 2018-09-28 Communication maître/esclave

Country Status (1)

Country Link
WO (1) WO2020068095A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115275408A (zh) * 2022-07-18 2022-11-01 山东交通学院 一种用于测量电池包内电芯电压与温度的系统及方法
WO2024082907A1 (fr) * 2022-10-20 2024-04-25 思瑞浦微电子科技(上海)有限责任公司 Réseau topologique et procédé de traitement de communication
CN120540178A (zh) * 2025-07-16 2025-08-26 深圳市边界智控科技有限公司 基于rs485通信的电动垂直起降电传总线控制系统及方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009239429A (ja) * 2008-03-26 2009-10-15 Mitsubishi Electric Corp 通信システムのノード識別子設定方法
EP1312185B1 (fr) * 2000-08-04 2014-03-05 Qualcomm Incorporated Procédé et logiciel de fonctionnement dans un réseau de type csma
JP2017005364A (ja) * 2015-06-05 2017-01-05 株式会社東芝 シリアル通信システムおよび通信設定方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1312185B1 (fr) * 2000-08-04 2014-03-05 Qualcomm Incorporated Procédé et logiciel de fonctionnement dans un réseau de type csma
JP2009239429A (ja) * 2008-03-26 2009-10-15 Mitsubishi Electric Corp 通信システムのノード識別子設定方法
JP2017005364A (ja) * 2015-06-05 2017-01-05 株式会社東芝 シリアル通信システムおよび通信設定方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115275408A (zh) * 2022-07-18 2022-11-01 山东交通学院 一种用于测量电池包内电芯电压与温度的系统及方法
CN115275408B (zh) * 2022-07-18 2026-02-06 山东交通学院 一种用于测量电池包内电芯电压与温度的系统及方法
WO2024082907A1 (fr) * 2022-10-20 2024-04-25 思瑞浦微电子科技(上海)有限责任公司 Réseau topologique et procédé de traitement de communication
CN120540178A (zh) * 2025-07-16 2025-08-26 深圳市边界智控科技有限公司 基于rs485通信的电动垂直起降电传总线控制系统及方法

Similar Documents

Publication Publication Date Title
US11792114B2 (en) System and method for facilitating efficient management of non-idempotent operations in a network interface controller (NIC)
CN103814550B (zh) 用于运行通信装置的方法以及相应的通信装置
US7418524B2 (en) Universal serial bus (USB) extension
US7106742B1 (en) Method and system for link fabric error detection and message flow control
JP2707529B2 (ja) データ通信システム
US11381514B2 (en) Methods and apparatus for early delivery of data link layer packets
CN101645766B (zh) 实现数据包重发的方法、装置及系统
CN109981480A (zh) 一种数据传输方法及第一设备
US11729021B2 (en) User station for a serial bus system and method for communication in a serial bus system
KR102099789B1 (ko) 버스 시스템용 가입자 국, 그리고 버스 시스템의 가입자 국들 간의 메시지 전송 방법
KR20020002305A (ko) 데이터 패킷 전송 방법 및 네트워크 통신 시스템
JPH06236328A (ja) データ処理装置におけるエラーのあるメッセージの処理方法
US9081905B2 (en) Low latency interconnect bus protocol
WO2020068095A1 (fr) Communication maître/esclave
JPH05504668A (ja) データ通信の最適化された方法と、その方法を使用するシステム
EP4131817B1 (fr) Procédé de transmission de données et dispositif de réseau
CN113132063B (zh) 一种物理层重传控制方法
ES2733332T3 (es) Protocolo de transmisión de datos con estado de excepción de protocolo
CN116055583A (zh) 可兼容多协议的通信系统及其控制方法、电子设备
CN103368689A (zh) 一种数据传输方法及系统
JP2014003377A (ja) 制御装置及び画像形成装置
WO2016057038A1 (fr) Émetteur ne réémettant pas un paquet malgré la réception d'un message de réémission du paquet
CN102884744B (zh) 用于保护有待于通过接口传输的数据包的方法和设备
US7760655B2 (en) Method and device for transfer of data over a data connection from a sender to a receiver by means of packets
CN115514457B (zh) 无线物联网控制信道通信方法、系统、设备及介质

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

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

Country of ref document: EP

Kind code of ref document: A1