Data transfer device, data transfer system and its method, image processing unit and recording medium

Description: TECHNICAL FIELD [Detailed description of the invention]

【０００１】

INDUSTRIAL APPLICABILITY The present invention relates to a data transfer device, a data transfer system and their methods, and an image processing device, and supplies an image of a digital camera or the like via a serial interface defined in, for example, IEEE1394. The present invention relates to data transfer and image processing when a device is directly connected to an image processing device such as a printer.

【０００２】

[Conventional Technology] A printer is connected to a personal computer (PC), which is a host device, via a parallel or serial interface such as Centronics or RS232C.

Further, digital devices such as scanners, digital still cameras, and digital video cameras, which are image supply devices, are also connected to the PC. The image data captured by each digital device is once captured on the hard disk on the PC, processed by the application software on the PC, converted into print data for the printer, and passed through the above interface. And sent to the printer.

In the above system, driver software for controlling each digital device, printer, etc. exists independently in the PC, and the image data output from the digital device is used on the PC by the driver software. It is saved as data in a format that is easy and easy to display. The stored data is converted into print data by an image processing method that takes into consideration the image characteristics of the input device and the image characteristics of the output device.

Today, new interfaces such as the interface defined by IEEE1394 (hereinafter referred to as the "1394 serial bus") can also directly connect an image supply device to a printer. When the image supply device and the printer are directly connected by the 1394 serial bus, a method of including print data in the operand of FCP (Function Control Protocol) can be considered. In addition, in the 1394 serial bus, a method of providing a register area for data transfer and writing data to the register area to perform data transfer is also conceivable.

Further, a method of instructing data transfer by using a command for instructing the start of data transfer and a response to the command is also conceivable.

【０００７】

However, the above-mentioned technique has the following problems. As described above, the image data output from the image supply device is converted into print data by the PC and printed by the printer. Therefore, even if the image supply device and the printer are directly connected, printing is performed without the PC. Can't do. There is also a printer called a video printer that directly prints the image data output from the digital video camera, but a versatile video printer that can only be connected between specific models and can be used directly with a large number of image supply devices. Absent. That is, it is not possible to directly send image data from an image supply device to a printer for printing by taking advantage of the function of directly connecting devices such as a 1394 serial bus.

The above-mentioned method of directly connecting the image supply device and the printer by the 1394 serial bus and including the print data in the operand of the FCP has a problem that the control command and the print data cannot be separated, and also for the command. There is also a problem that the transfer efficiency is low because a response is always required. Further, in the method of providing the register area for data transfer described above, a process for determining whether or not data can be written in the register area is required for each data transfer. Therefore, there is a problem that the overhead of this determination process becomes large and the transfer efficiency also decreases.

Further, when a data transfer instruction is given using the above-mentioned command for instructing the start of data transfer and a response to the command, a command and a response are exchanged for each data transfer in a certain unit, and the transfer is also performed. The problem of reduced efficiency arises.

The present invention is for solving the above-mentioned problems individually or collectively, and efficiently transfers data from the host device to the target device when the host device and the target device are connected by a 1394 serial bus or the like. The purpose is to do.

Another purpose is efficient data transfer in which control commands and data can be separated.

Another object is data transfer in which commands and responses are not exchanged for each unit of data transfer.

【００１３】

Means for Solving the Problems The present invention includes the following configurations as one means for achieving the above object.

The data transfer method according to the present invention is a data transfer method used between a host device and a target device connected by a serial bus, and is a lock transaction between the host device and the target device. Locks the target device, communicates information indicating the amount of data to be transmitted between the host device and the target device, transmits a data packet according to the information indicating the amount of data, and then data. When transmitting, the next data packet is transmitted without communicating the information indicating the amount of data.

The data transfer device according to the present invention is a data transfer device connected to a serial bus, and has a locking means for locking the target device by communication by a lock transaction with the target device, and the target device. A communication means for communicating information indicating the amount of data to be transmitted between the two, and a data packet is transmitted according to the information indicating the amount of data, and when subsequent data transmission is performed, the information indicating the amount of data is communicated. It is characterized by having a transmission means for transmitting the next data packet without any problem.

Further, a data transfer device connected to the serial bus, which is transmitted between the host device and a means for locking the data transfer device by communication by a lock transaction with the host device. When receiving a data packet according to the communication means for communicating the information indicating the amount of data and the information indicating the amount of data and subsequently receiving the data, the following information indicating the amount of data is not communicated with each other. It is characterized by having a receiving means for receiving a data packet.

The data transfer system according to the present invention is a data transfer system that transfers data via a serial bus, and locks the target device by communication by a lock transaction between the host device and the target device. When the means, the communication means for communicating the information indicating the amount of data to be transmitted between the host device and the target device, and the information indicating the amount of data, the data packet is transferred, and then the data is transferred. Is characterized by having a transfer means for transferring the next data packet without communicating the information indicating the amount of data.

The image processing apparatus according to the present invention is characterized in that the image data is transmitted to the target device or the image data received from the host device is processed by the above data transfer method.

【００１９】

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, a data transfer method according to an embodiment of the present invention will be described in detail with reference to the drawings.

FIG. 1 is a diagram showing a general configuration example of a system to which the present invention is applied, in which a PC 103, a printer 102, and a digital video camera (DVC) 101 are connected by using a 1394 serial bus. Therefore, the outline of the 1394 serial bus will be described in advance.

【００２１】

[Overview of IEEE1394] With the advent of home-use digital VTRs and digital video discs (DVDs), real-time and information-rich data such as video data and audio data (hereinafter collectively referred to as "AV data") are transferred. There is a need. In order to transfer AV data to a PC or other digital devices in real time, an interface with high-speed data transfer capability is required. The interface developed from that perspective is the 1394 serial bus.

FIG. 2 shows an example of a network system configured by using a 1394 serial bus. This system is equipped with devices A to H, and AB, AC, BD, DE, CF, CG, and CH are each connected by a twisted pair cable for a 1394 serial bus. Examples of these devices A to H are host computer devices such as personal computers and computer peripheral devices. Computer peripherals include digital VCRs, DVD players, digital still cameras, storage devices that use media such as hard disks and optical disks, CRT and LCD monitors, tuners, image scanners, film scanners, printers, MODEMs, and terminal adapters (TAs). All computer peripherals such as are targeted. The recording method of the printer may be any method such as an electrophotographic method using a laser beam or an LED, an inkjet method, an ink melting type or a sublimation type thermal transfer method, or a thermal recording method.

The connection between the devices can be a mixture of the daisy chain method and the node branch method, and can be connected with a high degree of freedom. In addition, each device has an ID, and by recognizing each other's IDs, one network is formed within the range connected by the 1394 serial bus. For example, by simply connecting each device in a daisy chain with one 1394 serial bus cable, each device plays the role of relay, so that one network can be configured as a whole.

Further, the 1394 serial bus corresponds to the Plug and Play function, and has a function of automatically recognizing the device and recognizing the connection status only by connecting the 1394 serial bus cable to the device. In addition, in the system shown in Fig. 2, when a certain device is removed from the network or newly added, the bus is automatically reset (the network configuration information up to that point is reset) to make a new one. Rebuild a network. With this function, it is possible to constantly set and recognize the network configuration at that time.

Further, the data transfer rate of the 1394 serial bus is defined as 100/200/400 Mbps, and compatibility is maintained by supporting a device having a higher transfer rate to a lower transfer rate. .. The data transfer mode includes an asynchronous transfer mode (ATM) for transferring asynchronous data such as a control signal and an isochronous transfer mode for transferring synchronous data such as real-time AV data. This asynchronous data and synchronous data are mixed in each cycle (usually 125 μs / cycle), following the transfer of the cycle start packet (CSP) indicating the start of the cycle, while giving priority to the transfer of the synchronous data. Transferred.

FIG. 3 is a diagram showing a configuration example of a 1394 serial bus. The 1394 serial bus has a layered structure. As shown in FIG. 3, the connector at the tip of the cable 813 for the 1394 serial bus is connected to the connector port 810. Above the connector port 810, there is a physical layer 811 and a link layer 812, which are composed of the hardware unit 800. The hardware unit 800 is composed of an interface chip, of which the physical layer 811 performs coding and connection-related control, and the link layer 812 controls packet transfer and cycle time.

The transaction layer 814 of the firmware unit 801 manages the data to be transferred (transaction) and issues Read, Write, and Lock instructions. The management layer 815 of the firmware unit 801 manages the connection status and ID of each device connected to the 1394 serial bus, and manages the network configuration. The above hardware and firmware are the actual configuration of the 1394 serial bus.

The application layer 816 of the software unit 802 differs depending on the software used, and how to transfer data on the interface is defined by a protocol such as a printer or an AV / C protocol.

FIG. 4 is a diagram showing an example of the address space in the 1394 serial bus. Each device (node) connected to the 1394 serial bus must have a 64-bit address unique to the node. Then, this address is stored in the memory of the device, and by constantly recognizing the node address of oneself or the other party, data communication can be performed by designating the communication partner.

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.

The 48-bit address used in each device is also divided into 20 bits and 28 bits, and is used with a structure in units of 256 Mbytes. Of the first 20-bit address space, 0 to 0xFFFFD is called the memory space, 0xFFFFE is called the private space, and 0xFFFFF is called the register space. The private space is an address that can be freely used in the device, and common information is placed between the devices connected to the bus in the register space and used for communication between the devices.

In the register space, the first 512 bytes are the registers that are the core of the CSR architecture (CSR core), the next 512 bytes are the serial bus registers, and the next 1024 bytes are the configuration ROMs. The rest is the unit space where device-specific registers are placed.

In general, to simplify the design of heterogeneous bus systems, nodes should use only the first 2048 bytes of initial unit space, resulting in CSR cores, serial bus registers, configuration ROMs and It is desirable to make up 4096 bytes including the first 2048 bytes of the unit space.

The above is the outline of the 1394 serial bus. Next, the features of the 1394 serial bus will be described in more detail.

【００３５】

[Details of 1394 serial bus] [Electrical Specifications of 1394 Serial Bus] FIG. 5 is a diagram showing a cross section of a cable for a 1394 serial bus. The 1394 serial bus cable is provided with a power supply line in addition to the two sets of twisted pair signal lines. This makes it possible to supply electric power to a device that does not have a power supply or a device whose voltage has dropped due to a failure or the like. The voltage of DC power supplied by the power supply line is specified as 8 to 40V, and the current is specified as a maximum current of 1.5A. The standard called DV cable consists of four wires that omit the power supply line.

[DS-Link Method] FIG. 6 is a diagram for explaining the DS-Link (Data / Strobe Link) method of the data transfer method adopted in the 1394 serial bus.

The DS-Link system is suitable for high-speed serial data communication and requires two sets of signal lines. In other words, one of the two pairs of strands sends the data signal, and the other pair sends the strobe signal. On the receiving side, a clock can be generated by exclusive-ORing this data signal and the strobe signal. Therefore, when the DS-Link method is used, it is not necessary to mix the clock signal in the data signal, so the transfer efficiency is higher than that of other serial data transfer methods, and the clock signal can be generated, so that the phase locked loop (PLL) is used. The circuit becomes unnecessary, and the circuit scale of the controller LSI can be reduced accordingly. Furthermore, since it is not necessary to send information indicating that the device is idle when there is no data to be transferred, the transceiver circuit of each device can be put to sleep, and power consumption can be reduced. ..

