WO2020068097A1

WO2020068097A1 - Initializing devices in daisy chain

Info

Publication number: WO2020068097A1
Application number: PCT/US2018/053294
Authority: WO
Inventors: Thieu X. Dang; Nicola Baldo; David SORIANO FOSAS
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 method of initializing at least one device connected to a master in a daisy chain, is provided. The method identifies at least one device connected to a master in a daisy chain. The method further initializes the at least one device. The method assigns a unique address to the at least one device. Further, a master controller, a system and a non-transitory computer readable storage medium are provided.

Description

INITIALIZING DEVICES IN DAISY CHAIN

BACKGROUND

[0001] In electrical and electronic engineering, a daisy chain is a wiring scheme in which multiple devices are wired together in sequence or in a ring. Daisy chains may be used for power, analog signals, digital data, or a combination thereof.

[0002] Examples of daisy-chained schemes includes Modbus which is a well- established communication protocol for industrial electronic devices that supports sensors and actuators and is commonly used within Programmable Logic Controllers, PLCs. Variants of Modbus work on top of serial communications.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Features of examples will be described, by way of example only, in the following detailed description with reference to the accompanying drawings in which similar reference numerals correspond to similar, though perhaps not identical, components. For the sake of brevity, reference numerals or features having a previously described function may or may not be described in connection with other drawings in which they appear.

[0004] Figure 1 is a block diagram of an example method of initializing devices in a daisy chain;

[0005] Figure 2 is a block diagram of another example method of initializing devices in a daisy chain;

[0006] Figure 3 is a block diagram of an example method of executing a firmware upgrade for device in a daisy chain;

[0007] Figure 4 illustrates an example of a master controller;

[0008] Figure 5 illustrates an example of daisy chain system; and

[0009] Figure 6 illustrates an example of a non-transitory computer readable storage medium with computer readable instructions to be executed by a computing device.

DETAILED DESCRIPTION

[0010] General examples provided herein relate to a method of initializing at least one device connected to a master in a daisy chain, a master controller, a system and a non-transitory computer readable storage medium.

[0011] Referring to the figures, examples for initializing devices in a daisy chain will be explained in more detail below.

[0012] Figure 1 is a block diagram of an example method of initializing devices in a daisy chain.

[0013] The example method 100 may be performed in a daisy-chain system including a master and at least one device (referred to as the device in this example). The device and the master are connected in a daisy chain. More specifically, the device is connected to the master in sequence or in a ring to form a daisy chain.

[0014] For example, the master may be a central engine and the device may be one of a variety of sensor or actuator device. The device in the daisy chain may be part of a device for three-dimensional printing (3D printer). The master may also be part of the 3D printer, or externally connected to the 3D printer. As it will be understood by one of ordinary skill, the daisy-chain system is not limited to a 3D printer. [0015] In the daisy chain, the master may communicate with the devices using an address. Each device in the daisy chain may have a device identifier. The device identifier may be used as the address of the device. That is, the master may communicate with a particular device in the daisy chain using the device identifier as the address of the device. For example, the master may send an instruction or command (a signal, in general) to the device instructing the device to read/write data to/from the device. The device may determine based on the device identifier received in the communication from the master whether the devices is the intended receptor. If this is the case, the device may execute the instruction or command and respond to the master, if appropriate.

[0016] Prior to initializing, the devices (i.e. , uninitialized devices) may all have a default device identifier or may be programmed to respond to communications from the master with a default address. An example of a default address may be device id 63 for a 6-bit address length.

[0017] In the daisy chain, the master may communicate with an uninitialized device by sending a command or instruction to the default address. For example, the master may send a command to read a register from the uninitialized device. An already initialized device in the daisy chain will not respond to the command or instruction, even if the initialized device is upstream of the uninitialized device because the already initialized device may have an address different from the default address. The first uninitialized device in the daisy chain will however receive and respond to the command or instruction because the uninitialized device uses the default address. Further uninitialized devices downstream of the first uninitialized device in the daisy chain will not receive the instruction or command because the first uninitialized device is blocking propagation of the command or instruction. In other examples, uninitialized devices may be configured to propagate the command or instruction if it contains a specific address (which, in one example, may also be the default address) such that all uninitialized devices may respond.

