JPH10304007A - Data processing method, data processing unit, printer and storage medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To enhance the extensibility in the case of transmission of print data via a system bus by allowing an initial protocol to include a 1st investigation processing that investigates a topology connection state of an identical network through a common serial bus in the case of executing a plurality of kinds of device specific protocols after the execution of the initial protocol. SOLUTION: A node ID is given to each device (node) to be connected in a 1394 serial bus, and each node is recognized as a network component. After a bus is reset, a statement of master-slave relationship is declared between directly connected ports of each node a port that node the declaration is set as a slave node and the opposite port is set as a master node, and finally a node B acting as a master node among all connected ports is decided to a route node. Then a mode to decide each node ID is selected, and initialization of the bus is finished by allowing all the nodes to inform its own decided node ID to all the other node.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a data processing method, a data processing device, a printer, and a storage medium for switching protocols of a plurality of types of printers via a common serial bus.

[0002]

2. Description of the Related Art Conventionally, various types of systems have been known as systems for sending data to a printer via a serial bus.

For example, SCSI (Small Computer System)
A technique of outputting data from a computer to a printer using a de facto standard interface that has been widely used, such as m Interface) or Centronics, is known.

[0004]

However, the conventional printer protocol for transmitting printer data using a serial bus is limited to one unique to a printer maker. Therefore, there has been a problem of lack of expandability. In particular, when print 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.

Accordingly, the present invention has been made to eliminate the above-mentioned drawbacks, and has a scalable data processing method for transmitting print data via a system bus.
It is an object to provide a data processing device, a printer, and 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 IEEE 1394 standard. It is another object of the present invention 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 that can obtain 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 that can reduce a load due to protocol switching.

[0006]

A first aspect of the present invention is a data processing method for switching protocols of a plurality of types of devices via a common serial bus, wherein an initial protocol irrespective of the types of protocols of the devices is provided. Executing, executing the plurality of device-specific protocols following the initial protocol, wherein the initial protocol comprises:
The method includes a first investigation process for investigating a topology connection state of the same network by the common serial bus. In a second aspect based on the first aspect, the initial protocol further includes a second investigation process for investigating a function of the device, a topology connection state obtained in the first investigation process, and the second connection process. Determining a protocol to be executed based on the plurality of protocols obtained in the investigation process. In a third aspect based on the first aspect, the first investigation process includes a process for obtaining information including a status and capabilities of a printer as a device. In a fourth aspect based on the third aspect, the protocol of the printer is a protocol for an inkjet printer. According to a fifth aspect, in the third aspect, the image data to be printed is transmitted after the execution of the printer-specific protocol. In a sixth aspect based on the fifth aspect, the image data is data photoelectrically converted by an imaging unit. In a seventh aspect based on the first aspect, the common serial bus is a bus conforming to the IEEE 1394 standard. In an eighth aspect based on the first aspect,
The common serial bus is a bus conforming to the USB standard. In a ninth aspect based on the first aspect, the initial protocol is a protocol executed in a layer higher than a data link layer of an OSI model. A tenth invention is a data processing device for switching a protocol of a plurality of types of devices via a common serial bus, wherein the first execution means executes an initial protocol irrespective of a type of a protocol of the device, Second executing means for executing the plurality of types of device-specific protocols following the initial protocol, wherein the initial protocol checks a topology connection state of the same network by the common serial bus. It is characterized by including. Eleventh
According to the tenth aspect, in the tenth aspect, the initial protocol further includes a second investigation process for investigating a function of the device, a topology connection state obtained in the first investigation process, and the second investigation process. Determining a protocol to be executed based on a plurality of protocols obtained in the processing. In a twelfth aspect based on the tenth aspect, the first investigation process includes a process of obtaining information including a status and capabilities of a printer as a device. In a thirteenth aspect based on the twelfth aspect, the protocol of the printer is a protocol for an ink jet printer. First
In a fourth aspect based on the tenth aspect, the second execution means transmits image data to be printed after executing a protocol specific to a printer as a device. In a fifteenth aspect based on the fourteenth aspect, the image data obtained by performing the photoelectric conversion is converted to the second image data.
Characterized in that it comprises imaging means for giving to the execution means. In a sixteenth aspect based on the tenth aspect, the common serial bus is a bus conforming to the IEEE 1394 standard. In a seventeenth aspect based on the tenth aspect, the common serial bus comprises a USB
It is a bus that conforms to the standard. In an eighteenth aspect based on the tenth aspect, the initial protocol is a protocol executed in a layer higher than a data link layer of an OSI model. Nineteenth
The invention is a printer that switches protocols of a plurality of types of devices via a common serial bus in accordance with a host, wherein the execution means executes an initial protocol irrespective of the type of the protocol; Receiving means for receiving print data after executing a printer-specific protocol, wherein the initial protocol includes a first checking process for checking a topology connection state of the same network by the common serial bus. I do. In a twentieth aspect based on the nineteenth aspect, the initial protocol further comprises a second investigation process for investigating a function of the device, a topology connection state obtained in the first investigation process, and the second investigation process. Determining a protocol to be executed based on the plurality of protocols obtained in the investigation process. In a twenty-first aspect based on the nineteenth aspect, the first investigation process includes a process of obtaining information including a status and a capability of a printer as a device. In a twenty-second aspect based on the twenty-first aspect, the protocol of the printer is a protocol for an inkjet printer. In a twenty-third aspect based on the nineteenth aspect, the image processing apparatus further comprises an image pickup unit for transmitting image data obtained by performing the photoelectric conversion to the reception unit as the print data. In a twenty-fourth aspect based on the nineteenth aspect, the common serial bus is an IEEE1394.
It is a bus that conforms to the standard. In a twenty-fifth aspect based on the nineteenth aspect, the common serial bus is a bus conforming to the USB standard. In a twenty-sixth aspect based on the nineteenth aspect, the initial protocol is a protocol executed in a layer higher than a data link layer of an OSI model. A twenty-seventh invention is a storage medium in which a data processing step for executing a data processing for switching a protocol of a plurality of types of devices via a common serial bus is stored in a computer-readable manner. Comprises a first execution step of executing an initial protocol irrespective of the type of protocol of the device, and a second execution step of executing the plurality of types of device-specific protocols subsequent to the initial protocol, The initial protocol includes a first investigation process for investigating a topology connection state of the same network by the common serial bus. In a twenty-eighth aspect based on the twenty-seventh aspect, the initial protocol further includes a second investigation process for investigating a function of the device, a topology connection state obtained in the first investigation process, and the second connection process. Determining a protocol to be executed based on the plurality of protocols obtained in the investigation process. In a twenty-ninth aspect based on the twenty-seventh aspect, the first investigation process includes a process of obtaining information including a status and capabilities of a printer as a device. In a thirtieth aspect based on the twenty-ninth aspect, the protocol of the printer is a protocol for an inkjet printer. In a thirty-first aspect based on the twenty-seventh aspect, the second execution step includes a step of transmitting image data to be printed after execution of a protocol unique to a printer as a device. According to a thirty-second aspect, in the thirty-first aspect, the image data is data photoelectrically converted by an imaging unit. In a thirty-third aspect based on the twenty-seventh aspect, the common serial bus is a bus conforming to the IEEE 1394 standard. In a thirty-fourth aspect based on the twenty-seventh aspect, the common serial bus is a bus that conforms to the USB standard. In a thirty-fifth aspect based on the twenty-seventh aspect, the initial protocol is a protocol executed in a layer higher than a data link layer of an OSI model.

