Communication device and communication system

Abstract

The storage capacity for storing address information, etc., of an I2C communication instrument, as well as the number of encoders and decoders, can be reduced. A communication device for establishing communication between a first I2C communication instrument and a second I2C communication instrument connected to a communication partner instrument comprises an encoder that generates header packet data containing a destination ID of the communication partner instrument and I2C packet data containing a slave address and an offset address of the second I2C communication instrument; a communication unit that sends a transmission packet comprising the header packet data and I2C packet data generated by the encoder to the communication partner instrument via a time-duplex (TDD) communication scheme and receives a receive packet from the communication partner instrument via the TDD communication scheme; and a decoder that generates the I2C packet data from the receive packet.

Description

[REFERENCE TO RELATED APPLICATIONS]

[0001] This application claims the benefit of Japanese priority patent application JP 20XX-XXXXXX, filed on March 24, 2022, the entire contents of which are hereby incorporated by reference. [Technical field]

[0002] The present disclosure relates to a communication device and a communication system. [State of the art]

[0003] A technique for establishing high-speed serial communication between multiple devices has been proposed (Patent Literature 1). This type of high-speed serial communication is used in various fields, for example, for communication between devices in vehicles. [List of citations][Patent literature]

[0004] [PTL 1] JP 2011-239011A [Summary][Technical Problem]

[0005] With the development of automated driving and electronic technology, the need for fast communication between devices in vehicles is increasing. The ASA (Automotive SerDes Alliance) proposes that fast serial communication will be established using a time-division duplex (TDD) communication scheme between a root (100) connected by a cable (hereinafter referred to simply as root (100)) and a leaf device (hereinafter referred to simply as leaf).

[0006] For example, a conceivable design of a communication system enables the root (100) to perform I2C communication with a CPU (110), and enables the leaf to perform I2C communication with a camera, and enables the root (100) and the leaf to perform fast serial communication in accordance with the ASA standards.

[0007] If multiple I2C communication instruments are connected to the leaf, the root (100) may include an encoder and a decoder for each I2C communication instrument so that fast serial communication can be established between the root (100) and the leaf and I2C communication can be established with multiple I2C communication instruments connected to the leaf.

[0008] However, providing multiple encoders and decoders for each leaf increases the size of the root (100). Furthermore, it is necessary to allocate a memory space to store data to be sent and received for each leaf and root (100), and as the number of connected leaves increases, the memory capacity increases.

[0009] Therefore, the present disclosure provides a communication apparatus and a communication system that do not need to increase the memory capacity for storing the data transmitted and received for each leaf and do not need to increase the number of encoders and decoders even when the number of leaves connected to the root increases. [Problem solving]

[0010] According to one embodiment of the present disclosure, the present disclosure provides a communication device configured to cause a first I2C communication instrument and a second I2C communication instrument connected to a communication partner device to establish communication therebetween, the communication device comprising: an encoder that generates header packet data including a destination ID of the communication partner device and I2C packet data including a slave address and an offset address of the second I2C communication instrument; a communication unit that sends a transmission packet comprising the header packet data and I2C packet data generated by the encoder to the communication partner device through a time division duplex (TDD) communication scheme and receives a reception packet from the communication partner device through the TDD communication scheme; and a decoder that generates the I2C packet data from the received packet.

[0011] The header packet data may include a plurality of the destination IDs corresponding to a plurality of communication partner devices.

[0012] A memory location that stores the header packet data and the I2C packet data may include a memory location for communication with the communication partner device.

[0013] The header packet data may include four of the destination IDs according to ASA (Automotive SerDes Alliance) standards.

[0014] The encoder and the decoder may be provided to be shared by the plurality of communication partner devices corresponding to the plurality of destination IDs.

[0015] A memory that stores the header packet data and the I2C packet data may include a plurality of fixed-length storage locations for storing the plurality of destination IDs included in the header packet data. An invalid ID may be stored in the storage location corresponding to the unused destination ID. The header packet data may include variable-length data including information indicating a number of valid destination IDs, with the valid destination IDs arranged after the information.

[0016] The header packet data may include a destination code that specifies a combination of the multiple destination IDs.

[0017] The target code may include bit string data with a fixed length.

[0018] The destination code can comprise 4-bit data and specify a combination of four of the destination IDs.

[0019] A memory storing the header packet data and the I2C packet data may store, as the I2C packet data, at least one of I2C configuration data including an operation setting of the second I2C communication instrument and I2C data for the second I2C communication instrument.

[0020] The present disclosure provides a communication system comprising: a first communication device to which a first I2C communication instrument is connected; and a second communication device to which a second I2C communication instrument is connected and which alternately sends and receives information to and from the first communication device within an allocated period by a time division duplex (TDD) communication scheme, wherein the first communication device comprises: a first encoder that generates header packet data comprising a destination ID of the second communication device and I2C packet data comprising a slave address and an offset address of the second I2C communication device, a communication unit that sends a transmission packet comprising the header packet data and I2C packet data generated by the first encoder to the second communication device through a time division duplex (TDD) communication scheme and receives a reception packet from the second communication device through the TDD communication scheme; and a first decoder that generates the I2C packet data from the received packet.

[0021] The second communication device may comprise: a second encoder that generates header packet data comprising a destination ID of the first communication device and I2C packet data comprising a slave address and an offset address of the first I2C communication device; a communication unit that sends a transmission packet comprising the header packet data and I2C packet data generated by the second encoder to the first communication device through a time division duplex (TDD) communication scheme and receives a reception packet from the first communication device through the TDD communication scheme; and a second decoder that generates the I2C packet data from the received packet.

[0022] The second I2C communication instrument may further comprise an I2C slave unit to which an I2C master unit is connected via an I2C bus.

[0023] Several of the second communication devices may be connected by a chain and The header packet data may be divided into multiple groups, and each group may include multiple destination IDs according to ASA (Automotive SerDes Alliance) standards. Multiple second communication devices may be connected by a chain, and the header packet data may include a group number indicating a group and a bit string specifying a combination of several of the destination IDs.

[0024] The present disclosure provides a communication device configured to cause a first I2C communication instrument and a second I2C communication instrument to establish communication therebetween based on I2C configuration data sent from a communication partner device to which the first I2C communication instrument is connected, the communication device comprising: an encoder that generates header packet data including a destination ID of the communication partner device and I2C packet data including a slave address and an offset address of the first I2C communication instrument; a communication unit that sends a transmission packet comprising the header packet data and I2C packet data generated by the encoder to the communication partner device through a time division duplex (TDD) communication scheme and receives a reception packet from the communication partner device through the TDD communication scheme; and a decoder that generates the I2C packet data from the receive packet, where the second I2C communication instrument further comprises an I2C slave unit to which an I2C master unit is connected via an I2C bus. [Brief description of the drawings] [ Fig. 1] Fig. 1 is a block diagram of a schematic embodiment of a communication system according to the present disclosure. [ Fig. 2] Fig. Figure 2 is a representation of information stored in an ASEP register of a sheet. [ Fig. 3] Fig. 3 is a diagram of a memory map of an internal memory in Fig. 1. [ Fig. 4] Fig. 4 is an explanatory diagram of a processing operation of an information processing apparatus according to a basic mode of the present disclosure. [ Fig. 5] Fig. 5 is an explanatory diagram of a processing operation that Fig. 4 follows. [ Fig. 6] Fig. 6 is an explanatory diagram of a processing operation that Fig. 5 follows. [ Fig. 7] Fig. 7 is an explanatory diagram of a processing operation that Fig. 6 follows. [ Fig. 8] Fig. 8 is an explanatory diagram of a processing operation that Fig. 7 follows. [ Fig. 9] Fig. 9 is an explanatory diagram of a processing operation that Fig. 8 follows. [ Fig. 10] Fig. 10 is an explanatory diagram of a processing operation that Fig. 9 follows. [ Fig. 11] Fig. 11 is an explanatory diagram of a processing operation that Fig. 10 follows. [ Fig. 12] Fig. 12 is an explanatory diagram of a processing operation that Fig. 11 follows. [ Fig. 13] Fig. 13 is an explanatory diagram of a processing operation that Fig. 12 follows. [ Fig. 14] Fig. Figure 14 is a data flow diagram of writing I2C configuration data in basic mode. [ Fig. 15] Fig. Figure 15 is a data flow diagram of writing I2C data to control a CIS in basic mode. [ Fig. 16] Fig. 16 is a block diagram of a schematic configuration of a communication system according to a first embodiment. [ Fig. 17] Fig. 17 is a diagram showing a memory map of an internal memory according to the first embodiment. [ Fig. 18] Fig. 18 is an explanatory diagram of a processing operation of an information processing apparatus according to the first embodiment. [ Fig. 19] Fig. 19 is an explanatory diagram of a processing operation that Fig. 18 follows. [ Fig. 20] Fig. 20 is an explanatory diagram of a processing operation that Fig. 19 follows. [ Fig. 21] Fig. 21 is an explanatory diagram of a processing operation that Fig. 20 follows. [ Fig. 22] Fig. 22 is a data flow diagram illustrating writing of I2C configuration data according to the first embodiment. [ Fig. 23] Fig. 23 is a data flow diagram illustrating writing of I2C data for controlling a CIS according to the first embodiment. [ Fig. 24] Fig. 24 is an illustration of a portion of information stored in an ASEP register of a root according to a second embodiment. [ Fig. 25] Fig. 25 is an illustration of a correspondence relationship between a target code and a target ID. [ Fig. 26] Fig. Figure 26 is an illustration of a data format written to the internal memory. [ Fig. 27] Fig. 27 is an explanatory diagram of a processing operation of an information processing apparatus according to the second embodiment. [ Fig. 28] Fig. 28 is an explanatory diagram of a processing operation that Fig. 27 follows. [ Fig. 29] Fig. 29 is an explanatory diagram of a processing operation that Fig. 28 follows. [ Fig. 30] Fig. 30 is a data flow diagram illustrating writing of I2C configuration data according to the second embodiment. [ Fig. 31] Fig. 31 is a data flow diagram illustrating writing of I2C data for controlling a CIS according to the second embodiment. [ Fig. 32] Fig. 32 is a block diagram of a schematic configuration of a communication system applicable to the first and second embodiments. [ Fig. 33] Fig. 33 is an illustration of a portion of information stored in an ASEP register of a leaf according to a third embodiment. [ Fig. 34] Fig. 34 is an illustration of a correspondence relationship between a group number, a destination code, and a destination ID. [ Fig. 35] Fig. 35 is a block diagram of an embodiment of connecting multiple cameras between a camera A and a camera B in Fig. 29 by a chain. [ Fig. 36] Fig. 36 is a representation of one of the designs of Fig. 35 corresponding I2C address registers. [Description of embodiments]