[0018] The example method 100 starts in block 1 10. In block 1 10, the device connected to the master in the daisy chain is identified. For example, the device may be identified by sending a signal (command or instruction) to the device and receiving a response from the device. As described above, the master may send a signal including an address (e.g., the default address).

[0019] In some examples, identifying in block 1 10 may comprise configuring the master to allow sending/receiving signals to/from devices in the daisy chain. Further, identifying in block 110 may comprise configuring at least one device upstream of the device in the daisy chain to forward signals from the master to the device. In other examples, identifying in block 1 10 may comprise configuring the device to forward signals from the master to at least one next device downstream of the device in the daisy chain.

[0020] As described, devices in the daisy chain which have not been initialized (i.e. , which are uninitialized) are typically configured to not forward, in the downstream direction (i.e., the direction away from the master), a signal received from the master or a next device which is immediately upstream of the device in the daisy chain, to a next device downstream of the device. In order to ensure forwarding or not forwarding the signal, the device may be configured correspondingly such that, for example, signal including the default address are received by the device but not forwarded (i.e., not further propagated).

[0021] In other example, identifying in block 1 10 may comprise sending at least one signal using the default address to determine whether the at least one device is initialized.

[0022] In some examples, identifying in block 1 10 may comprise the master sending a reset signal to the device. The device receiving the reset signal will be reset and set to an initial state, which allows initialization. Further, the master may read at least one register of the device to identify a device type and compare the device type with a set of expected device types of the device. The set of expected device types may, for example, comprise at least one expected device type of the device. Comparing the device type of the device to the set of expected device types enables the master to allow initializing the device correctly. [0023] The example method 100 may further comprise initializing the device, in block 120.

[0024] In some examples, initializing in block 120 may comprise reading at least one register of the device to identify at least one hardware version of the device, and comparing the at least one hardware version with at least one expected hardware version. For example, the master may send a signal to the device to read a register indicating the hardware version of the device and the device may respond to the master with the hardware version. In response to receiving the hardware version from the device, the master may compare the hardware version with the set of expected hardware version to determine whether the hardware version of the device allows initializing the device correctly.

[0025] In other examples, initializing in block 120 may comprise reading at least one register of the device to identify a firmware version, and comparing the firmware version with an expected firmware version. The master compares the firmware version of the device to allow initializing the device correctly. If the firmware version of the device is determined to be outdated, initializing in block 120 may further comprise executing a firmware upgrade for the device. Executing the firmware upgrade may, for example, comprise sending at least one instruction to cause the device to initialize a bootloader, read or write data, clear a memory, write a new firmware, and/or initialize the new firmware, resulting in the device having the new firmware and a firmware version matching the expected firmware version.

[0026] Finally, the example method 100 may comprise assigning a unique address to the device, in block 130. For example, assigning in block 130 may comprise writing the unique address to at least one register of the device. As described, the device has the default address prior to being initialized. The default address in the at least one register may be overwritten by the unique address or the unique address may be written to the at least one register and the device may be instructed to use the unique address. The device to which the unique address has be assigned is now initialized and the master can control the device. [0027] In some examples, the example method 100 may be repeated until all devices connected to the master in the daisy chain have unique addresses assigned and are thereby initialized. The master is then enabled to communicate with each device in the daisy chain using a unique address assigned to it.

[0028] For example, the example method 100 may be implemented as a software protocol which, when executed by a computing device (e.g., the master), causes the computing device to initialize and control devices (e.g., low cost devices such as sensor or actuator devices) connected to the computing device in a daisy chain. The example method 100 allows to identify the devices in the daisy chain, assign each device a unique address, check and upgrade the firmware on each device, and query and set registers on each device.

[0029] The example method 100 as described above may be incorporated into a communication protocol. According to the communication protocol, the master may communicate with devices in the daisy chain with requests (i.e., signals, commands, or instructions) to read from and write to registers, which provides an interface for the master to interact with sensor and actuator devices, for example. The communication protocol may be transported over a full duplex Universal Asynchronous Receiver T ransmitter (UART) physical interface.

[0030] Figure 2 is a block diagram of another example method of initializing devices in a daisy chain.