[Sequence of bus reset] Each device (node) connected to the 1394 serial bus is given a node ID and is recognized as a node constituting the network. For example, when the number of nodes increases or decreases due to disconnection of network devices or power on / off, that is, when there is a change in the network configuration and it is necessary to recognize the new network configuration, each node that detects the change is on the bus. Sends a bus reset signal to enter a mode that recognizes the new network configuration. The change in the network configuration is detected by detecting the change in the bias voltage at the connector port 810.

When a bus reset signal is transmitted from a certain node, the physical layer 811 of each node receives the bus reset signal and at the same time transmits the occurrence of the bus reset to the link layer 812, and also transmits the bus reset signal to the other nodes. To convey. Finally, after all the nodes receive the bus reset signal, the bus reset sequence is activated. The bus reset sequence is activated when the cable is plugged in or unplugged, or when the hardware detects a network error, etc., and it can also be started by giving a direct command to the physical layer 811 such as host control by the protocol. It will be started. Also, when the bus reset sequence is activated, the data transfer is suspended, waited for the bus reset, and resumed under the new network configuration after the bus reset is completed.

[Sequence of node ID determination] After the bus reset, each node enters an operation of giving an ID to each node in order to construct a new network configuration. The general sequence from bus reset to node ID determination at this time will be described with reference to the flowcharts shown in FIGS. 7 to 9.

FIG. 7 is a flowchart showing a series of sequence examples from the generation of the bus reset signal to the determination of the node ID and the ability to transfer data. Each node constantly monitors the generation of the bus reset signal in step S101, moves to step S102 when the bus reset signal is generated, and is directly connected to each other in order to obtain a new network configuration in the state where the network configuration is reset. A parent-child relationship is declared between the nodes. Then, step S102 is repeated until it is determined that the parent-child relationship has been determined among all the nodes by the determination in step S103.

When the parent-child relationship is determined, the process proceeds to step S104 to determine the root node, and in step S105, the node ID setting work for giving an ID to each node is performed. Node IDs are set in the order of predetermined nodes from the root node, and step S105 is repeated until it is determined in step S106 that IDs have been given to all the nodes.

When the node ID setting is completed, the new network configuration is recognized by all the nodes, so that the data transfer between the nodes can be performed, the data transfer is started in step S107, and the sequence is started. Returning to step S101, the generation of the bus reset signal is monitored again.

FIG. 8 is a flowchart showing a detailed example from monitoring the bus reset signal (S101) to determining the root node (S104), and FIG. 9 is a flowchart showing a detailed example of node ID setting (S105, S106).

In FIG. 8, the generation of the bus reset signal is monitored in step S201, and when the bus reset signal is generated, the network configuration is temporarily reset. Next, in step S202, as the first step of the work of re-recognizing the reset network configuration, each device resets the flag FL with the data indicating that it is a leaf node. Then, in step S203, each device checks the number of ports, that is, the number of other nodes connected to itself, and in step S204, it is undefined in order to start the declaration of the parent-child relationship from now on according to the result of step S203. Check the number of ports (parent-child relationship has not been determined). Here, the number of undefined ports is equal to the number of ports immediately after the bus reset, but the number of undefined ports detected in step S204 decreases as the parent-child relationship is determined.

Only the actual leaf node can declare the parent-child relationship immediately after the bus reset. Whether or not it is a leaf node can be known from the confirmation result of the number of ports in step S203, that is, if the number of ports is "1", it is a leaf node. In step S205, the leaf node declares a parent-child relationship to the node of the connection partner, "I am a child, the other party is a parent", and ends the operation.

On the other hand, the node in which the number of ports is "2 or more" in step S203, that is, the branch node, immediately after the bus reset, "the number of undefined ports> 1", so the process proceeds to step S206 and branches to the flag FL. Set the data indicating the node and wait for the parent-child relationship to be declared by the other node in step S207. A parent-child relationship is declared by another node, and the branch node that receives it returns to step S204 and checks the number of undefined ports, but if the number of undefined ports is "1", it is connected to the remaining port. In step S205, a parent-child relationship of "I am a child and the other party is a parent" can be declared to another node. In addition, a branch node whose number of undefined ports is "2 or more" waits for another node to declare a parent-child relationship again in step S207.

When the number of undefined ports of any one branch node (or, exceptionally, a leaf node that can declare a child but does not operate quickly) becomes "0", the parent-child relationship of the entire network The only node whose number of undefined ports has become "0", that is, the node that has been decided as the parent of all the nodes, sets the data indicating the root node in the flag FL in step S208, and sets the data indicating the root node in the flag FL. Recognized as the root node in step S209.

In this way, the procedure from the bus reset to the declaration of the parent-child relationship between all the nodes in the network is completed.

Next, the procedure for assigning an ID to each node will be described, but it is the leaf node that can set the ID first. Then, set the ID from the youngest number (node number: 0) in the order of leaf branch root.

In step S301 of FIG. 9, the process is branched according to the node type, that is, the leaf, the branch, and the route, based on the data set in the flag FL.

First, in the case of leaf nodes, in step S302, the number of leaf nodes (natural numbers) existing in the network is set in the variable N, and then in step S303, each leaf node requests a node number from the root node. To do. When there are a plurality of such requests, the root node performs arbitration in step S304, gives a node number to one node in step S305, and notifies the other nodes of the result indicating failure to acquire the node number.

The leaf node whose node number could not be acquired by the determination in step S306 repeats the request for the node number in step S303 again. On the other hand, the leaf node whose node number has been acquired notifies all the nodes by broadcasting the ID information including the acquired node number in step S307. When the broadcast of the ID information is completed, the variable N representing the number of leaves is decremented in step S308. Then, the procedure of steps S303 to S308 is repeated until the variable N becomes "0" by the determination of step S309, and after the ID information of all leaf nodes is broadcast, the process proceeds to step S310 to set the ID of the branch node. Move to.

The ID setting of the branch node is performed in almost the same manner as that of the leaf node. First, in step S310, the number of branch nodes (natural numbers) existing in the network is set in the variable M, and then in step S311 each branch node requests the root node for the node number. In response to this request, the root node arbitrates in step S312, gives one branch node in step S313 a younger number following the leaf node, and the branch node that could not get the node number shows acquisition failure. Notify.

The branch node, which has learned from the determination in step S314 that the acquisition of the node number has failed, repeats the request for the node number again in step S311. On the other hand, the branch node whose node number has been acquired notifies all the nodes by broadcasting the ID information including the acquired node number in step S315. When the broadcast of the ID information is completed, the variable M representing the number of branches is decremented in step S316. Then, according to the determination in step S317, the steps from steps S311 to S316 are repeated until the variable M becomes "0", the ID information of all the branch nodes is broadcast, and then the process proceeds to step S318 to proceed to the ID of the root node. Move on to settings.

When the process is completed up to this point, the root node is the only node for which the ID has not been finally acquired. Therefore, in step S318, the youngest number not given to other nodes is set as the own node number, and in step S319, the youngest number is set as the own node number. Broadcast the ID information of the root node.

This completes the procedure until the IDs of all the nodes are set. Next, a specific procedure of the node ID determination sequence will be described using the network example shown in FIG.

In the network shown in FIG. 10, node A and node C are directly connected below node B, which is the root, node D is directly connected below node C, and node E and node are directly below node D. It has a hierarchical structure in which F is directly connected. The procedure for determining the hierarchical structure, root node, and node ID is as follows.

After the bus reset occurs, a parent-child relationship is declared between the ports directly connected to each node in order to recognize the connection status of each node. The term "parent-child" as used herein means that the upper part of the hierarchical structure is "parent" and the lower part is "child". In Figure 10, node A was the first to declare a parent-child relationship after a bus reset. As mentioned above, the declaration of parent-child relationship can be started from the node (leaf) to which only one port is connected. This means that if the number of ports is "1", it is recognized that it is the end of the network tree, that is, the leaf node, and the parent-child relationship is determined from the node that operates earliest among those leaf nodes. Become. The port of the node that declares the parent-child relationship in this way is set as the "child" of the two nodes connected to each other, and the node of the other node is set as the "parent". In this way, the "child-parent" relationship is set between the node AB, the node ED, and the node FD.

Further, the hierarchy is raised by one, and the parent-child relationship is declared to the higher-level nodes in order from the node having a plurality of ports, that is, the node that has received the parent-child relationship declaration from another node among the branch nodes. In FIG. 10, after the parent-child relationship between node DE and DF is first determined, node D declares a parent-child relationship with node C, and as a result, a "child-parent" relationship is set between node DC. Node. Upon receiving a parent-child relationship declaration from node D, node C declares a parent-child relationship to node B connected to another port, which establishes a "child-parent" relationship between node CBs. Node.

In this way, a hierarchical structure as shown in FIG. 10 is configured, and the node B that is the parent of all the ports that are finally connected is determined to be the root node. Note that there is only one root node in one network configuration. Also, if node B, which has declared a parent-child relationship from node A, promptly declares a parent-child relationship to another node, there is a possibility that another node, such as node C, will become the root node. .. That is, depending on the timing at which the declaration of the parent-child relationship is transmitted, any node may become the root node, and even if the network configuration is the same, a specific node does not necessarily become the root node.

When the root node is determined, the determination mode of each node ID is entered. All nodes have a broadcast function that notifies all other nodes of their own ID information that has been determined. The ID information is broadcast as ID information including node number, connected position information, number of ports possessed, number of connected ports, parent-child relationship information of each port, and the like.

The allocation of the node number is started from the leaf node as described above, and the node numbers = 0,1,2, ... Are assigned in order. Then, by broadcasting the ID information, it is recognized that the node number has already been assigned.

When all the leaf nodes have acquired the node numbers, the next step is to move to the branch node and the node numbers following the leaf nodes are assigned. Similar to the leaf node, the ID information is broadcast in order from the branch node to which the node number is assigned, and finally the root node broadcasts its own ID information. Therefore, the root node always owns the highest node number.

As described above, the ID setting of the entire hierarchical structure is completed, the network configuration is constructed, and the bus initialization work is completed.

[Control information for node management] As a basic function of the CSR architecture for node management, the CSR core shown in FIG. 4 exists on the register. The positions and functions of these registers are shown in Fig. 11, and the offsets in the figure are relative to 0xFFFFF0000000.

In the CSR architecture, registers related to the serial bus are arranged from 0xFFFFF0000200. The positions and functions of these registers are shown in Fig. 12.

Further, information on the node resource of the serial bus is arranged at a place starting from 0xFFFFF0000800. The positions and functions of these registers are shown in Fig. 13.

In the CSR architecture, a configuration ROM is provided to represent the function of each node, and this ROM has a minimum format and a general format, and is arranged from 0xFFFFF0000 400. In the minimum form, it only represents the vendor ID as shown in FIG. 14, and this vendor ID is a unique value in the world represented by 24 bits.

