JPH10283135A - Data processing method, data processor, printer and storage medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To adapt a protocol even to a host not corresponding to an initial protocol by performing changeover to the protocol corresponding to the host by using the obtained identifier of the host and executing it in the case of judging the host not corresponding to the initial protocol. SOLUTION: Equipments A-H are provided and A and B, A and C, B and D, D and E, C and F, C and G and C and H are respectively connected by the twist pair cable of a 1394 serial bus. The respective equipments A-H are respectively provided with intrinsic IDs. In such a system, the initial protocol unrelated to the kind of the protocol of this printer is executed, the host not corresponding to the initial protocol is judged and the intrinsic identifier of the host is obtained. Then, in the case of judging that it is the host not corresponding to the initial protocol, the obtained identifier of the host is used and the protocol corresponding to the host is switched and executed.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a data processing method, a data processing device, a printer, and a storage medium for switching from a plurality of types of printer protocols to a protocol corresponding to a host via a common serial bus. It is.

[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. It is another object of the present invention to provide a data processing method, a data processing device, a printer, and a storage medium that can adapt a protocol to a host that does not support the initial protocol.

[0006]

SUMMARY OF THE INVENTION The present invention is a data processing method for switching a plurality of types of printer protocols via a common serial bus, and executes an initial protocol irrespective of the type of the printer protocol. ,
Determine a host that does not support the initial protocol, obtain a unique identifier of the host, and if it is determined that the host does not support the initial protocol, use the obtained identifier of the host, to the host It is characterized by switching to a corresponding protocol for execution. Also,
The common serial bus is a bus conforming to the IEEE 1394 standard. Further, the protocol of the printer is a protocol for an inkjet printer. Further, the common serial bus is a bus conforming to the USB standard. Further, the initial protocol is a protocol executed in a layer higher than the data link layer of the OSI model. Further, after executing the printer-specific protocol, image data to be printed is transmitted. Further, the image data is data photoelectrically converted by an imaging unit.
The present invention relates to a data processing device for switching a plurality of types of printer protocols via a common serial bus, wherein the execution unit executes an initial protocol irrespective of the type of the printer protocol; Determining means for determining a host not to perform, and obtaining means for obtaining a unique identifier of the host, wherein the execution means determines from the determination result of the determining means that the host does not correspond to the initial protocol. Using the identifier acquired by the acquiring means, the protocol is switched to a protocol corresponding to the host and executed. Further, the common serial bus is an IEEE1394.
It is a bus that conforms to the standard. Further, the protocol of the printer is a protocol for an inkjet printer. Further, the common serial bus is a bus conforming to the USB standard. Further, the initial protocol is a protocol executed in a layer higher than the data link layer of the OSI model. Further, after executing the printer-specific protocol, image data to be printed is transmitted. Further, the image data is
The data is photoelectrically converted by the imaging means. The present invention relates to a printer for switching protocols of a plurality of types of printers via a common serial bus, and executing means for executing an initial protocol irrespective of the type of the protocol of the printer, and determining a host which does not support the initial protocol. Determining means, and obtaining means for obtaining a unique identifier of the host, wherein the executing means determines, based on a determination result of the determining means, that the host does not correspond to the initial protocol, the obtaining means And switching to a protocol corresponding to the host using the identifier acquired in step (1). Further, the common serial bus is an IEEE1394.
It is a bus that conforms to the standard. Further, the protocol of the printer is a protocol for an inkjet printer. Further, the common serial bus is a bus conforming to the USB standard. Further, the initial protocol is a protocol executed in a layer higher than the data link layer of the OSI model. The image processing apparatus further includes an image pickup unit that transmits image data obtained by performing photoelectric conversion to the reception unit as the print data. The present invention relates to a storage medium storing steps for executing data processing for switching a plurality of types of printer protocols via a common serial bus, wherein an initial protocol irrespective of the type of the printer protocol is stored. An execution step to be executed, a determination step of determining a host that does not correspond to the initial protocol, and an acquisition step of acquiring a unique identifier of the host are stored in a computer readable manner, and the execution step is performed by the computer. When the determination result indicates that the host does not support the initial protocol, the method includes a step of switching to a protocol corresponding to the host using the identifier obtained in the obtaining step and executing the host. Further, the common serial bus is an IEEE1394.
It is a bus that conforms to the standard. Further, the protocol of the printer is a protocol for an inkjet printer. Further, the common serial bus is a bus conforming to the USB standard. Further, the initial protocol is a protocol executed in a layer higher than the data link layer of the OSI model. Further, the executing step includes a step of transmitting image data to be printed after executing the printer-specific protocol. Further, the image data is data photoelectrically converted by an imaging unit.

[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 Serial Bu
s) (hereinafter simply referred to as 1394 serial bus).

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.

As a data transfer mode, As is used to transfer asynchronous data such as a control signal (hereinafter, referred to as Async data).
synchronous transfer mode such as video data and audio data in real time (Isoc)
There is an Isochronous transfer mode for transferring the strong data (hereinafter referred to as Iso data). After transferring a cycle start packet (CSP) indicating the start of a cycle in each cycle (usually 125 μs per cycle), the Async data and the Iso data are transferred within the cycle while giving priority to the transfer of the Iso data over the Async data. It is mixed and transferred.

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 identifier (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, and can be used as a unique address space. Last two
8 bits store information such as identification of each device and designation of use conditions as an area of unique data.

The CRS architecture has a configuration ROM for representing the function of each node. This ROM has a minimum format and a general format, and is arranged from xFFFFF0000400. Such a ROM corresponds to the ROM in FIG.

In the minimum format, as shown in FIG. 4, only a vendor ID is represented, and this ID is a numerical value unique to the whole world represented by 24 bits.

In the general format, a format as shown in FIG.
It has information about the node, but the vendor ID in this case can be in the root_directory.

Also, bis_inf_block and ro
ot_leaf has a globally unique device number of 64 bits including the vendor ID.

This device number is used for continuously recognizing a node after a reconfiguration such as a bus reset.

FIG. 6 shows an example of a configuration ROM of a digital camera.

The vendor ID in FIG. 6 is node_ven
dor_id, chip_id_hi, chip_id
_Lo is represented by 64 bits.

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

Next, the technical portion which 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. 7 is a sectional view of a 1394 serial bus cable.

In the 1394 serial bus, a power supply line is provided in a connection cable in addition to 6 pins, ie, 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 the maximum current DC 1.5A.

It should be noted that the standard called DV cable has four pins without a power source.

The DS-Link coding will be described.

The 1394 serial bus employs
FIG. 8 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 coding method include higher transfer efficiency as compared with the 8 / 10B conversion, and the need for a PLL circuit, thereby 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. Each detected node sends a bus reset signal on the bus,
Enter the mode to recognize the new network configuration.

The method of detecting the change at this time is performed 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 started by a cable detection as described above, a start by hardware detection due to a network abnormality or the like, and also by directly issuing a command to a physical layer by a 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 an ID to each node 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. 9 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 state where the network is reset, 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. 9. 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. 10 and 11, respectively.

First, the flowchart of FIG. 10 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, as step S202, as a first stage of the operation 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 (parent-child relationship is not determined) 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 the bus reset, only the 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 a number of undefined ports> 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 it did not operate quickly enough to allow child declaration) becomes 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. 10 to the declaration of the parent-child relationship between all the nodes in the network are completed.

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

First, in the sequence up to FIG.
Since the information of the flag of each node such as branch and route is set, classification is performed in step S301 based on this.

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

At 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, if the number of remaining leaves is one or more at step S309, the I at 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, as 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, and 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 where the ID was obtained
At 315, the ID information of the node is transferred to all nodes by broadcast.

When the broadcasting of 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, as shown in FIG. 11, the procedure from the determination of the parent-child relationship to the setting of the IDs of all the nodes is completed.

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

Referring to FIG. 12, (root) node B
Are directly connected to node A and node C,
Further, a node D is directly connected below the node C, and a node E and a node F are directly connected below the node D in a hierarchical structure. 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 ports directly connected to 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. 12, 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 way, 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, between node AB, child-parent, node E-
The child-parent is determined between D and the child-parent is determined between the nodes FD.

Further, the node goes up one layer, and among nodes having a plurality of connection ports (referred to as branches), the parent / child relationship is declared further higher in order from the node which received the declaration of the parent / child relationship from another node. To go. In FIG. 12, 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. 12 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. 12, node B is determined to be the root node. This is because 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, next, each node
Enter the ID determination mode. 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.

The procedure for assigning node ID numbers is as follows:
First, it can be started from a node (leaf) that has connection to only one port, and node number =
0, 1, 2,...

The node having 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 the self ID information. That is,
The root always owns the highest 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 is completed.

The arbitration will be described.

In the 1394 serial bus, arbitration (arbitration) of the right to use the bus must be performed prior to 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. 13 (a) shows a diagram of a bus use request and FIG. 13 (b) shows a diagram of a bus use permission, which will be described below.

When the arbitration starts, one or more nodes issue a bus use request to the parent node. Nodes C and F in FIG. 13A are nodes that have issued a bus use right request. The parent node (node A in FIG. 13) which 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 uses 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 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, at step S404, when the route receives one or more bus use requests at step S403, the route checks at step S405 the number of nodes that have issued use requests.

The value selected in step S405 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 in FIG. 14 for explaining the flow of arbitration.

A description will now be given of the asynchronous transfer.

Asynchronous transfer is asynchronous transfer. FIG. 15 shows a temporal transition state in the asynchronous transfer.

The first sub-action gap in FIG. 15 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 a bus use permission is obtained by arbitration, data transfer is then executed in packet format.
After the data transfer, the receiving node sets the reception result ack (reception confirmation return code) for the transferred data to ac.
After a short gap of k gap, the transfer is completed by replying back or sending a response packet.
The ack 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.

FIG. 16 shows an example of a packet format for 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 the destination node ID, the source node ID, the transfer data length and the like as shown in FIG. Various codes and the like are written and transferred.

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.

In addition, 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. 17 is a diagram showing a temporal transition state in isochronous transfer.

The isochronous transfer is executed at fixed time intervals on the bus. 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. 17 shows channel A, channel B,
As indicated by channel C, a plurality of types of packets can be distinguished and 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 transmitted by broadcast, which is distributed from one source node to all other nodes.

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

The iso gap (isochronous gap) shown in FIG. 17 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 in addition to a data part and data CRC for error correction, and the header part has a transfer data length and a channel as shown in FIG. NO, other codes and a header CRC for error correction are written and transferred.

The above is the description of the isochronous transfer.

The bus cycle will be described.

In actual transfer on the 1394 serial bus, isochronous transfer and asynchronous transfer can coexist. FIG. 19 shows 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. 19, at the start of cycle #m, a cycle start packet is transferred from the cycle master to each node. 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. 19, the channel e, the channel s, and the channel k are sequentially isochronously transferred.

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

When the idle time reaches the subaction gap in which asynchronous transfer is possible, the node desiring to perform asynchronous transfer determines that arbitration can be executed.

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 and before the time (cycle synch) at which the next cycle start packet should be transferred. Only when they are given.

In cycle #m of FIG. 19, two packets (packet 1 and packet 2) of isochronous transfer for three channels and asynchronous transfer (including ack) thereafter
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 the 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 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. 20 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. Further, in Example 2, by inserting the LOGIN protocol also for the device protocol 9 specialized on the 1394 interface, it is possible for each device to determine whether the protocol is supported and to exchange data.

FIG. 21 is a diagram showing the basic operation of the LOGIN protocol. When executing 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. 22 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. 23 shows the flow of the login operation.

First step:-Lock the device (in this case, a multi-protocol printer)-Acquire printer capabilities (accepted 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. 24 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. 25 is a flowchart on the host side of the login processing.

To start login, first, the lock register 501, the protocol register 502, and the capability register 503 of the printer to be logged in.
Is confirmed by a read transaction. Here, it is confirmed whether or not the printer supports the protocol used by the host for communication from the contents of the capability register 503 (step S601). 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 determined that the login is possible at present (step S602).

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

In the state where the resources of the printer are 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 sets up a bit corresponding to a protocol to be used from now on, by a write transaction, to the protocol register 502 of the printer (step S604).

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

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

First, the printer normally waits for a login from the host (step S701). The login starts when the host reads the printer lock register 501, the protocol register 502, and the capability register 503. This is the case of a host that supports login, and a host that does not support login does not access these registers.

Login waiting state (step S701)
Is set to time out after a predetermined time, and in the next step S702, it is determined whether or not a time-out has occurred.

If it is determined in step S702 that the login is performed within the time without time-out, the process proceeds to waiting for reception of the used protocol type (step S705), and enters a state of waiting for notification of the used protocol.

On the other hand, if it is determined in step S702 that a timeout has occurred, a protocol search is performed (step S703). As will be described in detail later, the protocol search is a process of searching for a node to be a host and searching for a host protocol from a node ID.

Using the result of the protocol search in step S703, it is determined in step S704 whether the protocol is compatible with the printer.

If it is determined in step S704 that the printer supports the protocol, the protocol is set (step S706).

On the other hand, if the printer does not support the protocol, it enters a login wait state (step S701).

Therefore, the user is logged in and notified of the protocol to be used (step S705), or the corresponding protocol is found by the protocol search (step S705).
704), the protocol is set (step S
706).

Protocol setting (step S706)
Thereafter, by the following steps S707 to S712,
Switch to each protocol and perform data communication with each protocol.

When the data communication is completed, the printer operates the lock register 501 and the protocol register 50.
2. Confirm that the capability register 503 has been cleared (step S713), and return to the login waiting state (step S701).

However, the protocol search (step S70)
In the case where the protocol is determined in 3), it is natural that the system does not support logout. In this case, the reset state of the bus, the host, and the printer causes the initial state of the login wait state. Becomes