[0031] According to the example method 200, the devices connected to the master in a daisy chain may be initialized. The devices may be configured and can be controlled when being configured. The number of devices connected in sequence or to form a ring in the daisy chain may be any natural number, i.e., the number N of devices is in the range of 1 to n.

[0032] The example method 200 starts in block 202 with setting the current number to 1 (i.e., N = 1 ) in order to start initializing the first device in the daisy chain (referred to as the device hereinforth). [0033] Optionally, according to some examples, the example method 200 may proceed with blocks 292 and 294 and check the presence of the device. In some examples, a presence signal for the device may be read by the master, in block 292. This may be achieved by sending a signal or command to the device to read a register on the device. The device receiving the signal or command reads the register and responds the presence signal to the master. The presence signal may, for example, be signal high or signal low. The master may determine whether the presence signal, if received at all, is valid, in block 294. In particular, the master may check whether the presence signal indicates presence of the device. If the determination in block 294 is successful, the example method 200 proceed with block 202. Otherwise, the device is considered disconnected such that the daisy chain is interrupted, thereby causing an error state in block 296. The example method 200 may then proceeds with block 298.

[0034] In block 298, a status of the example method 200 may be set to initialization failed and the example method 200 may end. Alternatively, the example method 200 may be repeated to re-check whether the status is still present. The repetition may be performed a given number of times (e.g., one time, two times or three times).

[0035] In other examples, blocks 292 and 294 may be omitted. The example method 200 may directly proceed with block 204. In block 204, the device is configured to forward signals/commands to the next device downstream in the daisy chain. For example, the master may send a signal or command to the device to enable transmitting/receiving to/from the next device. The device may, for example, activate a universal synchronous and asynchronous receiver-transmitter (USART) upon receiving the signal or command from the master. In some examples, block 204 may be omitted for the first device (i.e. , in case of N = 1 ) in order to enable initializing the first device.

[0036] Then, in block 206, the master may send a reset signal which, when received at the device, causes the device to reset the hardware and/or a configuration of the device. In an example, the reset signal may be a high signal on the connection, or at least on a part of the connection such as at least one wire in case of a wired connection with multiple wires. The high signal may last for a given period of time, for example, 250 ms. For example, the master may send HW reset pulse to the device.

[0037] In block 208, a signal or command may be sent to the device to read a register. For example, the master may send a command to the device to read the register indicating a device type of the device (e.g., DEVICE_TYPE). The device receiving the command reads the register and responds to the master with the device type. The device type may, for example, one among sensor device, actuator device, or the like.

[0038] In block 210, the master may check whether a response to the signal or command sent in block 208 is received. That is, the master may check whether the device responds or not.

[0039] If not, the master may indicate the device as a non-response device, in block 212, and may then execute a firmware upgrade for the device, in block 214. Examples of executing a firmware upgrade are described below with reference to

Figure 3.

[0040] If the device responds and thus the check in block 210 is successful, the device type received from the device is compared with a set of device types, in block 216. For example, the set of device types comprises at least one device type but may also comprise more than one device type (e.g., in the form of a list, or the like). The set of device type indicates those device types which the master expects the device may be one of. Also, in some examples, the master may use individual sets of device types depending on the position of the device in the daisy chain (e.g., depending on the current number of N). In block 216, the master may determine whether the device type received from the device matches one of the device types in the set.

[0041] If the comparison in block 216 is not successful (i.e. , the received device type is not as expected), the example method 200 may indicate an error state (i.e., wrong device type), in block 218 and may then proceed to block 298, as described above.

[0042] Otherwise, if the comparison in block 216 is successful and thus the received device matches with the set of device types (i.e., the received device type is as expected), the example method 200 may proceed with block 220. In some examples, in block 220, the master may send a signal or command to the device to read a register. In particular, the register to be read may indicate the hardware version (e.g., HW_VERSION) of the device. The device receiving the signal or command reads out a value of the register and responds the value as the hardware version to the master.

[0043] The hardware version received from the device may then be compared with an expected hardware version, in block 222. For example, the expected hardware version may be a hardware version number, a set of hardware version numbers, a range of hardware version numbers, or the like. The expected hardware version indicates those hardware versions which the master expects the device may have. Also, in some examples, the master may use individual expected hardware versions depending on the position of the device in the daisy chain (e.g., depending on the current number of N). In block 222, the master may determine whether the hardware version received from the device matches the expected hardware version. In other examples, the master may determine whether the received hardware version is equal or greater to the expected version.