The general format is as shown in FIG. 15 and has information about the node. In this case, the vendor ID can be stored in the root directory (root_directory). In addition, the bus info block and root leaf have a 64-bit worldwide device number including the vendor ID. This device number is used to continue recognizing the node after a reconfiguration such as a bus reset.

[Serial Bus Management] As shown in FIG. 3, the 1394 serial bus protocol is composed of a physical layer 811 and a link layer 812 and a transaction layer 814. Among them, bus management provides basic functions for node control and bus resource management based on the CSR architecture.

A node that manages a bus (hereinafter referred to as a "bus management node") exists only on the same bus and provides a management function to other nodes on the serial bus. The management function includes a cycle master. Control, performance optimization, power supply management, transmission speed management, configuration management, etc.

[0073] The bus management function can be roughly divided into three functions: a bus manager, a synchronous (isochronos) resource manager, and a node control. Node control is a management function that enables inter-node communication in physical layer 811, link layer 812, transaction layer 814 and applications through CSR. The synchronous resource manager is a management function required for synchronous data transfer on the serial bus, and manages the transfer bandwidth and channel number allocation of synchronous data. To perform this management, the bus management node is dynamically selected from the nodes having the synchronous resource manager function after the bus is initialized.

Further, in a configuration in which a bus management node does not exist on the bus, a node having a synchronization resource manager function performs some functions of bus management such as power management and cycle master control. Furthermore, bus management is a management function that provides a service that provides a bus control interface to an application, and the control interface includes a serial bus control request (SB_CONTROL.request) and a serial bus event control confirmation (SB_CONTROL.confirmation). ), There is a serial bus event notification (SB_EVENT.indication).

The serial bus control request is used when an application requests a bus reset, a bus initialization, a bus status information, or the like from an application to a bus management node. The serial bus event control confirmation is the result of the serial bus control request, and the bus management node notifies the application of the confirmation. The serial bus event notification is for notifying the application of an event that occurs asynchronously from the bus management node.

[Data Transfer Protocol] In the data transfer of the 1394 serial bus, synchronous data (synchronous packet) that needs to be transmitted periodically and asynchronous data (asynchronous packet) that allows data transmission / reception at arbitrary timing are simultaneously transmitted. It exists and guarantees the real-time nature of synchronized data. In data transfer, a bus arbitration is performed to request a bus usage right and obtain a bus usage permission prior to the transfer.

In asynchronous transfer, the transmitting node ID and the receiving node ID are transmitted as packet data together with the transfer data. When the receiving node confirms its own node ID and receives the packet, it returns an acknowledge signal to the transmitting node to complete one transition.

In synchronous transfer, the transmitting node requests a synchronous channel along with the transmission rate, and the channel ID is sent as packet data together with the transfer data. The receiving node confirms the desired channel ID and receives the data packet. The number of channels required and the transmission rate are determined by application layer 816.

These data transfer protocols are defined by three layers: physical layer 811 and link layer 812 and transaction layer 814. Physical layer 811 performs physical and electrical interaction with the bus, automatic recognition of node connections, bus arbitration of bus usage rights between nodes, and so on. Link layer 812 performs cycle control for addressing, data checking, packet transmission / reception, and synchronous transfer. Transaction layer 814 performs processing related to asynchronous data. The processing in each layer will be described below.

[Physical Layer] Next, the bus arbitration in the physical layer 811 will be described.

The 1394 serial bus always arbitrates the bus usage right prior to data transfer. Each device connected to the 1394 serial bus constitutes a logical bus-type network that transmits the signal to all devices in the network by relaying the signal transferred on the network, so that packet collisions occur. Bus arbitration is necessary to prevent. This allows only one node to make a transfer at a given time.

FIG. 16 is a diagram for explaining a request for a bus use right, and FIG. 17 is a diagram for explaining a bus use permission. When bus arbitration begins, one or more nodes request the parent node to use the bus, respectively. In FIG. 16, node C and node F request the right to use the bus. The parent node (node A in FIG. 16) that receives this request further requests the parent node for the right to use the bus, thereby relaying the request for the right to use the bus by node F. This request is finally delivered to the root node performing the arbitration.

The root node that receives the request for the right to use the bus decides which node to give the right to use the bus. This arbitration work can only be performed by the root node, and the node that wins the arbitration is given permission to use the bus. FIG. 17 shows a state in which node C has been granted permission to use the bus and node F's request for the right to use the bus has been denied.

The root node sends a DP (dataprefix) packet to the node that has lost the bus arbitration to notify that the request for the right to use the bus has been denied. The request for the right to use the bus of the node that lost the bus arbitration will be kept waiting until the next bus arbitration.

As described above, the node that has won the arbitration and obtained the permission to use the bus can start the data transfer thereafter. Here, a series of flow of bus arbitration will be described with reference to the flowchart shown in FIG.

The bus must be idle in order for the node to be able to initiate data transfer. In order to confirm that the previously started data transfer has finished and the bus is currently idle, a predetermined idle time gap length (eg, sub-action gap) that is individually set for each transfer mode. When a predetermined gap length is detected, each node determines that the bus has become idle. In step S401, each node determines whether or not a predetermined gap length corresponding to the data to be transferred, such as asynchronous data and synchronous data, has been detected. Unless a given gap length is detected, the bus usage rights required to initiate the transfer cannot be requested.

When a predetermined gap length is detected in step S401, each node determines whether there is data to be transferred in step S402, and if so, uses a signal requesting the right to use the bus in step S403 as the route. Send to. As shown in FIG. 16, the signal representing the request for the right to use the bus is relayed to each device in the network and finally delivered to the root node. If it is determined that there is no data to be transferred in step S402, the process returns to step S401.

When the root node receives one or more signals requesting the right to use the bus in step S404, the root node checks the number of nodes requesting the right to use the bus in step S405. According to the determination in step S405, if there is only one node for which the right to use is requested, that node is given the permission to use the bus immediately after. If there are a plurality of nodes for which usage rights have been requested, arbitration work is performed in step S406 to narrow down the nodes to which the bus usage permission is granted immediately after. This arbitration work does not give permission to use the bus only to the same node every time, but gives permission to use the bus equally (fair arbitration).

[089] In step S407, the processing of the root node branches according to one node that has won the arbitration in step S406 and the other node that has lost. If there is one node that has won the arbitration or one node that has requested the right to use the bus, a permit number indicating the permission to use the bus is sent to that node in step S408. The node that receives this permission signal starts the transfer of the data (packet) to be transferred immediately after (step S410). In step S409, a DP (data prefix) packet indicating that the request for bus usage right has been denied is sent to the node that has lost the arbitration. The processing of the node that received the DP packet returns to step S401 to request the right to use the bus again. The processing of the node for which the data transfer in step S410 has been completed also returns to step S401.

[Transaction Layer] There are three types of transactions: read transaction, write transaction, and lock transaction.

In a read transaction, the initiator (request node) reads data from a specific address in the memory of the target (response node). In a write transaction, the initiator writes data to a specific address in the target memory. In the lock transaction, reference data and update data are transferred from the initiator to the target. The reference data is combined with the data of the target address to become a designated address indicating a specific address of the target. Then, the data at this designated address is updated by the update data.

FIG. 19 is a diagram showing a request / response protocol for each command of read, write, and lock based on the CSR architecture at transaction layer 814. The request, notification, response, and confirmation shown in the figure are services at transaction layer 814. It is a unit.

A transaction request (TR_DATA.request) is a packet transfer to a response node, a transaction notification (TR_DATA.indication) is a notification that a request has arrived at the response node, and a transaction response (TR_DATA.response) is an acknowledge transmission, a transaction. Confirmation (TR_DATA.confirmation) is the receipt of an acknowledge.

[Link Layer] FIG. 20 is a diagram showing a service in the link layer 812, which is a link request requesting the transfer of a packet to the response node (LK_DATA.request) and a link notification notifying the response node of receiving the packet (LK_DATA. It is divided into service units of indication), link response (LK_DATA.response) for packet transmission from the response node, and link confirmation (LK_DATA.confirmation) for packet transmission from the request node. One packet transfer process is called a sub-action, and there are two types: asynchronous sub-action and synchronous sub-action. The operation of each sub-action will be described below.

[Asynchronous Sub-Action] The asynchronous sub-action is an asynchronous data transfer. FIG. 21 is a diagram showing a temporal transition in asynchronous transfer. The first sub-action gap shown in FIG. 21 indicates the idle state of the bus. When the idle time reaches a predetermined value, the node wishing to transfer data requests the right to use the bus, and bus arbitration is executed.

When the use of the bus is permitted by the bus arbitration, the data is then packet-transferred, and the node that receives this data returns a reception confirmation return code ACK after a short gap called an ACK gap and responds. Data transfer is completed by returning the response packet. An ACK consists of 4-bit information and a 4-bit checksum, which contains information indicating success, busy state, or pending state, and is immediately returned to the node that sent the data.

FIG. 22 is a diagram showing a format of an asynchronous transfer packet. The packet has a header part in addition to the data part and the data CRC for error correction, and the target node ID, the source node ID, the transfer data length, various codes, and the like are written in the header part.

Asynchronous transfer is one-to-one communication from a transmitting node to a receiving node. Packets sent from the source node are distributed to each node in the network, but each node ignores packets other than those addressed to itself, so only the node specified as the destination receives the packet.

[Split Transaction] The service at the transaction layer 814 is performed by the set of transaction request and transaction response shown in FIG. Here, if the processing at the link layer 812 and the transaction layer 814 of the target (response node) is sufficiently fast, the request and the response are not processed by the independent sub-actions of the link layer 812, but are processed by one sub-action. Will be possible. However, if the target is slow, the request and response must be processed in separate transactions. And this operation is called a split transaction.

FIG. 23 is a diagram showing an operation example of a split transaction, in which the target returns pending in response to a write request from the controller of the initiator (request node). This allows the target to return confirmation information for the controller's write request, giving it time to process the data. Then, after a sufficient time has passed for data processing, the target notifies the controller of the write response and ends the write transaction. The link layer 812 can be operated by another node between the request and response sub-actions at this time.

FIG. 24 is a diagram showing an example of a temporal transition of a transfer state when a split transaction is performed. Sub-action 1 represents a request sub-action, and sub-action 2 represents a response sub-action.

[0102] In sub-action 1, the initiator sends a data packet representing a write request to the target, and the target that receives the data packet returns the pending indicating the above confirmation information by the acknowledge packet, and the request sub-action ends.

Then, after the sub-action gap is inserted, in sub-action 2, the target sends a write response in which the data packet has no data, and the initiator that receives this sends a complete response in the acknowledge packet to return a response sub. The action ends.

The minimum time from the end of sub-action 1 to the start of sub-action 2 is the time corresponding to the sub-action gap, and the maximum can be extended to the maximum waiting time set in the node. ..

[Synchronization Sub-Action] This synchronous transfer, which can be said to be the greatest feature of the 1394 serial bus, is particularly suitable for the transfer of data that requires real-time transfer such as AV data. Further, while asynchronous transfer is one-to-one transfer, this asynchronous transfer can uniformly transfer data from one source node to all other nodes by the broadcast function.

