JP3566495B2 - Data transfer device, data transfer system and method, image processing device, and recording medium - Google Patents

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a data transfer apparatus, a data transfer system and method, an image processing apparatus, and a recording medium. For example, the present invention relates to an image supply device such as a digital camera and a printer via a serial interface defined by IEEE 1394 or the like. The present invention relates to a data transfer device, a data transfer system and a data transfer method, an image processing device, and a recording medium when directly connected to an image processing device.
[0002]
[Prior art]
The printer is connected to a personal computer (PC) as a host device via a parallel or serial interface such as Centronics or RS232C.
[0003]
In addition, digital equipment which is an image supply device such as a scanner, a digital still camera, and a digital video camera is also connected to the PC. The image data captured by each digital device is temporarily captured to a hard disk or the like on a PC, then processed by application software or the like on the PC, converted into print data for a printer, and passed through the above interface. And sent to the printer.
[0004]
In such a system as described above, driver software for controlling each digital device, printer, and the like exists independently in the PC, and the image data output from the digital device is easy to use and displayed on the PC by the driver software. It is saved as data in a format that is easy to use. The stored data is converted into print data by an image processing method that takes into account the image characteristics of the input device and the image characteristics of the output device.
[0005]
Today, a new interface such as an interface defined by IEEE 1394 (hereinafter, referred to as a "1394 serial bus") allows a direct connection between an image supply device and a printer. When an image supply device and a printer are directly connected by a 1394 serial bus, a method of including print data in an FCP (Function Control Protocol) operand is conceivable. Further, in the 1394 serial bus, a method of providing a register area for data transfer and writing data in the register area to perform data transfer may be considered.
[0006]
In addition, the 1394 serial bus has a plurality of methods as a control procedure for data transfer, and data transfer can be performed by a method suitable for each device.
[0007]
[Problems to be solved by the invention]
However, the above-described technology 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 is printed by the printer. Therefore, even if the image supply device and the printer are directly connected, if the PC is not provided, the print data is not printed. Can not do. There is a printer called a video printer that directly prints image data output from a digital video camera, but a highly versatile video printer that can only be connected between specific models and can be used directly with many image supply devices Absent. In other words, it is not possible to directly send image data from an image supply device to a printer and print it by making use of a function of directly connecting devices, which is a feature of a 1394 serial bus or the like.
[0008]
The above-described method of directly connecting the image supply device and the printer via 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 from each other. There is also a problem that transfer efficiency is low because it is necessary. In the above-described method of providing a register area for data transfer, a process for determining whether data can be written to the register area is required for each data transfer. Therefore, there is a problem that the overhead of this determination processing is increased and the transfer efficiency is also lowered.
[0009]
In addition, in order to ensure connectivity with various types of devices, there are data transfer methods suitable for various devices, and thus a plurality of data transfer methods are required.
[0010]
There are two basic data transfer methods: a push (PUSH) method in which data is written from the host device to the target device, and a pull (PULL) method in which the target device reads data of the host device. One of the data transfer methods is determined by the resources of both devices. However, considering that various types of devices are directly connected, the data transfer method cannot be determined to be either the push method or the pull method.
[0011]
The present invention is to solve the above-mentioned problems individually or collectively, and directly connects a host device and a target device by a 1394 serial bus or the like, and targets processing of image data sent directly from the host device to the target device. It is an object of the present invention to provide a data transfer device, a data transfer system and a data transfer method, an image processing device, and a recording medium suitable for a device.
[0012]
It is another object of the present invention to provide a data transfer device, a data transfer system and its method, an image processing device, and a recording medium which can separate a control command and data and have high transfer efficiency.
[0013]
Another object of the present invention is to provide a data transfer device, a data transfer system and a data transfer method, an image processing device, and a recording medium that can set a data transfer method suitable for a device to be connected.
[0014]
Another object of the present invention is to provide a data transfer device, a data transfer system and a data transfer method, an image processing device, and a recording medium that can perform data transfer by a PULL method.
[0015]
[Means for Solving the Problems]
The present invention has the following configuration as one means for achieving the above object.
[0017]
A data transfer method according to the present invention is a data transfer method used between an image supply device and a target device connected by a serial bus, Fixing the resources of the target device to the image supply device, and after fixing the resources, In the two-way communication between the image supply device and the target device, determine a data transfer method available between the image supply device and the target device, Based on a request issued by the image supply device, Set to the target device Be done At least the data transfer method Push method or pull method When the data transfer method is set to the pull method, Data is read from the image supply device based on a request issued by the target device Control And , Of the data During the transfer, The target device receives control from an apparatus other than the image supply device. Without releasing the fixation of the resource based on a request of the image supply device after the transfer of the data. It is characterized by the following.
[0019]
The data transfer device according to the present invention includes: With target device and serial bus A data transfer device to be connected, After the resources of the target device are fixed to the data transfer device, Communication means for performing two-way communication with the target device, and a data transfer method that can be used with the target device by the two-way communication. Determining, based on the request issued by the data transfer device, As a data transfer method set in the target device, At least, either push model or pull model Setting means for setting, When the data transfer method is set to the pull method, the communication unit reads data from the data transfer device based on a request issued by the target device, and the data transfer device after the data transfer. Release the fixation of the resource based on the request of It is characterized by the following.
[0021]
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.
[0022]
FIG. 1 is a diagram illustrating 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 using a 1394 serial bus. Therefore, an outline of the 1394 serial bus will be described in advance.
[0023]
[Overview of IEEE 1394]
With the advent of home digital VTRs and digital video disks (DVDs), it has become necessary to transfer real-time and large-volume information data such as video data and audio data (hereinafter collectively referred to as "AV data"). . To transfer AV data to a PC or other digital devices in real time, an interface having a high-speed data transfer capability is required. An interface developed from such a viewpoint is the 1394 serial bus.
[0024]
FIG. 2 shows an example of a network system configured using a 1394 serial bus. This system is provided with devices A to H, and a 1394 serial bus is provided between AB, AC, BD, DE, CF, CG, and CH. Connected with a twisted pair cable. Examples of these devices A to H are a host computer device such as a personal computer and a computer peripheral device. Computer peripherals include digital VCRs, DVD players, digital still cameras, storage devices using media such as hard disks and optical disks, CRT and LCD monitors, tuners, image scanners, film scanners, printers, MODEMs, and terminal adapters (TA). And all computer peripherals. The recording method of the printer may be any method such as an electrophotographic method using a laser beam or LED, an ink jet method, an ink melting type or sublimation type thermal transfer method, and a thermal recording method.
[0025]
The connection between each device can be a mixture of the daisy chain method and the node branch method, and a highly flexible connection can be performed. Each device has an ID, and recognizes each other to form a single network in a range connected by a 1394 serial bus. For example, only by daisy-chaining each device with one 1394 serial bus cable, each device plays a role of relay, so that one network can be configured as a whole.
[0026]
Further, the 1394 serial bus supports 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. Further, 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) and the bus is automatically reset. Rebuilding a good network. With this function, the configuration of the network at that time can be always set and recognized.
[0027]
Further, the data transfer speed of the 1394 serial bus is defined as 100/200/400 Mbps, and compatibility is maintained by the device having the higher transfer speed supporting the lower transfer speed. The data transfer mode includes an asynchronous (Asynchronous) transfer mode (ATM) for transferring asynchronous data such as a control signal and a synchronous (Isochronous) transfer mode for transferring synchronous data such as real-time AV data. The asynchronous data and the 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, and prioritizing the transfer of the synchronous data. Will be transferred.
[0028]
FIG. 3 is a diagram showing a configuration example of the 1394 serial bus. The 1394 serial bus has a layer structure. As shown in FIG. 3, a connector at the tip of a 1394 serial bus cable 813 is connected to the connector port 810. Above the connector port 810, there are a physical layer 811 and a link layer 812 constituted by the hardware unit 800. The hardware unit 800 is configured by an interface chip. The physical layer 811 performs coding and connection-related control, and the link layer 812 performs packet transfer and cycle time control.
[0029]
The transaction layer 814 of the firmware unit 801 manages data to be transferred (transacted), and issues Read, Write, and Lock commands. 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 configuration of the network. The above hardware and firmware are the substantial configuration of the 1394 serial bus.
[0030]
The application layer 816 of the software unit 802 differs depending on the software used, and how data is transferred on the interface is defined by a protocol such as a printer or an AV / C protocol.
[0031]
FIG. 4 is a diagram showing an example of an address space in the 1394 serial bus. Each device (node) connected to the 1394 serial bus always has a 64-bit address unique to the node. This address is stored in the memory of the device, and by constantly recognizing the node address of itself or the other party, it is possible to perform data communication specifying the other party.
[0032]
The addressing of the 1394 serial bus is based on the IEEE 1212 standard. In the address setting, the first 10 bits are used for specifying a bus number, and the next 6 bits are used for specifying a node ID.
[0033]
The 48-bit address used in each device is also divided into 20 bits and 28 bits and used in a 256 Mbyte unit structure. Of the first 20-bit address space, 0 to 0xFFFFD is called a memory space, 0xFFFFE is called a private space, and 0xFFFFF is called a register space. The private space is an address that can be freely used in the device, and the register space stores information common to devices connected to the bus and is used for communication between the devices.
[0034]
In the register space, the first 512 bytes are a register (CSR core) that becomes a core of the CSR architecture, the next 512 bytes are a register of the serial bus, the next 1024 bytes are a configuration ROM, and the rest are units. Each space has its own device-specific registers.
[0035]
In general, to simplify the design of heterogeneous bus systems, nodes should use only the first 2048 bytes of the initial unit space, which results in CSR core, serial bus registers, configuration ROM and unit space. It is desirable that the first 2048 bytes be combined with 4096 bytes.
[0036]
The above is the outline of the 1394 serial bus. Next, the features of the 1394 serial bus will be described in more detail.
[0037]
[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 twisted pair signal lines. As a result, power can be supplied to a device having no power supply or a device whose voltage has been reduced due to a failure or the like. The voltage of the DC power supplied from the power supply line is regulated to 8 to 40 V, and the current is regulated to a maximum current of 1.5 A. In a standard called a DV cable, the cable is composed of four wires without a power supply line.
[0038]
[DS-Link system]
FIG. 6 is a diagram for explaining a DS-Link (Data / Strobe Link) system of a data transfer system employed in a 1394 serial bus.
[0039]
The DS-Link system is suitable for high-speed serial data communication and requires two sets of signal lines. That is, the data signal is transmitted by one of the two pairs of twisted pair wires, and the strobe signal is transmitted by the other pair. The receiving side has a feature that a clock can be generated by taking an exclusive OR of this data signal and the strobe signal. Therefore, when the DS-Link system is used, it is not necessary to mix a clock signal into a data signal, so that a transfer signal with higher transfer efficiency than other serial data transfer systems can be generated, and a phase locked loop (PLL) can be generated. The circuit becomes unnecessary, and the circuit scale of the controller LSI can be reduced accordingly. Further, since there is no need to send information indicating that the apparatus is in an idle state when there is no data to be transferred, the transceiver circuit of each device can be in a sleep state, and power consumption can be reduced. .
[0040]
[Bus reset sequence]
Each device (node) connected to the 1394 serial bus is given a node ID, and is recognized as a node constituting a network. For example, when the number of nodes increases or decreases due to connection / disconnection of network devices or power on / off, that is, there is a change in the network configuration, and when it is necessary to recognize a new network configuration, each node that detects the change is placed on the bus To enter a mode for recognizing a new network configuration. This change in the network configuration is detected by detecting a change in the bias voltage at the connector port 810.
[0041]
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 transmits the bus reset signal to another node. . After all the nodes finally receive the bus reset signal, the bus reset sequence is started. Note that the bus reset sequence is started when a cable is connected or disconnected, or when the hardware detects a network error or the like, and is also provided by directly giving an instruction to the physical layer 811 such as host control using a protocol. Is activated. Further, when the bus reset sequence is started, the data transfer is temporarily interrupted, waited during the bus reset, and resumed under the new network configuration after the bus reset.
[0042]
[Node ID determination sequence]
After the bus reset, each node enters an operation of giving each node an ID in order to construct a new network configuration. The general sequence from the bus reset to the determination of the node ID at this time will be described with reference to the flowcharts shown in FIGS.
[0043]
FIG. 7 is a flowchart showing an example of a series of sequences from the generation of the bus reset signal to the determination of the node ID and the start of data transfer. The nodes constantly monitor the generation of the bus reset signal in step S101, and when the bus reset signal is generated, shift to step S102, and are directly connected to each other to obtain a new network configuration in a state where the network configuration is reset. A parent-child relationship is declared between nodes. Then, step S102 is repeated until it is determined in step S103 that the parent-child relationship has been determined between all the nodes.
[0044]
When the parent-child relationship is determined, the process proceeds to step S104, where a root (root) node is determined. In step S105, a node ID setting operation for giving an ID to each node is performed. Node IDs are set in a predetermined node order from the root node, and step S105 is repeated until it is determined in step S106 that IDs have been given to all nodes.
[0045]
When the setting of the node ID is completed, the new network configuration has been recognized by all the nodes, so that data transfer between the nodes can be performed. In step S107, the data transfer is started, and the sequence proceeds to step S101. Then, the generation of the bus reset signal is monitored again.
[0046]
FIG. 8 is a flowchart showing a detailed example from monitoring of a bus reset signal (S101) to determination of a root node (S104), and FIG. 9 is a flowchart showing a detailed example of node ID setting (S105, S106).
[0047]
In FIG. 8, the generation of a bus reset signal is monitored in step S201, and when the bus reset signal is generated, the network configuration is reset once. Next, in step S202, as a first step of re-recognizing the reset network configuration, each device resets the flag FL with data indicating 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, according to the result of step S203, undefined to start declaring a parent-child relationship. 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 as the parent-child relationship is determined, the number of undefined ports detected in step S204 decreases.
[0048]
Declaring a parent-child relationship immediately after a bus reset is limited to actual leaf nodes. Whether the node is a leaf node can be known from the result of checking the number of ports in step S203. That is, if the number of ports is "1", the node is a leaf node. In step S205, the leaf node declares a parent-child relationship “I am a child and the other is a parent” with respect to the connection partner node, and ends the operation.
[0049]
On the other hand, the node whose port number is “2 or more” in step S203, that is, the branch node, is “undefined port number> 1” immediately after the bus reset, so the process proceeds to step S206, and the flag FL indicates the branch node. The data is set, and the process waits for declaration of a parent-child relationship from another node in step S207. A parent-child relationship is declared from another node, and the branch node receiving the declaration returns to step S204 to check the number of undefined ports. If the number of undefined ports is "1", the branch node is connected to the remaining port. A parent-child relationship of "I am a child and the other is a parent" can be declared to another node in step S205. Further, the branch node having the undefined port number “2 or more” waits for another node to declare a parent-child relationship again in step S207.
[0050]
If the number of undefined ports of any one of the branch nodes (or, in exceptional cases, leaf nodes that could not be operated quickly despite being able to make child declarations) becomes “0”, the declaration of the parent-child relationship of the entire network will be lost. The only node for which the number of undefined ports has become “0”, that is, the node that has been determined to be the parent of all nodes, sets data indicating the root node in the flag FL in step S208, and in step S209, Recognized as a root node.
[0051]
Thus, the procedure from the bus reset to the declaration of the parent-child relationship between all the nodes in the network is completed.
[0052]
Next, a procedure for assigning an ID to each node will be described. First, an ID can be set at a leaf node. Then, the ID is set in the order of leaf → branch → root in ascending order (node number: 0).
[0053]
In step S301 in FIG. 9, the process branches to processing according to the type of node, that is, leaf, branch, and route, based on the data set in the flag FL.
[0054]
First, in the case of a leaf node, in step S302, the number (natural number) of leaf nodes existing in the network is set as a variable N, and in step S303, each leaf node requests a node number from the root node. If there are a plurality of requests, the root node performs arbitration in step S304, assigns a node number to one node in step S305, and notifies another node of a result indicating that acquisition of the node number has failed.
[0055]
The leaf node from which the node number could not be obtained by the determination in step S306 repeats the request for the node number again in step S303. On the other hand, in step S307, the leaf nodes that have obtained the node numbers notify all the nodes by broadcasting ID information including the obtained node numbers. When the broadcast of the ID information ends, in step S308, the variable N indicating the number of leaves is decremented. 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 on to
[0056]
The ID setting of the branch node is performed in substantially the same manner as the leaf node. First, in step S310, the number (natural number) of branch nodes existing in the network is set as a variable M, and then in step S311, each branch node requests a node number from the root node. In response to this request, the root node performs arbitration in step S312, assigns a small number following the leaf node to one branch node in step S313, and indicates a failure indicating acquisition failure to the branch node for which the node number could not be acquired. Notify.
[0057]
The branch node, which has learned that the acquisition of the node number has failed in step S314, repeats the request for the node number in step S311 again. On the other hand, in step S315, the branch node that has obtained the node number notifies all nodes by broadcasting ID information including the obtained node number. When the broadcast of the ID information ends, the variable M representing the number of branches is decremented in step S316. Then, according to the determination in step S317, the procedure from step S311 to S316 is repeated until the variable M becomes “0”, and after the ID information of all branch nodes has been broadcast, the process proceeds to step S318, where the ID of the root node is determined. Move on to setting.
[0058]
At this point, the root node is the only node that has not finally obtained an ID. Therefore, in step S318, the lowest node number that has not been given to another node is set as its own node number. Broadcast ID information.
[0059]
Thus, the procedure up to setting the IDs of all the nodes is completed. Next, a specific procedure of a sequence for determining a node ID will be described using the network example shown in FIG.
[0060]
In the network shown in FIG. 10, the nodes A and C are directly connected below the node B which is the root, the node D is directly connected below the node C, and the nodes E and F are directly connected below the node D. It has a hierarchical structure. The procedure for determining the hierarchical structure, the root node, and the node ID is as follows.
[0061]
After the bus reset occurs, a parent-child relationship is declared between the directly connected ports of each node in order to recognize the connection status of each node. Here, the parent and child means that the upper level of the hierarchical structure is “parent” and the lower level is “child”. In FIG. 10, it is the node A that first declared the parent-child relationship after the bus reset. As described above, the declaration of the parent-child relationship can be started from a node (leaf) to which only one port is connected. This means that if the number of ports is “1”, the end of the network tree, that is, the leaf node is recognized, and the parent-child relationship is determined from the node that operates first among the leaf nodes. Become. In this way, the port of the node that has declared the parent-child relationship is set as the “child” of the two nodes connected to each other, and the node of the partner node is set as the “parent”. In this way, a "child-parent" relationship is set between the nodes AB, the nodes ED, and the nodes FD.
[0062]
Further, the hierarchy goes up by one, and a parent-child relationship is declared to a higher-order node sequentially from a node having a plurality of ports, that is, a node that has received a declaration of a parent-child relationship from another node among branch nodes. In FIG. 10, after the parent-child relationship between the nodes DE and DF is determined, the node D declares the parent-child relationship to the node C. As a result, the child-parent relationship between the nodes D and C is determined. Is set. The node C that has received the parent-child relationship declaration from the node D declares a parent-child relationship with respect to the node B connected to another port, whereby the “child-parent” relationship between the nodes C and B is established. Is set.
[0063]
In this way, a hierarchical structure as shown in FIG. 10 is formed, and the parent node B in all finally connected ports is determined as the root node. Note that there is only one root node in one network configuration. Further, when the node B whose parent-child relationship is declared from the node A promptly declares the parent-child relationship to another node, there is a possibility that another node such as the node C becomes a root node. . That is, depending on the timing at which the declaration of the parent-child relationship is transmitted, there is a possibility that any node may become a root node, and even if the network configuration is the same, a specific node is not necessarily a root node.
[0064]
When the root node is determined, the mode enters the determination mode of each node ID. All nodes have a broadcast function for notifying their own ID information to all other nodes. Note that the ID information is broadcast as ID information including a node number, information on a connected position, the number of ports having the number, the number of connected ports, information on the parent-child relationship of each port, and the like.
[0065]
Assignment of node numbers starts from a leaf node as described above, and node numbers = 0, 1, 2,... Are assigned in order. Then, by broadcasting the ID information, it is recognized that the node number has been assigned.
[0066]
When all the leaf nodes have obtained the node numbers, the process proceeds to the branch node, and the node numbers following the leaf nodes are assigned. Like 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.
[0067]
As described above, the ID setting of the entire hierarchical structure is completed, the network configuration is constructed, and the bus initialization operation is completed.
[0068]
[Control information for node management]
As a basic function of the CSR architecture for performing node management, a CSR core shown in FIG. 4 exists on a register. The positions and functions of these registers are shown in FIG. 11, where the offset is a relative position from 0xFFFFF00000000.
[0069]
In the CSR architecture, registers related to the serial bus are arranged from 0xFFFFF0000200. FIG. 12 shows the positions and functions of these registers.
[0070]
Information about the node resources of the serial bus is arranged at a location starting from 0xFFFFF0000800. FIG. 13 shows the positions and functions of these registers.
[0071]
The CSR architecture has a configuration ROM for representing the function of each node. This ROM has a minimum format and a general format, and is arranged from 0xFFFFF0000400. In the minimum format, only the vendor ID is represented as shown in FIG. 14, and this vendor ID is a value unique to the whole world represented by 24 bits.
[0072]
The general format has information on nodes in a format as shown in FIG. 15. In this case, the vendor ID can be stored in a root directory (root_directory). The bus information block (bus info block) and the root leaf (root leaf) have a 64-bit unique device number including a vendor ID in the world. This device number is used for continuously recognizing a node after a reconfiguration such as a bus reset.
[0073]
[Serial bus management]
The protocol of the 1394 serial bus includes a physical layer 811, a link layer 812, and a transaction layer 814, as shown in FIG. Among them, the bus management provides basic functions for node control and bus resource management based on the CSR architecture.
[0074]
The only node that performs bus management (hereinafter referred to as a “bus management node”) exists solely on the same bus and provides a management function to other nodes on the serial bus. , Performance optimization, power management, transmission speed management, configuration management, etc.
[0075]
The bus management function is roughly divided into three functions: a bus manager, a synchronous (isochronous) resource manager, and node control. The node control is a management function that enables communication between nodes in the physical layer 811, the link layer 812, the transaction layer 814, and the application using CSR. The synchronous resource manager is a management function necessary for performing synchronous data transfer on the serial bus, and manages the transfer bandwidth of synchronous data and the assignment of channel numbers. To perform this management, a bus management node is dynamically selected from nodes having a synchronous resource manager function after the bus is initialized.
[0076]
In a configuration in which a bus management node does not exist on a bus, a node having a synchronous resource manager function performs a part of bus management functions such as power management and cycle master control. Further, the bus management is a management function for performing a service of providing a bus control interface to an application. The control interface includes a serial bus control request (SB_CONTROL.request) and a serial bus event control confirmation (SB_CONTROL.confirmation). ), And serial bus event notification (SB_EVENT.indication).
[0077]
The serial bus control request is used when an application requests the bus management node for bus reset, bus initialization, bus status information, and the like. The serial bus event control confirmation is notified to the application from the bus management node as a result of the serial bus control request. The serial bus event notification is for notifying an event generated asynchronously from the bus management node to the application.
[0078]
[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 can be transmitted and received at an arbitrary timing are present at the same time. Real-time performance is guaranteed. In data transfer, prior to the transfer, a bus use right is requested, and bus arbitration for obtaining a bus use permission is performed.
[0079]
In the asynchronous transfer, the transmitting node ID and the receiving node ID are sent 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, thereby completing one transaction.
[0080]
In synchronous transfer, a transmitting node requests a synchronous channel together with a transmission rate, and a channel ID is sent as packet data together with transfer data. The receiving node confirms the desired channel ID and receives the data packet. The required number of channels and transmission speed are determined by the application layer 816.
[0081]
These data transfer protocols are defined by three layers: a physical layer 811, a link layer 812, and a transaction layer 814. The physical layer 811 performs a physical / electrical interface with a bus, automatic recognition of node connection, bus arbitration of a bus use right between nodes, and the like. The link layer 812 performs address control, data check, packet transmission / reception, and cycle control for synchronous transfer. The transaction layer 814 performs processing related to asynchronous data. Hereinafter, processing in each layer will be described.
[0082]
[Physical layer]
Next, bus arbitration in the physical layer 811 will be described.
[0083]
The 1394 serial bus always performs arbitration of the right to use the bus prior to data transfer. Each device connected to the 1394 serial bus forms a logical bus-type network that transmits the signal to all devices in the network by relaying signals transferred on the network, so that packet collision occurs. Bus arbitration is necessary in order to prevent this. This allows only one node to transfer at a given time.
[0084]
FIG. 16 is a diagram for explaining a request for a bus use right, and FIG. 17 is a diagram for explaining permission for a bus use. When the bus arbitration starts, one or a plurality of nodes respectively request the right to use the bus toward the parent node. In FIG. 16, nodes C and F are requesting the right to use the bus. The parent node (node A in FIG. 16) that has received 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 the node F. This request is finally delivered to the arbitrating root node.
[0085]
The root node that has received the request for the right to use the bus determines which node is given the right to use the bus. This arbitration work can be performed only by the root node, and the node that wins the arbitration is given permission to use the bus. FIG. 17 shows a state in which the node C is given a bus use permission and the node F request for the bus use right is rejected.
[0086]
The root node sends a data prefix (DP) packet to the node that has lost the bus arbitration to notify that the request for the right to use the bus has been rejected. The request for the right to use the bus of the node that has lost the bus arbitration is kept waiting until the next bus arbitration.
[0087]
As described above, the node that has won the arbitration and obtained the permission to use the bus can thereafter start data transfer. Here, a series of flows of the bus arbitration will be described with reference to a flowchart shown in FIG.
[0088]
The bus must be idle before a node can initiate a data transfer. In order to confirm that the data transfer started earlier has been completed and the bus is currently in an idle state, a predetermined idle time gap length (for example, a subaction gap) individually set in each transfer mode is required. Is detected, and if a predetermined gap length is detected, each node determines that the bus is in an idle state. In step S401, each node determines whether a predetermined gap length corresponding to each data to be transferred, such as asynchronous data or synchronous data, has been detected. Unless a predetermined gap length is detected, it is not possible to request the right to use the bus necessary to start the transfer.
[0089]
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, sends a signal requesting the right to use the bus to the route in step S403. I do. The signal indicating the request for the right to use the bus is finally delivered to the root node while being relayed to each device in the network, as shown in FIG. If it is determined in step S402 that there is no data to be transferred, the process returns to step S401.
[0090]
Upon receiving at least one signal requesting the right to use the bus in step S404, the root node checks the number of nodes requesting the right to use in step S405. If it is determined in step S405 that there is only one node requesting the right to use, that node is given the right to use the bus immediately thereafter. If there are a plurality of nodes requesting the right to use, an arbitration operation is performed in step S406 in which the number of nodes to which the bus use is granted immediately after is limited to one. This arbitration work does not always give a bus use permission only to the same node, but equally gives a bus use permission (fair arbitration).
[0091]
The process of the root node branches in step S407 according to one node that has won the arbitration in step S406 and another node that has lost the arbitration. If one node has won the arbitration or one node has requested the right to use the bus, a permission signal indicating permission to use the bus is sent to the node in step S408. The node receiving this permission signal starts transferring data (packets) to be transferred immediately (step S410). In step S409, a DP (data prefix) packet indicating that the request for the right to use the bus has been rejected is sent to the node that has lost the arbitration. The processing of the node that has received the DP packet returns to step S401 again to request the right to use the bus. The process of the node that has completed the data transfer in step S410 also returns to step S401.
[0092]
[Transaction layer]
There are three types of transactions: read transaction, write transaction, and lock transaction.
[0093]
In a read transaction, an initiator (request node) reads data from a specific address in a memory of a target (response node). In a write transaction, an initiator writes data to a specific address of a 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 data of the address of the target to become a designated address indicating a specific address of the target. Then, the data at the specified address is updated with the update data.
[0094]
FIG. 19 is a diagram showing a request / response protocol for each command of read, write, and lock based on the CSR architecture in the transaction layer 814. The request, notification, response, and confirmation shown in the figure are service units in the transaction layer 814. .
[0095]
A transaction request (TR_DATA.request) is a packet transfer to the response node, a transaction notification (TR_DATA.indication) is a notification that the request has reached the response node, a transaction response (TR_DATA.response) is an acknowledgment transmission, and a transaction confirmation (TR_DATA) .Confirmation) is the receipt of an acknowledgment.
[0096]
[Link Layer]
FIG. 20 is a diagram showing a service in the link layer 812. A link request (LK_DATA.request) for requesting packet transfer to the response node, a link notification (LK_DATA.indication) for notifying the response node of packet reception, and a response from the response node It is divided into service units of a link response (LK_DATA.response) for acknowledgment transmission and a link confirmation (LK_DATA.confirmation) for acknowledgment transmission of the requesting node. One packet transfer process is called a subaction, and there are two types of asynchronous subactions and synchronous subactions. Hereinafter, the operation of each sub-action will be described.
[0097]
[Asynchronous subaction]
An asynchronous subaction 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, a node desiring data transfer requests a bus use right, and bus arbitration is executed.
[0098]
When use of the bus is permitted by the bus arbitration, the data is then packet-transferred, and the node receiving this data returns a response code ACK after a short gap called an ACK gap, The data transfer is completed by returning the response packet. The ACK is composed of 4-bit information and 4-bit checksum, and includes information indicating success, busy state, or pending state, and is immediately returned to the data transmission source node.
[0099]
FIG. 22 shows the format of the packet for asynchronous transfer. The packet has a header portion in addition to the data portion and the data CRC for error correction, and the header portion has a destination node ID, a source node ID, a transfer data length, various codes, and the like written therein.
[0100]
Asynchronous transfer is one-to-one communication from a transmitting node to a receiving node. The packet sent from the source node is distributed to each node in the network, but each node ignores the packet other than its own, so that only the node designated as the destination receives the packet.
[0101]
[Split transaction]
The service in the transaction layer 814 is performed by a set of the transaction request and the transaction response shown in FIG. Here, if the processing in 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 independent subactions of the link layer 812, but are processed by one subaction. It becomes possible. However, if the processing speed of the target is slow, it is necessary to process the request and response in separate transactions. This operation is called a split transaction.
[0102]
FIG. 23 is a diagram showing an operation example of the split transaction. In response to a write request from the controller of the initiator (request node), the target returns a pending. As a result, the target can return the confirmation information for the write request from the controller, and can gain time for processing the data. Then, after a sufficient time has elapsed for data processing, the target notifies the controller of a write response and terminates the write transaction. At this time, the operation of the link layer 812 by another node is possible between the request and the response sub-action.
[0103]
FIG. 24 is a diagram showing an example of a temporal transition of the transfer state when a split transaction is performed. Subaction 1 represents a request subaction, and subaction 2 represents a response subaction.
[0104]
In sub-action 1, the initiator sends a data packet representing a write request to the target, and the target receiving the response returns the pending indicating the confirmation information by an acknowledge packet, thereby completing the request sub-action.
[0105]
Then, after the sub-action gap is inserted, in sub-action 2, the target sends a write response with no data packet, and the initiator receiving the response returns a complete response with an acknowledgment packet, thereby completing the response sub-action. I do.
[0106]
Note that the time from the end of sub-action 1 to the start of sub-action 2 is the minimum time corresponding to the sub-action gap, and the maximum time can be extended to the maximum waiting time set in the node.
[0107]
Synchronous subaction
This synchronous transfer, which can be said to be the greatest feature of the 1394 serial bus, is particularly suitable for transfer of data that requires real-time transfer such as AV data. Also, while asynchronous transfer is one-to-one transfer, this asynchronous transfer can uniformly transfer data from one source node to all other nodes by a broadcast function.
[0108]
FIG. 25 is a diagram showing a temporal transition in the synchronous transfer. The synchronous transfer is executed at regular intervals on the bus, and this time interval is called a synchronous cycle. The synchronization cycle time is 125 μs. A cycle start packet (CSP) 2000 indicates the start of the synchronization cycle and synchronizes the operation of each node. The node that transmits CSP2000 is a node called a cycle master. After the transfer in the previous cycle is completed and a predetermined idle period (subaction gap 2001) has passed, CSP2000 notifying the start of this cycle is transmitted. I do. That is, the time interval at which the CSP2000 is transmitted is 125 μS.
[0109]
Also, as shown in FIG. 25 as channel A, channel B, and channel C, by assigning a channel ID to each of a plurality of types of packets in one synchronization cycle, the packets can be distinguished and transferred. As a result, real-time transfer can be performed substantially simultaneously between a plurality of nodes, and the receiving node only needs to receive data of a desired channel ID. The channel ID does not represent the address of the receiving node or the like, but is merely a logical number for data. Therefore, a certain transmitted packet is distributed from one source node to all other nodes, that is, broadcast.
[0110]
Prior to packet transmission by synchronous transfer, bus arbitration is performed as in asynchronous transfer. However, since it is not one-to-one communication unlike asynchronous transfer, there is no ACK of a return code for acknowledgment in synchronous transfer.
[0111]
The iso gap (synchronization gap) shown in FIG. 25 indicates an idle period necessary for confirming that the bus is in an idle state before performing synchronous transfer. The node that detects the predetermined idle period determines that the bus is in the idle state, and requests the right to use the bus when performing synchronous transfer, so that bus arbitration is performed.
[0112]
FIG. 26 shows an example of a packet format for synchronous transfer. Each packet divided into each channel has a header part in addition to a data part and data CRC for error correction, and the header part has a transfer data length, a channel number, and the like as shown in FIG. Various codes and a header CRC for error correction are written.
[0113]
[Bus cycle]
Actually, synchronous transfer and asynchronous transfer can coexist in the 1394 serial bus. FIG. 28 is a diagram showing a temporal transition of a transfer state when synchronous transfer and asynchronous transfer are mixed.
[0114]
Here, as described above, the synchronous transfer is executed prior to the asynchronous transfer. The reason is that after CSP, synchronous transfer can be started with a gap (isochronous gap) shorter than the gap (subaction gap) of the idle period necessary to start asynchronous transfer. Therefore, synchronous transfer is performed with priority over asynchronous transfer.
[0115]
In the general bus cycle shown in FIG. 28, 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 a node that intends to perform synchronous transfer after waiting for a predetermined idle period (synchronization gap) participates in bus arbitration and starts packet transfer. In FIG. 28, channel e, channel s, and channel k are synchronously transferred in order.
[0116]
After the operations from the bus arbitration to the packet transfer are repeatedly performed for the given channel, when all the synchronous transfers in the cycle #m are completed, the asynchronous transfer can be performed. That is, when the idle time reaches a subaction gap where asynchronous transfer is possible, a node that wants to perform asynchronous transfer participates in bus arbitration. However, the asynchronous transfer can be performed only when a subaction gap for starting the asynchronous transfer is detected during a period from the end of the synchronous transfer to the time (cycle sync) at which the next CSP should be transferred. .
[0117]
In cycle #m shown in FIG. 28, after synchronous transfer for three channels, two packets (packet 1 and packet 2) including ACK are transferred by asynchronous transfer. After the asynchronous packet 2, the time to start the cycle m + 1 (cycle sync) is reached, and the transfer in the cycle #m ends here. However, when the time to transmit the next CSP (cycle sync) is reached during asynchronous or synchronous transfer, the transfer is not forcibly interrupted, and after the transfer is completed, the CSP of the next synchronous cycle is transmitted after an idle period. I do. That is, when one synchronization cycle continues for 125 μs or more, the next synchronization cycle is shortened by 125 μs by the extension. As described above, the synchronization cycle can be exceeded or shortened on the basis of 125 μs.
[0118]
However, the synchronous transfer is performed every cycle if necessary 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.
[0119]
[FCP]
In the AV / C protocol, a function control protocol FCP (Functional Control Protocol) is prepared for controlling devices on the 1394 serial bus. As the transmission and response of the FCP control command, an asynchronous packet defined by IEEE1394 is used. In FCP, the controlling node is called a controller, and the controlled node is called a target. An FCP packet frame sent from the controller to the target is an AV / C command frame, and an FCP packet frame returned from the target to the controller is called an AV node. / C response frame.
[0120]
FIG. 29 shows a case where the node A is a controller and the node B is a target. Of the register addresses prepared respectively, 512 bytes from address 0x0000B00 are a command register, and 512 bytes from address 0x0000D00 are a response register. Data is written to a register at a specified address by a 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 general AV / C transaction, the target needs to respond to the controller with a response frame within 100 ms after receiving the command frame.
[0121]
FIG. 30 is a diagram showing a packet format of the asynchronous transfer including the FCP packet frame. An AV / C transaction is executed by inserting a command frame or a response frame into the data area of the asynchronous data packet shown in FIG. .
[0122]
FIG. 31 is a diagram showing the structure of an AV / C command frame, and FIG. 32 is a diagram showing the structure of an AV / C response frame. As the FCP packet frame, the data portion of the FCP follows ctype, response, subunit_type, subunit_ID of the header. The structure is connected.
[0123]
“ctype” indicates a command type in a command frame, and indicates each state of CONTROL, STATUS, INQUIRY, and NOTIFY.
[0124]
"response" indicates a response code in the response frame, and indicates each state such as ACCEPTED, REJECTED, IN_TRANSITION, IMPLEMENTED, CHANGED, and INTERIM.
[0125]
Further, subunit_type indicates the classification of the device, and subunit_ID indicates the instance number.
[0126]
The data portion of the FCP has a configuration of an operation code and an operand, and can control a target using various AV / C commands and can respond to an AV / C response.
[0127]
The operation code (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 with the content according to the command type set in ctype.
[0128]
A command in which “CONTROL” is designated by “ctype” means a control command, which controls a target device or sets a target with contents set after an operand (opland). A command in which “STATUS” is designated by ctype is for obtaining a status corresponding to the command. The command in which “INQUIRY” is specified by ctype is for inquiring about the contents that can be set by the command. A command in which “NOTIFY” is specified in ctype is for confirming the command.
[0129]
For each command, the contents required for each command are set in the operands and written in the command frame.
[0130]
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. In the response operand, information indicating whether the execution of the command ended normally or ended in error is set, so that error processing can be performed in accordance with this operand.
[0131]
[LOGIN protocol]
[Communication using LOGIN protocol]
FIG. 33 is a diagram in which the interface of the 1394 serial bus is compared with each layer of the OSI model often used in the LAN. The physical layer 1 and the data link layer 2 of the OSI model correspond to a physical layer 811 and a link layer 812, which are 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. The LOGIN protocol 7 operates between the lower layer 4 of the 1394 serial bus interface and the transport protocol layer 5.
[0132]
In the example 1 shown in FIG. 33, a device conforming to the serial bus protocol (SBP-2) 8 for peripheral devices such as a printer is provided with a LOGIN protocol 7 so that a partner device conforms to the SBP-2 protocol. Can be used to notify that data is to be exchanged.
[0133]
In the 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 it is determined whether the devices support each other's protocol. be able to.
[0134]
FIG. 34 is a diagram showing a basic operation of the LOGIN protocol 7. When the printer device executes a print task (print task) 10 from the host device, first, the printer protocols A, B, and C prepared in the printer are provided. Is determined based on the communication of the LOGIN protocol 7, and thereafter, 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 prepared in the host device by the LOGIN protocol 7, and determines the transport protocol of the host device. 5, the print task 10 is processed by exchanging print data and commands according to the selected printer protocol.
[0135]
FIG. 35 is a diagram showing an example of a connection form in the 1394 serial bus. A device (PC12, scanner 13, DVC14, etc.) in which the LOGIN protocol 7 is mounted on the printer 11 that supports a plurality of printer protocols (multi-protocol support). Indicates a connected state. The printer 11 switches the printer protocol according to the transport protocol 5 of the partner device requesting the connection, which is determined by the LOGIN protocol 7, so that the printing task from each device can be processed without any problem.
[0136]
FIG. 36 is a diagram showing the flow of the login operation. In step 1: The host device locks the target device (in this case, a multi-protocol printer). The target device checks the capabilities (including the transport protocol) of the host device, and the capabilities are stored in a register 503 described later.
[0137]
In step 2: communication of print data is performed according to the protocol set in step 1.
[0138]
In step 3: The host device disconnects the connection with the target device.
[0139]
FIG. 37 shows the CSR of the 1394 serial bus provided in the printer which is the target device for the LOGIN protocol 7, and shows a lock register (lock) 501, a protocol register (protocol) 502, and a capability register (capability) 503. These registers are arranged at predetermined addresses in the initial unit space in the address space of the 1394 serial bus. That is, as described with reference to FIG. 4, of the 48-bit address width given to the device, 0xFFFFF in the first 20 bits is called a register space, and the first 512 bytes of the register (which becomes the core of the CSR architecture) CSR core).
[0140]
The lock register 501 indicates the locked state of the resource. A value “0” indicates a state in which a login is possible, and a value other than “0” indicates that the user is already logged in the locked state. The capability register 503 indicates a protocol that can be set for each bit, indicates that a protocol corresponding to a bit of a value “1” is settable, and indicates that a protocol corresponding to a “0” is not settable 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 becomes “1”. FIG. 38 is a flowchart showing a login process in the host device.
[0141]
In order to start login, first, the data of a lock register 501, a protocol register 502, and a capability register 503 of a target device to be logged in, for example, a printer, are confirmed by a read transaction. Here, it is confirmed from the data of the capability register 503 whether or not the target device supports the protocol used by the host device for communication (step S601).
[0142]
If the protocol of the host device is not supported by the target device, the login is stopped in the next step S602. If the data in the lock register 501 is other than “0”, it is assumed that another device is logging in and the login is stopped. If the data of the login register 501 is "0", it is determined that the login is possible at present (step S602).
[0143]
If the login is possible, the process proceeds to the resource lock process, and for example, “1” is written into the lock register 501 of the printer using a lock transaction, and login is set (step S603). In this state, the target device is locked, control from other devices is not possible, and register change is also impossible.
[0144]
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 a protocol that can be used by the host device before receiving print data. In this embodiment, by setting the corresponding bit of the protocol register 502 of the printer by the write transaction of the host device, the protocol to be used is notified to the printer (step S604).
[0145]
At this point, the protocol used by the host device for communication is notified to the target device, and the target device is in a locked state, so that the host device currently logged in to the target device transmits data, in this case, print data ( Step S605).
[0146]
When the data transmission is completed, 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).
[0147]
FIG. 39 is a flowchart showing a login process of a printer as a target device. A printer is usually in a state of waiting for a login from a host device. Since a 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, the register needs to be always readable from another device.
[0148]
It is now assumed that the printer has been locked by the host device that intends to execute printout (step S701). The printer waits for the next notification of the use protocol from the host device (step S702). The reason why the printer waits for the notification of the used protocol after the printer is locked is to prevent the protocol register 503 from being rewritten by a request from another device during login.
[0149]
When notified of the used protocol (step S703), the printer switches its own protocol to the notified used protocol (steps S704, S706 and S708), and performs communication in accordance with the protocol of the host device (step S705). , S707 or S709).
[0150]
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 a state of waiting for login (step S701).
[0151]
[Example considering device without LOGIN protocol]
FIG. 40 is a diagram for explaining an example in which a device that does not implement the LOGIN protocol 7 is considered. In comparison with the first example shown in FIG. 34, a device that does not have the LOGIN protocol 7 but has the protocol D is also supported. Is the feature. That is, in order to guarantee, for example, a printing operation not only for a device having the LOGIN protocol 7 but also for a device that supports only the existing protocol D (for example, the AV / C protocol), the LOGIN protocol 7 is used on the printer side. It adds a printer protocol corresponding to a device that does not have it.
[0152]
To explain this operation, if the printer recognizes that the host device does not support the LOGIN protocol 7 by a print request made at the beginning of the connection, the printer attempts to communicate with the host device using the protocol D and performs communication. Is satisfied, the print task 10 is executed according to the protocol D.
[0153]
FIG. 41 is a diagram in which the configuration shown in FIG. 40 is compared with each layer of the OSI model. Example 3 is a model of an AV device 15 compliant with the current AV / C protocol in which the LOGIN protocol 7 is not mounted. I have. Example 4 is modeled on a scanner 16 in which a non-standard protocol for a scanner without the LOGIN protocol 7 is installed.
[0154]
In other words, 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.
[0155]
[Direct print protocol]
Hereinafter, a printing procedure between the printer and the image supply device according to the present invention will be described. However, in order to directly connect the printer and the image supply device and cause the printer to perform image formation based on image data supplied from the image supply device. Is referred to as “direct print protocol (DPP)”.
[0156]
The basics of DPP are a command register (command) for writing a command, a response register (response) for writing a response to a command, and a transfer in an initial unit space (shown as a unit space in FIG. 4) of the 1394 serial bus. It comprises a data register (data) for writing data and a format register (format) for handling format information corresponding to the data format of each transfer data.
[0157]
FIG. 42 shows this register map. The command register and the response register are the same as those described with reference to FIG. In the following description, an example will be described in which an image supply device is a controller and a printer is a target, and image data is supplied from the image supply device to the printer to print an image.
[0158]
The command register 42-1 is arranged at a fixed address of 0xFFFFF0000B00 on the printer side, has a 512-byte memory space, and is used by 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.
[0159]
The response register 42-2 is arranged at a fixed address of 0xFFFFF0000D00 on the image supply device side, has a 512-byte memory space, and writes responses to various commands written from the image supply device to the printer. belongs to. Of course, when a response register is also provided on the printer side, it is possible to write a 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 and described.
[0160]
The data register 42-3 has FFFFFF0003000h as a default address, and is set to any valid address by a BlockAddress, BufferConfig command (a command for defining an address of the data register). The memory space of the data register 42-3 is set in a range predetermined by a BlockSize, BufferConfig command (a command that defines 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. When printing is performed, print data is written from the image supply device to the printer. In the print data, data written in the data register 42-3 according to a data format of a preset image format is referred to as a data frame.
[0161]
The format register 42-4 is a group of registers corresponding to each data format described later, and each register is a register for setting format information necessary 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.
[0162]
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. The printer performs printing in accordance with the frames output from the image supply device.
[0163]
The command sent from the image supply device to the printer is written into the command register 43-4 of the printer as a command frame. This command is a command for performing the printing shown in FIG. The response to this command is written into the response register 43-2 of the image supply device by the printer. This response includes information indicating whether the command was executed correctly, a return value for the command, and the like. Print data sent from the image supply device to the printer is written to the data register 43-6 of the printer as a data frame. The format information sent from the image supply device to the printer is written into the format register 43-7 of the printer as a format frame.
[0164]
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 inquiring and a read / write register CONTROL / STATUS 44-2 for setting and information acquisition. INQUIRY 44-1 and CONTROL / STATUS 44-2 are formed from register groups having the same configuration. That is, the registers 44-3 to 44-7 and the registers 44-9 to 44-13 that constitute the register group.
[0165]
More specifically, the format register group includes registers 44-3 and 44-4 (44-9 and 44-10) that form a common register group, and a printer format register group (print format register group). ), The registers 44-5 to 44-7 (44-11 to 44-13).
[0166]
The common register group is a group of registers in which registers common to all data formats are collected. A register GLOBAL 44-3 (44-9) common to all printers and a register LOCAL 44-4 unique to an individual printer are provided. (44-10).
[0167]
The printer format register group is a group of registers in which information unique to each data format is collected. The printer format register group includes n from register format [1] 44-5 (44-11) to format [n] 44-7 (44-13). Register group. The registers format [1] to format [n] correspond to a data format described later, and one printer format register group is assigned to each data format to be mounted.
[0168]
The address of each format register is provided to the image supply device as a response to a command for setting a data format.
[0169]
FIG. 45 is a diagram showing a detailed configuration example of the status register status register 44-8 of the common register group. The status register 44-8 has a 32-bit common status register (common status register) 45-1 for holding a status common to each vendor's printer, and a vendor-specific status (vendor) for holding a status defined by each vendor. (specific status register) 45-2. Further, the extension to the vendor-specific status register 45-2 is defined as follows by the v flag (vendor status available flag) in the 31st bit of the common status register 45-1.
v flag: '0' = not available
'1' = available
[0170]
The information held in the common status register 45-1 is as follows.
error. warning: Status such as error or warning
paper state: Status related to recording paper
print state: Status related to printing status
[0171]
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. The register GLOBAL 44-3 (44-9) holds information common to all printers equipped with a DPP (Direct Print Protocol), that is, a register that collects information that does not differ depending on the type of printer. FIG. 46 shows an example thereof, in which media-type 46-1 indicates the type of recording medium, paper-size 46-2 indicates the size of the recording paper, page-margin 46-3 indicates the margin value of the page, and page-margin 46-3. Page-length 46-4 indicating the length, page-offset 46-5 indicating the page offset, print-unit 46-6 indicating the unit information of the printer, color-type 46-7 indicating the color type of the printer, data And a bit-order 46-8 indicating the bit order of.
[0172]
FIG. 47 is a diagram showing a detailed example of information held in the registers LOCAL 44-4 (44-10) of the common register group. The register LOCAL 44-4 (44-10) is a register that holds information unique to each model of the printer on which the DPP is mounted, that is, information that differs depending on the type of the printer. FIG. 47 shows an example thereof, and includes a paper 47-1 indicating the type of recording paper unique to the printer, a CMS 47-2 indicating the color matching method, and an ink 47-3 indicating the type of ink of an ink jet printer, for example.
[0173]
FIG. 48 is a diagram illustrating 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 image data formats, is held. In this case, the input ratio in the X direction inX-rate 48-1, the input ratio in the Y direction inY-rate 48-2, the output ratio in the X direction outX-rate 48-3, and the output ratio in the Y direction outY- rate 48-4. In this case, printing can be performed by scaling the given image data in the EXIF format in the X and Y directions in accordance with the contents of each register.
[0174]
FIG. 49 is a diagram illustrating an example of information stored in the register format [2] 44-6, which is an example in which information on a Raw RGB format, which is one of image data formats, is stored. The Raw RGB format is an image format in which each pixel is composed of R (red), G (green), and B (blue) data. In this case, the ratio of the input in the X direction inX-rate 49-1, the ratio of the input in the Y direction inY-rate 49-2, the ratio of the output in the X direction outX-rate 49-3, and the ratio of the output in the Y direction 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 type of the pixel. Pixel-format 49-12 as shown. In this case, it is possible to print the image data in the given Raw RGB format by performing scaling and resolution conversion in the X and Y directions in accordance with the contents of each register and further processing based on information relating to the image size. Become.
[0175]
FIG. 50 is a diagram showing a list of commands and responses to the commands. Commands are classified into several types. The classification includes "status" related to status, "control" for printer control, "block / buffer" for data transfer setting, "channel" for channel setting, "transfer" for transfer method, and format setting. "Format", "login" for login, and "data" for data transfer.
[0176]
More specifically, the “status” includes a command GetStatus for obtaining the status of the printer and a response GetStatusresponse 50-1 thereof.
[0177]
The "control" includes a command PrintReset for resetting the printer and its response PrintResetResponse 50-2, a PrintStart and a response PrintStartResponse 50-3 for instructing the start of printing, a PrintStop and a response PrintStopResponse 50-4 for instructing to stop the printing, and printing. InsertPaper for instructing supply of recording paper and its response InsertPaperResponse 50-5, EjectPaper for instructing ejection of recording paper and its EjectPaperResponse 50-6, CopyStart for instructing to start copying image data, and its response CopyStartR. sponse 50-7, and, the like CopyEnd and the response CopyEndResponse 50-8 instructs the copy end of the image data.
[0178]
The “block / buffer” includes BlockSize and its response BlockSizeResponse 50-9 for specifying the size of the block, BlockAddress and its response BlockAddressResponse 50-10 for specifying the address of the block, and FreeBlock and its response FreeBlockRs for acquiring the number of empty blocks. 50-11, WriteBlocks for instructing data writing to the block and its response WriteBlocksResponse 50-12, BufferConfig for designating buffer information and its response BufferConfigResponse 50-13, and start of data acquisition from the buffer. There is such as a constant to SetBuffer and its response SetBufferResponse 50-14.
[0179]
As the “channel”, there are OpenChannel for opening a channel and its response OpenChannelResponse 50-15, and CloseChannel for closing a channel and its response CloseChannelResponse 50-16.
[0180]
The “transfer” includes a TransferMethod for designating a data transfer method and a TransferMethodResponse 50-17 response to the TransferMethod.
[0181]
The “format” includes SetFormat for setting a format and a response SetFormatResponse 50-18 thereof.
[0182]
The “login” includes Login for logging in and its response LoginResponse 50-19, Logout for logging out and its response LogoutResponse 50-20, and Reconnect for performing reconnection and its response ReconnectResponse 50-21.
[0183]
The above commands are written in the command frame.
[0184]
Further, the “data” includes a WriteBlock 50-22 for writing data, a WriteBuffer 50-23, and a PullBuffer 50-24 for reading data. These commands are for writing and reading data frames, and there is no corresponding response.
[0185]
The image supply device sets a value corresponding to each command shown in FIG. 50 in an operation code (opcode) of the command frame shown in FIG. 31 and writes the value in the command register 43-4 of the printer. Is executed. 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 the response in the response register 43-2 of the image supply device. With this response, the image supply device can receive the execution result of each command.
[0186]
FIG. 51 is a diagram illustrating an example of an image data format supported by the DPP. The printer must support at least one of these formats, RAW image data. Optionally, other formats can be supported.
[0187]
FIG. 52 is a diagram showing the flow of the 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. With the returned response, the image supply device knows the address of the INQUIRY register of the printer.
[0188]
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. Based on the returned response, the image supply device knows the address of the CONTROL / STATUS register of the printer.
[0189]
In steps S504-1 to S504-m, the image supply device reads the INQUIRY register of the printer 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, knows the set value of the format, and reads the STATUS / CONTROL register of the printer in steps S506-1 to S506-n. Write the data and set the format.
[0190]
The following two types of packets are used for data transfer in DPP.
・ Control command packet for flow control
.Packets for data transmission
[0191]
In the present embodiment, five types of data transfer methods are listed below according to the difference between the flow control method and the data transmission method. In any of the methods, the control command for flow control conforms to the FCP.
Transfer method 1: Response model (Response Model)
Transfer method 2: Simple response model (Simple Response Model)
Transfer method 3: Push large buffer model (PUSH Large Buffer Model)
Transfer method 4: Pull buffer model (PULL Buffer Model)
Transfer method 5: Synchronous model (Isochronous Model)
[0192]
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. As shown in FIG. 53, TransferMethod is used for the command, and TransferMethodResponse is used for the response.
[0193]
FIG. 53 is a diagram illustrating an example of a setting procedure of the data transfer method. The image supply device obtains the currently available printer data transfer method using the TransferMethod command and response of the command type INQUIRY (S600-1 and S600-2), and obtains the current data transfer method and response using the TransferMethod command and response of the command type CONTROL / STATUS. The data transfer method set in the printer is acquired and set (S600-3 and S600-4).
[0194]
Incidentally, in any of the above five types, the control command for flow control conforms to FCP, which is a protocol for controlling devices on the 1394 serial bus. The transfer of the FCP control command is always performed by an asynchronous write transaction for both transmission and response.
[0195]
FIG. 54 is a diagram showing a register map in the address space of the 1394 serial bus of registers required for the transfer method 1 and the transfer method 2. In this embodiment, the controlling node is an image supply device (corresponding to a controller in FCP), and the controlled node is a printer (corresponding to a target in FCP).
[0196]
Both the image supply device and the printer have a command register (601-1 and 601-7) of 512 bytes from offset 0x0B00 and a response register (601-2 and 601-8) of 512 bytes from offset 0x0D00 in the register space. These registers comply with the FCP protocol and AV / C commands.
[0197]
The flow control is performed by writing the command frame 601-4 and the response frame 601-5 in the command register (601-1 and 601-7) and the response register (601-2 and 601-8). For transfer of print data, a dedicated data frame is defined. That is, the data registers (601-3 and 601-9) for the block size are provided from the offset 0x3000 of the register space, and the data frames 601-6 are written in the data registers (601-3 and 601-9) to thereby obtain the print data. A transfer is performed. The block size is, for example, 512 bytes.
[0198]
FIG. 55 shows an example of a data packet frame, which is composed of a data header 602-1, a data payload 602-2, and the like.
[0199]
FIG. 56 is a diagram showing a configuration example of the data header 602-1. The upper 8 bits are a block count area 603-1 and the lower 8 bits are a 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.
[0200]
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 into the data register 604-1 of the printer. The printer has buffers (604-2 to 604-5) of the same size as the data packets, and the data packets written to the data register 604-1 are sequentially stored in these buffers (604-2 to 604-5). Moved. The number of these data buffers is desirably 255, which is equal to the maximum value of the block count, but may be less. Here, each buffer corresponds to a block count value, and a data packet having a block count of “0” is stored in a block [0] buffer, and a data packet having a block count of “1” is stored in a block [1] buffer. Is stored. The data packets stored in the buffers (604-2 to 604-5) are developed in the memory space 604-6 of the printer after the data header 602-1 is removed.
[0201]
[Transfer method 1]
The transfer method 1, which is a response model, is a method in which 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.
[0202]
FIG. 58 is a diagram showing a FreeBlock command and a response in the transfer method 1. In the transfer method 1, prior to data transfer, a FreeBlock command and a response are used to acquire information indicating how many data packets the image supply device transfers.
[0203]
The image supply device transfers the FreeBlock command by a write transaction (S605-1), and the printer returns an ACK packet indicating confirmation of the transaction (S605-2). The printer returns a FreeBlock response to notify the currently available FreeBlockCount (S605-3), and the image supply device returns an ACK packet indicating confirmation of the transaction (S605-4).
[0204]
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 using the DPP Login command and response (S606-1 and S606-2), and sets a format used for data transfer using the format register group (S606-3). Thereafter, the logical channel is opened by the OpenChannel command and response (S606-4 and S606-5). Subsequently, data transfer is started, and the print data is transferred in the data packet format shown in FIG. In addition, the packet transfer is performed in one cycle by transferring blocks of a number equal to the number of data buffers on the printer side indicated by reference numerals 604-2 to 604-5 in FIG.
[0205]
The transfer of the print data in the transfer method 1 is performed as follows. The image supply device obtains the number of FreeBlocks of the printer from the FreeBlock command and response (S606-6 and S606-7), and sequentially transfers the same number of data packets as the number of FreeBlocks using the 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, the WriteBlock command has no response, and an ACK packet for confirming that the data packet has been stored in the data register 601-9 is returned from the printer (S606-9).
[0206]
Then, the block transfer consisting of the repetition of the packet transfer by the WriteBlock command and the return of the corresponding ACK packet of the number equal to the number of FreeBlocks is repeated until all the print data is output from the image supply device. In the meantime, the number of FreeBlocks of the printer is obtained by the FreeBlock command and response.
[0207]
When the transfer of the print data is completed, the image supply device closes the logical channel using the CloseChannel command and response (S606-10 and S606-11), and logs out of the printer using the DPP Logout command and response (S606-12 and S606). 13).
[0208]
[Transfer method 2]
The transfer method 2 which is a simplified response model performs data transfer in the same procedure as the transfer method 1 except for a method of acquiring the number of FreeBlocks.
[0209]
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 using the DPP Login command and response (S607-1 and S607-2), and sets a format used for data transfer using the format register group (S607-3). Then, the logical channel is opened by the OpenChannel command and response (S607-4 and S607-5). Subsequently, data transfer is started, and the print data is transferred in the data packet format shown in FIG. In addition, the packet transfer is performed in one cycle by transferring blocks of a number equal to the number of data buffers on the printer side indicated by reference numerals 604-2 to 604-5 in FIG.
[0210]
The transfer of the print data in the transfer method 2 is performed as follows. The image supply device obtains the number of FreeBlocks of the printer from the WriteBlocks command and the response (S607-6 and S607-7). However, the response in step S607-7 is of the INTERIM (provisional) type in order to obtain the number of FreeBlocks thereafter only by the response from the printer. The image supply device sequentially transfers the same number of data packets as the obtained number of FreeBlocks by the WriteBlock (S607-8), and returns the above-mentioned ACK packet from the printer (S607-9). Then, the block transfer consisting of the repetition of the packet transfer by the WriteBlock command and the return of the corresponding ACK packet of the number equal to the number of FreeBlocks is repeated until a series of print data is completely output from the image supply device. However, the number of FreeBlocks in the block transfer in the second and subsequent rounds is notified to the image supply device by a WriteBlocks response sent from the printer at the end of each block transfer cycle (S607-10). This WriteBlocks response is a CONTINUE type in order to continue acquiring the number of FreeBlocks only by the response of the printer.
[0211]
When the transfer of the print data is completed, the image supply device closes the logical channel using the CloseChannel command and response (S607-11 and S607-12), and logs out of the printer using the DPP Logout command and response (S607-13 and S607-). 14).
[0212]
[Method of obtaining the number of FreeBlocks]
Hereinafter, a method for acquiring the number of FreeBlocks, which is the difference between the transfer method 1 and the transfer method 2, will be described in detail.
[0213]
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. FIG. 61 shows the ACK packet of the write transaction omitted in FIG. Both the device and the target device (printer) have relatively low processing speeds in the link layer and the transaction layer.
[0214]
When the image supply device writes the FreeBlock command to the command register by the write transaction (S608-1), the ACK packet indicating the above-mentioned pending is returned from the link layer of the printer (S608-2). Next, the image supply device sends a FreeBlock command with no data (S608-3), receives an ACK packet indicating "complete" from the printer (S608-4), and ends one write transaction.
[0215]
Subsequently, the printer returns a FreeBlock response, which is also written in the response register as a FreeBlock response including the number of FreeBlocks, similarly to the FreeBlock command in step S608-1 (S608-5). An ACK packet indicating “pending” is returned from the link layer of the image supply device (S608-6), a FreeBlock response with no data is sent (S608-7), and an ACK packet indicating “complete” is received (S608-8). , One write transaction ends.
[0216]
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. Can be obtained.
[0219]
The acquisition of the number of FreeBlocks is necessary for each cycle of block transfer. Therefore, the transfer method 2 can reduce the number of packets transferred on the bus compared to the transfer method 1.
[0218]
FIG. 62 is a diagram showing WriteBlocks of the transfer method 1 and the transfer method 2 in detail. Since the WriteBlock does not require a response, the WriteBlock (S609-1), an ACK packet indicating pending (S609-2), a WriteBlock with no data (S609-3), and an ACK packet indicating complete (S609-4). Data can be transferred in half the procedure compared to the case of transferring commands and responses, and relatively high-speed data transfer can be performed even when the processing of the link layer and the transaction layer is relatively low. .
[0219]
FIG. 63 is a diagram showing WriteBlocks of the transfer method 1 and the transfer method 2 in detail, where the processing of the link layer and the transaction layer is sufficiently fast. In this case, the procedure is a WriteBlock (S610-1) and an ACK packet (S610-2) indicating complete, and more efficient data transfer can be performed.
[0220]
FIG. 64 is a view for explaining WriteBlock error processing when a bus reset occurs, and shows a case where a bus reset occurs during the transfer of the n-th (= 0 to 255) packet in a certain block transfer cycle. In a write transaction, a failure of normal data packet transfer can be detected by an ACK packet, but an error at the time of occurrence of a bus reset cannot be detected. Therefore, in the present embodiment, error processing is executed in the following procedure. That is, the number of FreeBlocks is acquired (S611-1), and WriteBlock is performed n times (from S611-2 to S611-6). When a bus reset occurs here (S611-7), the image supply device generates a bus reset. The immediately preceding WriteBlock [n] is performed again (S611-8), and thereafter, the normal processing is continued (S611-9 to S611-14).
[0221]
[Transfer method 3]
FIG. 65 is a diagram illustrating 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.
[0222]
Commands and responses between the image supply device and the printer conforming to the FCP include an operation of writing a command frame 65-7 as command request data from the command register 65-1 of the image supply device to the command register 65-4 of the printer. The process is executed by writing a 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.
[0223]
Also, unlike the FCP, the data frame 65-9 is changed to 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. -9 is used.
[0224]
FIG. 66 is a diagram illustrating an example of an operation flow of the PUSH buffer model between the image supply device and the printer. The operations of Login, Logout, OpenChannel, CloseChannel, and format setting in the command frame and the response frame are the same as those in the transfer method 1 described above, and therefore detailed description is omitted.
[0225]
In FIG. 66, the image supply device makes an inquiry about the buffer area of the printer by using the INQUIRY of the BufferConfig command (S701). On the other hand, the printer returns a buffer size and a buffer address in a BufferConfig response (S702).
[0226]
Next, the image supply device sets a buffer size and a buffer address of the printer to which the data is to be written, using CONTROL of the BufferConfig command (S703). On the other hand, the printer returns that the setting is completed by a BufferConfig response (S704).
[0227]
Next, the image supply device notifies the printer of the start of data transfer by using the SetBuffer command NOTIFY (S705). On the other hand, the printer returns, by the INTERIM of the SetBuffer response, that it is ready to receive the data (S706), and starts the data transfer. Then, the printer notifies the image supply device that the data transfer to the initially set buffer area has been completed by the CONTINUE of the SetBuffer response (S709).
[0228]
WriteBuffer in step S707 indicates a data frame writing operation by the image supply device, and performs an operation of sequentially writing data to a buffer address set in the printer.
[0229]
WriteTransactionResponse in step S708 indicates a response packet when a data frame is synchronously transferred. As described above, if the data capture speed of the printer is fast enough, the processing can be completed using the acknowledgment of one write transaction.However, if the data capture takes a long time, an independent response will be sent as a split transaction. Will occur.
[0230]
Step S710 shows a process of transferring a plurality of data frames. That is, data is transferred by a continuous write transaction for the buffer size set by the BufferConfig command. Such a data transfer method using a continuous write transaction is referred to as a “PUSH data transfer method” or simply “PUSH method”.
[0231]
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 can be configured not to include a header or the like. .
[0232]
FIG. 68 is a diagram showing an example of the relationship between the data register and the buffer of the printer. The data written in the data register 68-1 is directly stored in the address of the printer memory space 68-2 indicated by the BufferAddress determined by the offset Destination_Offset. Written. Since the offset value is incremented by the data length Data_Length, data can be continuously written in the area indicated by the buffer size BufferSize by repeatedly writing data to successive buffer addresses.
[0233]
[Transfer method 4]
FIG. 69 is a diagram illustrating a configuration example of a command register, a response register, and a data register of the image supply device and the printer in the PULL Buffer Model.
[0234]
Commands and responses between the image supply device and the printer conforming to the FCP include an operation of writing a command frame 69-7 as command request data from the command register 69-1 of the image supply device to the command register 69-4 of the printer. The operation is executed by writing a 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.
[0235]
Also, unlike the FCP, the data frame 69-9 performs a one-way operation of reading image data from the data register 69-3 of the image supply device to the data register 69-6 of the printer using a read transaction. 9 is used.
[0236]
FIG. 70 is a diagram illustrating an example of an operation flow of the PULL buffer model between the image supply device and the printer. The operations of Login, Logout, OpenChannel, CloseChannel, and format setting in the command frame and response frame are the same as those of the above-described transfer method 1, and the commands and responses (S711 to S714) of BufferConfig, SetBuffer are described above. Since the method is the same as the method 3, detailed description is omitted.
[0237]
In FIG. 70, the image supply device notifies the printer that data transfer can be started by NOTIFY of the SetBuffer command (S715). On the other hand, the printer returns, by the INTERIM of the SetBuffer response, that the printer is ready for the reception (S716), and starts the data transfer. Then, the printer notifies the image supply device that the data transfer to the initially set buffer area has been completed by the CONTINUE of the SetBuffer response (S719).
[0238]
The printer requests a read transaction by a Pull Buffer request (S717). On the other hand, the image supply device transfers the data by a Pull Buffer response packet (S718), and the data is sequentially written to the buffer address set in the printer.
[0239]
Step S720 shows a process of transferring a plurality of data frames. That is, data is transferred by a continuous read transaction for the buffer size set by the BufferConfig command. Such a data transfer method using a continuous read transaction is referred to as a “PULL type data transfer method” or “PULL method” for short.
[0240]
FIG. 71 is a diagram showing an example of the relationship between the data register and the buffer of the image supply device, and the data of the address of the memory space 72-2 of the image supply device indicated by BufferAddress determined by the offset Destination_Offset set in the data register 71-1. Is read by a read transaction. Since the offset value is incremented by the data length Data_Length, the data can be read continuously from the area indicated by the buffer size BufferSize by repeatedly reading data for successive buffer addresses.
[0241]
[Transfer method 5]
The transfer method 5 which is an isochronous model is one in which the transfer of print data using the asynchronous write transaction of the transfer method 1 described above is replaced with the transfer of print data using a synchronous write transaction. The configuration of the data packet is the same as the configuration shown in FIGS. 55 and 56. The data packet frame processing in the printer in the block transfer is the same as the processing shown in FIG.
[0242]
According to this transfer method, data can be transferred at a fixed time by using a synchronous write transaction.
[0243]
In addition, by performing block transfer, if an error occurs when, for example, one page of print data is transferred collectively, one page of print data is retransmitted, which takes time. However, if the print data is transferred in finer block units, for example, in print band units in an ink jet printer or the like, the print data can be retransmitted efficiently when an error occurs.
[0244]
FIG. 72 shows a command frame and a response frame for flow control. The image supply device writes a command frame into the command register 75-3 of the printer by an asynchronous write transaction. On the other hand, the printer writes a response frame corresponding to the command to the response register 75-2 of the image supply device by an asynchronous write transaction.
[0245]
FIG. 73 is a diagram showing an example of the flow of the printing process. First, similarly to the transfer method 1 described above, the image supply device sends a Login command to the printer (S507). In response, the printer returns a Login response (S508), and the connection is established.
[0246]
Next, similarly to the transfer method 1 described above, the image supply device performs format setting (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.
[0247]
Subsequently, the image supply device 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 ErrorStatus. The FreeBlock number is the number of block buffers secured in blocks in the memory space of the printer, and ErrorStatus is for notifying the image supply device of error information in the previous block transfer. Note that the printer always returns normal to ErrorStatus for the first FreeBlock command after the logical channel is opened.
[0248]
Next, the image supply device performs block transfer of the print data by a synchronous transaction (S514). At this time, the image supply device transmits data packets for the number indicated by the FreeBlock number.
[0249]
Next, the image supply device sends a FreeBlock command to the printer (S515). In response, the printer returns a FreeBlock response (S516). If the ErrorStatus of this response indicates an error, that is, if an error has occurred in the previous block transfer, the image supply device retransmits the data transferred in step S514 (S517). Thereafter, the processes of steps S515, S516 and S517 are repeatedly executed until the data transfer ends normally. If the ErrorStatus indicates normal, the image supply device sends out data packets of the number of FreeBlocks included in the FreeBlock response (S517).
[0250]
The printer can recognize whether an error has occurred by referring to the block count (FIG. 73) of the header part of the transferred data. If the number of FreeBlocks is larger than the number of blocks of data to be transferred, the image supply device sends out dummy packets corresponding to the larger number.
[0251]
Thereafter, the data transfer by the synchronous transaction is repeated until all the series of print data is output from the image supply device.
[0252]
When the data transfer is completed, the image supply device closes the logical channel by using the CloseChannel command and response (S518 and S519), and logs out of the printer by using the DPP Logout command and response (S520 and S520). S521).
[0253]
As described above, according to the present embodiment, an image supply device is directly connected to a printer via a 1394 serial bus or the like, image data of the image supply device is directly sent to the printer, and an image based on the image data is printed by the printer. be able to.
[0254]
Further, since the control command and the print data can be separated, an efficient data transfer method can be provided in a 1394 serial bus or the like.
[0255]
Further, it is possible to provide a data transfer method capable of recovering a transfer error in the 1394 serial bus.
[0256]
Also, by notifying the number of empty blocks in 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 a data transfer method is provided in which overhead required for the determination is eliminated. can do. Furthermore, since data for the notified number of free blocks is transmitted and received at a time, a data transfer method with high transfer efficiency can be provided.
[0257]
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.
[0258]
Also, when data is transferred from the host device to the target device, the exchange of a command and its response is limited to a command instructing the start of data transfer and a response to the command. By not transmitting the data, it is possible to provide a data transfer method that avoids a decrease in transfer efficiency due to the transmission of the command.
[0259]
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.
[0260]
Further, it is possible to provide a data transfer method capable of performing synchronous transfer and asynchronous transfer in the same transfer procedure when performing data transfer between a host device and a target device.
[0261]
Also, it is possible to provide a data transfer method capable of re-transferring a data unit when a transfer error occurs in a certain data unit in synchronous transfer when performing data transfer between the host device and the target device. it can.
[0262]
Further, it is possible to provide a data transfer method capable of performing correct data transfer even when a bus reset occurs when performing data transfer between a host device and a target device.
[0263]
Further, a peripheral device such as a printer using the above-described data transfer method can be provided.
[0264]
[Modification]
In the above-described embodiment, an example has been described in which a method based on the FCP is used and a response to the command is used, and a method of setting information in the response and notifying the host device is used. A method of mapping a register on a memory is also conceivable.
[0265]
In this case, the command is executed by writing command data to a command register assigned to a specific address of the memory. Similarly, a response is indicated by reading data in a response register assigned to a specific address in the memory.
[0266]
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 and information to the response register. The host device can obtain a command execution result and information by reading the response register of the target device after writing the command in the command register.
[0267]
As described above, the present invention can be realized by using a register in the memory bus model.
[0268]
Also, in the above-described embodiment, an example in which a network is configured using a serial interface defined by IEEE 1934 has been described. However, the present invention is not limited to this, and a serial called Universal Serial Bus (USB) is used. The present invention can also be applied to a network configured using an arbitrary serial interface such as an interface.
[0269]
[Other embodiments]
The present invention can be applied to a system including a plurality of devices (for example, a host computer, an interface device, a reader, a printer, etc.), but it can be applied to a device including one device (for example, a copier, a facsimile device, etc.) May be applied.
[0270]
Further, an object of the present invention is to provide a storage medium storing a program code of software for realizing the functions of the above-described embodiments to a system or an apparatus, and a computer (or CPU or MPU) of the system or apparatus to store the storage medium. It is needless to say that the present invention can also be achieved by reading and executing the program code stored in the program. 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 nonvolatile memory card, a ROM, and the like can be used.
[0271]
When the computer executes the readout program code, not only the functions of the above-described embodiments are realized, but also an OS (Operating System) running on the computer based on the instruction of the program code. It goes without saying that a case where some or all of the actual processing is performed and the functions of the above-described embodiments are realized by the processing is also included.
[0272]
Further, after the program code read from the storage medium is written into a memory provided in a function expansion card inserted into the computer or a function expansion unit connected to the computer, the function expansion is performed based on the instruction of the program code. It goes without saying that the CPU or the like provided in the card or the function expansion unit performs part or all of the actual processing, and the processing realizes the functions of the above-described embodiments.
[0273]
【The invention's effect】
As described above, according to the present invention, a host device and a target device are directly connected via a 1394 serial bus or the like, and data suitable for causing the target device to process image data sent directly from the host device to the target device. A transfer device, a data transfer system and method, an image processing device, and a recording medium can be provided.
[0274]
Further, it is possible to provide a data transfer device, a data transfer system and a method thereof, an image processing device, and a recording medium which can separate a control command and data and have high transfer efficiency.
[0275]
Further, it is possible to provide a data transfer device, a data transfer system and a method thereof, an image processing device, and a recording medium for setting a data transfer method suitable for a device to be connected.
[0276]
Further, it is possible to provide a data transfer device, a data transfer system and its method, an image processing device, and a recording medium that perform data transfer by a PULL method.
[Brief description of the 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 a configuration example of a network 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 is a view showing a cross section of a cable for a 1394 serial bus.
FIG. 6 is a diagram for explaining a DS-Link system of a data transfer system adopted in a 1394 serial bus;
FIG. 7 is a flowchart showing a series of sequence examples from generation of a bus reset signal to determination of a node ID and data transfer;
FIG. 8 is a flowchart illustrating a detailed example from monitoring of a bus reset signal to determination of 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 a network operation of a 1394 serial bus.
FIG. 11 is a diagram showing a function of a CSR architecture of a 1394 serial bus;
FIG. 12 is a diagram showing registers related to a 1394 serial bus;
FIG. 13 is a diagram showing registers relating to node resources of the 1394 serial bus;
FIG. 14 is a diagram showing a minimum format of a configuration ROM of a 1394 serial bus;
FIG. 15 is a diagram showing a general format of a configuration ROM of a 1394 serial bus;
FIG. 16 is a diagram illustrating a request for a bus use right;
FIG. 17 is a diagram illustrating permission to use a bus.
FIG. 18 is a flowchart showing the flow of arbitration in the 1394 serial bus;
FIG. 19 is a diagram showing a request / response protocol of each command of read, write, and lock based on a CSR architecture in a transaction layer,
FIG. 20 is a diagram showing a service in a link layer;
FIG. 21 is a diagram showing temporal transition in asynchronous transfer;
FIG. 22 is a diagram showing 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 temporal transition in synchronous transfer;
FIG. 26 is a diagram showing an example of a packet format for synchronous transfer;
FIG. 27 is a diagram showing details of a field of a packet format of a synchronous transfer in the 1394 serial bus;
FIG. 28 is a diagram showing a temporal transition of a transfer state when synchronous transfer and asynchronous transfer coexist;
FIG. 29 is a diagram showing an operation of an AV / C transaction in the 1394 serial bus.
FIG. 30 is a diagram showing a packet format of an asynchronous transfer including an FCP packet frame;
FIG. 31 is a diagram showing a structure of an AV / C command frame.
FIG. 32 is a diagram showing the structure of an AV / C response frame.
FIG. 33 is a diagram in which the interface of the 1394 serial bus is compared with each layer of the OSI model;
FIG. 34 is a view 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 a login operation;
FIG. 37 is a view showing CSR of a 1394 serial bus provided in a printer which is a target device for a LOGIN protocol.
FIG. 38 is a flowchart showing a login process in the host device;
FIG. 39 is a flowchart showing a login process of a printer as a target device.
FIG. 40 is a view for explaining an example in which a device not implementing the LOGIN protocol is considered;
FIG. 41 is a diagram comparing the configuration shown in FIG. 40 with each layer of the OSI model;
FIG. 42 is a diagram showing a register map;
FIG. 43 is a diagram showing a flow of a frame from the image supply device to the 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 the common register group;
FIG. 46 is a diagram showing a detailed example of information held in a register GGLOBAL of a common register group;
FIG. 47 is a view showing a detailed example of information held in a register LOCAL of a common register group;
FIG. 48 is a view showing an example of information held in a register format [1];
FIG. 49 is a view showing an example of information held in a register format [2];
FIG. 50 is a diagram showing a list of commands and responses to the commands;
FIG. 51 shows an example of an image data format supported by DPP.
FIG. 52 is a view 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 is a view showing a register map in a 1394 serial bus address space of registers necessary for the transfer method 1 and the transfer method 2;
FIG. 55 is a view showing an example of a data packet frame;
FIG. 56 is a diagram showing a configuration example of a data header.
FIG. 57 is a view showing data packet frame processing in the printer in block transfer.
FIG. 58 is a diagram showing a FreeBlock command and a response in the 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 a FreeBlock command and a response in the transfer method 1;
FIG. 62 is a diagram showing WriteBlocks of the transfer method 1 and the transfer method 2 in detail;
FIG. 63 is a diagram showing in detail WriteBlocks of the transfer method 1 and the transfer method 2.
FIG. 64 is an exemplary view for explaining WriteBlock error processing when a bus reset occurs;
FIG. 65 is a diagram illustrating a configuration example of a command register, a response register, and a data register of an image supply device and a printer in a PUSH Large Buffer Model;
FIG. 66 is a view showing an example of an operation flow of a PUSH buffer model between the image supply device and the printer;
FIG. 67 is a view showing a configuration example of a data packet in a data frame;
FIG. 68 is a view showing an example of the relationship between a data register and a buffer of a printer.
FIG. 69 is a diagram illustrating a configuration example of a command register, a response register, and a data register of an image supply device and a printer in a PULL Buffer Model;
FIG. 70 is a view showing an example of an operation flow of a PULL buffer model between the image supply device and the printer;
FIG. 71 is a view showing a relationship example between a data register and a buffer of the image supply device;
FIG. 72 is a view showing a command frame and a response frame for flow control;
FIG. 73 is a diagram illustrating an example of the flow of a printing process.

Claims (2)

A data transfer method used between an image supply device and a target device connected by a serial bus,
Fixing the resources of the target device to the image supply device,
After fixing the resources, in the two-way communication between the image supply device and the target device, determine a data transfer method available between the image supply device and the target device,
Based on the request issued by the image supply device, the data transfer method set in the target device, at least, set to either push method or pull method ,
Wherein when the data transfer scheme is set to the pull system to control so that data is read from the image supply device based on a request issued by the target device,
During the transfer of the data, the target device does not accept control from an apparatus other than the image supply device, and releases the fixed resource based on the request of the image supply device after the transfer of the data. Data transfer method. A data transfer device connected to a target device by a serial bus ,
After the resources of the target device are fixed to the data transfer device, communication means for performing bidirectional communication with the target device,
By the two-way communication, determine a data transfer method that can be used with the target device , based on a request issued by the data transfer device, as a data transfer method set in the target device, at least push Setting means for setting either the model or the pull model ,
When the data transfer method is set to the pull method, the communication unit reads data from the data transfer device based on a request issued by the target device, and the data transfer device after the data transfer. A data transfer device that releases the fixation of the resource based on the request .

Images