[0007]

Embodiments of the present invention will be described below with reference to the drawings.

Here, first, in the first and second embodiments described below, a digital I / O connecting each device is used.
Since the IEEE 1394 serial bus is used as / F, the IEEE 1394 serial bus will be described in advance.

With the advent of consumer digital VCRs and DVD players, it is necessary to support real-time and high-information-volume data transfer of video data and audio data. Such video data and audio data are transferred in real time and transmitted to a personal computer (P
In order to capture the data in C) or transfer the data to other digital devices, an interface capable of high-speed data transfer having a necessary transfer function is required, and the interface developed from such a viewpoint is:
IEEE 1394-1995 (High Performance Seria
l Bus) (hereinafter simply referred to as 1394 serial bus)
It is.

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

This system comprises devices A, B, C, D,
E, F, G, H, and between A and B, between A and C, B
The 1394 serial bus twisted pair cables are connected between -D, DE, CF, CG, and CH. The 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.
A highly flexible connection is possible.

Each device has its own unique ID and recognizes each other to form a single network in a range connected by a 1394 serial bus. One 1394 connection between each digital device
Just by sequentially connecting with a serial bus cable, each device plays a role of relay, and constitutes one network as a whole. In addition, it has a function of automatically recognizing the device and recognizing the connection status when the cable is connected to the device by the 1394 serial bus and the Plug & Play function.

In the system shown in FIG. 1, when a certain device is deleted from the network or newly added, the bus is automatically reset, and the network configuration up to that time is reset. From
Rebuild a new network. With this function, the configuration of the network at that time can be constantly set and recognized.

The data transfer rate is 100/200 /
It has a transmission rate of 400 Mbps, and a device having a higher transfer rate supports a lower transfer rate and is compatible.