FIG. 25 is a diagram showing a temporal transition in synchronous transfer, in which synchronous transfer is executed at regular time intervals on a bus, and this time interval is called a synchronous cycle. The synchronization cycle time is 125 μs. The cycle start packet (CSP) 2000 is responsible for indicating the start of this synchronization cycle and synchronizing the operations of each node. It is the node called the cycle master that sends the CSP2000, and after the transfer within the previous cycle ends and the predetermined idle period (sub-action gap 2001) elapses, the CSP2000 that announces the start of this cycle is sent. To do. That is, the time interval at which this CSP2000 is transmitted is 125 μS.

Further, as shown in FIG. 25 as channel A, channel B, and channel C, it is possible to distinguish and transfer these packets by giving channel IDs to a plurality of types of packets in one synchronization cycle. it can. As a result, real-time transfer is possible between a plurality of nodes at substantially the same time, and the receiving node need only receive the data of the desired channel ID. This channel ID does not represent the address of the receiving node or the like, but is merely a logical number for the data. Therefore, a certain packet transmitted is distributed from one source node to all other nodes, that is, it is broadcast.

[0108] Prior to packet transmission by synchronous transfer, bus arbitration is performed in the same manner as asynchronous transfer. However, unlike asynchronous transfer, it is not one-to-one communication, so there is no ACK of the return code for confirmation of reception in synchronous transfer.

[0109] Further, the iso gap (synchronous gap) shown in FIG. 25 represents an idle period required for confirming that the bus is in an idle state before performing synchronous transfer. The node that detects this predetermined idle period determines that the bus is in an idle state, and requests the right to use the bus when it wants to perform synchronous transfer, so that bus arbitration is performed.

FIG. 26 is a diagram showing an example of a packet format for synchronous transfer. Each of the various packets divided into each channel has a header part in addition to the data part and the data CRC for error correction, and the header part has the transfer data length, channel number, etc. as shown in FIG. 27. Various codes and header CRC for error correction are written.

[Bus Cycle] In fact, synchronous transfer and asynchronous transfer can be mixed in the 1394 serial bus. FIG. 28 is a diagram showing a temporal transition of the transfer state when synchronous transfer and asynchronous transfer are mixed.

Here, as described above, the synchronous transfer is executed with priority over the asynchronous transfer. The reason is that after CSP, synchronous transfer can be initiated with a gap (isochronous gap) shorter than the idle period gap (sub-action gap) required to initiate asynchronous transfer. Therefore, synchronous transfer is prioritized over asynchronous transfer.

In the general bus cycle shown in FIG. 28, the CSP is transferred from the cycle master to each node at the start of cycle # m. The operation of each node is synchronized by the CSP, and the node that tries to perform synchronous transfer after waiting for a predetermined idle period (synchronous gap) participates in bus arbitration and enters packet transfer. In FIG. 28, channel e, channel s, and channel k are sequentially transferred synchronously.

[0114] After repeating the operation from bus arbitration to packet transfer for a given channel, when all the synchronous transfers in cycle #m are completed, asynchronous transfer can be performed. In other words, when the idle time reaches the sub-action gap that allows asynchronous transfer, the node that wants to perform asynchronous transfer participates in bus arbitration. However, asynchronous transfer is possible only when a sub-action gap for invoking asynchronous transfer is detected between the end of synchronous transfer and the time when the next CSP should be transferred (cycle synch). ..

In cycle # m shown in FIG. 28, two packets (packet 1, packet 2) including ACK are transferred by asynchronous transfer after synchronous transfer for three channels. After this asynchronous packet 2, the time to start cycle m + 1 (cycle synch) is reached, so the transfer in cycle # m ends here. However, when the time to send the next CSP (cycle synch) is reached during asynchronous or synchronous transfer, the transfer is not forcibly interrupted, and after the transfer is completed, the CSP for the next synchronous cycle is transmitted after an idle period. To do. That is, when one synchronization cycle continues for 125 μs or more, the extension of the synchronization cycle shortens the next synchronization cycle from the standard 125 μs. In this way, the synchronization cycle can be exceeded or shortened based on 125 μs.

However, the synchronous transfer is executed every cycle if necessary in order to maintain the real-time transfer, and the asynchronous transfer may be postponed to the next and subsequent synchronous cycles due to the shortened synchronous cycle time. The cycle master also manages such delay information.

[FCP] In the AV / C protocol, a functional control protocol (FCP) is prepared for controlling a device on a 1394 serial bus. Asynchronous packets specified by IEEE1394 are used for sending and responding to FCP control commands. In FCP, the node on the control side is called the controller, the node on the controlled side is called the target, the FCP packet frame sent from the controller to the target is the AV / C command frame, and conversely the FCP packet frame returned from the target to the controller is AV. Called / C response frame.

FIG. 29 shows a case where node A is a controller and node B is a target. Of the register addresses prepared for each, 512 bytes from address 0x0000B00 is a command register, and 512 bytes from address 0x0000D00 is a response register. Data is written to the register at the specified address by each packet frame using asynchronous transfer. The relationship between the transmission of the AV / C command frame by the controller and the response of the AV / C response frame by the target at this time is called an AV / C transaction. In a typical AV / C transaction, the target needs to respond to the controller with a response frame within 100ms of receiving the command frame.

FIG. 30 is a diagram showing a packet format of asynchronous transfer including an FCP packet frame, in which a command frame or a response frame is inserted into the data area of the asynchronous data packet shown in FIG. 22 to perform an AV / C transaction. Will be executed.

FIG. 31 is a diagram showing the structure of the AV / C command frame, and FIG. 32 is a diagram showing the structure of the AV / C response frame. As the FCP packet frame, the header ctype, response, subunit_type, and subunit_ID are followed by the FCP. It has a structure in which the data parts of are connected.

[0121] ctype indicates a command type in a command frame, and indicates each state of CONTROL, STATUS, INQUIRY, and NOTIFY.

[0122] response indicates a response code in the response frame, and indicates each state such as ACCEPTED, REJECTED, IN_TRANSITION, IMPLEMENTED, CHANGED, and INTERIM.

Further, subunit_type indicates the device classification, and subunit_ID indicates the instance number.

The data portion of the FCP has an opcode + operand configuration, and can control the target using various AV / C commands and respond to the AV / C response.

The opcode in the command frame is one of the command groups shown in the command column shown in FIG. 50, and each command is executed according to the command type set in ctype.

The command in which "CONTROL" is specified by the ctype means a control command, controls the target device, and sets the target with the contents set after the operand (oprand). A command for which "STATUS" is specified by ctype is for obtaining the status corresponding to the command. The command for which "INQUIRY" is specified by ctype is for inquiring the contents that can be set by the command. The command for which "NOTIFY" is specified for ctype is for confirming the command.

[0127] For each command, the contents required for each command are set in the operands and written in the command frame.

[0128] The response code shown in the response column of FIG. 50 is set as the operation code in the response frame. Each response has an operand corresponding to each response. Information indicating whether the command execution ended normally or ended with an error is set in the response operand, so error processing can be performed according to this operand.

【０１２９】

[LOGIN protocol] [Communication using LOGIN protocol] Fig. 33 is a diagram comparing the interface of the 1394 serial bus with each layer of the OSI model often used in LAN. The physical layer 1 and the data link layer 2 of the OSI model correspond to the physical layer 811 and the link layer 812, which are the lower layers 4 of the interface of the 1394 serial bus. The transport protocol layer 5 and the presentation layer 6 in the interface of the 1394 serial bus existing on the lower layer 4 correspond to the upper layer 3 including the network layer, the transport layer, the session layer, and the presentation layer of the OSI model. Further, the LOGIN protocol 7 operates between the lower layer 4 of the interface of the 1394 serial bus and the transport protocol layer 5.

[0130] In Example 1 shown in FIG. 33, a device conforming to the serial bus protocol (SBP-2) 8 for a peripheral device such as a printer is provided with the LOGIN protocol 7 so that the other device is SBP-2. You can be notified that you want to exchange data using a compliant protocol.

[0131] In Example 2 shown in FIG. 33, the device protocol 9 specialized on the interface of the 1394 serial bus is also provided with the LOGIN protocol 7, so that the devices support each other's protocols. Can be discriminated.

FIG. 34 is a diagram showing the basic operation of the LOGIN protocol 7. When the printer device executes the print task 10 from the host device, first, the printer protocol A prepared in the printer, Which of B and C is selected for exchanging print data is determined based on the communication by the LOGIN protocol 7, and then the print data is exchanged according to the determined printer protocol. That is, when connecting to a host device, a printer device that supports several printer protocols first determines the transport protocol 5 provided in the host device by the LOGIN protocol 7, and then determines the transport protocol of the host device. Print task 10 is processed by selecting a printer protocol that matches 5 and exchanging print data and commands according to the selected printer protocol.

FIG. 35 is a diagram showing an example of a connection form in a 1394 serial bus, in which a device (PC 12, scanner 13, DVC14 etc.) is connected. The printer 11 can process the printing task from each device without any problem by switching the printer protocol according to the transport protocol 5 of the remote device requesting the connection, which is determined by the LOGIN protocol 7.

FIG. 36 is a diagram showing a flow of login operation. In step 1: The host device locks the target device (in this case a multi-protocol printer). The target device examines the capabilities of the host device (including the transport protocol), and such capabilities are stored in register 503, which will be described later.

In step 2: The print data is communicated according to the protocol set in step 1.

In step 3: The host device disconnects from the target device.

FIG. 37 shows the CSR of the 1394 serial bus provided by the printer, which is the target device for the LOGIN protocol 7, and shows the lock register (lock) 501, protocol register (protocol) 502, and capability register (capability) 503. ing. These registers are located at defined addresses in the initial unit space in the address space of the 1394 serial bus. That is, as explained with reference to FIG. 4, of the 48 bits of the address width given to the device, 0xFFFFF in the first 20 bits is called the register space, and the first 512 bytes of the register (the register that becomes the core of the CSR architecture). CSR core) is located.

The lock register 501 indicates the locked state of the resource, a value 0 indicates a log-inable state, and a value other than 0 indicates that the resource has already been logged in in the locked state. The capability register 503 indicates a protocol that can be set for each bit, indicates that the protocol corresponding to the bit with the value '1' can be set, and the protocol corresponding to '0' cannot be set. Represents. 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'. FIG. 38 is a flowchart showing the login process in the host device.

[0139] In order to start login, first, the data of the target device to be logged in, for example, the lock register 501, the protocol register 502, and the capability register 503 of the printer is confirmed by a read transaction. Here, from the data in the capability register 503, it is confirmed whether or not the target device supports the protocol used by the host device for communication (step S601).

If the host device protocol is not supported by the target device, login is aborted in the next step S602. If the data in the lock register 501 is other than "0", it is considered that another device is logged in and the login is canceled. If the data in the login register 501 is "0", it is considered that login is currently possible (step S602).

[0141] If login is possible, the process proceeds to resource lock processing, and for example, "1" is written to the lock register 501 of the printer using a lock transaction to set login (step S603). In this state, the target device is locked, control from other devices is not possible, and registers cannot be changed.

