Information communication system, information communication method, information signal processing device and information signal processing method, and storage medium

[0001] This application is a Rule 53(b) continuation of International Application No. PCT/JP00/059321, filed Aug. 31, 2000.

[0002] The present invention relates to an information signal processing apparatus connected to a communication control network and an information signal processing method and, more particularly, to an information signal processing apparatus connected to an IEEE 1394-compliant communication control bus and an information signal processing method.

[0003] Moreover, the present invention relates to an information communication system having a first communication control network, a second communication network different from the first communication control network, and a connection device for enabling communication between the first communication control network and the second communication network, and an information communication method and, more particularly, to an information communication system connected by, e.g., an IEEE 1394 serial interface, and an information communication method.

[0004] A serial bus interface such as an IEEE 1394 interface can simultaneously connect a plurality of devices such as a DV (Digital Video), DC (Digital Camera), host computer, scanner, and VTR, unlike a so-called centronics parallel interface for one-to-one connection between a host computer and a terminal (device). This serial bus interface can realize a data communication network system or home network constructed by connecting a plurality of devices based on an IEEE 1394 standard as one of serial bus standards.

[0005] Various devices are connected to these networks, and many unspecified devices of different manufacturers may be connected.

[0006] According to IEEE 1394-1995, a maximum of 63 nodes can be connected to one 1394 bus (to be referred to as a “local bus” hereinafter) by an IEEE 1394 serial bus address designation method. If a 10-bit address space is defined for designation of a bus ID for specifying a bus, 1,023 buses can be connected to each other. In a cable environment, a cable between information signal processing apparatuses (to be referred to as “nodes” hereinafter) serving as devices is 4.5 m long at maximum.

[0007] To solve technical limitations posed when more than a connectable maximum of 63 devices are to be connected via an IEEE 1394 bus or a plurality of IEEE 1394 buses located at remote places are to be connected to each other, a device called a “1394 bridge” is generally used. By connecting a plurality of IEEE 1394 local buses via 1394 bridges, devices connected to the different local buses can communicate data.

[0008] In IEEE 1394, when the bus configuration changes by, e.g., an increase/decrease in the number of nodes upon insertion/removal of a device node, ON/OFF operation of the power supply, activation by hardware detection owing to a network error, or a direct instruction under host control from a protocol, a new network configuration must be recognized. In this case, each node which has detected the change transmits a bus reset signal to execute a mode in which a new network configuration is recognized.

[0009] This bus reset signal is transmitted to another nodes on the local bus. After all the nodes detect the bus reset signal, bus reset starts. When bus reset starts, data transfer is temporarily suspended. After the bus reset is finished, the suspended data transfer is restarted in a new network configuration.

[0010] In a device connected to an IEEE 1394 bus, a physical layer and data link layer in a transfer protocol are defined by IEEE 1394. As for the upper layer, various upper protocols are defined and implemented in accordance with the intended use and application of a device.

[0011] The upper protocols of IEEE 1394 determine a connection establishment method in communicating data with a specific device using an IEEE 1394 bus, a resource management method, an application data transmission/reception method, a connection cancellation method at the end of data transfer, a resume method in bus reset which is a feature of IEEE 1394 in addition to resume from an error, and protocols before and after bus reset.

[0012] A DPP (Direct Print Protocol) as an example of the upper protocols defines that when bus reset occurs, a device which establishes a connection at the start of data transfer issues a reset command, and the other device returns an acknowledge upon reception of the command, thereby restarting data transfer.

[0013] An AV/C protocol defines that when bus reset occurs before a node which has received an AV/C command issued by the other node sends a response, the command itself becomes invalid, and the command issuing node cannot expect any response.

[0014] In this manner, when IEEE 1394 bus reset occurs, data transfer is temporarily suspended, and the network topology changes before and after bus reset. An upper protocol layer must cope with such a status change, so that the protocol standard defines procedures on both the data transmitting and receiving sides upon occurrence of bus reset. This definition allows continuing data transfer between devices which implement the same upper protocol without any influence because, if bus reset occurs, the data transmitting and receiving sides execute the defined appropriate processes in data transfer.

[0015] However, if bus reset occurs on one local bus connected to another IEEE 1394 bus, the IEEE 1394 bridge does not transfer the bus reset signal to the other local bus (to be referred to as a “remote bus” hereinafter), i.e., does not propagate bus reset between the busses. Therefore, an error may occur in data transfer between nodes via the bridge.

[0016] When data is transferred between devices on the same local bus using the above-mentioned upper protocols, bus reset is transmitted to all the nodes on the local bus. Accordingly, both the data transmission and reception nodes can detect bus reset, and can appropriately execute bus reset procedures by the upper protocols.

[0017] However, if bus reset occurs on one local bus during data transfer from a data transmission node on the local bus to a data reception node connected to the other local bus via an IEEE 1394 bridge, the IEEE 1394 bridge does not propagate bus reset to the other bus. Therefore, the node connected to the remote bus cannot detect the bus reset, only the device connected to the local bus executes a bus reset procedure by the upper protocol layer, and the processes between the data transmitting and receiving sides are inconsistent.

[0018] It is an object of the present invention to provide a communication network system capable of performing normal data communication between communication control networks while maintaining the consistency of network configuration update request processing in an upper protocol layer in a system constituted by connecting a plurality of communication control networks (e.g., IEEE 1394 buses) via a connection device (e.g., IEEE 1394 bridge).

[0019] It is another object of the present invention to provide a communication network system capable of performing normal data communication between buses while maintaining the consistency of bus reset processing in an upper protocol layer in a system constituted by connecting a plurality of communication control networks (e.g., IEEE 1394 buses) via a connection device (e.g., IEEE 1394 bridge).

[0020] Other features and advantages of the present invention will be apparent from the following description taken in conjunction with the accompanying drawings, in which like reference characters designate the same or similar parts throughout the figures thereof.

[0062] Preferred embodiments of present invention will be described in detail below with reference to the accompanying drawings.

[First Embodiment]

[0063] FIG. 1 is a block diagram showing the schematic configuration of the first embodiment according to the present invention. The first embodiment is constituted by two IEEE 1394-compliant local buses A 102 and B 103, and a 1394 bridge 101 for connecting them. FIG. 1 shows two local buses, but a larger number of local buses can be connected via 1394 bridge devices.

[0064] Each local bus has a bus ID as bus specifying information for specifying each local bus. The local bus A 102 represented by a bus ID “3FDh” and the local bus B 103 represented by a bus ID “3FEh” are connected to a plurality of device nodes.

[0065] In the first embodiment shown in FIG. 1, a node A1 (104) connected to the local bus A 102 is a digital still camera, and a node A2 (105) is a digital video cam coder. A node B1 (106) connected to the local bus B 103 is a printer, and a node B2 (107) is a digital video cam coder.

[0066] The node A1 (104) implements a direct print protocol standardized in advance as an upper protocol, whereas the node A2 (105) implements a standardized AV/C protocol.

[0067] Similarly, the node B1 (106) connected to the local bus B 103 implements a direct print protocol as an upper protocol, whereas the node B2 (107) implements an AV/C protocol.

[0068] <Technical Overview of IEEE 1394 Standard>

[0069] The technique of the IEEE 1394-1995 standard applied to the digital interface shown in FIG. 1 of the first embodiment will be explained. Details of the IEEE 1394-1995 standard (to be referred to as the “IEEE 1394 standard” hereinafter) are described in “IEEE Standard for a High Performance Serial Bus” published by IEEE (The Instituted of Electrical and Electronics Engineers, Inc.), Aug. 30, 1996.

[0070] (1) Overview

[0071] FIG. 2 shows an example of a communication system (to be referred to as a “1394 network”) constituted by nodes having digital interfaces complying with the IEEE 1394 standard (to be referred to as “1394 interfaces”). The 1394 network constitutes a bus type network capable of communicating serial data.

[0072] In FIG. 2, nodes A to H are connected via an IEEE 1394 standard-compliant communication cable. These nodes A to H are electronic devices such as a PC (Personal Computer), digital VTR (Video Tape Recorder), DVD (Digital Video Disc) player, digital camera, hard disk drive, and monitor.

[0073] The connection method of the 1394 network may include both a daisy chain method and node branch method, and enables connection with a high degree of flexibility.

[0074] The 1394 network automatically performs bus reset when, e.g., an existing device is removed, a new device is added, or an existing device is turned on/off. By performing this bus reset, the 1394 network can automatically recognize a new configuration and assign ID information to each device. This function allows the 1394 network to always recognize the network configuration.

[0075] The 1394 network also has a function of relaying data transferred from another device. This function allows all the devices to grasp the operation status of the bus.

[0076] The 1394 network has a function called plug & play. This function allows the 1394 network to automatically recognize connected devices by only connecting them without turning off all the devices.

[0077] The 1394 network copes with data transfer speeds of 100/200/400 Mbps. A device having a higher data transfer speed can support a lower data transfer speed, so that devices having different data transfer speeds can be connected.

[0078] The 1394 network further copes with two different data transfer schemes (i.e., asynchronous and isochronous transfer modes).

[0079] The asynchronous transfer mode is effective in transferring data (i.e., a control signal and file data) which should be asynchronously transferred if necessary. The isochronous transfer mode is effective in transferring data (i.e., video data and audio data) which should be successively transferred by a predetermined amount at a constant data transfer speed.

[0080] The asynchronous and isochronous transfer modes can be mixed in each communication cycle (one cycle is generally 125 μS). Each transfer mode is executed after transfer of a cycle start packet (to be referred to as a “CSP”) representing the start of the cycle.

[0081] In each communication cycle period, the isochronous transfer mode has higher priority than that of the asynchronous transfer mode. The transfer band of the isochronous transfer mode is ensured in each communication cycle.

[0082] (2) Architecture

[0083] The architecture of the IEEE 1394 standard will be described with reference to FIG. 3. FIG. 3 is a block diagram showing the architecture of the IEEE 1394 standard in the first embodiment.

[0084] The building elements of the IEEE 1394 interface will be explained. The IEEE 1394 interface is functionally made up of a plurality of layers (hierarchies). In FIG. 3, the IEEE 1394 interface is connected to the IEEE 1394 interface of another node via an IEEE 1394 standard-compliant communication cable 301. The IEEE 1394 interface has one or more communication ports 302, and each communication port 302 is connected to a physical layer 303 included in hardware.

[0085] In FIG. 3, the hardware is comprised of the physical layer 303 and a link layer 304. The physical layer 303 performs a physical and electrical interface with another node, detection of bus reset and its processing, encoding/decoding of input and output signals, and arbitration of bus access. The link layer 304 performs generation and transmission/reception of a communication packet, and control of the cycle timer.

[0086] In FIG. 3, the firmware includes a transaction layer 305 and serial bus management 306. The transaction layer 305 manages the asynchronous transfer mode, and provides various transactions (read, write, and lock). The serial bus management 306 provides a function of controlling the self node, managing the connection state of the self node, managing the ID information of the self node, and managing the resource of the serial bus network on the basis of a CSR architecture (to be described later).

[0087] The hardware 303 and 304 and the firmware 305 and 306 substantially constitute a 1394 interface. The basic configuration is defined by the IEEE 1394 standard.

[0088] An application layer 307 included in the software changes depending on application software to be used, and controls how to communicate data on the network. For example, for moving picture data of a digital VTR, the application layer 307 is defined by a communication protocol such as an AV/C protocol.

[0089] (2-1) Function of Link Layer 304

[0090] FIG. 4 is a view showing services which can be provided by the link layer 304. In FIG. 4, the link layer 304 provides the following four services:

• [0091] {circle around (1)} Link request (LK_—DATA.request) for requesting transfer of a predetermined packet of a response node
• [0092] {circle around (2)} Link indication (LK_—DATA.indication) for indicating reception of a predetermined packet to a response node
• [0093] {circle around (3)} Link response (LK_—DATA.response) representing reception of an acknowledge from a response node
• [0094] {circle around (4)} Link confirmation (LK_—DATA.confirmation) for confirming an acknowledge from a request node
  Note that the link response (LK_—DATA.response) does not exist in broadcast communication and the transfer of an isochronous packet.

