SYNCHRONE COMMUNICATION FROM SLAVE TO SLAVE

Abstract

Low-latency communication system (100), including: a slave node transceiver (104), comprising: an upstream transceiver circuit (122) for receiving a first signal sent via a two-wire bus (106) from an upstream device and for providing a second signal via the two-wire bus (106) to the upstream device, a downstream transceiver circuit (124) for providing a third signal downstream via the two-wire bus (106) towards a downstream device and for receiving a fourth signal via the two-wire bus (106) from the downstream device and a peripheral device interface (127, 129) for receiving first data from a first peripheral device that is communicatively coupled to the peripheral device interface (127, 129), wherein the downstream transceiver circuits (124) are to receive the first data into the third signal and; wherein the first signal comprises second data generated by a second peripheral device (127, 129) communicatively coupled to the upstream device, wherein the third signal is provided downstream after the first signal has been received, and the third signal comprises less than all the second data generated by the second peripheral device (127, 129) communicatively coupled to the upstream device, and wherein the peripheral device interface (127, 129) of the first peripheral device, which is communicatively coupled with the peripheral device interface (127, 129), is to provide at least a part of the second data generated by the second peripheral device, which is communicatively coupled with the upstream device, and wherein the fourth signal includes third data generated by a third peripheral device communicatively coupled to the downstream device, the second signal is provided upstream after the fourth signal has been received, and the second signal includes less than all the third data generated by the third peripheral device communicatively coupled to the downstream device, and wherein the peripheral device interface of the first peripheral device, which is communicatively coupled to the peripheral device interface, is to provide at least some of the third data generated by the third peripheral device, which is communicatively coupled to the downstream device, and wherein adding the first data to the third signal comprises adding the first data within a number of data slots in a downstream part of a superframe, and wherein a mask register DNMASK0, DNMASK1, DNMASK2 and DNMASK3 is provided which provides one bit for each possible downstream data slot, and If a slot mask bit LDNSLOTS.DNMASKEN of the mask register is set, the slot mask bit LDNSLOTS.DNMASKEN is used to select which downstream slots are consumed by the first peripheral device communicatively coupled to the slave node transceiver (104), and these are placed in a TX frame buffer, and If the slot mask bit LDNSLOTS.DNMASKEN is not set, an LDNSLOTS register defines the number of downstream slots consumed by the slave node transceiver. where the LDNSLOTS register defines the number of downstream data slots, starting immediately after a synchronization control frame, SCF.

Description

CROSS-REFERENCE TO RELATED REGISTRATION

[0001] The present application claims priority over the preliminary US patent application No. 62 / 289,051, filed on January 29, 2016, entitled “SYNCHRONOUS SLAVE-TO-SLAVE COMMUNICATIONS”. STATE OF THE ART

[0002] As electronic components become smaller and performance expectations increase, more components are being incorporated into devices that were previously unequipped or less equipped with them. In some environments, the communication infrastructure used to exchange signals between these components (e.g., in a vehicle) features thick and heavy bundles of cables. In DE 10 2015 117 673 A1, systems and techniques for the diagnosis and control of peripheral devices via a two-wire communication bus are described. WO 2013 / 052 886 A2 shows a two-wire bus system synchronous with embedded clock information that forms a large number of slave devices / peripheral devices, in which no microcontrollers are formed in the slave devices. US 2015 / 0301968A1 demonstrates the detection, configuration, and coordination of data communication between master and slave devices in a communication system, such as a two-wire point-to-point bus system, to control the sequential power-up of bus and slave devices. DE 10 2004 063 213 A1 discloses a method in which a data frame is transmitted as a forwarding data frame from one station to the next. The last station transmits the data frame as a returning data frame to the stations. The stations read external transmission data from the data fields of the returning data frame. DE 101 58 745 A1 discloses a process automation system comprising a transmitter and at least one sensor, which are jointly connected to a process controller via a fieldbus, wherein at least the transmitter communicates with the process controller via a master-slave communication method. The measurement signal processing can be simplified by having the at least one sensor communicate directly with the transmitter using a slave-slave communication method, and by the transmitter including a signal conditioning unit that processes the measured quantity acquired by the transmitter, depending on a measured value transmitted by the at least one sensor, into a measurement signal that can be transmitted to the process controller. The signal conditioning, which is dependent on the measured value, serves, for example, for compensation or calibration purposes or for calculating new measurement signals. EP 3 048 536 A1 discloses a two-wire bus system (e.g., unshielded twisted pair cable) that is simple (e.g., no microcontroller required in the slave devices), synchronous with embedded clock information, cost-effective, automotive EMC compliant, and offers sufficient speed and bandwidth for a large number of slave devices / peripherals. It also provides various protocols that can be used in different communication systems, such as a two-wire bus system. The two-wire bus can optionally be self-powered, meaning the master device can supply power to the slave devices via the two-wire bus. Methods for detecting, configuring, and coordinating data communication between master and slave devices in a communication system are also shown. EP 4 180 981 A1 refers generally to communication bus technology and, in particular, to a two-wire communication system for high-speed data and power distribution. It presents a two-wire bus system (e.g., unshielded twisted pair cable) that is simple (e.g., no microcontroller required in the slave devices), synchronous with embedded clock information, cost-effective, automotive EMC compliant, and offers sufficient speed and bandwidth for a large number of slave devices / peripherals. It also provides various protocols that can be used in different communication systems, such as a two-wire bus system. The two-wire bus can optionally be self-powered, meaning the master device can supply power to the slave devices via the two-wire bus. DE 10 2015 117 674 A1 discloses systems and techniques for distributed audio coordination over a two-wire communication bus. It can include, for example, a first slave device with circuitry to receive, via a two-wire bus, a synchronization control frame, audio data, and a dynamic processing (DP) parameter for a second audio device coupled to a second slave device. The first slave device can include circuitry to derive timing information from the synchronization control frame and circuitry to provide the audio data and a DP parameter (based on the DP parameter for the second audio device) to a first audio device coupled to the first slave device. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The embodiments become readily understandable by referring to the following detailed description in conjunction with the accompanying drawings. To facilitate this description, identical reference numbers denote identical structural elements. The embodiments are shown in the figures of the accompanying drawings as examples and not as limitations. Fig. Figure 1 is a block diagram of an exemplary two-wire communication system according to various embodiments. Fig. 2 is a block representation of a node transmitter-receiver located in a node of the system of Fig. 1 may be included, according to various embodiments. Fig. 3 is a representation of part of a system for communication within the system of Fig. 1 used synchronization control frame according to various embodiments. Fig. 4 is a representation of a system for communication within the system of Fig. 1 used superframe according to various embodiments. Fig. Figure 5 shows exemplary formats for a synchronization control frame in different operating modes of the system. Fig. 1 according to various embodiments. Fig. Figure 6 shows exemplary formats for a synchronization control frame in different operating modes of the system. Fig. 1 according to various embodiments. Fig. Figure 7 is a block diagram of various components of the bus protocol circuit of Fig. 2 according to different embodiments. Fig. Figures 8-11 show examples of information exchange on a two-wire bus according to different embodiments of the bus protocols described here. Fig. Figure 12 shows a ring topology for the two-wire bus and a unidirectional communication scheme based thereon according to various embodiments. Fig. Figure 13 schematically shows a device that is part of the system of Fig. 1 can serve as a node or host, according to various embodiments. Fig. Figure 14 shows an example of information exchange on a two-wire bus according to different embodiments of the bus protocols described here. Fig. Figure 15 is a block representation of an arrangement in which a slave node is coupled to an energy storage device and a peripheral device, according to various embodiments. Fig. Figure 16 shows an embodiment of the system of Fig. 1 together with a flowchart of a procedure that can be executed by a host to selectively route audio in the system. Fig. Figure 17 is a flowchart of a procedure performed by a slave node during the selective routing of audio in the system as shown in Fig. 16 can be executed according to various embodiments. Fig. Figure 18 shows an embodiment of the system of Fig. 1, in which a slave node has a wireless transceiver as a peripheral device. Fig. Figure 19 shows an embodiment of the system of Fig. 1, in which a host is paired with a wireless transceiver. Fig. Figures 20-23 show exemplary arrangements of a microphone, a microphone cable, and an audio receiving device used in the system of Fig. 1 may be included, according to various embodiments. Fig. Figure 24 shows an arrangement in which a slave node is located near an antenna coupled to the roof of a vehicle, according to various embodiments. Fig. Figure 25 shows an arrangement of several types of audiovisual devices as slave nodes in the system of Fig. 1 according to various embodiments. Fig. 26 shows a robot arm and an arrangement of the system of Fig. 1 to enable communication between sensors and actuators of the robot arm according to various embodiments. Fig. 27 is a block representation of an arrangement of components of the system of Fig. 1 with sending and receiving mailboxes according to various designs. Fig. Figure 28 shows an arrangement of slave nodes and associated peripheral devices in a vehicle according to various embodiments. Fig. 29 is a block representation of an arrangement of elements of the system of Fig. 1 and a bus monitor according to various embodiments. Fig. Figure 30 is a flowchart of a procedure for starting the operation of a bus monitor according to various embodiments. Fig. 31 gives an example of how upstream data slots can be used for slave-to-slave communication, according to different embodiments. Fig. Figures 32-35 show UPMASKn registers which can support slave-to-slave communication according to various embodiments. Fig. Figure 36 shows a local upstream slot offset register that can support slave-to-slave communication according to various embodiments. Fig. 37 gives an example of how downstream data slots can be used for slave-to-slave communication, according to various embodiments. Fig. Figures 38-41 show DNMASKn registers that can support slave-to-slave communication according to various embodiments. Fig. Figure 42 shows a local downstream slot offset register that can support slave-to-slave communication according to various embodiments. Fig. Figure 43 shows a local downstream slot register and its bit descriptions, which can support slave-to-slave communication according to various embodiments. Fig. 44 and Fig. Figure 45 shows non-slave-to-slave arrangements (left) and slave-to-slave arrangements for different communication scenarios according to different embodiments. Fig. Figures 46-55 show an example of slave-to-slave communication on a daisy-chain bus with multiple nodes according to different embodiments. Fig. Figures 56-65 show another example of slave-to-slave communication on a multi-node daisy-chain bus according to different embodiments. DETAILED DESCRIPTION

[0004] As electronic components become smaller and performance expectations rise, more components are being incorporated into devices that were previously unequipped or less equipped with them. This trend toward larger instrumentation has traditionally been limited by the communication infrastructure used to exchange signals between components. For example, the proliferation of sensors such as microphones, cameras, and so on in automobiles (and other closed and / or mobile systems such as robotic systems) has led to an excessive amount of wiring between components. This excessive wiring is accompanied by an increase in system complexity and weight, and a decrease in performance and reliability.

[0005] This section describes communication systems that provide low-latency time-division multiplex (TDM) communication over a two-wire bus (e.g., a twisted pair cable). These systems can transmit bidirectional synchronous data (e.g., digital audio), clock signals, and synchronization signals over the two-wire bus, supporting direct point-to-point connections between nodes on the bus and allowing multiple cascaded nodes at different locations to contribute or consume TDM channel content. These communication systems support downstream traffic (e.g., from a master node to a final slave node), upstream traffic (e.g., from a slave node to a master node), and power transmission over the same two-wire bus.

[0006] The following detailed description refers to the accompanying drawings, which form part thereof. In these drawings, identical numbers consistently denote identical parts, and embodiments that can be implemented are shown for illustrative purposes. It is understood that other embodiments may be used and structural or logical modifications may be made without deviating from the scope of protection of this disclosure. Therefore, the following detailed description should not be interpreted restrictively.

[0007] Various operations can be described as several discrete actions or operations performed sequentially in a manner most helpful for understanding the claimed subject matter. However, the order of description should not be interpreted as implying that these operations are necessarily sequential. In particular, these operations cannot be performed in the order presented. Described operations may be performed in a different order than the described embodiment. In additional embodiments, various additional operations may be performed and / or described operations may be omitted.

[0008] For the purposes of this disclosure, the expression “A and / or B” means (A), (B) or (A and B). For the purposes of this disclosure, the expression “A, B and / or C” means (A), (B), (C), (A and B), (A and C), (B and C) or (A, B and C).

[0009] Various components may be mentioned or represented here in the singular (e.g., a "processor", a "peripheral device", etc.), but this is only for the sake of ease of discussion, and any elements mentioned in the singular may, according to the present teachings, comprise several such elements.

[0010] The description uses the expressions "in one embodiment" or "in embodiments," which may each refer to one or more of the same or different embodiments. Furthermore, the expressions "comprising," "containing," "having," and the like, as used with reference to embodiments of the present disclosure, are synonymous. In the present usage, the term "circuits" may refer to, be part of, or comprise the following: an application-specific integrated circuit (ASIC), an electronic circuit and optical circuit, a processor (shared, dedicated, or grouped) and / or memory (shared, dedicated, or grouped) executing one or more software or firmware programs, a combinational logic circuit, and / or other suitable hardware providing the described functionality.A master node can also be referred to here as a master "device"; similarly, a slave node can be referred to here as a slave "device".

[0011] All embodiments described herein can be implemented according to any suitable related embodiments disclosed in any of the prior patent applications whose priority is claimed by the present application. In particular, any embodiment of the A2B (Automotive Audio Bus) system disclosed in any of the prior patent applications can be implemented in any combination with the embodiments described herein. For example, power switching and diagnostics can be included in the two-wire communication systems described herein, as discussed in U.S. Preliminary Application No. 61 / 845,542, filed on July 12, 2013. In another example, decoders can be included in the two-wire communication systems described herein, as discussed in U.S. Preliminary Application No. 61 / 843,902, filed on July 8, 2013.In another example, digital phase detectors can be included in the two-wire communication systems described here, as discussed in preliminary US application no. 61 / 843,896, filed on July 8, 2013. In yet another example, the two-wire communication systems described here can include the state machine functionality discussed in preliminary US application no. 61 / 843,891, filed on July 8, 2013.

[0012] Fig. Figure 1 is a block diagram of an exemplary half-duplex two-wire communication system 100 according to various embodiments. The system 100 comprises a host 110, a master node 102, and at least one slave node 104. Fig. Figure 1 shows three slave nodes (0, 1, and 2). The diagram of three slave nodes is shown in Figure 104. Fig. 1 is merely an example and the system 100 can include one, two or more slave nodes 104 as desired.

[0013] The master node 102 can communicate with the slave nodes 104 via a two-wire bus 106. The bus 106 can include various two-wire bus connections between adjacent nodes on the bus 106 to connect the nodes on the bus 106 in a cascaded manner. For example, the bus 106 can be configured as shown in Fig. Figure 1 shows a connection that couples master node 102 to slave node 0, a connection that couples slave node 0 to slave node 1, and a connection that couples slave node 1 to slave node 2. The connections of bus 106 can each consist of a single twisted pair of wires (e.g., an unshielded twisted pair of wires).

[0014] The host 110 can include a processor that programs the master node 102 and acts as the originator and receiver of various user information transmitted on the bus 106. In particular, the host 110 can be the master of I2S (Inter-Integrated Circuit Sound) communication taking place on the bus 106. The host 110 can communicate with the master node 102 via an I2S / time-division multiplex (TDM) bus and / or an I2C (Inter-Integrated Circuit) bus. In some embodiments, the master node 102 can be a transceiver (e.g., the one described below with reference to...). Fig. The master node 102 (2 discussed node transceivers 120) is located in a housing of the host 110. The master node 102 can be programmable via the I2C bus for configuration and feedback by the host 110 and can be configured to generate clock, synchronization, and framing for all slave nodes 104. In some embodiments, an extension of the I2C control bus between the host 110 and the master node 102 can be embedded in the data streams transmitted via bus 106, allowing the host 110 to directly access registers and status information for one or more slave nodes 104 and also enabling I2C-to-I2C communication over distances, allowing the host 110 to control the peripheral devices 108.

[0015] The master node 102 can generate "downstream signals" (e.g., data signals, power signals, etc., transmitted from the master node 102 on bus 106) and receive "upstream signals" (e.g., transmitted on bus 106 towards the master node 102). The master node 102 can provide a clock signal for synchronous data transmission over bus 106. In this usage, "synchronous data" can include data that is continuously streamed to / from the same node on bus 106 with a fixed time interval between two successive transmissions (e.g., audio signals). In some embodiments, the clock signal provided by the master node 102 can be derived from an I2S input provided to the master node 102 by the host 110.A slave node 104 can be an addressable network connection point representing a possible destination for data frames transmitted downstream or upstream on bus 106. A slave node 104 can also represent a possible source of downstream or upstream data frames. The system 100 can allow the transmission of control information and other data in both directions over bus 106 from one node to the next. One or more of the slave nodes 104 can also be powered by signals transmitted over bus 106.

[0016] In particular, each of the master node 102 and the slave node 104 can include a positive upstream port (referred to as "AP"), a negative upstream port (referred to as "AN"), a positive downstream port (referred to as "BP"), and a negative downstream port (referred to as "BN"). The positive and negative downstream ports of a node can be coupled to the positive and negative upstream ports, respectively, of the adjacent downstream node. As shown in Fig. As shown in Figure 1, the master node 102 can include a positive and negative upstream connection, but these connections cannot be used; in other embodiments, the master node 102 cannot include a positive and negative upstream connection. The last slave node 104 on the bus 106 (in Figure 1) Fig. 1 of the slave node 2) may include a positive and negative downstream connection, but these connections may not be used; in other embodiments, the last slave node 104 on the bus may not include a positive and negative downstream connection.

[0017] As discussed in detail below, the master node 102 can periodically send a synchronization control frame downstream, optionally along with data destined for one or more of the slave nodes 104. For example, the master node 102 can send a synchronization control frame every 1024 bits (representing a superframe) at a frequency of 48 kHz, resulting in an effective bit rate on bus 106 of 49.152 Mbps. Other rates are supported, including, for example, 44.1 kHz. The synchronization control frame can allow the slave nodes 104 to identify the beginning of each superframe and, in combination with physical layer coding / signaling, can also allow each slave node 104 to derive its internal operating clock from bus 106.The synchronization control frame can include a preamble to signal the start of synchronization, as well as control fields that encompass various addressing modes (e.g., normal, broadcast, discover), configuration information (e.g., writing to registers of slave node 104), transmission of I2C information, remote control of specific GPIO pins (general-purpose input / output) to slave node 104, and other services. A portion of the synchronization control frame following the preamble and the payload data can be scrambled to reduce the likelihood of information within the synchronization control frame being mistaken for a new preamble and to flatten the spectrum of related electromagnetic emissions.

[0018] The synchronization control frame can be forwarded between the slave nodes 104 (possibly together with other data that may come from the master node 102, but may additionally or alternatively come from one or more upstream slave nodes 104 or from a slave node 104 itself) until it reaches the last slave node 104 (i.e., slave node 2 in Fig. 1) reached by the master node 102, which has been configured as the last slave node 104 or has identified itself as the last slave node 104. Upon receiving the synchronization control frame, the last slave node 104 can send a synchronization response frame, followed by any data it is permitted to transmit (e.g., a 24-bit audio sample in a designated timeslot). The synchronization response frame can then be forwarded upstream between slave nodes 104 (possibly along with data from downstream slave nodes 104), and based on the synchronization response frame, each slave node 104 can identify any timeslot in which it is permitted to transmit.

[0019] In some embodiments, one or more of the slave nodes 104 in the system 100 can be coupled to and communicate with a peripheral device 108. For example, a slave node 104 can be configured to read data from and / or write data to the associated peripheral device 108 using I2S, pulse density modulation (PDM), TDM, and / or I2C protocols, as discussed below. Although the "peripheral device" 108 can be referred to here in the singular, this is simply for ease of discussion, and a single slave node 104 can be coupled to zero, one, or more peripheral devices.Examples of peripheral devices that may be included in the peripheral device 108 would be a DSP (digital signal processor), an FPGA (field programmable gate array), an ASIC (application-specific integrated circuit), an ADC (analog-to-digital converter), a DAC (digital-to-analog converter), a codec, a microphone, a microphone array, a loudspeaker, an audio amplifier, a protocol analyzer, an accelerometer or other motion sensor, an environmental condition sensor (e.g., a temperature, humidity, and / or gas sensor), a wired or wireless communication transceiver, a display device (e.g., a touchscreen display), a user interface component (e.g., a button, a dial, or other control element), a camera (e.g., a video camera), a storage device, or any other suitable device that transmits and / or receives data.Several examples of different peripheral device configurations are discussed in detail here.

[0020] In some embodiments, the peripheral device 108 can comprise any device configured for I2S (Inter-Integrated Circuit Sound) communication; the peripheral device 108 can communicate with the associated slave node 104 via the I2S protocol. In some embodiments, the peripheral device 108 can comprise any device configured for I2C (Inter-Integrated Circuit) communication; the peripheral device 108 can communicate with the associated slave node 104 via the I2C protocol. In some embodiments, a slave node 104 may not be coupled to any peripheral device 108.

[0021] A slave node 104 and its associated peripheral device 108 can be contained in separate housings and coupled by means of a wired or wireless communication link, or they can be contained in a common housing. For example, a loudspeaker connected as a peripheral device 108 can be housed together with the hardware for an associated slave node 104 (e.g., the one described below with reference to Fig. The two discussed node transceivers 120) are enclosed, so that the hardware for the associated slave node 104 is contained in an enclosure that also contains other loudspeaker components. The same can apply to any type of peripheral device 108.

[0022] As discussed above, host 110 can communicate with and control master node 102 using multi-channel I2S and I2C communication protocols. Specifically, host 110 can send data via I2S to a frame buffer (not shown) in master node 102, and master node 102 can read data from the frame buffer and send the data on bus 106. Similarly, master node 102 can store data received via bus 106 in the frame buffer and then send the data to host 110 via I2S.

[0023] Each slave node 104 can have internal control registers that can be configured by transmissions from the master node 102. Several such registers are discussed in detail below. Each slave node 104 can receive downstream data and forward the data further downstream. Each slave node 104 can receive and / or generate upstream data and / or forward data upstream and / or add data to an upstream transaction.

[0024] Communication on bus 106 can occur in periodic superframes. Each superframe can begin with a downstream synchronization control frame; be divided into periods of downstream transmission (also called "downstream parts"), upstream transmission (also called "upstream parts"), and no transmission (during which bus 106 is not driven); and end shortly before the transmission of another downstream synchronization control frame. The master node 102 can be programmed (by the host 110) with a number of downstream parts to be sent to one or more of the slave nodes 104 and a number of upstream parts to be received by one or more of the slave nodes 104.Each slave node 104 can be programmed (by the master node 102) with a number of downstream parts to be forwarded down the bus 106, a number of downstream parts to be consumed, a number of upstream parts to be forwarded up the bus 106, and a number of upstream parts in which the slave node 104 can send data received from the associated peripheral device 108. Communication on the bus 106 is described in more detail below with reference to... Fig. 2-12 discussed.

[0025] Each of the master node 102 and the slave node 104 can include a transceiver for managing communication between components of the system 100. Fig. Figure 2 is a block representation of a node-transmitter 120 located in a node (e.g., the master node 102 or a slave node 104) of the system 100. Fig. 1 may be included, according to various embodiments. In some embodiments, each of the nodes of the system 100 may contain a node transceiver 120, and a control signal may be supplied to the node transceiver 120 via a master or MSTR pin to indicate whether the node transceiver 120 should act as a master (e.g., when the MSTR pin is high) or slave (e.g., when the MSTR pin is low).