[0044] If the comparison in block 222 is not successful (i.e., the received hardware version is not as expected), the example method 200 may indicate an error state (i.e., wrong hardware version), in block 224 and may then proceed to block 298, as described above.

[0045] Otherwise, if the comparison in block 222 is successful and thus the received hardware version matches with, or is equal or greater than, the expected hardware version (i.e., the received hardware version is as expected), the example method 200 may proceed with block 226. In some examples, in block 226, the master may send a signal or command to the device to read a register. In particular, the register to be read may indicate the firmware version (e.g., FW_VERSION) of the device. The device receiving the signal or command reads out a value of the register and responds the value as the firmware version to the master.

[0046] The firmware version received from the device may then be compared with an expected firmware version, in block 228. For example, the expected firmware version may be a firmware version number, a set of firmware version numbers, a range of firmware version, or the like. The expected firmware version indicates those firmware versions which the master expects the device may have. Also, in some examples, the master may use individual expected firmware versions depending on the position of the device in the daisy chain (e.g., depending on the current number of N). In block 228, the master may determine whether the firmware version received from the device matches the expected firmware version. In other examples, the master may determine whether the received firmware version is equal or greater to the expected firmware version.

[0047] If the comparison in block 228 is not successful (i.e. , the received firmware version is not as expected), the example method 200 may proceed with block 214, as described above.

[0048] Otherwise, if the comparison in block 228 is successful and thus the received firmware version matches with, or is equal or greater than, the expected firmware version (i.e., the received firmware version is as expected), the example method 200 may proceed with block 230.

[0049] The example method 200 may also proceed with block 230 as described above after executing the firmware upgrade in block 214 and determining whether the firmware upgrade was successful in block 242. If the determination in block 242 indicates that the firmware update was not successful, the example method 200 may indicate an error state (i.e., firmware upgrade failed), in block 244 and may then proceed to block 298, as described above.

[0050] In block 230, a signal or command is sent to the device write a register. In particular, the register to be written may indicate a device identifier (e.g., DEVICEJD) of the device. The device identifier may represent an address of the device. In some examples, the address may be a unique address used among the devices in the daisy chain and in particular, may be different from the default address. As described above, signals or commands sent from the master are addressed to the device using the address of the device. The device receiving signals or commands from the master checks whether the signals or commands are designated for it. For example, the device checks whether the address indicated in the signals or commands corresponds to its own address (e.g., the device identifier written to the register). Accordingly, in block 230, the address is assigned to the device.

[0051] In some examples, the device may respond to the signal or command. For example, the device may either acknowledge receipt of the signal or command to write the address to the register or confirm that the address has been successfully written to the register. The response received from the device may indicate the device identifier (i.e. , address) written to the register and read therefrom. In block 232, the master may check whether a response is received from the device. In addition, the master may determine whether the device identifier which the device responds corresponds to the device identifier sent to the device.

[0052] If the check in block 232 is not successful (i.e., no response received or no match with the device identifier sent), the example method 200 may indicate an error state (i.e., new firmware not functional), in block 234 and may then proceed to block 298, as described above.

[0053] Otherwise, if the check in block 232 is successful, the example method 200 may proceed with block 236 to increment the current number (i.e., N = N + 1 ). In the example method 200, the current number may then be checked whether it is smaller to an expected number of devices in the daisy chain (e.g., to the number n). If not, the example method proceeds with block 292 or block 204, both described above. Otherwise, a status of the example method 200 may be set to initialization successful, in block 240. The example method 200 may then end successfully. [0054] As a result of the method 200 being performed successfully, each of the devices connected to the master in the daisy chain is initialized. That is, the firmware of each device is updated so as to have a firmware version matching the expected firmware version and a unique address is assigned to each device. Each of the devices in the daisy chain can therefore be controlled by the master using the unique address. Also, signals or commands can be directed to each of the device using the unique address.

[0055] Figure 3 is a block diagram of an example method of executing a firmware upgrade for device in a daisy chain.