The data transfer mode includes asynchronous data such as a control signal (hereinafter referred to as asynchronous data).
Asyncro that transfers Async data)
Nous transfer mode and real-time synchronous data such as video data and audio data (Isochronous data:
Hereafter, it is called Iso data.
There is a nous transfer mode. This Async data and I
so data is in each cycle (usually 125 μS per cycle)
After the transfer of the cycle start packet (CSP) indicating the start of the cycle, the transfer of the Iso data is prioritized over the Async data, and is transferred in the same cycle.

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

The 1394 serial bus has a layer (layer) structure as a whole. As shown in FIG.
There is a connector port for connecting a connector and a cable of the 1394 serial bus, and a physical layer and a link layer are positioned as hardware on the connector port.

The hardware part is a substantial part of an interface chip, of which the physical layer performs coding and control related to connectors, and the link layer performs packet transfer and cycle time control.

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

The hardware and firmware up to this point constitute the substantial structure of the 1394 serial bus.

The software application
The layer differs depending on the software to be used, and is a part for specifying how data is to be loaded on the interface. For example, a printer and an AVC protocol are specified.

The above is the configuration of the 1394 serial bus.

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

Each device (node) connected to the 1394 serial bus must have a 64-bit address unique to each node. By storing this address in the ROM, it is possible to always recognize the node address of oneself and the other party, and perform communication specifying the other party.

The addressing of the 1394 serial bus is based on the IEEE 1212 standard, and the first 10 bits are used for specifying the bus number.
The next 6 bits are used for specifying the node ID number. The remaining 48 bits become the address width given to the device,
Each can be used as a unique address space. The last 28 bits store information such as identification of each device and designation of use conditions as an area of unique data.

The above is the outline of the technology of the 1394 serial bus.

Next, the technology that can be said to be a feature of the 1394 serial bus will be described in more detail.

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

FIG. 4 is a sectional view of a 1394 serial bus cable.

In the 1394 serial bus, a power supply line is provided in the connection cable in addition to 6 pins, that is, two sets of twisted pair signal lines. As a result, power can be supplied to a device having no power supply, a device whose voltage has dropped due to a failure, and the like.

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

In the standard called DV cable, the cable is composed of four pins without a power supply.

The DS-Link coding will be described.

Adopted in the 1394 serial bus,
FIG. 5 is a diagram for explaining the DS-Link encoding method of the data transfer format.

In the 1394 serial bus, DS-Lin
The k (Data / Strobe Link) coding method is adopted. This DS-Link coding scheme is suitable for high-speed serial data communication, and its configuration requires two signal lines. The main data is sent to one of the twisted pairs, and the strobe signal is sent to the other twisted pair. On the receiving side, the clock is reproduced by taking the exclusive OR of the transmitted data and the strobe.

Advantages of using the DS-Link encoding method include higher transfer efficiency as compared with 8 / 10B conversion, and the need for a PLL circuit, thus eliminating the need for a controller LSI.
Power consumption because the transceiver circuit of each device can be put into a sleep state because there is no need to send information indicating that the device is in an idle state when there is no data to be transferred. Can be reduced.

The sequence of the bus reset will be described.

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

When there is a change in the network configuration, for example, a change occurs due to an increase or decrease in the number of nodes due to insertion / removal of a node or power ON / OFF, etc., and when a new network configuration needs to be recognized, the change is made. Each detected node sends a bus reset signal on the bus,
Enter the mode to recognize the new network configuration.

At this time, a change is detected by detecting a change in the bias voltage on the 1394 port board.

When a bus reset signal is transmitted from a certain node, the physical layer of each node transmits the bus reset signal to the link layer at the same time as receiving the bus reset signal, and transmits the bus reset signal to another node. . After all the nodes finally detect the bus reset signal, the bus reset is activated.

The bus reset is also activated by the above-described activation by hardware insertion / removal due to cable disconnection or network abnormality or the like, and also by directly issuing a command to the physical layer by host control from a protocol or the like. Further, when the bus reset is activated, the data transfer is suspended, the data transfer during this period is waited, and after the end, the data transfer is resumed under a new network configuration.

The above is the bus reset sequence.

The sequence for determining the node ID will be described.

After the bus reset, each node enters an operation of giving each node an ID in order to construct a new network configuration. At this time, from the bus reset to the node I
A general sequence up to the determination of D will be described with reference to the flowcharts of FIGS.

The flowchart of FIG. 6 shows a series of bus operations from the occurrence of a bus reset until the node ID is determined and data transfer can be performed.

First, as step S101, the occurrence of a bus reset in the network is constantly monitored. If a bus reset occurs due to power ON / OFF of a node, the process proceeds to step S102.

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

After the route is determined in step S104, the operation of setting a node ID for giving an ID to each node is performed in step S105. Node IDs are set in a predetermined node order, and I
The setting operation is repeatedly performed until D is given. When the IDs are finally set in all the nodes in step S106, the new network configuration is recognized in all the nodes. And data transfer is started.

In the state of step S107, a mode for monitoring the occurrence of a bus reset again is entered.
When the bus reset occurs, the setting operation from step S101 to step S106 is repeatedly performed.

The above is the description of the flowchart of FIG. 6. The flowchart from FIG. 6 shows a portion from the bus reset to the route determination and a procedure from the route determination to the end of the ID setting in a more detailed flowchart. Are shown in FIGS. 7 and 8, respectively.

First, the flowchart of FIG. 7 will be described.

When a bus reset occurs in step S201, the network configuration is reset once. The occurrence of a bus reset is constantly monitored in step S201.

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

In accordance with the result of the number of ports in step S204, the number of undefined (undetermined parent-child) ports is checked 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. However, as the parent-child relationship is determined, the number of undefined ports detected in step S204 changes.

First, immediately after a bus reset, only a leaf can declare a parent-child relationship. A leaf can be known by checking the number of ports in step S203. In step S205, the leaf declares "I am a child and the other is a parent" to the node connected thereto, and ends the operation.

A node which has a plurality of ports in step S203 and is recognized as a branch has an undefined port number> 1 in step S204 immediately after the bus reset.
Moving to step S206, a flag of branch is first set, and in step S207, the process waits for reception of "parent" in the parent-child relationship declaration from the leaf.

The leaf declares a parent-child relationship, and the branch that has received the declaration in step S207 appropriately returns to step S20.
Confirm the number of undefined ports of 4 and find that the number of undefined ports is 1
If it becomes, it becomes possible to declare “I am a child” in step S205 for the node connected to the remaining port. After the second time, step S204
Even if the number of undefined ports is checked in step S207, for a branch having two or more ports, the process waits again in step S207 to accept a "parent" from a leaf or another branch.

Finally, if any one of the branches or exceptionally leaves (because they did not operate quickly enough to make a child declaration) become zero as a result of the number of undefined ports in step S204, In this case, the declaration of the parent-child relationship of the entire network has been completed, and the only node for which the number of undefined ports has become zero (all are determined as parent ports) is flagged as a root in step S208, and the root is set in step S209 Is recognized.

In this manner, the steps from the bus reset shown in FIG. 7 to the declaration of the parent-child relationship between all the nodes in the network are completed.

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

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

As a task of assigning an ID to each node, an ID can be set first from the leaf. The IDs are set in ascending order of leaf → branch → route (node number = 0).

In step S302, the number N (N is a natural number) of leaves existing in the network is set.

Thereafter, in step S303, each leaf requests the root to give an ID. If there are a plurality of such requests, the route is determined in step S304.
Arbitration is performed, and an ID number is given to one winning node in step S305, and a failure result is notified to the losing node.

At step S306, the leaf whose ID acquisition has failed fails issues an ID request again and repeats the same operation. Step S30 from the leaf whose ID has been acquired
In step 7, the ID information of the node is transferred to all nodes by broadcast. When the broadcasting of the one-node ID information ends, the number of remaining leaves is reduced by one in step S308.

Here, as step S309, when the number of the remaining leaves is one or more, the I in step S303
The operation from the request of D is repeated, and finally, when all the leaves broadcast the ID information, step S
309 becomes N = 0, and the process proceeds to the branch ID setting. The branch ID setting is performed in the same manner as in the leaf setting.

First, at step S310, the number M (M is a natural number) of branches existing in the network is set.

Thereafter, in step S311, each branch requests the root to give an ID.
On the other hand, for the route, arbitration is performed in step S312, and the branch is given in order from the winning branch to the next youngest number given to the leaf.

In step S313, the root notifies the branch that issued the request of ID information or a failure result. In step S314, the branch whose ID acquisition has failed fails issues an ID request again and repeats the same operation.

Step S from the branch from which the ID was obtained
At 315, the ID information of the node is transferred to all nodes by broadcast.

When the broadcast of the one node ID information ends, the number of remaining branches is reduced by one in step S316.

Here, in step S317, when the number of the remaining branches is one or more, the operation from the ID request in step S311 is repeated, and the process is repeated until all the branches finally broadcast the ID information.
When all the branches have acquired the node IDs, M = 0 in step S317, and the branch ID acquisition mode ends.

At this point, since only the root node has not acquired the ID information at the end, step S
318 is set as the own ID number among the unassigned numbers, and the root I
Broadcast D information.

As described above, the procedure from the determination of the parent-child relationship to the setting of the IDs of all the nodes is completed as shown in FIG.

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

As shown in FIG. 9, a node A and a node C are directly connected below the (root) node B, and a node D is directly connected below the node C.
Further, below the node D, there is a hierarchical structure in which the nodes E and F are directly connected. The procedure for determining the hierarchical structure, the root node, and the node ID will be described below.

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

In FIG. 9, the node A first declares the parent-child relationship after the bus reset. Basically, a node (called a leaf) having a connection to only one port of the node can declare a parent-child relationship. Since the user can first know that only one port is connected, it recognizes that this is the edge of the network, and the parent-child relationship is determined from the node that operates earlier in the network. In this manner, the port on the side that has declared the parent-child relationship (node A between AB) is set as a child, and the port on the other side (node B) is set as a parent.
Thus, a child-parent is determined between nodes AB, a child-parent is determined between nodes ED, and a child-parent is determined between nodes FD.

Further, one level up, the nodes having a plurality of connection ports (referred to as branches) are successively further declared the parent-child relationship from the node which received the declaration of the parent-child relationship from another node. To go. In FIG. 9, first, the parent-child relationship between the node D and the node D-F is determined, and then the parent-child relationship is declared for the node C. As a result, the node D is determined as the child-parent between the nodes D and C. ing.

The node C receiving the parent-child relationship declaration from the node D becomes the node B connected to another port.
Declares a parent-child relationship. As a result, a child-parent is determined between the nodes C and B.

In this way, a hierarchical structure as shown in FIG. 9 is formed, and the node B that has become the parent in all finally connected ports is determined as the root node. There is only one route in one network configuration.

In FIG. 9, node B is determined to be the root node. Node B, which has received a parent-child relationship declaration from node A, makes a parent-child relationship declaration for 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 transmission timing, and the root node is not always constant even in the same network configuration.

When the root node is determined, the process enters a mode for determining each node ID. Here, all nodes notify their determined node IDs to all other nodes (broadcast function).

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

As a procedure for assigning node ID numbers, first, a node (leaf) having connection to only one port can be started, and node numbers = 0, 1, 2,... Assigned.

The node that has acquired the node ID broadcasts information including the node number to each node. Thereby, it is recognized that the ID number is “assigned”.

When all the leaves have acquired their own node IDs, the next step is to move to a branch, and the node ID number following the leaf is assigned to each node. Similarly 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 its own ID information. That is, the root always owns the maximum node ID number.

As described above, the assignment of the node IDs of the entire hierarchical structure is completed, the network configuration is reconstructed, and the bus initialization operation is completed.

The arbitration will be described.

In the 1394 serial bus, arbitration (arbitration) of the right to use the bus must be performed before data transfer.
Perform Since the 1394 serial bus is a logical bus-type network in which each device connected individually relays the transferred signal to transmit the same signal to all devices in the network, packet collision occurs. Arbitration is necessary to prevent
This allows only one node to transfer at a given time.

As a diagram for explaining arbitration, FIG. 10A shows a bus use request diagram, and FIG. 10B shows a bus use permission diagram.

When the arbitration starts, one or more nodes issue a bus use request to the parent node. Nodes C and F in FIG. 10A are nodes that have issued a bus use right request. The parent node (node A in FIG. 10) that has received the request further issues (relays) a bus use request toward the parent node. This request is finally delivered to the arbitration route.

The root node that has received the bus use request determines which node is to use the bus. This arbitration work can be performed only by the root node, and the node that has won the arbitration is given permission to use the bus. FIG.
In (b), use permission is given to the node C, and use of the node F is rejected.

A DP (data prefix) packet is sent to the node that has lost the arbitration to notify that the node has been rejected. The rejected node use request waits until the next arbitration.

As described above, the node that has won the arbitration and obtained the bus use permission can start transferring data thereafter.

Here, a series of arbitration flows will be described with reference to a flowchart shown in FIG.

In order for a node to be able to start data transfer,
The bus must be idle. In order to recognize that the data transfer that has been performed earlier is completed and that the bus is currently idle, a predetermined idle time gap length that is individually set in each transfer mode (for example,
Each node determines that its own transfer can be started by passing the subaction gap).

In step S401, it is determined whether a predetermined gap length corresponding to each data to be transferred, such as Async data and Iso data, has been obtained. Unless the predetermined gap length is obtained, the request for the right to use the bus required to start the transfer cannot be made, so the process waits until the predetermined gap length is obtained.

If a predetermined gap length is obtained in step S401, it is determined in step S402 whether there is data to be transferred. If so, a request for a bus use right is issued in step S403 to secure a bus for transfer. 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,
Wait as it is.

Next, when one or more bus use requests of step S403 are received by the route in step S404, the route checks the number of nodes that have issued use requests in step S405.

In step S405, the selection value is the number of nodes =
If it is 1 (the number of nodes that issued the use right request is one), that node is immediately given the bus use permission.
If the selection value in step S405 is the number of nodes> 1 (the number of nodes that issued a use request is plural), the root
As 406, an arbitration operation for deciding one node to be permitted to use is performed. This arbitration work is fair, and the same node does not always obtain permission each time, and it is structured to give equal rights (Fair
arbitration).

As step S407, step S40
At step 6, the node arbitrates the route from among the plurality of nodes that have issued the use request and selects one node whose use has been granted and another node that has lost. Here, for one node that has been arbitrated and has obtained use permission, or a node that has obtained use permission without arbitration with the number of use request nodes = 1 from the selection value in step S405, the route is set to that node as step S408. A permission signal is sent to it.

The node that has received the permission signal starts transferring data (packets) to be transferred immediately after receiving the permission signal. In addition, the node that has lost the arbitration in step S406 and is not permitted to use the bus uses the DP (data prefi?
x) The packet is sent, and the node receiving the packet sends a bus use request to perform the transfer again, so that the node
It returns to 401 and waits until a predetermined gap length is obtained.

The above is the description of the flowchart of FIG. 11 for explaining the flow of arbitration.

A description will now be given of an asynchronous transfer.

Asynchronous transfer is asynchronous transfer. FIG. 12 shows a temporal transition state in the 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 desiring transfer determines that the bus can be used and executes arbitration for acquiring the bus.

When the bus use permission is obtained by arbitration, the data transfer is executed in the form of a packet.
After the data transfer, the receiving node sets an ask (reception confirmation return code) of the reception result for the transferred data to a
After a short gap of sk gap, the transfer is completed by sending back a response or sending a response packet. Ask is composed of 4-bit information and 4-bit checksum, and includes information such as success, busy status, and pending status, and is immediately returned to the source node.

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

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

Asynchronous transfer is one-to-one communication from a self-node to a partner node. The packet transferred from the transfer source node is distributed to each node in the network, but the address other than its own address is ignored, so that only one destination node reads the packet.

The above is the description of the asynchronous transfer.

The Isochronous (synchronous) transfer will be described.

The isochronous transfer is a synchronous transfer. 1
This isochronous transfer, which can be said to be the greatest feature of the 394 serial bus, is a transfer mode suitable for transferring data requiring real-time transfer, such as multimedia data such as video data and audio data.

Also, when the asynchronous transfer (asynchronous) is 1
Unlike the one-to-one transfer, the isochronous transfer is uniformly transferred from one transfer source node to all other nodes by the broadcast function.

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

The isochronous transfer is executed on the bus at regular intervals. This time interval is called an isochronous cycle. The isochronous cycle time is 125 μS. A cycle start packet indicates the start time of each cycle, and plays a role of adjusting the time of each node. A node called a cycle master transmits a cycle start packet, and after a transfer in a previous cycle is completed, a predetermined idle period (subaction gap) is passed, and then the start of this cycle is announced. Send a cycle start packet.

The time interval at which the cycle start packet is transmitted is 125 μS.

FIG. 14 shows channels A, B,
As indicated by the channel C, a plurality of types of packets can be separately transferred by being given channel IDs in one cycle. This allows real-time transfer between a plurality of nodes at the same time, and the receiving node fetches only the data of the channel ID desired by itself. The channel ID does not represent the address of the transmission destination, but merely gives a logical number for the data. Therefore, the transmission of a certain packet is 1
From one source node to all other nodes,
It will be transferred by broadcast.

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

The iso gap (isochronous gap) shown in FIG. 14 indicates an idle period necessary for recognizing that the bus is empty before performing the isochronous transfer. After the predetermined idle period has elapsed, a node that wishes to perform isochronous transfer determines that the bus is free, and can perform arbitration before transfer.

Next, an example of a packet format for isochronous transfer will be described with reference to FIG.

Each packet divided into each channel has a header portion in addition to a data portion and data CRC for error correction, and the header portion has a transfer data length and a channel number as shown in FIG. , And other various codes, a header CRC for error correction, and the like are written and transferred.

The above is the description of the isochronous transfer.

Next, the bus cycle will be described.

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

The isochronous transfer is executed prior 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 (subaction gap) of the idle period required to start the asynchronous transfer. . Therefore, the isochronous transfer is executed with priority over the asynchronous transfer.

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, and after waiting for a predetermined idle period (isochronous gap), the node that should perform isochronous transfer performs arbitration and starts packet transfer. In FIG. 16, channel e, channel s, and channel k are sequentially and isochronously transferred.

After the operations from the arbitration to the packet transfer are repeatedly performed for the given channels, when all the isochronous transfers in the cycle #m are completed, the asynchronous transfer can be performed.

When the idle time reaches the sub-action gap in which asynchronous transfer is possible, it is determined that the node that wishes to perform asynchronous transfer can shift to execution of arbitration.

However, during the period in which the asynchronous transfer can be performed, a subaction gap for starting the asynchronous transfer is obtained after the completion of the isochronous transfer until the time (cycle synch) at which the next cycle start packet should be transferred. Only when they are given.

In cycle #m in FIG. 16, two packets (packet 1 and packet 2) of isochronous transfer for three channels and then asynchronous transfer (including ack) are performed.
Has been transferred. After this asynchronous packet 2, the time to start cycle m + 1 (cycle sync + 1)
h), the transfer in cycle #m ends here.