[0026] The node transceiver 120 can comprise an upstream transceiver 122 and a downstream transceiver 124. The upstream transceiver 122 can be connected to the above with reference to Fig. The positive and negative upstream connections discussed above are coupled, and the downstream transceiver 124 can be connected to the above with reference to Fig. The positive and negative downstream connections discussed in section 1 are coupled. In some embodiments, the upstream transceiver 122 and the downstream transceiver 124 can each be differential signaling or DS transceivers. In some embodiments, the upstream transceiver 122 can be a low-voltage DS or LVDS transceiver, and the downstream transceiver 124 can be an LVDS transceiver. Each node in the system 100 can be AC-coupled to the bus 106, and data signals can be transmitted on the bus 106 (e.g., via the upstream transceiver 122 and / or the downstream transceiver 124) using a predetermined form of DS (e.g., LVDS or multipoint LVDS (MLVDS) or similar signaling) with appropriate encoding to provide timing information over the bus 106 (e.g.,Differential Manchester coding, biphase marker coding, Manchester coding, NRZI coding (Non-Return-To-Zero, Inverted) with run-length limitation, or any other suitable coding may be transmitted. In some embodiments, the bus 106 may be provided by a coaxial cable, and the upstream and downstream signals may be asymmetric signals driving the coaxial cable.

[0027] The upstream transceiver 122 and the downstream transceiver 124 can communicate with the bus protocol circuit 126, and the bus protocol circuit 126 can communicate with a phase-locked loop (PLL) 128 and a voltage regulator circuit 130, among other components. When the node transceiver 120 is powered up, the voltage regulator circuit 130 can set a "power supply good" signal, which is used by the PLL 128 as a power-on reset.

[0028] As mentioned above, one or more of the slave nodes 104 in the system 100 can receive power, which is simultaneously transmitted along with data over the bus 106. For power distribution (which is optional, as some of the slave nodes 104 may be designed to be supplied with local power only), the master node 102 can apply a DC bias to the bus connection between the master node 102 and slave node 0 (e.g., by connecting one of the downstream terminals to a voltage source provided by a voltage regulator and the other downstream terminal to ground). The DC bias can be a predetermined voltage, such as 5 V, 8 V, the voltage of a car battery, or a higher voltage. Each successive slave node 104 can selectively tap its upstream bus connection to recover power (e.g., using the voltage regulator circuit 130).This power supply can power the slave node 104 itself (and optionally one or more peripheral devices 108 coupled to the slave node 104). A slave node 104 can also selectively bias the downstream bus connection for the next slave node 104 in the series, either with the recovered power from the upstream bus connection or from a local power supply. For example, slave node 0 can use the DC bias on the upstream bus connection 106 to recover power for slave node 0 itself and / or for one or more associated peripheral devices 108, and / or slave node 0 can recover power from its upstream bus connection 106 to bias its downstream bus connection 106.

[0029] In some embodiments, each node in the system 100 can thus supply power to the next downstream node via a downstream bus connection. The power supply to nodes can be performed in a sequenced manner. For example, after discovering and configuring slave node 0 via bus 106, the master node 102 can instruct slave node 0 to supply power to its downstream bus connection 106 to power slave node 1; after slave node 1 is discovered and configured, the master node 102 can instruct slave node 1 to supply power to its downstream bus connection 106 to power slave node 2 (and so on for additional slave nodes 104 connected to bus 106). In some embodiments, one or more of the slave nodes 104 can be powered locally, instead of being powered from or in addition to their upstream bus connection.In some such embodiments, the local power source for a given slave node 104 can supply power to one or more downstream slave nodes.

[0030] In some embodiments, an upstream filtering circuit 132 can be arranged between the upstream transceiver 122 and the voltage regulator circuits 130, and a downstream filtering circuit 131 can be arranged between the downstream transceiver 124 and the voltage regulator circuits 130. Since each connection of the bus 106 can carry AC (signal) and DC (power supply) components, the upstream filtering circuit 132 and the downstream filtering circuit 131 can separate the AC and DC components, supplying the AC components to the upstream transceiver 122 and the downstream transceiver 124, and supplying the DC components to the voltage regulator 130.AC couplings on the line side of the upstream transceiver 122 and downstream transceiver 124 essentially isolate the transceivers 122 and 124 from the DC component on the line to allow fast bidirectional communication. As discussed above, the DC component can be tapped for power supply, and the upstream filtering circuit 132 and the downstream filtering circuit 131 can, for example, include a ferrite, a common-mode choke, or an inductor to reduce the AC component supplied to the voltage regulator circuit 130. In some embodiments, the upstream filtering circuit 132 can be contained within the upstream transceiver 122, and / or the downstream filtering circuit 131 can be contained within the downstream transceiver 124; in other embodiments, the filtering circuit can be located outside the transceivers 122 and 124.Return current can be provided by the upstream filtering circuit 122 and the downstream filtering circuit 131 via a VSSN connection, which can be connected to VSS (e.g., ground) through the node transceiver 120. The upstream filtering circuit 132 and the downstream filtering circuit 131 can include DC connections for both the power and return current connections.

[0031] The node transceiver 120 can include a transceiver 127 for I2S, TDM, and PDM communication between the node transceiver 120 and an external device 155. Although the "external device 155" can be referred to here in the singular, this is simply for the sake of clarity, and multiple external devices can communicate with the node transceiver 120 via the I2S / TDM / PDM transceiver 127. As is known in the art, the I2S protocol is used to transmit pulse-code modulated or PCM information (e.g., between audio chips on a printed circuit board). In this usage, "I2S / TDM" can refer to an extension of the I2S stereo (two-channel) content to multiple channels using TDM. As is known in engineering, PDM can be used in sigma-delta converters, and in particular, the PDM format can represent an oversampled 1-bit sigma-delta ADC signal before decimation.The PDM format is often used as the output format for digital microphones. The I2S / TDM / PDM transceiver 127 can communicate with the bus protocol circuit 126 and pins for communication with the external device 155. Fig. Figure 2 shows six pins: BCLK, SYNC, DTX[1:0], and DRX[1:0]. The BCLK pin can be used for a 12S-bit clock, the SYNC pin can be used for a 12S frame synchronization signal, and the DTX[1:0] and DRX[1:0] pins are used for sending and receiving data channels, respectively. Although in Fig. Since two transmit pins (DTX[1:0]) and two receive pins (DRX[1:0]) are shown, any desired number of receive and / or transmit pins can be used.

[0032] If the node transceiver 120 is contained within the master node 102, the external device 155 can include the host 110, and the I2S / TDM / PDM transceiver 127 can (with respect to BCLK and SYNC) provide an I2S slave that can receive data from the host 110 and transmit data synchronously to the host 110 using an I2S interface clock signal from the host 110. Specifically, an I2S frame synchronization signal can be received at the SYNC pin as input from the host 110, and the PLL 128 can generate clocks using this signal. If the node transceiver 120 is contained in a slave node 104, the external device 155 can include one or more peripheral devices 108, and the I2S / TDM / PDM transceiver 127 can provide an I2S clock master (for BCLK and SYNC) that can control I2S communication with the peripheral device 108. In particular, the I2S / TDM / PDM transceiver 127 can provide a 12S frame synchronization signal at the SYNC pin as an output.Registers in the node transceiver 120 can determine which and how many I2S / TDM channels are transmitted as data slots over bus 106. A register for the TDM mode (TDMMODE) in the node transceiver 120 can store a value indicating how many TDM channels fit between successive SYNC pulses on a TDM transmit or receive pin. Knowing the channel size, the node transceiver 120 can automatically set the BCLK rate to match the number of bits in the sampling time (e.g., 48 kHz).

[0033] The node transceiver 120 can include a transceiver 129 for I2C communication between the node transceiver 120 and an external device 157. Although the "external device 157" can be referred to here in the singular, this is only for ease of presentation, and multiple external devices can communicate with the node transceiver 120 via the I2C transceiver 129. As is known in the art, the I2C protocol uses clock (SCL) and data (SDA) lines to provide data transfer. The I2C transceiver 129 can communicate with the external device 157 via the bus protocol circuit 126 and pins. Fig. Figure 2 shows four pins: ADR1, ADR2, SDA, and SCL. ADR1 and ADR2 can be used to modify the I2C addresses used by node 120 when it acts as an I2C slave (e.g., when it is contained within master node 102). SDA and SCL are used for the serial data and serial clock signals of I2C, respectively. When node 120 is contained within master node 102, external device 157 can include host 110, and I2C 129 can provide an I2C slave capable of receiving programming instructions from host 110. In particular, a serial I2C clock signal can be received at the SCL pin as input from host 110 for register accesses.If the node transceiver 120 is contained within a slave node 104, the external device 157 can include a peripheral device 108, and the I2C transceiver 129 can provide an I2C master to allow the I2C transceiver to program one or more peripheral devices according to instructions provided by the host 110 and sent to the node transceiver 120 via the bus 106. In particular, the I2C transceiver 129 can provide the serial I2C clock signal at the SCL pin as an output.

[0034] The node transceiver 120 can include an interrupt request (IRQ) pin for communication with the bus protocol circuit 126. If the node transceiver 120 is contained in the master node 102 via the I2C transceiver 129, the bus protocol circuit 126 can provide event-driven interrupt requests to the host 110 via the IRQ pin. If the node transceiver 120 is contained in a slave node 104 (e.g., if the MSTR pin is low), the IRQ pin can function as a GPIO pin with interrupt request capability.

[0035] System 100 can operate in any number of different operating modes. Each node on bus 106 can have a register indicating which operating mode is currently enabled. The following are descriptions of examples of different operating modes that can be implemented. In a standby mode, bus activity is reduced to enable global power savings; the only traffic required is a minimal downstream preamble to keep each node's PLL (e.g., PLL 128) synchronized. Read and write operations over bus 106 are not supported in standby mode. In a discovery mode, the master node 102 can send predefined signals on bus 106 and wait for appropriate responses to map the topology of the slave nodes 104 distributed on bus 106.In normal operating mode, full register access to and from the slave nodes 104, as well as access to and from peripheral devices 108 via bus 106, is available. Normal mode can be globally configured by the host 110 with or without synchronous upstream data and with or without synchronous downstream data.

[0036] Fig. Figure 3 shows a portion of a synchronization control frame 180 used for communication in the system 100, according to various embodiments. In particular, the synchronization control frame 180 can be used for data clock recovery and PLL synchronization, as discussed below. Since communication over the bus 106 can occur in both directions, communication can be time-multiplexed to downstream and upstream portions, as mentioned above. In a downstream portion, a synchronization control frame and downstream data can be sent from the master node 102, while in an upstream portion, a synchronization response frame and upstream data can be sent from each of the slave nodes 104 to the master node 102. The synchronization control frame 180 can include a preamble 182 and control data 184.Each slave node 104 can be configured to use the preamble 182 of the received synchronization control frame 180 as the time base for feeding the PLL 128. To enable this, a preamble 182 does not follow the "rules" of valid control data 184 and can therefore be easily distinguished from the control data 184.

[0037] For example, in some embodiments, communication on bus 106 can be encoded using a differential Manchester coding scheme of the clock-first, transition at zero type. According to such a coding scheme, each bit time begins with a clock transition. If the data value is zero, the encoded signal transitions again in the middle of the bit time. If the data value is one, the encoded signal does not transition again. The in Fig. The preamble 182 shown in Figure 5 may violate the coding protocol (e.g., by having clock transitions that do not occur at the beginning of bit times 5, 7, and 8), which means that the preamble 182 cannot match any legal (e.g., correctly encoded) pattern for the control data 184. Furthermore, the preamble 182 cannot be reproduced by taking a legal pattern of the control data 184 and forcing bus 106 high or low for a single-bit or multiple-bit duration. The in Fig. The preamble 182 shown in section 5 is merely exemplary, and the synchronization control framework 180 may include other preambles 182 which may violate the encoding used by the control data 184 in any suitable manner.

[0038] The bus protocol circuit 126 can include a differential Manchester decoder circuit running on a clock recovered from the bus 106, which detects the synchronization control frame 180 in order to send a frame SYNC indicator to the PLL 128. In this way, the synchronization control frame 180 can be detected without using a system clock or a faster oversampling clock. Consequently, the slave nodes 104 can receive a PLL synchronization signal from the bus 106 without requiring a crystal clock source at the slave nodes 104.

[0039] As mentioned previously, communication on bus 106 can occur in periodic superframes. Fig. Figure 4 is a representation of a superframe 190 according to various embodiments. As in Fig. As shown in Figure 4, a superframe can begin with a synchronization control frame 180. If the synchronization control frame 180 is used as the timing source for the PLL 128, the frequency at which superframes are transmitted (“the superframe frequency”) can be the same as the synchronization signal frequency. In some embodiments where audio data is transmitted on the bus 106, the superframe frequency can be the same as the audio sampling frequency used in the system 100 (e.g., either 48 kHz or 44.1 kHz), but any suitable superframe frequency can be used. Each superframe 190 can be divided into downstream transmission periods 192, upstream transmission periods 194, and no-transmission periods 196 (e.g., when the bus 106 is not driven).

[0040] In Fig. Figure 4 shows the superframe 190 with an initial downstream transmission period 192 and a subsequent upstream transmission period 194. The downstream transmission period 192 can include a synchronization control frame 180 and X downstream data slots 198, where X can be zero. Essentially, all signals on the bus 106 can be line-coded, and a synchronization signal is transmitted downstream from the master node 102 to the last slave node 104 (e.g., slave node 2 in the diagram). Fig. 1) in the form of the synchronization preamble 182 in the synchronization control frame 180, as discussed above. Downstream, synchronous TDM data can be contained in the X downstream data slots 198 following the synchronization control frame 180. The downstream data slots 198 can be of equal width. As discussed above, the PLL 128 can provide the clock that a node uses to time communication over the bus 106. In some embodiments where the bus 106 is used to transmit audio data, the PLL 128 can operate at a multiple of the audio sampling rate (e.g., 1024 times the audio sampling rate, resulting in 1024-bit clocks in each superframe).

[0041] The upstream transmission period 194 can include a synchronization response frame 197 and Y upstream data slots 199, where Y can be zero. In some embodiments, each slave node 104 can consume a portion of the downstream data slots 198. The last slave node (e.g., slave node 2 in Fig. 1) can respond (after a predetermined response time stored in a register of the last slave node) with a synchronization response frame 197. Upstream, synchronous TDM data can be added by any slave node 104 in the upstream data slots 199 directly after the synchronization response frame 197. The upstream data slots 199 can be of equal width. A slave node 104 that is not the last slave node (e.g., slave nodes 0 and 1 in Fig. 1) can replace the received synchronization response frame 197 with its own upstream response if a read of one of its registers has been requested in the synchronization control frame 180 of the superframe 190, or if a remote I2C read has been requested in the synchronization control frame 180 of the superframe 190.

[0042] The synchronization control frame 180 can initiate any downstream transmission, as discussed above. In some embodiments, the synchronization control frame 180 can be 64 bits long, but any other suitable length can be used. The synchronization control frame 180 can begin with the preamble 182, as mentioned above. In some embodiments, when the synchronization control frame 180 is forwarded by a slave node 104 to a downstream slave node 104, the preamble 182 can be generated by the sending slave node 104 instead of being retransmitted.

[0043] The control data 184 of the synchronization control frame 180 can include fields containing data used to control transactions over bus 106. Examples of these fields are discussed below, and some embodiments are described in Fig. 5 shown. In particular, it shows Fig. Five exemplary formats for the synchronization control frame 180 in normal mode, I2C mode, and discovery mode according to various embodiments. In some embodiments, a completely different preamble 182 or a completely different synchronization control frame 180 can be used in standby mode, so that the slave nodes 104 only need to receive the entire synchronization control frame 180 when a transition to normal mode is sent.

[0044] In some embodiments, the synchronization control frame 180 can include a counter or CNT field. The CNT field can have any suitable length (e.g., 2 bits) and can be incremented (modulo the length of the field) from the value used in the previous superframe. A slave node 104 that receives an unexpected CNT value can be programmed to return an interrupt.

[0045] In some embodiments, the synchronization control frame 180 may include a node addressing mode or NAM field. The NAM field may have any suitable length (e.g., 2 bits) and may be used to control access to registers of a slave node 104 via the bus 106. In normal mode, registers of a slave node 104 may be read and / or written based on the ID of the slave node 104 and the address of the register. Broadcast transactions are write operations that should be performed by every slave node 104. In some embodiments, the NAM field can provide four node addressing modes, including "none" (e.g., data not addressed to any specific slave node 104), "normal" (e.g., data unicast to a specific slave node 104 specified in the address field discussed below), "broadcast" (e.g., addressed to all slave nodes 104), and "discovery".

[0046] In some embodiments, the synchronization control frame 180 can include an I2C field. The I2C field can have any suitable length (e.g., 1 bit) and can be used to indicate that the period of the downstream transmission 192 includes an I2C transaction. The I2C field can indicate that the host 110 has issued instructions to remotely access a peripheral device 108, which acts as an I2C slave with respect to an associated slave node 104.

[0047] In some embodiments, the synchronization control frame 180 can include a node field. The node field can have any suitable length (e.g., 4 bits) and can be used to specify which slave node is addressed for normal and I2C accesses. In discovery mode, this field can be used to program an identifier for a newly discovered slave node 104 in a node ID register of the slave node 104. Each slave node 104 in the system 100 can be assigned a unique ID when the slave node 104 is discovered by the master node 102, as discussed below. In some embodiments, the master node 102 does not have a node ID, while in other embodiments, the master node 102 may have a node ID. In some embodiments, the slave node 104 (e.g., slave node 0 in) connected to the master node 102 on bus 106 is Fig. 1) Slave node 0 and each successive slave node 104 has a number that is 1 greater than that of the previous slave node. However, this is only an example, and any suitable slave node identification system can be used.

[0048] In some embodiments, the synchronization control frame 180 can include a read / write or RW field. The RW field can have any suitable length (e.g., 1 bit) and can be used to control whether normal accesses are read operations (e.g., RW==1) or write operations (e.g., RW==0).

[0049] In some embodiments, the synchronization control frame 180 can include an address field. The address field can have any suitable length (e.g., 8 bits) and can be used to address specific registers of a slave node 104 via the bus 106. For I2C transactions, the address field can be replaced with I2C control values, such as START / STOP, WAIT, RW, and DATA VLD. For discovery transactions, the address field can have a predetermined value (e.g., as in Fig. 5 shown).

[0050] In some embodiments, the synchronization control frame 180 can include a data field. The data field can be of any suitable length (e.g., 8 bits) and can be used for normal, I2C, and broadcast writes. The RESPCYCS value, multiplied by 4, can be used to determine how many cycles of a newly discovered node should elapse between the start of receiving the synchronization control frame 180 and the start of sending the synchronization response frame 197. If the NAM field specifies discovery mode, the node address and data fields discussed below can be encoded as a single RESPCYCS value which, when multiplied by a suitable optional multiplier (e.g., 4), specifies the time in bits from the end of the synchronization control frame 180 to the start of the synchronization response frame 197.This allows a newly discovered slave node 104 to determine the correct timeslot for upstream transmission.

[0051] In some embodiments, the synchronization control frame 180 may include a cyclic redundancy check (CRC) field. The CRC field may have any suitable length (e.g., 16 bits) and may be used to send a CRC value for the control data 184 of the synchronization control frame 180 according to the preamble 182. In some embodiments, the CRC may be calculated according to the CCITT CRC error detection scheme.

[0052] In some embodiments, at least a portion of the synchronization control frame 180 between the preamble 182 and the CRC field can be scrambled to reduce the probability that a sequence of bits in this interval periodically coincides with the preamble 182 (and thus can be misinterpreted by the slave node 104 as the beginning of a new superframe 190), and also to reduce electromagnetic emissions as mentioned above. In some such embodiments, the CNT field of the synchronization control frame 180 can be used by scrambling logic to ensure that the scrambled fields are scrambled differently from one superframe to the next. Various embodiments of the system 100 described here can omit the scrambling.

[0053] Other techniques can be used to ensure that the preamble 182 can be uniquely identified by the slave nodes 104, or to reduce the probability of the preamble 182 appearing elsewhere in the synchronization control frame 180, in addition to or instead of techniques such as scrambling and / or error coding as discussed above. For example, a longer synchronization sequence can be used to reduce the probability that a particular encoding of the rest of the synchronization control frame 180 will match it. Additionally or alternatively, the rest of the synchronization control frame can be structured so that the synchronization sequence cannot occur, such as by placing fixed "0" or "1" values ​​at appropriate bits.

[0054] The master node 102 can send read and write requests to the slave nodes 104, including both bus 106-specific requests and I2C requests. For example, the master node 102 can send read and write requests (specified using the RW field) (using the NAM and node fields) to one or more designated slave nodes 104 and can specify whether the request is a bus 106-specific request for the slave node 104, an I2C request for the slave node 104, or an I2C request to be forwarded to an I2C-compatible peripheral device 108 connected to the slave node 104 via one or more I2C ports of the slave node 104.

[0055] Now, with reference to upstream communication, the synchronization response frame 197 can initiate any upstream transmission. In some embodiments, the synchronization response frame 197 can have a length of 64 bits, but any other suitable length can be used. The synchronization response frame 197 can also include a preamble, as discussed above with reference to the preamble 182 of the synchronization control frame 180, followed by a data portion. At the end of a downstream transmission, the last slave node 104 on the bus 106 can wait until the RESPCYCS counter has expired and then begin transmitting a synchronization response frame 197 upstream. If an upstream slave node 104 has become the target of a normal read or write transaction, a slave node 104 can generate its own synchronization response frame 197 and replace the one received downstream.If any slave node 104 does not see a synchronization response frame 197 from a downstream slave node 104 at the expected time, the slave node 104 generates its own synchronization response frame 197 and begins sending it upstream.

[0056] The data portion of the synchronization response frame 197 can include fields containing data used to transmit response information back to the master node 102. Examples of these fields are discussed below and in Fig. Figure 6 shows some embodiments. In particular, it shows Fig. 6 exemplary formats for the synchronization response frame 197 in normal mode, I2C mode and discovery mode according to different embodiments.

[0057] In some embodiments, the synchronization response frame 197 can include a count or CNT field. The CNT field can have any suitable length (e.g., 2 bits) and can be used to transmit the value of the CNT field in the previously received synchronization control frame 180.

[0058] In some embodiments, the synchronization response frame 197 can include an acknowledgment or ACK field. The ACK field can be of any suitable length (e.g., 2 bits) and can be inserted by a slave node 104 to acknowledge a command received in the previous synchronization control frame 180 when that slave node 104 generates the synchronization response frame 197. Exemplary indicators that can be transmitted in the ACK field would be Wait, Acknowledge, Nonacknowledge (NACK), and Retry. In some embodiments, the ACK field can be sized to transmit an acknowledgment by a slave node 104 that it has received and processed a broadcast message (e.g., by sending a broadcast acknowledgment to the master node 102).In some embodiments, a slave node 104 can also indicate whether the slave node 104 has data to send (which could be used, for example, for on-demand upstream transmissions, such as non-TDM inputs from a keypad or touchscreen, or for prioritized upstream transmission, such as when the slave node 104 wants to report an error or emergency condition).

[0059] In some embodiments, the synchronization response frame 197 can include an I2C field. The I2C field can have any suitable length (e.g., 1 bit) and can be used to transmit the value of the I2C field in the previously received synchronization control frame 180.

[0060] In some embodiments, the synchronization response frame 197 can comprise a node array. The node array can have any suitable length (e.g., 4 bits) and can be used to send the ID of the slave node 104 that generates the synchronization response frame 197.

[0061] In some embodiments, the synchronization response frame 197 can include a data field. The data field can be of any suitable length (e.g., 8 bits), and its value can depend on the type of transaction and the ACK response of the slave node 104 that generates the synchronization response frame 197. For discovery transactions, the data field can include the value of the RESPCYCS field in the previously received synchronization control frame 180. If the ACK field indicates a NACK, or if the synchronization response frame 197 responds to a broadcast transaction, the data field can contain a broadcast acknowledgment or BA indicator (in which the last slave node 104 can indicate whether the broadcast write was received without errors), a discovery error or DER indicator (which indicates whether a newly discovered slave node 104 in a discovery transaction matches an existing slave node 104), and a CRC error orIncludes the CER indicator (which indicates whether a NACK was caused by a CRC error).

[0062] In some embodiments, the synchronization response frame 197 may include a CRC field. The CRC field may be of any suitable length (e.g., 16 bits) and may be used to send a CRC value for the portion of the synchronization response frame 197 between the preamble and the CRC field.

[0063] In some embodiments, the synchronization response frame 197 can include an interrupt request or IRQ field. The IRQ field can have any suitable length (e.g., 1 bit) and can be used to indicate that an interrupt has been signaled by a slave node 104.

[0064] In some embodiments, the synchronization response frame 197 can include an IRQ node field. The IRQNODE field can have any suitable length (e.g., 4 bits) and can be used to send the ID of the slave node 104 that signaled the interrupt presented by the IRQ field. In some embodiments, the slave node 104 inserts its own ID into the IRQNODE field to generate the IRQ field.

[0065] In some embodiments, the synchronization response frame 197 can include a second CRC or CRC-4 field. The CRC-4 field can have any suitable length (e.g., 4 bits) and can be used to send a CRC value for the IRQ and IRQNODE fields.

[0066] In some embodiments, the synchronization response frame 197 can include an IRQ field, an IRQNODE field, and a CRC-4 field as the last bits of the synchronization response frame 197 (e.g., the last 10 bits). As discussed above, these interrupt-related fields can have their own CRC protection in the form of CRC-4 (and thus not be protected by the preceding CRC field). Each slave node 104 that needs to signal an interrupt to the master node 102 inserts its interrupt information into these fields. In some embodiments, a slave node 104 with a pending interrupt can have a higher priority than any further downstream slave node 104 that also has a pending interrupt. The last slave node 104 on bus 106 (e.g., slave node 2 in Fig. 1) can always populate these interrupt fields. If the last slave node 104 has no interrupt pending, the last slave node 104 can set the IRQ bit to zero and the IRQNODE field to its node ID and provide the correct CRC-4 value. For convenience, a synchronization response frame 197 that transmits an interrupt can be referred to here as an "interrupt frame".

[0067] In some embodiments, at least a portion of the synchronization response frame 197 between the preamble 182 and the CRC field can be scrambled to reduce emissions. In some such embodiments, the CNT field of the synchronization response frame 197 can be used by scrambling logic to ensure that the scrambled fields are scrambled differently from one superframe to the next. Various embodiments of the system 100 described here can omit the scrambling.

[0068] Other techniques can be used to ensure that the preamble 182 can be uniquely identified by the slave nodes 104, or to reduce the probability of the preamble 182 appearing elsewhere in the synchronization response frame 197, in addition to or instead of techniques such as scrambling and / or error coding as discussed above. For example, a longer synchronization sequence can be used to reduce the probability that a particular encoding of the remainder of the synchronization control frame 180 will match it. Additionally, or alternatively, the remainder of the synchronization response frame can be structured so that the synchronization sequence cannot occur, such as by placing fixed "0" or "1" values ​​on appropriate bits.

[0069] Fig. Figure 7 is a block diagram of the bus protocol circuit 126 of Fig. 2 according to various embodiments. The bus protocol circuit 126 can include a control circuit 154 for controlling the operation of the node transceiver 120 according to the protocol described here for the bus 106. In particular, the control circuit 154 can control the generation of synchronization frames for transmission (e.g., synchronization control frames or synchronization response frames as discussed above), the processing of received synchronization frames, and the execution of control operations specified in received synchronization control frames. The control circuit 154 can include programmable registers, as discussed below. The control circuit 154 can generate and receive synchronization control frames suitable for received messages (e.g.,are assigned to a synchronization control frame if the bus protocol circuit 126 is contained in a slave node 104, or from an I2C device if the bus protocol circuit 126 is contained in a master node 102) and adjust the framing to the different operating modes (e.g. normal, discovery, standby, etc.).

[0070] When the node transmit-receiver 120 creates data for transmission on bus 106, the preamble circuit 156 can be configured to generate preambles for synchronization frames for transmission and to receive preambles of received synchronization frames. In some embodiments, a downstream synchronization control frame preamble can be sent by the master node 102 every 1024 bits. As discussed above, one or more slave nodes 104 can synchronize with the downstream synchronization control frame preamble and generate local phase-synchronized master clocks from the preamble.

[0071] The circuit 158 ​​for inserting cyclic redundancy checks (CRC) can be configured to generate one or more CRCs for synchronization frames for transmission. A frame / compression circuit 160 can be configured to take incoming data from the I2S / TDM / PDM transceiver 127 (e.g., from a frame buffer associated with the transceiver 127) and / or the I2C transceiver 129, optionally compress the data, and optionally generate parity check bits or error correction codes (ECC) for the data. A multiplexer (MUX) 162 can multiplex a preamble from the preamble circuit 156, synchronization frames, and data into a single stream for transmission. In some embodiments, the transmission stream can be scrambled by a scrambling circuit 164 before transmission.

[0072] For example, in some embodiments, the frame / compression circuit 160 can apply a floating-point compression scheme. In such an embodiment, the control circuit 154 can transmit 3 bits to indicate how many repeated sign bits are in the number, followed by a sign bit and N-4 data bits, where N is the size of the data to be transmitted over bus 106. The use of data compression can be configured by the master node 102, if desired.