[0025] Embodiments of a communication device and a communication system are described below with reference to the drawings. Although the following mainly describes main components of the communication device and the communication system, the communication device and the communication system may have components and functions that are not shown or described. The following description does not exclude components and functions that are not shown or described. (Basic mode of the communication system)

[0026] Fig. 1 is a block diagram of a schematic embodiment of a communication system according to the present disclosure. Fig. The communication system shown in Figure 1 is a communication system in a vehicle and comprises an ECU (10) and two cameras A (20) and B (40) which are connected via a chain.

[0027] The ECU (10) comprises a CPU (110), an I2C MASTER #1 (111), an I2C SLAVE #1 (121), an internal memory (mem #1 (131)), and a DLL (root) (150). A root (100) comprises several encoders (ASEs (142, 146)), several decoders (ASDs (141, 145)), an ASEP register (ASEP regs (140, 144)), a DLL (150), and a PhyL (160). Camera A (20) includes a DLL (sheet) (250), an I2C MASTER #3 (221), an internal memory (mem #3) (231), an ASA node #2 (200), a CMOS image sensor (CIS) #4 (401), an internal memory (mem #4) (431), an I2C SLAVE #4 (421), a CMOS image sensor (CIS) #5 (402), an internal memory (mem #5) (432), and an I2C SLAVE #5 (422).

[0028] A leaf (200) includes an ASEP register (ASEP-Reg (240)), an encoder (ASE (242)), a decoder (ASD (241)), a DLL (250), an OAM (255), a register (Reg (256)), and a PhyL (260). An ASA node #3 (300) includes a DLL (350), a branch function (351), and a PhyL (360).

[0029] The camera B (40) comprises a sheet (500), an I2C MASTER #6, an internal memory (mem #6), a CMOS image sensor (CIS) #7, an internal memory (mem #7), an I2C SLAVE #7, a CMOS image sensor (CIS) #8, an internal memory (mem #8) and an I2C SLAVE #8.

[0030] A leaf (500) comprises an ASEP register (ASEP-Reg (540)), an encoder (ASE (542)), a decoder (ASD (541)), a DLL (550), an OAM (555), a register (Reg (556)) and a PhyL (560).

[0031] As in Fig. As shown in Figure 1, the communication system according to the present disclosure includes the root (100) and the leaf (200) (500) that perform high-speed serial communication according to ASA standards. Hereinafter, the root (100) may be referred to as node #1, the leaf (200) may be referred to as node #2, and the leaf (500) may be referred to as node #5.

[0032] I2C configuration data is written to the ASEP register (240) in leaf (200) and the ASEP register (540) in node 5 (500) before I2C communication begins. The I2C configuration data includes an I2C CLK rate indicating the operating speed of the I2C bus, slave addresses to be managed, and flag information indicating the relationship between the offset address lengths handled by the slave addresses.

