Data processing method, data processing unit, printer and storage medium

The present invention relates to a data processing method, a data processing apparatus, a printer, and a storage medium for switching protocols of a plurality of types of printers via a common serious bus.

Conventional Technology Conventionally, various types of systems have been known as systems for transmitting data to a printer via a serious bus.

[0003] For example, a technique for outputting data from a computer to a printer using a de facto standard interface that has become widely used, such as SCSI (Small Computer System Interface) and Centronics, is known.

[0004] However, the conventional printer protocol for transmitting printer data using a serious bus is limited to one unique to a printer manufacturer. Therefore, there has been a problem of lack of extensibility. In particular, when printing data is output using an interface for connecting various types of devices, for example, an interface such as IEEE1394, the problem of lack of expandability has been a major problem to be solved.

[0005] Therefore, the present invention has been made to eliminate the above-mentioned drawbacks, and is a highly expandable data processing method, a data processing device, a printer, and a device when transmitting print data via a system bus. The purpose is to provide a storage medium. Another object of the present invention is to provide a data processing method, a data processing device, a printer and a storage medium suitable for the IEEE1394 standard. Another object of the present invention is to provide a data processing method, a data processing device, a printer and a storage medium suitable for connecting a printer directly from an image data output device without using a computer. Another object of the present invention is to provide a data processing method, a data processing device, a printer and a storage medium capable of obtaining an optimum printer output. Another object of the present invention is to provide a data processing method, a data processing device, a printer and a storage medium capable of reducing the load due to switching of protocols.

[Means for Solving the Problems] The data processing method of the present invention is a data processing method for switching protocols of a plurality of devices via a common serious bus, and is an initial stage performed with the device. By communicating the protocol, the first investigation process for investigating the ID of the device in the same network by the common serious bus and the second investigation process for investigating the protocol unique to the device are executed, and the first investigation is performed. The protocol to be executed is determined based on the ID obtained in the process and the protocol obtained in the second investigation process, and the determined protocol is executed following the initial protocol. The data processing device of the present invention is a data processing device for switching the protocol of a plurality of devices via a common serious bus, and is the same network by the common serious bus by communication of the initial protocol performed with the device. A first execution means for executing a first investigation process for investigating the ID of the device in the above, a second investigation process for investigating a protocol specific to the device, and an ID obtained in the first investigation process. It is characterized by including a determination means for determining a protocol to be executed based on the protocol obtained in the second investigation process, and a second execution means for executing the determined protocol following the initial protocol. To do. The printer of the present invention is a printer that switches the protocol of a plurality of devices corresponding to a host via a common serious bus, and is in the same network by the common serious bus by communication of the initial protocol performed with the device. A first execution means for executing a first investigation process for investigating the ID of the device, a second investigation process for investigating a protocol specific to the device, an ID obtained in the first investigation process, and It is characterized by including a determination means for determining a protocol to be executed based on the protocol obtained in the second investigation process, and a second execution means for executing the determined protocol following the initial protocol. .. The storage medium of the present invention is a computer-readable storage of a computer program for causing a computer to perform a data processing step for executing a data processing method for switching protocols of a plurality of devices via a common serious bus. The data processing method is a medium, and the data processing method includes a first investigation process for investigating the ID of the device in the same network by the common serious bus by communication of an initial protocol performed with the device, and the device. The step of executing the second investigation process for investigating the unique protocol and the protocol to be executed are determined based on the ID obtained in the first investigation process and the protocol obtained in the second investigation process. It is characterized by having a step and a step of executing the determined protocol following the initial protocol.

[Embodiments of the Invention] Hereinafter, embodiments of the present invention will be described with reference to the drawings.

[0008] First, in the first and second embodiments described below, since the IEEE1394 serial bus is used as the digital I / F for connecting the devices, the IEEE1394 serial bus is previously described. explain.

[0009] With the advent of consumer digital VCRs and DVD players, it is necessary to support real-time and high-information data transfer of video data, audio data, and the like. In order to transfer such video data and audio data in real time and import it to a personal computer (PC) or transfer it to other digital devices, a high-speed data transfer interface with the necessary transfer function is required. The interface developed from this point of view is IEEE1394-1995 (High Performance Serial Bus) (hereinafter, also simply referred to as 1394 serial bus).

FIG. 1 shows an example of a network system configured using a 1394 serial bus.

[0011] This system includes devices A, B, C, D, E, F, G, H, and can be used between AB, AC, BD, DE, CF, CG, and CH. Each is connected by a twisted pair cable of a 1394 serial bus. These devices A to H are, for example, personal computers, digital VTRs, DVDs, digital cameras, hard disks, monitors, tuners, monitors, and the like.

[0012] The connection method between the devices can be a mixture of the daisy chain method and the node branch method, and can be connected with a high degree of freedom.

[0013] Further, each device has its own unique ID, and each device constitutes one network within the range connected by the 1394 serial bus by recognizing each other. By simply connecting each digital device in sequence with a single 1394 serial bus cable, each device acts as a relay and constitutes one network as a whole. In addition, it has a function to automatically recognize the device and the connection status when the cable is connected to the device with the 1394 serial bus and Plug & Play functions.

[0014] Further, in the system as shown in FIG. 1, when a certain device is deleted or newly added from the network, the bus is automatically reset to reset the network configuration up to that point. From, we will rebuild the new network. With this function, it is possible to constantly set and recognize the network configuration at that time.

[0015] Further, the data transfer speed is 100/200 / 400 Mbps, and the device having the higher transfer speed supports the lower transfer speed and is compatible with each other.

[0016] The data transfer mode includes an asynchronous transfer mode for transferring asynchronous data such as a control signal (Asynchronous data: hereinafter referred to as Async data) and synchronous data such as real-time video data and audio data (Isochronous data: hereinafter referred to as Async data). There is an Isochronous transfer mode that transfers (called Iso data). In each cycle (usually 125 μS per cycle), the Async data and Iso data transfer the cycle start packet (CSP) indicating the start of the cycle, and then the Iso data transfer is prioritized over the Async data in the cycle. It is transferred in a mixed manner.