However, the time (cy) to transmit the next cycle start packet during asynchronous or synchronous transfer operation
If cle synch is reached, the cycle start packet of the next cycle is transmitted after waiting for an idle period after the transfer is completed without forcibly interrupting the transfer. That is, when one cycle continues for 125 μS or more, it is assumed that the next cycle is shortened by the corresponding amount. Thus, the isochronous cycle is 125 μS
Can be exceeded or shortened based on the standard.

However, the isochronous transfer is always executed if necessary every cycle in order to maintain the real-time transfer, and the asynchronous transfer may be transferred to the next and subsequent cycles due to the shortened cycle time. The information including such delay information is managed by the cycle master.

Therefore, the first embodiment will be described first.

FIG. 17 is a diagram best showing the features of the present invention. In FIG.
Compared with each layer of the OSI model used in AN, the physical layer 1 and the data link layer 2 of the OSI model
Physical layer, which is the lower layer 4 of the 394 interface
The upper layer 3 corresponding to the link layer and present 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 includes
It operates between the lower layer 4 of the 394 interface and the transport protocol 5.

In this embodiment, LOGIN is applied to a device conforming to the serial bus protocol (SBP-2) 8.
By inserting the protocol, it is possible to notify the partner device that he / she wants to exchange data using a protocol conforming to SBP-2. In a third embodiment described later, the LOGIN protocol is also inserted for the device protocol 9 specialized on the 1394 interface, so that each device determines whether the protocol is supported and determines whether the protocol is supported. Can interact.