[0095] Based on these services, the link layer 304 realizes the two transfer schemes, i.e., asynchronous and isochronous transfer modes.

[0096] (2-2) Function of Transaction Layer 305

[0097] FIG. 5 is a view showing services which can be provided by the transaction layer 305. In FIG. 5, the transaction layer 305 provides the following four services:

• [0098] {circle around (1)} Transaction request (TR_—DATA.request) for requesting a predetermined transaction of a response node
• [0099] {circle around (2)} Transaction indication (TR_—DATA.indication) for indicating reception of a predetermined transaction request to a response node
• [0100] {circle around (3)} Transaction response (TR_—DATA.response) representing reception of state information (including data for write and lock) from a response node
• [0101] {circle around (4)} Transaction confirmation (TR_—DATA.confirmation) for confirming state information from a request node

[0102] Based on these services, the transaction layer 305 manages asynchronous transfer, and realizes the following three transactions:

• [0103] {circle around (1)} Read transaction
• [0104] {circle around (2)} Write transaction
• [0105] {circle around (3)} Lock transaction

[0106] In {circle around (1)} read transaction, a request node reads information stored at a specific address of a response node.

[0107] In {circle around (2)} write transaction, the request node writes predetermined information at a specific address of the response node.

[0108] In {circle around (3)} lock transaction, the request node transfers reference data and update data to the response node, compares information at a specific address of the response node with the reference data, and updates the information at the specific address to the update data in accordance with the comparison result.

[0109] (2-3) Function of Serial Bus Management 306

[0110] The serial bus management 306 can provide the following three functions, i.e., {circle around (1)} node control, {circle around (2)} isochronous resource manager (to be referred to as an “IRM”), and {circle around (3)} bus manager.

[0111] {circle around (1)} Node control provides a function of managing the above-described layers, and managing asynchronous transfer executed with another node.

[0112] {circle around (2)} The IRM provides a function of managing isochronous transfer executed with another node. More specifically, the IRM manages pieces of information necessary to assign a transfer bandwidth and a channel number, and provides these pieces of information to another node.

[0113] The IRM exists only on a local bus, and is dynamically selected from other candidates (nodes having the IRM function) every bus reset. The IRM may provide some of functions (connection configuration management, power supply management, speed information management, and the like) which can be provided by the bus manager (to be described below).

[0114] {circle around (3)} The bus manager has the IRM function, and provides a more advanced bus management function than the IRM.

[0115] More specifically, the bus manager has a function of performing more advanced power supply management (manage, for each node, information representing whether power can be supplied via a communication cable and whether power must be supplied), more advanced speed information management (manage the maximum transfer speed between nodes), more advanced connection configuration management (create a topology map), and bus optimization based on these pieces of management information, and providing the pieces of information to another node.

[0116] The bus manager can provide an application with a service for controlling a serial bus network. This service includes a serial bus control request (SB_—CONTROL.request), serial bus event control confirmation (SB_—CONTROL.confirmation), and serial bus event indication (SB_—CONTROL.indication).

[0117] The serial bus control request (SB_—CONTROL.request) is a service of requesting bus reset by an application.

[0118] The serial bus event control confirmation (SB_—CONTROL.confirmation) is a service of confirming the serial bus control request (SB_—CONTROL.request) for the application. The serial bus event indication (SB_—CONTROL.indication) is a service of indicating an asynchronously generated event to the application.

[0119] (3) Description of Addressing

[0120] FIG. 6 is a view for explaining an address space in the 1394 interface. The 1394 interface defines a 64-bit address space in accordance with a CSR (Command and Status Register) architecture complying with ISO/IEC 13213:1994.

[0121] In FIG. 6, a 10-bit field 601 is used for an ID number for designating a predetermined bus, and a 6-bit field 602 is used for an ID number for designating a predetermined device (node). The upper 16 bits will be called a “node ID”, and each node identifies another node using this node ID. Each node can also perform communication with an identified partner using this node ID.

[0122] The remaining 48-bit field designates an address space (256-Mbyte structure) of each node. Of this field, a 20-bit field 603 designates a plurality of areas constituting an address space.

[0123] In the field 603, an area “0-0xFFFFD” is called a memory space.

[0124] An area “0xFFFFE” is called a private space, and represents addresses freely usable by each node. The area “0xFFFFE” is called a register space, and stores information common to nodes connected to a bus. Each node can use information of the register space to manage communication between nodes.

[0125] A 28-bit field 604 designates an address where information common or unique to each node is stored.

[0126] For example, the first 512 bytes in the register space are used for a CSR architecture core (CSR core) register. FIG. 7 shows the address and function of information stored in the CSR core register. The offset in FIG. 7 is a relative position from “0xFFFFF0000000”.

[0127] The next 512 bytes in FIG. 6 are used for a serial bus register. FIG. 8 shows the address and function of information stored in the serial bus register. The offset in FIG. 8 is a relative position from “0xFFFFF0000200”.

[0128] The next 1,024 bytes in FIG. 6 are used for a configuration ROM. The configuration ROM has minimum and general formats, and is arranged from “0xFFFFF0000400”. FIG. 9 shows a configuration ROM of the minimum format. In FIG. 9, a vender ID is a 24-bit numerical value uniquely assigned to each vendor by IEEE.

[0129] FIG. 10 shows a configuration ROM of the general format. In FIG. 10, the vendor ID is stored in a root directory 1002. A bus inform block 1001 and root leaf 1005 can hold node unique IDs as unique ID information for identifying each node.

[0130] The node unique ID determines a unique ID capable of specifying one node regardless of the manufacturer and model. The node unique ID is made up of 64 bits. The upper 24 bits represent a vendor ID, and the lower 48 bits represent information (e.g., the manufacturing number of a node) freely settable by the manufacturer of each node. The node unique ID is used when, for example, a specific node is kept recognized before and after bus reset.

[0131] In FIG. 10 showing the configuration ROM of the general format, the root directory 1002 can hold information about the basic function of a node. Detailed functional information is stored in subdirectories (unit directories 1004) offset from the root directory 1002. The unit directories 1004 store, e.g., information about software units supported by a node. More specifically, the unit directories 1004 hold information about a data transfer protocol for data communication between nodes, and a command set for defining predetermined communication procedures.

[0132] In FIG. 10, a node dependent info directory 1003 can hold information unique to a device. The node dependent info directory 1003 is offset from the root directory 1002.

[0133] In FIG. 10, vendor dependent information 1006 can hold information unique to a vendor which manufactures or sells nodes.

[0134] The remaining area is called a unit space, and designates an address where information unique to each node, e.g., identification information (manufacturer name, model name, or the like) or use conditions of each device are stored. FIG. 11 shows the address and function of information stored in the serial bus register of the unit space. The offset in FIG. 11 is a relative position from “0xFFFFF0000800”.

[0135] In general, to simplify the design of different types of bus systems, each node should use only the first 2,048 bytes of the register space. In other words, the bus system is desirably constituted by 4,096 bytes as a total of the CSR core register, the serial bus register, the configuration ROM, and the first 2,048 bytes of the unit space.

[0136] (4) Structure of Communication Cable

[0137] FIG. 12 is a sectional view showing an IEEE 1394-compliant communication cable.

[0138] The communication cable is made up of two twisted-pair signal lines and a power supply line. This power supply line can supply power even to a device whose main power supply is turned off, or a device which decreases in power due to a failure. The power supply voltage flowing through the power supply line is defined as 8 to 40 V, and the current is defined as a maximum of DC 1.5 A.

[0139] The two twisted-pair signal lines transmit information signals encoded by a DS-link (Data/Strobe link) coding scheme. FIG. 13 is a view for explaining the DS-link coding scheme in the first embodiment.

[0140] The DS-link coding scheme shown in FIG. 13 is suitable for high-speed serial data communication, and requires two twisted-pair lines. One twisted-pair line transmits a data signal, whereas the other twisted-pair line transmits a strobe signal. The receiving side can regenerate a clock by exclusive-ORing the data and strobe signals received from the two signal lines.

[0141] The 1394 interface using the DS-link coding scheme attains the following advantages:

• [0142] {circle around (1)} The transfer efficiency is higher than other coding schemes.
• [0143] {circle around (2)} The PLL circuit can be omitted to downsize the controller LSI.
• [0144] {circle around (3)} Information representing an idle state need not be transmitted, so that the transceiver circuit can easily change to a sleep state to reduce the power consumption.

[0145] (5) Bus Reset Function

[0146] The 1394 interface of each node can automatically detect a change in network connection configuration. In this case, the 1394 network executes processing called bus reset by the following procedures. A change in connection configuration can be detected by a change in bias voltage applied to the communication port of each node.

[0147] A node which has detected a change in network connection configuration (e.g., an increase/decrease in the number of nodes upon insertion/removal of a node or ON/OFF operation of a node), or a node which must recognize a new connection configuration transmits a bus reset signal onto the bus via the 1394 interface.

[0148] The 1394 interface of a node which has received the bus reset signal transmits occurrence of bus reset to its link layer 304, and transfers the bus reset signal to another node. A node which has received the bus reset signal clears the recognized network connection configuration and the node ID assigned to each device. After all the nodes detect the bus reset signal, each node automatically performs initialization processing (recognition of a new connection configuration and assignment of a new node ID) accompanying bus reset.

[0149] Note that bus reset can be activated not only by a change in connection configuration described above, but also by directly issuing an instruction from the application layer 307 to the physical layer 303 under host control.

[0150] After bus reset occurs, data transfer is temporarily suspended, and then restarted in a new network after completion of initialization processing accompanying bus reset.

[0151] (6) Description of Sequence After Occurrence of Bus Reset

[0152] After bus reset occurs, the 1394 interface of each node automatically executes recognition of a new connection configuration and assignment of a new node ID. A basic sequence from the start of bus reset to assignment processing of a node ID will be explained with reference to FIGS. 14 to 16.

[0153] FIG. 14 is a view for explaining a state after occurrence of bus reset in the 1394 network of FIG. 2.

[0154] In FIG. 14, node A comprises one communication port; node B, two communication ports; node C, two communication ports; node D, three communication ports; node E, one communication port; and node F, one communication port. The communication port of each node has a port number for identifying each port.

[0155] Processing from the start of bus reset to assignment of a node ID in FIG. 14 will be explained with reference to the flow chart of FIG. 15. FIG. 15 is a flow chart showing processing from the start of bus reset to assignment of a node ID in the first embodiment.

[0156] Nodes A to F shown in FIG. 14 that constitute a 1394 network always monitor whether bus reset occurs, as shown in step S1501. If a node which has detected a change in connection configuration outputs a bus reset signal, each node detects bus reset to execute processing from step S1502.

[0157] If bus reset is detected, the flow advances from step S1501 to step S1502, and respective nodes declare parent-child relationships between their communication ports after occurrence of bus reset. In step S1503, whether parent-child relationships between all the nodes are determined is checked. If NO in step S1503, the flow returns to step S1502, and each node repeats processing in step S1502 until parent-child relationships between all the nodes are determined.

[0158] After parent-child relationships between all the nodes are determined, the flow shifts from step S1503 to step S1504. In step S1504, the 1394 network determines a node, i.e., root which performs network arbitration. After the root is determined, the flow shifts to step S1505, and the 1394 interface of each node executes an operation of automatically setting the self node ID. In step S1506, whether node IDs have been set for all the nodes to complete ID setting processing is checked. If NO in step S1506, the flow returns to step S1505, and each node sets an ID for the next node based on predetermined procedures.

[0159] After node IDs are set for all the nodes, the flow advances from step S1506 to step S1507, and each node executes isochronous transfer or asynchronous transfer. After data transfer ends, the 1394 interface of each node returns to step S1501 to monitor bus reset.