Next, FIG. 2 shows the components of the 1394 serial bus.

[0018] The 1394 serial bus is composed of a layer structure as a whole. As shown in Figure 2, there is a connector port to which the 1394 serial bus cable and connector are connected, and the physical layer and link layer are positioned as hardware on it.

[0019] The hardware unit is a substantial interface chip portion, of which the physical layer performs coding and connector-related control, and the link layer controls packet transfer and cycle time.

The transaction layer of the firmware unit manages data to be transferred (transaction) and issues Read, Write, and Lock instructions. The management layer is a part that manages the connection status and ID of each connected device and manages the network configuration.

[0021] The hardware and firmware are substantially the configuration of the 1394 serial bus.

[0022] Further, the application layer of the software part differs depending on the software to be used, and is a part that defines how data is placed on the interface, and a printer, an AVC protocol, and the like are specified.

[0023] The above is the configuration of the 1394 serial bus.

Next, FIG. 3 shows a diagram of the address space in the 1394 serial bus.

[0025] Each device (node) connected to the 1394 serial bus must have a 64-bit address unique to each node. By storing this address in ROM, you can always recognize the node address of yourself or the other party, and you can also perform communication by specifying the other party.

[0026] The addressing of the 1394 serial bus is a method according to the IEEE1212 standard, and the first 10 bits are used for specifying the bus number and the next 6 bits are used for specifying the node ID number. The remaining 48 bits are the address width given to the device, and each can be used as a unique address space. The last 28 bits store information such as identification of each device and specification of usage conditions as an area of unique data.

[0027] The above is an outline of the 1394 serial bus technology.

[0028] Next, the technical part that can be said to be a feature of the 1394 serial bus will be described in more detail.

[0029] The electrical specifications of the 1394 serial bus will be described.

FIG. 4 shows a cross-sectional view of a 1394 serial bus cable.

[0031] In the 1394 serial bus, a power supply line is provided in addition to 6 pins, that is, two sets of twisted pair signal lines in the connection cable. This makes it possible to supply electric power to devices that do not have a power source or devices whose voltage has dropped due to a failure.

[0032] The voltage of the power supply flowing in the power supply line is specified as 8 to 40 V, and the current is specified as a maximum current of DC1.5 A.

[0033] In the standard called DV cable, the cable is composed of 4 pins without a power supply.

[0034] DS-Link coding will be described.

FIG. 5 shows a diagram for explaining the DS-Link coding method of the data transfer format adopted in the 1394 serial bus.

[0036] In the 1394 serial bus, a DS-Link (Data / Strobe Link) coding method is adopted. This DS-Link coding method is suitable for high-speed serial data communication, and its configuration requires two signal lines. The main data is sent to one of the strands, and the strobe signal is sent to the other strand. On the receiving side, the clock is reproduced by taking the exclusive OR of the data to be communicated and the strobe.

[0037] The advantages of using this DS-Link coding method are that the transfer efficiency is higher than that of 8 / 10B conversion, the circuit scale of the controller LSI can be reduced because the PLL circuit is not required, and the data should be transferred. Since it is not necessary to send information indicating that the device is in the idle state when there is no data, the power consumption can be reduced by putting the transceiver circuit of each device in the sleep state.

[0038] A bus reset sequence will be described.

[0039] In the 1394 serial bus, each connected device (node) is given a node ID and is recognized as a network configuration.

[0040] When there is a change in this network configuration, for example, when there is a change due to an increase or decrease in the number of nodes due to insertion / removal of nodes, power ON / OFF, etc., and it is necessary to recognize a new network configuration, the change Each detected node sends a bus reset signal on the bus to enter a mode for recognizing a new network configuration.

[0041] The change detection method at this time is performed by detecting the change in the bias voltage on the 1394 port board.

[0042] A bus reset signal is transmitted from a certain node, and the physical layer of each node receives the bus reset signal and at the same time transmits the occurrence of the bus reset to the link layer and transmits the bus reset signal to the other nodes. .. After all the nodes finally detect the bus reset signal, the bus reset is activated.

[0043] The bus reset is also activated by directly issuing a command to the physical layer by plugging / unplugging the cable as described above, starting by hardware detection due to a network abnormality, or host control from the protocol. In addition, when the bus reset is activated, the data transfer is temporarily suspended, the data transfer during this period is waited, and after the completion, the data transfer is restarted under the new network configuration.

[0044] The above is the bus reset sequence.

[0045] The sequence of determining the node ID will be described.

[0046] After the bus reset, each node enters an operation of giving an ID to each node in order to construct a new network configuration. The general sequence from bus reset to node ID determination at this time will be described using the flowcharts of FIGS. 6, 7, and 8.

The flowchart of FIG. 6 shows a series of bus operations from the occurrence of a bus reset to the determination of a node ID and the ability to transfer data.

[0048] First, as step S101, it is constantly monitored that a bus reset occurs in the network, and when a bus reset occurs due to power ON / OFF of a node or the like, the process proceeds to step S102.

In step S102, a parent-child relationship is declared between the directly connected nodes in order to know the connection status of the new network from the state where the network is reset. When the parent-child relationship is determined among all the nodes in step S103, one route is determined in step S104. Until the parent-child relationship is determined between all the nodes, the parent-child relationship is declared in step S102, and the route is not determined.

[0050] When the route is determined in step S104, the next step S105 is to set a node ID that gives an ID to each node. The node IDs are set in the specified node order, the setting work is repeated until all the nodes are given IDs, and finally as step S106, when all the nodes have been set with IDs, a new network configuration is performed. Is recognized in all the nodes, so that the data transfer between the nodes can be performed as step S107, and the data transfer is started.

[0051] When the state of step S107 is reached, the mode for monitoring the occurrence of the bus reset is entered again, and when the bus reset occurs, the setting work from step S101 to step S106 is repeated.