FIG. 18 is a diagram showing the basic operation of the LOGIN protocol. When the printer executes the print task 10, the printer first uses the LOGIN protocol to prepare the printer protocol A, B, C prepared by the printer. The printing operation is performed in accordance with the determined protocol. That is,
For devices that support several printer protocols on the printer side, when connecting to the target, the protocol of the partner device is first determined using the LOGIN protocol, and the printer uses the printer protocol that matches the partner protocol. Is selected from among a plurality of printers, and print data and commands are exchanged according to the selected protocol to perform print processing.

FIG. 19 shows a LOG in this embodiment.
FIG. 3 is a diagram illustrating a connection form of each device in a 1394 interface implementing an IN protocol, and a LOG for a printer 11 corresponding to a plurality of printer protocols.
When a device (PC 12, scanner 13, VCR 14, etc.) implementing the IN protocol is connected, the LOGI
By switching the printer protocol on the printer side according to the transport protocol of the partner using the N protocol, it is possible to process the printing task from each device without any problem.

FIG. 20 shows the flow of the login operation.

First step:-Lock the device (in this case, a multi-protocol printer)-Obtain the capabilities of the printer (accepting protocols, etc.) These capabilities are stored in a register 503 described later. -Set the host's capabilities to the printer. Second step:-Communication of print data using the protocol determined in the first step.-Third step:-Disconnect the connection between the printer and the host.