FIG. 27 is a flowchart showing the above-described protocol search.

First, the total number of nodes on the bus is obtained (step S801). The total number of bus nodes can be determined from a topology map or the like held by the bus manager.

Next, it is determined whether the total number of nodes obtained in step S801 is valid (step S801).
802). This determination is made when the total number of nodes is 3 or more, or when there is no other node (step S8).
02), a process of setting no corresponding protocol (invalid).

If it is determined in step S802 that the total number of nodes is invalid, there is no corresponding protocol (step S807), and the process returns.

On the other hand, if the total number of nodes is valid,
The node number of the other party is obtained (step S803). If the own node number is "0", the other node number is "1", if the own node number is "1", the other node number is "0", and so on. The number can be determined simply.

Next, the node ID of the other party is obtained (step S804). The node ID is the Config shown in FIG.
node_vendor_i of uration ROM
d, chip_id_hi, chip_id_lo to r
It can be obtained by reading with an ead transaction. Further, since the node ID has a unique number depending on the device, it is possible to specify the partner device.

Next, the protocol of the partner is determined from the device of the partner (step S805).

Next, it is determined whether or not the other party's protocol is valid for the printer (step S806). If it is not valid, it is determined that there is no corresponding protocol (step S807), and if it is valid, it is determined that there is a corresponding protocol (step S80).
8) Return.