[0142] With the resources of the target device locked as described above, the protocol is set next. Since the printer of this embodiment, which is the target device, supports a plurality of printer protocols, it is necessary to know the protocols that can be used by the host device before receiving the print data. In this embodiment, the printer is notified of the protocol to be used from now on by setting the corresponding bit of the protocol register 502 of the printer by the write transaction of the host device (step S604).

At this point, the protocol used by the host device for communication is notified to the target device, and the target device is in the locked state. Therefore, the host device currently logged in to the target device transmits data, in this case print data. (Step S605).

When the transmission of data is complete, the host device logs out of the printer by clearing the lock register 501 and the protocol register 503 of the target device (step S606).

FIG. 39 is a flowchart showing a login process of a printer as a target device. The printer is usually in a state of waiting for login from the host device. Since the print request from the host device is started by reading the lock register 501, the protocol register 502, and the capability register 503 of the printer, it is necessary to keep the register readable by other devices at all times.

[0146] Suppose the printer is now locked by a host device that is about to perform a printout (step S701). The printer then waits for the host device to inform it of the protocol used (step S702). The reason why the printer waits for the notification of the protocol to be used after it is locked is to prevent the protocol register 503 from being rewritten by a request from another device during login.

When notified of the protocol used (step S703), the printer switches its protocol to the notified protocol used (steps S704, S706 and S708) and communicates according to the protocol of the host device. (Steps S705, S707 or S709).

When the communication is completed, the printer confirms that the lock register 501 and the protocol register 503 have been cleared (step S710), and returns to the state of waiting for login (step S701).

[Example in which a device having no LOGIN protocol is considered] FIG. 40 is a diagram illustrating an example in which a device in which the LOGIN protocol 7 is not implemented is considered, and is compared with the first example shown in FIG. 34. The feature is that it also supports devices that do not have LOGIN protocol 7 and have protocol D. That is, in order to guarantee printing operation not only for devices having LOGIN protocol 7 but also for devices supporting only existing protocol D (for example, AV / C protocol), LOGIN protocol 7 is provided on the printer side. It adds a printer protocol for devices that do not have it.

Explaining this operation, if the printer recognizes that the host device does not support LOGIN protocol 7 by the print request made at the beginning of the connection, the printer uses protocol D to communicate with the host device. If an attempt is made and communication is established, the print task 10 is executed according to the protocol D.

FIG. 41 is a diagram comparing the configuration shown in FIG. 40 with each layer of the OSI model, and Example 3 is an AV device 15 conforming to the current AV / C protocol in which the LOGIN protocol 7 is not implemented. Is a model. Example 4 is modeled on a scanner 16 that implements a non-standard protocol for scanners that do not implement LOGIN protocol 7.

That is, even for a device having a protocol that does not implement the LOGIN protocol 7, if the printer can support the protocol of the device, the types of devices that can use the printer can be expanded. ..

【０１５３】

[Direct Print Protocol] The printing procedure between the printer and the image supply device according to the present invention will be described below. However, the printer and the image supply device are directly connected to form an image based on the image data supplied from the image supply device. The protocol used by the printer is called "Direct Print Protocol (DPP)".

[0154] The basis of DPP is a command register (command) for writing a command and a response register (response) for writing a response to a command in the initial unit space (shown in the unit space of FIG. 4) of the 1394 serial bus. ), A data register (data) for writing transfer data, and a format register (format) for handling format information corresponding to each data format of transfer data.

FIG. 42 is a diagram showing this register map, and the command register and the response register are the same as those described with reference to FIG. 29. In the following description, an example will be described in which the image supply device is the controller and the printer is the target, and the image data is supplied from the image supply device to the printer to print the image.

[0156] The command register 42-1 is arranged at a fixed address of 0xFFFFF0000B00 on the printer side, has a memory space of 512 bytes, and is for the image supply device to write various commands to the printer. Of course, if the command register is also on the image supply device side, it is possible to write commands from the printer. The command written in the command register 42-1 is called a command frame.

The response register 42-2 is located at a fixed address of 0xFFFFF0000D00 on the image supply device side, has a memory space of 512 bytes, and writes responses to various commands written from the image supply device to the printer. It is for being caught. Of course, if the response register is also on the printer side, it is possible to write the response from the image supply device. The response written in the response register 42-2 is called a response frame. In FIG. 29, the upper 0xFFFF of the address is omitted.

[0158] The data register 42-3 is set to an arbitrary address valid by the BlockAddress and BufferConfig commands (commands that define the address of the data register) with FFFFFF0003000h as the default address. The memory space of the data register 42-3 is set within a range determined in advance by the BlockSize and BufferConfig commands (commands that define the memory space of the data register). The data register 42-3 is a register for transferring data between the image supply device and the printer, and when printing is performed, print data is written from the image supply device to the printer. For print data, the data written in the data register 42-3 according to the data format of the preset image format is called a data frame.

[0159] The format register 42-4 is a collection of register groups corresponding to each data format described later, and each register is a register for setting format information required for each data format. That is, the format register 42-2 is a register for writing format information from the image supply device to the printer. The format information written in the format register 42-2 is called a format frame.

FIG. 43 is a diagram showing the flow of frames from the image supply device to the printer, showing the flow of command frames, response frames, data frames, and format frames, and the printer prints according to the frames output from the image supply device. Do.

The command sent from the image supply device to the printer is written as a command frame in the command register 43-4 of the printer. This command is a command for printing as shown in FIG. 50. The response to this command is written by the printer to the response register 43-2 of the image supply device. This response includes information indicating whether the command was executed correctly, a return value for the command, and so on. The print data sent from the image supply device to the printer is written to the printer's data register 43-6 as a data frame. The format information sent from the image supply device to the printer is written in the format register 43-7 of the printer as a format frame.

FIG. 44 is a diagram showing a configuration example of the format register 43-7. The format register 43-7 is divided into a read-only register INQUIRY 44-1 for inquiry and a read / write register CONTROL / STATUS 44-2 for setting and information acquisition. INQUIRY 44-1 and CONTROL / STATUS 44-2 are composed of register groups having the same configuration. That is, the registers 44-3 to 44-7 and the registers 44-9 to 44-13 that make up the register group.

More specifically, the format register groups are the registers 44-3 and 44-4 (44-9 and 44-10) that make up the print common register group, and the printer format register group (print). It is composed of registers 44-5 to 44-7 (44-11 to 44-13) that make up the format register group).

A common register group is a register group that collects registers common to all data formats, and is a register GLOBAL 44-3 (44-9) common to all printers and a register LOCAL unique to each printer. It is composed of 44-4 (44-10).

The printer format register group is a group of registers that collects information unique to each data format, and the registers format [1] 44-5 (44-11) to format [n] 44-7 (44-13). It consists of up to n registers. The registers format [1] to format [n] correspond to the data formats described later, and one printer format register group is assigned to each data format to be implemented.

The address of each format register is given to the image supply device as a response to a command for setting the data format.

FIG. 45 is a diagram showing a detailed configuration example of the status register status register 44-8 of the common register group. Status registers 44-8 are 32-bit each, a common status register 45-1 that holds the status common to each vendor's printer, and a vendor-specific status (vendor) that holds the status defined by each vendor. It consists of specific status register) 45-2. In addition, the v flag (vendor status available flag) in the 31st bit of the common status register 45-1 defines the extension to the vendor-specific status register 45-2 as follows.<img file="000002.tif" id="000002" he="015" wi="061" img-format="tif" img-content="drawing" />

[0168] Further, the information held in the common status register 45-1 is as follows. error.warning: Status of error, warning, etc. paper state: Status of chart paper print state: Status of print status

FIG. 46 is a diagram showing a detailed example of information held in the register GLOBAL 44-3 (44-9) of the common register group. Register GLOBAL 44-3 (44-9) is a register that holds information common to all printers equipped with DPP (Direct Print Protocol), that is, collects information that does not differ depending on the printer type. Figure 46 shows an example of this: media-type 46-1, which indicates the type of recording medium, paper-size 46-2, which indicates the size of the recording paper, page-margin 46-3, which indicates the page margin value, and page. Page-length 46-4 for length, page-offset 46-5 for page offset, print-unit 46-6 for printer unit information, color-type 46-7 for printer color type, data Includes bit-order 46-8, etc., which indicates the bit order of.

FIG. 47 is a diagram showing a detailed example of information held in the register LOCAL 44-4 (44-10) of the common register group. Register LOCAL 44-4 (44-10) is a register that holds unique information for each printer model equipped with DPP, that is, collects information that differs depending on the printer type. FIG. 47 shows an example thereof, and includes paper 47-1 showing a printer-specific recording paper type, CMS 47-2 showing a color matching method, and ink 47-3 showing an ink type of an inkjet printer, for example.

FIG. 48 is a diagram showing an example of information held in the register format [1] 44-5, which is an example in which information related to EXIF (Exchangeable Image File Format), which is one of the image data formats, is held. .. In this case, the input X-direction ratio inX-rate 48-1, the input Y-direction ratio inY-rate 48-2, the output X-direction ratio outX-rate 48-3, the output Y-direction ratio outY- Includes rate 48-4. In this case, printing is possible by scaling the given EXIF format image data in the XY directions according to the contents of each register.

FIG. 49 is a diagram showing an example of information held in the register format [2] 44-6, and is an example in which information related to the Raw RGB format, which is one of the image data formats, is held. Raw RGB format makes each pixel R (red), G (green), It is an image format composed of B (blue) data. In this case, the ratio in the X direction of the input inX-rate 49-1, the ratio in the Y direction of the input in Y-rate 49-2, the ratio in the X direction of the output outX-rate 49-3, the ratio in the Y direction of the output outY- rate 49-4, XY-size 49-5 indicating the fixed pixel size of XY, bit-pixel 49-6 indicating the number of bits per pixel, X-size 49-7 indicating the number of pixels in the X direction, pixels in the Y direction Y-size 49-8 indicating the number, plane 49-9 indicating the number of color planes, X-resolution 49-10 indicating the resolution in the X direction, Y-resolution 49-11 indicating the resolution in the Y direction, and the pixel type Including pixel-format 49-12 etc. shown. In this case, the given Raw RGB format image data can be printed by scaling and resolution conversion in the XY direction according to the contents of each register, and further processing based on information related to the image size. Become.

FIG. 50 is a diagram showing a command and a list of responses to the command. Commands are classified into several types. The classifications are "status" related to status, "control" for printer control, "block / buffer" for data transfer settings, "channel" for channel settings, "transfer" for transfer methods, and format settings. There are "format" about "format", "login" about login and "data" about data transfer.

[0174] More specifically, the "status" includes a command GetStatus for obtaining the status of the printer and its response GetStatusresponse 50-1.

Control includes a command PrintReset and its response PrintResetResponse 50-2 for resetting the printer, PrintStart and its response PrintStartResponse 50-3 for instructing the start of printing, and PrintStop and its response PrintStopResponse for instructing the stop of printing. 50-4, InsertPaper and its response instructing the supply of chart paper InsertPaperResponse 50-5, EjectPaper and its response instructing the ejection of chart paper EjectPaperResponse 50-6, CopyStart and its response instructing the start of copying image data CopyStartResponse 50 -7, and CopyEnd and its response CopyEndResponse 50-8, which indicate the end of copying the image data.