FIG. 21 shows a LOG in this embodiment.
FIG. 4 shows the CSR of the 1394 serial bus provided in the printer for the IN protocol. In the drawing, 501 is a lock register (lock), and 502 is a protocol register (pro)
tocol) and 503 are capability registers (ca
). These registers are 139
4 It is arranged at a predetermined address in the initial unit space in the address space of the serial bus. The lock register 501 indicates the locked state of the resource. A value of 0 indicates a state in which the user can log in, and a value other than 0 indicates that the user is already logged in the locked state. The capability register 503 indicates a settable protocol. Each bit corresponds to a protocol. A bit value of 1 indicates that the protocol can be set, and a value of 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 format of a printer map in a network (1394 network) constituted by a 1394 serial bus.

This printer map stores the unique ID (Unique ID), the node ID (Node ID), the status (Status), and the capability (Capability) of the printer node that has returned the response. The status here indicates, for example, the content of the protocol register 502 in FIG. 21 and the like.
y) is, for example, the capability register 50 of FIG.
3 is shown.

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

FIG. 24 is a diagram showing a format of a command for creating a printer map (FIG. 22). This command is notified to the target by a write transaction of an asynchronous packet.

In this protocol, a command as shown in FIG. 24 is arranged at a predetermined address in the target unit space in the 1394 address space.

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

Here, various devices are usually connected to the nodes of the network. Under such circumstances, when the initiator (host) attempts to output a printer, it is necessary to know to which node the printer is connected. Also, in order to obtain an appropriate output of the printer, it is very convenient to know in advance the physical location of the printer, its capabilities, its available capacity, and the like.

Therefore, in this embodiment, the printers connected to the same network are checked. For example,
At the time of output of the printer, the initiator (host) obtains information on the printer on the network, such as the physical location, capability, and spare capacity as described above (hereinafter, also referred to as topology / capability information), and prepares a printer map in advance. A target printer is selected based on the printer map.

Hereinafter, the printer map creation processing on the host side will be described with reference to FIG.

First, the host side prints a printer map (FIG. 2).
In order to create 2), the creation command (FIG. 24) is broadcasted (step S3001), and the process waits for reception of a response command from the target printer (step S3002).

Upon receiving the response command from the target, the host reads the contents of the protocol register and capability register of the target that has returned the response command (step S3003). As a result, the host recognizes the capabilities and states of the target.

Then, the host determines in step S3003
A printer map is created for the printer on the current 1394 network based on the information obtained in step S3004 (step S3004).

FIG. 26 is a flowchart showing the processing on the target side, ie, the printer side, during the printer map creation processing on the host side.

First, the printer presents a status and capabilities from the time of power-on (step S310).
1). Specifically, for example, the setting process of the protocol register and the capability register is performed according to the current capability and status of the own printer. Therefore, a change in the status and capabilities inside the printer reflects the status and capabilities in this step in the presentation.

Next, the printer waits for a printer map creation command from the host (step S3102).

Upon receiving the printer map creation command from the host, the printer returns a response command to the command to the host (step S31).
03).

FIG. 27 is a flowchart on the host side of the login processing.

In order to start login, after the printer map creation processing (step S600) shown in FIG. 25, the lock register 5 of the printer to be logged in
01, the protocol register 502 and the capability register 503 are confirmed by a read transaction.
Here, it is confirmed from the contents of the capability register 503 whether or not the printer supports a protocol used for communication by the host (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,
Assumes that another device is logged in and cancels the login. If the login register 501 is 0, it is considered that login is possible at present (step 602).

If the login is possible, the process proceeds to the resource lock process, where 1 is written to the lock register 501 of the printer using a lock transaction, and the login setting on the host side is set (step 603). In this state, the printer is locked, and output from other devices is not possible. It is also impossible to change the register.

With the resources of the printer locked as described above, the protocol is set next. Since the printer according to the present embodiment supports a plurality of print protocols, it must know the protocol on the host side before receiving print data. Here, a means is used in which the host side notifies the protocol register 502 of the printer by writing a bit corresponding to a protocol to be used from now on (step 604).

At this point, the protocol used by the host for communication is notified to the printer, and the printer is locked, so that the currently logged-in host transmits print data using the normal protocol (step 60).
5).

When the transmission of the print data is completed, the host clears the lock register 501, the protocol register 502, and the capability register 503 of the printer to log out of the printer (step 606).

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

After the printer map creation processing (step S700) shown in FIG. 26, the printer is normally in a state of waiting for login from the host. The print request from the host is transmitted to the lock register 501, the protocol register 502, and the capability register 503 of the printer.
, The register is always kept readable from another device.
It is now assumed that the host that intends to execute printout locks the printer (step 701).

After the printer is locked by writing to the lock register 501, the host waits for a notification of a protocol to be used from the host (step 702). Waiting for the protocol notification after the lock status is reached during login and by a request from another device,
This is to prevent the protocol register 502 from being rewritten.

When the printer is notified of the protocol, the printer switches the protocol to be accepted by itself, and communicates with the host (steps 703 to 710).

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).