[0052] The above is the explanation of the flowchart of FIG. 6, but the flow chart diagram shows the part of the flowchart of FIG. 6 from the bus reset to the route determination and the procedure from the route determination to the end of the ID setting in more detail. Are shown in FIGS. 7 and 8, respectively.

[0053] First, the flowchart of FIG. 7 will be described.

[0054] When a bus reset occurs in step S201, the network configuration is temporarily reset. It should be noted that as step S201, the occurrence of a bus reset is constantly monitored.

Next, as step S202, as the first step of the work of re-recognizing the connection status of the reset network, a flag indicating that the device is a leaf (node) is set in each device. Furthermore, as step S203, check how many ports each device has are connected to other nodes.

[0056] According to the result of the number of ports in step S204, the number of undefined (parent-child relationship has not been determined) ports is examined in order to start the declaration of the parent-child relationship. Immediately after the bus reset, the number of ports = the number of undefined ports, but as the parent-child relationship is determined, the number of undefined ports detected in step S204 changes.

[0057] First, immediately after the bus reset, only the leaf can declare the parent-child relationship first. The leaf can be known by checking the number of ports in step S203. As step S205, the leaf declares "I am a child and the other party is a parent" to the node connected to it and ends the operation.

[0058] A node that has a plurality of ports and is recognized as a branch in step S203 has an undefined number of ports> 1 in step S204 immediately after the bus reset, so it moves to step S206 and is first flagged as a branch. Wait to accept the "parent" in the parent-child relationship declaration from Reef in step S207.

[0059] The leaf declares a parent-child relationship, and the branch that receives it in step S207 checks the number of undefined ports in step S204 as appropriate, and if the number of undefined ports is 1, it is the remaining port. It is possible to declare "I am a child" in step S205 to the connected node. From the second time onward, for branches that have 2 or more even if the number of undefined ports is confirmed in step S204, wait again in step S207 to accept the "parent" from the leaf or another branch.

Finally, if any one branch, or exceptionally a leaf (because it didn't work quickly to make a child declaration), becomes zero as a result of the number of undefined ports in step S204, then this The only node that has completed the declaration of the parent-child relationship of the entire network and has zero undefined ports (all determined as parent ports) is flagged as root as step S208 and rooted as step S209. Is recognized as.

[0061] In this way, from the bus reset shown in FIG. 7 to the declaration of the parent-child relationship between all the nodes in the network is completed.

Next, the flowchart of FIG. 8 will be described.

[0063] First, since the flag information of each node such as leaf, branch, and root is set in the sequence up to FIG. 8, each is classified in step S301 based on this.

[0064] It is from the leaf that the ID can be set first as the work of giving the ID to each node. IDs are set from the youngest number (node number = 0 ~) in the order of leaf branch root.

[0065] As step S302, the number N of leaves existing in the network (N is a natural number) is set.

[0066] After this, as step S303, each leaf requests the route to be given an ID. If there are multiple requests, the route arbitrates as step S304, assigns an ID number to one node that wins as step S305, and notifies the losing node of the result of the failure.

[0067] The leaf whose ID acquisition has failed in step S306 issues an ID request again, and repeats the same operation. As step S307, the ID information of the node is transferred to all the nodes by broadcasting from the leaf from which the ID can be acquired. When the broadcast of the one-node ID information is finished, the number of remaining leaves is decremented by one in step S308.

[0068] Here, as step S309, when the number of the remaining leaves is 1 or more, the work of the ID request in step S303 is repeated, and finally when all the leaves broadcast the ID information, step S309 is performed. When N = 0, the next step is to set the branch ID. The branch ID setting is done in the same way as for the leaf.

[0069] First, as step S310, the number M of branches existing in the network (M is a natural number) is set.

After this, as step S311 each branch requests the root to be given an ID. On the other hand, the route is arbitrated as step S312, and the winning branch is given to the leaf in order from the next youngest number.

[0071] In step S313, the root notifies the branch that issued the request of the ID information or the failure result, and in step S314, the branch that has failed to acquire the ID issues an ID request again and repeats the same operation.

[0072] As step S315, the ID information of the node is transferred to all the nodes by broadcasting from the branch where the ID can be acquired.

[0073] When the broadcast of the one-node ID information is completed, the number of the remaining branches is decremented by one as step S316.

[0074] Here, as step S317, when the number of the remaining branches is 1 or more, the operation of the ID request in step S311 is repeated until all the branches finally broadcast the ID information. When all the branches have acquired the node ID, step S317 becomes M = 0, and the branch ID acquisition mode also ends.

[0075] When the process is completed up to this point, the only node for which ID information has not been finally acquired is the root, so the youngest number not given as step S318 is set as the own ID number, and the root ID is set as step S319. Broadcast information.

[0076] As shown in FIG. 8, the procedure from the determination of the parent-child relationship to the setting of the IDs of all the nodes is completed.

Next, as an example, the operation in the actual network shown in FIG. 9 will be described with reference to FIG.

[0078] As a description of FIG. 9, node A and node C are directly connected to the lower part of (root) node B, node D is directly connected to the lower part of node C, and further, node D is connected. At the lower level, node E and node F are directly connected to each other in a hierarchical structure. The procedure for determining the hierarchical structure, root node, and node ID will be described below.

[0079] After the bus is reset, a parent-child relationship is first declared between the directly connected ports of each node in order to recognize the connection status of each node. It can be said that the parent side is higher in the hierarchical structure and the child side is lower.

[0080] In FIG. 9, it is node A that first declares the parent-child relationship after the bus reset. Basically, a parent-child relationship can be declared from a node (called a leaf) that has a connection to only one port of the node. Since I can first know that this is only a one-port connection, it recognizes that it is the end of the network, and the parent-child relationship is determined from the node that operates earlier in it. In this way, the port on the side that declares the parent-child relationship (node A between AB) is set as the child, and the port on the other side (node B) is set as the parent. In this way, it is determined that the node AB is a child-parent, the node ED is a child-parent, and the node FD is a child-parent.

[0081] Going up one level further, among the nodes (called branches) that have multiple connection ports, the ones that have received the parent-child relationship declaration from other nodes are declared in order, and the parent-child relationship is declared higher. To go. In FIG. 9, node D first determines the parent-child relationship between DE and DF, and then declares the parent-child relationship with node C, and as a result, determines child-parent between node DC.

[0082] Node C, which has received the declaration of the parent-child relationship from node D, declares the parent-child relationship to node B connected to another port. This determines the child-parent between the node CBs.

[0083] In this way, the hierarchical structure as shown in FIG. 9 is configured, and the node B that becomes the parent in all the ports that are finally connected is determined to be the root node. There is only one route in one network configuration.

Note that node B was determined to be the root node in FIG. 9, but this is because node B, which received the parent-child relationship declaration from node A, declares the parent-child relationship to other nodes at an early timing. If so, the root node may have moved to another node. That is, any node may become a root node depending on the timing of transmission, and the root node is not always constant even in the same network configuration.

[0085] Once the root node has been determined, the next step is to enter a mode in which each node ID is determined. Here, all nodes notify all other nodes of their determined node ID (broadcast function).

[0086] The self-ID information includes information on its own node number, information on the position where it is connected, the number of ports it has, the number of ports it is connected to, information on the parent-child relationship of each port, and the like.

[0087] As a procedure for allocating node ID numbers, it is possible to start from a node (leaf) that has a connection to only one port, and node numbers = 0, 1, 2, ... Assigned.

[0088] The node that has obtained the node ID transmits information including the node number to each node by broadcasting. This recognizes that the ID number is "allocated".

[0089] When all the leaves have acquired their own node IDs, the next step is to move to a branch and the node ID numbers following the leaves are assigned to each node. Similar to the leaf, the node ID information is broadcast sequentially from the branch to which the node ID number is assigned, and finally the root node broadcasts the self-ID information. That is, the route always owns the highest node ID number.

[0090] As described above, the allocation of the node ID of the entire hierarchical structure is completed, the network configuration is reconstructed, and the bus initialization work is completed.

[0091] The arbitration will be described.

[0092] In the 1394 serial bus, the arbitration (arbitration) of the bus usage right is always performed prior to the data transfer. The 1394 serial bus is a logical bus-type network in which each individually connected device relays the transferred signal to all the devices in the network, so that packet collisions occur. Arbitration is necessary to prevent the problem. This allows only one node to transfer at a given time.

As a diagram for explaining arbitration, FIG. 10 (a) shows a diagram of a bus use request, and a diagram of a bus use permission is shown in FIG. 10 (b), which will be described below.

[0094] When the arbitration starts, one or more nodes issue a request for bus usage right to the parent node. Node C and node F in Fig. 10 (a) are the nodes issuing the bus usage right request. In response to this, the parent node (node A in Fig. 10) further issues (relays) a request for bus usage rights to the parent node. This request is finally delivered to the arbitration route.

[0095] The root node that receives the bus use request decides which node to use the bus. This arbitration work can be performed only by the root node, and the node that wins the arbitration is given permission to use the bus. In Fig. 10 (b), the use permission is given to the node C, and the use of the node F is denied.

[0096] A DP (data prefix) packet is sent to the node that has lost the arbitration to notify that the node has been rejected. The bus usage request of the rejected node is waited until the next arbitration.

[0097] As described above, the node that has won the arbitration and obtained the permission to use the bus can start the data transfer thereafter.

[0098] Here, a series of arbitration flows will be described with reference to FIG. 11.

[0099] The bus must be idle in order for the node to initiate data transfer. In order to recognize that the previously performed data transfer is completed and the bus is currently free, a predetermined idle time gap length (for example, a sub-action) set individually for each transfer mode is used. By passing the gap), each node determines that its transfer can be started.