Block / buffer includes BlockSize and its response BlockSizeResponse 50-9, which specifies the size of the block, BlockAddress and its response BlockAddressResponse 50-10, which specifies the address of the block, FreeBlock and FreeBlock which obtains the number of free blocks. The response FreeBlockResponse 50-11, WriteBlocks and its response WriteBlocksResponse 50-12 that instruct to write data to the block, BufferConfig that specifies buffer information and its response BufferConfigResponse 50-13, and the start of data acquisition from the buffer. SetBuffer and its response SetBufferResponse 50-14 and so on.

[0177] Examples of the channel include an OpenChannel that opens the channel and its response OpenChannelResponse 50-15, and a CloseChannel that closes the channel and its response CloseChannelResponse 50-16.

[0178] Examples of the "transfer" include a Transfer Method for specifying a data transfer method and a response TransferMethod Response 50-17.

[0179] Examples of the "format" include SetFormat for setting the format and SetFormatResponse 50-18.

"Login" includes Login and its response LoginResponse 50-19 for logging in, Logout and its response LogoutResponse 50-20 for logging out, Reconnect and its response ReonnectResponse 50-21 for reconnection, and the like. ..

The above commands are written in the command frame.

[0182] Further, as "data", there are WriteBlock 50-22 and WriteBuffer 50-23 for writing data, PullBuffer 50-24 for reading data, and the like. These commands write and read data frames, and there is no corresponding response.

The image supply device sets a value corresponding to each command shown in FIG. 50 in the opcode of the command frame shown in FIG. 31 and writes the value to the command register 43-4 of the printer. Executes the command. The response to the command has the same value as the command. The printer sets the response in the operation code of the response frame shown in FIG. 32 and writes it in the response register 43-2 of the image supply device. By this response, the image supply device can receive the execution result of each command.

FIG. 51 is a diagram showing an example of an image data format supported by DPP. The printer must support at least one of these formats, raw image data. It can also optionally support multiple other formats.

FIG. 52 is a diagram showing a flow of a format setting process. First, the image supply device sends a SetFormat (INQUIRY) command to the printer in step S500, and the printer returns a SetFormat response in step S501. From the response returned, the image feeding device knows the address of the printer's INQUIRY register.

Next, the image supply device sends a SetFormat (CONTROL / STATUS) command to the printer in step S502, and the printer returns a SetFormat response in step S503. From the response returned, the image feeding device knows the address of the printer's CONTROL / STATUS register.

[0187] The image supply device reads the INQUIRY register of the printer in steps S504-1 to S504-m to know the format supported by the printer and the setting items of the format. Next, the image supply device reads the STATUS / CONTROL register of the printer in steps S505-1 to S505-n to know the format setting value, and in steps S506-1 to S506-n to the STATUS / CONTROL register of the printer. Write the data and set the format.

[0188] The following two types of packets are used for data transfer in DPP. -Control command packet for flow control -Packet for data transmission

[0189] In the present embodiment, five types of data transfer methods are listed below depending on the difference in flow control and data transmission method. In any of the methods, the control command for flow control conforms to FCP. .. Transfer method 1: Response Model Transfer method 2: Simplifed Response Model Transfer method 3: PUSH Large Buffer Model Transfer method 4: PULL Buffer Model Transfer method 5: Isochronous Model

In the actual transfer, one of the above methods is selected and set, and the procedure is the same as the format setting procedure shown in FIG. 52. As shown in FIG. 53, TransferMethod is used for the command and TransferMethodResponse is used for the response.

FIG. 53 is a diagram showing an example of a data transfer method setting procedure. The image supply device acquires the currently available printer data transfer method (S600-1 and S600-2) with the TrasferMethod command and response of command type INQUIRY, and is currently using the TransferMethod command and response of command type CONTROL / STATUS. , Acquire and set the data transfer method set in the printer (S600-3 and S600-4).

By the way, in any of the above five types of methods, the control command for flow control conforms to FCP, which is a protocol for controlling a device on the 1394 serial bus. The transfer of FCP control commands is always an asynchronous write transaction for both transmission and response.

FIG. 54 is a diagram showing a register map in the address space of the 1394 serial bus of the registers required for the transfer method 1 and the transfer method 2. In the present embodiment, the controlling node is an image supply device (corresponding to the controller in FCP), and the controlled node is a printer (corresponding to the target in FCP).

Both the image supply device and the printer have a command register (601-1 and 601-7) with an offset of 0x0B00 to 512 bytes in the register space and a response register (601-2 and 601-8) with an offset of 0x0D00 to 512 bytes. .. These registers comply with the FCP protocol and AV / C commands.

Flow control is performed by writing command frames 601-4 and response frames 601-5 to these command registers (601-1 and 601-7) and response registers (601-2 and 601-8). .. In addition, a dedicated data frame is defined for the transfer of print data. In other words, data registers (601-3 and 601-9) for the block size are provided from the register space offset 0x3000, and data frames 601-6 are written to the data registers (601-3 and 601-9) to print data. The transfer is done. The block size is, for example, 512 bytes.

FIG. 55 is a diagram showing an example of a data packet frame, which is composed of a data header 602-1, a data payload 602, and the like.

FIG. 56 is a diagram showing a configuration example of the data header 602-1. The upper 8 bits are the block count area 603-1 and the lower 8 bits are the reserved area S603-2 for the future. The block count area 603-1 is used internally by the target (printer) and is a counter that counts the number of blocks transferred by one block transfer. Since the block count area 603-1 is 8 bits, it can take a value from 0 to 255.

FIG. 57 is a diagram showing data packet frame processing in the printer in block transfer. The data packet received by the printer is first written to the data register 604-1 of the printer. The printer has buffers (604-2 to 604-1) of the same size as the data packets, and the data packets written to the data register 604-1 are sequentially sent to these buffers (604-2 to 604-1). Be transferred. The number of these data buffers is preferably 255, which is equal to the maximum value of the block count, but may be less than this. Here, each buffer corresponds to the block count value, data packets having a block count of "0" are placed in the buffer of Block [0], and data packets having a block count of "1" are placed in the buffer of Block [1]. , Stored. The data packets stored in the buffers (604-2 to 604-1) are expanded into the printer's memory space 604-6 after the data header 602-1 is removed.

[Transfer Method 1] In the transfer method 1 which is a Response Model, a data packet frame is defined for data transmission, a data register is provided, and print data is transferred by a write transaction while performing flow control by a control command. It is a method to do.

FIG. 58 is a diagram showing a FreeBlock command and a response in the transfer method 1. In transfer method 1, the FreeBlock command and response are used to acquire information indicating how many data packets the image supply device transfers prior to data transfer.

The image feeding device transfers the FreeBlock command in a write transaction (S605-1), and the printer returns an ACK packet indicating confirmation for that transaction (S605-2). The printer returns a FreeBlock response to signal the currently available FreeBlockCount (S605-3), and the image-feeding device returns an ACK packet confirming the transaction (S605-4).

FIG. 59 is a diagram showing an example of a data transfer flow in the transfer method 1. The image supply device logs in to the printer by the DPP Login command and response (S606-1 and S606-2), and uses the format register group described above to set the format used for data transfer (S606-3). Then open the logical channel with the OpenChannel command and response (S606-4 and S606-5). Subsequently, the data transfer is started, and the print data is transferred in the data packet format shown in FIG. 55. In addition, packet transfer is performed in one cycle for a number of blocks equal to the number of data buffers on the printer side shown by reference numerals 604-2 to 604-1 in FIG. 57.

[0203] The print data in the transfer method 1 is transferred as follows. The image supply device obtains the number of FreeBlocks of the printer by the FreeBlock command and response (S606-6 and S606-7), and sequentially transfers the same number of data packets as the number of FreeBlocks by WriteBlock (S606-8). WriteBlock is a command for transferring a packet for print data from the data register 601-3 shown in FIG. 54 to the data register 601-9. However, there is no response to the WriteBlock command, and the printer returns an ACK packet to confirm that the data packet was stored in the data register 601-9 (S606-9).

Then, a block transfer consisting of repeating packet transfer by the WriteBlock command and return of the corresponding ACK packet, which is equal to the number of FreeBlocks, is repeated until all the series of print data is output from the image supply device. During each block transfer, the number of FreeBlocks of the printer is acquired by the FreeBlock command and the response.

[0205] When the transfer of print data is completed, the image supply device closes the logical channel by the CloseChannel command and response (S606-10 and S606-11), and logs out from the printer by the Logout command and response of DPP (S606-12). And S606-13).

[Transfer Method 2] The transfer method 2, which is a Simplified Response Model, transfers data in the same procedure as the transfer method 1 except for the method of acquiring the number of Free Blocks.

FIG. 60 is a diagram showing an example of a data transfer flow in the transfer method 2. The image supply device logs in to the printer by the DPP Login command and response (S607-1 and S607-2), and uses the format register group described above to set the format used for data transfer (S607-3). Then open the logical channel with the OpenChannel command and response (S607-4 and S607-5). Subsequently, the data transfer is started, and the print data is transferred in the data packet format shown in FIG. 55. In addition, packet transfer is performed in one cycle for a number of blocks equal to the number of data buffers on the printer side shown by reference numerals 604-2 to 604-1 in FIG. 57.

[0208] The print data in the transfer method 2 is transferred as follows. The image supply device obtains the number of free blocks of the printer by the WriteBlocks command and response (S607-6 and S607-7). However, the response in step S607-7 is an INTERIM (provisional) type because the number of FreeBlocks after that is acquired only by the response from the printer side. The image supply device sequentially transfers the same number of data packets as the obtained number of FreeBlocks by WriteBlock (S607-8), and the printer returns the above-mentioned ACK packet (S607-9). Then, a block transfer consisting of repeating packet transfer by the WriteBlock command and return of the corresponding ACK packet, which is equal to the number of FreeBlocks, is repeated until all the series of print data is output from the image supply device. However, the number of FreeBlocks in the block transfer after the second lap is notified to the image supply device by the WriteBlocks response sent from the printer at the end of the block transfer cycle (S607-10). This WriteBlocks response is a CONTINUE type in order to continue acquiring the number of FreeBlocks only by the printer response.

[0209] When the transfer of print data is completed, the image supply device closes the logical channel by the CloseChannel command and response (S607-11 and S607-12), and logs out from the printer by the Logout command and response of DPP (S607-13). And S607-14).

[Method of acquiring the number of FreeBlocks] The method of acquiring the number of FreeBlocks, which is the difference between the transfer method 1 and the transfer method 2, will be described in detail below.

[0211] Fig. 61 is a diagram showing in detail the FreeBlock command and response in steps S606-6 and S606-7 of the transfer method 1, and is shown in FIG. 59 including the ACK packet of the write transaction omitted in FIG. 59. Both the (image supply device) and the target device (printer) show a case where the processing speed of the link layer and the transaction layer is relatively low.