[0160] By the above procedures, the 1394 interface of each node can automatically execute recognition of a new connection configuration and assignment of a new node ID every time bus reset occurs.

[0161] (7) Determination of Parent-child Relationship

[0162] Details of parent-child relationship declaration processing (i.e., processing of recognizing parent-child relationships between nodes) in step S1502 shown in FIG. 15 will be described with reference to the flow chart of FIG. 16. FIG. 16 is a flow chart showing details of parent-child relationship declaration processing in step S1502 shown in FIG. 15 in the first embodiment.

[0163] In parent-child relationship declaration processing of the first embodiment, nodes A to F on the 1394 network confirm the connection states (connection or disconnection) of the self communication ports upon occurrence of bus reset in step S1601 shown in FIG. 16. After confirming the connection state of the communication port, each node counts in step S1602 the number of communication ports (to be referred to as connected ports) connected to other nodes, and checks whether the number of connected ports is one.

[0164] If the number of connected ports is one in step S1602, the flow shifts to step S1603, and the node recognizes itself as a “leaf”. The “leaf” means a node connected to only one node. In step S1604, the node serving as a leaf declares a “child” to a node connected to the connected port. At this time, the leaf recognizes that the connected port is a “parent port (communication port connected to a parent node)”. After that, the flow advances to step S1611.

[0165] Parent-child relationships are sequentially declared between a branch and a leaf serving as a network terminal end, and then between branches. The parent-child relationships between nodes are determined in the order of a communication port which can make a declaration early. A communication port which declares a child is recognized as a “parent port” between nodes, and a communication port which has received the declaration is recognized as a “child port (communication port connected to a child node)”. For example, in FIG. 14, nodes A, E, and F recognize themselves as leaves, and declare child-parent relationships. Then, nodes A and B are determined to be a child and parent; nodes E and D, a child and parent; and nodes F and D, a child and parent.

[0166] If the number of connected ports is not one but two or more as a result of processing in step S1602, the flow shifts to step S1605, and the node recognizes itself as a “branch”. The “branch” means a node connected to two or more nodes. In step S1606, the node serving as a branch receives declaration of a parent-child relationship from a node at each connected port. The connected port which has received the declaration is recognized as a “child port”.

[0167] After one connected port is recognized as a “child port”, the flow advances to step S1607, and the branch detects whether there are two or more connected ports (i.e., undefined ports) for which parent-child relationships have not been determined yet. If YES in step S1607, the flow returns to processing in step S1606, and the branch receives declaration of a parent-child relationship from a node at each connected port again.

[0168] If NO in step S1607, the flow shifts to step S1608, and the branch checks whether only one undefined port exists. If YES in step S1608, the branch recognizes the undefined port as a “parent port”, and declares a “child” to a node connected to the port in step S1609. Then, the flow advances to step S1611.

[0169] The branch cannot declare a child to another node until the number of remaining undefined ports decreases to one. For example, in the configuration of FIG. 14, nodes B, C, and D recognize themselves as branches, and receive declarations from leaves or other branches. Node D declares a parent-child relationship to node C after parent-child relationships between D and E and between D and F are determined. Node C which has received the declaration from node D declares a parent-child relationship to node B.

[0170] If NO in step S1608 (i.e., all the connected ports of the branch are parent ports), the flow shifts to step S1610, and the branch recognizes itself as a root. For example, in FIG. 14, node B in which all the connected ports are parent ports is recognized by other nodes to be a root for arbitrating communication on the 1394 network.

[0171] In this case, node B is determined to be a root. If the timing at which node B declares a parent-child relationship is earlier than the timing at which node C declares a parent-child relationship, another node may become a root. Hence, even the same network configuration does not always use the same node as a root.

[0172] After the parent-child relationships of all the connected ports are declared, each node can recognize the connection configuration of the 1394 network as a hierarchical structure (tree structure). The declarations at all the connected ports end in step S1611, and the flow returns to the main routine. Note that the parent node is an upper node in the hierarchical structure, and the child node is a lower node in the hierarchical structure.

[0173] (8) Assignment of Node ID

[0174] Node ID setting processing (i.e., processing of automatically assigning the node ID of each node) in step S1505 shown in FIG. 15 will be described in detail with reference to FIG. 17. FIG. 17 is a flow chart showing details of node ID setting processing in step S1505 of FIG. 15. The node ID is made up of a bus number and node number. In the first embodiment, respective nodes are connected to the same bus, and have the same bus number.

[0175] In node ID setting processing of the first embodiment, the root gives node ID setting permission to a communication port having the smallest number among child ports connected to nodes whose node IDs have not been set yet. In FIG. 17, the root sets the node IDs of all the nodes connected to a child port having the smallest number, determines that the child port has been set, and performs the same control for a child port having the second smallest number. After the IDs of all the nodes connected to child ports are set, the root sets the self node ID. Node numbers contained in node IDs are basically sequentially assigned as 0, 1, 2, . . . to leaves and branches. Thus, the root has the largest node number.

[0176] A node which has received the setting permission in step S1701 checks in step S1702 whether a child port including a node whose node ID has not been set yet exists in the self child ports. If NO in step S1702, the flow shifts to step S1705.

[0177] If YES in step S1702, the flow advances to step S1703, and the node which has received setting permission gives setting permission to a node directly connected to the child port (child port having the smallest number). In step S1704, the node which has received setting permission checks whether a child port including a node whose node ID has not been set yet exists in the self child ports. If YES in step S1704, the flow returns to step S1703, and the node gives setting permission to a child port having the smallest number.

[0178] If NO in step S1704, the flow shifts to step S1705.

[0179] In this way, if a child port including an unset node is not detected in step S1702 or S1704, the flow shifts to step S1705, and the node which has received setting permission sets the self node ID. In step S1706, the node which has set the self node ID broadcasts a self ID packet containing information about its node number and the connection state of the communication port. “Broadcast” means to transfer a communication packet of a given node to many unspecified nodes constituting a 1394 network.

[0180] Each node can receive this self ID packet to recognize a node number assigned to each node, and can recognize the assigned node number. For example, in FIG. 14, node B serving as a root gives node ID setting permission to node A connected to a communication port having the smallest port number “#1”. Node A assigns “No. 0” as its node number, and sets a node ID made up of a bus number and the node number. Then, node A broadcasts a self ID packet containing the node number.

[0181] FIG. 18 shows a format of a self ID packet output in step S1706. In FIG. 18, reference numeral 1801 denotes a field for storing the node number of a node which has sent a self ID packet; 1802, a field for storing information about a compatible transfer speed; 1803, a field representing the presence/absence of a bus management function (the presence/absence of a bus manager ability); and 1804, a field for storing information about power consumption and supply characteristics.

[0182] In FIG. 18, reference numeral 1805 denotes a field for storing information about the connection state of a communication port having a port number “#0” (connection, disconnection, parent-child relationship of a communication port, and the like); 1806, a field for storing information about the connection state of a communication port having a port number “#1” (connection, disconnection, parent-child relationship of a communication port, and the like); and 1807, a field for storing information about the connection state of a communication port having a port number “#2” (connection, disconnection, parent-child relationship of a communication port, and the like).

[0183] When a node which sends a self ID packet has a bus manager ability, a contender bit in the field 1803 is set to “1”; otherwise, to “0”.

[0184] The bus manager is a node having a function of performing, based on various pieces of information contained in the above-mentioned self ID packet, bus power supply management (manage, for each node, information representing whether power can be supplied via a communication cable and whether power must be supplied), speed information management (manage the maximum transfer speed between nodes from information about a compatible transfer speed of each node), topology map information management (manage the network connection configuration from parent-child relationship information of a communication port), and bus optimization based on topology map information, and a function of providing these pieces of information to other nodes. These functions allow the node serving as a bus manager to manage the bus over the 1394 network.

[0185] In processing of FIG. 17, a node which has set a node ID after processing in step S1706 checks in step S1707 whether a parent node exists. If YES in step S1707, the flow returns to step S1702, and the parent node executes processing from step S1702, and gives permission to a node whose node ID has not been set yet.

[0186] If NO in step S1707, the node is determined to be a root. The flow shifts to step S1708, and the node serving as a root checks whether node IDs are set for nodes connected to all the child ports. If ID setting processing for all the nodes is not completed in step S1708 (NO), the flow returns to step S1701, and the root gives ID setting permission to a child port having the smallest number among child ports including the node. Then, processing after step S1702 is executed.

[0187] If YES in step S1708, the flow shifts to step S1709, and the root sets the self node ID. After setting the node ID, the root broadcasts a self ID packet in step S1710. Then, the flow returns to the main routine.

[0188] By this processing, the 1394 network can automatically assign a node ID to each node.

[0189] If a plurality of nodes have a bus manager ability after node ID setting processing, a node having the largest node number serves as a bus manager. That is, when a root having the largest node number in the network has a bus manager function, the root serves as a bus manager.

[0190] If, however, the root does not have this function, a node having the largest node number next to the root serves as a bus manager. Which node becomes a bus manager can be grasped by checking the contender bit 1803 in a self ID packet broadcasted by each node.

[0191] (9) Arbitration Function

[0192] FIGS. 19A and 19B are views for explaining arbitration in the 1394 network in the first embodiment shown in FIG. 1.

[0193] The 1394 network always performs bus access arbitration prior to data transfer. The 1394 network is a logical bus type network, and can transfer the same communication packet to all the nodes in the network by relaying a communication packet transferred from each node to another node. To prevent collision of communication packets, arbitration must be executed, which allows only one node to transfer a packet at given time.

[0194] FIG. 19A is a view for explaining a case wherein nodes B and F issue bus access requests.

[0195] When arbitration starts, nodes B and F issue bus access requests to their parents. A parent (i.e., node C) which has received the request from node B relays the bus access request to its parent node (i.e., node D). This request is finally sent to a root (node D) which finally executes arbitration.

[0196] The root which has received the bus access requests determines which node can use the bus. This arbitration operation can be done by only a node serving as a root, and a node which wins arbitration is permitted to use the bus.

[0197] FIG. 19B is a view showing a case wherein a request from node F is permitted, and a request from node B is denied.

[0198] The root transmits a DP (Data Prefix) packet to a node which loses in arbitration, and notifies the node of denial. The denied node holds a bus access request until the next arbitration.

[0199] By controlling arbitration, the 1394 network can manage bus access.

[0200] (10) Communication Cycle

[0201] In the first embodiment, the asynchronous and isochronous transfer modes can be mixed in time division in each communication cycle period. In general, the communication cycle period is 125 μS long.

[0202] FIG. 20 is a view for explaining a case wherein the asynchronous and isochronous transfer modes are mixed in one communication cycle.

[0203] In the first embodiment, the isochronous transfer mode is executed preferentially to the asynchronous transfer mode. This is because an idle period (subaction gap) necessary for activating asynchronous transfer after a cycle start packet is set longer than an idle period (isochronous gap) necessary for activating isochronous transfer. Thus, isochronous transfer is executed preferentially to asynchronous transfer.

[0204] In FIG. 20, a cycle start packet (to be referred to as a “CSP” hereinafter) is transferred from a predetermined node at the start of each communication cycle. Each node can count the same time as another node by adjusting the time using the CSP.

[0205] (11) Isochronous Transfer Mode

[0206] The isochronous transfer mode is an isochronous type transfer scheme. Isochronous mode transfer can be executed in a predetermined period after the start of a communication cycle. The isochronous transfer mode is always executed every cycle in order to maintain real-time transfer.

[0207] The isochronous transfer mode is a transfer mode suitable for transfer of data such as moving picture data or audio data which requires real-time transfer. The isochronous transfer mode is broadcasting communication, unlike one-to-one communication in the asynchronous transfer mode. That is, a packet sent from a given node is transferred to all the nodes on the network. Note that isochronous transfer does not use any ack (acknowledge).