[0100] As step S401, it is determined whether or not a predetermined gap length corresponding to the data to be transferred, such as Async data and Iso data, has been obtained. Unless the predetermined gap length is obtained, the bus usage right required to start the transfer cannot be requested, so wait until the predetermined gap length is obtained.

[0101] When a predetermined gap length is obtained in step S401, it is determined whether there is data to be transferred as step S402, and if so, a request for a bus usage right is requested to secure a bus for transfer as step S403. Emit to the route. At this time, the transmission of the signal indicating the request for the right to use the bus is finally delivered to the route while relaying each device in the network as shown in FIG. If there is no data to be transferred in step S402, it waits as it is.

[0102] Next, as step S404, when one or more routes receive the bus usage request of step S403, the route checks the number of nodes that have issued the usage request as step S405.

If the selection value in step S405 is the number of nodes = 1 (the number of nodes that have issued the usage right request is one), the immediately following bus usage permission is given to that node. If the selection value in step S405 is the number of nodes> 1 (multiple nodes have issued usage requests), the route performs arbitration work to determine one node to be granted permission in step S406. This arbitration work is fair, and it is structured so that only the same node does not get permission every time, but gives equal rights (fair arbitration).

[0104] As step S407, a selection is made to divide the plurality of nodes for which the usage request is issued in step S406 into one node whose route has been arbitrated and the usage permission has been obtained, and the other defeated nodes. Here, for one node that has been arbitrated and obtained permission to use, or a node that has been arbitrated and obtained permission to use without arbitration with the number of request nodes = 1 from the selection value in step S405, the route is set to that node as step S408. Send a permission signal to it.

[0105] The node that has obtained the permission signal starts transferring the data (packet) to be transferred immediately after receiving the permission signal. In addition, the node that lost the arbitration in step S406 and was not allowed to use the bus is sent a DP (data prefix) packet indicating arbitration failure from the root as step S409, and the node that receives this forwards again. In order to issue a bus usage request for the bus, the process returns to step S401 and waits until a predetermined gap length is obtained.

[0106] The above is the explanation of the flowchart FIG. 11 for explaining the flow of arbitration.

[0107] Asynchronous transfer will be described.