[0212] When the image supply device writes the FreeBlock command to the command register by the write transaction (S608-1), the link layer of the printer returns an ACK packet indicating pending as described above (S608-2). Next, the image supply device sends a free block command with no data (S608-3), receives an ACK packet (S608-4) indicating complete from the printer, and one write transaction ends.

Subsequently, the printer returns a FreeBlock response, which is also written to the response register as a FreeBlock response including the number of FreeBlocks, similar to the FreeBlock command in step S608-1 (S608-5). From the link layer of the image supply device, an ACK packet indicating pending is returned (S608-6), a free block response with no data (S608-7) is sent, and an ACK packet indicating complete is received (S608-8). , One write transaction ends.

On the other hand, the method of acquiring the number of FreeBlocks in the transfer method 2 uses only the FreeBlock response from the printer in the second and subsequent cycles of the block transfer cycle of the print data, and therefore operates only in steps S608-5 to S608-8. You can get the number of FreeBlocks with.

[0215] Acquisition of the number of Free Blocks is necessary for each cycle of block transfer. Therefore, the number of packets transferred on the bus can be reduced in the transfer method 2 as compared with the transfer method 1.

FIG. 62 is a diagram showing in detail the Write Blocks of the transfer method 1 and the transfer method 2. Since WriteBlock does not require a response, the procedure is WriteBlock (S609-1), ACK packet indicating pending (S609-2), WriteBlock without data (S609-3) and ACK packet indicating complete (S609-4). Therefore, data can be transferred in half the procedure compared to transferring commands and responses, and relatively high-speed data transfer can be performed even when the processing of the link layer and transaction layer is relatively slow. ..

[0217] FIG. 63 is a diagram showing in detail the Write Blocks of the transfer method 1 and the transfer method 2, but it is a case where the processing of the link layer and the transaction layer is sufficiently high speed. In this case, the procedure is WriteBlock (S610-1) and ACK packet (S610-2) indicating complete, and more efficient data transfer can be executed.

[0218] Fig. 64 is a diagram for explaining the error handling of WriteBlock when a bus reset occurs, and shows a case where a bus reset occurs at the time of n (= 0 to 255) packet transfer of a certain block transfer cycle. There is. In a write transaction, a failure of normal data packet transfer can be detected by an ACK packet, but an error when a bus reset occurs cannot be detected. Therefore, in the present embodiment, error processing is executed by the following procedure. That is, when the number of FreeBlocks is acquired (S611-1), WriteBlock is performed n times (from S611-2 to ~ S611-6), and a bus reset occurs here (S611-7), the image supply device has a bus reset. Perform the previous WriteBlock [n] again (S611-8), and then continue normal processing (S611-9 to S611-14).

[Transfer Method 3] FIG. 65 is a diagram showing a configuration example of a command register, a response register, and a data register of an image supply device and a printer in the PUSH Large Buffer Model.

[0220] For the command and response between the FCP-compliant image supply device and the printer, write the command frame 65-7 as the command request data from the command register 65-1 of the image supply device to the command register 65-4 of the printer. It is executed by the operation of writing the response frame 65-8 as response data from the response register 65-5 of the printer to the response register 65-2 of the image supply device.

Further, for the data frame 65-9, unlike the FCP, a one-way operation of writing image data from the data register 65-3 of the image supply device to the data register 65-6 of the printer using a write transaction. Data frame 65-9 is used.

FIG. 66 is a diagram showing an example of the operation flow of the PUSH buffer model between the image supply device and the printer. Since the operations for Login, Logout, OpenChannel, CloseChannel, and format setting in the command frame and response frame are the same as those in the transfer method 1 described above, detailed description thereof will be omitted.

[0223] In FIG. 66, the image supply device inquires about the buffer area of the printer by INQUIRY of the BufferConfig command (S701). In response, the printer returns the buffer size and buffer address in the BufferConfig response (S702).

Next, the image supply device sets the buffer size and the buffer address of the printer to which the data is written by the CONTROL of the BufferConfig command (S703). On the other hand, the printer returns that the setting is completed by the BufferConfig response (S704).

Subsequently, the image supply device notifies the printer that the transfer of data is started by NOTIFY of the SetBuffer command (S705). On the other hand, the printer returns that it is ready to receive the data for the time being (S706) by the INTERIM of the SetBuffer response, and starts the data transfer. Then, the printer notifies the image supply device that the data transfer to the initially set buffer area is completed by the CONTINUE of the SetBuffer response (S709).

[0226] The Write Buffer in step S707 indicates a data frame writing operation by the image supply device, and sequentially writes data to a buffer address set in the printer.

[0227] WriteTransactionResponse in step S708 indicates a response packet when data frames are synchronously transferred. As mentioned above, if the printer's data acquisition speed is fast enough, the process can be completed using the acknowledge of one write transaction, but if it takes a long time to acquire the data, an independent response will be issued as a split transaction. It will occur.

[0228] Step S710 shows a transfer process of a plurality of data frames. In other words, data is transferred by continuous write transactions for the buffer size set by the BufferConfig command. A data transfer method that uses continuous write transactions in this way is called a "PUSH type data transfer method" or abbreviated as "PUSH method".

[0229] FIG. 67 is a diagram showing a configuration example of a data packet in a data frame. Since data can be written by directly addressing the buffer of the printer, the data packet 67-1 is configured not to include a header or the like. be able to.

FIG. 68 is a diagram showing an example of the relationship between the data register of the printer and the buffer, and the data written in the data register 68-1 is the memory space 68-2 of the printer pointed to by the Buffer Address determined by the offset Destination_Offset. Written directly to the address. Since the offset value is incremented by the data length Data_Length, by writing the data repeatedly to the continuous buffer addresses, the data can be continuously written in the area indicated by the buffer size BufferSize.

[Transfer Method 4] FIG. 69 is a diagram showing a configuration example of a command register, a response register, and a data register of an image supply device and a printer in the PULL Buffer Model.

[0232] For the command and response between the FCP-compliant image supply device and the printer, write the command frame 69-7 as the command request data from the command register 69-1 of the image supply device to the command register 69-4 of the printer. It is executed by the operation of writing the response frame 69-8 as response data from the response register 69-5 of the printer to the response register 69-2 of the image supply device.

[0233] As for the data frame 69-9, unlike the FCP, the data is operated in one direction to read the image data from the data register 69-3 of the image supply device to the data register 69-6 of the printer by using a read transaction. Frame 69-9 is used.

FIG. 70 is a diagram showing an example of the operation flow of the PULL buffer model between the image supply device and the printer. The operation of Login, Logout, OpenChannel, CloseChannel, and format setting in the command frame and response frame is the same as the above-mentioned transfer method 1, and the above-mentioned transfer of the BufferConfig and SetBuffer commands and responses (S711 to S714). Since it is the same as the method 3, detailed description is omitted.

[0235] In FIG. 70, the image feeding device notifies the printer that the data transfer can be started by NOTIFY of the SetBuffer command (S715). On the other hand, the printer returns that it is ready to receive for the time being (S716) by the INTERIM of the SetBuffer response, and starts the data transfer. Then, the printer notifies the image supply device that the data transfer to the initially set buffer area is completed by the CONTINUE of the SetBuffer response (S719).

The printer requests a read transaction with a PullBuffer request (S717). On the other hand, the image supply device transfers data by the PullBuffer response packet (S718), and the data is sequentially written to the buffer address set in the printer.

[0237] Step S720 shows a transfer process of a plurality of data frames. In other words, data is transferred by continuous read transactions for the buffer size set by the BufferConfig command. Such a data transfer method using continuous read transactions is called a "PULL type data transfer method" or abbreviated as "PULL method".

FIG. 71 is a diagram showing an example of the relationship between the data register of the image supply device and the buffer, and is the memory space 72-2 of the image supply device pointed to by the BufferAddress determined by the offset Destination_Offset set in the data register 71-1. Read the address data by read transaction. Since the offset value is incremented by the data length Data_Length, the data can be continuously read from the area indicated by the buffer size BufferSize by repeatedly reading the data for the continuous buffer addresses.

[Transfer Method 5] The transfer method 5, which is an Isochronous Model, replaces the transfer of print data using the asynchronous write transaction of the transfer method 1 described above with the transfer of print data using the synchronous write transaction. is there. The configuration of the data packet is the same as the configuration shown in FIGS. 55 and 56. Further, the data packet frame processing in the printer in the block transfer is the same as the processing shown in FIG. 57.

[0240] According to this transfer method, data can be transferred at a fixed time by using a synchronous write transaction.

[0241] Further, if an error occurs when, for example, one page of print data is collectively transferred by block transfer, one page of print data will be retransmitted, which takes time. However, if the print data is transferred in smaller block units, for example, in print band units in an inkjet printer or the like, the print data can be efficiently retransmitted due to the occurrence of an error.

FIG. 72 is a diagram showing a command frame and a response frame for flow control. The image supply device writes a command frame to the printer's command register 75-3 by an asynchronous write transaction. On the other hand, the printer writes the response frame for the command to the response register 75-2 of the image supply device by the asynchronous write transaction.

[0243] FIG. 73 is a diagram showing an example of a flow of printing processing. First, the image supply device sends a Login command to the printer (S507), as in the transfer method 1 described above. In response, the printer returns a Login response (S508) and the connection is established.

Next, as in the transfer method 1 described above, the image supply device sets the format (S509) and sends an OpenChannel command to the printer (S510). In response, the printer returns an OpenChannel response (S511) and the logical channel is opened.

The image supply device then sends a FreeBlock command to the printer (S512). In response, the printer returns a FreeBlock response (S513). This FreeBlock response includes the number of FreeBlocks and the Error Status. The number of FreeBlocks is the number of block buffers allocated in block units in the memory space of the printer, and ErrorStatus is for notifying the image supply device of the error information in the previous block transfer. The printer always returns normal to ErrorStatus for the first FreeBlock command after the logical channel is opened.

Subsequently, the image supply device blocks and transfers the print data by a synchronous transaction (S514). At this time, the image supply device sends out as many data packets as the number indicated by the number of Free Blocks.

Next, the image supply device sends a FreeBlock command to the printer (S515). In response, the printer returns a FreeBlock response (S516). If the Error Status of this response indicates an error, that is, if an error occurs in the previous block transfer, the image supply device retransmits the data transferred in step S514 (S517). After that, the processes of steps S515, S516, and S517 are repeatedly executed until the data transfer is normally completed. If the ErrorStatus indicates normal, the image supply device sends out the data packets of the number of FreeBlocks included in the FreeBlock response (S517).

[0248] The printer can recognize whether or not an error has occurred by referring to the block count (FIG. 73) of the header portion of the transferred data. If the number of Free Blocks is larger than the number of blocks of data to be transferred, the image supply device sends out a number of dummy packets corresponding to the larger number.

After that, the transfer of data by the synchronous transaction is repeated until all the series of print data is output from the image supply device.

[0250] When the data transfer is completed, the image supply device closes the logical channel (S518 and S519) by the CloseChannel command and the response, and logs out from the printer by the Logout command and the response of the DPP, as in the transfer method 1 described above. (S520 and S521).