[0073] In some embodiments, the receive stream entering the node transceiver 120 can be demultiplexed by the design circuit 166. A demultiplexer (DEMUX) 168 can demultiplex the preamble, synchronization frames, and data from the receive stream. A CRC check circuit 159 on the receive side can check received synchronization frames for correct CRC. If the CRC check circuit 159 identifies a CRC error in an incoming synchronization control frame 180, the control circuit 154 can be notified of the error and will not execute any control commands in the control data 184 of the synchronization control frame 180. If the CRC check circuit 159 identifies a CRC error in an incoming synchronization response frame 197, the control circuit 154 can be notified of the error and can generate an interrupt to transmit to the host 110 in an interrupt frame.A deframe / decompression circuit 170 can accept received data, check its parity if necessary, perform error detection and correction if necessary (e.g. single error correction - double error detection (SECDED)), decompress the data if necessary, and write the received data to the I2S / TDM / PDM transceiver 127 (e.g. a frame buffer assigned to the transceiver 127) and / or the I2C transceiver 129.

[0074] As discussed above, upstream and downstream data on bus 106 can be transmitted in TDM data slots in a superframe 190. The control circuit 154 can include registers dedicated to managing these data slots on bus 106, several examples of which are discussed below. If the control circuit 154 is contained in a master node 102, the values ​​in these registers can be programmed into the control circuit 154 by the host 110. If the control circuit 154 is contained in a slave node 104, the values ​​in these registers can be programmed into the control circuit 154 by the master node 102.

[0075] In some embodiments, the control circuit 154 may include a downstream slots (DNSLOTS) register. If the node transceiver 120 is contained in the master node 102, this register may hold the values ​​of the total number of downstream data slots. This register may also define the number of data slots used for combined I2S / TDM / PDM reception by the I2S / TDM / PDM transceiver 127 in the master node 102. In a slave node 104, this register may define the number of data slots routed downstream to the next slave node 104 before or after locally generated downstream slots are added, as discussed in more detail below with reference to LDNSLOTS.

[0076] In some embodiments, the control circuit 154 may include a register of local downstream slots (LDNSLOTS). This register may be unused in the master node 102. In a slave node 104, this register may define the number of data slots that the slave node 104 will use and not forward. Alternatively, this register may define the number of slots that the slave node 104 can contribute to the downstream data path 106.

[0077] In some embodiments, the control circuit 154 may include an upstream slots (UPSLOTS) register. In the master node 102, this register may hold the value of the total number of upstream data slots. This register may also define the number of slots used by the I2S / TDM / PDM transceiver 127 in the master node 102 for I2S / TDM transmission. In a slave node 104, this register may define the number of data slots that are passed upstream before the slave node 104 begins adding its own data.

[0078] In some embodiments, the control circuit 154 may include a register of local upstream slots (LUPSLOTS). This register may be unused in the master node 102. In a slave node 104, this register may define the number of data slots that the slave node 104 adds to the data received downstream before sending it upstream. This register may also define the number of data slots used for combined I2S / TDM / PDM reception by the I2S / TDM / PDM transceiver 127 in the slave node 104.

[0079] In some embodiments, the control circuit 154 may include a register for broadcast downstream slots (BCDNSLOTS). This register may be unused in the master node 102. In a slave node 104, this register may define the number of broadcast data slots. In some embodiments, broadcast data slots may always be at the beginning of the data array. The data in the broadcast data slots may be used by multiple slave nodes 104 and may be passed downstream through all slave nodes 104, whether they are used or not.

[0080] In some embodiments, the control circuit 154 may include a slot format register (SLOTFMT). This register can define the format of data for upstream and downstream transmissions. The data size for the I2S / TDM / PDM transceiver 127 may also be determined by this register. In some embodiments, valid data sizes include 8, 12, 16, 20, 24, 28, and 32 bits. This register may also include bits for enabling floating-point compression for downstream and upstream traffic. When floating-point compression is enabled, the I2S / TDM data size can be 4 bits larger than the data size over the bus 106. All nodes in the system 100 can have the same SLOTFMT values ​​when data slots are enabled, and the nodes can be programmed by a broadcast write operation so that all nodes are updated with the same value.

[0081] Fig. Figures 8-11 show examples of information exchange on bus 106 according to different embodiments of the bus protocols described here. In particular, they show Fig. 8-11 Embodiments in which each slave node 104 is coupled to one or more loudspeakers and / or one or more microphones as the peripheral device 108. This is merely an example, since any desired arrangement of the peripheral device 108 can be coupled to any particular slave node 104 according to the techniques described herein.

[0082] To begin, it shows Fig. 8 Signaling and timing considerations for bidirectional communication on bus 106 according to various embodiments. The in Fig. The eight depicted slave nodes 104 have different numbers of sensor / actuator elements, and thus different amounts of data can be sent to or received from the various slave nodes 104. Specifically, slave node 1 has two elements, slave node 4 has four elements, and slave node 5 has three elements, so that the data transmitted by the master node 102 comprises two time slots for slave node 1, four time slots for slave node 4, and three time slots for slave node 5. Similarly, slave node 0 has three elements, slave node 2 has three elements, slave node 3 has three elements, slave node 6 has one element, and slave node 7 has four elements, so that the data transmitted upstream by these slave nodes 104 comprises the corresponding number of time slots. It should be noted that there does not necessarily have to be a one-to-one correlation between elements and time slots.For example, a microphone array with three microphones contained in the peripheral device 108 may include a digital signal processor that combines signals from the three microphones (and possibly also information received from the master node 102 or from other slave nodes 104) to produce a single data sample which, depending on the type of processing, could correspond to a single time slot or multiple time slots.