Asynchronous transfer is an asynchronous transfer. Figure 12 shows the temporal transition state in asynchronous transfer.

The first sub-action gap in FIG. 12 indicates the idle state of the bus. When the idle time reaches a certain value, the node wishing to transfer determines that the bus can be used and executes arbitration for acquiring the bus.

[0110] After obtaining permission to use the bus by arbitration, data transfer is then executed in packet format. After data transfer, the receiving node transfers the received result ask (reception confirmation return code) for the transferred data by returning and responding after a short gap called ask gap, or by sending a response packet. Is completed. ask consists of 4-bit information and a 4-bit checksum, including information such as success, busy state, or pending state, and is immediately returned to the source node.

Next, FIG. 13 shows an example of a packet format for asynchronous transfer.

[0112] The packet has a header part in addition to the data part and the data CRC for error correction, and the header part includes a target node ID, a source node ID, a transfer data length, and various types as shown in FIG. Code etc. are written and transfer is performed.

[0113] Further, asynchronous transfer is one-to-one communication from the own node to the other node. Packets transferred from the forwarding node are distributed to each node in the network, but addresses other than the address addressed to itself are ignored, so only one node at the destination can read the packet.

[0114] The above is the description of asynchronous transfer.

[0115] Isochronous transfer will be described.

[0116] The isochronous transfer is a synchronous transfer. This isochronous transfer, which can be said to be the greatest feature of the 1394 serial bus, is a transfer mode suitable for transferring data that requires real-time transfer, such as multimedia data such as video data and audio data.

[0117] Further, while asynchronous transfer (asynchronous) is a one-to-one transfer, this isochronous transfer is uniformly transferred from one node of the transfer source to all other nodes by the broadcast function. ..

[0118] FIG. 14 is a diagram showing a temporal transition state in isochronous transfer.

[0119] The isochronous transfer is executed on the bus at regular time intervals. This time interval is called an isochronous cycle. The isochronous cycle time is 125 μS. The cycle start packet indicates the start time of each cycle and plays a role of adjusting the time of each node. It is the node called the cycle master that sends the cycle start packet, and announces the start of this cycle after a predetermined idle period (sub-action gap) has passed after the end of the transfer in the previous cycle. Send a cycle start packet.

The transmission time interval of this cycle start packet is 125 μS.

Further, as shown in FIG. 14 as channel A, channel B, and channel C, a plurality of types of packets can be transferred separately by being given channel IDs within one cycle. This enables real-time transfer between multiple nodes at the same time, and the receiving node captures only the data of the channel ID that you want. This channel ID does not represent the destination address, but merely gives a logical number to the data. Therefore, the transmission of a packet is broadcasted from one source node to all other nodes.

[0122] Prior to the packet transmission of the isochronous transfer, arbitration is performed as in the asynchronous transfer. However, since it is not one-to-one communication like asynchronous transfer, there is no ask (reception confirmation reply code) in isochronous transfer.

[0123] Further, the iso gap shown in FIG. 14 represents an idle period required for recognizing that the bus is in an empty state before performing isochronous transfer. After this predetermined idle period elapses, the node that wants to perform isochronous transfer determines that the bus is free and can perform arbitration before transfer.

[0124] Next, FIG. 15 shows and describes an example of a packet format for isochronous transfer.

[0125] Each of the various packets divided into each channel has a header part in addition to the data part and the data CRC for error correction, and the header part has a transfer data length and a channel NO as shown in FIG. , Other various codes and header CRC for error correction are written and transferred.

[0126] The above is the description of isochronous transfer.

[0127] Next, the bus cycle will be described.

[0128] In the actual transfer on the 1394 serial bus, isochronous transfer and asynchronous transfer can be mixed. FIG. 16 shows a diagram showing the temporal transition of the transfer state on the bus in which isochronous transfer and asynchronous transfer are mixed at that time.

[0129] The isochronous transfer is executed in preference to the asynchronous transfer. The reason is that after the cycle start packet, the isochronous transfer can be started with a gap length (isochronous gap) shorter than the gap length (sub-action gap) of the idle period required to start the asynchronous transfer. .. Therefore, the isochronous transfer is executed with priority over the asynchronous transfer.

[0130] In the general bus cycle shown in FIG. 16, a cycle start packet is transferred from the cycle master to each node at the start of cycle #m. As a result, each node adjusts the time, waits for a predetermined idle period (isochronous gap), and then the node that should perform isochronous transfer performs arbitration and enters packet transfer. In FIG. 16, channel e, channel s, and channel k are sequentially isochronously transferred.

[0131] After repeating the operation from the arbitration to the packet transfer for a given channel, when all the isochronous transfers in the cycle #m are completed, the asynchronous transfer can be performed.

[0132] When the idle time reaches the sub-action gap that enables asynchronous transfer, it is determined that the node that wants to perform asynchronous transfer can move to the execution of arbitration.

[0133] However, during the period during which the asynchronous transfer can be performed, a sub-action gap for invoking the asynchronous transfer is obtained between the end of the isochronous transfer and the time (cycle synch) at which the next cycle start packet should be transferred. Only when it is done.

[0134] In cycle #m of FIG. 16, isochronous transfer for three channels and then asynchronous transfer (including ack) are transferred in two packets (packet 1, packet 2). After this asynchronous packet 2, the time to start cycle m + 1 (cycle synch) is reached, so the transfer in cycle #m ends here.

[0135] However, if the time (cycle synch) for transmitting the next cycle start packet is reached during the asynchronous or synchronous transfer operation, it is not forcibly interrupted and waits for an idle period after the transfer is completed. Then send the cycle start packet for the next cycle. That is, when one cycle continues for 125 μS or more, the component cycle is assumed to be shorter than the standard 125 μS. In this way, the isochronous cycle can be exceeded or shortened based on 125 μS.

However, isochronous transfer is always performed every cycle to maintain real-time transfer, and asynchronous transfer may be passed on to the next and subsequent cycles due to the reduced cycle time. This delay information is also managed by the cycle master.