[0056] According to the example method 300, the firmware for a device connected to a master in a daisy chain is upgraded or updated. The example method 300 may be performed in case it is determined that the version of the firmware of the device does not match with a version that is expected for that device. This may involve comparing the version, for example, a version number, identifier for the version, or the like, with the expected version. If the version is smaller than the expected version, the firmware is regarded as being outdated and is to be updated.

[0057] In some examples, the determination of whether the firmware of the device needs to be updated may be based on other information such as, for example, a hash value of the firmware, a type of the firmware, a name of the firmware, or the like. The information is not limited to these examples and may be anything that identifies or characterizes the firmware. In other examples, the firmware also may be upgraded each time the device is initialized.

[0058] The example method 300 starts in block 302 with configuring the master and/or the device to enable receiving/transmitting data. In some example, the master may configure a receiver/transmitter (e.g., UART) to receive and/or transmit data from/to the device. To configure the device in block 302, the master may, for example, send a signal or instruction to the device over the connection between the device and the master. The instruction, when received at the device, cause the device to configure it to enable receiving/transmitting data. In an example, a receiver/transmitter (e.g., UART) of the device may be activated. For example, UART may be configured with 8 bits per character, no parity bits and 1 stop bit.

[0059] The master may send the signals or instructions to the device, as described hereinbelow, either using a unique address assigned to the device previously or using a default address. The default address may be set to 63. In the case of sending using the default address, the device may beforehand be configured to not forward the signals or instructions received from the master to a next device downstream of the device in the daisy chain.

[0060] Then, in block 304, the master may send a reset signal which, when received at the device, causes the device to reset the hardware and/or a configuration of a bootloader of the device. In an example, the reset signal may be a high signal on the connection, or at least on a part of the connection such as at least one wire in case of a wired connection with multiple wires. The high signal may last for a given period of time, for example, 250 ms. For example, the master may send HW reset to bootloader pulse on CONFIG.

[0061] The receiver/transmitter of the master and/or the device is then configured for the bootloader, in block 306. In some examples, the receiver/transmitter of the master may be configured for a bootloader specific to a manufacturer, the device the firmware of which is to be upgrade, the manufacturer of the device, or the like. The receiver/transmitter of the device may be configured by sending a signal or instruction from the master, e.g., using the default address or the unique address assigned to the device. For example, UART may be configured for bootloader.

[0062] In block 308, the master sends a signal or instruction to synchronize the bootloader to the device. In some example, the master may send a specific code (e.g., hex code 0x7 F) identifying the signal or instruction to synchronize the bootloader. For example, the master may send SYNC command.

[0063] Then, in block 310, the master sends a signal or instruction to the device. The signal or instruction of block 310 may be to get information from the bootloader of the device, the status of the bootloader, or the like. For example, the master may send bootloader GET command.

[0064] In some examples, the master may send command to the device to trigger the bootloader of the device. In these examples, blocks 308 and 310 may be omitted.

[0065] In response to receiving a response to the signal or instruction sent in block 310 (e.g., GET response), the master may configure a bootloader client according to the response, in block 312. In some examples, the master configures the bootloader client using, and in accordance with, the information received from the device.

[0066] The master may also send a signal or instruction to the device to receive information identifying the bootloader or the device, in block 314. For example, the master may send bootloader GET ID command.

[0067] The master receives, from the device, the information identifying the bootloader or the device and in block 316, compares the received information with expected information. For example, the device may send a product identifier in response to receiving the signal or instruction and the master compares the product identifier with an expected product identifier, the expected product identifier may be a product identifier of a manufacturer.

[0068] If the comparison in block 316 is not successful, the master assumes the information received from the device to be not correct, in block 318. For example, if the product identifier received from the device does not match with an expected product identifier in block 316 (e.g., is not equal, not within a particular range, or the like), the master assumes the product identifier to be wrong, indicating an error state. If this is the case, the master considers the firmware upgrade has failed and may indicate a corresponding error or fail state, block 320.

[0069] Otherwise, if the comparison in block 316 is successful and thus the master assumes the information received from the device to be correct, the example method 300 may proceed with block 322. For example, the comparison may be successful if the product identifier received from the device matches with an expected product identifier.