[0208] In FIG. 20, channel e (ch e), channel s (ch s), and channel k (ch k) represent periods during which nodes perform isochronous transfer. The 1394 interface uses different channel numbers in order to discriminate a plurality of different isochronous transfer operations. This enables isochronous transfer between a plurality of nodes. In this case, the channel number does not specify a transmission destination, but only gives a logical number to data.

[0209] The isochronous gap shown in FIG. 20 represents a bus idle state. Upon the lapse of a predetermined time in this idle state, a node which desires isochronous transfer determines that it can use the bus, and executes arbitration.

[0210] FIG. 21 shows the format of a communication packet transferred based on the isochronous transfer mode in the first embodiment. The communication packet transferred based on the isochronous transfer mode will be called an isochronous packet.

[0211] In FIG. 21, the isochronous packet is made up of a header 2101, header CRC 2102, data 2103, and data CRC 2104.

[0212] The header 2101 includes a field 2105 for storing the data length of the data 2103, a field 2106 for storing format information of the isochronous packet, a field 2107 for storing the channel number of the isochronous packet, a field 2108 for storing a packet format and a transaction code (tcode) for identifying processing which must be executed, and a field 2109 for storing an isochronous code.

[0213] (12) Asynchronous Transfer Mode

[0214] The asynchronous transfer mode of the first embodiment is an asynchronous type transfer scheme. Asynchronous transfer is one-to-one communication from a self node to a partner node, and can be executed until the next communication cycle starts (i.e., the CSP of the next communication cycle is transferred) after the end of an isochronous transfer period.

[0215] In FIG. 20, the first subaction gap represents a bus idle state. After the idle time reaches a predetermined value, a node which desires asynchronous transfer determines that it can use the bus, and executes arbitration.

[0216] The node which gains bus access by arbitration transfers a packet shown in FIG. 22 to a predetermined node. The node which has received this packet returns ack (acknowledge) or response packet subsequently to ack gap.

[0217] FIG. 22 is a view showing the format of a communication packet based on the asynchronous transfer mode in the first embodiment. The communication packet transferred based on the asynchronous transfer mode will be called an asynchronous packet.

[0218] In FIG. 22, the asynchronous packet is made up of a header 2201, header CRC 2202, data 2203, and data CRC 2204.

[0219] In the header 2201, a field 2205 stores the node ID of a destination node; a field 2206, the node ID of a source node; a field 2207, a label representing a series of transactions; a field 2208, a code representing a retransmission status; a field 2209, a packet format and a transaction code (tcode) for identifying processing which must be executed; a field 2210, priority; a field 2211, the memory address of a destination; a field 2212, the length of data; and a field 2213, an extended transaction code.

[0220] A packet transferred from a transferring node in asynchronous transfer is transmitted to all the nodes in the network, but the nodes ignore packets except for ones designated to the self addresses. Thus, only a destination node can read the packet.

[0221] When asynchronous transfer reaches time at which the next CSP should be transferred, the next CSP is transmitted after the end of transfer without forcibly stopping transfer. If one communication cycle continues for 125 μS or more, the next communication cycle is shortened. This enables the 1394 network to hold an almost constant communication cycle.

[0222] (13) Creation of Device Map

[0223] As a means for obtaining the topology of the 1394 network by an application in order to create a device map, the IEEE 1394 standard provides the following means:

[0224] 1) The topology map register of the bus manager is read.

[0225] 2) The topology map is estimated from a self ID packet in bus reset.

[0226] By the means 1) and 2), the topology of a cable connection order based on the parent-child relationships between nodes can be attained, but the topology of a physical positional relationship cannot be attained (a port which is not actually mounted is listed).

[0227] As another means, information for creating a device map is held in the database of a device other than a configuration ROM. In this case, the means for obtaining various pieces of information depends on protocols for database access. On the other hand, the configuration ROM itself and the function of reading it are necessarily attached to an IEEE 1394-compliant device.

[0228] Thus, the first embodiment employs a function of storing information about the device position, function, and the like in the configuration ROM of each node and reading information by an application. Accordingly, the application of each node can have a so-called device map display function regardless of specific protocols for database access, data transfer, and the like.

[0229] The configuration ROM can store a physical position, function, and the like as node dependent information. Such information can be used to realize the device map display function.

[0230] In this case, in order for an application to obtain the 1394 network topology based on the physical positional relationship, the configuration ROM of each node is read-accessed in accordance with bus reset or a user's request, thereby obtaining the 1394 network topology. Further, various pieces of node information such as functions in addition to the physical position of a node can be described in the configuration ROM. By read-accessing the configuration ROM, function information of each node can be attained at the same time as the physical position of the node. When an application is to acquire configuration ROM information of each node, the application uses an API for acquiring arbitrary configuration ROM information of a designated node.

[0231] With the use of this means, the application of a device on the IEEE 1394 network can create various device maps such as a physical topology map and the function map of each node in accordance with application purposes. The user can select a device having a necessary function.

[0232] <Overview of 1394 Bridge>

[0233] The configuration and connection device in the first embodiment will be described.

[0234] The technique of an IEEE 1394 bridge applied to the digital interface of the first embodiment will briefly be described. The standard of the IEEE 1394 bridge (to be referred to as a “1394 bridge” hereinafter) is being defined by the IEEE p1394.1.

[0235] According to the 1394 standard, a maximum of 63 nodes can be connected to one 1394 bus, and the hop count is up to 16. To connect more than 63 1394 nodes to a 1394 network, or connect devices at remote places by connecting more than 16 hops, a 1394 bridge is generally used.

[0236] The IEEE 1394 standard uses 64-bit fixed addressing according to the IEEE 1212 standard, and defines 10 bits as a bus ID. Thus, a maximum of 1,023 buses except for ID 1023 for designating a local bus can be connected via 1394 bridges to constitute a 1394 network.

[0237] The main function of the 1394 bridge is control of 1394 node transaction between buses via the bridge. In 1394 transaction, a node which issues a transaction, i.e., issuing node is designated using a node ID as described in <Technical Overview of IEEE 1394 Standard>. The 1394 bridge has a table of information such as topology information of two connected buses and node ID information, and discloses partner's bus/node information to two connected buses to enable transactions between the buses.

[0238] On the 1394 bus, bus reset occurs when the connection configuration changes by additionally connecting a device node or when a certain node intentionally instructs bus reset. To automatically reassign a node ID upon occurrence of bus reset, the bus reset sequence and node ID determination sequence are done to create a new topology. Details of these sequences are described in “(6) Description of Sequence After Occurrence of Bus Reset” and “(8) Assignment of Node ID” of <Technical Overview of IEEE 1394 Standard>, and a description thereof will be omitted.

[0239] Because of these characteristics, topology/node ID information of a connected bus dynamically changes, and the bridge updates this information.

[0240] During the 1394 bus reset sequence, data transfer on the bus is suspended, and a complicated node ID reassignment sequence is executed. It is, therefore, inefficient to propagate a bus reset signal to a bus which need not execute any bus reset sequence. For this reason, the 1394 bridge does not propagate the bus reset signal of one connected bus to the other bus.

[0241] As another bridge function, the 1394 bridge has a packet routing function based on arbitration between 1394 bridges and exchange of information between bridges in a network constituted by a plurality of buses in which a plurality of bus bridges are connected.

[0242] The configuration and functions of the communication system constructed using the 1394 interface have been described.

[0243] [Description of Configuration and Connection Device in First Embodiment]

[0244] The configuration and connection device in the first embodiment will be described. The configuration of a 1394 serial bus interface common to respective nodes connected to each local bus will be explained with reference to FIG. 23. FIG. 23 is a block diagram showing the arrangement of the 1394 interface block of a 1394 node in the first embodiment.

[0245] In FIG. 23, reference numeral 2701 denotes a link layer control IC (LINK IC) which interfaces a device main body, controls data transfer of a PHY IC, and realizes the function of the link layer in <Technical Overview of IEEE 1394 Standard>. The main function of this IC includes a transmission/reception FIFO function of temporarily storing transmission/reception data via the PHY IC, a function of packeting transmission data, a function of determining whether the PHY IC is suitable for an assigned channel when reception data has the self node address or is isochronous transfer data, a receiver function of performing error check for the data, and a function of interfacing the device main body.

[0246] Reference numeral 2702 denotes a physical layer control IC (PHY IC) for directly driving the 1394 serial bus. The physical layer control IC 2702 realizes the function of the physical layer in <Technical Overview of IEEE 1394 Standard>. The main function of this IC includes bus initialization, arbitration, encoding/decoding of a transmission data code, monitoring of a cable ON state, supply of a load termination type power source (for recognizing active connection), and an interface with a link layer IC.

[0247] Reference numeral 2703 denotes a configuration ROM which stores identification and communication conditions unique to each device. The data format of this ROM complies with a format defined by the IEEE 1212 and IEEE 1394 standards, as described in <Technical Overview of IEEE 1394 Standard>.

[0248] Reference numeral 2704 denotes a CPU for controlling 1394 interfaces such as the link layer IC and PHY IC; 2705, a ROM storing control programs for these interfaces; and 2706, a RAM used for a data buffer for storing transmission/reception data, a control work area, and the data areas of various registers mapped at 1394 addresses.

[0249] Each node comprises a configuration ROM of a general format as shown in FIG. 24. Software unit information of each device is stored in a unit directory, whereas node dependent information is stored in a node dependent info directory.

[0250] The basic function instance of each device such as a printer function or scanner function, and detailed information accessory to the basic function can be held by an instance directory offset from the root directory.

[0251] The format of the instance directory will be described. The instance directory stores information of a device such as a printer or scanner which does not depend on protocols. For a single-function device, basic function information is one. For a device which supports a plurality of functions, a plurality of functions are listed. For each of the listed functions, the instance directory stores pointer information to a unit directory for storing corresponding protocol software information, and a pointer to a feature directory for holding detailed information unique to each function.

[0252] As described in <Technical Overview of IEEE 1394 Standard>, the last 28 bits out of the address setting of the 1394 serial bus are ensured as the unique data area of each device which can be accessed by another device connected to the serial bus. FIG. 25 is a view showing the address space of the 28-bit area serving as the unique data area of each device.

[0253] CSR core registers shown in FIG. 11 are arranged in an area from address 0000 to address 0200 in FIG. 25. These registers exist as basic functions for node management defined by the CSR architecture.

[0254] An area from address 0200 to address 0400 is defined by the CSR architecture as an area for storing serial bus dependent registers. FIG. 26 shows an example of the area for storing serial bus dependent registers according to the first embodiment. As described in <Technical Overview of IEEE 1394 Standard>, registers at address 0200 to address 0230 are defined and used for synchronization of data transfer, supply of power, management of the bus resource, and the like. This is the same as the arrangement shown in FIG. 12.

[0255] A register REMOTE_—BUS_—RESET arranged at address 0240 in FIG. 26 is a feature of the first embodiment. The format of this register is shown in FIG. 27.

[0256] A node in which data prepared by substituting an effective bus ID in a BUS_—ID field in accordance with the format of FIG. 27 is written by a 1394 write transaction to this register can know occurrence of bus reset in a remote bus represented by the BUS_—ID field other than a local bus connected to this node. The above-mentioned configuration ROM is arranged in an area from address 0400 to address 0800.

[0257] An area from address 0800 to address 1000 shown in FIG. 25 stores the current 1394 bus topology information and information about the transfer speed between nodes. An area after address 1000 is called a unit space where registers concerning operations unique to each device are arranged. This area stores registers and a data transfer memory mapped buffer area defined by upper protocols supported by each device, or device dependent registers.

[0258] The operation of the first embodiment in a 1394 network where devices A1 and A2 each having a 1394 interface constituted in the above manner are connected to the bus A, devices B1 and B2 are connected to the bus B, and the buses A and B are connected by a 1394 bridge device will be explained with reference to FIGS. 28 and 29. FIG. 28 is a view showing communication control procedures complying with a DPP protocol in the first embodiment, and FIG. 29 is a view showing communication control procedures complying with an AV/C protocol in the first embodiment.