[0137] Therefore, first, the first embodiment will be described.

[0138] Fig. 17 is a diagram that best represents the features of the present invention. In the figure, when the interface of 1394 is compared with each layer of the OSI model used in the LAN, the physical layer 1 of the OSI model and the data link are shown. Layer 2 corresponds to the physical link layer which is the lower layer 4 of the 1394 interface, and the upper layer 3 existing above the lower layer 4 corresponds to the transport protocol layer 5 and the presentation layer 6 in the 1394 interface. Further, the LOGIN protocol 7, which is a feature of the present invention, operates between the lower layer 4 of the 1394 interface and the transport protocol 5.

[0139] In this embodiment, by inserting the LOGIN protocol into a device conforming to the serial bus protocol (SBP-2) 8, oneself communicates with the other device using the protocol conforming to SBP-2. You can notify that you want to do. Further, in the third embodiment described later, by inserting the LOGIN protocol also for the device protocol 9 specialized on the 1394 interface, it is determined whether each device supports the protocol and the data is stored. You can interact.

[0140] FIG. 18 is a diagram showing the basic operation of the LOGIN protocol. When the printer executes the print task 10, the printer protocols A, B, and C prepared by the printer using the LOGIN protocol first. Of these, which one is selected for printing is determined, and then the printing operation is performed according to the determined protocol. That is, in a device that supports several printer protocols on the printer side, when connecting to the target, the protocol of the other device is first determined using the LOGIN protocol, and the printer matches the protocol of the other party. A printer protocol is selected from a plurality of protocols, and print data and commands are exchanged according to the selected protocol to perform print processing.

[0141] FIG. 19 is a diagram showing a connection form of each device in the 1394 interface implementing the LOGIN protocol in this embodiment, and shows a device in which the LOGIN protocol is implemented for a printer 11 corresponding to a plurality of printer protocols ([0141]. When PC12, scanner 13, VCR14, etc.) are connected, the printer protocol can be switched on the printer side according to the transport protocol of the other party using the LOGIN protocol, and the printing task from each device can be processed without any problem. It becomes possible.

[0142] Fig. 20 shows the flow of login operation.

[0143] First step: -Lock the device (in this case, a multi-protocol printer) -Acquire the printer capabilities (accepting protocol, etc.) Such capabilities are stored in register 503, which will be described later. -Set the host capabilities to the printer Second step: -Communicate print data with the protocol determined in the first step Third step: -The printer and host disconnect the connection [0144] Figure 21 shows this implementation. In the form, the CSR of the 1394 serial bus provided by the printer for the LOGIN protocol is shown. In the figure, 501 indicates a lock register (lock), 502 indicates a protocol register (protocol), and 503 indicates a capability register (capability). These registers are located at defined addresses in the initial unit space in the 1394 serial bus address space. The lock register 501 indicates the locked state of the resource, a value 0 indicates that the resource can be logged in, and a value other than 0 indicates that the resource has already been logged in in the locked state. The capability register 503 indicates a configurable protocol, and a bit value 1 indicates that the protocol can be set, and 0 indicates that the protocol cannot be set. The protocol register 502 indicates the currently set protocol, and the value of the bit corresponding to the bit of the capability register 503 corresponding to the set protocol becomes 1.

FIG. 22 is a diagram showing a printer map format in a network configured by a 1394 serial bus (1394 network).

[0146] In this printer map, the unique ID (Unique ID), node ID (Node ID), status (Status), and capability (Capability) of the printer node that returned the response are stored. The status here indicates, for example, the contents of the protocol register 502 of FIG. 21, and the capability (Capability) indicates, for example, the contents of the capability register 503 of FIG. 21.

FIG. 23 is a diagram showing the format of node unique IDs in the CRC architecture.

FIG. 24 is a diagram showing the format of the printer map (FIG. 22) creation command, which is notified to the target by a write transaction of asynchronous packets.

Commands such as those shown in FIG. 24 are placed at defined addresses in the target unit space in the 1394 address space in this protocol.

FIG. 25 is a flowchart showing a host-side printing protocol (host-side printer map creation process) when a plurality of multi-protocol printers are connected to a 1394 network.

[0151] Here, various devices are usually connected to a node in a network. Under these circumstances, when the initiator (host) attempts to output the printer, it needs to know which node the printer is connected to. Further, in order to obtain an appropriate output of the printer, it is very convenient to know the physical location of the printer, its capacity, its spare capacity, and the like in advance.

[0152] Therefore, in this embodiment, the printers connected to the same network are investigated. For example, at the time of printer output, the initiator (host) obtains information such as the physical location, capacity, and spare capacity (hereinafter, also referred to as topology / capacity information) of the printer on the network as described above, and creates a printer map in advance. Then select the desired printer based on the printer map.

[0153] Hereinafter, a printer map creation process on the host side will be described with reference to FIG. 25.

[0154] First, in order to create a printer map (FIG. 22), the host side broadcasts the creation command (FIG. 24) (step S3001) and waits for a response command from the target printer. (Step S3002).

[0155] When the host side receives the response command from the target, it then reads the contents of the protocol register and the capability register of the target that returned the response command (step S3003). As a result, the host side recognizes the ability and state of the target.

[0156] Then, the host side creates a printer map for the printer on the current 1394 network based on the information obtained in step S3003 (step S3004).

[0157] FIG. 26 is a flowchart showing a process on the target side, that is, a printer side at the time of the printer map creation process on the host side described above.

First, the printer presents the status and capabilities from the time the power is turned on (step S3101). Specifically, for example, the protocol register and the capability register are set according to the current capacity and state of the own printer. Therefore, changes in status and capabilities within the printer will also reflect the status and capabilities at this step in the presentation.

Next, the printer is in a state of waiting for receiving a printer map creation command from the host side (step S3102).

When the printer receives the printer map creation command from the host side, the printer returns a response command to the command to the host side (step S3103).

[0161] FIG. 27 is a flowchart of the login process on the host side.