[0083] In Fig. 8. The master node 102 sends a synchronization control frame (SCF), followed by data for loudspeakers coupled to specific slave nodes 104 (SD). Each successive slave node 104 forwards the synchronization control frame and also forwards at least any data intended for downstream slave nodes 104. A particular slave node 104 may forward all data or may remove data specific to that slave node 104. When the last slave node 104 receives the synchronization control frame, that slave node 104 sends the synchronization response frame (SRF), optionally followed by any data that the slave node 104 is authorized to send. Each successive slave node 104 forwards the synchronization response frame along with any data from downstream slave nodes 104 and, if necessary, inserts data from one or more microphones (MDs) coupled to the specific slave nodes 104. In the example of Fig. 8 The master node sends 102 data to slave nodes 1, 4 and 5 (in Fig. 8 (shown as active loudspeakers) and receives data from slave nodes 7, 6, 3, 2 and 0 (in Fig. 8 shown as microphone arrays).

[0084] Fig. Figures 9-11 show various exemplary data transmission operations in System 100. Fig. Figures 9-11 show the SCF as time-synchronized between adjacent nodes, while the SRF is shown as time-delayed between adjacent nodes; this is for illustrative purposes only, and both the SCF and SRF can exhibit similar time delays from node to node. Slot "Y" could also be part of the downstream data.

[0085] Fig. Figure 9 schematically shows the dynamic removal of data from a downstream transmission and insertion of data into an upstream transmission from the perspective of the downstream transmit-receiver 124 according to various embodiments. Fig. 9 sends the master node 102 as in Fig. 8. A synchronization control frame (SCF) is sent, followed by data for slave nodes 1, 4, and 5 (SD) in reverse order (e.g., data for slave node 5 is followed by data for slave node 4, which is followed by data for slave node 1, and so on) (see the line labeled MASTER). When slave node 1 receives this transmission, it removes its own data and forwards only the synchronization control frame, followed by the data for slave nodes 5 and 4, to slave node 2. Slave nodes 2 and 3 forward the data unchanged (see the line labeled SLAVE 2), so that the data forwarded by slave node 1 is received by slave node 4 (see the line labeled SLAVE 3).Slave node 4 removes its own data and forwards only the synchronization control frame, followed by the data for slave node 5, to slave node 5. Similarly, slave node 5 removes its own data and forwards only the synchronization control frame to slave node 6. Slave node 6 then forwards the synchronization control frame to slave node 7 (see the line labeled SLAVE 6).

[0086] At this point, slave node 7 sends the synchronization response frame (SRF), followed by its data (see the line labeled SLAVE 6), to slave node 6. Slave node 6 forwards the synchronization response frame, along with the data from slave node 7 and its own data, to slave node 5. Slave node 5, in turn, forwards the synchronization response frame, along with the data from slave nodes 7 and 6, to slave node 4. Slave node 4 has no data to add and therefore simply forwards the data to slave node 3 (see the line labeled SLAVE 3), which forwards the data, along with its own data, to slave node 2 (see the line labeled SLAVE 2). Slave node 2, in turn, forwards the data, along with its own data, to slave node 1.Slave node 1 has no data to add and therefore forwards the data to slave node 0, which forwards the data along with its own. As a result, master node 102 receives the synchronization response frame, followed by the data from slave nodes 7, 6, 3, 2, and 0 (see the line labeled MASTER).

[0087] Fig. Figure 10 shows another example of the dynamic removal of data from a downstream transmission and insertion of data into an upstream transmission from the point of view of the downstream transmit-receiver 124 as shown in Fig. 9, although in Fig. 10. The slave nodes 104 are coupled to both sensors and actuators as the peripheral device 108, so that the master node 102 sends data downstream to all slave nodes 104 and receives data back from all slave nodes 104. Furthermore, in Fig. 10. The data is ordered based on the node address for which it is intended or from which it originates. The data slot designated “Y” can be used for data integrity checking or data correction; in some embodiments, the data slot designated “Y” may be included additionally or as an alternative in the downstream data.

[0088] Fig. Figure 11 shows another example of the dynamic removal of data from a downstream transmission and insertion of data into an upstream transmission from the point of view of the downstream transmit-receiver 124 as shown in Fig. 9, although in Fig. 11. Data is transmitted downstream and upstream in sequential order instead of reverse order. Buffering in each slave node 104 allows selective adding, removing, and / or forwarding of data.

[0089] As previously discussed, each slave node 104 can remove data from downstream or upstream transmissions and / or add data to downstream or upstream transmissions. Thus, for example, the master node 102 can send a separate sample of data to each of a number of slave nodes 104, and each such slave node 104 can remove its data sample and forward only data intended for downstream slaves. Conversely, a slave node 104 can receive data from a downstream slave node 104 and forward the data along with additional data. One advantage of transmitting as little information as necessary is to reduce the amount of power collectively consumed by the system 100.

[0090] System 100 can also support broadcast transmissions (and multicast transmissions) from the master node 102 to the slave nodes 104, specifically by configuring the downstream slot usage of the slave nodes 104. Each slave node 104 can process the broadcast transmission and forward it to the next slave node 104, although a particular slave node 104 may "consume" the broadcast message (i.e., not forward the broadcast transmission to the next slave node 104).

[0091] System 100 can also support upstream transmissions (e.g., from a specific slave node 104 to one or more other slave nodes 104). Such upstream transmissions can include unicast, multicast, and / or broadcast upstream transmissions. Using upstream addressing as discussed above with regard to downstream transmissions, a slave node 104 can determine, based on the configuration of the upstream slot usage of the slave nodes 104, whether or not to remove data from an upstream transmission and / or whether or not to forward an upstream transmission to the next upstream slave node 104. Thus, for example, data can be forwarded by a specific slave node 104 to one or more other slave nodes 104 in addition to or instead of forwarding the data to the master node 102. Such slave-slave relationships can be configured, for example, via the master node 102.

[0092] Thus, in various embodiments, the slave nodes 104 can act as active / intelligent repeater nodes with the ability to selectively forward, discard, and add information. The slave nodes 104 can generally perform such functions without necessarily decoding / examining all data, since each slave node 104 knows the relevant timeslot(s) in which it will receive / send data and can therefore remove data from or add data to a timeslot. Although the slave nodes 104 may not need to decode / examine all data, they can typically re-clock the data they send / forward. This can improve the robustness of the system 100.

[0093] In some embodiments, bus 106 can be configured for unidirectional communication in a ring topology. For example, shows Fig. Figure 12 describes an arrangement 1200 with the master node 102 and four slave nodes 104 in a ring topology and shows signaling and timing considerations for unidirectional communication in the arrangement 1200 according to various embodiments. In such embodiments, the transceivers 120 in the nodes can comprise a receive-only transceiver (MASTER IN) and a transmit-only transceiver (MASTER OUT), instead of two bidirectional transceivers for upstream and downstream communication. In the embodiment shown in Fig. In the link layer synchronization scheme shown in Figure 12, the master node 102 sends a synchronization control frame (SCF) 180, which may be followed by "downstream" data 1202 for the three loudspeakers coupled to different slave nodes 104 (the data for the different loudspeakers can be arranged in any suitable order, as above with reference to Fig. (discussed in 8-11), and each successive slave node 104 forwards the synchronization control frame 180 together with any “upstream” data from previous slave nodes 104 and “upstream” data from itself to provide “upstream” data 1204 (e.g., the data from the eight different microphones can be arranged in any suitable order, as above with reference to Fig. Discussed in sections 8-11).

[0094] As described here, data can be transmitted between elements of the system 100 in any number of ways. In some embodiments, data can be sent as part of a set of synchronous data slots upstream by a slave node 104 (e.g., using data slots 199) or downstream by a slave node 104 or a master node 102 (e.g., using data slots 198). The volume of such data can be adjusted by changing the number of bits in a data slot or by including additional data slots. Data can also be transmitted by inclusion in a synchronization control frame 180 or a synchronization response frame 197 in the system 100. Data transmitted in this way can be I2C control data from the host 110 (with a response from a peripheral device 108 associated with a slave node 104); accesses to registers of the slave node 104 (e.g.,for the discovery and configuration of slots and interfaces), which may include write access from the host 110 / master node 102 to a slave node 104 and read access from a slave node 104 to the host 110 / master node 102; and event signaling via interrupts from a peripheral device 108 to the host 110. In some embodiments, general-purpose input / output (GPIO) pins may be used to transmit information from a slave node 104 to the master node 102 (e.g., by having the master node 102 query the GPIO pins via I2C or by having a node transceiver 120 of a slave node 104 generate an interrupt on an interrupt request pin). For example, in some such embodiments, a host 110 can send information via I2C to the master node 102, and the master node 102 can then send this information to the slave via the GPIO pins.Any of the types of data discussed here, as transmitted over bus 106, can be transmitted using any one or more of these communication paths. Other types of data and data communication techniques may be disclosed here in System 100.

[0095] Embodiments of the present disclosure can be implemented into a system using any suitable hardware and / or software for configuration as desired. Fig. Figure 13 schematically shows a device 1300 that can serve as a host or node (e.g., a host 110, a master node 102, or a slave node 104) in the system 100, according to various embodiments. Fig. 13 is a number of components shown as included in the device 1300, but any one or more of these components may be omitted or duplicated as is suitable for the application.

[0096] Furthermore, in various embodiments, the device 1300 can incorporate one or more of the features described in Fig. The device 1300 may not include the components shown in Figure 13, but it may include an interface circuit for coupling with one or more of the components. For example, the device 1300 may not include a display device 1306, but it may include a display device interface circuit (e.g., a connector and driver circuits) to which a display device 1306 can be coupled. In another set of examples, the device 1300 may not include an audio input device 1324 or an audio output device 1308, but it may include an audio input or audio output interface circuit (e.g., a connector and supporting circuits) to which an audio input device 1324 or an audio output device 1308 can be coupled.

[0097] The device 1300 can include the node transceiver 120 according to any of the embodiments disclosed herein for managing communication on the bus 106 when the device 1300 is coupled to the bus 106. The device 1300 can include a processing device 1302 (e.g., one or more processing devices) which may be contained within the node transceiver 120 or be separate from the node transceiver 120. In the present usage, the term "processing device" may refer to any device or part of a device that processes electronic data from registers and / or memory in order to transform such electronic data into other electronic data that can be stored in registers and / or memory.The processing device 1302 can comprise one or more digital signal processors (DSPs), application-specific integrated circuits (ASICs), central processing units (CPUs), graphics processing units (GPUs), cryptoprocessors, or any other suitable processing devices. The device 1300 can comprise a memory 1304, which itself can comprise one or more memory devices, such as volatile memory (e.g., dynamic random-access memory (DRAM)), non-volatile memory (e.g., read-only memory (ROM)), flash memory, semiconductor memory, and / or a hard disk.

[0098] In some embodiments, the memory 1304 can be used to store a working copy and a permanent copy of programming instructions that cause the device 1300 to execute any suitable techniques disclosed herein. In some embodiments, machine-accessible media (including non-perishable, computer-readable storage media), methods, systems, and devices for executing the techniques described above are illustrative examples of embodiments disclosed herein for communication via a two-wire bus. For example, instructions can be stored on computer-readable media (e.g., the memory 1304) which, when executed by one or more processing devices included in the processing device 1302, cause the device 1300 to execute any techniques disclosed herein.

[0099] In some embodiments, the device 1300 may include another communication chip 1312 (e.g., one or more other communication chips). The communication chip 1312 may, for example, be designed to manage wireless communication for transferring data to and from the device 1300. The term "wireless" and its derivatives may be used to describe circuits, devices, systems, methods, techniques, communication channels, etc., that can transmit data by using modulated electromagnetic radiation through a non-solid medium. The term does not imply that the associated devices contain no wires whatsoever, although in some embodiments they might not.

[0100] The 1312 communication chip can implement any of several wireless standards or protocols, including, but not limited to, IEEE (Institute for Electrical and Electronics Engineers) standards such as Wi-Fi (IEEE 802.11 family), the IEEE 802.16 standards (e.g., IEEE 802.16 Supplement 2005), the LTE (Long-Term Evolution) project along with any supplements, updates, and / or revisions (e.g., the Advanced LTE project, the UMB (Ultra Mobile Broadband) project (also known as "3GPP2"), etc.). IEEE 802.16-compliant Broadband Wireless Access (BWA) networks are generally referred to as WiMAX networks, where WiMAX stands for Worldwide Interoperability for Microwave Access, a certification mark for products that pass conformance and interoperability testing for the IEEE 802.16 standards.The one or more 1312 communication chips can operate according to a GSM (Global System for Mobile Communication), GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System), HSPA (High Speed ​​Packet Access), E-HSPA (Evolved HSPA), or LTE network. The one or more 1312 communication chips can operate according to EDGE (Enhanced Data for GSM Evolution), GERAN (GSM EDGE Radio Access Network), UTRAN (Universal Terrestrial Radio Access Network), or E-UTRAN (Evolved UTRAN). The one or more 1312 communication chips can operate according to CDMA (Code Division Multiple Access), TDMA (Time Division Multiple Access), DECT (Digital Enhanced Cordless Telecommunications), EV-DO (Evolution-Data Optimized), and derivatives thereof, as well as any other wireless protocols designated as 3G, 4G, 5G, and beyond.The communication chip 1312 can operate according to other wireless protocols in other embodiments. The device 1300 can include an antenna 1322 to enable wireless communication and / or to receive other wireless transmissions (such as AM or FM radio transmissions).

[0101] In some embodiments, the 1312 communication chip can manage wired communication using a protocol other than the one described here for bus 106. Wired communication can include electrical, optical, or any other suitable communication protocol. Examples of wired communication protocols that can be enabled by the 1312 communication chip include Ethernet, CAN (Controller Area Network), I2C, MOST (Media-Oriented Systems Transport), or any other suitable wired communication protocol.

[0102] As mentioned above, the 1312 communication chip can comprise multiple communication chips. For example, a first 1312 communication chip can be dedicated to shorter-range wireless communication, such as Wi-Fi or Bluetooth, and a second 1312 communication chip can be dedicated to longer-range wireless communication, such as GPS, EDGE, GPRS, CDMA, WiMAX, LTE, EV-DO, or others. In some embodiments, a first 1312 communication chip can be dedicated to wireless communication and a second 1312 communication chip can be dedicated to wired communication.

[0103] The device 1300 can include a battery / power supply circuit 1314. The battery / power supply circuit 1314 can include one or more energy storage devices (e.g., batteries or capacitors) and / or a circuit for coupling components of the device 1300 to a power source separate from the device 1300 (e.g., mains power supply, voltage provided by a car battery, etc.). For example, the battery / power supply circuit 1314 can include the upstream filtering circuit 132 and the downstream filtering circuit 131, which are described above with reference to Fig. 2 will be discussed, and could be loaded via the bias on bus 106.

[0104] The device 1300 can include a display device 1306 (or a corresponding interface circuit, as discussed above). The display device 1306 can, for example, include any visual indicators, such as a heads-up display, a computer monitor, a projector, a touchscreen display, a liquid crystal display (LCD), a light-emitting diode display, or a flat panel display.

[0105] The device 1300 can include an audio output device 1308 (or a corresponding interface circuit, as discussed above). The audio output device 1308 can, for example, include any device that produces an audible indicator, such as loudspeakers, headsets, or earphones.

[0106] The device 1300 can include an audio input device 1324 (or a corresponding interface circuit, as discussed above). The audio input device 1324 can include any device that generates a signal representing a sound, such as microphones, microphone arrays, or digital instruments (e.g., instruments with a MIDI output (Musical Instrument Digital Interface)).

[0107] The device 1300 can include a GPS device 1318 (Global Positioning System) (or a corresponding interface circuit, as discussed above). The GPS device 1318 can communicate with a satellite-based system and receive a location data for the device 1300, as is known in the art.

[0108] The device 1300 may include a further output device 1310 (or a corresponding interface circuit, as discussed above). Examples of the further output device 1310 would be an audio codec, a video codec, a printer, a wired or wireless transmitter for providing information to other devices, or an additional storage device. Additionally, any suitable peripheral devices 108 discussed herein may be included in the further output device 1310.

[0109] The device 1300 may include a further input device 1320 (or a corresponding interface circuit, as discussed above). Examples of the further input device 1320 would be an accelerometer, a gyroscope, an image acquisition device, a keyboard, a cursor control device such as a mouse, a stylus, a touchpad, a barcode reader, a QR code reader (Quick Response), or an RFID reader (Radio Frequency Identification). Additionally, any suitable sensors or peripheral devices 108 discussed herein may be included in the further input device 1320.

[0110] Any suitable display, input, output, communication, or storage devices described above with reference to device 1300 may serve as the peripheral device 108 in system 100. Alternatively or additionally, any of the display, input, output, communication, or storage devices described above with reference to device 1300 may be contained in a host (e.g., host 110) or a node (e.g., a master node 102 or a slave node 104). Decimation to support lower sampling rates and use of multiple slots to support higher sampling rates

[0111] In some embodiments, the nodes of bus 106 can support a single high-bandwidth audio sampling rate (e.g., 44.1 kHz - 48 kHz). However, many digital audio signals may not always require the full audio spectrum supported by bus 106. For example, some audio noise cancellation applications may not require the full bandwidth for some of the audio signals transmitted over bus 106. By decimating signals that do not require full bandwidth, multiple channels can be "packed" into a single audio stream and distributed independently on bus 106 to different slave nodes 104. For example, a decimated audio stream could include multi-channel noise cancellation streams, multi-channel active audio, or other lower-bandwidth streams. Sampling rates lower than 40 kHz may be appropriate, for example, for transmitting human speech, lower-quality audio, and FM radio.

[0112] In an isochronous digital audio network (e.g., bus 106), conventional approaches to providing multiple audio streams typically require all streams to be provided at a sampling rate chosen by the needs of the channel with the highest audio bandwidth. All other channels may be forced to maintain this same high sampling rate, and therefore digital throughput can be wasted when this high sampling rate is not necessary. Since the overall digital bus throughput is limited, this conventional redundancy can reduce the number of channels that can be transmitted.

[0113] If, instead, audio is decimated, the bus 106 can allow the transmission of multiple channels of audio in a single audio slot by multiplexing the stream in the master node 102 and selectively listening to or receiving one or more of the channels in the slave node 104.

[0114] If a digital audio signal requires a higher sampling rate than the superframe rate of bus 106, it is also possible to use bus 106 to support the higher sampling rate by transmitting the audio signal (e.g., in multiple data slots within a single superframe 190) across multiple channels. For example, a slave node 104 can use multiple data slots to transmit at a higher sampling rate than the superframe rate (e.g., two data slots to double the superframe rate, four data slots to quadruple the superframe rate, etc.). Sampling rates above 48 kHz may be desirable, for example, for higher-quality audio (e.g., professional audio) and DVD-Audio.

[0115] To support two or four times the sampling rate in a slave node 104, the master node 102 can use two or four times the number of TDM data channels on its sampling frequency interface to the host 110. To increase the sampling rate, multiple whole channels and / or fractions of a channel can be used.

[0116] In some embodiments, data for a single peripheral device 108 (associated with a slave node 104) can occupy several of the downstream data slots 198. This data can be, for example, audio data. In some embodiments, data from a single peripheral device 108 (associated with the slave node 104) can occupy several of the upstream data slots 199. For example, shows Fig. 14 is an example of information exchange on the two-wire bus 106 according to various embodiments of the bus protocols described here. As in the line “MASTER SEND” of Fig. As shown in Figure 14, one downstream data slot can be occupied by speaker data destined for the speaker associated with Slave Node 1, and two downstream data slots (SD2(1) and SD2(2)) can be occupied by speaker data destined for the speaker associated with Slave Node 2. The speaker associated with Slave Node 2 can thus receive data at twice the rate of the speaker associated with Slave Node 1. Analogous use of multiple data slots can occur in the upstream data slots 199.

[0117] In some embodiments, a specific data slot in the upstream data slots 199 of a first superframe 190 can contain data from a first peripheral device, while this specific data slot in the upstream data slots 199 of a second superframe 190 can contain data from a second, different peripheral device. For example, after the first synchronization response frame in the "MASTER RECEIVE" line of Fig. As shown in Figure 14, the first upstream data slot can be occupied by microphone data from the microphone associated with Slave Node 1, and the second upstream data slot can be occupied by microphone data from microphone A associated with Slave Node 0 (MD0A). This is shown after the second synchronization response frame in the "MASTER RECEIVE" line of Fig. As shown in Figure 14, the first upstream data slot can again be occupied by microphone data from the microphone associated with Slave Node 1, but the second upstream data slot can be occupied by microphone data from microphone B associated with Slave Node 0 (MD0B). The microphone associated with Slave Node 1 can thus provide data on bus 106 at twice the rate of each of the microphones associated with Slave Node 104. Analogous use of multiple data slots can occur in the downstream data slots 198. Although Fig. 14 An example shows that several peripheral devices associated with the same slave node share a particular upstream data slot; in some embodiments, several peripheral devices associated with different slave nodes may share a particular upstream data slot.

[0118] As mentioned above, a slave node 104, which is coupled to a peripheral device 108 via an I2S / TDM bus (e.g. using the I2S / TDM / PDM transceiver 127 of the node transceiver 120), can communicate with the peripheral device 108 at a rate of less than the superframe rate. A setting in the slave node 104 can determine by what factor the slave peripheral communication is reduced relative to the superframe rate (e.g. by a factor of two, a factor of four, etc.), and several peripheral devices 108 coupled to the slave node 104 (or several channels to a single peripheral device 108) can share a communication slot between the slave node 104 and the master node 102 by time multiplexing (e.g., two peripheral devices 108 can take turns injecting data into a given communication slot between the master node 102 and the slave node 104).In some embodiments, if a peripheral device 108 with a "reduced data rate" takes a long time to send data back to the slave node 104 when the data rate is reduced, the slave node 104 can send a SYNC signal to the peripheral device 108 on an integer number of superframes before the time at which the data should be sent to the master node 102 (the integer being stored in the slave node 104).

[0119] In some embodiments, the I2S / TDM / PDM transceiver 127 of the node transceiver 120 can operate at a reduced rate relative to the superframe rate. For example, permissible reduced rates at a superframe rate of 48 kHz would be 24 kHz, 12 kHz, 6 kHz, 4 kHz, 3 kHz, 2.4 kHz, 2 kHz, 1.71 kHz, and 1.5 kHz. The node transceiver 127 can transmit data that is received upstream or downstream by the I2S / TDM / PDM transceiver 127. The I2S / TDM / PDM transceivers 127 of different slave nodes 104 can operate at different rates. In some embodiments, the I2S / TDM / PDM transceiver 127 of the master node 102 can operate at the highest data rate in the system 100.

[0120] In some embodiments, the data slots on bus 106 can be configured to run at a full continuous audio rate (e.g., 48 kHz) or at a reduced rate by skipping data slots for the superframes 190 that do not contain data (e.g., if there are only microphone nodes with a "reduced sampling rate" as peripheral devices 108 in the system 100). This approach can save power by reducing the activity level on bus 106 without increasing the channel bandwidth on bus 106.

[0121] In some embodiments, the data slots on bus 106 can be configured to run at a full continuous audio rate or at a reduced rate by time-dividing bus data slots for a given slave node 104 into multiple I2S / TDM channels without skipping data slots for superframes 190. This approach can be advantageous when different types of peripheral devices 108 are coupled to slave nodes 104 on bus 106 (e.g., a multi-axis accelerometer coupled to one slave node 104, a microphone or amplifier node coupled to another slave node 104, etc.). This approach can increase the channel bandwidth on bus 106 and save some power.

[0122] A node on bus 106 can include one or more registers (e.g., in memory 1304) for storing configuration information related to reduced-rate operation. For example, an I2SRRATE register can define an RRDIV field that allows the superframe rate to be divided down to the reduced I2S rate. For example, with a superframe rate of 48 kHz, RRDIV can be set to a reduced rate of 24 kHz, 12 kHz, 6 kHz, 4 kHz, 3 kHz, 2.4 kHz, 2 kHz, 1.71 kHz, or 1.5 kHz in some embodiments. The I2SRRATE register can also include a control bit RBUS that enables reduced-rate slots on bus 106. In some embodiments, the I2SRRATE register can be defined as a master-only, auto-broadcast register to ensure that the value is the same in all nodes of a bus, while in other embodiments this may not be the case.

[0123] An I2SRATE register can include a field (e.g., a 3-bit field) that selects the slave node's I2S / TDM rate as an integer multiple of the superframe rate, or as a fraction of the superframe rate. The I2SRATE register can also include a REDUCE bit that controls the handling of RX data at a slave node of increased rate by reducing or duplicating I2S / TDM data to achieve the superframe rate. A SHARE field can allow data slot sharing on bus 106.

[0124] An I2SRRCTL register can provide bits that allow a node's processing unit 1302 to track a full-rate frame containing new samples at a reduced rate. Setting an ENVLSB bit in the I2SRRCTL register can cause the least significant bit (LSB) of each data channel to be set when a new sample is sent and cleared otherwise. Setting an ENXBIT bit in the I2SRRCTL register can cause an additional bit after the LSB of each data channel's data word to be used. This additional bit can be set when a new sample is sent and cleared otherwise. In some embodiments, the data word length can be smaller than the channel widths (e.g., a 24-bit data word in a 32-bit I2S channel), and this additional bit can specify new samples (while the remaining bits in the channel can still specify erroneous data).Setting an ENSTRB bit in the I2SRRCTL register can configure the ADR1 pin as a strobe, indicating the frame where reduced-rate data is updated. Setting an ENCHAN bit in the I2SRRCTL register can configure a "full-rate" node to produce an additional I2S / TDM data channel to indicate the frame where reduced-rate data is updated.

[0125] An I2SRRSOFFS register can provide fields used to advance the SYNC edge in a reduced-rate slave node by superframe increments. The RRSOFFSET field of the I2SRRSOFFS register can store a value used to advance the SYNC edge of a reduced-rate slave node by a number of superframes. This register can minimize the latency of reduced-rate data transferred over the bus when I2S / TDM RECEIVE data requires more than one superframe access time. In some embodiments, the active SYNC edge in a reduced-rate slave node might occur two superframes before the data should be sent to the host or another processor. Setting RRSOFFSET to N can cause the SYNC edge to occur N superframes earlier.The received data can still be sent in the same superframe 190 on bus 106, regardless of the RRSOFFSET value. Transfer of auxiliary power and battery power

[0126] As previously discussed, the slave nodes 104 can be powered locally by their own power source and / or can extract power from the bus 106. In some embodiments, a slave node 104 can extract auxiliary output current to power an amplifier associated with the slave node 104 as a peripheral device 108, enabling sufficient audio output through the amplifier (and possibly in combination with other amplifiers connected to the same or other slave nodes 104) to drive loudspeakers. The amplifier may be "intelligent" (e.g., with its own digital signal processing capability) or not (e.g., without digital signal processing).

[0127] Transmitting auxiliary power via bus 106 can be particularly advantageous in emergency situations where the primary local power source for a slave node 104 fails; for example, warning messages or other information can still be transmitted via the audio system in a vehicle. Extracting auxiliary power from bus 106 can also eliminate the costs associated with connecting and wiring a local power source to the slave node 104 (for example, in association with an active loudspeaker).

[0128] Furthermore, in embodiments where the bus 106 supplies power to the slave nodes 104, the bus 106 can provide a current that supports local power storage (e.g., for charging one or more batteries, capacitors, or supercapacitors), thereby making additional local or phantom power supplies for powering a peripheral device 108 (e.g., an audio amplifier) ​​associated with a slave node 104 less necessary or even unnecessary. In some embodiments, the limited current from the bus 106 can power a slave node 106 that has a local energy storage device, wherein the energy storage device supplies the necessary energy during peak current demands while being charged during periods of low current demand. This can be particularly advantageous when applied to audio signals with a high crest factor.In some embodiments, a local battery in locally powered slave nodes 104 may also be useful (e.g. to reduce the wire thickness for the local power supply).

[0129] Fig. Figure 15 is a block diagram of an arrangement 1500 in which a slave node 104 is coupled to an energy storage device 1502 and a peripheral device 108 (e.g., a loudspeaker). In some embodiments, the slave node 104 can extract power from the bus 106 (as, for example, above with reference to Fig. 1 and Fig. (discussed in Section 2) and can use this current, at least partially, to store energy in the energy storage device 1502. The energy storage device 1502 can comprise any suitable energy storage device, such as a capacitor or a battery. In particular, the (not shown) node transmitter-receiver 120 of the slave node 104 can comprise a power supply circuit 1314 for receiving a bias voltage via the bus 106 and for providing energy from the bias voltage to the energy storage device 1502. The slave node 104 can selectively use the energy storage device 1502 to drive the loudspeaker 108. In some embodiments, the slave node 104 can selectively use the energy storage device 1502 to supply power to the bus 106 in order to provide power to another slave node 104.The energy storage device 1502 can be connected to an amplifier, a transceiver and / or other components or peripheral devices 108 (e.g. a digital signal processor, ADC, DAC, a battery management circuit, etc.). Nodes with both a loudspeaker and a microphone as peripheral devices

[0130] In some embodiments, a slave node 104 can be associated with a loudspeaker as a peripheral device 108 (mostly using downstream communication), a microphone as a peripheral device 108 (mostly using upstream communication), or a combination of a loudspeaker and a microphone (using both upstream and downstream communication, as supported by the bus 106). The number of loudspeakers and microphones for a slave node 104 can vary depending on the application and can be any suitable combination. Several examples of slave nodes 104 associated with both loudspeakers and microphones as peripheral devices are discussed here.In some of these embodiments, a peripheral device communication circuit (such as the I2S / TDM / PDM transceiver 127, the I2C transceiver 129, or one or more GPIO pins with interrupt request capability) of a node transceiver 120 of a slave node 104 can communicate with at least one loudspeaker and at least one microphone. The host 110 can push data onto the bus 106 (via the master node 102) to communicate with these devices and / or receive data from the bus 106 from these devices (via the master node 102). Collision detection

[0131] In some embodiments where the system 100 is integrated into a vehicle, the bus 106 can provide a digital network to aid in understanding vehicle integrity and the severity of an accident during collisions. Using microphones and / or other sensors (integrated into the peripheral device 108), the environmental conditions near the associated slave node 104 can be detected, and the detected information can be sent upstream or downstream to an application that needs to gather information related to the vehicle's safety and integrity. Examples of other detection methods include ultrasonic sensors, visual sensors, or electromechanical sensors (e.g., accelerometers and gyroscopes). Conference systems

[0132] In some embodiments, the system 100 can distribute audio sampled by a microphone associated with one slave node 104 (or several slave nodes 106) to a loudspeaker associated with another slave node 104 (or several other slave nodes 104). For example, the bus 106 can distribute acquired local microphone information within a vehicle (e.g., cars, sedans, buses, minivans, airplanes, etc.) so that audio communication can be provided between passenger and driver, driver to backseat, or between any pair of locations. Some embodiments of the system 100 can broadcast audio sampled by a microphone associated with any of the slave nodes 104 to many other slave nodes 104 in an audio network provided by the bus 106. The bus 106 can also transmit any other data between any two suitable points (e.g.,messages, data files, content streams, etc.) are transmitted.

[0133] In some embodiments, a slave node 104 can include a peripheral communication circuit (such as the I2S / TDM / PDM transceiver 127, the I2C transceiver 129 of the node transceiver 120, or one or more GPIO pins with interrupt request capability) for communication with a microphone and a conference circuit user interface element (e.g., as peripheral devices 108). A user can actuate the conference circuit user interface element when the user wants to provide audio from the microphone of another device coupled to the bus 106. The conference circuit user interface element can be, for example, a button, a gesture recognition device, a microphone (e.g., coupled with a processing device that can perform speech recognition tasks to detect commands to start and end a conference call), or a designated part of a touchscreen display.When a user activates the conference call user interface element, the slave node 104 can provide data from the microphone upstream and / or downstream on bus 104 for reception and / or playback by one or more other devices (e.g., nodes or the host 110). In some embodiments, the host 110 can receive the microphone data and route it to another slave node 104 on bus 106 for playback. The slave node 104 can also provide routes of data in response to activation of the conference call user interface element to specify the source of the microphone data and / or the desired destination(s) for the microphone data.

[0134] For example, it shows Fig. Figure 16 describes an arrangement 1600 comprising a host 110, a master node 102, and two slave nodes 104, along with their associated peripheral devices 108, and a flowchart of a method 1602 that can be executed by the host 110 of the arrangement 1600 to selectively route audio around the arrangement 1600. In the arrangement 1600, a slave node 0 can be associated with a single loudspeaker, while slave node 1 can be associated with a loudspeaker, a microphone, and a button that acts as the conference circuit user interface element discussed above. The method 1602 can represent a "host-centric" approach to routing data in the arrangement 1600.

[0135] In 1604, the host 110 can provide Music 0 to the slave node 0. Music 0 represents any desired data stream that is routed to the slave node 0 during "nominal" operation. In some embodiments, Music 0 can be video data, voice data, or any other suitable data. The host 110 can provide Music 0 in 1604 to the slave node 0 via the master node 102 over bus 106 using any of the bus protocols disclosed herein.

[0136] In 1606, the host 110 can provide Music 1 to the slave node 1. Music 1 represents any desired data stream that is routed to the slave node 1 during "nominal" operation. In some embodiments, Music 1 can be video data, voice data, or any other suitable data. The host 110 can provide Music 1 in 1606 to the slave node 1 via the master node 102 over bus 106 using any of the bus protocols disclosed herein.

[0137] In 1608, host 110 can receive button data from slave node 1. This button data can indicate the state of the button (e.g., whether the button has been pressed by a user). Host 110 can receive button data from slave node 1 in 1608 via bus 106 through master node 102 using any of the bus protocols disclosed herein.

[0138] In 1610, the host 110 can receive microphone data from the slave node 1. The microphone data can be audio data captured by the microphone associated with the slave node 1 as a peripheral device 108. The host 110 can receive microphone data from the slave node 1 in 1610 via the bus 106 through the master node 102 using any of the bus protocols disclosed herein.

[0139] In 1612, host 110 can determine whether the button data received in 1608 indicates that the button was pressed by a user. If host 110 determines in 1612 that the button was not pressed, host 110 can return to 1604 and continue supplying music to slave node 0.

[0140] When host 110 in 1612 determines that the button has been pressed, host 110 can proceed to 1614 and provide the microphone data from slave node 1 to slave node 0. Host 110 can provide the microphone data to slave node 0 instead of music 0, interrupting music 0 for the microphone data. Slave node 0 can provide the microphone data to its associated loudspeaker, thus providing the audio collected by the microphone associated with slave node 1 to the loudspeaker associated with slave node 0. Host 110 can provide the microphone data to slave node 0 in 1614 via bus 106 through master node 102 using any of the bus protocols disclosed herein.

[0141] In 1616, the host 110 can stop supplying music 1 to slave node 1 (to turn off the speaker associated with slave node 1 while the microphone associated with slave node 1 sends its data to other devices on the bus) and can then return to 1612 to determine if the button is still pressed. In some embodiments, the host 110 can decrease the volume of music 1 in 1616 instead of stopping its supply. In some embodiments, the host 110 can mute the volume of music 1 in 1616 instead of stopping its supply.

[0142] Fig. Figure 17 is a flowchart of a procedure 1700, which is passed through slave node 0 of the arrangement 1600 of Fig. 16. During the selective routing of audio around the arrangement 1500, various embodiments can be performed. Method 1700 can represent a “slave-centric” approach to routing data in the arrangement 1600.

[0143] In 1702, slave node 0 can receive Music 0 from host 110. As discussed above with reference to 1604, Music 0 represents any desired data stream that is routed to slave node 0 during "nominal" operation. In some embodiments, Music 0 can be video data, voice data, or any other suitable data. Host 110 can provide Music 0 to slave node 0 in 1702 via bus 106 or via master node 102 using any of the bus protocols disclosed herein.

[0144] In 1704, slave node 0 can provide music 0 to the loudspeaker, which is associated with slave node 0 as peripheral device 108. In response, the loudspeaker can output music 0 as an audible signal.

[0145] In 1706, slave node 0 can receive button data from slave node 1. The button data can indicate the state of the button associated with slave node 1 (e.g., whether the button has been pressed by a user). In some embodiments, slave node 0 can receive the button data directly from slave node 1 via bus 106 (e.g., without the data first having to pass through master node 102). In some embodiments, slave node 0 can receive the button data from slave node 1 via master node 102 and / or host 110. In general, slave node 0 in 1706 can receive button data from slave node 1 using any of the bus protocols disclosed herein.

[0146] In 1708, slave node 0 can receive microphone data from slave node 1. The microphone data can be audio data captured by the microphone associated with slave node 1 as a peripheral device 108. In some embodiments, slave node 0 can receive the microphone data directly from slave node 1 via bus 106 (e.g., without the data first having to pass through master node 102). In some embodiments, slave node 0 can receive the microphone data from slave node 1 via master node 102 and / or host 110. In general, slave node 0 in 1708 can receive microphone data from slave node 1 using any of the bus protocols disclosed herein.

[0147] At node 1710, slave node 0 can determine whether the button data received at node 1706 indicates that the button was pressed by a user. If slave node 0 determines at node 1710 that the button was not pressed, it can return to node 1702 and continue receiving the music signal from host node 110.

[0148] If slave node 0 in 1710 determines that the button has been pressed, slave node 0 can proceed to 1712 and provide the microphone data to the speaker associated with slave node 0. Slave node 0 can then provide the microphone data to speaker 0 instead of the music, pausing the music for the microphone data. Slave node 0 can then return to 1710 to determine if the button is still pressed. Routes of voice calls

[0149] In some embodiments, the System 100 can provide a digital audio network for routing incoming and outgoing voice calls from a single receiver (e.g., rerouting calls between different locations within a vehicle). By effectively utilizing low-latency downstream and upstream channels, high-quality voice calls can be routed around a vehicle in a variety of ways.

[0150] In some embodiments, a slave node 104 can include a peripheral communication circuit (such as the I2S / TDM / PDM transceiver 127, the I2C transceiver 129 of the node transceiver 120, or one or more GPIO pins with interrupt request capability) coupled to a wireless transceiver as a peripheral device 108. The wireless transceiver can receive voice calls, and the slave node 104 can place the data representing the voice calls (e.g., upstream or downstream) onto the bus 106.

[0151] For example, it shows Fig. 18 An embodiment of the system 100 in which a wireless transceiver is included in the peripheral device 108 associated with the slave node 1. The slave node 1 can receive voice call data from the wireless transceiver and can make it available to other devices in the system 100 (upstream and / or downstream) according to any of the bus protocols disclosed herein. The slave node 1 can also receive data from any other devices in the system 100 and make it available to the wireless transceiver for inclusion in an outgoing voice transmission according to any of the bus protocols disclosed herein.

[0152] In another example, it shows Fig. 19 An embodiment of the system 100 in which a wireless transceiver 1902 (e.g., using any suitable communication protocol) is coupled to the host 110. The host 110 can receive data from the wireless transceiver 1902 and make it available to other devices in the system 100 according to any of the bus protocols disclosed herein. The host 110 can also receive data from any of the other devices in the system 100 and make it available to the wireless transceiver 1902 for inclusion in an outgoing voice transmission according to any of the bus protocols disclosed herein. Communication receiver and sender

[0153] As discussed above with regard to wireless voice call transceivers, instead of or in addition to providing speakers and microphones as peripheral devices 108 for slave nodes 104 connected to the bus 106, a slave node 104 can also be associated with one or more communication transceivers as peripheral devices 108. Examples of such transceivers would be Bluetooth modules, near-field transceivers, wireless internet transceivers, Ethernet transceivers, EAVB (Ethernet Audio Video Bridging) transceivers, transceivers used for data transmission in IoT (Internet of Things) applications, etc. The system 100 can effectively provide a physical layer communication link that extends the bus 106 to provide not only downstream and upstream audio communication but also streaming communication.Audio, video, and any suitable information can be transmitted synchronously using the bus (with data being transmitted concurrently with audio I2S / TDM, I2C, IRQ, etc., as discussed above with reference to the I2S / TDM / PDM transceiver 127 and the I2C transceiver 129). This functionality can be particularly advantageous for sending and receiving time-coded media, or in applications where timing between different data streams is important. (See above with reference to...) Fig. 18 and Fig. The embodiments discussed in section 19 can also apply to any suitable communication receivers and transmitters.

[0154] For example, in some embodiments, a Bluetooth module associated with the slave node 104 can communicate with a mobile device to send signals via Bluetooth to the bus 106 (e.g., to a slave node 104 or the master node 102) so that the signal can be delivered to other devices in the system 100 (e.g., an audio signal can be played back by loudspeakers associated with the slave nodes 104 connected to the bus 106). More generally, the bus protocols disclosed herein can be used as a bridge to other communication systems and / or to bridge multiple communication systems. Routes of content

[0155] In some embodiments, the System 100 can provide a digital audio network that allows the transmission of audio content locally to any one or more of the Slave Nodes 104. For example, the System 100 can be configured to selectively route audio to different parts of the digital audio network (e.g., rear channels, front channels, a speaker at a specific seat in the vehicle, etc.). Examples of this functionality were given above with reference to Fig. 16 and Fig. 17 discussed. In addition to audio, such selective routing can be applied to any other type of streaming content.

[0156] In some embodiments, the communication between nodes enabled by the System 100 can be used to collect audio signals from many microphones contained in the peripheral devices 108 in order to avoid crosstalk and / or echo in the digital distributed audio network implemented by the System 100. In particular, different slave nodes 104 on the bus 106 can be aware of the audio signals transmitted on the bus 106 and can adjust their audio output in response to compensate for this. As above with reference to Fig. 16 and Fig. As stated in paragraph 17, control decisions on how to properly compensate for multiple audio sources can be made in a distributed manner (e.g., by processing devices 1302 contained in one or more of the slave nodes 104) or in a centralized manner (e.g., by processing devices 1302 contained in the master node 102 or the host 110). Beam shaping

[0157] In some embodiments, the ability of the System 100 to deliver and collect synchronous audio content to multiple slave nodes 104 on the bus 106 can support beamforming applications. Such applications may include detecting the location of a loudspeaker and / or forming a beam to ensure that output audio is focused on a specific area (but with reduced or no audibility outside that area). Any suitable application for focused audio transmission or reception can also take advantage of the System 100. Microphone connectivity

[0158] In some embodiments, the System 100 can provide a digital microphone connection that is compatible with existing analog microphones, connectors and preamplifiers and operates using standard shielded three-wire microphone cabling.

[0159] Previous attempts have been made to introduce digital microphones for professional audio and sound reinforcement. In these attempts, the audio signal was converted directly from analog to digital within the capsule and then transmitted digitally. This approach required specialized microphones, dedicated digital cabling, and digital receivers, and was therefore incompatible with the rest of the professional audio ecosystem.

[0160] The System 100 provides a digital interconnect system by connecting an ADC contained in a standard positive XLR connector of a microphone (or other microphone-connected enclosure) to the bus 106 using the Node Transceiver 120. The ADC can be directly coupled to the output of any existing analog dynamic, electret, or condenser microphone and can be powered by standard 48V microphone phantom power. The ADC can convert the analog microphone signal into a digital signal, and this digital signal can be transmitted (via the Node Transceiver 120) over the bus 106 using standard microphone cabling.In most embodiments, for communication over bus 106, the characteristic high-frequency signals can be combined on a common set of conductors with the lower-frequency analog microphone signal without interference, so that both can be transmitted on the same cable and readily separated as required. Since bus 106 is formed from two-wire connections, a connection can be provided by standard microphone wiring, and because communication over bus 106 is typically carried at a much higher frequency than standard audio, transmissions over bus 106 on the microphone wiring can be combined with the existing analog microphone signal for backward / forward compatibility.

[0161] At the receiving end of a microphone, a number of different connection arrangements can be used. In some embodiments, a connection element can include the node transceiver 120 and a digital output that can be converted to a standard S / PDIF, AES / EBU, AES42, or other digital format for connection to an audio receiving device (e.g., a mixer or audio input device). In some embodiments, a connection element can also include the node transceiver and a DAC and can send an analog signal to the standard microphone input. Advantages of such an approach may include the use of a lower-noise digital connection instead of an analog one.In some embodiments, a connecting element can be attached to an analog microphone input, the signal transmitted via the node transceiver 120 being outside the audio band and thus backward compatible with analog devices. In some embodiments, a connecting element can include a dual receiver connection for both the digital output and the analog signal, giving a user the ability to select between the digital and analog signals for different applications (e.g., the analog signal for a secondary preamplifier and conversion).

[0162] In some embodiments, the node transceiver 120 and a DAC could be directly integrated into an XLR connector or a junction box powered by 48 V phantom power. The entire assembly could utilize a standard microphone cable, with the node transceiver 120 and converter located within the microphone connectors.

[0163] These embodiments can be applied to multiple microphone settings and used to create a “digital snake.” In such embodiments, multiple microphone signals (either analog or digital) can be combined and transmitted over bus 106 via a standard microphone cable without the need for any large multi-conductor or specialized digital wiring. At the receiving end, a node transceiver 120 can disconnect each audio input channel for connection to standard audio hardware as discussed above.

[0164] Fig. Figures 20-23 show exemplary arrangements of a microphone 2002, a microphone cable 2010, and an audio receiving device 2020, which may be included in the system 100, according to various embodiments. In each of these arrangements, a microphone 2002 has a cable connector 2004. The microphone cable 2010 has a first connector 2006 for coupling to the cable connector 2004 and a second connector 2012 for coupling to the audio receiving device 2020. One or more conductors couple the first connector 2006 and the second connector 2012 for transmitting data between them. The one or more conductors may, for example, be standard microphone cabling. The audio receiving device 2020 may have a cable connector 218 for coupling to the second connector 2012 of the microphone cable 2010.In some embodiments, the cable connector 2004, the first connector 2006, the second connector 2012 and the cable connector 2018 may be XLR connectors or have any other suitable geometry.

[0165] Fig. Figure 20 shows an arrangement 2000 in which an ADC 2008 is located in or near the first connector 2006 and generates a digital output from the analog microphone signal, which is fed to a node transceiver 120 located in or near the second connector 2012. The output of the node transceiver 120 can comprise four wires, providing upstream signals for transmission on one upstream pair of the four wires and / or downstream signals for transmission on one downstream pair of the four wires. The digital output of the ADC 2008 can be provided in parallel with the output of the node transceiver 120 (e.g., on its own wire or wires).The cable connector 2018 of the audio receiving device 2020 can receive the four wires transmitting the output of the node transmitter receiver 120 and route these signals on these four wires to bus 106, and can receive the wires transmitting the digital output of the ADC 2008 and route this digital output to any suitable digital audio input.

[0166] Fig. Figure 21 shows an arrangement 2100 in which an ADC 2008 is arranged in or near the first connector 2006 and generates a digital output from the analog microphone signal. This digital output is fed to a node transceiver 120, which is arranged in or near the second connector 2012. As above with reference to Fig. As discussed in section 20, the output of the node transmitter 120 can comprise four wires, providing upstream signals for transmission on one upstream pair of the four wires and / or downstream signals for transmission on one downstream pair of the four wires. The digital output of the ADC 2008 can be fed in parallel to a DAC 2016 located in or near the second connector 2012. The analog output of the DAC 2016 can be fed in parallel to the output of the node transmitter 120 (e.g., on its own wire or wires). The cable connector 2018 of the audio receiver 2020 can receive the four wires transmitting the output of the node transmitter 120 and route the signals on these four wires to bus 106, and can receive the wires transmitting the analog output of the DAC 2016 and route this analog output to any suitable analog audio input.

[0167] Fig. Figure 22 shows an arrangement 2200 in which an ADC 2008 is located in or near the first connector 2006 and generates a digital output from the analog microphone signal, which is fed to a node transceiver 120, also located in or near the first connector 2006. The output of the node transceiver 120 can comprise four wires, providing upstream signals for transmission on one upstream pair of the four wires and / or downstream signals for transmission on one downstream pair of the four wires. The analog output of the microphone 2002 can be combined with the output of the node transceiver 120 (e.g., on a common set of at least four wires).The cable connector 2018 of the audio receiving device 2020 can receive the four wires that transmit the output of the node transceiver 120, combined with the analog output of the microphone 2002, and route these four wires to bus 106 and to any suitable analog audio input. As discussed above, since the signals transmitted over bus 106 generally do not overlap with analog audio signals in terms of frequency, the signals can be transmitted on the same set of conductors and the desired signals extracted (e.g., by filtering or by the inability of the final receiving device to detect signals in the other frequency band).

[0168] Fig. Figure 23 shows an arrangement 2300 in which an ADC 2008 is arranged in or near the first connector 2006 and generates a digital output from the analog microphone signal. This digital output is fed to a node transceiver 120, which is arranged in or near the second connector 2012. As above with reference to Fig. As discussed in section 20, the output of node transmitter 120 can comprise four wires, providing upstream signals for transmission on one upstream pair of the four wires and / or downstream signals for transmission on one downstream pair of the four wires. The digital output of the ADC 2008 can be fed in parallel to the output of node transmitter 120 in the second connector 2012 (e.g., on its own wire or wires), and the analog microphone signal from the microphone 2002 can be fed in parallel to both in the second connector 2012 (e.g., on their own wire or wires).The cable connector 2018 of the audio receiving device 2020 can receive the four wires transmitting the output of the node transceiver 120 and route the signals on these four wires to bus 106, receive the wires transmitting the analog microphone signal and route this analog signal to any suitable analog audio input, and receive the wires transmitting the digital output of the ADC 2008 and route this digital signal to any suitable digital audio input.

[0169] Although Fig. The 20-23 different components shown at various locations in a microphone cable 2010 are merely examples, and the components can be rearranged as appropriate. For example, in some embodiments, some or all of the components (e.g., the ADC 2008, the node transceiver 120, and / or the DAC 2016) can be located in the cable connector 2004 or the cable connector 2018. As discussed above, in some embodiments, the analog microphone signal can share conductors with the traffic generated by the node transceiver 120 on bus 106 and / or the digital representation of the analog microphone signal generated by the ADC 2008. Radio receiver as a node on the bus

[0170] As discussed above with reference to wireless voice call transceivers, instead of or in addition to providing loudspeakers and microphones as peripheral devices 108 for slave nodes 104 connected to the bus 106, a slave node 104 can also be associated with one or more radio receivers as peripheral devices 108, such as FM (frequency modulation) receivers, AM (amplitude modulation) receivers, satellite radio receivers, television media receivers, or other radio signal receivers. In a conventional vehicle environment, a receiver has an antenna mounted on a roof, rear window, rear spoiler, or other part of the vehicle, with a long wire connecting the antenna back to a radio head unit at the front of the vehicle.With this conventional approach, electromagnetic interference can occur due to the long wire, requiring other in-vehicle electronics to be carefully designed and controlled to avoid disturbing the frequency of the signal transmitted over the long wire.

[0171] To mitigate these problems and improve design flexibility and performance, in some embodiments of the system 100, a node transceiver 120 (e.g., contained in a slave node 104) can include a peripheral device communication circuit that communicates with an antenna coupled to a roof or other part of a vehicle, and the peripheral device communication circuit can communicate with the antenna via a wired connection. The node transceiver 120 can be located near the antenna, and the data received by the antenna can be transmitted via the bus 106 to a head unit (e.g., a master node 102 or a host 110 contained in a head unit) instead of via a single long wire coupling the antenna to the head unit.This can reduce or eliminate the problem of electromagnetic interference by transmitting the received data digitally in frequency bands that are not so easily disrupted by other in-vehicle electronics.

[0172] Fig. Figure 24 shows an arrangement 2400 in which a slave node 104 is located near an antenna 2404 coupled to the roof of a vehicle, according to various embodiments. The antenna 2404 (and any associated radio receiver circuit) can be a peripheral device 108 of the slave node 104 and can provide received radio data to the slave node 104 via a suitable peripheral device communication circuit. The slave node 104 can provide the received radio data (e.g., in unprocessed or processed form) to a master node 102 in a head unit 2402 of the vehicle via the bus 106.

[0173] The peripheral device communication circuit that communicates with the antenna (e.g., the 12S / TDM / PDM transceiver 127, the I2C transceiver 129, and / or one or more GPIO pins with interrupt request capability of the node transceiver 120) can interface with existing I2S and / or I2C interfaces for a radio receiver associated with the antenna, and thus the node transceiver 120 can readily interface with a radio receiver. In some embodiments, the node transceiver 120 can also provide a sample rate converter (e.g., built-in) to process the received radio signals (which are usually fixed at a suitable carrier frequency) before the received radio signals (e.g., at the audio sampling frequency corresponding to the superframe rate) are transmitted via bus 106.The data received by the radio receiver can then be transmitted upstream or downstream to a slave node 104 on the bus 106 (e.g. to a loudspeaker or to another delivery to a user). Transporting compressed video

[0174] As discussed above, video can be transmitted over bus 106 in addition to or instead of audio. In some embodiments, compressed video (or low-quality video, such as from a rear-facing camera or a rear-seat video monitor) can also be transmitted over bus 106 at a suitable data rate. For example, compressed video can be transmitted from a camera or for a video display. User interface controls

[0175] In the system 106, microphones and any suitable sensors can be included as peripheral devices 108 to provide user interfaces or to enhance audio applications. Applications of microphones and / or sensors in a vehicle environment would include, for example, hands-free user interfaces (e.g., voice control / commands), telematics, driver monitoring, emergency / breakdown assistance, and gesture recognition applications. For example, microphones can be embedded in a seatbelt or any suitable location in a vehicle. The bus 106 can provide an efficient communication channel for transmitting the audio data collected by the microphones and any suitable sensors. In some embodiments, any suitable I2C devices, such as gesture recognition sensors, pushbuttons, memory devices, displays, etc., can also be included in the system 100 (e.g.,the peripheral devices 108 can communicate with the I2C transceiver 129 contained in the node transceiver 120). Backplane connectivity

[0176] In some embodiments, the System 100 can be used to connect different subsystems (which may be located on different control boards or on the same board) with low latency. In particular, the System 100 can be used to chain multiple boards together to create a much larger system. The System 100 can also connect boards containing smaller devices via the same Bus 106. Conference room systems, entertainment systems, intercom systems, smart homes, surveillance systems, and emergency systems, among others, can effectively utilize the Bus 106 to connect their subsystems.

[0177] In some embodiments, the system can connect 100 audiovisual devices for a performance stage, recording studio, or any other suitable entertainment environment. The wiring required to connect audiovisual devices can be advantageously reduced compared to conventional thick-cable techniques by using the two-wire bus 106. The audiovisual devices can include loudspeakers, mixing consoles, musical instruments, time-coding devices, lighting equipment, amplifiers, video displays, pyrotechnics, and any other suitable equipment. For example, [the text abruptly ends here, so the translation stops as well.] Fig. 25 an arrangement 2500 in which several types of audiovisual devices contain a node transceiver 120 and thus act as slave nodes 104 and can communicate on the bus 106. In particular, a master console 2502 can comprise the host 110 and the master node 102, and the node transceivers 120 can be contained in or coupled to a mixing console 2504, a musical instrument 2506, lighting equipment 2508, an amplifier 2510, a loudspeaker 2512, and a pyrotechnic console 2514. Each of these devices can act as a peripheral device 108 and can communicate with its associated node transceiver 120 using any suitable peripheral device communication circuit (e.g. the I2S / TDM / PDM transceiver 127, the I2C transceiver 129 and / or one or more GPIO pins with interrupt request capability).Data from these devices can be made available on bus 106 by the node transmitter-receivers 120 to other devices according to any of the bus protocols disclosed herein.

[0178] The System 100 can be used to connect devices in any suitable environment. For example, the System 100 can be used to connect medical devices with many sensors or subsystems (e.g., for patient monitoring applications) to the relevant... Fig. The 25 discussed methods are interconnected. The use of the two-wire bus 106 can reduce the wiring connecting these sensors and systems relative to conventional approaches. Vibration measurement

[0179] In some embodiments, System 100 allows microphones and other sensors to be interconnected, designed to monitor many parts of a material, such as a carbon fiber material, when the material is subjected to a stress test or during use. The materials can include, for example, sheets of material, objects, rails, bridges, vehicles, or buildings. These microphones and other sensors and / or devices that generate stimuli for component testing of materials or objects can also be effectively interconnected using bus 106 in System 100 according to any of the bus protocols disclosed herein. Control systems

[0180] In some embodiments, the System 100 can provide a low-latency, chained communication architecture as discussed above. Due to the low latency and synchronicity of the System 100's data transmission, it can provide an effective communication channel for control systems, particularly those that can benefit from reduced wiring and / or those that can operate using the power supplied by the Bus 106. Control systems can advantageously use the System 100 to transmit commands between nodes on the Bus 106 or data associated with the state of the nodes on the Bus 106 to execute control functions.

[0181] When the system 100 is implemented in systems with fault tolerance requirements, the slave nodes 104 on the bus can be connected in a ring configuration, where any of the slave nodes 104 can be designated as the last slave node 104. Examples of ring configurations are given above with reference to Fig. 12. If a bus segment in the ring fails, the ring configuration can provide a fault-tolerant configuration to maintain connectivity between nodes. Bus 106 can also leverage the node discovery mechanism discussed here to discover the correct last slave node 104 in the ring to recover from the fault. Distributed processing over low-latency communication links

[0182] System 100 can be used to distribute processing operations between different slave nodes 104. As discussed above, this can be advantageous for control systems where it is desirable to perform local processing at the nodes while still maintaining a low-latency communication link between them. For example, backup / safety functions can be distributed among multiple slave nodes 104. A slave node 104 can implement a mechanism to prevent one or more peripheral devices 108 associated with that slave node 104 (e.g., devices that monitor and control a robotic limb) from exerting excessive force or reacting too early to locally detected problems.System 100 can enable distributed local processing, which can reduce or avoid the immediate need to send information from the slave nodes 104 to a centralized processor (with the potential to affect the system).

[0183] In some embodiments, a slave node 104 can use the broadcast functionality of the system 100 to listen to other sensors / servos / actuators acting as peripheral devices 108 for other slave nodes 104 and to react accordingly, without relying on a central processor (e.g. in the host 110).

[0184] By effectively employing the distributed processing enabled by the System 100, artificial limbs and other robotics applications can be given processing equivalent to muscle memory, with the slave nodes 104 being able to independently process and react to the state of their environments and their own state without intervention by the master node 102 and / or the host 110. Artificial limbs

[0185] Various embodiments of the system 100 can advantageously be applied to the control systems often found in artificial / robotic limbs and in robotics in general. The sensors and actuators used by robotic systems can serve as peripheral devices 108 for slave nodes 104 on the bus 106. In some embodiments, these sensors and actuators can also be powered via the bus 106 as discussed above. Advantageously, wiring can be reduced from a large bundle of wires to a daisy-chained two-wire system, thus providing form factor advantages for robotics.

[0186] An example is a robotic leg where the knee joint requires information from one or more foot sensors, and the ankle joint requires information from one or more knee sensors. Traditionally, a centralized processor would be connected to the sensors and actuators using many wires. Using System 100, the number of wires can be reduced from this conventional approach, thus enabling faster localized processing, as information is distributed globally over Bus 106 according to any of the bus protocol techniques disclosed herein.

[0187] For example, it shows Fig. 26 a robotic limb 2600 with a knee joint 2602, an ankle joint center 2604 and an ankle joint 2606. Fig. Figure 26 also shows an arrangement 2608 of the system 100, which enables sensors and actuators for the robotic limb 2600 to transmit data on the robotic limb 2600. In particular, the arrangement 2608 can comprise a slave node 0 with a peripheral device 108 with a knee sensor, a slave node 1 with a peripheral device 108 with the knee actuator, a slave node 2 with a peripheral device 108 with an ankle center sensor, a slave node 3 with a peripheral device 108 with an ankle center actuator, a slave node 4 with a peripheral device 108 with a foot sensor, and a slave node 5 with a peripheral device 108 with a foot actuator.Data generated by any of the sensors contained in the peripheral devices 108 can be transmitted to the associated slave nodes 104 and can then be transmitted upstream and / or downstream to ultimately reach one or more of the other slave nodes 104 (e.g. for use in controlling any of the actuators contained in the peripheral devices 108).

[0188] The same advantages discussed above with regard to robotic limbs can also apply to any robotic system comprising many smaller electronic subsystems (each performing some local processing for the subsystem). The use of System 100 in robotics for connecting sensors and servos is not limited to connecting sensors and actuators; System 100 can be used to connect any suitable electronic devices, such as memory, processors, speakers, microphones, lamps, radio receivers, etc. For example, System 100 can be applied to a network of body sensors in a gaming application, for researching body movement, or for controlling other machinery through body movement. Sensor or device networks

[0189] The System 100 allows the implementation of any suitable control system to reduce cabling while providing a low-latency communication link. These control systems could include, for example, machinery (heavy, large-scale industrial machinery), manufacturing line equipment (with many controllers and sensors), drones (autonomous flying robots), autonomous control systems, powered control systems, and so on. In many of these control systems, devices such as sensors (or sensor blocks), controllers, and / or actuators (e.g., small actuators) can operate synchronously to provide their respective functions, and the System 100 can provide an effective, low-latency communication link between these devices without excessive amounts of wiring (and weight) while also powering these devices.Sensor networks in general can also take advantage of the features of System 100 to reduce wiring and can also use Bus 106 as a power supply network for the sensors. Distributed Intelligence Support

[0190] In some embodiments, the slave node 104 and the host 110 can each include receiving and transmitting mailboxes for communication with each other. Some embodiments can use I2C for mailbox communication; the I2C interface of a slave node 104 (e.g., managed by the I2C transceiver 129) can be configured as an I2C slave, so that a processing device can program the slave node 104 via I2C and initiate read and / or write operations on the mailboxes.

[0191] In some embodiments, the node transmitter 120 can include receive and send registers for a slave node 104, which can be used as input and output "mailboxes" for communication between a processing device 1302 of the host 110 and a processing device 1302 of the slave node 104 (e.g., a processing device separate from the node transmitter 120). The host 110 and the slave node 104 can be notified of data in their respective mailboxes by an interrupt triggered upon completion of the data write to the mailbox. The node transmitter 120 can be configured to generate an interrupt for a processing device 1302 contained in the slave node 104 upon completion of a data write to a relevant mailbox.

[0192] Fig. Figure 27 is a block representation of an arrangement 2700 in which a slave node 0 comprises a node transmitter 120 with a receiving mailbox 2710 and a sending mailbox 2712, enabling communication with a receiving mailbox 2704 and a sending mailbox 2708 of a host 110 (via a master node 102). In particular, data fed to the receiving mailbox 2710 can be transmitted to the processing device 1302 of slave node 0 via an interrupt generated by the node transmitter 120, and the processing device 1302 of slave node 0 can notify the node transmitter 120 that data for transmission to the host 110 is in the sending mailbox 2712.

[0193] The node transceiver 120 can include a number of registers for controlling these mailboxes. In some embodiments, registers MBOX0CTL and MBOX1CTL can provide fields to release these mailboxes and to control the direction, message length, and interrupt releases for the mailboxes.

[0194] Mailbox 0 can be configured as a default receiving mailbox (e.g., receiving mailbox 2710, into which host 110 writes and which a processing device 1302 of slave node 104 reads). Mailbox 1 can be configured as a default sending mailbox (e.g., sending mailbox 2712, into which a processing device 1302 of slave node 104 writes and which host 110 reads).

[0195] An MBxLEN field of the MBOXxCTL register can define the length of the associated mailbox. If this field is 0, MBOXxB0 can be the last byte of the mailbox. If this field is 1, MBOXxB1 can be the last byte of the mailbox. If this field is 2, MBOXxB2 can be the last byte of the mailbox. If this field is 3, MBOXxB3 can be the last byte of the mailbox.

[0196] For a shared receiving mailbox, if an MBxFIEN bit of the MBOXxCTL register is set, an interrupt can occur for the processing device 1302 of slave node 104 after the last byte of the assigned mailbox is written by host 110 and the node's transmit receiver 120 determines that a bus retry was not necessary. If an MBxEIEN field of the MBOXxCTL register is set, an interrupt can occur for host 110 after the last byte of the assigned mailbox is read by the processing device 1302 of slave node 104.

[0197] For a shared mailbox, if the MBxFIEN field is set, an interrupt can occur for host 110 after the last byte of the assigned mailbox is written by the processing device 1302 of slave node 104. If the MBxEIEN field is set, an interrupt can occur for the processing device 1302 of slave node 104 after the last byte of the assigned mailbox is read by host 110 and the node's send / receive receiver 120 determines that a bus retry was not necessary.

[0198] In some embodiments, the MBOX0STAT and MBOX1STAT registers can provide status information for the mailboxes. When a mailbox is full, an associated MBxFULL bit of the MBOXxSTAT register can be high, and the MBxEMPTY bit can be low. When a mailbox is empty, an associated MBxEMPTY bit of the MBOXxSTAT register can be high, and the MBxFULL bit can be low. The MBxEIRQ and MBxFIRQ bits contained in the MBOXxSTAT register can be high when the associated mailbox signals an interrupt to the host 110 or local processor (e.g., the processing device 1302 of slave node 104), and can be low when the interrupt is being processed by the host 110 or local processor.

[0199] In some embodiments, registers MBOX0Bn and MBOX1Bn can contain mailbox data. Each mailbox can hold up to 32 bits of data in some examples. An MBxLEN field in the MBOXxBn register can define the number of active bytes in the mailbox. In some embodiments, each mailbox can support 8-, 16-, 24-, or 32-bit messages. Sensor support

[0200] In some vehicle applications, the system 100 can include an array of slave nodes 104 on the bus 106 for connecting two microphones located on the left and right sides of the passenger compartment, respectively, as well as an environmental sensor coupled to a slave node 104 on the bus 106 and positioned between the microphones and near the windshield. The environmental sensor can measure temperature and humidity (e.g., for condensation control and air conditioning functions) and / or ambient gases (e.g., ammonia, carbon monoxide, nitrogen dioxide) for air redirection to improve passenger comfort. The microphones can be, for example, MEMS (microelectromechanical systems) microphone arrays.

[0201] In some embodiments, the node transceiver 120 of a slave node 104 comprises a peripheral device communication circuit (e.g., the 12S / TDM / PDM transceiver 127, the I2C transceiver 129, and / or one or more GPIO pins with interrupt request capability) communicating with an environmental sensor (such as a humidity sensor, temperature sensor, and / or gas sensor) in a vehicle. In some embodiments, the host 110 can generate a control instruction for an air conditioning system in the vehicle based on data from an environmental sensor, which is transmitted to the host 110 via a slave node 104, the bus 106, and the master node 102. For example, [reference to relevant figure] Fig. 28 an arrangement 2800 of the system 100, wherein a slave node 0 (on the left side of the passenger compartment) has a peripheral device 108 with a microphone and a loudspeaker, a slave node 1 (near a windshield 2802) has a peripheral device 108 with a humidity and / or temperature sensor, a slave node 2 has a peripheral device 108 with a gas sensor, and a slave node 3 (on the right side of the passenger compartment) has a peripheral device 108 with a microphone and a loudspeaker.

[0202] If microphones are included in vehicles on the left and right sides of the passenger compartment (e.g., for noise reduction and / or beam shaping), the wiring used to couple these microphones can be interrupted by intermediate slave nodes 104 that are coupled to the peripheral devices performing climate control functions (HVAC functions (Heating, Ventilation and Air Conditioning) and / or air monitoring functions) near the windshield area. In some scenarios, a peripheral device for a slave node 104 may include a humidity and / or temperature sensor that can provide humidity and / or temperature information allowing the measurement of the dew point on the windshield surface and the prediction of windshield condensation, so that the vehicle's HVAC system can operate "just in time" to prevent the windows from fogging up.Such a system can save energy compared to "always-on" or manually controlled HVAC systems and also improve safety during vehicle operation by preventing windshield fogging. An example of a humidity and / or temperature sensor that can be used in some embodiments is the HTU21D sensor manufactured by Measurement Specialties in Hampton, Virginia, USA. Similarly, data generated by a gas sensor that detects the presence of unwanted chemicals in the vehicle's passenger compartment air can be used to trigger operation of the vehicle's HVAC system to improve ventilation and reduce chemical concentrations. An example of a gas sensor that can be used in some embodiments is the MiCS-6814 sensor manufactured by SGX Sensortech in Switzerland. Integrated accelerometer

[0203] In some embodiments, a slave node 104 can be associated with a peripheral device 108 that includes an accelerometer (e.g., a multi-axis accelerometer) integrated on the same circuit board as the node transmitter-receiver 120 (e.g., the upstream transmitter-receiver 122 and / or the downstream transmitter-receiver 124). Audio inputs and outputs, such as microphones and loudspeakers, can also be coupled to the same circuit board. One application for such an embodiment could be road noise cancellation, where the vibration of the chassis is measured and the noise is canceled out by the audio components. Test equipment support

[0204] In some embodiments, a node transceiver 120 can be configured in a "bus monitor mode" or "BMM," in which the node transceiver 120 monitors upstream and / or downstream activity on a segment of the bus 106 for both master and slave node behavior (e.g., which signals are coming from and / or going to the master and / or slave). In some embodiments, the upstream transceiver 122 of the node transceiver 120 monitors downstream data and delivers it to a protocol analyzer (e.g., via an I2S bus using the I2S / TDM / PDM transceiver 127). A node transceiver 120 operating in bus monitor mode can be referred to here as a "bus monitor" or "BM." In this mode, the downstream transceiver 124 of the node transceiver 120 can be disabled.A bus monitor cannot be daisy-chained with other slave nodes 104, but it can tap into the pair of wires just upstream of a slave node 104 to be monitored and can be discovered by the master node 102, although it does not have all the functionality of a node transceiver 120 in a typical slave node 104. The bus monitor can initially be configured by a processor that communicates with the bus monitor (e.g., via an I2C protocol).

[0205] Thus, in some embodiments, a node transceiver 120 acting as a bus monitor can include a peripheral device communication circuit (e.g., the 12S / TDM / PDM transceiver 127, the I2C transceiver 129, and / or one or more GPIO pins with interrupt request capability) to provide a signal received via bus 106 from an upstream device to a protocol analyzer. In some embodiments, the downstream transceiver 124 of a node transceiver 120 operating in bus monitor mode can be disabled. The upstream transceiver 122 can be configured to receive data only, not to transmit it.

[0206] Fig. Figure 29 is a block diagram of an arrangement 2900 of elements of the system 100 and a bus monitor according to various embodiments. In the arrangement 2900, a bus monitor device 2902 can comprise a bus monitor 2906 and a processing device 2908 communicating with the bus monitor 2906 via I2C and / or I2S (e.g., using the I2S / TDM / PDM transceiver 127 and / or the I2C transceiver 129 of the bus monitor). The processing device 2908 can be of any form described above with reference to Fig. The processing devices 1302 discussed in section 13 are assumed. The BMM 2906 can tap the two wires of the bus 106 directly upstream of the slave node 1, and an isolation circuit 2904 can be arranged between the BMM 2906 and the bus 106. The isolation circuit 2904 can include an analog circuit for isolating the bus 106 from the load of the BMM 2906.

[0207] In some embodiments, the bus monitor mode can allow a node transceiver 120 to act as a passive BM, also referred to here as a sniffer. A BM can use its I2S port to send traffic from the bus 106 to a protocol analyzer. A BM can be passive in the system 100 insofar as it examines control write operations of the bus synchronization control frame 180 in order to configure its bus properties to match those of the slave node 104 that the BM monitors, but does not respond to synchronization control frames 180.

[0208] The upstream transceiver 122 can see both upstream and downstream data because the BM is not chained. In some embodiments, when receiving downstream data via the upstream transceiver 122, a BM can load a received synchronization control frame 180 and its corresponding downstream data slots 198 into a downstream frame buffer. In some embodiments, when receiving upstream data via the upstream transceiver 122, a BM can load a received synchronization response frame and its corresponding upstream data slots into an upstream frame buffer. The BM can feed both downstream and upstream data to the I12S / TDM / PDM transceiver 127 for provision to a protocol analyzer (e.g., the processing device 2908).

[0209] The node transceiver 120 may include one or more registers to support the BMM. In some embodiments, the node transceiver 120 may include a BMMCFG register. The BMMCFG register may include a BMMEN bit (to indicate whether the node transceiver 120 should operate in the BMM or not), a BMMRXEN bit (to enable or disable the upstream transceiver 122 when the node transceiver is in the BMM), and a BMMNDSC node (to indicate whether the system 100 ramp-up and discovery processes should occur before or after the BM is connected and enabled).

[0210] Fig. Figure 30 is a flowchart of a method 3000 for initiating the operation of a BM according to various embodiments. The method 3000 can be executed by the processing device 2908 in the bus monitor device 2902 and can be described as being executed with reference to the BM 2906.

[0211] In 3002, the processing device 2908 can release the BMM in the BM 2906. Before releasing the BMM, the BM 2906 can default to a standard configuration for the node transceiver 120. Releasing the BMM in 3002 can include setting the BMMEN bit discussed above.

[0212] In 3004, the processing device 2908 can be connected to the bus 106 upstream of a slave node 104 to be monitored (e.g., slave node 1 of) after the BM is connected to the bus 106 line. Fig. 29) Release the upstream transceiver 122 in BM 2906. Enabling the upstream transceiver 122 in BM 2906 may involve setting the BMMRXEN bit discussed above.

[0213] In 3006, the processing device 2908 can configure the BM 2906's 12S / TDM / PDM transceiver 127 for transmission using commands sent via the I2C transceiver 129.

[0214] In 3008, after the BM 2906 is discovered by the host 110 and the PLL 128 of the BM 2906 locks, the processing device 2908 can receive data from bus 106 via the BM 2906's 12S / TDM / PDM transceiver 127. As mentioned earlier, the BM 2906 can examine control write operations of the bus synchronization control frame 180 to configure its bus properties (e.g., the values ​​of DNSLOTS and UPSLOTS) to match those of the monitored slave node 104 (e.g., slave node 1 of Fig. 29) agree.

[0215] A BM can discover the segment of bus 106 to which it is connected and can also learn the configuration of the downstream slave node 104 if the BM is allowed to monitor bus 106 during discovery. Some monitored parameters may apply to the entire bus 106 (e.g., all slave nodes 104), some to the immediately downstream slave node 104, and some to slave nodes 104 further downstream. The BM can monitor the discovery, save the parameters from a more recent discovery, use known settings, or try different parameter variations until successful decoding is achieved (e.g., music data is successfully decoded).

[0216] In some embodiments, the payload information transmitted downstream on bus 106 can only be examined if the host 110 enables this functionality with a control instruction, which is forwarded by the master node 102 to a slave node 104, which is to act as a BM. In some such embodiments, if the BM is not configured accordingly by the master node 102, the BM can only output ("sniff") synchronization control and response frame data, but not the payload information in the data slots. This can provide a certain degree of content protection, since the data is scrambled and a BM can only access the payload data if the host 110 permits it. Slave-to-slave communication

[0217] In general, slave nodes 104 can output downstream data originating from the master node 102 on their DTXn pins. The transceiver can also selectively output upstream or downstream data originating from other slave nodes 104 without requiring data slots to be routed through the master node 102 first. Similarly, slave nodes 104 can generally receive input data destined for the master node 102 on their DRx pins. The transceiver can also directly provide upstream or downstream data to other slave nodes 104 without requiring data slots to be routed through the master node 102 first.

[0218] In embodiments that utilize this synchronous communication between multiple slave nodes 104, the slave nodes 104 can selectively receive bus upstream data slots on the DTXn pins. The system can skip DRXn data channels based on a programmable offset before the upstream slots are generated by the slave node 104.

[0219] Fig. Figures 31-65 show various examples of slave-to-slave communication systems and techniques. Any embodiments shown in these figures or discussed below with reference to them can be combined with any of the other embodiments disclosed herein. The use or representation of specific numbers of elements in these figures (e.g., 10 in Fig. The 31 upstream data slots shown are merely examples, and the systems and techniques can be applied to or integrated with any desired and suitable number of arbitrary elements. Furthermore, for the sake of clarity, specific names may be used here for registers, variables, data slots, etc., but any data structures used as described here may have any suitable names or other identifiers.

[0220] In some embodiments, registers or other data structures can be used to store data representing which upstream data slots a slave node 104 can use. For example, registers UPMASKO, UPMASK1, UPMASK2, and UPMASK3 can provide one bit for each possible upstream data slot. If any of these bits are set, the corresponding upstream data slot can be received by slave node 104 (e.g., by downstream transceiver 124) and placed in the TX frame buffer after any received downstream data slots. The UPSLOTS register can define the number of upstream data slots, starting immediately after the SRF, that are passed upstream by slave node 104 (e.g., by upstream transceiver 122).

[0221] In embodiments where no slave-to-slave communication occurs, a slave node 104 can receive UPSLOTS upstream data slots with the downstream transmit-receiver 124 and send (UPSLOTS + LUPSLOTS) upstream data slots with the upstream transmit-receiver 122. In embodiments where slave-to-slave communication occurs, the use of the registers UPMASKO to UPMASK3 can modify the calculation used to determine the number of received upstream data slots. In particular, a slave node 104 can receive MAX (UPSLOTS, upmaskrx) upstream data slots with the downstream transmit-receiver 124 and send (UPSLOTS + LUPSLOTS) upstream data slots with the upstream transmit-receiver 122, where upmaskrx can be calculated as follows: if (RXUPSLOT31==1) upmaskrx = 32; else if (RXUPSLOT30==1) upmaskrx = 31; else if (RXUPSLOT29==1) upmaskrx = 30; ...else if (RXUPSLOT02==1) upmaskrx = 3; else if (RXUPSLOT01==1) upmaskrx = 2; else if (RXUPSLOT00==1) upmaskrx = 1; else upmaskrx = 0.

[0222] Since it is possible for a slave node 104 to receive upstream data slots that are not forwarded, the slave node 104 can send local upstream data slots to the upstream transceiver 122 while still receiving upstream data slots to the downstream transceiver 124.

[0223] A slave node 104, which generates upstream data slots, typically starts with the first entry in the RX frame buffer. In some embodiments, if used, an UPOFFSET register can define an offset to be applied in the RX frame buffer before data is taken and sent upstream.

[0224] Fig. Figure 31 gives an example of how upstream data slots in a slave node 104 can be used for slave-to-slave communication after programming the registers UPMASKO,..., UPMASK3, and UPOFFSET, according to various embodiments. The A-side transmit-receiver can be the upstream transmit-receiver 122, and the B-side transmit-receiver can be the downstream transmit-receiver 124. In the example of Fig. 31 Slave node 104 can receive 10 upstream data slots (UP0 to UP9) provided upstream by the downstream slave node for the B-side transmit receiver of the current slave node 104. In this example, six slots (UP0, UP1, UP6-9) are used locally for transmit data output. Two of these slots are forwarded to the upstream slave node 104, with an additional four slots not used by this node (UPSLOTS=6). Four slots are removed from the data frame and replaced here by four slots (LUPSLOTS=4) of locally provided receive data. When data slots are removed from bus 106, they may be replaced with a different number of slots (exceeding or decreasing the initial number) or not replaced at all.

[0225] Fig. Figure 32 shows an UPMASKO register that defines bits 7 to 0 of a 32-bit UPMASK field. As discussed above, in a slave node 104, the UPMASK field can define the upstream data slots that are received by the slave node 104 (the "local" slave node) from the bus 106 by the downstream transceiver 124. These data slots can be transmitted over I2S / TDM and can follow any downstream slots received by the slave node 104 (defined in LDNSLOTS). In some embodiments, changes to this register do not take effect until a CONTROL.NEWSTRCT bit of the master node 102 is set. Table 1 gives bit descriptions for an example UPMASKO register. Each bit set in the RXUPSLOT registers can indicate that upstream data is intercepted by upstream slave node 104. Table 1. Bit Bitname Einstellungen Beschreibung Rücksetzen Zugriff 7 RXUPSLOT07 Upstream-Datenschlitz 7 empfangen. 0x0 R / W Dieses Bit definiert, ob der Upstream-Datenschlitz 7 durch den lokalen Slave-Knoten empfangen wird oder nicht. 1 Upstream-Datenschlitz 7 RX- Freigegeben 0 Upstream-Datenschlitz 7 RX-Gesperrt 6 RXUPSLOT06 Upstream-Datenschlitz 6 empfangen. 0x0 R / W This bit defines whether the upstream data slot 6 is received by the local slave node or not. 1 Upstream data slot 6 RX- Released 0 Upstream data slot 6 RX locked 5 RXUPSLOT05 Received upstream data slot 5. 0x0 R / W This bit defines whether the upstream Data slot 5 is received by the local slave node or not. 1 Upstream data slot 5 RX enabled 0 Upstream data slot 5 RX locked 4 RXUPSLOT04 Received upstream data slot 4. 0x0 R / W This bit defines whether the upstream data slot 4 is received by the local slave node or not. 1 Upstream data slot 4 RX- Released 0 Upstream data slot 4 RX locked 3 RXUPSLOT03 Received upstream data slot 3. 0x0 R / W This bit defines whether the upstream data slot 3 is received by the local slave node or not. 1 Upstream data slot 3 RX- Released 0 Upstream data slot 3 RX locked 2 RXUPSLOT02 Received upstream data slot 2. 0x0 R / W This bit defines whether the upstream data slot 2 is received by the local slave node or not. 1 Upstream data slot 2 RX- Released 0 Upstream data slot 2 RX locked 1 RXUPSLOT01 Received upstream data slot 1. 0x0 R / W This bit defines whether the upstream data slot 1 is received by the local slave node or not. 1 Upstream data slot 1 RX- Released 0 Upstream data slot 1 RX locked 0 RXUPSLOT00 Upstream data slot 0 received. 0x0 R / W This bit defines whether the upstream data slot 0 is received by the local slave node or not. 1 Upstream data slot 0 RX- Released 0 Upstream data slot 0 RX locked

[0226] Fig.Figure 33 shows an UPMASK1 register that defines bits 15 to 8 of the 32-bit UPMASK field. As discussed above, in a slave node 104, the UPMASK field can define the upstream data slots that are received by the slave node 104 via the downstream transceiver 124 from the bus 106. These data slots can be transmitted via I2S / TDM and can follow any downstream slots received by the upstream transceiver 122 of the slave node 104 (defined in LDNSLOTS). In some embodiments, changes to this register do not take effect until the CONTROL.NEWSTRCT bit of the master node 102 is set. Table 2 gives bit descriptions for an example UPMASK1 register. Table 2. bit Bitname Settings Description Reset access 7 RXUPSLOT15 Received upstream data slot 15. 0x0 R / W This bit defines whether the upstream data slot 15 is received by the local slave node or not. 1 Upstream data slot 15 RX- Released 0 Upstream data slot 15 RX locked 6 RXUPSLOT14 Received upstream data slot 14. 0x0 R / W This bit defines whether the upstream data slot 14 is received by the local slave node or not. 1 Upstream data slot 14 RX- Released 0 Upstream data slot 14 RX locked 5 RXUPSLOT13 Received upstream data slot 13. 0x0 R / W This bit defines whether the upstream data slot 13 is received by the local slave node or not. 1 Upstream data slot 13 RX- Released 0 Upstream data slot 13 RX locked 4 RXUPSLOT12 Received upstream data slot 12. 0x0 R / W This bit defines whether the upstream data slot 12 is by the local The slave node will receive the data or not. 1 Upstream data slot 12 RX- Released 0 Upstream data slot 12 RX locked 3 RXUPSLOT11 Received upstream data slot 11. 0x0 R / W This bit defines whether the upstream data slot 11 is received by the local slave node or not. 1 Upstream data slot 11 RX- 0 Released Upstream Data Slot 11 RX Locked 2 RXUPSLOT10 Received upstream data slot 10. 0x0 R / W This bit defines whether the upstream data slot 10 is received by the local slave node or not. 1 Upstream data slot 10 RX- Released 0 Upstream data slot 10 RX locked 1 RXUPSLOT09 Received upstream data slot 9. 0x0 R / W This bit defines whether the upstream data slot 9 is received by the local slave node or not. 1 Upstream data slot 9 RX- Released 0 Upstream data slot 9 RX locked 0 RXUPSLOT08 Received upstream data slot 8. 0x0 R / W This bit defines whether the upstream data slot 8 is received by the local slave node or not. 1 Upstream data slot 8 RX- Released 0 Upstream data slot 8 RX locked

[0227] Fig.Figure 34 shows an UPMASK2 register that defines bits 23 to 16 of the 32-bit UPMASK field. As discussed above, in a slave node 104, the UPMASK field can define the upstream data slots received by the local node with the downstream transceiver 124 from the bus 106. These data slots can be transmitted via I2S / TDM and can follow any downstream slots received by the slave node 104 (defined in LDNSLOTS). In some embodiments, changes to this register only take effect after the CONTROL.NEWSTRCT bit of the master node 102 is set. Table 3 gives bit descriptions for an example UPMASK2 register. Table 3. bit Bitname Settings Description Reset access 7 RXUPSLOT23 Received upstream data slot 23. 0x0 R / W This bit defines whether the upstream data slot 23 is received by the local slave node or not. 1 Upstream data slot 23 RX- Released 0 Upstream data slot 23 RX locked 6 RXUPSLOT22 Received upstream data slot 22. 0x0 R / W This bit defines whether the upstream data slot 22 is received by the local slave node or not. 1 Upstream data slot 22 RX- Released 0 Upstream data slot 22 RX locked 5 RXUPSLOT21 Received upstream data slot 21. 0x0 R / W This bit defines whether the upstream data slot 21 is received by the local slave node or not. 1 Upstream data slot 21 RX- Released 0 Upstream data slot 21 RX - Locked 4 RXUPSLOT20 Upstream data slot 20 received. 0x0 R / W This bit defines whether the upstream data slot 20 is received by the local slave node or not. 1 Upstream data slot 20 RX- Released 0 Upstream data slot 20 RX - Locked 3 RXUPSLOT19 Upstream data slot 19 received. 0x0 R / W This bit defines whether the upstream Data slot 19 is received by the local slave node or not. 1 Upstream data slot 19 RX- Released 0 Upstream data slot 19 RX locked 2 RXUPSLOT18 Upstream data slot 18 received. 0x0 R / W This bit defines whether the upstream data slot 18 is received by the local slave node or not. 1 Upstream data slot 18 RX- Released 0 Upstream data slot 18 RX locked 1 RXUPSLOT17 Received upstream data slot 17. 0x0 R / W This bit defines whether the upstream data slot 17 is received by the local slave node or not. 1 Upstream data slot 17 RX- Released 0 Upstream data slot 17 RX locked 0 RXUPSLOT16 Received upstream data slot 16. 0x0 R / W This bit defines whether the upstream data slot 16 is received by the local slave node or not. 1 Upstream data slot 16 RX- Released 0 Upstream data slot 16 RX locked

[0228] Fig.Figure 35 shows an UPMASK3 register that defines bits 31 to 24 of the 32-bit UPMASK field. As discussed above, in a slave node 104, the UPMASK field can define the upstream data slots received by the local node from bus 106. These data slots can be transmitted over I2S / TDM and can follow any downstream slots received by slave node 104 (defined in LDNSLOTS). In some embodiments, changes to this register do not take effect until the CONTROL.NEWSTRCT bit of the master node 102 is set. Table 4 gives bit descriptions for an example UPMASK3 register. Table 4. bit Bitname Settings Description Reset access 7 RXUPSLOT31 Upstream data slot 31 received. 0x0 R / W This bit defines whether the upstream data slot 31 is received by the local slave node or not. 1 Upstream data slot 31 RX- Released 0 Upstream data slot 31 RX locked 6 RXUPSLOT30 Upstream data slot 30 received. 0x0 R / W This bit defines whether the upstream data slot 30 is received by the local slave node or not. 1 Upstream data slot 30 RX- Released 0 Upstream data slot 30 RX locked 5 RXUPSLOT29 Received upstream data slot 29. 0x0 R / W This bit defines whether the upstream data slot 29 is received by the local slave node or not. 1 Upstream data slot 29 RX- Released 0 Upstream data slot 29 RX locked 4 RXUPSLOT28 Upstream data slot 28 received. 0x0 R / W This bit defines whether the upstream data slot 28 is received by the local slave node or not. 1 Upstream data slot 28 RX- Released 0 Upstream data slot 28 RX locked 3 RXUPSLOT27 Received upstream data slot 27. 0x0 R / W This bit defines whether the upstream data slot 27 is received by the local slave node or not. 1 Upstream data slot 27 RX- Released 0 Upstream data slot 27 RX locked 2 RXUPSLOT26 Upstream data slot 26 received. 0x0 R / W This bit defines whether the upstream data slot 26 is received by the local slave node or not. 1 Upstream data slot 26 RX- Released 0 Upstream data slot 26 RX locked 1 RXUPSLOT25 Upstream data slot 25 received. 0x0 R / W This bit defines whether the upstream data slot 25 is received by the local slave node or not. 1 Upstream data slot 25 RX- Released 0 Upstream data slot 25 RX locked 0 RXUPSLOT24 Upstream data slot 24 received. 0x0 R / W This bit defines whether the upstream data slot 24 is received by the local slave node or not. 1 Upstream data slot 24 RX- Released 0 Upstream data slot 24 RX locked

[0229] Fig.Figure 36 shows an example local upstream slot offset register (UPOFFSET). In a slave node 104, the UPOFFSET register can define a number of data slots received via I2S / TDM / PDM that are skipped before data slots are transmitted upstream through the upstream transceiver 122 on bus 106. Table 5 gives bit descriptions for an example UPOFFSET register. In some embodiments, instead of a UPOFFSET register, a node can use an RX data mask to selectively decide which data channels of an I2S / TDM frame to provide. Table 5. bit Bitname Settings Description Reset access [7:5] RESERVED Reserved. 0x00 R / W [4:0] UPOFFSET Upstream slot offset for local 0x00 R / W Nodes. This bit field defines the Number of data slots received via I2S / TDM / PDM that are skipped before data slots are transmitted upstream on the bus.

[0230] Analog operations can occur for downstream communication. In particular, slave node 104 can selectively receive bus downstream slots on the DTXn pins. The slave node 104 can generate downstream slots on bus 106 from the DRXn pin using a programmable offset. This operating mode therefore allows slave node 104 to both receive and send downstream data.

[0231] In some embodiments, registers or other data structures can be used to store data about which upstream data slots a slave node 104 can use. For example, registers DNMASK0, DNMASK1, DNMASK2, and DNMASK3 can provide one bit for each possible downstream data slot. When the LDNSLOTS.DNMASKEN bit is set, these bits select which downstream slots are consumed by the local node and place them in the TX frame buffer. When the LDNSLOTS.DNMASKEN bit is not set, the LDNSLOTS register can define the number of downstream slots consumed by the local node. The DNSLOTS register can define the number of downstream data slots, starting immediately after the SCF, that are routed downstream (e.g., through the downstream transmit receiver 124) through the slave node 104.A variable dnmaskrx can be defined as follows: if (RXDNSLOT31==1) dnmaskrx = 32; else if (RXDNSLOT30==1) dnmaskrx = 31; else if (RXDNSLOT29==1) dnmaskrx = 30; ... else if (RXDNSLOT02==1) dnmaskrx = 3; else if (RXDNSLOT01==1) dnmaskrx = 2; else if (RXDNSLOT00==1) dnmaskrx = 1; else dnmaskrx = 0.

[0232] In the case dnmaskrx==0, a slave node 104 can receive (BCDNSLOTS + DNSLOTS + LDNSLOTS) downstream data slots and send (BCDNSLOTS + DNSLOTS) downstream data slots. In the case dnmaskrx!=0, a slave node 104 can receive MAX(DNSLOTS, dnmaskrx) downstream data slots and send (DNSLOTS + LDNSLOTS) downstream data slots. Since it is possible for a slave node 104 to send downstream data slots, the slave node 104 can send local downstream data slots on the downstream transceiver 124 while still receiving upstream data slots on the upstream transceiver 122. Note that setting the LDNSLOTS.DNMASKEN bit in a slave node 104 can change the meaning of the LDNSLOTS register and cause the BCDNSLOTS register to be ignored.

[0233] In some embodiments, a DNOFFSET register can define an offset to be applied in the RX frame buffer before data is taken and sent downstream by the downstream transmit receiver 124. The value of the DNOFFSET register can only be used if the slave node 104 is configured to send downstream data (e.g., if the DNMASKO,..., DNMASK3 registers are not all zero and LDNSLOTS is not zero). In a slave node 104, the meaning of the LDNSLOTS register can change depending on the LDNSLOTS.DNMASKEN bit. If the LDNSLOTS.DNMASKEN bit = 0, the LDNSLOTS register can define the number of data slots acquired by the slave node 104 during the downstream portion of the superframe. These data slots can be consumed by slave node 104 and cannot be forwarded to the next slave node 104 downstream. If this is LDNSLOTS.With the DNMASKEN bit set to 1, the LDNSLOTS register can define the number of data slots added by slave node 104 during the downstream portion of the superframe. These data slots can be added after the DNSLOTS data slots have been routed downstream through the local node.

[0234] Fig. Figure 37 gives an example of how downstream data slots in a slave node 104 can be used for slave-to-slave communication after programming the registers DNMASKO,..., DNMASK3, and DNOFFSET, according to various embodiments. The A-side transmit-receiver can be the upstream transmit-receiver 122, and the B-side transmit-receiver can be the downstream transmit-receiver 124. In the example of Fig. 37 The slave node can provide 10 downstream data slots because RXDNSLOT09 is set and the value of DNSLOTS is 6.

[0235] Fig.Figure 38 shows an example of a DNMASKO register that defines bits 7 to 0 of a 32-bit DNMASK field. As discussed above, in a slave node 104, if any bits in DNMASKEN are set, the DNMASK field can define the downstream data slots received by the local node from bus 106. These data slots can be transmitted via I2S / TDM. If DNMASKEN is not set, the LDNSLOTS register can define the number of downstream data slots taken by the local slave node 104. In some embodiments, changes to this register do not take effect until the CONTROL.NEWSTRCT bit of the master node 102 is set. Table 6 gives bit descriptions for an example DNMASKO register. Table 6. bit Bitname Settings Description Reset access 7 RXDNSLOT07 Downstream data slot 7 0x0 R / W Received. This bit defines whether the downstream data slot 7 is received by the local slave node or not. 1 Downstream data slot 7 RX- Released 0 Downstream data slot 7 RX- Blocked 6 RXDNSLOT06 Downstream data slot 6 0x0 R / W Received. This bit defines whether the downstream data slot 6 is received by the local slave node or not. 1 Downstream data slot 6 RX- Released 0 Downstream data slot 6 RX- Blocked 5 RXDNSLOT05 Downstream data slot 5 0x0 R / W Received. This bit defines whether the downstream data slot 5 is received by the local slave node or not. 1 Downstream data slot 5 RX- Released 0 Downstream data slot 5 RX- Blocked 4 RXDNSLOT04 Downstream data slot 4 0x0 R / W Received. This bit defines whether the downstream data slot 4 is received by the local slave node or not. 1 Downstream data slot 4 RX- Released 0 Downstream data slot 4 RX- Blocked 3 RXDNSLOT03 Downstream data slot 3 0x0 R / W Received. This bit defines whether the downstream data slot 3 is received by the local slave node or not. 1 Downstream data slot 3 RX- Released 0 Downstream data slot 3 RX- Blocked 2 RXDNSLOT02 Downstream data slot 2 0x0 R / W Received. This bit defines whether the downstream data slot 2 is received by the local slave node or not. 1 Downstream data slot 2 RX- Released 0 Downstream data slot 2 RX- Blocked 1 RXDNSLOT01 Downstream data slot 1 0x0 R / W Received. This bit defines whether the downstream data slot 1 is received by the local slave node or not. 1 Downstream data slot 1 RX- Released 0 Downstream data slot 1 RX- Blocked 0 RXDNSLOT00 Downstream data slot 0 0x0 R / W Received. This bit defines whether the downstream data slot 0 is received by the local slave node or not. 1 Downstream data slot 0 RX- Released 0 Downstream data slot 0 RX- Blocked

[0236] Fig.Figure 39 shows an example DNMASK1 register, which defines bits 15 to 8 of the 32-bit DNMASK field. As discussed above, in a slave node 104, if any bits in DNMASKEN are set, the DNMASK field can define the downstream data slots received from bus 106 by the upstream transceiver 122 of the local slave node 104. These data slots can be transmitted via I2S / TDM. If DNMASKEN is not set, the LDNSLOTS register can define the number of downstream data slots taken by the local node. In some embodiments, changes to this register do not take effect until the CONTROL.NEWSTRCT bit of the master node 102 is set. Table 7 gives bit descriptions for an example DNMASK1 register. Table 7. bit Bitname Settings Description Reset access 7 RXDNSLOT15 Downstream data slot 15 0x0 R / W received. This bit defines whether the downstream data slot 15 is received by the local slave node or not. 1 Downstream data slot 15 RX- Released 0 Downstream data slot 15 RX- Blocked 6 RXDNSLOT14 Downstream data slot 14 0x0 R / W Received. This bit defines whether the downstream data slot 14 is received by the local slave node or not. 1 Downstream data slot 14 RX- Released 0 Downstream data slot 14 RX- Blocked 5 RXDNSLOT13 Downstream data slot 13 0x0 R / W received. This bit defines whether the downstream data slot 13 is received by the local slave node or not. 1 Downstream data slot 13 RX- Released 0 Downstream data slot 13 RX- Blocked 4 RXDNSLOT12 Downstream data slot 12 0x0 R / W received. This bit defines whether the downstream data slot 12 is passed through the is received by the local slave node or not. 1 Downstream data slot 12 RX- Released 0 Downstream data slot 12 RX- Blocked 3 RXDNSLOT11 Downstream data slot 11 0x0 R / W received. This bit defines whether the downstream data slot 11 is received by the local slave node or not. 1 Downstream data slot 11 RX- Released 0 Downstream data slot 11 RX- Blocked 2 RXDNSLOT10 Downstream data slot 10 0x0 R / W received. This bit defines whether the downstream data slot 10 is received by the local slave node or not. 1 Downstream data slot 10 RX- Released 0 Downstream data slot 10 RX- Blocked 1 RXDNSLOT09 Downstream data slot 9 0x0 R / W Received. This bit defines whether the downstream data slot 9 is received by the local slave node or not. 1 Downstream data slot 9 RX- Released 0 Downstream data slot 9 RX- Blocked 0 RXDNSLOT08 Downstream data slot 8 0x0 R / W Received. This bit defines whether the downstream data slot 8 is received by the local slave node or not. 1 Downstream data slot 8 RX- Released 0 Downstream data slot 8 RX locked

[0237] Fig.Figure 40 shows an example DNMASK2 register, which defines bits 23 to 16 of the 32-bit DNMASK field. As discussed above, in a slave node 104, if any bits in DNMASKEN are set, the DNMASK field can define the downstream data slots received from bus 106 by the upstream transceiver 122 of the local slave node 104. These data slots can be transmitted via I2S / TDM. If DNMASKEN is not set, the LDNSLOTS register can define the number of downstream data slots taken by the local node. In some embodiments, changes to this register do not take effect until the CONTROL.NEWSTRCT bit of the master node 102 is set. Table 8 gives bit descriptions for an example DNMASK2 register. Table 8. bit Bitname Settings Description Reset access 7 RXDNSLOT23 Downstream data slot 23 0x0 R / W Received. This bit defines whether the downstream data slot 23 is received by the local slave node or not. 1 Downstream data slot 23 RX- Released 0 Downstream data slot 23 RX- Blocked 6 RXDNSLOT22 Downstream data slot 22 0x0 R / W Received. This bit defines whether the downstream data slot 22 is received by the local slave node or not. 1 Downstream data slot 22 RX- Released 0 Downstream data slot 22 RX- Blocked 5 RXDNSLOT21 Downstream data slot 21 0x0 R / W Received. This bit defines whether the downstream data slot 21 is received by the local slave node or not. 1 Downstream data slot 21 RX- Released Downstream data slot 21 RX- Blocked 4 RXDNSLOT20 Downstream data slot 20 0x0 R / W Received. This bit defines whether the downstream data slot 20 is received by the local slave node or not. 1 Downstream data slot 20 RX- Released Downstream data slot 20 RX- 0 Blocked 3 RXDNSLOT19 Downstream data slot 19 0x0 R / W Received. This bit defines whether the downstream data slot 19 is received by the local slave node or not. 1 Downstream data slot 19 RX- Released 0 Downstream data slot 19 RX- Blocked 2 RXDNSLOT18 Downstream data slot 18 0x0 R / W received. This bit defines whether the downstream data slot 18 is received by the local slave node or not. 1 Downstream data slot 18 RX- Released 0 Downstream data slot 18 RX- Blocked 1 RXDNSLOT17 Downstream data slot 17 0x0 R / W received. This bit defines whether the downstream data slot 17 is received by the local slave node or not. 1 Downstream data slot 17 RX- 0 Released 17 RX Downstream data slot 17 RX- Blocked 0 RXDNSLOT16 Downstream data slot 16 0x0 R / W received. This bit defines whether the downstream data slot 16 is received by the local slave node or not. 1 Downstream data slot 16 RX- Released 0 Downstream data slot 16 RX- Blocked

[0238] Fig.Figure 41 shows an example DNMASK3 register, which defines bits 31 to 24 of the 32-bit DNMASK field. As discussed above, in a slave node 104, if any bits in DNMASKEN are set, the DNMASK field can define the downstream data slots received from bus 106 by the upstream transceiver 122 of the local slave node 104. These data slots can be transmitted via I2S / TDM. If DNMASKEN is not set, the LDNSLOTS register can define the number of downstream data slots taken by the local node. In some embodiments, changes to this register do not take effect until the CONTROL.NEWSTRCT bit of the master node 102 is set. Table 9 gives bit descriptions for an example DNMASK3 register. Table 9. bit Bitname Settings Description Reset access 7 RXDNSLOT31 Downstream data slot 31 0x0 R / W Received. This bit defines whether the downstream data slot 31 is received by the local slave node or not. 1 Downstream data slot 31 RX- Released 0 Downstream data slot 31 RX- Blocked 6 RXDNSLOT30 Downstream data slot 30 0x0 R / W Received. This bit defines whether the downstream data slot 30 is received by the local slave node or not. 1 Downstream data slot 30 RX- Released 0 Downstream data slot 30 RX- Blocked 5 RXDNSLOT29 Downstream data slot 29 0x0 R / W Received. This bit defines whether the downstream data slot 29 is received by the local slave node or not. 1 Downstream data slot 29 RX- Released 0 Downstream data slot 29 RX- Blocked 4 RXDNSLOT28 Downstream data slot 28 0x0 R / W Received. This bit defines whether the downstream data slot 28 is received by the local slave node or not. 1 Downstream data slot 28 RX- Released 0 Downstream data slot 28 RX- Blocked 3 RXDNSLOT27 Downstream data slot 27 0x0 R / W received. This bit defines whether the downstream data slot 27 is received by the local slave node or not. 1 Downstream data slot 27 RX- Released 0 Downstream data slot 27 RX- Blocked 2 RXDNSLOT26 Downstream data slot 26 0x0 R / W Received. This bit defines whether the downstream data slot 26 is received by the local slave node or not. 1 Downstream data slot 26 RX- Released 0 Downstream data slot 26 RX- Blocked 1 RXDNSLOT25 Downstream data slot 25 0x0 R / W received. This bit defines whether the downstream data slot 25 is passed through the is received by the local slave node or not. 1 Downstream data slot 25 RX- Released 0 Downstream data slot 25 RX- Blocked 0 RXDNSLOT24 Downstream data slot 24 0x0 R / W Received. This bit defines whether the downstream data slot 24 is received by the local slave node or not. 1 Downstream data slot 24 RX- Released 0 Downstream data slot 24 RX- Blocked

[0239] Fig.Figure 42 shows an example of a local downstream slot offset register (DNOFFSET). In a slave node 104, the DNOFFSET register can define a number of data slots received via I2S / TDM / PDM that are skipped before data slots are transmitted downstream through the slave node 104 on bus 106. The value in the DNOFFSET register can only be used if any of the bits in DNMASKEN are set. Table 10 gives bit descriptions for an example DNOFFSET register. Table 10. bit Bitname Settings Description Reset access [7:5] RESERVED Reserved. 0x00 R / W [4:0] DNOFFSET Downstream slot offset for local 0x00 R / W Nodes. This bit field defines the number of data slots received via I2S / TDM / PDM that are skipped before data slots are transmitted downstream on the bus.

[0240] Fig.Figure 43 shows an example of a local downstream slots register (LDNSLOTS). In a slave node 104, the meaning of the LDNSLOTS register can change depending on whether DNMASKEN is set or not. If DNMASKEN is 0, the LDNSLOTS register can define the number of data slots captured by the local slave node 104 during the downstream portion of the superframe. These data slots are consumed by the local slave node 104 and are not passed downstream to the next slave node 104. If DNMASKEN is 1, the LDNSLOTS register can define the number of data slots added by the local slave node 104 during the downstream portion of the superframe. These data slots are added after DNSLOTS data slots have been passed downstream by the local slave node 104. In some embodiments, changes to this register only take effect after the CONTROL.The NEWSTRCT bit of master node 102 has been set. The LDNSLOTS register can only be relevant in slave node 104. Table 11 gives bit descriptions for an example LDNSLOTS register. Table 11. bit Bitname Description Specification 7 DNMASKS New Downstream Broadcast Approval 'h0 1'b0 - Downstream data slot mask locked 1'b1 - Downstream data slot mask enabled 6 Reserved 0 5:0 LDNSLOTS Number of downstream slots targeted in the local node 'h0 The LDNSLOTS field defines the number of data slots captured by the local node during the downstream portion of the superframe. These bits should be programmed with a value between 0 and 32.

[0241] Fig. 44 and Fig. Figure 45 shows various exemplary scenarios that use any of the slave-to-slave communication techniques revealed here. Fig.Figure 44 shows a first arrangement (left) in which upstream transmissions from a microphone in a third slave node 104 on bus 106 must pass through the master node 102 and the host 110 before being routed downstream to loudspeakers coupled to a first and second slave node 104, and a second slave-to-slave arrangement (right) in which upstream transmissions from the microphone can be routed directly upstream to the loudspeakers without having to pass through the master node 102 and the host 110 (e.g., a DSP). The arrangements of Fig. 44 allows slave nodes 104, which are closer to the master node 102, to directly consume data from slave nodes 104 that are farther away from the master node 102, without routing data through the master node 102 or the host 110. This can reduce communication latency and save bus bandwidth.

[0242] Fig.Figure 45 shows a first arrangement (left) in which downstream transmissions from a microphone in a first slave node 104 on bus 106 must be routed upstream through the master node 102 and the host 110 before being routed downstream to loudspeakers coupled to a second and third slave node 104, and a second slave-to-slave arrangement (right) in which communication from the microphone can be routed directly upstream to the loudspeakers without having to pass through the master node 102 and the host 110 (e.g., a DSP). The arrangements of Fig. 45 allows slave nodes 104, which are closer to the master node 102, to directly supply data from slave nodes 104 that are farther away from the master node 102, without routing data through the master node 102 or the host 110. This can reduce communication latency and save bus bandwidth.

[0243] Fig.Figures 46-55 show an example of slave-to-slave communication on a chained bus with multiple nodes according to various embodiments discussed here. In particular, they show Fig. Figures 46-55 each show how data can move on a bus 106 in a particular example system 100 according to various embodiments disclosed herein, and also show the structure of superframes relayed between adjacent nodes on the bus 106. As discussed above, the length of a superframe can depend on the sampling rate; for example, in some embodiments, a superframe can have a length of 20.83 microseconds when the sampling rate is 48 kilohertz.

[0244] Fig.Figure 46 shows an exemplary System 100 with a host 110 coupled to a stereo tuner 111. The host 110 is coupled to a master node 102, and the master node 102 is coupled to a chain of four slave nodes 104 (identified as Slave 0, Slave 1, Slave 2, and Slave 3). Each of the slave nodes 104 in the System 100 of Fig. 46 is coupled to one or more associated peripheral devices 108. In particular, as in Fig. Figure 46 shows Slave 0 coupled with one microphone, Slave 1 coupled with six loudspeakers, Slave 2 coupled with one microphone, and Slave 3 coupled with two microphones. Slave 1 may, for example, include an amplifier that drives its assigned loudspeakers. As mentioned above, the specific number and type of slave nodes 104 and the specific number and type of peripheral devices 108, which are shown in Fig. 46 (and Fig.47-55) are shown only as examples, and any suitable number and type may be used according to the techniques disclosed herein.

[0245] Fig. Figure 46 also shows a scenario in which the master node 102 receives data from the tuner 111 (e.g., left and right audio data) and the master node 102 prepares to send a superframe downstream to slave 0. As in Fig. As shown in Figure 46, the downstream superframe sent from master node 102 to slave 0 begins with an SCF and is followed by a downstream data slot each for the left and right audio data from tuner 111. In this scenario, the DNSLOTS value for master node 102 is 2.

[0246] Fig. Figure 47 shows a scenario in which Slave 0 receives a superframe from Master Node 102, as in Fig. 46 is shown, has received, and is preparing to send a superframe downstream to Slave 1. As shown in Fig. As shown in Figure 47, the downstream superframe sent from Slave 0 to Slave 1 begins with an SCF and is followed by a downstream data slot each for the left and right audio data from tuner 111 (received by master node 102) and a downstream data slot for microphone data generated by the microphone associated with Slave 0. The value of DNSLOTS is 2 for Slave 0 (indicating that two downstream slots are occupied by data received from an upstream node), and the value of LDNSLOTS is 1 for Slave 0 (indicating that Slave 0 adds a single downstream slot of data). The value of DNMASKO is 0 for Slave 0 in this scenario (indicating that Slave 0 will not consume any of the data sent by master node 102).

[0247] Fig. Figure 48 shows a scenario in which Slave 1 has received a superframe from Slave 0, as in Fig.47 is shown, and is preparing to send a superframe downstream to Slave 2. As shown in Fig.As shown in Figure 48, Slave 1 will "consume" all the data from Slave 0 (i.e., the left and right audio data from tuner 111 and the data from the microphone associated with Slave 0) and will not return any data or add any other data to the superframe sent from Slave 1 to Slave 2. In some embodiments, Slave 1 uses all the consumed data from Slave 0 by outputting this data to the loudspeakers associated with Slave 1. The superframe sent downstream from Slave 1 to Slave 2 thus begins with an SCF and is not followed by any additional data. The value of DNSLOTS is 0 for Slave 1 (indicating that no downstream data slots will be occupied by data received from an upstream node), and the value of LDNSLOTS is 0 for Slave 1 (indicating that Slave 1 will not add any downstream data slots).The value of DNMASKO for Slave 1 in this scenario is 7 (which indicates that Slave 1 is consuming the data received by Slave 0 in the downstream slots associated with mask values ​​1, 2 and 4).

[0248] Fig. Figure 49 shows a scenario in which Slave 2 has received a superframe from Slave 1, as in Fig. 48 is displayed (i.e., only the SCF) and is preparing to send a superframe downstream to Slave 3. As shown in Fig.As shown in Figure 49, Slave 2 does not add any other data to the superframe sent from Slave 2 to Slave 3. The superframe sent downstream from Slave 2 to Slave 3 thus begins with an SCF and is not followed by any additional data. The value of DNSLOTS is 0 for Slave 2 (indicating that no downstream data slots are occupied by data received from an upstream node), and the value of LDNSLOTS is also 0 for Slave 2 (indicating that Slave 2 will not add any downstream data slots). The value of DNMASKO is 0 for Slave 2 in this scenario (indicating that Slave 2 does not consume any data received from Slave 1).

[0249] Fig. Figure 50 shows a scenario in which Slave 3 has received a superframe from Slave 2, as in Fig.49 is shown (i.e., only the SCF). Since Slave 3 is the last slave node 104 on bus 106, it does not need to perform any downstream transmissions. The value of DNSLOTS is 0 for Slave 3 (indicating that no downstream data slots are occupied by data received from an upstream node), and the value of LDNSLOTS is also 0 for Slave 3 (indicating that Slave 3 is not adding any downstream data slots). The value of DNMASKO is 0 for Slave 3 in this scenario (indicating that Slave 3 is not consuming any data received from Slave 2).

[0250] Fig. 51 shows a scenario in which Slave 3, after receiving a superframe from Slave 2 as above, with reference to Fig. 50 discussed and prepared to send a superframe back upstream to Slave 2. As in Fig.As shown in Figure 51, the upstream superframe sent by Slave 3 to Slave 2 begins with an SRF and is followed by an upstream data slot for each of the two microphones associated with Slave 3. The value of UPSLOTS is 0 for Slave 3 (indicating that no upstream slots are occupied by data received from a downstream node), and the value of LUPSLOTS is 2 for Slave 3 (indicating that Slave 3 adds data to two upstream slots). The value of UPMASKO is 0 for Slave 3 in this scenario (indicating that Slave 3 does not consume any data sent by any downstream slave nodes).

[0251] Fig. Figure 52 shows a scenario in which Slave 2 has received a superframe from Slave 3, as in Fig. 51 is shown, and is preparing to send a superframe upstream to Slave 1. As shown in Fig.As shown in Figure 52, the upstream superframe sent by Slave 2 to Slave 1 begins with an SRF and is followed by the two upstream data slots of Slave 3 and an additional upstream data slot occupied by data generated by the microphone associated with Slave 2. The value of UPSLOTS for Slave 2 is 2 (indicating that two upstream slots are occupied by data received from a downstream node), and the value of LUPSLOTS for Slave 2 is 1 (indicating that Slave 2 adds one upstream slot of data). The value of UPMASKO for Slave 2 in this scenario is 0 (indicating that Slave 2 does not consume any data sent by any downstream slave nodes).

[0252] Fig. Figure 53 shows a scenario in which Slave 1 has received a superframe from Slave 2, as in Fig.52 is shown, and is preparing to send a superframe upstream to Slave 0. As shown in Fig. As shown in Figure 53, Slave 1 consumes the data from the microphones associated with Slave 2 and Slave 3 and places the data from the microphones associated with Slave 3 back on bus 106 for transmission upstream to Slave 0. In some embodiments, Slave 1 uses all the data coming from Slave 2 and consumes it by outputting this data to the loudspeakers associated with Slave 1. As shown in Fig.As shown in Figure 53, the superframe sent upstream from Slave 1 to Slave 0 begins with an SRF and is followed by an upstream data slot for the data generated by each of the two microphones associated with Slave 3. Slave 1 does not add any additional data upstream to bus 106. The value of UPSLOTS for Slave 1 is 2 (indicating that two upstream slots are occupied by data received from a downstream node), and the value of LUPSLOTS for Slave 1 is 0 (indicating that Slave 1 does not add any data to any upstream slots). The value of UPMASKO for Slave 1 in this scenario is 7 (indicating that Slave 1 consumes the data received from Slave 2 in the upstream slots associated with mask values ​​1, 2, and 4).

[0253] Fig. Figure 54 shows a scenario in which Slave 0 has received a superframe from Slave 1, as in Fig.53 is shown, and is preparing to send a superframe upstream to master node 102. Slave 0 may not be able to consume any of the data from Slave 1, but can only forward this data upstream. As shown in Fig.As shown in Figure 54, the upstream superframe sent by Slave 0 to Master Node 102 begins with an SRF and is followed by an upstream data slot for the data generated by each of the two microphones associated with Slave 3. Slave 0 does not add any additional data upstream to bus 106. The value of UPSLOTS for Slave 0 is 2 (indicating that two upstream slots are occupied by data received from a downstream node), and the value of LUPSLOTS for Slave 0 is 0 (indicating that Slave 0 will not add any data to any upstream slots). The value of UPMASKO for Slave 0 in this scenario is 0 (indicating that Slave 0 will not consume any data received from Slave 1). Fig. 55 is a summary of the Fig. Downstream and upstream communication shown on pages 46-54.

[0254] Fig.Figures 56-65 show another example of slave-to-slave communication on a chained bus with multiple nodes according to various embodiments discussed above. In particular, they show Fig. 56-65 each show how data can move on a bus 106 in a certain exemplary system 100 according to various embodiments disclosed herein, and also show the structure of superframes relayed between adjacent nodes on the bus 106.

[0255] Fig. Figure 56 shows an exemplary System 100 with a host 110 coupled to a stereo tuner 111. The host 110 is coupled to a master node 102, and the master node 102 is coupled to a chain of four slave nodes 104 (identified as slave 0, slave 1, slave 2, and slave 3). Each of the slave nodes 104 in the System 100 of Fig. 56 is coupled to one or more associated peripheral devices 108. In particular, as shown in Fig. Figure 56 shows Slave 0 coupled with one microphone and one speaker, Slave 1 coupled with one microphone and two speakers (labeled 1 and 2), Slave 2 coupled with two microphones (labeled 1 and 2) and two speakers (labeled 1 and 2), and Slave 3 coupled with one microphone and two speakers (labeled 1 and 2). Slaves 0, 1, 2, and 3 can, for example, include amplifiers that drive their assigned speakers. As mentioned above, the specific number and type of slave nodes 104 and the specific number and type of peripheral devices 108, which are shown in Fig. 56 (and Fig. 57-65) are shown only as examples, and any suitable number and type may be used according to the techniques disclosed herein.

[0256] Fig.Figure 56 also shows a scenario in which the master node 102 receives data from the tuner 111 (e.g., left and right audio data) and the master node 102 prepares to send a superframe downstream to slave 0. As in Fig. As shown in Figure 56, the downstream superframe sent from master node 102 to slave 0 begins with an SCF and is followed by a downstream data slot each for the left and right audio data from tuner 111. The value of DNSLOTS for master node 102 in this scenario is 2.

[0257] Fig. Figure 57 shows a scenario in which Slave 0 has received a superframe from Master Node 102, as in Fig. 56 is shown, and is preparing to send a superframe downstream to Slave 1. As shown in Fig.As shown in Figure 57, Slave 0 consumes the right audio data from tuner 111. In some embodiments, Slave 0 uses all the data consumed by master node 102 by outputting this data to the loudspeaker associated with Slave 0. Additionally, Slave 0 places data from its microphone on bus 106. In particular, as shown in Fig.Figure 57 shows the superframe sent downstream from Slave 0 to Slave 1 with an SCF and is followed by a downstream data slot for the link audio data from tuner 111 (received by master node 102) and a downstream data slot for the microphone data generated by the microphone associated with Slave 0. The value of DNSLOTS is 1 for Slave 0 (indicating that a downstream slot is occupied by data received from an upstream node), and the value of LDNSLOTS is 1 for Slave 0 (indicating that Slave 0 adds a single downstream slot of data). The value of DNMASKO is 2 for Slave 0 in this scenario (indicating that Slave 0 consumes the data received from master node 102 in the downstream slot associated with the mask value 2). As indicated by the curved arrows in Fig.As specified in 57 and discussed below, the data generated by the microphone of Slave 0 can be output to speaker 2 of Slave 1 and speaker 2 of Slave 2.

[0258] Fig. Figure 58 shows a scenario in which Slave 1 has received a superframe from Slave 0, as in Fig. 57 is shown, and is preparing to send a superframe downstream to Slave 2. As shown in Fig.As shown in Figure 58, Slave 1 consumes some of the data from Slave 0 (i.e., the data from the microphone associated with Slave 0) and places the data from the microphone of Slave 0 and the data from the microphone of Slave 1 onto bus 106. In some embodiments, Slave 1 uses the data coming from Slave 0 and consumes it by outputting this data to the loudspeaker 2 associated with Slave 1. The superframe sent downstream from Slave 1 to Slave 2 begins with an SCF and is followed by a downstream data slot for the left audio data from the tuner 111, a downstream data slot for the microphone data from Slave 0, and a downstream data slot for data generated by the microphone associated with Slave 1.The value of DNSLOTS for Slave 1 is 2 (indicating that two downstream data slots are occupied by data received from an upstream node), and the value of LDNSLOTS for Slave 1 is 1 (indicating that Slave 1 adds one downstream data slot). The value of DNMASKO for Slave 1 in this scenario is 2 (indicating that Slave 1 consumes the data received by Slave 0 in the downstream slot associated with the mask value 2). This is shown by the curved arrows in the diagram. Fig. As specified in 58 and discussed below, the data generated by the microphone of Slave 1 can be output to loudspeaker 1 by Slave 2.

[0259] Fig. Figure 59 shows a scenario in which Slave 2 has received a superframe from Slave 1, as in Fig. 58 is shown, and is preparing to send a superframe downstream to Slave 3. As shown in Fig.As shown in Figure 59, Slave 2 consumes some of the data from Slave 1 (i.e., the data from the microphones associated with Slaves 0 and 1) and places data from microphone 2 of Slave 2 onto bus 106. In some embodiments, Slave 2 uses the microphone data consumed by Slave 1 from Slave 0 by outputting this data to loudspeaker 2 associated with Slave 2, and Slave 2 uses the microphone data consumed by Slave 1 from Slave 1 by outputting this data to loudspeaker 1 associated with Slave 2. The superframe sent downstream from Slave 2 to Slave 3 begins with an SCF and is followed by a downstream data slot for the link audio data from tuner 111 and a downstream data slot for data generated by microphone 2 associated with Slave 2.The value of DNSLOTS is 1 for Slave 2 (indicating that a downstream data slot is occupied by data received from an upstream node), and the value of LDNSLOTS is 1 for Slave 2 (indicating that Slave 2 is adding a downstream data slot). The value of DNMASKO is 6 for Slave 2 in this scenario (indicating that Slave 2 is consuming the data received by Slave 1 in the downstream slots associated with mask values ​​2 and 4). As indicated by the curved arrow in . Fig. As specified in 59 and discussed below, the data generated by microphone 2 of Slave 2 can be output to loudspeaker 1 of Slave 3.

[0260] Fig. Figure 60 shows a scenario in which Slave 3 has received a superframe from Slave 2, as in Fig.Figure 59 shows that since Slave 3 is the last slave node 104 on bus 106, it does not need to perform any downstream transmissions. Slave 3 can consume the data from microphone 2 of Slave 2 (and can output it, for example, to speaker 1 of Slave 3) and can consume the link audio data from tuner 111 (and can output it, for example, to speaker 2 of Slave 3). The value of DNSLOTS is 0 for Slave 3 (indicating that no downstream data slots are occupied by data received from an upstream node), and the value of LDNSLOTS is also 0 for Slave 3 (indicating that Slave 3 does not add any downstream data slots). The value of DNMASKO is 3 for Slave 3 in this scenario (indicating that Slave 3 consumes the data received from Slave 2 in the downstream slots associated with mask values ​​1 and 2).

[0261] Fig.61 shows a scenario in which Slave 3, after receiving a superframe from Slave 2 as above, with reference to Fig. 60 discussed and prepared to send a superframe back upstream to Slave 2. As in Fig. As shown in Figure 61, the upstream superframe sent by Slave 3 to Slave 2 begins with an SRF and is followed by an upstream data slot for data generated by the microphone associated with Slave 3. The value of UPSLOTS is 0 for Slave 3 (indicating that no upstream slots are occupied by data received from a downstream node), and the value of LUPSLOTS is 1 for Slave 3 (indicating that Slave 3 adds an upstream slot of data). The value of UPMASKO is 0 for Slave 3 in this scenario (indicating that Slave 3 does not consume any data sent by any downstream slave nodes).

[0262] Fig.Figure 62 shows a scenario in which Slave 2 has received a superframe from Slave 3, as in Fig. 61 is shown, and is preparing to send a superframe upstream to Slave 1. As shown in Fig.As shown in Figure 62, the upstream superframe sent by Slave 2 to Slave 1 begins with an SRF and is followed by the upstream data slot of Slave 3 and two additional upstream data slots occupied by data generated by the microphones associated with Slave 2. The value of UPSLOTS is 1 for Slave 2 (indicating that one upstream slot is occupied by data received from a downstream node), and the value of LUPSLOTS is 2 for Slave 2 (indicating that Slave 2 will add data to two upstream slots). The value of UPMASKO is 0 for Slave 2 in this scenario (indicating that Slave 2 will not consume any data sent by any downstream slave nodes). As indicated by the curved arrow in Fig. As specified in 62 and discussed below, the data generated by microphone 2 of Slave 2 can be output to loudspeaker 1 of Slave 1.

[0263] Fig. Figure 63 shows a scenario in which Slave 1 has received a superframe from Slave 2, as in Fig. 62 is shown, and is preparing to send a superframe upstream to Slave 0. As shown in Fig. As shown in Figure 63, Slave 1 consumes the data from microphone 2 associated with Slave 2 and does not place this data back on bus 106 for transmission upstream to Slave 0. In some embodiments, Slave 1 uses all the data coming from Slave 2 and consumes it by outputting this data to the loudspeakers associated with Slave 1 (e.g., loudspeaker 1). Slave 1 can also place data generated by its own microphone on bus 106. As shown in Fig.As shown in Figure 63, the upstream superframe sent from Slave 1 to Slave 0 begins with an SRF and is followed by an upstream data slot for the data generated by the microphone associated with Slave 3, an upstream data slot for the data generated by microphone 1 of Slave 2, and an upstream data slot for data generated by the microphone of Slave 1. The value of UPSLOTS is 2 for Slave 1 (indicating that two upstream slots are occupied by data received from a downstream node), and the value of LUPSLOTS is 1 for Slave 1 (indicating that Slave 1 adds one upstream slot of data). The value of UPMASKO is 4 for Slave 1 in this scenario (indicating that Slave 1 consumes the data received by Slave 2 in the upstream slot associated with the mask value 4).

[0264] Fig.Figure 64 shows a scenario in which Slave 0 has received a superframe from Slave 1, as in Fig. 63 is shown, and is preparing to send a superframe upstream to the master node 102. Slave 0 may not be able to consume any of the data from Slave 1, but can only forward this data upstream. Slave 0 can also place data generated by its own microphone onto bus 106. As shown in Fig.As shown in Figure 64, the superframe sent upstream by Slave 0 to Master Node 102 begins with an SRF and is followed by an upstream data slot for the data generated by the microphone associated with Slave 3, an upstream data slot for the data generated by Microphone 1 of Slave 2, an upstream data slot for the data generated by the microphone of Slave 1, and an upstream data slot for the data generated by the microphone of Slave 0. The value of UPSLOTS is 3 for Slave 0 (indicating that three upstream slots are occupied by data received from a downstream node), and the value of LUPSLOTS is 1 for Slave 0 (indicating that Slave 0 adds one upstream slot of data). The value of UPMASKO is 0 for Slave 0 in this scenario (indicating that Slave 0 does not consume any data received from Slave 1). Fig. 65 is a summary of the in Fig.Downstream and upstream communication shown on pages 56-64.

[0265] Any of the embodiments described herein can be combined in any desired combination with slave-to-slave communication functionality according to any of the embodiments disclosed herein.

[0266] The following paragraphs give examples of various embodiments disclosed herein.

[0267] Example A1 is a slave node transceiver for low-latency communication, comprising: an upstream transceiver circuit for receiving a first signal sent over a two-wire bus from an upstream device and for providing a second signal over the two-wire bus to the upstream device; a downstream transceiver circuit for providing a third signal downstream over the two-wire bus towards a downstream device and for receiving a fourth signal over the two-wire bus from the downstream device; and a clock circuit for generating a clock signal in the slave node transceiver based on a preamble of a synchronization control frame in the first signal, wherein the timing of the reception and provision of signals over the two-wire bus by the slave node transceiver is based on the clock signal.

[0268] Example A2 may include the subject of Example A1 and may further specify that the synchronization control frame is associated with downstream data in a superframe of the first signal, the downstream data includes multiple data slots, and data for a single peripheral device in communication with the slave node transceiver occupies two or more of the multiple data slots.

[0269] Example A3 may include the subject matter of Example A2 and may further specify that the data for the individual peripheral device is audio data.

[0270] Example A4 may include the subject of any of Examples A1-A3 and may further specify the following: the first signal includes a first synchronization control frame and associated first downstream data, and a second synchronization control frame and associated second downstream data; the first downstream data includes a data slot with a specified index and with data for a first peripheral device in communication with the slave node transceiver; and the second downstream data includes a data slot with the specified index and with data for a second peripheral device, different from the first peripheral device, in communication with the slave node transceiver.

[0271] Example A5 may include the subject of Example A4 and may further specify that the first and second peripheral devices are different microphones.

[0272] Example A6 can include the subject of any of Examples A1-A5 and can further specify the following: The second signal includes a synchronization response frame, the synchronization response frame is associated with upstream data in a superframe of the second signal, the upstream data includes multiple data slots, and data originating in a single peripheral device in communication with the slave node transceiver occupies two or more of the multiple data slots.

[0273] Example A7 may include the subject of Example A6 and may further specify that the data originating from the single peripheral device is audio data.

[0274] Example A8 can include the subject of any of the examples A1-A7 and can further specify the following: the second signal includes a first synchronization response frame and associated first upstream data and a second synchronization response frame and associated second upstream data;

[0275] The first upstream data includes a data slot with a specific index and with data originating in a first peripheral device in communication with the slave node transceiver; and the second upstream data includes a data slot with the specific index and with data originating in a second peripheral device different from the first peripheral device in communication with the slave node transceiver.

[0276] Example A9 may include the subject of Example A8 and may further specify that the first and second peripheral devices are different microphones.

[0277] Example A10 may include the subject matter of any of Examples A1-A9 and may further include: a power supply circuit for receiving a bias voltage via the two-wire bus from the upstream device and providing energy from the bias voltage to an energy storage device coupled to the slave node transceiver.

[0278] Example A11 may include the subject matter of any of Examples A1-A10 and may further include a peripheral device communication circuit for communication with at least one loudspeaker and at least one microphone.

[0279] Example A12 may include the subject of Example A11 and may further specify that the peripheral device communication circuit includes an I2S (Inter-Integrated Circuit Sound) transceiver, a TDM (Time Division Multiplex) transceiver, a PDM (Pulse Density Modulation) transceiver, an I2C (Inter-Integrated Circuit) transceiver, or a GPIO (General Purpose Input / Output) pin.

[0280] Example A13 may include the subject matter of any of Examples A1-A12 and may further include a peripheral device communication circuit for communicating with a microphone and a conference circuit user interface element, wherein a user activates the conference circuit user interface element when the user wishes to provide audio from the microphone of another device coupled to the two-wire bus, and wherein the second signal includes data originating from the microphone when the conference circuit user interface element is activated.

[0281] Example A14 may include the subject matter of any of Examples A1-A13 and may further include a peripheral device communication circuit for communicating with a wireless transceiver, wherein the wireless transceiver is to receive voice calls and wherein the upstream transceiver circuit is to include data representing the voice calls in the second signal.

[0282] Example A15 may include the subject matter of any of Examples A1-A14 and may further specify that the upstream device is coupled to a wireless transceiver, wherein the wireless transceiver is to receive voice calls and the upstream transceiver circuit is to receive data representing voice calls in the first signal.

[0283] Example A16 may include the subject matter of any of Examples A1-A15 and may further specify that a host device is coupled to a master device of the two-wire bus, the host device is coupled to a wireless transceiver, the wireless transceiver is to receive voice calls, and the upstream transceiver circuit is to receive data representing the voice calls in the first signal.

[0284] Example A17 may include the subject matter of any of Examples A1-A16 and may further include a peripheral device communication circuit in communication with an antenna coupled to a roof or other part of a vehicle, wherein the peripheral device communication circuit communicates with the antenna via a wired connection.

[0285] Example A18 may include the subject matter of Example A17 and may further specify that the upstream device is a master device located in the vehicle's head unit.

[0286] Example A19 may include the subject of any of Examples A1-A18 and may further specify that the slave node transceiver is contained in a loudspeaker, a mixing console, a musical instrument, time coding equipment, an amplifier, a video display, or a pyrotechnics console.

[0287] Example A20 may include the subject of any of Examples A1-A19 and may further include a peripheral device communication circuit in communication with a sensor or actuator at a joint of a robotic limb.

[0288] Example A21 can include the subject of any of Examples A1-A20 and can further include a receiving mailbox and a sending mailbox, wherein the host device is to generate an interrupt to transfer to the downstream device when data is to be provided to the sending mailbox, and the downstream device is to generate an interrupt to transfer to the host device when data is to be provided to the receiving mailbox.

[0289] Example A22 may include the subject matter of any of Examples A1-A21 and may further include a peripheral device communication circuit in communication with a humidity or temperature sensor in a vehicle.

[0290] Example A23 may include the subject matter of any of Examples A1-A22 and may further include a peripheral device communication circuit in communication with a gas sensor in a vehicle.

[0291] Example A24 may comprise the subject of any of Examples A1-A23 and may further comprise a peripheral device communication circuit to feed the first signal or the second signal to a protocol analyzer, wherein the downstream transmit-receiver circuit is blocked.

[0292] Example A25 can encompass the subject of any of the examples A1-A24 and can further specify that data is sent downstream in the synchronization control frame.

[0293] Example A26 can encompass the subject of any of the examples A1-A25 and can further specify that data is sent upstream in a synchronization response frame.

[0294] Example B1 is a master-node transceiver for low-latency communication, comprising: an I2S (Inter-Integrated Circuit Sound) receiver for receiving an I2S signal from a host device, wherein the I2S signal provides clock information; a clock circuit for generating a clock signal based on the clock information; and a downstream transceiver circuit for routing a first signal downstream via a two-wire bus towards a downstream device and for receiving a second signal via the two-wire bus from the downstream device, wherein a preamble of a synchronization control frame of the first signal is based on the clock signal and the downstream device generates its own clock signal based on the preamble.

[0295] Example B2 may include the subject of Example B1 and may further specify the following: The synchronization control frame is associated with downstream data in a superframe of the first signal, the downstream data includes multiple data slots, and data for a single peripheral device coupled to the downstream device occupies two or more of the multiple data slots.

[0296] Example B3 may include the subject matter of Example B2 and may further specify that the data for the individual peripheral device is audio data.

[0297] Example B4 may include the subject of any of Examples B1-B3 and may further specify the following: The first signal includes a first synchronization control frame and associated first downstream data, and a second synchronization control frame and associated second downstream data; the first downstream data includes a data slot with a specified index and with data for a first peripheral device coupled to the downstream device; and the second downstream data includes a data slot with the specified index and with data for a second peripheral device, different from the first peripheral device, coupled to the downstream device.

[0298] Example B5 may include the subject of Example B4 and may further specify that the first and second peripheral devices are different microphones.

[0299] Example B6 can include the subject of any of Examples B1-B5 and can further specify that the second signal includes a synchronization response frame, the synchronization response frame is associated with upstream data in a superframe of the second signal, the upstream data includes multiple data slots, and data coming from a single peripheral device coupled to the downstream device occupies two or more of the multiple data slots.

[0300] Example B7 may include the subject matter of Example B6 and may further specify that the data coming from the individual peripheral device is audio data.

[0301] Example B8 may include the subject of any of Examples B1-B7 and may further specify the following: The second signal includes a first synchronization response frame and associated first upstream data, and a second synchronization response frame and associated second upstream data; the first upstream data includes a data slot with a specified index and with data coming from a first peripheral device coupled to the downstream device; and the second upstream data includes a data slot with the specified index and with data coming from a second peripheral device, different from the first peripheral device, coupled to the downstream device.

[0302] Example B9 may include the subject of Example B8 and may further specify that the first and second peripheral devices are different microphones.

[0303] Example B10 can include the subject of any of the examples B1-B9 and can further specify that the first signal includes data for at least one loudspeaker coupled to the downstream device and the second signal includes data coming from at least one microphone coupled to the downstream device.

[0304] Example B11 may comprise the subject matter of any of Examples B1-B10 and may further comprise a peripheral device communication circuit for communication with a wireless transceiver, wherein the wireless transceiver is to receive voice calls and wherein the downstream transceiver circuit is to include data representing the voice calls in the first signal.

[0305] Example B12 may include the subject of any of Examples B1-B11 and may further specify that the downstream device is coupled with a wireless transceiver, the wireless transceiver is to receive voice calls, and the downstream transceiver circuit is to receive data representing the voice calls in the second signal.

[0306] Example C1 is a host device comprising: an I2S (Inter-Integrated Circuit Sound) transceiver circuit for routing an I2S signal to a master node transceiver, wherein the master node transceiver is a master of a two-wire bus, the I2S signal provides clock information, the master node transceiver is to generate a clock signal based on the clock information, the master node transceiver is to provide a first signal downstream via the two-wire bus towards a downstream device, a preamble of the synchronization control frame of the first signal is based on the clock signal, and the downstream device is to generate its own clock signal based on the preamble; an I2C (Inter-Integrated Circuit) transceiver circuit for receiving a first I2C signal from the master node transceiver and for routing a second I2C signal to the master node transceiver;and a processing circuit for generating data for the downstream device based on the first I2C signal, wherein the data for the downstream device is to be incorporated into the second I2C signal and sent by the master node transceiver via the two-wire bus to the downstream device.

[0307] Example C2 may include the subject of Example C1 and may further specify that the first signal includes data for at least one loudspeaker coupled to the downstream device.

[0308] Example C3 may include the subject of any of Examples C1-C2 and may further specify the following: The I2S transceiver circuit shall receive audio from a microphone coupled to the downstream device via the two-wire bus and the master node transceiver; the I2C transceiver circuit shall receive a notification that a user has actuated a conference circuit user interface element coupled to the downstream device via the two-wire bus and the master node transceiver; and the I2S transceiver circuit, in response to the notification, shall provide audio over the two-wire bus of another downstream device via the two-wire bus and the master node transceiver.

[0309] Example C4 can include the subject of any of Examples C1-C3 and can further specify that the downstream device is coupled with a wireless transceiver, the wireless transceiver is to receive voice calls, and the I2C transceiver circuit is to receive data representing the voice calls via the master node transceiver and the two-wire bus.

[0310] Example C5 may include the subject matter of any of Examples C1-C4 and may further specify that the downstream device is wired to an antenna coupled to a roof or other part of a vehicle and that the master node transceiver is located in a head unit of the vehicle.

[0311] Example C6 can include the subject of any of Examples C1-C5 and can further specify that the host device includes a receiving mailbox and a sending mailbox, and that the host device is to generate an interrupt to transmit to the downstream device when data is provided to the sending mailbox.

[0312] Example C7 can include the subject of any of Examples C1-C6 and can further specify that the downstream device is coupled to an environmental sensor in a vehicle and that the processing circuit is to generate a control instruction for an air conditioning system in the vehicle based on data from the sensor, which is sent to the host device via the master node transceiver and the two-wire bus.

[0313] Example D1 is a microphone cable comprising: a first connector for coupling to a microphone; a second connector for coupling to an audio receiving device; a conductor for transmitting data between the first connector and the second connector;and a slave node transceiver comprising an upstream transceiver circuit for receiving a first signal transmitted over a two-wire bus from an upstream device and for routing a second signal over the two-wire bus to the upstream device, a clock circuit for generating a clock signal in the slave node transceiver based on a preamble of a synchronization control frame in the first signal, wherein the timing of the reception and provision of signals over the two-wire bus by the node transceiver is based on the clock signal, and a peripheral device communication circuit coupled to the conductor to receive the data transmitted between the first connector and the second connector, wherein the data is contained in the second signal.

[0314] Example D2 can include the subject of Example D1 and can further specify that the slave node transceiver is included in the first connector.

[0315] Example D3 can include the subject of any of the examples D1-D2 and can further specify that the slave node transceiver is contained in the second connector.

[0316] Example D4 can include the subject of any of the examples D1-D3 and can further specify that the slave node transceiver is located between the first connector and the second connector.

[0317] Example D5 may include the subject matter of any of Examples D1-D4 and may further include an analog-to-digital converter (ADC) for converting an analog microphone input signal received at the first connector into a digital signal, wherein the data transmitted between the first connector and the second connector includes the digital signal.

[0318] Example D6 may include the subject matter of Example D5 and may further specify that the second connector is to provide the second signal and the digital signal to the audio receiving device.

[0319] Example D7 can include the subject of any of Examples D5-D6 and can further specify that the second connector is to provide the second signal and the analog microphone input signal to the audio receiving device.

[0320] Example D8 may include the subject matter of Example D7 and may further specify that providing the second signal and the analog microphone input signal includes providing the sum of the second signal and the analog microphone input signal.

[0321] Example D9 may include the subject of any of Examples D7-D8 and may further specify that the second connector shall also provide the digital signal to the audio receiving device.

[0322] Example D10 can include the subject of any of the examples D5-D9 and can further include a digital-to-analog converter for converting the digital signal into an analog signal.

[0323] Example D11 may include the subject matter of Example D10 and may further specify that the second connector of the audio receiving device shall provide the second signal and the analog signal.

[0324] Example E1 is a system with one or more of the slave node transceivers according to one of the examples A, coupled via two-wire bus links to a master node transceiver according to one of the examples B.

[0325] Example E2 can include the subject of Example E1 and can further include a host device of any of the Examples C coupled with the master node transceiver.

[0326] Example E3 is a method according to any of the techniques disclosed herein.

[0327] Example E4 is a device with means for carrying out any of the techniques disclosed herein.

[0328] Example E5 is one or more non-perishable, computer-readable media containing instructions which, in response to execution by one or more processing devices of a system, cause the system to execute any of the techniques disclosed herein.

[0329] Example F1 can include any embodiment of the slave-to-slave communication functionality disclosed herein.

[0330] Example F2 can include the subject matter of any of the above Examples AE and can further include any embodiments of the slave-to-slave communication functionality disclosed herein.

[0331] Example G1 is a low-latency communication system comprising: a slave node transceiver with an upstream transceiver circuit for receiving a first signal sent via a two-wire bus from an upstream device and for routing a second signal via the two-wire bus to the upstream device, a downstream transceiver circuit for routing a third signal downstream via the two-wire bus towards a downstream device and for receiving a fourth signal via the two-wire bus from the downstream device, and a peripheral device interface for receiving data from a peripheral device communicatively coupled to the peripheral device interface, wherein the downstream transceiver circuit is to incorporate the data into the third signal.

[0332] Example G2 can encompass the subject of Example G1 and can further specify that the data is audio data.

[0333] Example G3 can include the subject of any of the examples G1-2 and can further specify that the first signal includes data generated by a peripheral device communicatively coupled to the upstream device, the third signal is provided downstream after the first signal has been received, and the third signal includes less than all of the data generated by the peripheral device communicatively coupled to the upstream device.

[0334] Example G4 may include the subject of Example G3 and may further specify that the upstream device is a host device.

[0335] Example G5 can encompass the subject of any of the examples G3-4 and can further specify that the upstream device is a master node.

[0336] Example G6 can encompass the subject of any of the examples G3-5 and can further specify that the upstream device is a slave node.

[0337] Example G7 can include the subject of any of Examples G3-6 and can further specify that the peripheral device interface of the peripheral device communicatively coupled to the peripheral device interface provides at least some of the data generated by the peripheral device communicatively coupled to the upstream device.

[0338] Example G8 can include the subject of any of the examples G3-7 and can further specify that an intermediate upstream device is arranged on the two-wire bus in a chain between the slave node transceiver and the upstream device.

[0339] Example G9 can include the subject of any of Examples G1-8 and can further specify that the fourth signal includes data generated by a peripheral device communicatively coupled to the downstream device, the second signal is provided upstream after the fourth signal has been received, and the second signal includes less than all of the data generated by the peripheral device communicatively coupled to the downstream device.

[0340] Example G10 may include the subject matter of Example G9 and may further specify that the peripheral device interface of the peripheral device communicatively coupled to the peripheral device interface provides at least some of the data generated by the peripheral device communicatively coupled to the downstream device.

[0341] Example G11 can include the subject of any of the examples G9-G10 and can further specify that the peripheral device includes a loudspeaker.

[0342] Example G12 can include the subject of any of Examples G9-11 and can further specify that an intermediate downstream device is arranged on the two-wire bus in a chain between the slave node transceiver and the downstream device.

[0343] Example G13 can include the subject of any of the examples G1-12 and can further include the upstream device and the downstream device.

[0344] Example G14 may include the subject of any of Examples G1-13 and may further specify that the slave node transceiver further includes a clock circuit for generating a clock signal in the slave node transceiver based on a preamble of a synchronization control frame in the first signal, wherein timing of the reception and provision of signals over the two-wire bus by the slave node transceiver is based on the clock signal.

[0345] Example G15 may include the subject of Example G14 and may further specify that the second signal includes a synchronization response frame and that the synchronization response frame is associated with upstream data in a superframe of the second signal.

[0346] Example G16 can include the subject of any of the examples G1-15 and can further include the peripheral device.

[0347] Example H1 is a low-latency communication system comprising: a master node transceiver; and several slave node transceivers communicatively coupled to each other and to the master node transceiver in a chained two-wire bus, wherein at least one of the slave node transceivers comprises: an upstream transceiver circuit for receiving a first signal transmitted over a two-wire bus from an upstream device on the bus and for providing a second signal over the two-wire bus to the upstream device, wherein the first signal comprises data generated by a peripheral device communicatively coupled to the upstream device, and a downstream transceiver circuit for providing a third signal downstream via the two-wire bus towards a downstream device on the bus and for receiving a fourth signal via the two-wire bus from the downstream device, wherein the third signal is provided downstream after the first signal has been received and the third signal comprises less than all the data generated by the peripheral device communicatively coupled to the upstream device.

[0348] Example H2 can include the subject of Example H1 and can further include a host device communicatively coupled to the master node transceiver.

[0349] Example I1 is a method for slave-to-slave communication in a chained two-wire bus, comprising: Receiving data in a first slave device from a second slave device downstream of the first slave device via the bus; and providing less than all data from the second slave device through the first slave device to a third device upstream of the first slave device via the bus.

[0350] Example I2 can include the subject of Example I1 and can further specify that the data from the second slave device is data generated by a peripheral device coupled to the second slave node via an I2S (Inter-Integrated Circuit Sound) transceiver, a TDM (Time Division Multiplex) transceiver, a PDM (Pulse Density Modulation) transceiver, an I2C (Inter-Integrated Circuit) transceiver, or a GPIO (General Purpose Input / Output) pin.

Claims

[1] Low-latency communication system (100), comprising: a slave node transceiver (104), comprising: an upstream transceiver circuit (122) for receiving a first signal sent via a two-wire bus (106) from an upstream device and for providing a second signal via the two-wire bus (106) to the upstream device, a downstream transceiver circuit (124) for providing a third signal downstream via the two-wire bus (106) towards a downstream device and for receiving a fourth signal via the two-wire bus (106) from the downstream device and a peripheral device interface (127, 129) for receiving first data from a first peripheral device that is communicatively coupled to the peripheral device interface (127, 129), wherein the downstream transceiver circuits (124) are to receive the first data into the third signal and; wherein the first signal comprises second data generated by a second peripheral device (127, 129) communicatively coupled to the upstream device, wherein the third signal is provided downstream after the first signal has been received, and the third signal comprises less than all the second data generated by the second peripheral device (127, 129) communicatively coupled to the upstream device, and wherein the peripheral device interface (127, 129) of the first peripheral device, which is communicatively coupled with the peripheral device interface (127, 129), is to provide at least a part of the second data generated by the second peripheral device, which is communicatively coupled with the upstream device, and wherein the fourth signal comprises third data generated by a third peripheral device communicatively coupled to the downstream device, the second signal is provided upstream after the fourth signal has been received, and the second signal comprises less than all the third data generated by the third peripheral device communicatively coupled to the downstream device, and wherein the peripheral device interface of the first peripheral device, which is communicatively coupled to the peripheral device interface, is to provide at least some of the third data generated by the third peripheral device, which is communicatively coupled to the downstream device, and wherein adding the first data to the third signal comprises adding the first data within a number of data slots in a downstream part of a superframe, and wherein a mask register DNMASK0, DNMASK1, DNMASK2 and DNMASK3 is provided which provides one bit for each possible downstream data slot, and If a slot mask bit LDNSLOTS.DNMASKEN of the mask register is set, the slot mask bit LDNSLOTS.DNMASKEN is used to select which downstream slots are consumed by the first peripheral device communicatively coupled to the slave node transceiver (104), and these are placed in a TX frame buffer, and If the slot mask bit LDNSLOTS.DNMASKEN is not set, an LDNSLOTS register defines the number of downstream slots consumed by the slave node transceiver. where the LDNSLOTS register defines the number of downstream data slots, starting immediately after a synchronization control frame, SCF. [2] Low latency communication system (100) according to claim 1, wherein the data are audio data. [3] Low latency communication system (100) according to claim 1, wherein the upstream device is a host device. [4] Low latency communication system (100) according to claim 1, wherein the upstream device is a master node (102). [5] Low latency communication system (100) according to claim 1, wherein the upstream device is a slave node. [6] Low latency communication system (100) according to one of claims 1 and 3 to 5, wherein an intermediate upstream device is arranged in a chain on the two-wire bus (106) between the slave node transceiver (104) and the upstream device. [7] Low latency communication system (100) according to claim 1, wherein the peripheral device comprises a loudspeaker. [8] Low latency communication system (100) according to one of claims 1 and 7, wherein an intermediate downstream device is arranged in a chain on the two-wire bus (106) between the slave node transceiver (104) and the downstream device. [9] Low-latency communication system (100) according to any of the preceding claims, further comprising the upstream device and the downstream device. [10] Low-latency communication system (100) according to any of the preceding claims, wherein the slave node transceiver (104) further comprises: Clock circuits for generating a clock signal in the slave node transceiver (104) based on a preamble of the synchronization control frame in the first signal, wherein the timing of the reception and provision of signals via the two-wire bus (106) by the slave node transceiver (104) is based on the clock signal. [11] Low-latency communication system (100) according to claim 10, wherein the second signal includes a synchronization response frame and the synchronization response frame is associated with upstream data in a superframe of the second signal. [12] Low-latency communication system (100), comprising: a master node transceiver (102); and several slave node transceivers (104) that are communicatively coupled to each other and to the master node transceiver (102) in a chained two-wire bus (106), wherein at least one of the slave node transceivers (102) comprises the following: an upstream transceiver circuit (122) for receiving a first signal transmitted on the bus via a two-wire bus (106) from an upstream device and for providing a second signal via the two-wire bus (106) to the upstream device, wherein the first signal comprises second data generated by a second peripheral device communicatively coupled to the upstream device, and a downstream transceiver circuit (124) for providing a third signal downstream via the two-wire bus (106) towards the downstream device on the bus and for receiving a fourth signal via the two-wire bus (106) from the downstream device, wherein the third signal is provided downstream after the first signal has been received and the third signal comprises less than all the second data generated by the second peripheral device communicatively coupled to the upstream device, and wherein adding the first data to the third signal comprises adding the first data within a number of data slots in a downstream part of a superframe, and wherein a mask register DNMASK0, DNMASK1, DNMASK2 and DNMASK3 is provided which provides one bit for each possible downstream data slot, and If a slot mask bit LDNSLOTS.DNMASKEN of the mask register is set, the slot mask bit LDNSLOTS.DNMASKEN is used to select which downstream slots are consumed by the first peripheral device communicatively coupled to the slave node transceiver (104), and these are placed in a TX frame buffer, and If the slot mask bit LDNSLOTS.DNMASKEN is not set, an LDNSLOTS register defines the number of downstream slots consumed by the slave node transceiver (104). where the LDNSLOTS register defines the number of downstream data slots, starting immediately after a synchronization control frame, SCF. [13] Low-latency communication system (100) according to claim 12, further comprising: a host device communicatively coupled to the master node transceiver (102).

Images