[0259] Before the buses A and B attain their current connection configurations, bus reset independently occurs on each bus every time a device node is additionally connected. A bus reset sequence and bus ID determination sequence are executed to automatically assign a node ID upon occurrence of bus reset, and a new topology is created.

[0260] Then, 1394 data transfer starts on each bus. Details of these sequences are described in “(6) Description of Sequence After Occurrence of Bus Reset” and “(8) Assignment of Node ID” of <Technical Overview of IEEE 1394 Standard>, and a description thereof will be omitted. Although the operation changes depending on the connection order of connection nodes and the connection order of buses to the 1394 bridge, the bus reset-1394 initialization sequence is repeated every time a node is connected. Finally, a topology in which devices A1 and A2 are connected to the bus A via the 1394 bridge 101, and devices B1 and B2 are connected to the bus B is formed.

[0261] While the topology of the 1394 network is determined in this state, and 1394 data transfer is normally performed, the node A1 as a digital still camera having a direct print protocol (to be referred to as a “DPP”) as an upper protocol searches for a printer device which supports the DPP on the 1394 network, like the self node, in order to transfer image data to a printer connected to the 1394 network and print the image data in accordance with user operation or the trigger of an application.

[0262] This is realized by read-accessing the configuration ROM of a partner node for a node connected to the network. This is shown in FIG. 19. More specifically, the node uses an IEEE 1394 read transaction for the partner node to receive the ROM contents of the partner node as a read response.

[0263] As described above, 1394-related information is described in the configuration ROM of each node. Further, the basic function of each node such as a printer or camera is described in the instance directory, and an upper protocol such as an AV/C protocol or DPP and software information are described in the unit directory.

[0264] While the node A1 read-accesses the ROM of each node on the local bus A, and then read-accesses the ROM of each node on the bus B via the 1394 bridge, the node A1 detects that the node B1 is a printer as a DPP device.

[0265] Although details of a 1394 transaction via the 1394 bridge will be omitted, its standard is being defined by IEEE p1394.1.

[0266] After the camera as the node A1 finds the node B1 which is a printer and has the same protocol as the DPP protocol supported by the node A1, the node A1 establishes connection with the node B1 in accordance with procedures and a format defined by the DPP protocol shown in FIG. 28.

[0267] More specifically, the node A1 transmits a connection request command to the node B1 using a write transaction, as shown in {circle around (1)} of FIG. 28. In response to this, the node B1 transmits a connection request response using a write transaction, as shown in {circle around (2)} of FIG. 28. Then, transfer of application data starts.

[0268] Similarly, the node B2 as a digital video cam coder having an AV/C protocol as an upper protocol starts transmission/reception of an AV/C command with the node A2 via the 1394 bridge using an AV/C protocol shown in FIG. 29. The node B2 issues an AV/C command, and enters a response wait state, as shown in {circle around (1)} of FIG. 29.

[0269] Assume that a device node A3 (108) shown in FIG. 1 is newly connected to the bus A by user operation in this network state. Since the new node is additionally connected, bus reset occurs in accordance with IEEE 1394 characteristics.

[0270] The 1394 interface layer of each node on the bus A which has received a bus reset signal notifies the upper protocol layer of this information. At the same time, the node starts a series of bus reset resume processes such as a bus reset sequence and node ID determination sequence in order to automatically assign a node ID upon occurrence of bus reset.

[0271] After bus reset on the bus A 102 is notified to the DPP layer, the node A1 (104), which establishes connection with the node B1 (106) on the bus B 103 in accordance with a DPP protocol on the bus A 102 and performs data transfer, starts bus reset resume processing complying with the DPP protocol.

[0272] In bus reset resume processing by DPP, when data transfer normally restarts after bus reset resume processing ends in the 1394 layer to determine a new node ID and topology, a node which has first transmitted a connection request to a partner node within a predetermined time before data transmission restarts transmits a reconnection request command.

[0273] After bus reset resume is completed in the 1394 interface layer, a node which has received a request in establishment of connection enters a reception wait state for a reconnection request command from the node which has established connection. If the node does not receive any command, it abandons the connection.

[0274] After bus reset on the bus A 102 is notified to the AV/C layer, the node B1 (106) which is transferring data to the node B2 (107) on the bus B 103 in accordance with an AV/C protocol on the bus A 102 starts bus reset procedure processing.

[0275] In the AV/C protocol, a node which has received an AV/C command transmitted by one node generally transmits a paired response containing information such as command execution results and the like to the command issuing node. Upon occurrence of bus reset, an AV/C command sent before reset for which no response is received is regarded not to be executed and to be abandoned. Thus, an AV/C command must be resent after bus reset processing ends in the 1394 interface layer, and data transfer normally resumes.

[0276] On the bus B 103 whose connection configuration is not changed, no bus reset occurs in accordance with the IEEE standard. Even if bus reset occurs on the bus A 102 connected via the 1394 bridge 101, the bus B 103 detects this, but the 1394 bridge 101 does not propagate any bus reset signal to another bus, i.e., the bus B 103 in this case because of defined characteristics.

[0277] Hence, only nodes such as the nodes A1, A2, and A3 connected to the bus A 102 start bus reset resume processing. The node B1 (106) as the data transmission destination of the node A1 (104) and the node B2 (107) as the data transmission destination of the node A2 (105) do not start this processing.

[0278] In the 1394 network system of the first embodiment, the 1394 bridge comprises a means for notifying, of bus reset occurrence information on one bus, a node connected to the other bus, and each node comprises a means for receiving a bus reset occurrence notification from a remote bus.

[0279] More specifically, the 1394 bridge 101 which has received a bus reset signal upon occurrence of bus reset on the bus A executes bus reset processing on the node controller side. At the same time, the 1394 bridge 101 notifies the node controller side of the bus B of occurrence of bus reset together with bus ID information of the bus A, i.e., a value 3FDh.

[0280] The node controller of the bus B which has received this information uses a 1394 write transaction to write a packet containing data representing the bus ID: 3 FDh of the remote bus suffering bus reset in the register “REMOTE_—BUS_—RESET” arranged at address 0240 of each node connected to the bus B in accordance with the format of this register.

[0281] Although no bus reset occurs on the bus B, the bus B is notified of occurrence of bus reset on the remote bus A by writing the ID of the bus A in the REMOTE_—BUS_—RESET register of each node by the 1394 bridge 101, as shown in {circle around (3)} of FIG. 28 or {circle around (2)} of FIG. 29.

[0282] The 1394 interface layer of each node on the bus B which has detected write in the REMOTE_—BUS_—RESET register notifies the upper protocol layer of occurrence of bus reset on the remote bus and bus ID information of the remote bus.

[0283] The node B1, which has established connection with the node A1 on the bus A in accordance with a DPP protocol on the bus B and has performed data transfer, checks the ID of the remote bus suffering bus reset, and confirms that the remote bus is the bus A connected to a node as the connection destination of the node B1. Then, the node B1 recognizes that the connection destination node, i.e., node A1 has started bus reset resume processing complying with a DPP protocol.

[0284] The node B1 also starts processing corresponding to DPP bus reset processing, and enters a reception wait state for a reconnection request command from the node with which the node B1 establishes connection. This ensures the consistency of DPP protocol processing between the node A1 which starts bus reset processing after bus reset actually occurs, and the node B1 connected to the bus B on which no bus reset occurs.

[0285] After that, the node A1 transmits a reconnection request command shown in {circle around (4)} of FIG. 28 to the node B1, and the node B1 transmits a reconnection request response shown in {circle around (5)} of FIG. 28 to the node A1, thereby restarting data communication.

[0286] Similarly, the node B2, which has exchanged an AV/C command with the node A2 on the bus A in accordance with an AV/C protocol on the bus B, checks the ID of the remote bus suffering bus reset, and confirms that the remote bus is the bus A connected to the node A2 as a connection destination node. Then, the node B2 recognizes that the connection destination node, i.e., node A2 has started bus reset processing according to an AV/C protocol.

[0287] The node B2 also executes processing corresponding to AV/C bus reset processing shown in FIG. 29, and processing in which an AV/C command sent before remote bus reset for which no response is received is regarded not to be executed and to be abandoned. This ensures the consistency of AV/C protocol processing between the node A2 which starts bus reset processing after bus reset actually occurs, and the node B2 connected to the bus B on which no bus reset occurs.

[0288] The node B2 resends an AV/C command shown in {circle around (3)} of FIG. 29 to the node B2. In response to this, the node A2 transmits an AV/C response shown in {circle around (4)} of FIG. 29 to the node B2, thereby continuing communication.

[0289] As described above, the first embodiment provides a 1394 bus system characterized in that a node connected to an IEEE 1394 bus comprises a means capable of receiving the ID of a bus suffering bus reset and a reset occurrence notification when bus reset occurs on a remote bus other than a bus connected to the self node, and if a plurality of buses are connected via bridges, a bridge connected to the bus suffering bus reset transmits to the reception means of other connected buses a remote bus reset occurrence notification containing the ID of the bus suffering bus reset. When bus reset occurs on one local bus in performing data transfer from a data transmission node on one local bus to a data reception node connected to the other local bus via a 1394 bridge, the 1394 bridge can notify the node connected to the remote bus of bus reset. The reception node connected to the other bus can detect bus reset to maintain the consistency of bus reset processing in the upper protocol layer. This enables normal data communication between buses.

[0290] The first embodiment can further provide a node connected to an IEEE 1394-compliant communication control bus with a means capable of receiving the ID of a bus suffering bus reset and a reset occurrence notification when bus reset occurs on a remote bus other than a local bus connected to the self node.

[0291] As the remote bus reset occurrence notification reception means, the first embodiment can provide a means for storing a register at a predetermined address on the node, and detecting write of bus ID information at the address to receive a remote bus reset occurrence notification.

[0292] Further, the first embodiment can provide an information signal processing apparatus characterized in that the predetermined register is arranged in the core CSR architecture register space or serial bus register space in the address space of each 1394 node.

[0293] The first embodiment can provide a 1394 bus system characterized in that occurrence of remote bus reset is notified when a plurality of buses are connected via bridges in an IEEE 1394 bus system, and bus reset occurs in a remote bus other than connected buses. Moreover, this embodiment can provide a 1394 bus system characterized in that a bridge connected to a bus suffering bus reset transmits to the node of another connected bus a remote bus reset occurrence notification containing the ID of the bus suffering bus reset.

[Second Embodiment]

[0294] The second embodiment according to the present invention will be described below. In the second embodiment, the configuration and function of a communication system using a 1394 interface are the same as those in the first embodiment, and a detailed description thereof will be omitted.

[0295] In the second embodiment, the same reference numerals as in the first embodiment denote the same parts in the configuration and connection device of the second embodiment, and a detailed description thereof will be omitted.

[0296] In the second embodiment, a 1394 serial bus interface can be constituted similarly to the first embodiment shown in FIG. 23, and the configuration ROM of each node can adopt the same formats as those shown in FIGS. 24 and 25. The second embodiment is different from the first embodiment in that the format of an area from address 0200 to address 0400 shown in FIG. 25 for storing serial bus dependent registers has the format shown in FIG. 30.

[0297] In the second embodiment, NOTIFY_—BUS_—RESET arranged at address 0244 is assigned in addition to serial bus dependent registers shown in FIG. 26, and is a characteristic register of the second embodiment. The format of the NOTIFY_—BUS_—RESET register will be explained with reference to FIG. 31. FIG. 31 is a view showing the format of the NOTIFY_—BUS_—RESET register in the second embodiment.