[0162] In order to start login, after the printer map creation process (step S600) shown in FIG. 25, the lock register 501, the protocol register 502, and the capability register 503 of the printer to be logged in are confirmed by a read transaction. To do. Here, from the contents of the capability register 503, it is confirmed whether or not the printer supports the protocol used by the host for communication (step 601). If the host's protocol is not supported by the printer, the next step is to abort the login.

If the lock register 501 is other than 0, it is considered that another device is logged in, and the login is canceled. If the login register 501 is 0, it is considered that you can log in now (step 602).

[0164] When login is possible Move to the resource lock process, write 1 to the lock register 501 of the printer using the lock transaction, and set the login setting on the host side (step 603). In this state, the printer is locked and output from other devices is impossible. Also, the register cannot be changed.

[0165] With the printer resources locked as described above, the protocol is set next. Since the printer in this embodiment supports a plurality of print protocols, it is necessary to know the protocol on the host side before receiving the print data. Here, a means is used in which the host side notifies the protocol register 502 of the printer by a write transaction by setting a bit corresponding to the protocol to be used (step 604).

[0166] At this point, since the protocol used by the host for communication is notified to the printer and the printer is in the locked state, the currently logged-in host transmits the print data by the normal protocol (step 605).

[0167] When the transmission of the print data is completed, the host logs out of the printer by clearing the lock register 501, the protocol register 502, and the capability register 503 of the printer (step 606).

[0168] FIG. 28 is a flowchart of the login process on the printer side.

[0169] After the printer map creation process (step S700) shown in FIG. 26, the printer side is normally in a state of waiting for login from the host. Since the print request from the host is started by reading the lock register 501, the protocol register 502, and the capability register 503 of the printer, the register is always kept readable by other devices. Now suppose the host trying to print out locks the printer (step 701).

[0170] When the printer is locked by writing to the lock register 501, the host then waits for the notification of the protocol used (step 702). The reason for waiting for the protocol notification after the locked state is to prevent the protocol register 502 from being rewritten by a request from another device during login.

[0171] When notified of the protocol, the printer switches the protocol it accepts and communicates with the host side (steps 703 to 710).

[0172] When the communication is completed, the printer confirms that the lock register 501, the protocol register 502, and the capability register 503 have been cleared (step 711), and returns to the login waiting state (step 701).

[0173] Next, a second embodiment will be described.

[0174] In the first embodiment described above, as described with reference to FIGS. 25 and 26, when a plurality of printers are connected to the 1394 network, the host creates a printer map for the printers on the network. However, in this second embodiment, both the host and the printer support multiple protocols on the 1394 network, and such a printer is selected based on the printer map. When multiple printers are connected, the host examines the available protocols for each printer and takes a majority vote to determine the most supported protocol.

[0175] Since the second embodiment is the same as the first embodiment except for the processes shown in FIGS. 25 and 26, detailed description thereof will be omitted here. Only the points different from the first embodiment will be specifically described.

First, FIG. 29 is a flowchart showing a printer map creation process on the host side in this embodiment, and FIG. 30 is a flowchart showing a process on the printer side at the time of this process. The process of FIG. 29 is the process performed in step S600 of the login process on the host side shown in FIG. 27, and the process of FIG. 30 is the process performed in step S700 of the login process of the printer side shown in FIG. 29. is there.

[0177] Here, in this embodiment, as described above, both the initiator (host) and the target (printer) support a plurality of protocols on the 1394 network, and a plurality of such printers are provided in the same network. Of course, if connected, the initiator and target must use the same protocol, but to decide which protocol to use now, the initiator looks up the available protocols for each printer and takes a majority vote among them. , Use the most supported protocol.

[0178] In this way, by configuring to take a majority vote in the situation where many protocols are available, it is possible to reduce the types of protocols actually used, and as a result, the load due to the protocol switch of the initiator. Can be lowered.

Hereinafter, the printer map creation process (relative majority protocol determination printer map process) on the initiator side (host side) and the target side (printer side) will be described with reference to FIGS. 29 and 30.

[0180] First, in order to create a printer map as shown in FIG. 22, the host side broadcasts the creation command (step S3201) and waits for a response command from the target printer (step S3201). Step S3202).

[0181] When the host side receives the response command from the target, it then reads the contents of the protocol register and the capability register of the target that returned the response command (step S3203). As a result, the host side recognizes the ability and state of the target.

Next, the host side creates a printer map for the printer on the current 1394 network based on the information obtained in step S3203 (step S3204).

Next, the host side examines the available protocols of the multi-protocol printer currently connected to the network from the printer map created in step S3204, and is the most supported among those protocols. Select a protocol (step S3205).

Then, the host side notifies each printer of the protocol selected in step S3205 as a protocol notification command (step S3206).

[0185] On the other hand, the printer first presents the status and the capability from the time when the power is turned on (step S3301). Specifically, for example, the protocol register and the capability register are set according to the current capacity and state of the own printer. Therefore, changes in status and capabilities within the printer will also reflect the status and capabilities at this step in the presentation.

Next, the printer is in a state of waiting for receiving a printer map creation command from the host side (step S3302).

[0187] Next, when the printer receives the printer map creation command from the host side, it returns a response command to the command to the host side (step S3303).

Next, the printer enters the state of waiting for receiving the protocol notification command from the host side (step S3402).

When the printer receives the protocol notification command from the host side, the printer returns a response command to the command to the host side (step S3503).

[0190] Next, a third embodiment will be described.

[0191] FIG. 31 is a diagram showing the operation in this embodiment, and when compared with the first embodiment shown in FIG. 2, it corresponds to protocol D in which the LOGIN protocol is not implemented. It can be said that the feature is that. That is, in order to guarantee the printing operation not only for the target having the LOGIN protocol but also for the device supporting only the existing protocol D (for example, AV / C protocol), the printer supports it. The printer protocol to be used is added for devices that do not have the LOGIN protocol.