[0251] As described above, according to the present embodiment, the image supply device and the printer are directly connected by a 1394 serial bus or the like, the image data of the image supply device is directly sent to the printer, and the image based on the image data is printed on the printer. Can be printed on.

Further, since the control command and the print data can be separated, an efficient data transfer method can be provided on a 1394 serial bus or the like.

[0253] Further, it is possible to provide a data transfer method capable of recovering a transfer error on the 1394 serial bus.

[0254] Further, by notifying the number of free blocks related to the register area for data transfer, it is not necessary to determine whether or not writing is possible when writing data to the register area, and the overhead required for the determination is deleted. A method can be provided. Further, since the data for the number of notified free blocks is collectively transmitted and received, it is possible to provide a data transfer method with high transfer efficiency.

[0255] Further, it is possible to provide a data transfer method capable of selecting a data transfer method suitable for a transfer destination device from a plurality of data transfer methods.

Further, when transferring data from the host device to the target device, the exchange of the command and the response to the command is limited to the command instructing the start of the data transfer and the response to the command, that is, the start of the data transfer. After that, by not transmitting the command, it is possible to provide a data transfer method that avoids a decrease in transfer efficiency due to the transmission of the command.

[0257] Further, when data transfer is performed between the host device and the target device, a data transfer method based on the PUSH method or the PULL method can be provided.

[0258] Further, when data transfer is performed between the host device and the target device, it is possible to provide a data transfer method capable of performing synchronous transfer and asynchronous transfer in the same transfer procedure.

[0259] Further, when data transfer is performed between a host device and a target device, if a transfer error occurs in a certain data unit in synchronous transfer, a data transfer method capable of retransferring the data unit is provided. can do.

[0260] Further, it is possible to provide a data transfer method capable of performing correct data transfer even when a bus reset occurs when data is transferred between the host device and the target device.

[0261] Further, it is possible to provide a peripheral device such as a printer that uses the above data transfer method.

【０２６２】

[Modification Example] In the above-described embodiment, an example of using a command based on FCP and a response to the command, setting information in the response and notifying the host device has been described, but the memory bus model of IEEE1394 has been described. A characteristic method of mapping registers on memory is also conceivable.

[0263] In this case, the command is executed by writing the command data to the command register assigned to a specific address in the memory. Similarly, the response is indicated by reading the data in the response register assigned to a specific address in memory.

Therefore, when the target device recognizes that the command has been written to the command register, it executes the command, and then writes the result or information to the response register. The host device can obtain the command execution result and information by reading the response register of the target device after writing the command to the command register.

[0265] As described above, the present invention can be realized by using the registers in the memory bus model.

[0266] Further, in the above-described embodiment, an example of configuring a network using a serial interface defined in IEEE 1934 has been described, but the present invention is not limited to this, and the Universal Serial Bus (USB) is used. It can also be applied to a network configured using any serial interface, such as a serial interface called.

【０２６７】

[Other Embodiments] Even if the present invention is applied to a system composed of a plurality of devices (for example, a host computer, an interface device, a reader, a printer, etc.), the present invention is a device composed of one device (for example, copying). It may be applied to machines, facsimile machines, etc.).

[0268] An object of the present invention is to supply a storage medium in which a program code of software that realizes the functions of the above-described embodiment is recorded to a system or device, and to supply a computer (or CPU or MPU) of the system or device. Needless to say, is also achieved by reading and executing the program code stored in the storage medium. In this case, the program code itself read from the storage medium realizes the function of the above-described embodiment, 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, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM, a CD-R, a magnetic tape, a non-volatile memory card, a ROM, or the like can be used.

[0269] Further, by executing the program code read by the computer, not only the function of the above-described embodiment is realized, but also the OS (operating system) running on the computer based on the instruction of the program code. ) Etc. perform a part or all of the actual processing, and it goes without saying that the processing may realize the function of the above-described embodiment.

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

【０２７１】

INDUSTRIAL APPLICABILITY As described above, according to the present invention, when a host device and a target device are connected by a serial bus such as a 1394 serial bus, efficient data transfer is performed from the host device to the target device. be able to. That is, since it is not necessary to transfer information indicating the amount of data to be transmitted between the host device and the target device each time the data is transferred, the data transfer efficiency can be improved.

[0272] Further, the control command and the data can be separated, and the data can be transferred efficiently.

[0273] Further, it is possible to make a data transfer in which a command and a response are not exchanged for each data transfer of a certain unit.

[Simple explanation of drawings]

FIG. 1 is a diagram showing a general configuration example of a system to which the present invention is applied.

FIG. 2 is a diagram showing an example of a network configuration using a 1394 serial bus.

FIG. 3 is a diagram showing a configuration example of a 1394 serial bus.

FIG. 4 is a diagram showing an example of an address space in a 1394 serial bus.

FIG. 5 shows a cross section of a cable for a 1394 serial bus,

FIG. 6 is a diagram for explaining a DS-Link system as a data transfer system adopted in a 1394 serial bus.

FIG. 7 is a flowchart showing a series of sequence examples from the generation of a bus reset signal to the determination of a node ID and the ability to transfer data.

FIG. 8 is a flowchart showing a detailed example from monitoring a bus reset signal to determining a root node.

FIG. 9 is a flowchart showing a detailed example of node ID setting.

FIG. 10 is a diagram showing an example of network operation of a 1394 serial bus.

FIG. 11 illustrates the functionality of the 1394 serial bus CSR architecture.

FIG. 12 shows a register for a 1394 serial bus,

FIG. 13 shows a 1394 serial bus node resource register,

FIG. 14 shows a minimum format of a 1394 serial bus configuration ROM,

FIG. 15 shows a general format of a 1394 serial bus configuration ROM,

FIG. 16 illustrates a request for bus usage rights,

FIG. 17 is a diagram illustrating permission to use a bus,

FIG. 18 is a flowchart showing the flow of arbitration in a 1394 serial bus.

FIG. 19 shows a request / response protocol for read, write, and lock commands based on the CSR architecture at the transaction layer.

FIG. 20 shows a service in the link layer,

FIG. 21 shows a temporal transition in asynchronous transfer.

FIG. 22 shows a format of an asynchronous transfer packet,

FIG. 23 is a diagram showing an operation example of a split transaction.

FIG. 24 is a diagram showing an example of a temporal transition of a transfer state when performing a split transaction.

FIG. 25 is a diagram showing a temporal transition in synchronous transfer.

FIG. 26 is a diagram showing an example of a packet format for synchronous transfer.

FIG. 27 shows details of packet format fields for synchronous forwarding on a 1394 serial bus.

FIG. 28 is a diagram showing a temporal transition of a transfer state when synchronous transfer and asynchronous transfer are mixed.

FIG. 29, a diagram showing the operation of an AV / C transaction on a 1394 serial bus,

FIG. 30 shows a packet format for asynchronous forwarding, including FCP packet frames.

FIG. 31 is a diagram showing the structure of an AV / C command frame.

FIG. 32 is a diagram showing the structure of an AV / C response frame.

FIG. 33 contrasts the interface of the 1394 serial bus with each layer of the OSI model.

FIG. 34 shows a diagram showing the basic operation of the LOGIN protocol.

FIG. 35 is a diagram showing an example of a connection form in a 1394 serial bus.

FIG. 36 is a diagram showing a flow of login operation.

FIG. 37 illustrates the CSR of a 1394 serial bus included in a printer that is a target device for the LOGIN protocol.

FIG. 38 is a flowchart showing a login process in a host device.

FIG. 39 is a flowchart showing a login process of a printer as a target device.

FIG. 40 is a diagram illustrating an example considering a device that does not implement the LOGIN protocol.

41 is a diagram comparing the configuration shown in FIG. 40 with each layer of the OSI model.

FIG. 42 shows a register map,

FIG. 43 shows a frame flow from an image feeding device to a printer.

FIG. 44 is a diagram showing a configuration example of a format register.

FIG. 45 is a diagram showing a detailed configuration example of a status register status register of a common register group.

FIG. 46 shows a detailed example of information held in register GLOBAL of a common register group.

FIG. 47 shows a detailed example of information held in register LOCAL of a common register group.

FIG. 48 shows an example of information held in register format [1].

FIG. 49 shows an example of information held in register format [2].

FIG. 50 is a diagram showing a command and a list of responses to the command.

FIG. 51 shows an example of an image data format supported by DPP.

FIG. 52 is a diagram showing a flow of a format setting process.

FIG. 53 is a diagram showing an example of a data transfer method setting procedure.

FIG. 54 shows a register map of the registers required for transfer method 1 and transfer method 2 in the address space of the 1394 serial bus.

FIG. 55 shows an example of a data packet frame,

FIG. 56 is a diagram showing a configuration example of a data header.

FIG. 57 shows data packet frame processing in a printer in block transfer.

FIG. 58 is a diagram showing a FreeBlock command and a response in transfer method 1.

FIG. 59 is a diagram showing an example of a data transfer flow in the transfer method 1.

FIG. 60 is a diagram showing an example of a data transfer flow in the transfer method 2.

FIG. 61 is a diagram showing in detail the FreeBlock command and response in transfer method 1.

FIG. 62 is a diagram showing in detail the Write Blocks of the transfer method 1 and the transfer method 2.

FIG. 63 is a diagram showing in detail the Write Blocks of the transfer method 1 and the transfer method 2.

FIG. 64 is a diagram illustrating error handling of WriteBlock when a bus reset occurs.

FIG. 65 is a diagram showing a configuration example of a command register, a response register, and a data register of an image supply device and a printer in the PUSH Large Buffer Model.

FIG. 66 is a diagram showing an example of an operation flow of a PUSH buffer model between an image supply device and a printer.

FIG. 67 is a diagram showing a configuration example of a data packet in a data frame.

FIG. 68 is a diagram showing an example of a relationship between a data register and a buffer of a printer.

FIG. 69 is a diagram showing a configuration example of a command register, a response register, and a data register of an image supply device and a printer in the PULL Buffer Model.

FIG. 70 is a diagram showing an example of an operation flow of a PULL buffer model between an image supply device and a printer.

FIG. 71 is a diagram showing an example of a relationship between a data register and a buffer of an image supply device.

FIG. 72 is a diagram showing a command frame and a response frame for flow control.

FIG. 73 is a diagram showing an example of a flow process of printing processing.

Continuation of front page (72) Inventor Naohisa Suzuki 3-30-2 Shimomaruko, Ota-ku, Tokyo Within Janon Co., Ltd. (72) Inventor Jiro Tateyama 3-30-2 Shimomaruko, Ota-ku, Tokyo Within Janon Co., Ltd. (72) Inventor Atsushi Nakamura 3-30-2 Shimomaruko, Ota-ku, Tokyo Within Janon Co., Ltd. (56) References Japanese Patent Application Laid-Open No. 6-303285 (JP, A) Japanese Patent Application Laid-Open No. 8-340338 (JP, A) Japanese Patent Application Laid-Open No. 7-36807 (JP, A) (58) Surveyed field (Int.Cl.⁷, DB name) H04L 29/08 G06F 13/00 351 H04L 12/40