Therefore, the result of the above-mentioned protocol search is notified as to the presence or absence of the corresponding protocol and the protocol.

By the processing shown in FIG. 26 and FIG. 27, the printer can identify the protocol of the partner from the node ID of the partner with respect to the device that does not log in, and can match its own protocol to that protocol.

The present invention may be applied to a system composed of a plurality of devices as shown in FIG. 22, 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 out 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 extended function board inserted into the computer or a function extension 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.

Furthermore, the identifier unique to the host in the present invention may be an ASCII code, binary data, or the name of a corporation or an individual who exclusively uses the host. The identifier may be a network address, for example, an IP address or MA
An address called a C address may be used. Also, for example, instead of an identifier unique to the host, a variable identifier may be used, or an encryption key or the like may be used. That is, any information that can identify the host is included in the identifier according to the present invention.

[0188]

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. In addition, by configuring the printer and other protocols to be compatible with host devices that do not support the initial protocol, it is possible to match the protocol to hosts that do not implement the initial protocol. can do.

[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 minimum configuration ROM.
FIG.

FIG. 5: Configuration ROM of general format
FIG.

FIG. 6: Configuration of a digital camera
FIG. 3 is a diagram for explaining a ROM.

FIG. 7 is a cable sectional view of IEEE1394.

FIG. 8 is a diagram for explaining a DS-Link encoding method.

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

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

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

FIG. 12 illustrates a parent-child relationship between nodes.

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

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

FIG. 15 is a diagram showing a sub-action in asynchronous transfer.

FIG. 16 is a diagram showing a packet structure in asynchronous transfer.

FIG. 17 is a diagram showing a sub-action in Isochronous transfer.

FIG. 18 is a diagram showing a packet structure in isochronous transfer.

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

FIG. 20 is a diagram for explaining a system to which the present invention is applied.

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

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

FIG. 23 is a diagram illustrating the flow of a login operation.

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

FIG. 25 is a flowchart for explaining the host-side processing of the login processing.

FIG. 26 is a flowchart for explaining a printer-side process of a login process.

FIG. 27 is a flowchart illustrating a protocol search process.

[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 (27)

[Claims] 1. A data processing method for switching a plurality of types of printer protocols via a common serial bus, wherein the host executes an initial protocol irrespective of the type of the printer protocol, and does not support the initial protocol. And obtains a unique identifier of the host, and when it is determined that the host does not support the initial protocol, switches to a protocol corresponding to the host using the obtained host identifier and executes the host. A data processing method. 2. The method according to claim 1, wherein the common serial bus is an IEEE13.
2. The data processing method according to claim 1, wherein the bus conforms to the 94 standard. 3. The data processing method according to claim 1, wherein the protocol of the printer is a protocol for an inkjet printer. 4. The data processing method according to claim 1, wherein the common serial bus is a bus conforming to a USB standard. 5. 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. 6. The data processing method according to claim 1, further comprising transmitting image data to be printed after executing the printer-specific protocol. 7. The data processing method according to claim 6, wherein said image data is data photoelectrically converted by an imaging unit. 8. A data processing device for switching protocols of a plurality of types of printers via a common serial bus, wherein the execution unit executes an initial protocol irrespective of the type of the protocol of the printer. Determining means for determining an unsupported host, and obtaining means for obtaining a unique identifier of the host, wherein the executing means determines that the host is not compatible with the initial protocol based on a determination result of the determining means. In this case, the data processing device is characterized by switching to a protocol corresponding to the host using the identifier acquired by the acquisition unit and executing the protocol. 9. The common serial bus includes an IEEE 13 bus.
9. The data processing device according to claim 8, wherein the bus conforms to the 94 standard. 10. The data processing method according to claim 8, wherein the protocol of the printer is a protocol for an inkjet printer. 11. The data processing device according to claim 8, wherein the common serial bus is a bus conforming to a USB standard. 12. The data processing apparatus according to claim 8, wherein said initial protocol is a protocol executed in a layer higher than a data link layer of an OSI model. 13. The data processing apparatus according to claim 8, wherein image data to be printed is transmitted after the execution of the printer-specific protocol. 14. The image data according to claim 1, wherein the image data is data photoelectrically converted by an imaging unit.
3. The data processing device according to 3. 15. A printer for switching protocols of a plurality of types of printers via a common serial bus, comprising: an execution unit for executing an initial protocol irrespective of a type of the protocol of the printer; and a host not supporting the initial protocol. Determining means for determining, and obtaining means for obtaining a unique identifier of the host, wherein the execution means determines, based on a determination result of the determining means, that the host does not correspond to the initial protocol, the obtaining means A printer adapted to switch to a protocol corresponding to the host using the identifier acquired by the means. 16. The device according to claim 1, wherein the common serial bus is an IEEE1
The printer according to claim 15, wherein the bus conforms to the 394 standard. 17. The printer according to claim 15, wherein the protocol of the printer is a protocol for an inkjet printer. 18. The printer according to claim 15, wherein the common serial bus is a bus conforming to a USB standard. 19. The printer according to claim 15, wherein the initial protocol is a protocol executed in a layer higher than a data link layer of an OSI model. 20. The data processing apparatus according to claim 15, further comprising an imaging unit that transmits image data obtained by performing photoelectric conversion to the reception unit as the print data. 21. A storage medium storing a step for executing data processing for switching a plurality of types of printer protocols via a common serial bus, wherein the initial protocol is independent of the type of the printer protocol. And a determining step of determining a host that does not correspond to the initial protocol; and an obtaining step of obtaining a unique identifier of the host, the computer storing the reading step in a readable manner. When it is determined that the host does not support the initial protocol based on the determination result, the method includes a step of switching to a protocol corresponding to the host using the identifier acquired in the acquiring step and executing the host. Storage medium. 22. The common serial bus includes an IEEE 1 bus.
22. The storage medium according to claim 21, which is a bus conforming to the 394 standard. 23. The storage medium according to claim 21, wherein the protocol of the printer is a protocol for an ink jet printer. 24. The storage medium according to claim 21, wherein said common serial bus is a bus conforming to a USB standard. 25. The storage medium according to claim 21, wherein said initial protocol is a protocol executed in a layer higher than a data link layer of an OSI model. 26. The storage medium according to claim 21, wherein said executing step includes a step of transmitting image data to be printed after executing said printer-specific protocol. 27. The image processing apparatus according to claim 2, wherein the image data is data photoelectrically converted by an imaging unit.
6. The storage medium according to 6.