[0070] In block 322, the master may send a signal or instruction to the bootloader to read data from the device. In some example, the device may store in a memory or register at least one byte which may be read. For example, the master may send bootloader READ command. The at least one byte may indicate whether a firmware exists on the device, whether the device is a blank device, whether the device is allowed to be flashed (i.e., whether a firmware can be re-/written to the device), a value of the device type, a value of the hardware version, or the like. In some examples, the value of the device type and/or the value of the hardware version may be hash values, generated in accordance with any suitable hash algorithm such as SHA1 , MD5, or the like. In response to receiving the signal or instruction, the device may read the at least one byte from the memory or register, and responds the same to the master.

[0071] The master may compare the received data from the device in order to determine whether the device is a blank device, in block 324. For example, the master may determine whether the at least one byte matches with a value (e.g., byte pattern) in order to determine that the device is a blank device. The at least one byte may comprise a byte or bytes indicating that the device is a blank device.

[0072] If it is determined in block 324 that the device is a blank device (i.e., a match is determined), the example method 300 may proceed with block 326. Otherwise, the example method 300 may proceed with block 334.

[0073] In block 326, the master may determine whether the device being a blank device is allowed to be flashed. That is, the master may determine whether a firmware can be written to the device, or its memory or registers. The master may use the at least one byte which may comprise a byte or bytes indicating whether the device can be flashed. If the determination in block 326 is not successful and thus the device is not allowed to be flashed, the example method 300 proceeds with block 328. In this case, the master assumes that flashing the device is not allowed, resulting in an error state. This error state is considered by the master as the firmware upgrade has failed such that a corresponding error or fail state may be present, block 320.

[0074] Otherwise, if the determination in block 326 is successful and thus the device is allowed to be flashed, the master may send a signal or instruction to the bootloader of the device to write data into the memory or registers of the device, in block 330. In some examples, the data to be written comprises the device type (i.e. , DEVICE_TYPE) of the device, the hardware version (i.e., HW_VERSION) of the device, and/or hash values thereof. The hash values may be generated by the master device using any suitable hash algorithm. The data may be written into the at least one byte of the device. For example, the master may send WRITE command to write a hash of DEVICE_TYPE and HW_VERSION into the at least one byte.

[0075] In block 332, the master may then send a signal or instruction to synchronize the bootloader to the device. In some example, the master may send a specific code (e.g., hex code 0x7 F) identifying the signal or instruction to synchronize the bootloader. For example, the master may send bootloader SYNC command. The example method proceeds with block 342.

[0076] If it is determined in block 324 that the device is not a blank device (i.e., no match is determined), the master may then proceed with determining whether the data received from the device in response to block 322 correspond to an expected device type, in block 334, and/or to an expected hardware version, in block 338.

[0077] For example, in block 334, the master may determine whether the data comprise information indicating a device type of the device which matches with an expected device type at the master. For example, the at least one byte may comprise a byte or bytes representing the device type, e.g., in the form of a value or hash. In particular, byte 0 of the at least one byte may comprise the hash of the DEVICE TYPE and may be used in the determination. If the determination in block 334 is not successful, the master assumes the device type to not be matching and thus wrong, in block 336. This may indicate an error state and the master may consider the firmware upgrade has failed, indicating a corresponding error or fail state, block 320.

[0078] Otherwise, if the determination in block 334 is successful, the master may determine whether the data comprise information indicating a hardware version of the device which matches with an expected hardware version at the master, in block 338. For example, the at least one byte may comprise a byte or bytes representing the hardware version, e.g., in the form of a value or hash. In particular, byte 1 of the at least one byte may comprise the hash of the HW_VERSION and may be used in the determination. If the determination in block 338 is not successful, the master assumes the hardware version to be not matching and thus wrong, in block 340. This may indicate an error state and the master may consider the firmware upgrade has failed, indicating a corresponding error or fail state, block 320. Otherwise, the example method proceeds with block 342.

[0079] In block 342, the master may send a signal or instruction to the bootloader of the device to clear the memory or register (e.g., a flash memory of the device). In some example, the master may send a sequence of signals or instructions such as ERASE commands. In other examples, block 342 may be omitted if not needed which may be the case if the device is a blank device.