Next, a second embodiment will be described.

In the first embodiment, 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. Then, a target printer is selected based on the printer map. However, in the second embodiment,
When a host and a printer both support multiple protocols on a 1394 network, and more than one such printer is connected, the host examines the available protocols of each printer, takes a majority decision, and supports the most. Determine which protocol is being used.

Since the second embodiment is the same as the first embodiment except for the processing shown in FIGS. 25 and 26, the detailed description is omitted.
Only the differences from the first embodiment will be specifically described.

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

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 connected to the same network. If connected, the initiator and target must of course use the same protocol, but to determine which protocol to use now, the initiator examines the available protocols for each printer and takes a majority vote. , Use the most supported protocol.

As described above, by configuring so that a majority decision is made in a situation where many protocols are available, the types of protocols actually used can be reduced, and as a result, the load imposed by the protocol switch of the initiator can be reduced. Can be lowered.

Hereinafter, referring to FIGS. 29 and 30, the initiator side (host side) and the target side (printer side) will be described.
The printer map creation processing (relative majority protocol determination printer map processing) will be described.

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

Upon receiving the response command from the target, the host reads the contents of the protocol register and capability register of the target that has returned the response command (step S3203). As a result, the host recognizes the capabilities and states of the target.

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

Next, the host checks the available protocols of the multi-protocol printer currently connected to the network from the printer map created in step S3204, and among these protocols, the host supports the most. Select a protocol (Step S
3205).

Then, the host determines in step S3205
The protocol selected in is notified to each printer as a protocol notification command (step S3206).

On the other hand, the printer first presents the status and capabilities from the time of power-on (step S
3301). Specifically, for example, the setting process of the protocol register and the capability register is performed according to the current capability and status of the own printer. Therefore, changes in status and capabilities inside the printer
The status and capabilities in this step are also reflected in the presentation.

Next, the printer waits for reception of a printer map creation command from the host (step S3302).

Next, upon receiving the printer map creation command from the host, the printer returns a response command to the command to the host (step S330).
3).

Next, the printer waits for a protocol notification command from the host (step S3).
402).

Upon receiving the protocol notification command from the host, the printer returns a response command to the command to the host (step S350).
3).

Next, a third embodiment will be described.