[0192] Explaining this operation, when the printer side recognizes that the target side does not support the LOGIN protocol by the conversation by the LOGIN protocol performed at the beginning of the connection, the printer side talks to the target using another protocol D. If a conversation is established there, the printing task according to the protocol D can be executed.

[0193] FIG. 32 is a diagram showing a comparison with the OSI model in this embodiment, and in this embodiment, a printer conforming to the current AV / C protocol in which the LOGIN protocol is not implemented is used as a model. .. Example 4 shows the implementation of a protocol that does not have the functionality of the LOGIN protocol created for scanners, which is not yet defined in the current protocol. In other words, if the printer can handle protocols that do not implement the LOGIN protocol, the types of target devices that can be connected can be widened.

[0194] In the above-described embodiment, the printer is mainly described as a device on the network, but the present invention is not limited to this, and a monitor, a computer, a digital camera, or the like may be used, and the printer is limited to a specific model of the device. is not it.

[0195] Further, in the creation of the printer map executed in step S600 of FIG. 27, step S700 of FIG. 28, and step S3201 of FIG. 29, the topology connection state is investigated as shown in FIG. 9, and the display map is displayed. By determining the topology connection state to be created, it is possible to determine the protocol to be actually used in consideration of the topology connection state, not just a majority decision.

[0196] Further, the present invention may be applied to a system composed of a plurality of devices as shown in FIG. 19, or may be applied to a data processing method in a device composed of one device.

[0197] Further, an object of the present invention is to supply a storage medium storing a program code of software for realizing the functions of the host and the terminal of each of the above-described embodiments to the system or device, and to supply the computer of the system or device. Needless to say, it can also be achieved by (or CPU or MPU) reading and executing the program code stored in the storage medium.

[0198] In this case, the program code itself read from the storage medium realizes the functions of the above-described embodiments, and the storage medium storing the program code constitutes the present invention.

[0199] As a storage medium for supplying the program code, for example, a floppy disk, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM, a CD-R, a magnetic tape, a non-volatile memory card, a ROM, or the like is used. Can be done.

[0200] Further, by executing the program code read by the computer, not only the functions of the above-described embodiment are realized, but also the OS and the like running on the computer based on the instructions of the program code and the like. Needless to say, there is a case where a part or all of the actual processing is performed and the function of the embodiment is realized by the processing.

[0201] Further, after the program code read from the storage medium is written in the memory provided in the extension function board inserted in the computer or the function expansion unit connected to the computer, based on the instruction of the program code, the program code is written. Needless to say, there are cases where the function expansion board, the CPU provided in the function expansion unit, or the like performs a part or all of the actual processing, and the processing realizes the functions of the above-described embodiment.

[Effects of the Invention] As described above, according to the present invention, it is possible to provide a highly expandable data processing method, data processing apparatus, printer and storage medium. In particular, since it is compatible with multiple types of printer protocols, it is extremely expandable. Further, by investigating the printers connected to the same network, the target printer can be selected, so that the optimum printer output can be obtained. Furthermore, even when many protocols are available, it is possible to reduce the types of protocols actually used by determining the protocol most supported by the printer among those protocols. , The load of switching to the host-side protocol can be reduced.

BRIEF DESCRIPTION OF THE DRAWINGS [Fig. 1] Fig. 1 is a diagram showing an example of a communication system using an IEEE1394 cable.

FIG. 2 is a diagram showing a hierarchical structure of IEEE1394.

FIG. 3 is a diagram showing an IEEE1394 address.

FIG. 4 is a cross-sectional view of an IEEE1394 cable.

FIG. 5 is a diagram for explaining a DS-Link coding method.

FIG. 6 is a flowchart illustrating the process from bus reset to ID setting.

FIG. 7 is a flowchart illustrating a method of determining a route.

FIG. 8 is a flowchart illustrating a procedure from determining a parent-child relationship to setting all node IDs.

FIG. 9 is a diagram showing a parent-child relationship between nodes.

FIG. 10 is a diagram for explaining the process of arbitration.

FIG. 11 is a flowchart showing a process of arbitration.

FIG. 12 is a diagram for explaining a sub-action in Asynchronous transfer.

FIG. 13 is a diagram for explaining a packet structure in asynchronous transfer.

FIG. 14 is a diagram for explaining a sub-action in Isochronous transfer.

FIG. 15 is a diagram showing a packet structure in Isochronous forwarding.

FIG. 16 is a diagram for explaining an example of an IEEE1394 communication cycle.

FIG. 17 is a diagram for explaining a system to which the present invention is applied in the first embodiment.

FIG. 18 is a diagram for explaining the basic operation of the LOGIN protocol.

FIG. 19 is a diagram for explaining a connection mode of each device in a 1394 interface that implements the LOGIN protocol.

FIG. 20 is a diagram for explaining a flow of login operation.

FIG. 21 is a diagram for explaining the CSR of the 1394 serial bus provided in the printer for the LOGIN protocol.

FIG. 22 is a diagram for explaining a printer map in a 1394 network.

FIG. 23 is a diagram for explaining a node ID in the CRC architecture.

FIG. 24 is a diagram for explaining a command for creating a printer map.

FIG. 25 is a flowchart for explaining a printer map creation process on the host side.

FIG. 26 is a flowchart for explaining a printer map creation process on the printer side.

FIG. 27 is a flowchart for explaining a process on the host side of the login process.

FIG. 28 is a flowchart for explaining a process on the printer side of a login process.

FIG. 29 is a flowchart for explaining a printer map creation process on the host side in the second embodiment.

FIG. 30 is a flowchart for explaining a printer map creation process on the printer side in the second embodiment.

FIG. 31 is a diagram for explaining system operation in the third embodiment.

FIG. 32 is a diagram for explaining a comparison with the OSI model in the third embodiment.

[Code description] 1 Physical layer of OSI model 2 Data link layer 3 Upper layer 4 Upper layer 5 Transport protocol layer 6 Presentation layer 7 LOGIN protocol 8 Serial bus protocol (SBP-2) 9 Device protocol