[0080] Then, in block 344, the master may send a signal or instruction to the bootloader of the device to write data to the memory or register of the device. For example, the data to be written may be a sequence of computer executable instructions, program code, or a new program. In some examples, the master may send a sequence of signals or instructions such as WRITE commands. In other examples, the signal(s) or instruction(s) to write may be followed by sending signal(s) or instructions to read the data written to the memory or register. The data read after writing the same may be compared to the data to be written to validate whether they match. In case of a match, the master may proceed with sending next signal(s) or instruction(s) to write. Otherwise, the master may re-send previous signal(s) or instructions(s) or assumes that the firmware upgrade has failed. [0081] After the data has been written completely, the master may send a signal or instruction to jump to the newly written data, in block 346. For example, the master may send a GO command.

[0082] Then, in block 348, the master and/or the device may again be configured to enable receiving/transmitting data. In some example, the master may configure UART to receive and/or transmit data from/to the device. For example, UART may be configured with 8 bits per character, no parity bits and 1 stop bit.

[0083] Finally, in block 350, the master may consider the firmware upgrade to be successful, indicating a corresponding success state. The example method 300 may then end.

[0084] Figure 4 illustrates an example of a master controller. The master controller may be used to initialize and control devices connected to the master controller in a daisy chain.

[0085] In some examples, the master controller 400 as illustrated in Figure 4 comprises an identifier logic 410, an initializer 420 and an address assigner 430. In other examples, the master controller 400 may comprise more orfewer components.

[0086] The identifier logic 410 identifies at least one device connected to the master controller in the daisy chain. The initialized 420 initializes the at least one device. The address assigner 430 assigns a unique address to the at least one device.

[0087] In some examples, the identifier logic 410 of the master controller 400 may configure at least one other device upstream of the at least one device in the daisy chain to forward signals from the master controller 400 to the at least one device. In other examples, the identifier logic 410 of the master controller 400 may configure the at least one device to forward signals from the master controller 400 to at least one next device downstream of the at least one device in the daisy chain. For example, the identifier logic 410 may send a signal or command to the at least one device in response to which the at least one device set a register to activate/deactivate forwarding signals or commands received from the master controller 400 to the at least one next device.

[0088] In other examples, the identifier logic 410 of the master controller 400 may send at least one signal using a default address to determine whether the at least one device is initialized.

[0089] In some other examples, the identifier logic 410 of the master controller 400 may send a reset signal to the at least one device, read at least one register of the at least one device to identify a device type, and compare the device type with a set of expected device types of the at least one device. For example, the set of expected device types may comprise at least one expected device type of the at least one device.

[0090] The identifier logic 410 according to another example may read at least one register of the at least one device to identify at least one hardware version, and compare the at least one hardware version with at least one expected hardware version.

[0091] According to other examples, the initializer 420 may read at least one register of the at least one device to identify a firmware version. The initializer 420 may also compare the firmware version with an expected firmware version. In some examples, the initializer 420 may execute a firmware upgrade for the at least one device, if the firmware version does not match the expected firmware version. The initializer 420 may further send at least one instruction to cause the at least one device to initialize a bootloader, read or write data, clear a memory, write a new firmware, or initialize the new firmware.

[0092] In some examples, the address assigner 430 may write the unique address to at least one register of the at least one device to thereby initialize the at least one device.

[0093] In other examples, the master controller 400 may execute operations as described above in connection with Figures 1 to 3. Alternatively, the master controller 400 may comprise one or more components or circuits, each to implement one or more of the operations described above.

[0094] Figure 5 illustrates an example of a daisy chain system.

[0095] The daisy chain system 500 may comprise a master controller 510 and at least one device 520. The at least one device 520 may be connected to the master controller 510 in a daisy chain. In Figure 5, three devices 520a, 520b and 520c are shown. However, the daisy chain system 500 is not limited to the number of three and may comprise any other number but at least one device 520. The devices 520 are connected together in sequence or in a ring to form a daisy chain.

[0096] In some examples, each device 520a, 502b, 502c may include a storage such as a flash memory or other form of non-volatile storage such as a hard drive, any form of read-only memory (ROM), or any type of magnetic storage device. Each device 520a, 520b, 520c may further include additional component such as connection interfaces, processors, processing circuitry, sensors and actuators. In other examples, the devices 520a, 520b, 520c may any type of sensor or actuator devices.