FIG. 31 is a diagram showing the operation in this embodiment. Compared with the first embodiment shown in FIG. 2, protocol D which does not implement the LOGIN protocol is also supported. The feature is that it is. That is, not only for the target having the LOGIN protocol, but also for the existing protocol D (for example, AV / C
In order to guarantee the printing operation even for a device that supports only the protocol, the printer side adds a printer protocol corresponding to the device that does not have the LOGIN protocol.

This operation will be described. When the printer recognizes that the target does not support the LOGIN protocol by the conversation based on the LOGIN protocol performed at the beginning of the connection, the printer communicates with the target using the other protocol D. When a conversation is established, a printing task in accordance with the protocol D can be executed.

FIG. 32 shows the OSI in this embodiment.
FIG. 6 is a diagram showing a comparison with a model, and in this embodiment, the current AV / AV not implementing the LOGIN protocol;
The model is a printer conforming to the C protocol.
Example 4 shows that the current protocol is not yet defined,
This shows a case where a protocol that does not have the function of the LOGIN protocol created for the scanner is installed. That is, if the printer can handle a protocol that does not implement the LOGIN protocol, the type of target device to be connected can be varied.

In the above-described embodiment, the printer is mainly described as a device on the network. However, the present invention is not limited to this, and may be a monitor, a computer, a digital camera, or the like, and is limited to a specific type of device. is not.

In addition, step S600 in FIG.
Step S700 of FIG. 29 and Step S3201 of FIG.
In the creation of the printer map, the topology connection state is examined, for example, as shown in FIG. 9, and a display map is created. By determining such a topology connection state, it is not merely a majority decision but a topology connection state. Can be used to determine the actual protocol to be used.

The present invention may be applied to a system composed of a plurality of devices as shown in FIG. 19 or to a data processing method in a device composed of one device.

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

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.

As a storage medium for supplying the program code, for example, a floppy disk, hard disk, optical disk, magneto-optical disk, CD-ROM, C
DR, magnetic tape, nonvolatile memory card, ROM
Etc. can be used.

By executing the program code read by the computer, not only the functions of the above-described embodiment are realized, but also an OS or the like running on the computer based on the instruction of the program code. Performs part or all of the actual processing, and the processing realizes the functions of the embodiments.

Further, after the program code read from the storage medium is written in a memory provided in an expansion board inserted into the computer or a function expansion unit connected to the computer, based on the instruction of the program code, The CPU provided in the function expansion board or function expansion unit performs part or all of the actual processing,
It goes without saying that the processing may realize the functions of the above-described embodiments.

[0202]

As described above, according to the present invention, it is possible to provide a data processing method, a data processing device, a printer, and a storage medium with high expandability. In particular, since it is possible to support a plurality of types of printer protocols, the scalability is extremely high. Further, by investigating the printers connected to the same network, the target printer can be selected, so that an optimum printer output can be obtained. Furthermore, even when many protocols are available, the type of protocol that is actually used can be reduced by determining the most supported protocol from the printer among those protocols. In addition, the load caused by switching to the protocol on the host side can be reduced.

[Brief description of the drawings]

FIG. 1 is a diagram illustrating an example of a communication system using an IEEE 1394 cable.

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

FIG. 3 is a diagram showing IEEE 1394 addresses.

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

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

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

FIG. 7 is a flowchart illustrating a route determination method.

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

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

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

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

FIG. 12 is a diagram for describing 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 transfer.

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

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 a basic operation of the LOGIN protocol.

FIG. 19 is a diagram illustrating a connection form of each device in a 1394 interface implementing the LOGIN protocol.

FIG. 20 is a diagram illustrating a flow of a login operation.

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

FIG. 22 is a diagram illustrating a printer map in the 1394 network.

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

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

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

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

FIG. 27 is a flowchart illustrating a host-side process of a login process.

FIG. 28 is a flowchart for explaining the printer-side processing of the login processing.

FIG. 29 is a flowchart illustrating a printer map creation process on the host side according to the second embodiment.

FIG. 30 is a flowchart for describing printer map creation processing on the printer side according to the second embodiment.

FIG. 31 is a diagram for describing a system operation according to the third embodiment.

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

[Explanation of symbols]

 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

Claims (35)

[Claims] 1. A data processing method for switching a protocol of a plurality of types of devices via a common serial bus, comprising: executing an initial protocol irrespective of a type of a protocol of the device; A data processing method for executing a plurality of types of device-specific protocols, wherein the initial protocol includes a first investigation process for investigating a topology connection state of the same network by the common serial bus. 2. The method according to claim 2, wherein the initial protocol further includes a second investigation process for investigating a function of the device, a topology connection status obtained in the first investigation process, and a plurality of the plurality of initial connection protocols obtained in the second investigation process. 2. The data processing method according to claim 1, further comprising a step of determining a protocol to be executed based on the protocol. 3. The data processing method according to claim 1, wherein the first checking process includes a process of obtaining information including a status and a capability of a printer as a device. 4. The data processing method according to claim 3, wherein the protocol of the printer is a protocol for an ink jet printer. 5. The data processing method according to claim 3, wherein image data to be printed is transmitted after the execution of the printer-specific protocol. 6. The data processing method according to claim 5, wherein said image data is data photoelectrically converted by an imaging unit. 7. The device according to claim 1, wherein said common serial bus is an IEEE13.
2. The data processing method according to claim 1, wherein the bus conforms to the 94 standard. 8. The data processing method according to claim 1, wherein the common serial bus is a bus conforming to a USB standard. 9. The data processing method according to claim 1, wherein the initial protocol is a protocol executed in a layer higher than a data link layer of an OSI model. 10. A data processing apparatus for switching a protocol of a plurality of types of devices via a common serial bus, wherein the first execution unit executes an initial protocol irrespective of a type of a protocol of the device. Second execution means for executing the plurality of types of device-specific protocols following the initial protocol, wherein the initial protocol performs a first investigation process for investigating a topology connection state of the same network by the common serial bus. A data processing device characterized by including. 11. The initial protocol further includes a second investigation process for investigating a function of the device, a topology connection state obtained in the first investigation process, and a plurality of pieces of information obtained in the second investigation process. 11. The data processing device according to claim 10, further comprising: a process of determining a protocol to be executed based on the protocol. 12. The data processing apparatus according to claim 10, wherein the first investigation processing includes a processing for obtaining information including a status and a capability of a printer as a device. 13. The data processing apparatus according to claim 12, wherein the protocol of the printer is a protocol for an ink jet printer. 14. The apparatus according to claim 10, wherein said second execution means transmits image data to be printed after executing a protocol specific to a printer as a device.
The data processing device according to claim 1. 15. The data processing apparatus according to claim 14, further comprising an image pickup unit that supplies the image data obtained by performing the photoelectric conversion to the second execution unit. 16. The device according to claim 1, wherein the common serial bus is an IEEE1
The data processing device according to claim 10, wherein the bus is a bus conforming to the 394 standard. 17. The data processing device according to claim 10, wherein the common serial bus is a bus conforming to a USB standard. 18. The data processing apparatus according to claim 10, wherein the initial protocol is a protocol executed in a layer higher than a data link layer of an OSI model. 19. A printer for switching a protocol of a plurality of types of devices according to a host via a common serial bus, an execution unit for executing an initial protocol irrespective of the type of the protocol, Receiving means for receiving print data after executing a printer-specific protocol, wherein the initial protocol includes a first check process for checking a topology connection state of the same network by the common serial bus. And the printer. 20. The initial protocol further includes a second investigation process for investigating the function of the device, a topology connection state obtained in the first investigation process, and a plurality of topology connections obtained in the second investigation process. 20. The printer according to claim 19, further comprising a step of determining a protocol to be executed based on the protocol. 21. The printer according to claim 19, wherein the first investigation process includes a process of obtaining information including a status and a capability of the printer as a device. 22. The printer according to claim 21, wherein the protocol of the printer is a protocol for an inkjet printer. 23. The printer according to claim 19, further comprising an imaging unit configured to transmit image data obtained by performing photoelectric conversion to the reception unit as the print data. 24. The common serial bus includes an IEEE 1 bus.
20. The printer according to claim 19, wherein the bus conforms to the 394 standard. 25. The printer according to claim 19, wherein the common serial bus is a bus conforming to a USB standard. 26. The printer according to claim 19, wherein the initial protocol is a protocol executed in a layer higher than a data link layer of an OSI model. 27. A computer-readable storage medium storing data processing steps for executing data processing for switching protocols of a plurality of types of devices via a common serial bus, wherein the data processing steps are A first execution step of executing an initial protocol irrespective of a type of a protocol of the device; and a second execution step of executing the plurality of types of device-specific protocols following the initial protocol. The storage medium characterized in that the protocol includes a first investigation process for investigating a topology connection state of the same network by the common serial bus. 28. The initial protocol further includes a second investigation process for investigating a function of the device, a topology connection state obtained in the first investigation process, and a plurality of pieces of information obtained in the second investigation process. 28. The storage medium according to claim 27, further comprising: a process of determining a protocol to be executed based on said protocol. 29. The storage medium according to claim 27, wherein said first investigation process includes a process of obtaining information including a status and capabilities of a printer as a device. 30. The storage medium according to claim 29, wherein the protocol of the printer is a protocol for an inkjet printer. 31. The storage medium according to claim 27, wherein said second execution step includes a step of transmitting image data to be printed after execution of a protocol specific to a printer as a device. 32. The image processing apparatus according to claim 3, wherein the image data is data photoelectrically converted by an imaging unit.
The storage medium according to claim 1. 33. The common serial bus includes an IEEE 1 bus.
The storage medium according to claim 27, wherein the storage medium is a bus conforming to the 394 standard. 34. The storage medium according to claim 27, wherein said common serial bus is a bus conforming to a USB standard. 35. The storage medium according to claim 27, wherein said initial protocol is a protocol executed in a layer higher than a data link layer of an OSI model.