[0298] The NOTIFY_—BUS RESET register is a register mounted on the bridge portal of a 1394 bridge 101 (to be described below) to which the second embodiment is applied. According to a 1394 write transaction, a data with a format of FIG. 31 is written into the register. If an effective bus ID, an effective node ID and an effective command (1: store, 0: delete) are respectively substituted in a BUS_—ID field, a NODE_—ID field and a command field of the data written in the register, the bridge 101 receives the data as an effective data, and executes process according to the value of the command field. If the value of the command field is “1” (store), the bridge 101 stores the values of BUS_—ID field and NODE_—ID field of the received data into the storage table corresponds to the portal. If the value of the command field is “0” (delete), the bridge 101 deletes the values of BUS_—ID field and NODE_—ID field of the received data from the storage table corresponds to the portal. When a bus reset occurs in the 1394 bus to which the portal is connected, the bridge 101 notifies the occurrence of the bus reset to the node by writing, according to the 1394 write transaction, to a REMOTE_—BUS_—RESET register of the node designated by the bus ID and node ID stored in the storage table.

[0299] FIG. 32 is a block diagram showing the arrangement of the IEEE 1394 bridge 101 in the second embodiment. In FIG. 32, a portal A 3301 is connected to a bus A 102, whereas a portal B 3302 is connected to a bus B 103. Each portal functions as one node connected to the bus.

[0300] A bridge controller 3303 has a function of bridging the portals A 3301 and B 3302. A bus reset manager 3304 stores or deletes a bus ID and node ID written in the NOTIFY_—BUS_—RESET register of the portal A 3301 in or from a storage table A 3305.

[0301] Similarly, the bridge controller 3303 stores or deletes a bus ID and node ID written in the NOTIFY_—BUS_—RESET register of the portal B 3302 in or from a storage table B 3306. The bridge controller 3303 notifies a node of occurrence of bus reset by writing data in accordance with the same format of FIG. 27 as in the first embodiment in the REMOTE BUS RESET register of the node stored in the storage table A 3305 when bus reset occurs on the bus A 102, or in the storage table B 3306 when bus reset occurs on the bus B 103.

[0302] The configuration ROM is arranged in an area from address 0400 to address 0800.

[0303] Similar to the first embodiment, an area from address 0800 to address 1000 shown in FIG. 25 stores the current 1394 bus topology information and information about the transfer speed between nodes. An area after address 1000 is called a unit space where registers concerning operations unique to each device are arranged. This area stores registers and a data transfer memory mapped buffer area defined by upper protocols supported by each device, or device dependent registers.

[0304] A detailed operation in a 1394 network shown in FIG. 1 where the nodes A1 (104) and A2 (105) each having a 1394 interface constituted in the above manner are connected to the bus A 102, the nodes B1 (106) and B2 (107) are connected to the bus B 103, and the bus A 102 and bus B 103 are connected by the 1394 bridge 101 will be explained with reference to FIGS. 33 and 34. FIG. 33 is a view showing communication control procedures complying with a DPP protocol in the second embodiment, and FIG. 34 is a view showing communication control procedures complying with an AV/C protocol in the second embodiment.

[0305] Before buses A and B attain their current connection configurations, bus reset independently occurs on each bus every time a device node is additionally connected. Upon occurrence of bus reset, a node ID is automatically assigned. For this purpose, a bus reset sequence and bus ID determination sequence are executed to create a new topology.

[0306] Then, 1394 data transfer starts on each bus. Details of these sequences are described in “(6) Description of Sequence After Occurrence of Bus Reset” and “(8) Assignment of Node ID” of <Technical Overview of IEEE 1394 Standard>, and a description thereof will be omitted.

[0307] Although the operation changes depending on the connection order of connection nodes and the connection order of buses to the 1394 bridge 101, the bus reset-1394 initialization sequence is repeated every time a node is connected. Finally, a topology in which devices A1 and A2 are connected to the bus A via the 1394 bridge 101, and devices B1 and B2 are connected to the bus B is formed.

[0308] While the topology of the 1394 network is determined in this state, and 1394 data transfer is normally performed, the node A1 as a digital still camera having a direct print protocol (to be referred to as a “DPP”) as an upper protocol searches for a printer device which supports the DPP on the 1394 network, like the self node, in order to transfer image data to a printer connected to the 1394 network and print the image data in accordance with user operation or the trigger of an application.

[0309] This is realized by read-accessing the configuration ROM of a partner node for a node connected to the network. This is shown in FIG. 19. More specifically, the node uses an IEEE 1394 read transaction for the partner node to receive the ROM contents of the partner node as a read response.

[0310] As described above, 1394-related information is described in the configuration ROM of each node. Further, the basic function of each node such as a printer or camera is described in the instance directory, and an upper protocol such as an AV/C protocol or DPP and software information are described in the unit directory.

[0311] While the node A1 read-accesses the ROM of each node on the local bus A, and then read-accesses the ROM of each node on the bus B via the 1394 bridge, the node Al detects that the node B1 is a printer as a DPP device.

[0312] Although details of a 1394 transaction via the 1394 bridge will be omitted, its standard is being defined by IEEE p1394.1.

[0313] After the camera as the node A1 (104) finds the node B1 (106) which is a printer and has the same protocol as the DPP protocol supported by the node A1, the node A1 establishes connection with the node B1 in accordance with procedures and a format defined by the DPP protocol shown in FIG. 33, and starts data transfer.

[0314] At this time, as shown in {circle around (1)} of FIG. 33, the node A1 (104) writes {(bus ID of bus B), (node ID of node B1), (storage command)} in the NOTIFY_—BUS_—RESET register of the portal A 3301 of the 1394 bridge 101 in accordance with the format shown in FIG. 31. The node A1 (104) transmits a connection request command to the node B1 using a write transaction shown in {circle around (2)} of FIG. 33.

[0315] In response to this, as shown in {circle around (3)} of FIG. 33, the node B1 (106) writes {(bus ID of bus A), (node ID of node A1), (storage command)} in the NOTIFY_—BUS_—RESET register of the portal B 3302 of the 1394 bridge 101 in accordance with the format of FIG. 31.

[0316] The node B1 (106) transmits a connection request response to the node A1 using a write transaction shown in {circle around (4)} of FIG. 33. In this way, the node A1 (104) establishes connection with the node B1 (106), and the bus reset manager of the 1394 bridge stores these bus IDs and node IDs in corresponding storage tables.

[0317] Similarly, the node B2 (107) as a digital video cam coder having an AV/C protocol as an upper protocol starts transmission/reception of an AV/C command with the node A2 (105) via the 1394 bridge using an AV/C protocol. For this purpose, the node B2 (107) performs the same write operation as {circle around (1)} of FIG. 33 in the bridge 101 so as to enable notifying a partner node of bus reset, as shown in {circle around (1)} of FIG. 34.

[0318] The node B2 (107) issues an AV/C command shown in {circle around (2)} of FIG. 34, and enters a response wait state. Also, the node A2 (105) which has received the AV/C command shown in {circle around (2)} of FIG. 34 performs the same write operation as {circle around (3)} of FIG. 33 in the bridge 101 so as to enable notifying a partner node of bus reset, as shown in {circle around (3)} of FIG. 34.

[0319] Assume that a device node A3 (108) shown in FIG. 1 is newly connected to the bus A by user operation in this network state. Then, bus reset occurs in accordance with IEEE 1394 characteristics.

[0320] In this case, no bus reset occurs on the bus B 103 whose connection configuration does not change. The node B1 (106) serving as the data transmission destination of the node A1 (104), and the node B2 (107) serving as the data transmission destination of the node A2 (105) do not start bus reset resume processing.

[0321] However, this causes the above problem, so that the second embodiment executes the following operation instead of the defined operation.

[0322] In the 1394 network system of the second embodiment, the bus reset manager 3304 of the 1394 bridge 101 comprises a means for notifying, of bus reset occurrence information on a bus connected to a bridge portal, a node stored in a storage table corresponding to this portal. Each node comprises a means for receiving a sub reset occurrence notification on a remote bus. This arrangement solves the above problem.

[0323] More specifically, the 1394 bridge 101 which has received a bus reset signal upon occurrence of bus reset on the bus A 102 performs bus reset processing by the node controller of the portal A 3301 connected to the bus A 102. The bus reset manager 3304 uses a 1394 write transaction to sequentially write packets containing data of the bus ID of a remote bus, i.e., the bus ID: 3FDh of the bus A suffering bus reset in accordance with the register format in the REMOTE_—BUS_—RESET registers arranged at address 0240 of the serial bus registers of respective nodes shown in FIG. 30 that are stored in the storage tables 3305 and 3306.

[0324] In the second embodiment, the bus IDs and node IDs of the node B1 (106) and node B2 (107) are stored in the storage tables, so that data are written in these nodes, as shown in {circle around (5)} of FIG. 33 or {circle around (4)} of FIG. 34.

[0325] As a result, the bus B 103 does not suffer bus reset, but can be notified of occurrence of bus reset on the remote bus A by writing the ID of the bus A 102 in the REMOTE_—BUS_—RESET register of each node that should be notified by the bridge 101.

[0326] The 1394 interface layer of each node which has detected write in the REMOTE_—BUS_—RESET register notifies the upper protocol layer of occurrence of bus reset on a remote bus and the bus ID information of the remote bus.

[0327] The node B1 (106), which establishes connection with the node A1 (104) on the bus A in accordance with a DPP protocol on the bus B and performs data transfer, checks the ID of the remote bus suffering bus reset, and confirms that the remote bus is the bus A 102 connected to a node as the connection destination of the node B1. Then, the node B1 recognizes that the connection destination node, i.e., node A1 (104) has started bus reset resume processing complying with a DPP protocol.

[0328] The node B1 (106) also starts processing corresponding to DPP bus reset processing, and enters a reception wait state for a reconnection request command from the node with which the node B1 (106) establishes connection. This ensures the consistency of DPP protocol processing between the node A1 (104) which starts bus reset processing after bus reset actually occurs, and the node B1 (106) connected to the bus B 103 on which no bus reset occurs.

[0329] After that, the node A1 (104) transmits a reconnection request command shown in {circle around (6)} of FIG. 33 to the node B1 (106), and the node B1 (106) transmits a reconnection request response shown in {circle around (7)} of FIG. 33 to the node A1 (104), thereby restarting data communication.

[0330] Similarly, the node B2 (107), which exchanges an AV/C command with the node A2 (105) on the bus A 102 in accordance with an AV/C protocol on the bus B 103, checks the ID of the remote bus suffering bus reset, and confirms that the remote bus is the bus A 102 connected to the node A2 (105) as the connection destination of the node B2. Then, the node B2 (107) recognizes that the connection destination node, i.e., node A2 (105) has started bus reset processing according to an AV/C protocol. The node B2 (107) also executes processing corresponding to AV/C bus reset processing, and processing in which an AV/C command sent before remote bus reset for which no response is received is regarded not to be executed and to be abandoned. This ensures the consistency of AV/C protocol processing between the node A2 (105) which starts bus reset processing after bus reset actually occurs, and the node B2 (107) connected to the bus B 103 on which no bus reset occurs.

[0331] The node B2 (107) resends an AV/C command shown in {circle around (5)} of FIG. 34 to the node A2 (105). In response to this, the node A2 (105) transmits an AV/C response shown in {circle around (6)} of FIG. 34 to the node B2 (107), thereby continuing communication.

[0332] Even when bus reset occurs on the bus B 103, the bus reset manager 3304 of the 1394 bridge 101 similarly notifies a target node on the bus A 102 of occurrence of bus reset, thereby maintaining the consistency of upper protocol processing.

[0333] As described above, the second embodiment provides an IEEE 1394 bridge having at least two portals respectively connected to different IEEE 1394 buses, characterized by comprising a bus reset management means made up of a means for monitoring bus reset of the IEEE 1394 buses inserted/removed to/from the respective portals, a means for designating either one of the IEEE 1394 buses connected to the respective portals, a means for designating a node on a network constituted by a plurality of IEEE 1394 buses connected via bridges, and a means for notifying the designated node of bus reset of the designated bus. This IEEE 1394 bridge can notify a node connected to a remote bus of occurrence of bus reset.

[Third Embodiment]

[0334] In the third embodiment, the basic configuration is the same as in the first and second embodiments shown in FIGS. 1 to 34, and a detailed description thereof will be omitted. Only the difference from the first and second embodiments will be described. The third embodiment is different from the second embodiment in communication control procedures complying with a DPP protocol. Communication control procedures complying with a DPP protocol in the third embodiment according to the present invention will be described with reference to FIG. 35.