[0097] The master controller 510 may also include components such as a processor and a storage. In some examples, the master controller 510 may be a central engine for controlling the devices 520a, 520b, 520c. The interconnection between the master controller 510 and the devices 520a, 520b, 520c may be of any type suitable for interconnection such as Ethernet, UART, CAN bus, Modbus connections, or the like.

[0098] In one example, at least the devices 520a, 520b, 520c inter-connected in the daisy-chain manner form parts of a 3D printer. The master controller 510 may also be part of the 3D printer or connected to the 3D printer.

[0099] The master controller 510 is to identify the at least one device 520 connected to the master controller in the daisy chain, initialize the at least one device 520, and assign a unique address to the at least one device 520. An example of a master controller 510 which can be used in the daisy chain system 500 may be the master controller described above in connection with Figure 4. The master controller 510 is however not limited to the example of Figure 4.

[0100] Figure 6 illustrates an example of a non-transitory computer readable storage medium with computer readable instructions to be executed by a computing device.

[0101] The non-transitory computer readable storage medium 620 has computer readable instructions stored thereon. The computer readable instructions is for execution by a computing device 610. An example of the computer device 610 may comprise the master controller as illustrated in Figure 4. When executed, the computer readable instructions may cause the computing device 610 to identify at least one device connected to the computing device 610 in a daisy chain 630. The computer readable instructions may further cause the computing device 610 to initialize the at least one device 640 and assign a unique address to the at least one device 650.

[0102] The above discussion is meant to be illustrative of the principles and various examples of this disclosure. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. For example, the scope of disclosure is not limited to daisy-chained devices of a 3D printer, including a variety of sensor and actuator devices, as illustrated herein. The method, master controller and system of initializing daisy- chained devices may be extended to any type of daisy-chained devices. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

CLAIMS WHAT IS CLAIMED IS:

1. A method, comprising:

identifying at least one device connected to a master in a daisy chain;

initializing the at least one device; and

assigning a unique address to the at least one device.

2. The method of claim 1 , wherein identifying comprises:

configuring at least one other device upstream of the at least one device in the daisy chain to forward signals from the master to the at least one device.

3. The method of claim 1 , wherein identifying comprises:

sending at least one signal using a default address to determine whether the at least one device is initialized.

4. The method of claim 1 , wherein initializing comprises:

reading at least one register of the at least one device to identify at least one hardware version; and

comparing the at least one hardware version with at least one expected hardware version.

5. The method of claim 1 , wherein initializing comprises:

reading at least one register of the at least one device to identify a firmware version; and

comparing the firmware version with an expected firmware version.

6. The method of claim 5, further comprising:

executing a firmware upgrade for the at least one device, if the firmware version does not match the expected firmware version.

7. The method of claim 6, wherein executing comprises sending at least one instruction to cause the at least one device to initialize a bootloader, read or write data, clear a memory, write a new firmware, or initialize the new firmware.

8. The method of claim 1 , wherein assigning comprises writing the unique address to at least one register of the at least one device.

9. A master controller, comprising:

an identifier logic to identify at least one device connected to the master controller in a daisy chain;

an initializer to initialize the at least one device; and

an address assigner to assign a unique address to the at least one device.

10. The master controller of claim 9, wherein the identifier logic is to configure at least one other device upstream of the at least one device in the daisy chain to forward signals from the master controller to the at least one device.

1 1 . The master controller of claim 9, wherein the identifier logic is to send at least one signal using a default address to determine whether the at least one device is initialized.

12. The master controller of claim 9, wherein the initializer is to read at least one register of the at least one device to identify a firmware version, compare the firmware version with an expected firmware version, and execute a firmware upgrade for the at least one device, if the firmware version does not match the expected firmware version.

13. The master controller of claim 9, wherein the address assigner is to write the unique address to at least one register of the at least one device.

14. A system, comprising:

a master controller; and

at least one device connected to the master controller in a daisy chain, wherein the master controller is to identify at least one device connected to the master controller in a daisy chain, initialize the at least one device, and assign a unique address to the at least one device.

15. A non-transitory computer readable storage medium having computer readable instructions stored thereon that, when executed by a computing device, causes the computing device to:

identify at least one device connected to the computing device in a daisy chain;

initialize the at least one device; and

assign a unique address to the at least one device.