JP3774542B2 - Data processing method, data processing apparatus, printer, and storage medium - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a data processing method, a data processing device, a printer, and a storage medium for switching a plurality of types of printer protocols via a common serial bus.
[0002]
[Prior art]
Conventionally, various types of systems are known as systems for sending data to a printer via a serial bus.
[0003]
For example, a technique for outputting data from a computer to a printer using a de facto standard interface that has been widely used, such as SCSI (Small Computer System Interface) and Centronics, is known.
[0004]
[Problems to be solved by the invention]
However, the conventional printer protocol for transmitting printer data using a serial bus is limited to one unique to the printer manufacturer.
Therefore, the problem of lack of expandability has arisen.
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.
[0005]
Therefore, the present invention has been made to eliminate the above-described drawbacks. When print data is transmitted via a system bus, a highly scalable data processing method, data processing apparatus, printer, and storage medium are provided. The purpose is to provide.
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 apparatus, a printer, and a storage medium suitable for connecting a printer directly from an image data output device without using a computer.
It is another object of the present invention to provide a data processing method, a data processing apparatus, a printer, and a storage medium that can obtain an optimal printer output.
Another object of the present invention is to provide a data processing method, a data processing apparatus, a printer, and a storage medium that can reduce a load caused by switching protocols.
[0006]
[Means for Solving the Problems]
The data processing method of the present invention is a data processing method for switching the protocols of a plurality of devices via a common serial bus, and the same network using the common serial bus by communication of an initial protocol performed between the devices. The first investigation process for investigating the ID of the device and the second investigation process for investigating the protocol unique to the device are executed, and the ID obtained in the first investigation process and the second investigation A protocol to be executed is determined based on the protocol obtained by the processing, and the determined protocol is executed following the initial protocol.
The data processing apparatus of the present invention is a data processing apparatus for switching the protocols of a plurality of devices via a common serial bus, and the same network using the common serial bus by communication of an initial protocol performed with the devices The first execution process for investigating the ID of the device, the first execution means for executing the second investigation process for investigating the protocol specific to the device, and the ID obtained by the first investigation process And a 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 a protocol of a plurality of devices corresponding to a host via a common serial bus, and communicates with the device through an initial protocol communication in the same network using the common serial bus. A first execution unit for executing a first investigation process for examining the ID of the device; a second investigation process for investigating a protocol specific to the device; and the ID obtained by the first investigation process; The apparatus includes: a determination unit that determines a protocol to be executed based on the protocol obtained in the second investigation process; and a second execution unit that executes the determined protocol following the initial protocol. .
A storage medium according to the present invention stores a computer program stored in a computer-readable manner for causing a computer to execute a data processing step for executing a data processing method for switching protocols of a plurality of devices via a common serial bus. The data processing method includes: a first investigation process for examining an ID of the device in the same network using the common serial bus by communication of an initial protocol performed with the device; and A step of executing a second investigation process for investigating a unique protocol, and a 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. And the determined protocol following the initial protocol Characterized by a step of execution.
[0007]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[0008]
Here, first, in the first and second embodiments described below, the IEEE 1394 serial bus is used as a digital I / F for connecting the devices, and therefore the IEEE 1394 serial bus will be described in advance.
[0009]
With the advent of consumer digital VCRs and DVD players, it is necessary to support real-time and high-information data transfer such as video data and audio data. In order to transfer such video data and audio data in real time and transfer them to a personal computer (PC) or other digital devices, an interface capable of high-speed data transfer with the necessary transfer functions is required. An interface developed from such a viewpoint is IEEE 1394-1995 (High Performance Serial Bus) (hereinafter also simply referred to as 1394 serial bus).
[0010]
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, and H. Between A and B, between A and C, between B and D, between D and E, between C and F, A 1394 serial bus twisted pair cable is connected between CG and CH. The devices A to H are, for example, a personal computer, a digital VTR, a DVD, a digital camera, a hard disk, a monitor, a tuner, a monitor, and the like.
[0012]
The daisy chain method and node branch method can be mixed as the connection method between each device.
It can be connected with a high degree of freedom.
[0013]
Each device has its own unique ID, and each device recognizes each other to form one network within a range connected by the 1394 serial bus. By simply connecting each digital device with one 1394 serial bus cable in sequence, each device serves as a relay and constitutes a single 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 with the 1394 serial bus and the Plug & Play function.
[0014]
In addition, in the system as shown in FIG. 1, when a device is deleted from the network or newly added, the bus is automatically reset, the network configuration up to that point is reset, and a new one is added. A reliable network. This function makes it possible to always set and recognize the network configuration at that time.
[0015]
The data transfer rate is 100/200/400 Mbps, and devices with higher transfer rates support lower transfer rates and are compatible.
[0016]
As data transfer modes, asynchronous data such as control signals (Asynchronous data: hereinafter referred to as “Asynchronous data”) and asynchronous data such as real-time video data and audio data (Isochronous data: hereinafter referred to as “Iso data”) are transferred. There is an isochronous transfer mode for transferring The Async data and Iso data are transferred within a cycle (usually 1 cycle 125 μs) after transferring a cycle start packet (CSP) indicating the start of the cycle, and then giving priority to the transfer of Iso data over the Async data. Transferred together.
[0017]
FIG. 2 shows the components of the 1394 serial bus.
[0018]
The 1394 serial bus has a layer structure as a whole. As shown in FIG. 2, there is a connector port to which a cable and a connector of a 1394 serial bus are connected, and a physical layer and a link layer are positioned thereon as hardware.
[0019]
The hardware part is a substantial interface chip part, of which the physical layer performs coding and connector-related control, and the link layer performs packet transfer and cycle time control.
[0020]
The transaction layer of the firmware unit manages data to be transferred (transaction), 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 network configuration.
[0021]
The hardware and firmware are the actual 1394 serial bus configuration.
[0022]
The application layer of the software part differs depending on the software to be used, and is a part that defines how data is loaded on the interface. Printers, AVC protocols, and the like are specified.
[0023]
The above is the configuration of the 1394 serial bus.
[0024]
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 always has 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 itself and the other party, and to perform communication specifying the other party.
[0026]
The addressing of the 1394 serial bus is based on 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 can be used as a unique address space. The last 28 bits are used as a unique data area for storing information for identifying each device and specifying usage conditions.
[0027]
The above is the outline of the technology of the 1394 serial bus.
[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.
[0030]
FIG. 4 shows a cross-sectional view of a 1394 serial bus cable.
[0031]
In the 1394 serial bus, in addition to 6 pins, that is, two pairs of twisted pair signal lines, a power supply line is provided in the connection cable. As a result, it is possible to supply power to devices that do not have a power supply or devices whose voltage has dropped due to a failure.
[0032]
The voltage of the power source flowing in the power line is defined as 8 to 40 V, and the current is defined as the maximum current DC 1.5A.
[0033]
In the standard called DV cable, it is composed of 4 pins without a power source.
[0034]
DS-Link encoding will be described.
[0035]
FIG. 5 is a diagram for explaining the DS-Link encoding method of the data transfer format employed in the 1394 serial bus.
[0036]
In the 1394 serial bus, a DS-Link (Data / Strobe Link) encoding method is adopted. This DS-Link encoding method is suitable for high-speed serial data communication, and its configuration requires two signal lines. Main data is sent to one of the twisted wires, and a strobe signal is sent to the other twisted wire. On the receiving side, the clock is reproduced by taking an exclusive OR of the communicated data and the strobe.
[0037]
Advantages of using this DS-Link encoding method are that transfer efficiency is higher than that of 8 / 10B conversion, the PLL circuit is not required, the circuit scale of the controller LSI can be reduced, and there is no data to be transferred. In some cases, it is not necessary to send information indicating that the device is in an idle state, so that the transceiver circuit of each device can be put in a sleep state, thereby reducing power consumption.
[0038]
A bus reset sequence will be described.
[0039]
In the 1394 serial bus, each connected device (node) is given a node ID and recognized as a network configuration.
[0040]
When there is a change in this network configuration, for example, when a change occurs due to an increase or decrease in the number of nodes due to insertion / extraction of nodes, power ON / OFF, etc. The node enters a mode to recognize a new network configuration by sending a bus reset signal on the bus.
[0041]
The change detection method at this time is performed by detecting a change in bias voltage on the 1394 port board.
[0042]
When a bus reset signal is transmitted from a certain node, the physical layer of each node receives the bus reset signal, and simultaneously transmits the occurrence of the bus reset to the link layer and transmits the bus reset signal to the other nodes. After all nodes have finally detected the bus reset signal, the bus reset is activated.
[0043]
The bus reset is also activated by issuing a command directly to the physical layer by means of hardware detection due to cable insertion / removal or network abnormality as described above, and host control from the protocol.
Further, when the bus reset is activated, the data transfer is temporarily interrupted, and the data transfer during this time is awaited and resumed under a new network configuration after the end.
[0044]
The above is the bus reset sequence.
[0045]
A sequence for 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. A general sequence from bus reset to node ID determination at this time will be described with reference to the flowcharts of FIGS.
[0047]
The flowchart in FIG. 6 shows a series of bus operations from when a bus reset occurs until a node ID is determined and data transfer can be performed.
[0048]
First, in step S101, the occurrence of a bus reset in the network is constantly monitored. If a bus reset occurs due to the power ON / OFF of the node, the process proceeds to step S102.
[0049]
In step S102, in order to know the connection status of the new network from the state where the network is reset, a parent-child relationship is declared between the directly connected nodes. When the parent-child relationship is determined among all the nodes as step S103, one route is determined as step S104. Until the parent-child relationship is determined among 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, a node ID setting operation for giving an ID to each node is performed in step S105. Node IDs are set in a predetermined node order, and the setting operation is repeated until IDs are given to all the nodes. When IDs are finally set for all the nodes in step S106, a new network configuration is set. Is recognized in all the nodes, so that data transfer between the nodes can be performed in step S107, and data transfer is started.
[0051]
In the state of step S107, a mode for monitoring the occurrence of a bus reset is entered again. When a bus reset occurs, the setting operation from step S101 to step S106 is repeated.
[0052]
The above is the description of the flowchart of FIG. 6, and the part from the bus reset to the route determination of the flowchart of FIG. It shows in FIG. 7, FIG.
[0053]
First, the flowchart of FIG. 7 will be described.
[0054]
When a bus reset occurs as step S201, the network configuration is once reset. In step S201, the occurrence of a bus reset is constantly monitored.
[0055]
Next, in step S202, as a first step of re-recognizing the connection status of the reset network, a flag indicating that each device is a leaf (node) is set. In step S203, the number of ports that each device has is connected to other nodes.
[0056]
In accordance with the result of the number of ports in step S204, in order to start the declaration of the parent-child relationship from now on, the number of undefined ports (parent-child relationship is not determined) is examined. 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.
[0057]
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 “it is a child and the other party is a parent” to the node connected to itself, and ends the operation.
[0058]
A node that has a plurality of ports in step S203 and has been recognized as a branch immediately after the bus reset indicates that the number of undefined ports> 1 in step S204. Therefore, the process proceeds to step S206, where a branch flag is set, and in step S207. Wait to accept the “parent” in the parent-child relationship declaration from the leaf.
[0059]
The leaf declares the parent-child relationship, and the branch receiving it in step S207 appropriately checks the number of undefined ports in step S204. If the number of undefined ports is 1, the branch is connected to the remaining port. It is possible to declare “I am a child” in step S205 to a certain node. From the second time, even if the number of undefined ports is confirmed in step S204, for a branch that is 2 or more, it waits again in step S207 to accept a “parent” from a leaf or another branch.
[0060]
Eventually, if any one branch or exceptionally leaf (because it was able to declare a child but didn't work quickly) became zero as a result of the number of undefined ports in step S204, this is the whole network The only node for which the number of undefined ports has become zero (all determined as parent ports) is flagged as a route in step S208 and recognized as a route in step S209. Is made.
[0061]
In this way, the process from the bus reset shown in FIG. 7 to the declaration of the parent-child relationship between all nodes in the network is completed.
[0062]
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, the information is classified in step S301 based on this information.
[0064]
As an operation for assigning an ID to each node, the ID can first be set from the leaf. IDs are set from a young number (node number = 0 to 0) in the order of leaf → branch → root.
[0065]
In step S302, the number N (N is a natural number) of leaves existing in the network is set.
[0066]
Thereafter, in step S303, each leaf requests the root to give an ID. When there are a plurality of requests, the route performs arbitration in step S304, gives an ID number to one winning node in 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. In step S307, the leaf that has obtained the ID broadcasts the ID information of the node to all the nodes. When the one-node ID information is broadcast, the number of remaining leaves is reduced by one in step S308.
[0068]
Here, as step S309, when the number of remaining leaves is 1 or more, the process of the ID request in step S303 is repeated, and finally when all the leaves broadcast the ID information, step S309 returns N = 0. Then, the process proceeds to branch ID setting. The branch ID setting is performed in the same manner as the leaf.
[0069]
First, in step S310, the number M (M is a natural number) of branches existing in the network is set.
[0070]
Thereafter, in step S311, each branch requests the root to give an ID. On the other hand, the route is arbitrated in step S312, and is given from the next young number that has been given to the leaf in order from the winning branch.
[0071]
In step S313, the route notifies the branch that issued the request of the ID information or the failure result. In step S314, the branch that has failed in ID acquisition issues an ID request again and repeats the same operation.
[0072]
In step S315, the ID information of the node is broadcast to all the nodes from the branch that has obtained the ID.
[0073]
When the one-node ID information is broadcast, the number of remaining branches is reduced by one in step S316.
[0074]
Here, as the step S317, when the number of remaining branches is 1 or more, the operation from the ID request operation in the step S311 is repeated until all branches finally broadcast the ID information. When all branches acquire node IDs, M = 0 in step S317, and the branch ID acquisition mode is also terminated.
[0075]
When the process is completed up to this point, the only node that has not obtained ID information is the root, so the lowest number not given in step S318 is set as its own ID number, and the ID information of the route is broadcast in step S319. To do.
[0076]
Thus, as shown in FIG. 8, after the parent-child relationship is determined, the procedure until the IDs of all the nodes are set is completed.
[0077]
Next, as an example, an operation in the actual network shown in FIG. 9 will be described with reference to FIG.
[0078]
In the description of FIG. 9, the nodes A and C are directly connected to the lower level of the (root) node B, the node D is directly connected to the lower level of the node C, and further to the lower level of the node D. A hierarchical structure in which node E and node F are directly connected. The procedure for determining the hierarchical structure, root node, and node ID will be described below.
[0079]
After the bus is reset, first, in order to recognize the connection status of each node, a parent-child relationship is declared between the directly connected ports of each node. It can be said that the parent and child are higher in the hierarchical structure and the child side is lower.
[0080]
In FIG. 9, after the bus reset, it is the node A that first declared the parent-child relationship. Basically, a parent-child relationship can be declared from a node (referred to as a leaf) that has a connection to only one port of the node. Since it can first know that this is only one port connection, it recognizes that it is at the end of the network, and the parent-child relationship is determined from the node that has acted early in it. In this way, the port on the side (Node A between A and B) where the parent-child relationship declaration is made is set as a child, and the port on the other side (Node B) is set as a parent. Thus, the node A-B is determined as the child-parent, the node E-D is determined as the child-parent, and the node FD is determined as the child-parent.
[0081]
Further up one layer, among the nodes having a plurality of connection ports (referred to as “branches”), the declaration of the parent-child relationship is sequentially performed from the node receiving the declaration of the parent-child relationship from another node. In FIG. 9, the node D first declares the parent-child relationship between D-E and DF, and then declares the parent-child relationship for the node C. As a result, the node D-C is determined as a child-parent. ing.
[0082]
The node C that has received the parent-child relationship declaration from the node D declares the parent-child relationship to the node B connected to another port. As a result, the node CB is determined as a child-parent.
[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 finally connected ports is determined as the root node.
Only one route exists in one network configuration.
[0084]
In FIG. 9, node B is determined as the root node. If node B receives a parent-child relationship declaration from node A and issues a parent-child relationship declaration to other nodes at an early timing, The root node may have moved to another node. That is, any node may be a root node depending on the transmission timing, and the root node is not always constant even in the same network configuration.
[0085]
Once the root node is determined, the next mode is to determine each node ID. Here, all nodes notify their determined node IDs to all other nodes (broadcast function).
[0086]
The self ID information includes its own node number, information on the connected position, the number of ports it has, the number of ports connected, information on the parent-child relationship of each port, and the like.
[0087]
As a procedure for assigning node ID numbers, first, a node (leaf) connected to only one port can be activated, and node numbers = 0, 1, 2,.
[0088]
The node having the node ID transmits information including the node number to each node by broadcasting. Thus, it is recognized that the ID number is “allocated”.
[0089]
When all the leaves have acquired their own node IDs, the next step is to branch and the node ID numbers that follow the leaves are assigned to each node. Similarly to the leaf, node ID information is broadcast sequentially from the branch to which the node ID number is assigned, and finally the root node broadcasts self ID information. That is, the route always has the largest node ID number.
[0090]
As described above, assignment of node IDs for the entire hierarchical structure is completed, the network configuration is reconstructed, and bus initialization is completed.
[0091]
Arbitration will be described.
[0092]
In the 1394 serial bus, the bus use right is always arbitrated before data transfer. Since the 1394 serial bus is a logical bus type network in which each individually connected device transmits the same signal to all devices in the network by relaying the transferred signal, packet collision Arbitration is necessary to prevent this. As a result, only one node can be transferred at a certain time.
[0093]
As a diagram for explaining the arbitration, FIG. 10A shows a bus use request diagram in FIG. 10B, and a bus use permission diagram will be described below.
[0094]
When arbitration starts, one or more nodes each issue a bus use right request to the parent node. Node C and node F in FIG. 10A are nodes that have issued a bus use right request. Upon receiving this, the parent node (node A in FIG. 10) issues (relays) a bus use right request to the parent node. This request is finally delivered to the mediation route.
[0095]
The root node that has received the bus use request determines which node uses the bus. This arbitration work can be performed only by the root node, and the node that won the arbitration is given permission to use the bus. FIG. 10B is a diagram in which the use permission is given to the node C and the use of the node F is rejected.
[0096]
A DP (data prefix) packet is sent to the node that lost the arbitration to inform it of the rejection. The rejected node bus use request is waited until the next arbitration.
[0097]
As described above, the node that has won the arbitration and obtained the bus use permission can subsequently start data transfer.
[0098]
Here, a series of arbitration flows will be described with reference to the flowchart of FIG.
[0099]
In order for a node to begin data transfer, the bus needs to be idle. In order to recognize that the previous data transfer has been completed and the bus is currently empty, a predetermined idle time gap length (for example, subaction By passing the gap, each node determines that its transfer can start.
[0100]
In step S401, it is determined whether a predetermined gap length corresponding to data to be transferred, such as Async data and Iso data, has been obtained. As long as the predetermined gap length cannot be obtained, the bus use right required to start the transfer cannot be requested, so the process waits until the predetermined gap length is obtained.
[0101]
If a predetermined gap length is obtained in step S401, it is determined whether there is data to be transferred in step S402. If there is, a request for bus use right is issued to the route so as to secure a bus for transfer in step S403. Depart. 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, the process waits as it is.
[0102]
Next, in step S404, if one or more bus use requests in step S403 are received by the route, the route checks the number of nodes that have issued use requests in step S405.
[0103]
If the selection value in step S405 is the number of nodes = 1 (one node that has issued a usage right request), the bus use permission immediately after that is given to that node. If the selected value in step S405 is the number of nodes> 1 (a plurality of nodes that have made use requests), the route performs an arbitration operation to determine one node to be permitted to use in step S406. This arbitration work is fair, and only the same node does not get permission every time, and the rights are given equally (fair arbitration).
[0104]
In step S407, a selection is made to divide one node that has obtained use permission by arbitrating the route from the plurality of nodes that issued the use request in step S406 and another node that has lost. Here, for one node that has been granted arbitration and obtained use permission, or a node that has obtained use permission without arbitration from the selection value in step S405 without using the requested number of nodes = 1, in step S408, the route is set to that node. In response, a permission signal is sent.
[0105]
The node having obtained the permission signal starts to transfer data (packet) to be transferred immediately after receiving the permission signal. In addition, a DP (data prefix) packet indicating an arbitration failure is sent from the route to the node that has lost the arbitration in step S406 and the bus use is not permitted, and the node that has received the transfer performs the transfer again in step S409. Therefore, the process returns to step S401 and waits until a predetermined gap length is obtained.
[0106]
The above is the description of the flowchart in FIG. 11 that describes the flow of arbitration.
[0107]
Asynchronous transfer will be described.
[0108]
Asynchronous transfer is asynchronous transfer. FIG. 12 shows a temporal transition state in asynchronous transfer.
[0109]
The first subaction gap in FIG. 12 indicates the bus idle state. When the idle time reaches a certain value, the node that desires to transfer determines that the bus can be used, and executes arbitration for acquiring the bus.
[0110]
When the bus use permission is obtained by arbitration, data transfer is executed in the packet format. After the data transfer, the receiving node returns the response (return code for reception confirmation) of the received data with respect to the transferred data by returning it after a short gap called ask gap, or by transmitting a response packet. Is completed. Ask is composed of 4-bit information and a 4-bit checksum, and includes information such as success, busy status, and pending status, and is immediately returned to the source node.
[0111]
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 error correction data CRC, and the header part has a target node ID, a source node ID, a transfer data length, various codes, etc. as shown in FIG. Written and transferred.
[0113]
Asynchronous transfer is one-to-one communication from the self node to the partner node. The packet transferred from the transfer source node is distributed to each node in the network, but since the address other than the address addressed to itself is ignored, only one destination node reads.
[0114]
The above is the description of asynchronous transfer.
[0115]
Isochronous transfer will be described.
[0116]
Isochronous transfer is 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]
Asynchronous transfer (asynchronous) is a one-to-one transfer, but 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]
Isochronous transfer is executed at regular intervals on the bus. This time interval is called an isochronous cycle. The isochronous cycle time is 125 μS. The cycle start packet has a role of indicating the start time of each cycle and adjusting the time of each node. The node that transmits the cycle start packet is a node called a cycle master, and after the end of the transfer in the previous cycle, after passing through a predetermined idle period (subaction gap), the start of this cycle is notified. Send cycle start packet.
[0120]
The time interval at which this cycle start packet is transmitted is 125 μs.
[0121]
Further, as indicated by channel A, channel B, and channel C in FIG. 14, a plurality of types of packets can be distinguished and transferred by being given channel IDs within one cycle. This enables real-time transfer between a plurality of nodes at the same time, and the receiving node captures only the data of the channel ID that it wants. This channel ID does not represent a destination address, but merely gives a logical number to the data. Therefore, transmission of a certain packet is forwarded by broadcast from one transmission source node to all other nodes.
[0122]
Prior to transmission of packets for isochronous transfer, arbitration is performed as in asynchronous transmission. However, since there is no one-to-one communication as in asynchronous transfer, there is no ask (reception confirmation reply code) in isochronous transfer.
[0123]
Further, the iso gap (isochronous gap) shown in FIG. 14 represents an idle period necessary for recognizing that the bus is idle before performing isochronous transfer. When this predetermined idle period elapses, a node that wishes to perform isochronous transfer determines that the bus is free and can perform arbitration before transfer.
[0124]
Next, FIG. 15 shows an example of a packet format for isochronous transfer, which will be described.
[0125]
Each packet divided into each channel has a header portion in addition to the data portion and error correction data CRC, and the header portion has a transfer data length, channel number, and other various types as shown in FIG. A code, a header CRC for error correction, and the like 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 time transition state of the transfer state on the bus in which isochronous transfer and asynchronous transfer are mixed.
[0129]
Isochronous transfer is executed with priority over asynchronous transfer. The reason is that after a cycle start packet, isochronous transfer can be started with a gap length (isochronous gap) shorter than the gap length (subaction gap) of the idle period necessary for starting asynchronous transfer. . Therefore, isochronous transfer is executed with priority over 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, the time is adjusted at each node, and after waiting for a predetermined idle period (isochronous gap), the node which should perform isochronous transfer performs arbitration and enters packet transfer. In FIG. 16, channel e, channel s, and channel k are transferred isochronously in order.
[0131]
After repeating the operations 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 subaction gap where asynchronous transfer is possible, it is determined that a node that wishes to perform asynchronous transfer can move to execution of arbitration.
[0133]
However, the period during which asynchronous transfer can be performed is when a subaction gap for starting asynchronous transfer is obtained between the end of isochronous transfer and the time to transfer the next cycle start packet (cycle synch) Limited to.
[0134]
In cycle #m in FIG. 16, isochronous transfer for three channels and then asynchronous transfer (including ack) are transferred in two packets (packet 1 and packet 2). After this asynchronous packet 2, it is time to start cycle m + 1 (cycle synch), so the transfer in cycle #m ends here.
[0135]
However, if the time to send the next cycle start packet during the asynchronous or synchronous transfer operation (cycle synch) is reached, do not forcibly suspend and wait for the idle period after the transfer ends. Send cycle start packet for cycle. That is, when one cycle continues for 125 μS or more, it is assumed that the fractional cycle is shortened from the reference 125 μS. Thus, the isochronous cycle can be exceeded or shortened on the basis of 125 μS.
[0136]
However, isochronous transfer is always executed if necessary for every cycle in order to maintain real-time transfer, and asynchronous transfer may be passed to the next and subsequent cycles because the cycle time is shortened.
This delay information is managed by the cycle master.
[0137]
Therefore, first, the first embodiment will be described.
[0138]
FIG. 17 is a diagram that best represents the characteristics of the present invention. When the interface of 1394 is compared with each layer of the OSI model used in the LAN, the physical layer 1 and the data link layer 2 of the OSI model are shown in FIG. The upper layer 3 existing on the lower layer 4 corresponds to the transport protocol layer 5 and the presentation layer 6 in the 1394 interface. 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 compliant with the serial bus protocol (SBP-2) 8, the user wants to communicate with the partner device using a protocol compliant with SBP-2. Can be notified. In a third embodiment to be described later, the LOGIN protocol is also inserted into the device protocol 9 specialized on the 1394 interface to determine whether each device supports the protocol, and to Can communicate.
[0140]
FIG. 18 is a diagram showing the basic operation of the LOGIN protocol. When the printer executes the print task 10, the printer protocol A, B, or C prepared by the printer using the LOGIN protocol is firstly selected. Which one is to be selected and printed is determined, and thereafter 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 partner device's protocol is first determined using the LOGIN protocol, and the printer matches the partner protocol. One printer protocol is selected from among a plurality of printer protocols, and print processing is performed by exchanging print data and commands in accordance with the selected protocol.
[0141]
FIG. 19 is a diagram showing a connection form of each device in the 1394 interface that implements the LOGIN protocol in this embodiment. A device (PC 12, scanner) that implements the LOGIN protocol for the printer 11 that supports a plurality of printer protocols. 13, VCR14, etc.), the printing protocol from each device can be processed without problems by switching the printer protocol on the printer side according to the transport protocol of the other party using the LOGIN protocol. It becomes.
[0142]
FIG. 20 shows the flow of the login operation.
[0143]
First step:
-Lock the device (in this case, a multi-protocol printer)
・ Acquire printer capabilities (accepted protocols, etc.)
Such capability is stored in a register 503 described later.
・ Set host capabilities to the printer
Second step:
・ Communication of print data using the protocol determined in the first step
Third step:
-Printer and host disconnect
[0144]
FIG. 21 shows the CSR of the 1394 serial bus provided in the printer for the LOGIN protocol in this embodiment, in which 501 is a lock register (lock), 502 is a protocol register (protocol), and 503 is a capability register ( (capability). These registers are arranged at predetermined addresses in the initial unit space in the address space of the 1394 serial bus. The lock register 501 indicates the lock state of the resource, and a value of 0 indicates that the login is possible, and a value other than 0 indicates that the login has already been performed in the lock state. The capability register 503 indicates a protocol that can be set, and corresponds to the protocol for each bit. 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 is 1.
[0145]
FIG. 22 is a diagram showing the format of a printer map in a network (1394 network) configured with a 1394 serial bus.
[0146]
The printer map stores a unique ID (Unique ID), a node ID (Node ID), a status (Status), and a capability (Capability) of the printer node that has returned the response.
The status here indicates, for example, the contents of the protocol register 502 in FIG. 21, and the capability, for example, indicates the contents of the capability register 503 in FIG.
[0147]
FIG. 23 is a diagram showing a format of a node unique ID in the CRC architecture.
[0148]
FIG. 24 is a diagram showing the format of a printer map (FIG. 22) creation command. This command is notified to the target by an asynchronous packet write transaction.
[0149]
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.
[0150]
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 the 1394 network.
[0151]
Here, various devices are usually connected to the nodes in the network. Under such circumstances, when the initiator (host) tries to output the printer, it is necessary to know which node the printer is connected to. In addition, 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 capability, its remaining capacity, and the like.
[0152]
Therefore, in this embodiment, 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, capability, and remaining power (hereinafter also referred to as topology / capability information) as described above for the printer on the network, and creates a printer map in advance. Then, the target printer is selected based on the printer map.
[0153]
Hereinafter, the printer map creation processing on the host side will be described with reference to FIG.
[0154]
First, in order to create a printer map (FIG. 22), the host side broadcasts its creation command (FIG. 24) (step S3001) and waits for a response command from the target printer (step S3002). ).
[0155]
Upon receiving the response command from the target, the host side next reads the contents of the protocol register and capability register of the target that has returned the response command (step S3003). Thereby, the host side recognizes the capability 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 processing on the target side, that is, on the printer side during the printer map creation processing on the host side described above.
[0158]
First, the printer presents the status and capability from when the power is turned on (step S3101).
Specifically, for example, setting processing of a protocol register and a capability register is performed according to the current capability and state of the printer. Therefore, changes in status and capability within the printer also reflect the status and capability at this step in the presentation.
[0159]
Next, the printer waits to receive a printer map creation command from the host side (step S3102).
[0160]
When the printer receives a printer map creation command from the host side, it 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 the 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. Here, it is confirmed from the contents of the capability register 503 whether the printer supports the protocol used by the host for communication (step 601). If the host protocol is not supported by the printer, the login is aborted in the next step.
[0163]
If the lock register 501 is other than 0, it is assumed that another device is logging in and the login is stopped. If the login register 501 is 0, it is considered that login is currently possible (step 602).
[0164]
If login is possible, the process proceeds to resource lock processing, and 1 is written in the lock register 501 of the printer using a lock transaction to set login on the host side (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.
[0165]
Next, the protocol is set with the printer resources locked as described above. Since the printer in this embodiment supports a plurality of print protocols, the host side protocol must be known before receiving print data. Here, a means is used in which the host side notifies the printer protocol register 502 of a bit corresponding to the protocol to be used by a write transaction (step 604).
[0166]
At this point, the protocol used for communication by the host is notified to the printer, and since the printer is locked, the currently logged-in host transmits print data using 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 on the printer side of the login process.
[0169]
After the printer map creation process (step S700) shown in FIG. 26, the printer side is in a state waiting for login from the normal 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 in a readable state from other devices. Now, assume that the host that intends to execute printout locks the printer (step 701).
[0170]
When the printer is locked by writing to the lock register 501, the host next waits for notification of the protocol used (step 702). The reason for waiting for the protocol notification after entering the locked state is to prevent the protocol register 502 from being rewritten by a request from another device during login.
[0171]
When the protocol is notified, the printer switches the protocol accepted by the printer and performs communication in accordance with the host (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 are 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. The target printer is selected based on the printer map. In the second embodiment, both the host and the printer support a plurality of protocols on the 1394 network, and a plurality of such printers are connected. If so, 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 processing shown in FIGS. 25 and 26, the detailed description thereof is omitted, and here the first embodiment is omitted. Only different points from this embodiment will be specifically described.
[0176]
FIG. 29 is a flowchart showing the host-side printer map creation process in this embodiment, and FIG. 30 is a flowchart showing the printer-side process during this process.
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.
[0177]
In this embodiment, as described above, both initiator (host) and target (printer) support multiple protocols on the 1394 network, and a plurality of such printers are connected to the same network. Of course, the initiator and target must use the same protocol, but to determine which protocol to use now, the initiator examines the available protocols for each printer, takes a majority vote, and most often Use a supported protocol.
[0178]
In this way, it is possible to reduce the type of protocol that is actually used by configuring so that a majority vote is taken in a situation where many protocols can be used. As a result, the load caused by the protocol switch of the initiator is reduced. Can do.
[0179]
Hereinafter, printer map creation processing (relative majority protocol determination printer map processing) on the initiator side (host side) and target side (printer side) will be described with reference to FIGS. 29 and 30. FIG.
[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 S3202). .
[0181]
Upon receiving the response command from the target, the host side next reads the contents of the protocol register and capability register of the target that has returned the response command (step S3203). Thereby, the host side recognizes the capability and state of the target.
[0182]
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).
[0183]
Next, the host side checks available protocols of the multi-protocol printer currently connected to the network from the printer map created in step S3204, and selects the most supported protocol from those protocols. (Step S3205).
[0184]
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 capability from when the power is turned on (step S3301).
Specifically, for example, setting processing of a protocol register and a capability register is performed according to the current capability and state of the printer. Therefore, changes in status and capability within the printer also reflect the status and capability at this step in the presentation.
[0186]
Next, the printer waits to receive a printer map creation command from the host side (step S3302).
[0187]
Next, when the printer receives a printer map creation command from the host side, the printer returns a response command to the command to the host side (step S3303).
[0188]
Next, the printer waits to receive a protocol notification command from the host side (step S3402).
[0189]
When the printer receives a 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. Compared with the first embodiment shown in FIG. 2, the protocol D that does not implement the LOGIN protocol is also supported. Is a feature.
In other words, not only for targets with the LOGIN protocol but also for devices that support only the existing protocol D (for example, AV / C protocol), the printer side supports it to guarantee the printing operation. The printer protocol to be added is added for a device that does not have the LOGIN protocol.
[0192]
To explain this operation, when the printer side recognizes that the target side does not support the LOGIN protocol by the conversation using the LOGIN protocol performed at the beginning of the connection, the printer side uses the other protocol D to talk to the target. Therefore, when a conversation is established, a print 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. 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 represents a case where a protocol that is not yet defined in the current protocol and that does not have the function of the LOGIN protocol created for the scanner is implemented.
In other words, if the printer can cope with a protocol that does not implement the LOGIN protocol, the types of target devices to be connected can be widened.
[0194]
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 a monitor, a computer, a digital camera, or the like may be used, and the device is not limited to a specific model device.
[0195]
In the creation of the printer map executed in step S600 in FIG. 27, step S700 in FIG. 28, and step S3201 in FIG. 29, the topology connection state is investigated as shown in FIG. 9, for example, and a display map is created. By determining the topology connection state, it is possible to determine a protocol to be actually used in consideration of the topology connection state, not just the majority vote.
[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 an apparatus composed of one device.
[0197]
Another object of the present invention is to supply a storage medium storing software program codes for realizing the functions of the host and terminal of each of the above-described embodiments to a system or apparatus, and the computer (or CPU) of the system or apparatus. Needless to say, this can also be achieved by 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 nonvolatile memory card, a ROM, or the like can be used.
[0200]
Further, by executing the program code read by the computer, not only the functions of the above-described embodiments are realized, but also the OS running on the computer based on the instruction of the program code is actually It goes without saying that a case where the function of the embodiment is realized by performing part or all of the processing and the processing is included.
[0201]
Further, after the program code read from the storage medium is written to the memory provided in the extension function board inserted in the computer or the function extension unit connected to the computer, the function extension is performed based on the instruction of the program code. It goes without saying that the CPU or the like provided in the board or the function expansion unit performs part or all of the actual processing, and the functions of the above-described embodiments are realized by the processing.
[0202]
【The invention's effect】
As described above, according to the present invention, it is possible to provide a highly scalable data processing method, data processing apparatus, printer, and storage medium. In particular, since it can cope with a plurality of types of printer protocols, it has extremely high expandability.
Further, since the target printer can be selected by examining printers connected to the same network, an optimal printer output can be obtained. Furthermore, even under the circumstances where many protocols are available, it is possible to reduce the types of protocols that are actually used by determining the most supported protocol from the printer among those protocols. The load due to switching to the host-side protocol 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 an IEEE 1394 address;
FIG. 4 is a cable cross-sectional view of IEEE1394.
FIG. 5 is a diagram for explaining a DS-Link encoding method.
FIG. 6 is a flowchart illustrating from bus reset to ID setting.
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 illustrating a parent-child relationship between nodes.
FIG. 10 is a diagram for explaining an arbitration process;
FIG. 11 is a flowchart showing an arbitration process;
FIG. 12 is a diagram for explaining subactions in Asynchronous transfer;
FIG. 13 is a diagram for explaining a packet structure in Asynchronous transfer.
FIG. 14 is a diagram for explaining subactions in isochronous transfer;
FIG. 15 is a diagram illustrating a packet structure in Isochronous transfer.
FIG. 16 is a diagram for explaining 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 for explaining a connection form of each device in a 1394 interface that implements the LOGIN protocol.
FIG. 20 is a diagram for explaining the flow of a login operation.
FIG. 21 is a view for explaining CSR of a 1394 serial bus provided in a printer for the LOGIN protocol.
FIG. 22 is a diagram for explaining 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 for explaining printer map creation processing on the host side;
FIG. 26 is a flowchart for explaining printer map creation processing on the printer side;
FIG. 27 is a flowchart for explaining host-side processing of login processing;
FIG. 28 is a flowchart for explaining processing on the printer side of login processing;
FIG. 29 is a flowchart for explaining host-side printer map creation processing according to the second embodiment;
FIG. 30 is a flowchart for explaining printer map creation processing on the printer side in the second embodiment;
FIG. 31 is a diagram for explaining a system operation in 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 layers
4 Upper layers
5 Transport protocol layer
6 Presentation layer
7 LOGIN protocol
8 Serial bus protocol (SBP-2)
9 Device protocol

Claims (28)

A data processing method for switching protocols of a plurality of devices via a common serial bus,
A first investigation process for investigating an ID of the device in the same network using the common serial bus and a second investigation process for examining a protocol unique to the device by communication of an initial protocol performed with the device Run
Determining a protocol to be executed based on the ID obtained in the first investigation process and the protocol obtained in the second investigation process;
A data processing method comprising: executing the determined protocol following the initial protocol.   2. The data processing method according to claim 1, wherein the initial protocol includes processing for obtaining capability information including an ID of a printer as the device and a protocol specific to the printer.   3. The data processing method according to claim 2, wherein the printer protocol is a protocol for an ink jet printer.   4. The data processing method according to claim 2, wherein image data to be printed is transmitted after execution of a protocol specific to the printer.   The data processing method according to claim 4, wherein the image data is data photoelectrically converted by an imaging unit.   6. The data processing method according to claim 1, wherein the common serial bus is a bus conforming to the IEEE 1394 standard.   6. The data processing method according to claim 1, wherein the common serial bus is a bus conforming to a USB standard.   The data processing method according to any one of claims 1 to 7, wherein the initial protocol is a protocol executed in a layer higher than a data link layer of the OSI model. A data processing apparatus for switching protocols of a plurality of devices via a common serial bus,
A first investigation process for investigating an ID of the device in the same network using the common serial bus and a second investigation process for examining a protocol unique to the device by communication of an initial protocol performed with the device First execution means for executing
Means for determining a protocol to be executed based on the ID obtained in the first investigation process and the protocol obtained in the second investigation process;
A data processing apparatus comprising: a second execution unit that executes the determined protocol following the initial protocol.   10. The data processing apparatus according to claim 9, wherein the initial protocol includes processing for obtaining capability information including an ID of a printer as the device and a protocol unique to the printer.   11. The data processing apparatus according to claim 10, wherein the printer protocol is an ink jet printer protocol.   12. The data processing apparatus according to claim 10, wherein the second execution unit transmits image data to be printed after execution of a protocol specific to a printer as the device.   13. The data processing apparatus according to claim 12, further comprising an imaging unit that supplies the image data obtained by performing photoelectric conversion to the second execution unit.   14. The data processing apparatus according to claim 9, wherein the common serial bus is a bus conforming to the IEEE 1394 standard.   14. The data processing apparatus according to claim 9, wherein the common serial bus is a bus conforming to a USB standard.   The data processing apparatus according to claim 9, wherein the initial protocol is a protocol executed in a layer higher than a data link layer of the OSI model. A printer that switches a protocol of a plurality of devices corresponding to a host via a common serial bus,
A first investigation process for investigating an ID of the device in the same network using the common serial bus and a second investigation process for examining a protocol unique to the device by communication of an initial protocol performed with the device First execution means for executing
Means for determining a protocol to be executed based on the ID obtained in the first investigation process and the protocol obtained in the second investigation process;
A printer comprising: second execution means for executing the determined protocol following the initial protocol.   18. The printer according to claim 17, wherein the initial protocol includes processing for obtaining capability information including a printer ID and a protocol specific to the printer.   The printer according to claim 18, wherein the protocol of the printer is a protocol for an inkjet printer.   20. The printer according to claim 17, further comprising an imaging unit that transmits image data obtained by performing photoelectric conversion to the receiving unit as the print data.   21. The printer according to claim 17, wherein the common serial bus is a bus conforming to the IEEE 1394 standard.   21. The printer according to claim 17, wherein the common serial bus is a bus conforming to a USB standard.   The printer according to any one of claims 17 to 22, wherein the initial protocol is a protocol executed in a layer higher than a data link layer of the OSI model. A computer-readable storage medium storing a computer program for causing a computer to execute a data processing step for executing a data processing method for switching a protocol of a plurality of devices via a common serial bus, the data The processing method is
A first investigation process for investigating an ID of the device in the same network using the common serial bus and a second investigation process for examining a protocol unique to the device by communication of an initial protocol performed with the device A step of performing
Determining a protocol to be executed based on the ID obtained in the first investigation process and the protocol obtained in the second investigation process;
And a step of executing the determined protocol following the initial protocol.   25. The storage medium according to claim 24, wherein the initial protocol includes processing for obtaining capability information including an ID of a printer as the device and a protocol specific to the printer.   26. The storage medium according to claim 25, wherein the protocol of the printer is a protocol for an inkjet printer.   27. The storage medium according to claim 25, wherein the second execution step includes a step of transmitting image data to be printed after execution of a protocol specific to a printer as the device.   The storage medium according to any one of claims 24 to 27, wherein the initial protocol is a protocol executed in a layer higher than a data link layer of the OSI model.

Images