[0335] Similar to the second embodiment, while the topology of a 1394 network is determined, and 1394 data transfer is normally performed, a node A1 as a digital still camera having a DPP as an upper protocol searches for a printer device which supports the DPP on the 1394 network, like the self node, in order to transfer image data to a printer connected to the 1394 network and print the image data in accordance with user operation or the trigger of an application.

[0336] While the node A1 read-accesses the ROM of each node on a local bus A 102, and then read-accesses the ROM of each node on a bus B 103 via a 1394 bridge, the node A1 detects that a node B1 is a printer as a DPP device. Assume that the node B1 comprises a REMOTE_—BUS_—RESET register, but the node A1 does not comprise it. The node B1 can know this from ROM information of the node A1.

[0337] In the third embodiment, when (3FFH) and (3FH) are respectively written in the bus ID field and node ID field of the format shown in FIG. 31 in the NOTIFY_—BUS_—RESET register of a bridge portal, a bus reset manager 3304 of a 1394 bridge 101 stores the bus ID and node ID of the writing node in a storage table corresponding to the written portal.

[0338] After the camera as the node A1 finds the node B1 which is a printer and has the same protocol as the DPP protocol supported by the node A1, the node A1 establishes connection with the node B1 in accordance with procedures and a format defined by the DPP protocol. To start transferring application data, the node A1 transmits a connection request shown in {circle around (1)} of FIG. 35 to the node B1 using a write transaction.

[0339] At this time, as shown in {circle around (2)} of FIG. 35, the node B1 writes {(3FFH), (3FFH), (storage command)} in the NOTIFY_—BUS_—RESET register of the portal A 3301 of the 1394 bridge in accordance with the format of FIG. 31.

[0340] The bus reset manager of the 1394 bridge stores the bus ID and node ID of the node B1 in a storage table corresponding to the portal A. Then, the node B1 transmits a connection request response shown in {circle around (3)} of FIG. 35 to the node A1 using a write transaction, and establishes connection.

[0341] Similar to the second embodiment, assume that a device node A3 (108 shown in FIG. 1) is newly connected to the bus A 102 by user operation in the network state shown in FIG. 1. Part of this control is different from the second embodiment.

[0342] Since the new node is additionally connected, bus reset occurs in accordance with IEEE 1394 characteristics. The 1394 interface layer of each node on the bus A 102 which has received a bus reset signal notifies the upper protocol layer of this information. At the same time, the node starts a series of bus reset resume processes such as a bus reset sequence and node ID determination sequence in order to automatically assign a node ID upon occurrence of bus reset.

[0343] After bus reset on the bus A 102 is notified to the DPP layer, the node A1 (104), which has established connection with the node B1 (106) on the bus B 103 in accordance with a DPP protocol on the bus A 102 and has performed data transfer, starts bus reset resume processing complying with the DPP protocol, similar to the first embodiment.

[0344] On the other hand, when no bus reset occurs in the bus B 103 whose connection configuration does not change, and bus reset occurs on the bus A 102, as described in the first embodiment, a bus reset signal is not propagated to the bus B 103. At this time, only nodes such as the nodes A1, A2, and A3 connected to the bus A start bus reset resume processing. The node B1 as the data transmission destination of the node A1 and the node B2 as the data transmission destination of the node A2 do not start this processing.

[0345] In the third embodiment, as well as the first embodiment, the 1394 bridge 101 which has received a bus reset signal upon occurrence of bus reset on the bus A 102 executes bus reset processing on the node controller side of the portal A 3301 connected to the bus A 102. The bus reset manager 3304 uses a 1394 write transaction to sequentially write packets containing data of the bus ID of a remote bus, i.e., the bus ID: 3FDh of the bus A 102 suffering bus reset in accordance with the register format in REMOTE_—BUS_—RESET registers arranged at address 0240 of respective nodes stored in storage tables 3305 and 3306. At the same time, the bus reset manager 3304 also writes data in the node B1, as shown in {circle around (4)} of FIG. 35.

[0346] Although no bus reset occurs on the bus B, the bus B is notified of occurrence of bus reset on the remote bus A by writing the ID of the bus A 102 in the REMOTE_—BUS_—RESET register of each target node by the 1394 bridge 101.

[0347] The 1394 interface layer of each node which has detected write in the REMOTE_—BUS_—RESET register notifies the upper protocol layer of occurrence of bus reset on the remote bus and bus ID information of the remote bus.

[0348] The node B1 (106), which has established connection with the node A1 (104) on the bus A 102 in accordance with a DPP protocol on the bus B 103 and has performed data transfer, checks the ID of the remote bus suffering bus reset, and confirms that the remote bus is the bus A connected to a node as the connection destination of the node B1 (106). Then, the node B1 (106) recognizes that the connection destination node, i.e., node A1 (104) has started bus reset resume processing complying with a DPP protocol.

[0349] The node B1 (106) also starts processing corresponding to DPP bus reset processing, and enters a reception wait state for a reconnection request command from the node with which the node B1 (106) establishes connection. This ensures the consistency of DPP protocol processing between the node A1 which starts bus reset processing after bus reset actually occurs, and the node B1 connected to the bus B on which no bus reset occurs.

[0350] Thereafter, the node A1 transmits a reconnection request command shown in {circle around (5)} of FIG. 35 to the node B1, and the node B1 transmits a reconnection request response shown in {circle around (6)} of FIG. 35 to the node A1, thereby restarting data communication.

[0351] If bus reset occurs on the bus B, the node A1 on the bus A does not know occurrence of bus reset on the bus B. During bus reset on the bus B, the request of the node A1 is held by the bridge, and sent to the node B1 by the bridge after the end of bus reset on the bus B, as shown in {circle around (7)} of FIG. 35. The node B1 transmits a reconnection request response to the node A1, as shown in {circle around (8)} of FIG. 35, and can restart data communication.

[0352] Since the node B1 can maintain consistency after the end of bus reset, the node B1 can restart communication in response to a request from the node A1, as shown in FIG. 35.

[0353] As described above, the third embodiment provides an information communication system including a first IEEE 1394 bus connected to an IEEE 1394 bridge, a first node connected to the first IEEE 1394 bus, a second IEEE 1394 bus different from the first IEEE 1394 bus, and a second node connected to the second IEEE 1394 bus, the first and second nodes communicating with each other, characterized in that the first node instructs the IEEE 1394 bridge connected to the first IEEE 1394 bus to monitor bus reset on the first IEEE 1394 bus and notify the second node of bus reset on the first IEEE 1394 bus. This information communication system can notify a communication partner node connected to a remote bus of occurrence of bus reset on a bus connected to the self node.

[0354] If bus reset occurs on one local bus in performing data transfer from a data transmission node on one local bus to a data reception node connected to the other local bus via a 1394 bridge using the same upper protocol, the 1394 bridge can notify the node connected to the remote bus of bus reset. The reception node connected to the other bus can detect the bus reset, and maintain the consistency of bus reset processing in the upper protocol layer. This enables normal data communication between buses.

[Fourth Embodiment]

[0355] FIG. 36 is a block diagram showing the configuration of the fourth embodiment according to the present invention.

[0356] In the fourth embodiment, as shown in FIG. 36, a 1394 bridge A 3401 is connected to a bus A via a portal A, and to a bus C via a portal C1. A 1394 bridge B 3402 is connected to a bus B via a portal B, and the bus C via a portal C2.

[0357] The bus A is connected to a node A1 (3403) and node A2 (3404), the bus B is connected to a node B1 (3405) and node B2 (3406), and the bus C is connected to a node C1 (3407) and node C2 (3408).

[0358] The bus A has a bus ID (3FDh), the bus B has a bus ID (3FEh), and the bus C has a bus ID (3FCh).

[0359] The system of the fourth embodiment has the same building components as those in the third embodiment, and the 1394 bridge has the same arrangement as that shown in FIG. 32. Only the difference from the third embodiment will be described below.

[0360] In the fourth embodiment, as well as the second embodiment, after a camera as the node A1 finds the node B1 which is a printer and has the same protocol as the DPP protocol supported by the node A1, the node A1 establishes connection with the node B1 in accordance with the procedures and format defined by a DPP protocol shown in FIG. 37, and starts transferring application data. As shown in {circle around (1)} of FIG. 37, the node Al writes {(bus ID of bus B), (node ID of node B1), (storage command)} in the NOTIFY_—BUS_—RESET register of the portal A of the 1394 bridge A 3401, and transmits a connection request shown in {circle around (2)} of FIG. 37 to the node B1. In response to this, as shown in {circle around (3)} of FIG. 37, the node B1 writes {(bus ID of bus A), (node ID of node A1), (storage command)} in the NOTIFY_—BUS_—RESET register of the portal B of the second 1394 bridge in accordance with the format of FIG. 31, and transmits a connection request shown in {circle around (4)} of FIG. 37 to the node A1.

[0361] The bus reset managers of the 1394 bridges A3401 and B3402 store these bus IDs and node IDs in corresponding storage tables.

[0362] Similarly, the node B2 as a digital video cam coder having an AV/C protocol as an upper protocol starts exchanging an AV/C command with the node A2 via the 1394 bridges A 3401 and B 3402 using an AV/C protocol. The node B2 performs the same write operation as {circle around (1)} of FIG. 37 in the second 1394 bridge in {circle around (1)} of FIG. 38 so as to enable notifying a partner node of bus reset. Subsequently, the node B2 issues an AV/C command, as shown in {circle around (2)} of FIG. 38, and enters a response wait state.

[0363] The node A2 which has received the command from the node B2 performs the same write operation as {circle around (1)} of FIG. 38 in the first 1394 bridge so as to enable notifying a partner node of bus reset, as shown in {circle around (3)} of FIG. 38.

[0364] Assume that a device node A3 (3409 in FIG. 36) is newly connected to the bus A by user operation in this network state. Since the new node is additionally connected, bus reset occurs in accordance with IEEE 1394 characteristics. The 1394 interface layer of each node on the bus A which has received a bus reset signal notifies the upper protocol layer of this information. At the same time, the node starts a series of bus reset resume processes such as a bus reset sequence and node ID determination sequence in order to automatically assign a node ID upon occurrence of bus reset.

[0365] In the fourth embodiment, as well as the first embodiment, the 1394 bridge A 3401 which has received a bus reset signal upon occurrence of bus reset on the bus A executes bus reset processing on the node controller side of the portal A connected to the bus A. The bus reset manager uses a 1394 write transaction to sequentially write packets containing data of the bus ID of a remote bus, i.e., the bus ID: 3FDh of the bus A suffering bus reset in accordance with the register format in REMOTE_—BUS_—RESET registers arranged at address 0240 of respective nodes stored in the storage tables, as shown in {circle around (5)} of FIG. 37 or {circle around (4)} of FIG. 38.

[0366] These packets are transmitted to the node on the bus B via the bus C and the 1394 bridge B 3402.

[0367] Although no bus reset occurs on the bus B, the bus B is notified of occurrence of bus reset on the remote bus A by writing the ID of the bus A in the REMOTE_—BUS_—RESET register of each node which should be notified to the storage table of the 1394 bridge B 3402.

[0368] The 1394 interface layer of each node which has detected write in the REMOTE_—BUS_—RESET register notifies the upper protocol layer of occurrence of bus reset on the remote bus and bus ID information of the remote bus.

[0369] Similar to the first embodiment, each node performs processing corresponding to bus reset to ensure the consistency of an upper protocol, as shown in {circle around (6)} and {circle around (7)} of FIG. 37 or {circle around (5)} and {circle around (6)} of FIG. 38.

[0370] Bus reset on the bus B can also be notified from the 1394 bridge B 3402 to the node on the bus A via the bus C and 1394 bridge A 3401, thereby maintaining the consistency of an upper protocol.