[0033] Fig. Figure 2 is a representation of information stored in the ASEP register (I2C address register) (540) in sheet (500). Fig. 2, a slave address (7'h52) is assigned to the ASEP register (540). An offset address (200) stores a value (4'h4) indicating an I2C CLK rate (400 kHz) at which the I2C bus (51) should operate, and an offset address (207) stores a slave address (7'h47), which is a slave address managed by an ASA node 5 (500), flag information indicating that the offset address has 16 bits, and flag information (1'b0) indicating that the slave address (7'h48) and the offset address together have 8 bits.

[0034] In an ASA V1.01, the CPU (110) in the ECU (10) accesses internal memory #1 (131) via the I2C master (111) and the I2C slave (121). Internal memory #1 (131) is a memory map divided into multiple address regions, and each address region can access different blocks.

[0035] Fig. Figure 3 is a diagram of a memory map of the internal memory (mem #1) in Fig. 1. As in Fig. As shown in Figure 3, I2C MASTER #1 (111) writes I2C packet data, which is a source of the I2C packet, to the respective address regions of internal memory #1 (131). Therefore, the relationship between the node (ASA Node #2, ASA Node #5) of leaf (200) (500) and the slave address under its control is designed to be managed in the address region of internal memory #1 (131).

[0036] In an example in Fig. 3 is an address region ((0×0000-0×FFF) a region in which communication with ASA node #2 (200) is performed, and an address region (0x2000-0x2FFF) is a region in which communication with ASA node #5 (500) is performed.

[0037] The ASD (141) and the ASE (142) perform I2C communication with ASA node #2 (200) using the address range (0x0000-0xFFF). The ASD (145) and the ASE (146) perform I2C communication with ASA node #5 (500) using the address range (0x2000-2xFFF). In addition, an OAM (155) uses an address range (0x4000-0x4FFF).

[0038] Fig. 4 to 13 are explanatory diagrams of processing operations of the information processing apparatus according to a basic mode of the present disclosure. Fig. 4 to 13 illustrate steps 1 to 16 in the execution order of processing in the information processing apparatus.

[0039] As in Fig. As shown in Figure 3, since the I2C MASTER #1 (111) must divide the address region of the internal memory #1 (131) for each ASA node that is a transfer destination before use, the utilization efficiency of the internal memory #1 (131) deteriorates. For example, there is a problem that the amount of transfer data to be transferred via I2C at one time is limited by the address region allocated in the internal memory #1 (131), making it difficult to utilize a memory space effectively.

[0040] In addition, as in Fig. 3, an ASE / ASD of the ASA node corresponding to each address region in the internal memory #1 (131) must be specified, and there is a problem that the number of circuits of the root (100), which is the ASA node #1, increases.

[0041] In an ASA design V1.01, the CPU (110) in the ECU (10) gets access to the internal memory #1 (131) via the I2C master (111) and the I2C slave (121). As in Fig. As shown in Figure 3, internal memory #1 (131) is a memory map divided into multiple address regions, and the respective address regions can access different blocks. For example, if the ECU (10) sends control data of the CIS #7 (601) built into camera B (50) to the internal memory #7 (631) via I2C communication, the CPU (110) must first write I2C configuration data, including the I2C CLK rate of the I2C bus (51) of camera B (50) and the slave address, which is handled by the ASA node #5 (500) and has an offset address length of a flag (8 bits / 16 bits), into the ASEP register (540), as shown in Fig. 2 shown.

[0042] Fig. Figure 14 is a data flow diagram of writing I2C configuration data in basic mode. Step 1 in Fig. 4 comprises three processing steps: steps 1-1, 1-2 and 1-3. In step 1-1, the CPU (110) instructs the I2C MASTER #1 (111) to write I2C packet data, which includes I2C configuration data for the ASEP register (540), into the internal memory #1 (131) of the I2C SLAVE #1 (121) ((11-1) in Fig. 14) to write.

[0043] Next, in step 1-2, the I2C-MASTER #1 (111) sends the I2C packet data along with a write address (0x2000) for the internal memory #1 (131) to the slave address (7'h41) of the I2C-SLAVE #1 (121) ((11-1) in Fig. 14).

[0044] Next, in step 1-3, the I2C SLAVE #1 (121) writes the received I2C packet data to the internal memory #1 (131).

[0045] Step 2 in Fig. 4 includes three processing steps: steps 2-1, 2-2, and 2-3. In step 2-1, once the I2C packet data has been written to internal memory #1 (131), the ASE (146) reads the I2C packet data, converts the I2C packet data into the I2C packet for the ASA, and sends the I2C packet to the DLL (150).

[0046] In step 2-2, the DLL (150) adds a header packet of the ASA node #1 as the transmission source and the ASA node #5 as the transmission destination to the I2C packet received from the ASE (146) and sends a container (30-1) to the PhyL (160).

[0047] In step 2-3, the PhyL (160) sends the container (30-1) via the ASA (30) to the opposite ASA node #2 (200).

[0048] Step 3 in Fig. 5 comprises five processing steps: steps 3-1, 3-2, 3-3, 3-4, and 3-5. In step 3-1, the PhyL (260) in ASA node #2 (200) restores the received container (30-1) and sends the container (30-1) to the DLL (250).

[0049] In step 3-2, the DLL (250) considers the header packet in the received container (30-1), determines that the container (30-1) is an I2C packet addressed to the ASA node #5, and sends the container (30-1) as it is to the branching function unit (351).

[0050] In step 3-3, the branching function unit (351) sends the received container (30-1) to the DLL (350). In step 3-4, the DLL (350) sends the received container (30-1) as it is to the PhyL (360). In step 3-5, the PhyL (360) sends the received container (30-1) as container (40-1) via an ASA (40) to the opposite ASA node #5 (500). Step 4 in Fig. 5 includes three processing steps: steps 4-1, 4-2, and 4-3. In step 4-1, the PhyL (560) in ASA node #5 (500) restores the received container (40-1) and sends the container (40-1) to the DLL (550).

[0051] In step 4-2, the DLL (550) examines the header packet in the received container (40-1), determines that the container (40-1) is an I2C packet addressed to ASA node #5, and sends the I2C packet to the corresponding ASD (541). Furthermore, the DLL (550) considers ASA node #1 as a transmission source included in the received header packet.

[0052] In step 4-3, the ASD (541) restores the original I2C packet data from the received I2C packet, and the ASD (541) analyzes the restored I2C packet data and writes the I2C configuration data into the ASEP register (540) addressed to the slave address (7'h52) ( Fig. 2 and (50-1) in Fig. 14).

[0053] The ASD (541) also writes the I2C configuration data to the internal memory #6 (531) so that the I2C master #6 (521) sets the I2C operating speed of the I2C bus (51).

[0054] In addition, the I2C master #6 (521) can understand whether the offset address length of the slave address to be managed is 8 bits or 16 bits.

[0055] Step 5 in Fig. 6 includes three processing steps: steps 5-1, 5-2, and 5-3. In step 5-1, each time the ASD (541) writes the I2C configuration data to the ASEP register (540), the ASE (542) generates ACK / NACK as the write result and converts the ACK / NACK into a packet of ACK / NACK data in the ASA. The ASE (542) sends an I2C packet to the DLL (550), which is created by adding a packet of the slave address as the write destination to a packet of ACK / NACK data ((50-2) in Fig. 14) is obtained.

[0056] In step 5-2, the DLL (550) adds a header packet of the ASA node #5 as the transmission source and the ASA node #1 as the transmission destination to the I2C packet received from the ASE (542) and sends the container (40-2) to the PhyL (560).

[0057] In step 5-3, the PhyL (560) sends the container (40-2) via the ASA (40) to the opposite ASA node #3 (300).

[0058] Step 6 in Fig. 6 comprises five processing steps: steps 6-1, 6-2, 6-3, 6-4, and 6-5. In step 6-1, the PhyL (360) in ASA node #3 (300) restores the received container (40-2) and sends the container (40-2) to the DLL (350).

[0059] In step 6-2, the DLL (350) considers the header packet in the received container (40-2), determines that the container (40-2) is an I2C packet addressed to the ASA node #1, and sends the container (40-2) as it is to the branching function unit (351).

[0060] In step 6-3, the branching function unit (351) sends the received container (40-2) to the DLL (250). In step 6-4, the DLL (250) sends the received container (40-2) as is to the PhyL (260).

[0061] In step 6-5, the PhyL (260) sends the received container (40-2) as a container (30-2) via the ASA (30) to the opposite ASA node #1 (100). Step 7 in Fig. Figure 7 includes six processing steps: steps 7-1, 7-2, 7-3, 7-4, 7-5, and 7-6. In step 7-1, the PhyL (160) in ASA node #1 (100) restores the received container (30-2) and sends the container (30-2) to the DLL (150).

[0062] In step 7-2, the DLL (150) examines the header packet in the received container (30-2), determines that the container (30-2) is an I2C packet addressed to the ASA node #1, and sends the I2C packet to the corresponding ASD (145).

[0063] In step 7-3, the ASD (145) restores the original I2C packet data from the received I2C packet, and the ASD (145) writes the restored I2C packet data to and after the write address (0x2800) of the internal memory #1 (131).

[0064] In step 7-4, the CPU (110) periodically issues read commands to the I2C MASTER #1 (111) to check whether the ACK / NACK data, which is a write result of the I2C configuration data, has been written into the internal memory #1 (131) of the I2C SLAVE #1 (121).

[0065] In step 7-5, the I2C-MASTER #1 (111) sends the I2C packet data together with a read address (0x2800) for the internal memory #1 (131) to the slave address (7'h41) of the I2C-SLAVE #1 (121) ((11-2) in Fig. 14).

[0066] In step 7-6, the CPU (110) checks the I2C packet data ((12-2)) read by the I2C-MASTER #1 (111) in Fig. 14) to check whether the I2C configuration data has been written to the ASEP register (540) in ASA node #5 (500).

[0067] In an ASA V1.01, the CPU (110) in the ECU (10) gets access to the internal memory #1 (131) via the I2C master (111) and the I2C slave (121). As shown in Fig. 3, the internal memory #1 (131) is a memory map divided into several address regions, and the respective address regions can access different blocks.

[0068] For example, if the I2C configuration data has been written into the ASEP register (540) in the above-mentioned step 1 to step 7, and the ECU (10) sends the control data of the CIS #7 (601) built into camera B (50) to the internal memory #7 (631) by means of the I2C communication, the processing in step 8 is executed in Fig. 8. Step 8 in Fig. 8 includes three processing steps: steps 8-1, 8-2 and 8-3. Fig. Figure 15 is a data flow diagram of writing I2C data to control a CIS in basic mode. In step 8-1, the CPU (110) instructs the I2C MASTER #1 (111) to write I2C packet data, which includes control data from the CIS #7 (601), into the internal memory #1 (131) of the I2C SLAVE #1 (121) ((11-3) in Fig. 15) to write.

[0069] The I2C packet data includes a slave address (7'h47) of the I2C slave #7 (621) and an offset address of the internal memory #7 (631).

[0070] In step 8-2, the I2C-MASTER #1 (111) sends the I2C packet data together with a write address (0x2000) for the internal memory #1 (131) to the slave address (7'h41) of the I2C-SLAVE #1 (121) ((11-3) in Fig. 15).

[0071] Next, in step 8-3, the I2C SLAVE #1 (121) writes the received I2C packet data to the internal memory #1 (131).

[0072] Step 9 in Fig. Figure 9 includes three processing steps: steps 9-1, 9-2, and 9-3. In step 9-1, once the I2C packet data has been written to internal memory #1 (131), the ASE (146) reads the I2C packet data, converts the I2C packet data into the I2C packet for the ASA, and sends the I2C packet to the DLL (150).

[0073] In step 9-2, the DLL (150) adds a header packet of the ASA node #1 as the transmission source and the ASA node #5 as the transmission destination to the I2C packet received from the ASE (146) and sends the container (30-3) to the PhyL (160).

[0074] In step 9-3, the PhyL (160) sends the container (30-3) via the ASA (30) to the opposite ASA node #2 (200).

[0075] Step 10 in Fig. Figure 9 includes five processing steps: steps 10-1, 10-2, 10-3, 10-4, and 10-5. In step 10-1, the PhyL (260) in ASA node #2 (200) restores the received container (30-3) and sends the container (30-3) to the DLL (250).

[0076] In step 10-2, the DLL (250) considers the header packet in the received container (30-3), determines that the container (30-3) is an I2C packet addressed to the ASA node #5, and sends the container (30-3) as it is to the branching function unit (351).

[0077] In step 10-3, the branching function unit (351) sends the received container (30-3) to the DLL (350). In step 10-4, the DLL (350) sends the received container (30-3) as it is to the PhyL (360). In step 10-5, the PhyL (360) sends the received container (30-3) as a container (40-3) via the ASA (40) to the opposite ASA node #5 (500). Step 11 in Fig. Figure 10 includes three processing steps: steps 11-1, 11-2, and 11-3. In step 11-1, the PhyL (560) in ASA node #5 (500) restores the received container (40-3) and sends the container (40-3) to the DLL (550).

[0078] In step 11-2, the DLL (550) examines the header packet in the received container (40-3), determines that the container (40-3) is an I2C packet addressed to ASA node #5, and sends the I2C packet to the corresponding ASD (541). Furthermore, the DLL (550) considers ASA node #1 as a transmission source included in the received header packet. In step 11-3, the ASD (541) recovers the original I2C packet data from the received I2C packet, and the ASD (541) analyzes the recovered I2C packet data and determines that the I2C packet data is CIS control data addressed to the slave address (7'h47). The ASD (541) writes the recovered I2C packet data into the internal memory #6 (531) ((53-3) in Fig. 15).

[0079] Step 12 in Fig. 10 comprises three processing steps: steps 12-1, 12-2, and 12-3. In step 12-1, the I2C master #6 (521) reads the I2C packet data written into the internal memory #6 (531) and sends the I2C packet data as an I2C signal to the I2C bus (51) according to the I2C configuration data set in step 4-3 ((51-3) in Fig. 15).

[0080] In step 12-2, the I2C slave #7 (621) receives the I2C signal addressed to the slave address (7'h 47) and writes the received control data of the CIS #7 (601) into the internal memory #7 (631) ((52-3) in Fig. 6). (Fug6(52-3))

[0081] In step 12-3, the CIS #7 (601) reads the control data written to the internal memory #7 (631). Step 13 in Fig. Figure 11 includes step 13-1. In step 13-1, every time I2C slave 7 (621) writes the control data to internal memory 7 (631) in step 12-2, I2C slave 7 (621) returns the ACK / NACK to I2C master 6 (521). I2C master 6 (521) writes the received ACK / NACK to internal memory 6 (531).

[0082] Step 14 in Fig. Figure 11 includes three processing steps: steps 14-1, 14-2, and 14-3. In step 14-1, the ASE (542) reads the ACK / NACK data once the writing of the ACK / NACK to the internal memory #6 (531) is completed. The ASE (542) converts the ACK / NACK data into an I2C packet of the ASA, which is obtained by adding a packet of a slave address as a transmission source to a packet of the ACK / NACK data, and sends the packet to the DLL (550) ((53-4) in Fig. 15).

[0083] In step 14-2, the DLL (550) adds a header packet of the ASA node #5 as the transmission source and the ASA node #1 as the transmission destination to the I2C packet received from the ASE (542) and sends the container (40-4) to the PhyL (560).

[0084] In step 14-3, the PhyL (560) sends the container (40-4) via the ASA (40) to the opposite ASA node #3 (300).

[0085] Step 15 in Fig. Figure 12 comprises five processing steps: steps 15-1, 15-2, 15-3, 15-4, and 15-5. In step 15-1, the PhyL (360) in ASA node #3 (300) restores the received container (40-4) and sends the container (40-4) to the DLL (350).

[0086] In step 15-2, the DLL (350) considers the header packet in the received container (40-4), determines that the container (40-4) is an I2C packet addressed to the ASA node #1, and sends the container (40-4) as it is to the branching function unit (351).

[0087] In step 15-3, the branching function unit (351) sends the received container (40-4) to the DLL (250). In step 15-4, the DLL (250) sends the received container (40-4) as is to the PhyL (260).

[0088] In step 15-5, the PhyL (260) sends the received container (40-4) as a container (30-4) via the ASA (30) to the opposite ASA node #1 (100).

[0089] Step 16 in Fig. Figure 13 includes six processing steps: steps 16-1, 16-2, 16-3, 16-4, 16-5, and 16-6. In step 16-1, the PhyL (160) in ASA node #1 (100) restores the received container (30-4) and sends the container (30-4) to the DLL (150).

[0090] In step 16-2, the DLL (150) examines the header packet in the received container (30-4), determines that the container (30-4) is an I2C packet addressed to the ASA node #1, and sends the I2C packet to the corresponding ASD (145).

[0091] In step 16-3, the ASD (145) restores the original I2C packet data from the received I2C packet and the ASD (145) writes the recovered I2C packet data to and from the write address (0x2800) of internal memory #1 (131).

[0092] In step 16-4, the CPU (110) periodically issues read commands to the I2C MASTER #1 (111) to check whether the ACK / NACK data, which is a write result of the control data of the CIS #7, has been written into the internal memory #1 (131) of the I2C SLAVE #1 (121).

[0093] In step 16-5, the I2C-MASTER #1 (111) sends the I2C packet data together with a read address (0x2800) for the internal memory #1 (131) to the slave address (7'h41) of the I2C-SLAVE #1 (121) ((11-4) in Fig. 15).

[0094] In step 16-6, the CPU (110) checks the I2C packet data read by the I2C MASTER #1 (111) to check whether the control data of the CIS #7 has been successfully written into the internal memory #7 (631) of the I2C slave #7 (621) ((12-4) in Fig. 15). (First embodiment)

[0095] Fig. 16 is a block diagram of a schematic configuration of a communication system according to the first embodiment. The communication system according to the first embodiment includes an ECU (10) and two cameras A (20) and B (40) connected by a chain, as shown in Fig. 16 shown.

[0096] The ECU (10) comprises a root (100), a CPU (110), an I2C MASTER #1 (111), an I2C SLAVE #1 (121), and an internal memory (mem #1) (131). A root (100) comprises an encoder (ASE (142)), a decoder (ASD (141)), an ASEP register (ASEP-Reg (140)), a DLL (150), and a PhyL (160). The internal memory (mem #1) (131) can be provided in the root (100).

[0097] The internal design of the root (100) according to the Fig. 16 partially differs from the internal design of the root (100) in Fig. 1. Specifically, the root (100) in Fig. 16 does not include the ASEP-Reg (144), the ASD (145) and the ASE (146), which are in the root (100) in Fig. 1. With the exception of this point, the design of the communication system in Fig. 16 and the design of the communication system in Fig. 1 equal.

[0098] In the first embodiment, the CPU (110) in the ECU (10) gains access to the internal memory #1 (131) via the I2C master (111) and the I2C slave (121).

[0099] Fig. Figure 17 is a memory map diagram of internal memory #1 (131) according to the first embodiment. Internal memory #1 (131) is a memory map shared by all ASA nodes. Therefore, I2C MASTER #1 (111) writes the header packet data (1) into Fig. 17) as the source of the “ASA Node # of the destination” for insertion into the header packet and (2) the I2C packet data ((2) in Fig. 17) as the source of the I2C packet in the address region of internal memory #1 (131).

[0100] Note that if there are multiple ASA destination nodes, the header packet data includes multiple "ASA destination node IDs." Specifically, the header packet data includes four destination IDs according to the ASA (Automotive SerDes Alliance) standards.

[0101] As in Fig. As shown in Fig. 17, the header packet data according to the first embodiment may be fixed-length data, and an invalid ID is assigned to an unused node ID among the four destination IDs.

[0102] Alternatively, the header packet data may be variable-length data, where information specifying the number of valid destination IDs is added to the header of the header packet and then a valid destination ID is assigned.

[0103] Therefore, in the first embodiment, the relationship between the node (ASA node #2, ASA node #5) of the leaf (200) (500) and the slave address under its control is not managed in the address regions of the internal memory #1 (131). In the first embodiment, the address region (0×0000-0×FFF) is a region where communication with the opposing ASA node is established.

[0104] The ASD (141) and the ASE (142) use an address range (0x0000-0xFFF) to generate and parse packets for I2C communication with the opposing ASA node. Furthermore, the OAM (155) uses an address range (0x1000-0x1FFF).

[0105] As described above, in the first embodiment, the relationship between the leaf node and the slave address under its control is managed as data in the internal memory #1 (131), and thus, an ASE / ASD for each ASA node becomes unnecessary, and the memory capacity can be reduced compared to the internal memory #1 (131). Fig. 1 may be reduced.

[0106] In the first embodiment, the CPU (110) in the ECU (10) gains access to the internal memory #1 (131) via the I2C master (111) and the I2C slave (121).

[0107] The internal memory #1 (131) according to the first embodiment is a memory map shared by ASA nodes, as shown in Fig. 17 shown.

[0108] For example, if the ECU (10) sends control data of the CIS #7 (601) built into camera B (50) to the internal memory #7 (631) by means of I2C communication, the CPU (110) must first write I2C configuration data including the I2C CLK rate of the I2C bus (51) of camera B (50) and the slave address handled by the ASA node #5 (500), and with an offset address length of a flag (8 bits / 16 bits) in the ASEP register (540) ( Fig. 2).

[0109] Fig. 18 to 21 are explanatory diagrams each illustrating a processing operation of the information processing device according to the first embodiment. Fig. Figures 18 to 21 show steps 1, 2, 7, 8, 9, and 16 in the execution order of the processing in the information processing device. The processing in the other processing steps is similar to that in Fig. 4 to 13.

[0110] Fig. 22 is a data flow diagram illustrating writing of I2C configuration data according to the first embodiment. Fig. 23 is a data flow diagram illustrating writing of I2C data for controlling a CIS according to the first embodiment.

[0111] Step 1 in Fig. 18 comprises three processing steps: steps 1-1, 1-2 and 1-3. In step 1-1, the CPU (110) instructs the I2C-MASTER #1 (111) to write header packet data ((1) into Fig. 17), which includes identification information (destination ID) of the ASA node #5 as the destination for the ASEP register (540), and I2C packet data ((2) in Fig. 17), which include I2C configuration data, into the internal memory #1 (131) of the I2C-SLAVE #1 (121) ((11-1) in Fig. 22) to write.

[0112] Note that the I2C configuration data for the ASEP register (540) includes the I2C CLK rate of the I2C bus (51), a slave address (7'h47) managed by the ASA node #5 (500), and flag information (8 bits / 16 bits) indicating the length of the offset address thereof.

[0113] In step 1-2, the I2C-MASTER #1 (111) sends the header packet data and the I2C packet data together with a write address (0x0000) for the internal memory #1 (131) to the slave address (7'h41) of the I2C-SLAVE #1 (121) ((11-1) in Fig. 22).

[0114] In step 1-3, the I2C SLAVE #1 (121) writes the received header packet data and the I2C packet data into the internal memory #1 (131).

[0115] Step 2 in Fig. Figure 18 includes three processing steps: steps 2-1, 2-2, and 2-3. In step 2-1, once the header packet data has been written to internal memory #1 (131), the ASE (142) reads the header packet data and sends the header packet data to the DLL (150). Next, once the I2C packet data has been written to internal memory #1 (131), the ASE (142) reads the I2C packet data, converts the I2C packet data into the I2C packet for the ASA, and sends the I2C packet to the DLL (150).

[0116] In step 2-2, the DLL (150) generates a header packet from the header packet data received from the ASE (142) and its own ASA node #. Furthermore, the DLL (150) adds the generated header packet to the I2C packet received from the ASE (142) and sends the container (30-1) to the PhyL (160).

[0117] In step 2-3, the PhyL (160) sends the container (30-1) via the ASA (30) to the opposite ASA node #2 (200).

[0118] Step 3 to step 6 in the first embodiment are identical to step 3 to step 6 in the Fig. 5 and Fig. 6, so that the explanation of it is omitted.

[0119] Step 7 in Fig. 19 includes six processing steps: Steps 7-1, 7-2, 7-3, 7-4, 7-5, 7-6. In step 7-1, the PhyL (160) in ASA node #1 (100) restores the received container (30-2) and sends the container (30-2) to the DLL (150).

[0120] In step 7-2, the DLL (150) considers the header packet in the received container (30-2), determines that the container (30-2) is an I2C packet addressed to the ASA node #1, and sends the ASA node information via a transmission source and the I2C packet to the corresponding ASD (141).

[0121] In step 7-3, the ASD (141) restores the original data from the received I2C packet, and the ASD (141) writes the ASA node information about a transmission source and the restored I2C packet data to and after the write address (0x0800) of the internal memory #1 (131).

[0122] In step 7-4, the CPU (110) periodically issues read commands to the I2C MASTER #1 (111) to check whether the ACK / NACK data, which is a write result of the I2C configuration data, has been written into the internal memory #1 (131) of the I2C SLAVE #1 (121).

[0123] In step 7-5, the I2C-MASTER #1 (111) reads the ASA node information about a transmission source and the I2C packet data together with a read address (0x0800) for the internal memory #1 (131) to the slave address (7'h41) of the I2C-SLAVE #1 (121) ((11-2) in Fig. 22).

[0124] In step 7-6, the CPU (110) checks the ASA node information about a transmission source and the I2C packet data read by the I2C MASTER #1 (111) to check whether the I2C configuration data is written to the ASEP register (540) in the ASA node #5 (500) ((12-2) in Fig. 22) were written.

[0125] Step 8 in Fig. 20 comprises three processing steps: steps 8-1, 8-2, and 8-3. For example, if the I2C configuration data was written to the ASEP register (540) in steps 1 to 7 and the ECU (10)

[0126] When the control data of the CIS #7 (601) installed in camera B (50) is sent to the internal memory #7 (631) via I2C communication, the CPU (110) instructs the I2C-MASTER #1 (111) to send the header packet data ((1) in Fig. 17), which specify the ASA node 5# as the destination, and the I2C packet data ((2) in Fig. 17), which include the control data of the CIS #7 (601), into the internal memory #1 (131) in the I2C-SLAVE #1 (121) in step 8-1 ((11-3) in Fig. 22) to write.

[0127] Note that the I2C packet data includes a slave address (7'h47) of I2C slave #7 (621) and an offset address of internal memory #7 (631).

[0128] In step 8-2, the I2C-MASTER #1 (111) sends the header packet data and the I2C packet data together with a write address (0x0000) for the internal memory #1 (131) to the slave address (7'h41) of the I2C-SLAVE #1 (121) ((11-3) in Fig. 22).

[0129] In step 8-3, the I2C SLAVE #1 (121) writes the received header packet data and the I2C packet data into the internal memory #1 (131).

[0130] Step 9 in Fig. Figure 20 includes three processing steps: steps 9-1, 9-2, and 9-3. In step 9-1, once the header packet data has been written to internal memory #1 (131), the ASE (142) reads the header packet data and sends the header packet data to the DLL (150). Next, once the I2C packet data has been written to internal memory #1 (131), the ASE (142) reads the I2C packet data, converts the I2C packet data into the I2C packet for the ASA, and sends the I2C packet to the DLL (150).

[0131] In step 9-2, the DLL (150) creates a header packet from the header packet data received from the ASE (142) and its own ASA node #.

[0132] In addition, the DLL (150) adds the generated header packet to the I2C packet received from the ASE (142) and sends the container (30-3) to the PhyL (160).

[0133] In step 9-3, the PhyL (160) sends the container (30-3) via the ASA (30) to the opposite ASA node #2 (200).

[0134] Step 10 to step 15 in the first embodiment are identical to step 10 to step 15 in the Fig. 9 to 12, so that the explanation of it is omitted.

[0135] Step 16 in Fig. Figure 21 comprises six processing steps: steps 16-1, 16-2, 16-3, 16-4, 16-5, and 16-6. In step 16-1, the PhyL (160) in ASA node #1 (100) restores the received container (30-4) and sends the container (30-4) to the DLL (150).

[0136] In step 16-2, the DLL (150) considers the header packet in the received container (30-4), determines that the container (30-4) is an I2C packet addressed to the ASA node #1, and sends the ASA node information via a transmission source and the I2C packet to the corresponding ASD (141).

[0137] In step 16-3, the ASD (141) restores the original I2C packet data from the received I2C packet, and the ASD (141) writes the ASA node information about a transmission source and the restored I2C packet data to and after the write address (0x0800) of the internal memory #1 (131).

[0138] In step 16-4, the CPU (110) periodically issues read commands to the I2C MASTER #1 (111) to check whether the ACK / NACK data, which is a write result of the control data of the CIS #7, has been written into the internal memory #1 (131) of the I2C SLAVE #1 (121).

[0139] In step 16-5, the I2C-MASTER #1 (111) reads the ASA node information about a transmission source and the I2C packet data together with a read address (0x0800) for the internal memory #1 (131) for the slave address (7'h41) of the I2C-SLAVE #1 (121) ((11-4) in Fig. 22).

[0140] In step 16-6, the CPU (110) checks the ASA node information about a transmission source and the I2C packet data read by the I2C MASTER #1 (111) to check whether the control data of the CIS #7 has been successfully written into the internal memory #7 (631) of the I2C slave #7 (621) ((12-4) in Fig. 22).

[0141] As described above, a first I2C communication instrument (e.g., the I2C master #1 (111) and the I2C slave #1 (121)) according to the first embodiment is connected to the root (100), and the root (100) causes the first I2C communication instrument (111, 121) and a second I2C communication instrument (221, 421, 422, 521, 621, 622), which is a communication partner device (e.g., leaf (200) or (500)), to establish communication between them.

[0142] The root (100) includes internal memory #1 (131), the encoder (ASE (142)), the decoder (ASD (140)), and a communication unit (DLL (150)). Internal memory #1 (131) stores header packet data including a destination ID of the second communication device (200, 500) and I2C packet data including a slave address and an offset address of the second I2C communication device.

[0143] The encoder (ASE (142)) generates header packet data including a destination ID of the communication partner device (200, 500) and I2C packet data including a slave address and an offset address of the second I2C communication instrument (221, 421, 422, 521, 621, 622). The communication unit (150, 160) sends a transmission packet including the header packet data and I2C packet data generated by the encoder (142) to the communication partner device (200, 500) using a time division duplex (TDD) communication scheme and receives a reception packet from the communication partner device (200, 500) using the TDD communication scheme. The decoder (ASD (140)) generates I2C packet data from the reception packet.

[0144] Typically, the header packet data includes multiple destination IDs corresponding to multiple communication partner devices (200, 500). A memory location storing the header packet data and the I2C packet data includes a storage area for communication with the communication partner device (200, 500). For example, the header packet data includes four destination IDs according to the ASA (Automotive SerDes Alliance) standards. The encoder (142) and the decoder (141) are designed to be shared by multiple second I2C communication instruments corresponding to the multiple destination IDs.

[0145] A memory (131) that stores the header packet data and the I2C packet data has a plurality of storage locations, each having a fixed length, for storing the plurality of destination IDs included in the header packet data. An invalid ID is stored in a storage location corresponding to an unused destination ID. The memory (131) that stores the header packet data and the I2C packet data stores, as the I2C packet data, at least one of the I2C configuration data including an operating setting of the second I2C communication device and the I2C data for the second I2C communication device.

[0146] More specifically, the first communication device (100), which represents the root (100), comprises a first encoder (142), a communication unit (150, 160), and a first decoder (141). The first encoder (142) generates header packet data including a destination ID of the second communication device (200, 500) and I2C packet data including a slave address and an offset address of the second I2C communication device (221, 421, 422, 521, 621, 622). The communication unit (150, 160) sends a transmission packet comprising header packet data and I2C packet data generated by the encoder (142) to the second communication device (200, 500) using a time division duplex (TDD) communication scheme, and receives a reception packet from the second communication device (200, 500) using the TDD communication scheme. The first decoder (141) generates I2C packet data from the reception packet.

[0147] The second communication device (200, 500), representing the sheet (200) or (500), comprises a second encoder (242, 542), a communication unit (250, 260, 550, 560), and a second decoder (241, 541). The second encoder (242, 542) generates header packet data including a destination ID of the first communication device (100) and I2C packet data including a slave address and an offset address of the first I2C communication instrument (111, 121).

[0148] The communication unit (250, 260, 550, 560) sends a transmission packet generated by the second encoder (242, 542) and comprising header packet data and I2C packet data to the first communication device (100) through a time division duplex (TDD) communication scheme and receives a reception packet from the first communication device (100) through the TDD communication scheme.

[0149] The second decoder (241, 541) generates I2C packet data from the received packet.

[0150] Therefore, according to the first embodiment, it may be unnecessary to provide the I2C packet data for each sheet (200) (500) individually, and thus the storage capacity of the internal memory #1 (131) can be reduced.

[0151] In addition, since the storage space in the internal memory #1 (131) storing the header packet data and the I2C packet data is shared by all the I2C communication instruments in the leaf (200) (500), it may be unnecessary to provide the ASE (142) and the ASD (141) for each I2C communication instrument in each communication device, thereby reducing the number of the ASEs (142) and ASDs (141) and simplifying the design of the root (100). (Second embodiment)

[0152] Fig. 24 is a diagram showing a part of information stored in the ASEP register (I2C address register) of the root (100) according to the second embodiment. Fig. 24 shows an example in which a destination ID1 and a destination ID2 are stored in the offset address (209) and a destination ID3 and a destination ID4 are stored in the offset address (210).

[0153] Fig. Figure 25 is a diagram illustrating a correspondence relationship between a destination code [3:0] and a destination ID [1:4]. There are 16 types of destination codes [3:0], and combinations of destination ID1 to destination ID4 corresponding to each destination code are provided.

[0154] Fig. Figure 26 is a diagram of a data format written to an internal memory #1 (131). The header packet data and the I2C packet data are written to the internal memory #1 (131). The header packet data includes a Fig. 25, and the I2C packet data includes a slave address and an offset address.

[0155] In the second embodiment, the CPU (110) in the ECU (10) gains access to the internal memory #1 (131) via the I2C master (111) and the I2C slave (121). The internal memory #1 (131) according to the second embodiment is a memory map shared by ASA nodes. Accordingly, the I2C master #1 (111) writes header packet data and I2C packet data in data formats specified in Fig. 26 in the address region of internal memory #1 (131).

[0156] As described above, in the second embodiment, the relationship between the node (ASA node #2, ASA node #5) of the leaf (200) (500) and the slave address under its control is not managed in the address region of the internal memory #1 (131). In the second embodiment, the address region (0×0000-0×FFF) is a region where communication with the opposite ASA node is established. The ASD (141) and the ASE (142) perform I2C communication with the opposite ASA node using the address region (0×0000-0×FFF). In addition, the OAM (155) uses an address region (0x1000-0x1FFF). Once the ASE (142) receives a target code ((1) in Fig. 26), the ASE (142) changes the code from a destination ID of the corresponding ASEP Reg (140) to the header packet data format ((1) in Fig. 17) according to the first embodiment and sends the code to the DLL (150). As described above, in the second embodiment, similar to the first embodiment, the relationship between the leaf node (200) and the slave address under its control is managed as data in the internal memory #1, and thus an ASE / ASD for each ASA node becomes unnecessary, and the memory capacity can be reduced compared to the internal memory #1 ( Fig. 3) can be reduced in basic mode.

[0157] Furthermore, in the second embodiment, the header packet data required for each communication is reduced from 4 bytes in the first embodiment to 1 byte, whereby the I2C communication can be established with a smaller data volume compared to that in the first embodiment.

[0158] In the second embodiment, the CPU (110) in the ECU (10) gains access to the internal memory #1 (131) via the I2C master (111) and the I2C slave (121). As shown in Fig. As shown in Figure 26, internal memory #1 (131) is a memory map shared by ASA nodes.

[0159] For example, if the ECU (10) sends control data of the CIS #7 (601) built into camera B (50) to the internal memory #7 (631) by means of I2C communication, the CPU (110) must first write a destination ID of the leaf node (200), which is a communication partner, into the ASEP register (140) of the ASA node #1 (100), which is a root node (100), as shown in Fig. 24 shown.

[0160] Fig. 27 to 29 are explanatory diagrams each illustrating a processing operation of the information processing device according to the second embodiment. Fig. 27 to 29 illustrate steps 0 to 2 in the execution order of processing in the information processing device. Fig. 30 is a data flow diagram illustrating writing of I2C configuration data according to the second embodiment. Fig. 31 is a data flow diagram illustrating writing of I2C data for controlling a CIS according to the second embodiment.

[0161] Step 0 in Fig. 27 includes three processing steps: Steps 0-1, 0-2, 0-3 and 0-4. In step 0-1, the CPU (110) instructs the I2C-MASTER #1 (111) to write header packet data ((1) into Fig. 26) a destination code (4'b0000) as a destination into the ASEP register (140), where destination IDs indicate the ASA node #2 and the ASA node #5 as communication partners, and to write a valid flag into the internal memory #1 (131) of the I2C-SLAVE #1 (121).

[0162] Note that I2C packet data ((2) in Fig. 26) of the write command together with a destination ID, including a valid flag, a slave address (7'h21) and an offset address assigned to the ASEP register (140).

[0163] In step 0-2, the I2C-MASTER #1 (111) sends the header packet data ((1) in Fig. 26) and the I2C packet data ((2) in Fig. 26) together with a write address (0x0000) for the internal memory #1 (131) to the slave address (7'h41) of the I2C-SLAVE #1 (121).

[0164] In step 0-3, the I2C-SLAVE #1 (121) writes the received header packet data ((1) into Fig. 26) and the I2C packet data ((2) in Fig. 26) into the internal memory #1 (131) ( Fig. 26).

[0165] In steps 0-4, once the header packet data has been written to internal memory #1 (131), the ASE (142) reads the header packet data and checks the destination code (4'b0000). From the destination code, it can be seen that subsequent data is its own I2C packet data (root node (100)).

[0166] After the I2C packet data is written to the internal memory #1 (131), the ASE (142) then reads the I2C packet data and writes the ASA node #2 (destination ID1) and the ASA node #5 (destination ID2) together with a valid flag from the slave address (7'h21) contained in the I2C packet data to the offset address (209) of the ASEP register (140).

[0167] Note that if a field of the offset address (210) becomes 16'h0000 by initialization, writing may be unnecessary.

[0168] In the second embodiment, the CPU (110) in the ECU (10) gains access to the internal memory #1 (131) via the I2C master (111) and the I2C slave (121). The internal memory #1 (131) is a memory map shared by ASA nodes ( Fig. 26).

[0169] For example, if the ECU (10) sends control data of the CIS #7 (601) built into camera B (50) to the internal memory #7 (631) by means of I2C communication, the CPU (110) must, after step 0, in the ASEP register (540) ( Fig. 2) Write I2C configuration data including the I2C CLK rate of the I2C bus (51) of camera B (50) and the slave address handled by ASA node #5 (500), and with an offset address length of a flag (8 bits / 16 bits).

[0170] Step 1 in Fig. 28 comprises three processing steps: steps 1-1, 1-2 and 1-3. In step 1-1, the CPU (110) instructs the I2C-MASTER #1 (111) to write header packet data ((1) into Fig. 26) including a destination code specifying a destination into the ASEP register (540) and I2C packet data ((2) in Fig. 26) including I2C configuration data into the internal memory #1 (131) of the I2C-SLAVE #1 (121) ((11-1) in Fig. 30) to write.

[0171] Note that the I2C configuration data for the ASEP register (540) includes the I2C CLK rate of the I2C bus (51), a slave address (7'h47) managed by the ASA node #5 (500), and flag information (8 bits / 16 bits) indicating the length of its offset address. In step 1-2, the I2C MASTER #1 (111) sends the header packet data and the I2C packet data, along with a write address (0x0000) for the internal memory #1 (131), to the slave address (7'h41) of the I2C SLAVE #1 (121) ((11-1) in Fig. 30).

[0172] In step 1-3, the I2C SLAVE #1 (121) writes the received header packet data and the I2C packet data into the internal memory #1 (131).

[0173] Step 2 in Fig. 29 includes three processing steps: steps 2-1, 2-2, and 2-3. In step 2-1, the ASE (142) reads the header packet data once the header packet data has been written to internal memory #1 (131).

[0174] The ASE (142) sends a destination ID of a valid communication partner, written from a destination code (Table 2-1) specified by the header packet to the ASEP register (140), to the DLL (150) as header packet data after conversion.

[0175] Then, once the I2C packet data is written to the internal memory #1 (131), the ASE (142) reads the I2C packet data, converts the I2C packet data into the I2C packet for the ASA, and sends the I2C packet to the DLL (150).

[0176] In the second embodiment, data of a destination ID2 of the ASEP register (140) written in step 0 is read from the destination code (4'b0010) received by the ASE (142).

[0177] If en_flag of the destination ID2 is enabled (1'b1), the ASE (142) sends data (ASA node #5) of the destination ID2 to the DLL (150) as the header packet data after conversion.

[0178] Then, once the I2C packet data is written to the internal memory #1 (131), the ASE (142) reads the I2C packet data, converts the I2C packet data into the I2C packet for the ASA, and sends the I2C packet to the DLL (150).

[0179] If a target code specifies multiple target IDs, after conversion, multiple specified ASA nodes # are sent as header packet data to the DLL (150). As described above, the target code ( Fig. 25) of the second embodiment, the header packet data ((1) in Fig. 17) of the first embodiment more efficiently.

[0180] In step 2-2, the DLL (150) generates a header packet from the header packet data received from the ASE (142) after conversion and its own ASA node # . Furthermore, the DLL (150) adds the generated header packet to the I2C packet received from the ASE (142) and sends the Fig. 14 shown container (30-1) to the PhyL (160).

[0181] In step 2-3, the PhyL (160) sends the Fig. 14 shown container (30-1) via the ASA (30) to the opposite ASA node #2 (200).

[0182] Steps 3 to 16 in the second embodiment are identical to steps 3 to 16 in the first embodiment, so the explanation thereof is omitted. As described above, in the second embodiment, since a destination code that is bit string data with a fixed length is used as the header packet data stored in the internal memory, it is possible to specify a combination of multiple destination IDs with a storage capacity smaller than that of the header packet data in the first embodiment. Therefore, the amount of data communication between the I2C master and the I2C slave in the root (100) can be reduced, and the storage capacity of the internal memory can be reduced compared to the first embodiment. (Third embodiment)

[0183] Fig. Fig. 32 is a block diagram of a schematic configuration of a communication system applicable to the above-mentioned first and second embodiments. The following mainly describes differences from the communication system in Fig. 16 described.

[0184] The communication system in Fig. 32 has a multiple master configuration where an I2C master (821) of an I2C debugger (80) is connected to an I2C bus of the ECU (10).

[0185] Similar to the ECU (10), the I2C debugger (80) can perform I2C communication with camera A (20) and camera B (50) via ASA (30).

[0186] The communication system in Fig. 32 also has a multiple master configuration where an I2C master (921) of an I2C debugger (90) is connected to an I2C bus of camera B (50).

[0187] In the communication system of Fig. 32, an investigation by an I2C debugger can also be performed from the camera side, which is relatively easy to connect, but an I2C slave (522) is also necessary so that an I2C master (921) of the I2C debugger (90) can communicate via ASA (40) with an I2C device in another ASA node.

[0188] Therefore, if the page of ASA node #1 (100) is the root (100), ASA node #5 (500) is the leaf (200), and thus the information in Fig. 2 written into the ASEP-Reg (540).

[0189] If, however, the I2C debugger (90) is connected to camera B (50) and the I2C master (921) serves as the master to communicate with another I2C device in the ASA node, ASA node #5 (500) serves as the root (100) and ASA node #1 as the leaf (500). Therefore, information in Fig. 24 also written into the ASEP-Reg (540).

[0190] Fig. 33 is a diagram showing a part of information stored in the ASEP register (I2C address register) of the root according to the third embodiment. Fig. Figure 33 shows an example in which the target ID1 to target ID4 are stored for each of several groups. More specifically, Fig. 33 an example in which a destination ID1 and a destination ID2 of a group #0 are stored in the offset address (209), a destination ID3 and a destination ID4 of the group #0 are stored in the offset address (210), a destination ID1 and a destination ID2 of a group #1 are stored in an offset address (211), and a destination ID3 and a destination ID4 of the group #1 are stored in an offset address (212).

[0191] Fig. Figure 34 is an illustration of a correspondence relationship between a group number, a destination code [3:0], and a destination ID [1:4]. There are 16 types of destination codes [3:0], and combinations of destination ID1 to destination ID4 corresponding to the respective destination codes are provided for each group.

[0192] In the second embodiment, if communication is established with a destination ID that is not registered in the I2C address register, it is necessary to rewrite data of the destination ID.

[0193] On the other hand, the I2C address register ( Fig. 33) of the third embodiment, the destination ID1 to destination ID4 for each group. Therefore, in a destination code [7:0], which is Fig. 34 of the third embodiment, a destination code [7:4] representing information for identifying a group is added to the destination code [3:0] of the second embodiment.

[0194] According to Fig. 33 and Fig. 34, by first registering the target ID1 to the target ID4 of a plurality of groups, in the third embodiment, the number of unregistered target IDs decreases, and the frequency of rewriting the unregistered target IDs can be reduced.

[0195] Fig. 33 and Fig. 34 show examples in which two groups are provided, but in the third embodiment, a maximum of 64 destination IDs in a maximum of 16 groups can be registered in the ASEP register (140). According to Fig. 33 and Fig. 34, by first registering the target ID1 to the target ID4 of a plurality of groups, in the third embodiment, the number of unregistered target IDs decreases, and the frequency of rewriting the unregistered target IDs can be reduced.

[0196] Fig. 35 is a block diagram of an embodiment of connecting multiple cameras (60, 61, 62) between camera A (20) and camera B (50) in Fig. 29 by a chain.

[0197] Fig. 36 is a representation of one of the designs of Fig. 35 corresponding I2C address register. A destination ID corresponding to a group #0 destination code is stored at offset addresses (209) and (210), and a destination ID corresponding to a group #1 destination code is stored at offset addresses (211) and (212).

[0198] More specifically, the offset address (209) stores a target ID of ASA node #2, a target ID of ASA node #4, and information indicating that these target IDs are enabled. The offset address (210) stores a target ID of ASA node #7, a target ID of ASA node #9, and information indicating whether these target IDs are enabled or disabled. The offset address (211) stores a target ID of ASA node #9, a target ID of ASA node #5, and information indicating that these target IDs are enabled. In the offset address (212), information (in Fig. 36 locked) via a target ID3 of group #1 and a target ID4 of group #1.

[0199] In the design of Fig. 35 is generated when the target code [7:0] output by the ECU (10) is Fig.34 8'h01, ASA node #1 (100) generates header packet data that includes ASA node #2. In the case of 8'h03, ASA node #1 (100) generates header packet data that includes ASA nodes #2 and #4. In the case of 8'h11, ASA node #1 (100) generates header packet data that includes ASA node #9. In the case of 8'h13, ASA node #1 (100) generates header packet data that includes ASA nodes #9 and #5.

[0200] As described above, for example, the sheet (500) causes the first I2C communication instrument (111, 121) and the second I2C communication instrument (221, 421, 422, 521, 621, 622) to establish communication between them based on the I2C configuration data sent from the communication partner device (ASA node #1 (100)) to which the first I2C communication instrument (111, 121) is connected.

[0201] The ASA node #5 (500) according to the third embodiment includes an encoder (242, 542), a communication unit (221, 421, 422, 521, 621, 622), and a decoder (241, 541). The encoder (242, 542) generates header packet data including a destination ID of the communication partner device (100) and I2C packet data including a slave address and an offset address of the first I2C communication device (111, 121). The communication unit (221, 421, 422, 521, 621, 622) sends a transmission packet comprising header packet data and I2C packet data generated by the encoder (242, 542) to the communication partner device (100) using a time division duplex (TDD) communication scheme, and receives a reception packet from the communication partner device (100) using the TDD communication scheme. The decoder (241, 541) generates I2C packet data from the reception packet.As described above, in the third embodiment, the second I2C communication device (221, 421, 422, 521, 621, 622) further includes the I2C slave unit (522) to which the I2C master unit (921) is connected via the I2C bus. Therefore, if necessary, it is possible to cause the ASA node (200) or (500) to operate as a root and cause the ASA node #1 (100) to operate as a leaf. Furthermore, in the third embodiment, the plurality of second communication devices are connected by a chain, and the header packet data includes a group number indicating a group and a bit string specifying a combination of a plurality of destination IDs. Therefore, the root (100) can establish I2C communication with an I2C communication device included in each of the plurality of leaves (200, 500). It is also possible to make any of the multiple leaves connected by a concatenation work as a root.It should be noted that the present technology may have the following configurations. (1) A communication device configured to cause a first I2C communication instrument and a second I2C communication instrument connected to a communication partner device to establish communication therebetween, the communication device comprising: an encoder that generates header packet data including a destination ID of the communication partner device and I2C packet data including a slave address and an offset address of the second I2C communication instrument; a communication unit that sends a transmission packet comprising the header packet data and I2C packet data generated by the encoder to the communication partner device through a time division duplex (TDD) communication scheme and receives a reception packet from the communication partner device through the TDD communication scheme; and a decoder that generates the I2C packet data from the received packet. (2) The communication device according to (1), wherein the header packet data includes a plurality of the destination IDs corresponding to a plurality of communication partner devices. (3) The communication device according to (2), wherein a storage space storing the header packet data and the I2C packet data includes a storage space for communication with the communication partner device. (4) The communication device according to (2) or (3), wherein the header packet data includes four of the destination IDs according to ASA (Automotive SerDes Alliance) standards. (5) The communication device according to any one of (2) to (4), wherein the encoder and the decoder are intended to be shared by the plurality of communication partner devices corresponding to the plurality of destination IDs. (6) The communication device according to any one of (2) to (5), wherein a memory that stores the header packet data and the I2C packet data, has a plurality of memory locations, each having a fixed length, for storing the plurality of destination IDs contained in the header packet data, and An invalid ID is stored in the memory location corresponding to the target ID that is unused. (7) The communication device according to any one of (2) to (5), wherein the header packet data comprises variable-length data including information indicating the number of destination IDs that are valid, and wherein the destination IDs that are valid are arranged after the information. (8) The communication device according to (1), wherein the header packet data includes a destination code specifying a combination of the plurality of destination IDs. (9) The communication device according to (8), wherein the target code comprises bit string data having a fixed length. (10) The communication device according to (9), wherein the destination code comprises 4-bit data and specifies a combination of four of the destination IDs. (11) The communication device according to any one of (1) to (10), wherein a memory that stores the header packet data and the I2C packet data, as the I2C packet data, stores at least one of I2C configuration data including an operation setting of the second I2C communication instrument and I2C data for the second I2C communication instrument. (12) A communication system comprising: a first communication device to which a first I2C communication instrument is connected; and a second communication device to which a second I2C communication instrument is connected and which alternately sends and receives information to and from the first communication device within an allocated period by a time division duplex (TDD) communication scheme, wherein the first communication device comprises: a first encoder that receives header packet data comprising a destination ID of the second communication device and generates I2C packet data comprising a slave address and an offset address of the second I2C communication instrument, a communication unit that sends a transmission packet comprising the header packet data and I2C packet data generated by the first encoder to the second communication device through a time division duplex (TDD) communication scheme and receives a reception packet from the second communication device through the TDD communication scheme; and a first decoder that generates the I2C packet data from the received packet. (13) The communication system according to (12), wherein the second communication device comprises: a second encoder that generates header packet data comprising a destination ID of the first communication device and I2C packet data comprising a slave address and an offset address of the first I2C communication instrument; a communication unit that sends a transmission packet comprising the header packet data and I2C packet data generated by the second encoder to the first communication device through a time division duplex (TDD) communication scheme and receives a reception packet from the first communication device through the TDD communication scheme; and a second decoder that generates the I2C packet data from the received packet. (14) The communication system according to (13), wherein the second I2C communication instrument further comprises an I2C slave unit to which an I2C master unit is connected via an I2C bus. (15) The communication system according to (13) or (14), wherein a plurality of the second communication devices are connected by a chain and the header packet data is divided into several groups and each group contains several of the destination IDs according to ASA (Automotive SerDes Alliance) standards. (16) The communication system according to (13) or (14), wherein a plurality of the second communication devices are connected by a chain and the header packet data includes a group number specifying a group and a bit string specifying a combination of several of the destination IDs. (17) A communication device configured to cause a first I2C communication instrument and a second I2C communication instrument to establish communication between them based on I2C configuration data sent from a communication partner device to which the first I2C communication instrument is connected, the communication device comprising: an encoder that generates header packet data including a destination ID of the communication partner device and I2C packet data including a slave address and an offset address of the first I2C communication instrument; a communication unit that sends a transmission packet comprising the header packet data and I2C packet data generated by the encoder to the communication partner device through a time division duplex (TDD) communication scheme and receives a reception packet from the communication partner device through the TDD communication scheme; and a decoder that generates the I2C packet data from the receive packet, where the second I2C communication instrument further comprises an I2C slave unit to which an I2C master unit is connected via an I2C bus.

[0202] The modes of the present disclosure are not limited to the individual embodiments described above and include various modifications that may be conceived by those skilled in the art. Furthermore, the effects of the present disclosure are not limited to the effects described above. That is, various additions, modifications, and partial deletions may be made without deviating from the conceptual idea and spirit of the present disclosure derived from the contents defined in the claims and equivalents thereof. [List of reference symbols] 10 ECU 11 I2C bus 12 System bus 20 Camera 21 I2C bus 30 ASA 40 ASA 50 Camera 51 I2C bus 80 I2C debuggers 90 I2C debuggers 100 ASA nodes 111 I2C master 121 I2C slave 131 Internal memory 140 ASEP registers 141 Application Stream Decapsulator 142 Application Stream Encapsulator 150 Security layer (root / leaf) 155 Operation, administration, maintenance 156 registers 160 physical layer 200 ASA nodes 221 I2C master 231 Internal memory 240 ASEP registers 241 Application Stream Decapsulator 242 Application Stream Encapsulator 250 Security layer (sheet) 255 Operation, administration, maintenance 256 registers 260 Physical layer 300 ASA nodes 350 Link Layer (Branch) 351 Branching functional unit 360 physical layer 401 CMOS image sensor 402 CMOS image sensor 421 I2C slave 422 I2C slave 431 Internal memory 432 Internal Memory 500 ASA nodes 521 I2C master 522 I2C slave 531 Internal Memory 540 ASEP registers 541 Application Stream Decapsulator 542 Application Stream Encapsulator 550 Security layer (root / leaf) 555 Operation, administration, maintenance 556 registers 560 Physical layer 601 CMOS image sensor 602 CMOS image sensor 621 I2C slave 622 I2C slave 631 Internal memory 632 Internal Memory 821 I2C Master 831 Internal Memory 921 I2C Master 931 Internal Memory QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited patent literature

[0000] JP 2011-239011A

[0004]

Claims

[1] A communication device configured to cause a first I2C communication instrument and a second I2C communication instrument connected to a communication partner device to establish communication therebetween, the communication device comprising: an encoder that generates header packet data including a destination ID of the communication partner device and I2C packet data including a slave address and an offset address of the second I2C communication instrument; a communication unit that sends a transmission packet comprising the header packet data and I2C packet data generated by the encoder to the communication partner device through a time division duplex (TDD) communication scheme and receives a reception packet from the communication partner device through the TDD communication scheme; and a decoder that generates the I2C packet data from the received packet. [2] The communication device according to claim 1, wherein the header packet data includes a plurality of the destination IDs corresponding to a plurality of communication partner devices. [3] The communication device according to claim 2, wherein a storage space storing the header packet data and the I2C packet data includes a storage space for communication with the communication partner device. [4] The communication device of claim 2, wherein the header packet data includes four of the destination IDs according to ASA (Automotive SerDes Alliance) standards. [5] The communication device according to claim 2, wherein the encoder and the decoder are arranged to be shared by the plurality of communication partner devices corresponding to the plurality of destination IDs. [6] The communication device according to claim 2, wherein a memory storing the header packet data and the I2C packet data has a plurality of storage locations each having a fixed length for storing therein the plurality of destination IDs included in the header packet data, and an invalid ID is stored in the storage location corresponding to the destination ID that is unused. [7] The communication device according to claim 2, wherein the header packet data comprises variable-length data including information indicating a number of the destination IDs that are valid, and wherein the destination IDs that are valid are arranged after the information. [8] The communication device according to claim 1, wherein the header packet data includes a destination code specifying a combination of the plurality of destination IDs. [9] A communication device according to claim 8, wherein the target code comprises bit string data having a fixed length. [10] The communication device according to claim 9, wherein the destination code comprises 4-bit data and specifies a combination of four of the destination IDs. [11] The communication device according to claim 1, wherein a memory storing the header packet data and the I2C packet data stores, as the I2C packet data, at least one of I2C configuration data including an operation setting of the second I2C communication instrument and I2C data for the second I2C communication instrument. [12] Communication system comprising: a first communication device to which a first I2C communication instrument is connected; and a second communication device to which a second I2C communication instrument is connected and which alternately sends and receives information to and from the first communication device within an allocated period by a time division duplex (TDD) communication scheme, where the first communication device comprises: a first encoder that generates header packet data comprising a destination ID of the second communication device and I2C packet data comprising a slave address and an offset address of the second I2C communication device, a communication unit that sends a transmission packet comprising the header packet data and I2C packet data generated by the first encoder to the second communication device through a time division duplex (TDD) communication scheme and receives a reception packet from the second communication device through the TDD communication scheme, and a first decoder that generates the I2C packet data from the received packet. [13] A communication system according to claim 12, wherein the second communication device comprises: a second encoder that generates header packet data comprising a destination ID of the first communication device and I2C packet data comprising a slave address and an offset address of the first I2C communication device; a communication unit that sends a transmission packet comprising the header packet data and I2C packet data generated by the second encoder to the first communication device through a time division duplex (TDD) communication scheme and receives a reception packet from the first communication device through the TDD communication scheme; and a second decoder that generates the I2C packet data from the received packet. [14] The communication system of claim 13, wherein the second I2C communication instrument further comprises an I2C slave unit to which an I2C master unit is connected via an I2C bus. [15] The communication system of claim 13, wherein a plurality of said second communication devices are connected by a chain, and said header packet data is divided into a plurality of groups, each group comprising a plurality of said destination IDs according to ASA (Automotive SerDes Alliance) standards. [16] The communication system according to claim 13, wherein a plurality of said second communication devices are connected by a chain, and said header packet data includes a group number indicating a group and a bit string specifying a combination of a plurality of said destination IDs. [17] A communication device configured to cause a first I2C communication instrument and a second I2C communication instrument to establish communication between them on the basis of I2C configuration data sent from a communication partner device to which the first I2C communication instrument is connected, the communication device comprising: an encoder that generates header packet data including a destination ID of the communication partner device and I2C packet data including a slave address and an offset address of the first I2C communication instrument; a communication unit that sends a transmission packet comprising the header packet data and I2C packet data generated by the encoder to the communication partner device through a time division duplex (TDD) communication scheme and receives a reception packet from the communication partner device through the TDD communication scheme; and a decoder that generates the I2C packet data from the receive packet, where the second I2C communication instrument further comprises an I2C slave unit to which an I2C master unit is connected via an I2C bus.

Images