[0371] As described above, according to the fourth embodiment, a notification packet is transmitted to only a node to which bus reset must be notified. The traffic on the network does not greatly increase, and the performance of the network does not decrease.

[0372] The fourth embodiment provides an information communication system including a first IEEE 1394 bus connected to an IEEE 1394 bridge, a first node connected to the first IEEE 1394 bus, a second IEEE 1394 bus different from the first IEEE 1394 bus, and a second node connected to the second IEEE 1394 bus, the first and second nodes communicating with each other, characterized in that the second node instructs the IEEE 1394 bridge connected to the first IEEE 1394 bus to monitor bus reset on the first IEEE 1394 bus and notify the second node of bus reset on the first IEEE 1394 bus. This information communication system can notify the self node connected to a remote bus of occurrence of bus reset on a bus connected to a connection partner. Since the self node comprises an ability of maintaining consistency against bus reset on the remote bus, the node can communicate with a conventional device which is connected to the remote bus and to which the present invention is not applied.

[Fifth Embodiment]

[0373] In the fifth embodiment, the same reference numerals as in the second embodiment denote the same parts of the configuration and connection device in the fifth embodiment, and a detailed description thereof will be omitted.

[0374] In the fifth embodiment, similar to the first embodiment, the 1394 serial bus interface has the same arrangement as in the first embodiment shown in FIG. 23, and the configuration ROM of each node has the same format as shown in FIGS. 24 and 25. Further, an IEEE 1394 bridge device 101 has the same arrangement as in the second embodiment shown in FIG. 32.

[0375] The fifth embodiment is different from the above embodiments in that the format of an area where serial bus dependent registers from address 0200 to address 0400 shown in FIG. 25 has the format shown in FIG. 39.

[0376] The fifth embodiment uses address 023C, and does not require an area from address 0240, compared to the serial bus dependent registers shown in FIGS. 26 and 30. That is, the fifth embodiment is characterized by an operation with defined registers at address 0200 to address 0230 described in <Technical Overview of IEEE 1394 Standard>. The operation in the fifth embodiment adopting the 1394 bridge 101 with the same arrangement shown in FIG. 32 as the second embodiment will be described with reference to FIGS. 40 and 41.

[0377] FIG. 40 is a view showing communication control procedures complying with a direct print protocol (to be referred to as a “DPP” hereinafter) in the fifth embodiment according to the present invention. FIG. 41 is a view showing communication control procedures complying with an AV/C protocol in the fifth embodiment.

[0378] Before buses A and B attain their current connection configurations, bus reset independently occurs on each bus every time a device node is additionally connected. A bus reset sequence and bus ID determination sequence are executed to automatically assign a node ID upon occurrence of bus reset, and a new topology is created.

[0379] Then, 1394 data transfer starts on each bus. Details of these sequences are described in “(6) Description of Sequence After Occurrence of Bus Reset” and “(8) Assignment of Node ID” of <Technical Overview of IEEE 1394 Standard>, and a description thereof will be omitted.

[0380] Although the operation changes depending on the connection order of connection nodes and the connection order of buses to the 1394 bridge, the bus reset-1394 initialization sequence is repeated every time a node is connected. Finally, a topology in which devices A1 and A2 are connected to the bus A via the 1394 bridge 101, and devices B1 and B2 are connected to the bus B is formed.

[0381] While the topology of the 1394 network is determined in this state, and 1394 data transfer is normally performed, the node A1 as a digital still camera having a DPP as an upper protocol searches for a printer device which supports the DPP on the 1394 network, like the self node, in order to transfer image data to a printer connected to the 1394 network and print the image data in accordance with user operation or the trigger of an application.

[0382] This is realized by read-accessing the configuration ROM of a partner node for a node connected to the network. This is described in the first embodiment with reference to FIG. 19. More specifically, the node uses an IEEE 1394 read transaction for the partner node to receive the ROM contents of the partner node as a read response.

[0383] As described above, 1394-related information is described in the configuration ROM of each node. Further, the basic function of each node such as a printer or camera is described in the instance directory, and an upper protocol such as an AV/C protocol or DPP and software information are described in the unit directory.

[0384] While the node A1 read-accesses the ROM of each node on the local bus A, and then read-accesses the ROM of each node on the bus B via the 1394 bridge, the node A1 detects that the node B1 is a printer as a DPP device.

[0385] Although details of a 1394 transaction via the 1394 bridge will be omitted, its standard is being defined by IEEE p1394.1.

[0386] After the camera as the node A1 finds the node B1 which is a printer and has the same protocol as the DPP protocol shown in FIG. 40 that is supported by the node A1, the node A1 establishes connection with the node B1 in accordance with procedures and a format defined by the DPP protocol.

[0387] More specifically, the node A1 transmits a connection request command to the node B1 using a write transaction, as shown in {circle around (1)} of FIG. 40. In response to this, the node B1 transmits a connection request response shown in {circle around (2)} of FIG. 40 to the node A1.

[0388] At this time, the 1394 bridge 101 traces communication between these nodes, and stores an identification set of the bus ID and node ID of the node B1, those of the node A1, and the DPP protocol in a connection management table 3105.

[0389] Similarly, the node B2 as a digital video cam coder having an AV/C protocol as an upper protocol starts transmission/reception of an AV/C command with the node A2 shown in FIG. 41 via the 1394 bridge using an AV/C protocol. The node B2 issues an AV/C command shown in {circle around (1)} of FIG. 41, and enters a response wait state.

[0390] The 1394 bridge 101 traces communication between these nodes, and stores an identification set of the bus ID and node ID of the node B2, those of the node A2, and the AV/C protocol in the connection management table 3105.

[0391] Assume that a device node A3 (node 108 shown in FIG. 1) is newly connected to the bus A by user operation in this network state. Then, bus reset occurs, as described above, and a series of bus reset resume processes start. When bus reset on the bus A is notified to the DPP layer, the node A1, which has established connection with the node B1 on the bus B in accordance with a DPP protocol on the bus A and has performed data transfer, starts the above-described bus reset resume processing complying with the DPP protocol.

[0392] On the bus B whose connection configuration is not changed, no bus reset occurs. If bus reset occurs on the bus A connected via the 1394 bridge 101, the bus B detects this, but the characteristics of the 1394 bridge 101 in the fifth embodiment prevent any bus reset signal from propagating to another bus, i.e., the bus B in this case.

[0393] Hence, only nodes such as the nodes A1, A2, and A3 connected to the bus A start bus reset resume processing. The node B1 as the data transmission destination of the node A1 and the node B2 as the data transmission destination of the node A2 do not start this processing.

[0394] In the 1394 network system of the fifth embodiment, the 1394 bridge 101 comprises a means for storing connection information containing the upper protocol of a node which establishes connection via the bridge, and performing, by the bridge, bus reset resume processing of the upper protocol layer which should be executed by a node connected to the other node upon occurrence of bus reset on one bus.

[0395] More specifically, the 1394 bridge 101 which has received a bus reset signal upon occurrence of bus reset on the bus A executes bus reset processing on the node controller side connected to the bus A. At the same time, the 1394 bridge 101 confirms a node on the bus A which starts bus reset resume processing of the upper protocol layer, from connection information stored in the connection management table.

[0396] The node A1 of the bus A transmits a reconnection command shown in {circle around (3)} of FIG. 40 to the node B1 with which the node A1 establishes connection to transfer data. The 1394 bridge does not transmit this to the node B1, but transmits a reconnection response shown in {circle around (4)} of FIG. 40 to the node A1 in place of the node B1. This ensures the consistency of DPP protocol processing between the node A1 which starts bus reset processing after bus reset actually occurs, and the node B1 connected to the bus B on which no bus reset occurs.

[0397] The node B2, which has exchanged an AV/C command with the node A2 on the bus A in accordance with an AV/C protocol on the bus B, wait for a response from the node B2. However, the communication destination node A2 starts bus reset processing complying with an AV/C protocol, and abandons the command received from the node B2 because bus reset has occurred on the connected bus A. The 1394 bridge knows that a response from the node A2 is not transmitted to the node B2. Thus, the 1394 bridge resends an AV/C command which the node B2 sent before remote bus reset and for which no response is received, to the node A2, as shown in {circle around (2)} of FIG. 41.

[0398] This ensures the consistency of AV/C protocol processing between the node A2 which starts bus reset processing after bus reset actually occurs, and the node B2 connected to the bus B on which no bus reset occurs. Thus, subsequent communication control procedures can be smoothly executed, as shown in, e.g., {circle around (3)} of FIG. 41.

[0399] As described above, the fifth embodiment provides an information communication system including a first IEEE 1394 bus connected to an IEEE 1394 bridge, a first node connected to the first IEEE 1394 bus, a second IEEE 1394 bus different from the first IEEE 1394 bus, and a second node connected to the second IEEE 1394 bus, the first and second nodes communicating with each other, characterized in that the IEEE 1394 bridge comprises a means for interpreting an upper protocol used by communication between the first and second nodes, and a means for performing processing which should be done by the second node, by the bridge instead of the second node when bus reset occurs on the first IEEE 1394 bus, and when bus reset occurs on the first IEEE 1394 bus, the IEEE bus bridge performs processing which should be executed upon occurrence of bus reset between the first node and the IEEE 1394 bridge, thereby performing communication between the first and second nodes regardless of bus reset on the first IEEE 1394 bus.

[0400] According to the fifth embodiment, if bus reset occurs on one local bus in performing data transfer from a data transmission node on one local bus to a data reception node connected to the other local bus via a 1394 bridge using the same upper protocol, the 1394 bridge 101 can execute bus reset resume processing instead of the node on the remote bus.

[0401] As a result, the consistency of bus reset processing in the upper protocol layer can be maintained without notifying the reception node connected to the other bus of occurrence of bus reset. This realizes normal data communication between buses.

[0402] More specifically, in a system in which a plurality of communication control networks (e.g., IEEE 1394 buses) are connected via connection devices (e.g., IEEE 1394 bridges), if a network configuration update request (e.g., IEEE 1394 bus reset) occurs in one communication control network in performing data transfer from a data transmission communication device of one communication network to a data reception communication device connected to the other communication control network via a connection device using the same upper protocol, the connection device can execute network configuration update resume processing instead of the communication device connected to the communication control network. The consistency of network configuration update request processing in the upper protocol layer can be ensured without notifying the reception communication device connected to the other communication control network of the network configuration update request. This enables normal data communication between communication control networks.

[Other Embodiment]

[0403] The present invention may be applied to a system constituted by a plurality of devices (e.g., a host computer, interface device, reader, and printer) or an apparatus comprising a single device (e.g., a copying machine or facsimile apparatus).

[0404] The object of the present invention is realized even by supplying a storage medium storing software program codes for realizing the functions of the above-described embodiments to a system or apparatus, and causing the computer (or a CPU or MPU) of the system or apparatus to read out and execute the program codes stored in the storage medium.

[0405] In this case, the program codes read out from the storage medium realize the functions of the above-described embodiments by themselves, and the storage medium storing the program codes constitutes the present invention.

[0406] As a storage medium for supplying the program codes, a floppy disk, hard disk, optical disk, magnetooptical disk, CD-ROM, CD-R, magnetic tape, nonvolatile memory card, ROM, or the like can be used.

[0407] The functions of the above-described embodiments are realized not only when the readout program codes are executed by the computer but also when the OS (Operating System) running on the computer performs part or all of actual processing on the basis of the instructions of the program codes.

[0408] The functions of the above-described embodiments are also realized when the program codes read out from the storage medium are written in the memory of a function expansion board inserted into the computer or a function expansion unit connected to the computer, and the CPU of the function expansion board or function expansion unit performs part or all of actual processing on the basis of the instructions of the program codes.

[0409] When the present invention is applied to the above storage medium, program codes corresponding to the above-described flow charts are stored in this storage medium.

[0410] As many apparently widely different embodiments of the present invention can be made without departing from the spirit and scope thereof, it is to be understood that the invention is not limited to the specific embodiments thereof except as defined in the appended claims.