JP3943722B2 - Data transfer apparatus, data transfer system and method, image processing apparatus, and recording medium - Google Patents

Description

[0001]
BACKGROUND 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, an image supply device and an image processing device are directly connected via a serial interface defined by IEEE1394 or the like. Data transfer apparatus, data transfer system and method, image processing apparatus, and recording medium.
[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.
[0002]
Also, digital devices that are image supply devices such as scanners, digital still cameras, and digital video cameras are connected to the PC. Image data captured by each digital device is temporarily captured on a hard disk on a PC, then processed by application software on the PC, etc., and converted into print data for a printer, via the above interface. And sent to the printer.
[0003]
In the system as described above, driver software for controlling each digital device and printer exists independently on the PC, and the image data output from the digital device is easy to use and display on the PC with these driver software. Stored as easy-to-use data. 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.
[0004]
Today, an image supply device and a printer can be directly connected with a new interface such as an interface defined by IEEE1394 (hereinafter referred to as “1394 serial bus”). When an image supply device and a printer are directly connected by a 1394 serial bus, a method of including print data in an operand of an FCP (Function Control Protocol) can be considered. In addition, in the 1394 serial bus, a method for transferring data by providing a register area for data transfer and writing data in the register area is also conceivable.
[0005]
A method of instructing data transfer using a command instructing start of data transfer and a response to the command is also conceivable.
[Problems to be solved by the invention]
However, the above-described technique has the following problems. As described above, since the image data output from the image supply device is converted to print data by the PC and printed by the printer, even if the image supply device and the printer are directly connected, printing is possible without the PC. Can not do. There is also a printer called a video printer that directly prints image data output from a digital video camera, but it can only be connected between specific models, and a highly versatile video printer that can be directly connected to 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 for printing by making use of a function for directly connecting devices such as a 1394 serial bus.
[0006]
The method described above, in which the image supply device and printer are directly connected via the 1394 serial bus and the print data is included in the operand of the FCP, has the problem that the control command and the print data cannot be separated, and there is always a response to the command. There is also a problem that transfer efficiency is low because it is necessary. Further, the above-described method for providing a register area for data transfer requires a process for determining whether data can be written to the register area every time data is transferred. Therefore, the overhead of this determination process is increased, and there is a problem that the transfer efficiency is lowered.
[0007]
In order to solve this problem, a method of using the same register area without separating data and commands can be considered. This method can reduce the register area used and provide a simpler data transfer method. Further, it is not determined whether or not the register area to which data is written is writable, and after writing the data to the register, only a correct / incorrect response to the write is performed, and if there is a successful response, the next data is transferred Is also possible.
[0008]
Although this method has an advantage of simplifying the data transfer procedure, there arises a problem that a buffer for storing an area where data is written on the data receiving side becomes full. As soon as the data is written to the register and saved in its own buffer, the data receiving side returns a response indicating that data can be received. The data transfer side that has received a response indicating that the data can be received tries to start transfer of the next data immediately. Therefore, if the processing on the data receiving side is slower than the data transferring side, the buffer on the data receiving side is always full.
[0009]
The data receiving side cannot return a reception ready response to the data sending side until the processing proceeds and an empty buffer is created after storing the data of the last empty buffer. In this case, since the same register area is used for the command and the data, the command other than the data transfer cannot be executed if there is no space in the buffer on the data receiving side during the execution of the command for transferring the data.
[0010]
This means that when a printer is considered as the data receiving side, there are cases where a command for obtaining the printer status (paper out, error, etc.) can be executed and cannot be executed during data transfer. That is, when the printer has an empty buffer and a command for obtaining a status can be received, the command can be executed, but when there is no empty buffer, the command cannot be executed or the command is kept waiting until an empty buffer is formed. Therefore, a problem occurs particularly when performing status acquisition that requires real-time performance. There is also a problem that it is impossible to determine whether the status is at a required time.
[0011]
Further, since the response to the transfer is performed in a substantially constant short time after the data is transferred, the amount of data flowing on the data bus is increased, and there is a problem with respect to the effective use of the bus.
[0012]
Also, when data transfer is instructed using the command for instructing the start of data transfer and the response to the command described above, the exchange of the command and response occurs for each unit of data transfer, which also reduces the transfer efficiency. Problem occurs.
[0013]
The present invention is for solving the above-mentioned problems individually or collectively, and connects a host device and a target device by a 1394 serial bus or the like, and transfers commands sent from the host device to the target device. Data transfer device, data transfer system and method, and image processing device capable of arbitrarily executing commands other than data transfer when using the same register area for data and only performing a response to writing data to the register In addition, an object is to provide a recording medium.
[0014]
Another object of the present invention is to provide a data transfer device, a data transfer system and method, an image processing device, and a recording medium that realize efficiency of traffic on a data bus by adjusting a response time for data transfer. To do.
[0015]
[Means for Solving the Problems]
The present invention has the following configuration as one means for achieving the above object.
[0016]
The data transfer method according to the present invention includes: Host device A data transfer method used between the target device and the target device, Should be stored in the buffer of the target device The first data From the host device to the target device transfer A first transfer step to , The first data Indicates the free space of the buffer as a response to Buffer information From the target device to the host device Reply A first reply step to , When the free capacity indicated by the buffer information is not larger than a predetermined capacity, a second transfer step of transferring specific data from the host device to the target device, and without storing the specific data in the buffer, A second reply step of returning buffer information indicating the free capacity of the buffer as a response to the specific data from the target device to the host device; and the specific data is transferred from the host device to the target device. And a third transfer step of transferring second data to be stored in the buffer from the host device to the target device when the free capacity indicated by the buffer information is larger than a predetermined capacity. It is characterized by that.
[0017]
In addition, data according to the present invention A receiving device receiving first data to be stored in the buffer from a host device; and buffer information indicating a free capacity of the buffer as a response to the first data to the host device. A first transmitting means for transmitting; a second receiving means for receiving specific data from the host device if the free capacity indicated by the buffer information is not greater than a predetermined capacity; and the specific data in the buffer. Second transmission means for transmitting buffer information indicating the free capacity of the buffer to the host device as a response to the specific data without storing; and after receiving the specific data from the host device, the buffer The second data to be stored in the buffer when the free capacity indicated by the information is larger than a predetermined capacity And receiving from the host device, the host device transfers the specific data to the data receiving device when the free capacity indicated by the buffer information is not larger than a predetermined capacity. It is characterized by that.
[0018]
In addition, data according to the present invention The transfer apparatus includes: first transfer means for transferring first data to be stored in a buffer of a target device to the target device; and buffer information indicating a free capacity of the buffer as a response to the first data. A first receiving means for receiving from the target device; a second transferring means for transferring specific data to the target device if the free capacity indicated by the buffer information is not greater than a predetermined capacity; and Second response means for receiving buffer information indicating the free capacity of the buffer from the target device as a response; and after the specific data is transferred to the target device, the free capacity indicated by the buffer information is a predetermined capacity. If it is greater, the second data to be stored in the buffer is transferred to the target. A third transfer means for transferring to the network device, wherein the target device stores the buffer information indicating a free capacity of the buffer as a response to the specific data without storing the specific data in the buffer. Send to data transfer device It is characterized by that.
[0019]
[Outline of IEEE 1394]
With the advent of home digital VTRs and digital video discs (DVDs), it is necessary to transfer real-time and large-volume data such as video data and audio data (hereinafter collectively referred to as “AV data”). . In order 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. The interface developed from such a viewpoint is the 1394 serial bus.
[0020]
FIG. 2 shows an example of a network system configured using a 1394 serial bus. This system includes devices A to H, and AB, AC, BD, DE, CF, CG, and CH are connected by a twisted pair cable for a 1394 serial bus. Examples of these devices A to H are host computer devices such as personal computers and computer peripheral devices. Computer peripherals include digital VCRs, DVD players, digital still cameras, storage devices that use media such as hard disks and optical discs, CRT and LCD monitors, tuners, image scanners, film scanners, printers, MODEMs, and terminal adapters (TA) All computer peripherals such as 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, or a thermal recording method.
[0021]
Connection between devices can be a mixture of the daisy chain method and the node branch method, and a connection with a high degree of freedom can be performed. In addition, each device has an ID, and recognizes each other to form one network within the range connected by the 1394 serial bus. For example, by simply daisy-chaining each device with a single 1394 serial bus cable, each device plays the role of relay, so that one network can be configured as a whole.
[0022]
The 1394 serial bus is compatible with the Plug and Play function, and has a function of automatically recognizing a device and recognizing a connection state simply by connecting a 1394 serial bus cable to the device. In addition, in the system shown in Fig. 2, when a device is removed from the network or is newly added, the bus is automatically reset (the network configuration information up to that point is reset) to create a new one. A good network. This function makes it possible to always set and recognize the network configuration at that time.
[0023]
The data transfer rate of the 1394 serial bus is defined as 100/200/400 Mbps, and compatibility is maintained by a device having a higher transfer rate supporting a lower transfer rate. As the data transfer mode, there are an asynchronous transfer mode (ATM) for transferring asynchronous data such as a control signal and a synchronous transfer mode for transferring synchronous data such as real-time AV data. Asynchronous data and synchronous data are mixed in the cycle while giving priority to the transfer of synchronous data following the transfer of the cycle start packet (CSP) indicating the cycle start in each cycle (usually 125μs / cycle). Transferred.
[0024]
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, the connector port 810 is connected to the connector at the end of the cable 813 for the 1394 serial bus. Above the connector port 810, there are a physical layer 811 and a link layer 812 configured by the hardware unit 800. The hardware unit 800 is configured by an interface chip, of which the physical layer 811 performs encoding, connection-related control, and the like, and the link layer 812 performs packet transfer, cycle time control, and the like.
[0025]
The transaction layer 814 of the firmware unit 801 manages data to be transferred (transaction), 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 network configuration. The hardware and firmware up to the above are the substantial configuration of the 1394 serial bus.
[0026]
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 AV / C protocol.
[0027]
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 must have a unique 64-bit address. This address is stored in the memory of the device, and by always recognizing the node address of itself or the other party, data communication specifying the other party can be performed.
[0028]
The addressing of the 1394 serial bus is based on the IEEE1212 standard, and the address setting uses the first 10 bits for specifying the bus number and the next 6 bits for specifying the node ID.
[0029]
The 48-bit address used in each device is also divided into 20 bits and 28 bits, and is used with a structure of 256 Mbyte units. 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 within the device, and the register space stores information common to the devices connected to the bus and is used for communication between the devices.
[0030]
The first 512 bytes of the register space are the CSR architecture core registers (CSR core), the next 512 bytes are serial bus registers, the next 1024 bytes are the configuration ROM, and the rest are units. Each device-specific register is placed in space.
[0031]
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 cores, serial bus registers, configuration ROMs and unit space It is desirable that the first 2048 bytes are combined to make up 4096 bytes.
[0032]
The above is the outline of the 1394 serial bus. Next, features of the 1394 serial bus will be described in more detail.
[0033]
[Details of 1394 serial bus]
[Electrical specifications of 1394 serial bus]
FIG. 5 shows a cross section of a cable for a 1394 serial bus. The 1394 serial bus cable is provided with a power line in addition to two pairs of twisted pair signal lines. As a result, it is possible to supply power to a device that does not have a power source or a device whose voltage has dropped due to a failure or the like. The voltage of the DC power supplied from the power line is specified as 8 to 40V, and the current is specified as the maximum current 1.5A. In the standard called DV cable, it is composed of four wires without the power line.
[DS-Link method]
FIG. 6 is a diagram for explaining a data transfer method DS-Link (Data / Strobe Link) method employed in the 1394 serial bus.
[0034]
The DS-Link method is suitable for high-speed serial data communication and requires two sets of signal lines. That is, the data signal is sent by one set of two pairs of twisted wires, and the strobe signal is sent by another set. The receiving side is characterized in that a clock can be generated by taking an exclusive OR of the data signal and the strobe signal. For this reason, when using the DS-Link method, there is no need to mix the clock signal in the data signal, so the clock signal can be generated with higher transfer efficiency than other serial data transfer methods, so phase locked loop (PLL) The circuit becomes unnecessary, and the circuit scale of the controller LSI can be reduced accordingly. Furthermore, since there is no need to send information indicating that the device is in an idle state when there is no data to be transferred, the transceiver circuit of each device can be put into a sleep state, and power consumption can be reduced. .
[Bus reset sequence]
Each device (node) connected to the 1394 serial bus is given a node ID and recognized as a node constituting the network. For example, when the number of nodes increases or decreases due to connection separation of network devices, power on / off, etc., that is, when there is a change in the network configuration and it is necessary to recognize a new network configuration, each node that detects the change is on the bus Then, a bus reset signal is transmitted to enter a mode for recognizing a new network configuration. This change in the network configuration is detected by detecting a change in bias voltage at the connector port 810.
[0035]
When a bus reset signal is transmitted from a certain node, the physical layer 811 of each node receives the bus reset signal and simultaneously transmits the occurrence of the bus reset to the link layer 812 and transmits the bus reset signal to other nodes. . After all nodes have finally received the bus reset signal, the bus reset sequence is activated. Note that the bus reset sequence is activated when a cable is inserted or removed, or when the hardware detects a network error, etc., and also by giving a direct command to the physical layer 811 such as host control by protocol. It is activated. When the bus reset sequence is activated, the data transfer is temporarily suspended, waited during the bus reset, and resumed based on the new network configuration after the bus reset is completed.
[Node ID determination sequence]
After the bus reset, each node enters an operation of giving an ID to each node in order to construct a new network configuration. A general sequence from bus reset to node ID determination at this time will be described with reference to flowcharts shown in FIGS. FIG. 7 is a flowchart showing a series of sequence examples from the generation of the bus reset signal until the node ID is determined and data transfer can be performed. The nodes constantly monitor the generation of the bus reset signal in step S101, and when the bus reset signal is generated, the nodes move 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 by the determination in step S103 that the parent-child relationship has been determined among all the nodes.
[0036]
When the parent-child relationship is determined, the process proceeds to step S104, where a 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 order of a predetermined node from the root node, and step S105 is repeated until it is determined in step S106 that all nodes have been given IDs.
[0037]
When the node ID setting is completed, the new network configuration has been recognized in all nodes, so that data transfer between the nodes can be performed, data transfer is started in step S107, and the sequence proceeds to step S101. The generation of the bus reset signal is monitored again.
[0038]
FIG. 8 is a flowchart showing a detailed example from the monitoring of the bus reset signal (S101) to the determination of the root node (S104), and FIG. 9 is a flowchart showing a detailed example of the node ID setting (S105, S106).
[0039]
In FIG. 8, the generation of the bus reset signal is monitored in step S201. When the bus reset signal is generated, the network configuration is once reset. Next, in step S202, as a first step of re-recognizing the reset network configuration, each device resets the flag FL with data indicating that it is a leaf node. Then, in step S203, each device checks the number of ports, that is, the number of other nodes connected to itself, and in step S204, depending on the result of step S203, to start declaration of parent-child relationship from now on, 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.
[0040]
Only actual leaf nodes can declare parent-child relationships immediately after a bus reset. Whether or not the node is a leaf node can be known from the confirmation result of the number of ports in step S203, that is, if the number of ports is “1”, the node is a leaf node. In step S205, the leaf node declares the parent-child relationship to the connection partner node “I am a child, the partner is a parent”, and the operation ends.
[0041]
On the other hand, the node whose number of ports is “2 or more” in step S203, that is, the branch node is “undefined port number> 1” immediately after the bus reset, and therefore proceeds to step S206, and the flag FL indicates the branch node. Data is set, and it waits for a parent-child relationship to be declared from another node in step S207. The parent node is declared from another node, and the branch node receiving it returns to step S204 to check the number of undefined ports. If the number of undefined ports is "1", it is connected to the remaining port. In step S205, a parent-child relationship of “I am a child and the other party is a parent” can be declared to other nodes. In addition, the branch node whose number of undefined ports is still “2 or more” waits until the parent-child relationship is declared again from another node in step S207.
[0042]
If the number of undefined ports in any one of the branch nodes (or leaf nodes that did not work quickly despite exceptions being able to declare children) becomes "0", the parent-child relationship declaration for the entire network is The only node for which the number of undefined ports has become “0”, that is, the node determined to be the parent of all nodes, sets the data indicating the root node in the flag FL in step S208, and in step S209 Recognized as root node.
[0043]
In this way, the procedure from the bus reset to the declaration of the parent-child relationship between all nodes in the network is completed.
[0044]
Next, a procedure for giving an ID to each node will be described. It is a leaf node that can first set an ID. Then, IDs are set from a young number (node number: 0) in the order of leaf → branch → root.
[0045]
In step S301 in FIG. 9, the process branches to processing corresponding to the type of node, that is, leaf, branch, and route, based on the data set in the flag FL.
[0046]
First, in the case of leaf nodes, the number of leaf nodes (natural number) existing in the network is set to the variable N in step S302, and then 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, gives a node number to one node in step S305, and notifies the other nodes of the result indicating failure in obtaining the node number.
[0047]
The leaf node that could not obtain the node number according to the determination in step S306 repeats the node number request again in step S303. On the other hand, the leaf node that has acquired the node number notifies all the nodes by broadcasting ID information including the acquired node number in step S307. When the broadcast of the ID information ends, the variable N representing the number of leaves is decremented in step S308. Then, the procedure from step S303 to S308 is repeated until the variable N becomes “0” by the determination in step S309, and after the ID information of all the leaf nodes is broadcasted, the process proceeds to step S310 to set the branch node ID Move on.
[0048]
Branch node ID setting is performed in substantially the same manner as leaf nodes. First, in step S310, the number of branch nodes (natural number) existing in the network is set to 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 and assigns a young number following the leaf node to one branch node in step S313, and results in acquisition failure for the branch node that could not acquire the node number To be notified.
[0049]
As a result of the determination in step S314, the branch node that knows that acquisition of the node number has failed repeats the request for the node number again in step S311. On the other hand, in step S315, the branch node that has acquired the node number broadcasts ID information including the acquired node number to notify all nodes. When the broadcast of the ID information ends, the variable M representing the number of branches is decremented in step S316. Then, as a result of the determination in step S317, the procedure from steps S311 to S316 is repeated until the variable M becomes “0”, and the ID information of all the branch nodes is broadcast. Move on to setting.
[0050]
At this point, the only node that has not obtained an ID is the root node. Therefore, in step S318, the youngest number not given to other nodes is set as its own node number. Broadcast ID information.
[0051]
This is the end of the procedure until all the node IDs are set. Next, a specific procedure of the node ID determination sequence will be described using the network example shown in FIG.
[0052]
In the network shown in FIG. 10, node A and node C are directly connected below node B, which is the root, node D is directly connected below node C, and node E and node F are directly connected below node D. Has a hierarchical structure. The procedure for determining the hierarchical structure, root node, and node ID is as follows.
[0053]
After the bus reset occurs, in order to recognize the connection status of each node, a parent-child relationship is declared between the ports directly connected to each node. The parent and child here means that the upper level of the hierarchical structure is “parent” and the lower level is “child”. In FIG. 10, after the bus reset, the node A first declared the parent-child relationship. As described above, the declaration of the parent-child relationship can be started from a node (leaf) to which only one port is connected. If the number of ports is “1”, it is recognized that the end of the network tree, that is, the leaf node, and the parent-child relationship is determined from the node that performed the earliest operation among those leaf nodes. Become. Thus, the port of the node that declared the parent-child relationship is set as a “child” of the two nodes connected to each other, and the node of the counterpart 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.
[0054]
Further, the hierarchy is advanced by one, and the parent-child relationship is declared to the higher-order node sequentially from the node having a plurality of ports, that is, the node that has received the parent-child relationship declaration from the other nodes among the branch nodes. In FIG. 10, after the parent-child relationship between the node DE and the DF is first determined, the node D declares the parent-child relationship to the node C. As a result, the “child-parent” relationship is set between the node DCs. The Node C, which has received a parent-child relationship declaration from node D, declares a parent-child relationship to node B connected to another port, and this establishes a “child-parent” relationship between nodes CB. The
[0055]
In this way, the hierarchical structure as shown in FIG. 10 is configured, and the node B that becomes the parent in all the finally connected ports is determined as the root node. Note that there is only one root node in one network configuration. In addition, if node B, which has been declared a parent-child relationship from node A, promptly declares a parent-child relationship to other nodes, another node such as node C may become the root node. . That is, depending on the timing at which the declaration of the parent-child relationship is transmitted, any node may be the root node, and even if the network configuration is the same, a specific node is not necessarily the root node.
[0056]
When the root node is determined, a determination mode for each node ID is entered. All nodes have a broadcast function for notifying all other nodes of their determined ID information. The ID information is broadcast as ID information including a node number, information on a connected position, the number of ports that are present, the number of ports that are connected, and parent-child relationship information of each port.
[0057]
As described above, node numbers are assigned from leaf nodes, and node numbers = 0, 1, 2,... Are assigned in order. Then, by broadcasting the ID information, it is recognized that the node number has already been assigned.
[0058]
When all the leaf nodes have obtained the node number, the next step is to move to the branch node and the node number following the leaf node is assigned. Similar to the leaf node, 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 has the largest node number.
[0059]
As described above, ID setting for the entire hierarchical structure is completed, a network configuration is constructed, and bus initialization is completed.
[Control information for node management]
As a basic function of the CSR architecture for node management, the CSR core shown in FIG. 4 exists on a register. The positions and functions of these registers are shown in FIG. 11. The offset in the figure is a relative position from 0xFFFFF0000000.
[0060]
In the CSR architecture, registers related to the serial bus are arranged from 0xFFFFF0000200. The location and function of these registers are shown in FIG.
[0061]
In addition, information regarding serial bus node resources is arranged at a location starting from 0xFFFFF0000800. FIG. 13 shows the positions and functions of these registers.
[0062]
The CSR architecture has a configuration ROM to represent the function of each node. This ROM has a minimum format and a general format, and is allocated from 0xFFFFF0000400. The minimum format only represents a vendor ID as shown in FIG. 14, and this vendor ID is a unique value all over the world represented by 24 bits.
[0063]
Further, the general format is as shown in FIG. 15 and has information about the node. In this case, the vendor ID can be stored in the root directory (root_directory). The bus information block and the root leaf have a 64-bit global device number including the vendor ID. This device number is used for recognizing the node continuously after reconfiguration such as bus reset.
[Serial bus management]
As shown in FIG. 3, the 1394 serial bus protocol includes a physical layer 811, a link layer 812, and a transaction layer 814. Among them, bus management provides basic functions for node control and bus resource management based on the CSR architecture.
[0064]
A node that performs bus management (hereinafter referred to as a “bus management node”) exists only on the same bus and provides a management function to other nodes on the serial bus. , Performance optimization, power management, transmission speed management, configuration management, etc.
[0065]
The bus management function is roughly divided into three functions: a bus manager, a synchronous (isochronous) resource manager, and a node control. The node control is a management function that enables inter-node communication in the physical layer 811, the link layer 812, the transaction layer 814, and the application by CSR. The synchronous resource manager is a management function necessary for performing synchronous data transfer on the serial bus, and manages the allocation of the synchronous data transfer bandwidth and channel number. In order to perform this management, the bus management node is dynamically selected from the nodes having the synchronous resource manager function after initialization of the bus.
[0066]
In a configuration in which no bus management node exists on the bus, a node having a synchronous resource manager function performs a part of bus management functions such as power management and cycle master control. In addition, the bus management is a management function that provides a service that provides a bus control interface to the application. The control interface includes a serial bus control request (SB_control.request), a serial bus event control confirmation (SB _Control.confirmation) and serial bus event notification (SB_EVENT.indication).
[0067]
The serial bus control request is used when an application requests a 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.
[Data transfer protocol]
In the data transfer of the 1394 serial bus, synchronous data (synchronous packet) that needs to be transmitted periodically and asynchronous data (asynchronous packet) that allows data transmission / reception at any timing exist at the same time. Real-time performance is guaranteed. In data transfer, bus arbitration is performed to request a bus use right prior to transfer and to obtain permission to use the bus.
[0068]
In asynchronous transfer, a transmission node ID and a reception node ID are sent as packet data together with 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.
[0069]
In synchronous transfer, a transmission 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 number of required channels and the transmission rate are determined by the application layer 816.
[0070]
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 physical / electrical interface with the bus, automatic recognition of node connection, bus arbitration of bus usage rights between nodes, and the like. The link layer 812 performs cycle control for addressing, data check, packet transmission / reception, and synchronous transfer. The transaction layer 814 performs processing related to asynchronous data. Hereinafter, processing in each layer will be described.
[Physical layer]
Next, bus arbitration in the physical layer 811 will be described.
[0071]
Prior to data transfer, the 1394 serial bus always performs arbitration of the right to use the bus. Each device connected to the 1394 serial bus configures a logical bus network that relays the signal transferred over the network to all devices in the network, so packet collisions Bus arbitration is necessary to prevent this. This allows only one node to perform the transfer at a certain time.
[0072]
FIG. 16 is a diagram for explaining a request for a bus use right, and FIG. 17 is a diagram for explaining permission for use of the bus. When bus arbitration starts, one or more nodes request the right to use the bus toward the parent node. In FIG. 16, node C and node F request the right to use the bus. Upon receiving this request, the parent node (node A in FIG. 16) further requests the right to use the bus toward the parent node, thereby relaying the request for the right to use the bus by node F. This request is finally delivered to the root node that performs arbitration.
[0073]
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 a bus use permission is given to a node that has won the arbitration. FIG. 17 shows a state where the bus use permission is given to the node C and the request for the right to use the bus of the node F is denied.
[0074]
The root node sends a DP (data prefix) packet to the node losing the bus arbitration to inform 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 lost the bus arbitration is kept waiting until the next bus arbitration.
[0075]
As described above, a node that has won arbitration and has obtained permission to use the bus can subsequently start data transfer. Here, a series of bus arbitration flows will be described with reference to the flowchart shown in FIG.
[0076]
In order for a node to begin data transfer, the bus must be idle. In order to confirm that the previously started data transfer is completed and the bus is currently in an idle state, a predetermined idle time gap length (for example, subaction gap) set individually in each transfer mode When 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 data to be transferred such as asynchronous data or synchronous data has been detected. As long as a predetermined gap length is not detected, the right to use the bus necessary to start the transfer cannot be requested.
[0077]
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 there is, sends a signal requesting the right to use the bus to the route in step S403. To do. As shown in FIG. 16, the signal representing 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. If it is determined in step S402 that there is no data to be transferred, the process returns to step S401.
[0078]
When the root node receives one or more signals requesting the right to use the bus in step S404, the root node checks the number of nodes that have requested the right to use in step S405. If it is determined in step S405 that one node has requested the right to use, the right to use the bus immediately after that is given to that node. If there are a plurality of nodes that have requested usage rights, an arbitration operation is performed in step S406 to narrow down the nodes to which the right to use the bus immediately after is requested. This arbitration work does not give permission to use the bus only to the same node every time, but grants permission to use the bus equally (fair arbitration).
[0079]
The processing of the root node branches in step S407 according to one node that has won the arbitration in step S406 and the other nodes that have lost. If there is one node that has won the arbitration or one node that has requested the right to use the bus, a permission number indicating permission to use the bus is sent to that node in step S408. The node that has received this permission signal starts transferring data (packets) to be transferred immediately after (step S410). Further, in step S409, a DP (data prefix) packet indicating that the bus use right request has been rejected is sent to the node that has lost arbitration. The processing of the node that has received the DP packet returns to step S401 to request the right to use the bus again. The processing of the node that has completed the data transfer in step S410 also returns to step S401.
[Transaction layer]
There are three types of transactions: read transactions, write transactions, and lock transactions.
[0080]
In a read transaction, the initiator (request node) reads data from a specific address in the target (response node) memory. In a write transaction, the initiator writes data to a specific address in the target memory. In the lock transaction, reference data and update data are transferred from the initiator to the target. The reference data is combined with the data of the target address to become a designated address indicating a specific address of the target. Then, the data at the designated address is updated with the update data.
[0081]
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. .
[0082]
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 arrived at the response node, a transaction response (TR_DATA.response) is an acknowledge transmission, and a transaction confirmation (TR_DATA. .confirmation) is an acknowledgment reception.
[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 from the response node. It is divided into service units of link response (LK_DATA. Response) of acknowledge transmission and link confirmation (LK_DATA.confirmation) of acknowledge transmission of request node. One packet transfer process is called a subaction, and there are two types, an asynchronous subaction and a synchronous subaction. Below, operation | movement of each subaction is demonstrated.
Asynchronous subaction
Asynchronous subactions are asynchronous data transfers. FIG. 21 is a diagram showing temporal transition in asynchronous transfer. The first subaction gap shown in FIG. 21 indicates the idle state of the bus. When this idle time reaches a predetermined value, a node desiring data transfer requests the right to use the bus, and bus arbitration is executed.
[0083]
If the use of the bus is permitted by the bus arbitration, then the data is packet-transferred, and the node receiving this data responds with a return code ACK for confirmation of reception after a short gap called ACK gap, or Data transfer is completed by returning a response packet. The ACK is composed of 4-bit information and a 4-bit checksum, includes information indicating success, busy state, or pending state, and is immediately returned to the data transmission source node.
[0084]
FIG. 22 is a diagram showing the format of an asynchronous transfer packet. In addition to the data part and the error correction data CRC, the packet has a header part, in which the target node ID, source node ID, transfer data length, various codes, and the like are written.
[0085]
Asynchronous transfer is a one-to-one communication from a transmission node to a reception node. The packet sent out from the transmission source node is distributed to each node in the network, but each node ignores packets other than the packet addressed to itself, so that only the node designated as the destination receives the packet.
[Split transaction]
The service in the transaction layer 814 is performed by the set of transaction request and 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 target processing speed is slow, it is necessary to process the request and response in separate transactions. This operation is called a split transaction.
[0086]
FIG. 23 is a diagram illustrating an example of split transaction operation. The target returns pending in response to a write request from the initiator (request node) controller. Thereby, the target can return the confirmation information with respect to the write request of the controller, and can earn time for processing the data. Then, after a sufficient time for data processing has elapsed, the target notifies the controller of a write response and ends the write transaction. Note that the link layer 812 can be operated by another node between the request and response subactions at this time.
[0087]
FIG. 24 is a diagram showing an example of temporal transition of the transfer state when performing a split transaction. Subaction 1 represents a request subaction, and subaction 2 represents a response subaction.
[0088]
In subaction 1, the initiator sends a data packet representing a write request to the target, and the target that has received the request returns pending indicating the confirmation information by an acknowledge packet, thereby completing the request subaction.
[0089]
After the subaction gap is inserted, in subaction 2, the target sends a write response in which the data packet is no data, and the initiator that receives this completes the response subaction by returning a complete response with an acknowledge packet. To do.
[0090]
The time from the end of subaction 1 to the start of subaction 2 is the minimum corresponding to the subaction gap, and the maximum can be extended to the maximum waiting time set in the node.
Synchronous subaction
This synchronous transfer, which can be said to be the greatest feature of the 1394 serial bus, is particularly suitable for transferring data that requires real-time transfer such as AV data. Asynchronous transfer is a one-to-one transfer, but this asynchronous transfer can uniformly transfer data from one source node to all other nodes by a broadcast function.
[0091]
FIG. 25 is a diagram showing 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. The cycle start packet (CSP) 2000 plays a role of indicating the start of the synchronization cycle and synchronizing the operation of each node. The CSP2000 is sent by a node called the cycle master. After the transfer in the previous cycle is completed and a predetermined idle period (subaction gap 2001) is passed, the CSP2000 is sent to announce the start of this cycle. To do. That is, the time interval for transmitting this CSP2000 is 125 μS.
[0092]
Also, as indicated by channel A, channel B, and channel C in FIG. 25, by assigning channel IDs to a plurality of types of packets within one synchronization cycle, these packets can be transferred separately. Thereby, real-time transfer is possible between a plurality of nodes substantially simultaneously, and the receiving node only needs to receive data of a desired channel ID. This channel ID does not represent the address of the receiving node or the like, but is merely a logical number for data. Accordingly, a transmitted packet is transmitted from one source node to all other nodes, that is, broadcast.
[0093]
Prior to packet transmission by synchronous transfer, bus arbitration is performed as in asynchronous transfer. However, since asynchronous transfer is not one-to-one communication, there is no ACK of a return code for confirmation of reception in synchronous transfer.
[0094]
An iso gap (synchronization gap) shown in FIG. 25 represents an idle period necessary for confirming that the bus is in an idle state before performing synchronous transfer. The node that has detected this predetermined idle period determines that the bus is in an idle state, and if it wants to perform synchronous transfer, it requests the right to use the bus, so that bus arbitration is performed.
[0095]
FIG. 26 is a diagram showing an example of a packet format for synchronous transfer. Each packet divided into each channel has a header part in addition to the data part and error correction data CRC. The header part has a transfer data length, channel number, etc. as shown in FIG. Various codes and error correction header CRC are written.
[Bus cycle]
Actually, synchronous transfer and asynchronous transfer can be mixed in the 1394 serial bus. FIG. 28 is a diagram showing temporal transition of the transfer state when synchronous transfer and asynchronous transfer are mixed.
[0096]
Here, as described above, synchronous transfer is executed with priority over 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 for starting asynchronous transfer. Therefore, synchronous transfer is executed with priority over asynchronous transfer.
[0097]
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 performs synchronous transfer after waiting for a predetermined idle period (synchronization gap) participates in bus arbitration and enters packet transfer. In FIG. 28, channel e, channel s, and channel k are sequentially transferred in synchronization.
[0098]
After the operations from the bus arbitration to the packet transfer are repeated for the given channel, the asynchronous transfer can be performed when all the synchronous transfers in cycle #m are completed. That is, when the idle time reaches a subaction gap that allows asynchronous transfer, a node that wants to perform asynchronous transfer participates in bus arbitration. However, asynchronous transfer can be performed only when a sub-action gap for starting asynchronous transfer is detected between the end of synchronous transfer and the time to transfer the next CSP (cycle synch). .
[0099]
In cycle #m shown in FIG. 28, two packets (packet 1 and packet 2) including ACK are transferred by asynchronous transfer after synchronous transfer of three channels. After this asynchronous packet 2, the time to start cycle m + 1 is reached (cycle synch), so the transfer in cycle #m ends here. However, if the time to send the next CSP during the asynchronous or synchronous transfer (cycle synch) is reached, the transfer is not interrupted forcibly, and after the transfer is completed, the CSP of the next synchronous cycle is sent through the idle period. To do. That is, when one synchronization cycle continues for 125 μs or more, the next synchronization cycle is shortened from the reference 125 μs by the extension. Thus, the synchronization cycle can be exceeded and shortened on the basis of 125 μs.
[0100]
However, the synchronous transfer is executed every cycle if necessary in order to maintain the real-time transfer, and the asynchronous transfer may be postponed to the next and subsequent synchronous cycles due to the reduction of the synchronous cycle time. The cycle master also manages such delay information.
[0101]
[Data transfer processing]
[Data transfer protocol]
FIG. 29 is a diagram for explaining a protocol stack for data transfer on the 1394 serial bus.
[0102]
Applications often need to exchange large amounts of data such as image data between devices. In such a case, the application provides a reliable data transfer service to separate the details of hardware technology related to data transfer, restrictions, data error retransfer processing, etc. from the application program. Specific interface needs to be defined.
[0103]
Therefore, in this embodiment, when the application program performs data transfer, a hierarchical protocol system as shown in FIG. 29 is used. FIG. 29 shows, in order from the top, an application layer 29-1, a session layer 29-2, a transaction layer 29-3, a 1394 transaction layer 29-4 and a 1394 physical layer 29-5 defined by IEEE1394. Here, the 1394 transaction layer 29-4 corresponds to the transaction layer 814 shown in FIG. 3 described above, and the 1394 physical layer 29-5 corresponds to the link layer 812 and the physical layer 811.
[0104]
In the present embodiment, the device that transmits data operates as follows. First, the data transfer application 29-1 passes a large amount of data such as image data to the lower session layer 29-2 using an abstract interface such as a data transfer API. The session layer 29-2 divides the application data into units of the block register 30-3 defined in FIG. 30, and sequentially passes them to the lower transaction layer 29-3. The transaction layer 29-3 divides the application data of the block register 30-3 into units suitable for the write transaction of the lower 1394 transaction layer 29-4, and calls the write transaction service interface of the 1394 transaction 29-4. The 1394 transaction layer 29-4 and the 1394 physical layer 29-5 transfer the divided application data to other devices by means defined by IEEE1394.
[0105]
The device that receives data operates as follows. Properly divided data transferred from the transmission side is transferred to the block register 30-3 of the data receiving device defined in the transaction layer 29-3 by the 1394 physical layer 29-5 and the 1394 transaction layer 29-4. Written sequentially. The transaction layer 29-3 reconstructs the data sequentially written in the block register 30-3, assembles it into one block register unit data, and passes it to the upper session layer 29-2. The session layer 29-2 sequentially receives the data in one block register unit, reconfigures it into a data stream, and passes it to the application 29-1. The data reception side application 29-1 receives a large amount of data such as image data from the data transmission side device via the abstracted interface.
[Register configuration]
FIG. 30 is a diagram showing a register configuration for the transaction layer 29-3 of FIG. 29 to transfer data between devices, and is arranged in the initial unit space (indicated by the unit space of FIG. 4) of the 1394 serial bus. Is done. Prior to data transfer, the device knows in advance the address and size at which the transfer partner register is located, and uses these registers to transfer data. The register is a block register 30-3 for writing actual data, a control register 30-1 for writing control (writing completion notification) to the block register 30-3, and a writing completion notification to the control register 30-1. On the other hand, it comprises a response register 30-2 for returning the correctness (ACK / NACK) of the written data. The control register 30-1 and the response register 30-2 are collectively referred to as a block management register. These registers are prepared in both the image supply device that transfers the image data and the printer that receives the image data and prints them, and can transfer data to each other.
[0106]
FIG. 31 shows an overview of command transfer using the register shown in FIG. This is an example of command transfer from the image supply device to the printer, and the image supply device writes command data to be sent to the printer to the block register 31-6 on the printer side (command 31-9). Next, the image supply device writes to the control register 31-4 on the printer side to notify the end of command data transfer (control 31-7). The printer writes contents corresponding to ACK or NACK in the response register of the image supply device in order to return to the image supply device whether or not the data has been normally received (response 31-8).
[0107]
With the above procedure, the command is written from the image supply device to the printer register, and a response to the write is performed. If the ACK response from the printer is written to the response register of the image supply device, it indicates that the command has been successfully received by the printer.If NACK is returned, the data has been sent to the printer correctly for some reason. Indicates no. When the response is NACK, the image supply device needs to perform some error processing such as termination processing for errors and command re-transfer processing.
[0108]
FIG. 32 shows a procedure for returning a response to the command written in the register in FIG. 31 from the printer to the image supply device. The printer writes a reply (response) to be sent to the image supply device in the block register 32-3 on the image supply device side (reply 32-9). Next, the printer performs writing to notify the end of the reply transfer to the control register 32-1 on the image supply device side (control 32-7). The image supply device writes contents corresponding to ACK or NACK in the response register 32-5 of the image supply device in order to return to the printer whether or not the data has been normally received (response 32-8).
[0109]
With the above procedure, the reply is written from the printer to the register of the image supply device and a reply to the write is performed. If an ACK response is written to the printer's response register from the image supply device, it indicates that the reply has been successfully received by the image supply device, and if NACK is returned, the data is correct for some reason. Indicates that it has not been sent to. If the response is NACK, the printer needs to perform some error processing such as termination processing for errors and command re-transfer processing.
[0110]
The command transfer from the image supply device to the printer and the reply transfer procedure therefor have been described above with reference to FIGS. These are general command and reply procedures. Note that some commands do not require a reply, and in this case, the procedure shown in FIG. 32 is not executed. These can be determined for each command.
[0111]
FIG. 33 is a diagram showing the relationship between the block register 33-1 and the buffer that the device has internally. A plurality of buffers Blockbuffer [1] to [n] (33-2 to 33-7) having the same size as the block register 33-1 are prepared in the apparatus, and writing to the block register 33-1 is performed. And stored in Blockbuffer [1]-[n]. In writing to the block register 33-1, when there is a free space in the internal buffer, after the written data is stored in the buffer, if there is a free buffer that can be stored next, ACK is returned to the image supply device. When the buffer runs out of space, the ACK is not returned to the image supply device until an empty buffer is created after the last buffer is saved.
[0112]
In the image supply device, the next command cannot be transferred until an ACK is returned after the buffer is empty on the printer side. In the printer, when the data to be printed is empty, for example, the data in Blockbuffer [1] is converted to data for printing, and the buffer becomes empty when all the data in the buffer is processed. The data written to the block register 33-1 can be saved again.
[0113]
FIG. 34 shows the configuration of the control register 30-1 shown in FIG. 30 at the top, and the control contents are set in the control command 34-1. For example, if the control command 34-1 is 01h, it represents BLOCK COMPLETE, that is, indicates completion of writing to the block register.
[0114]
The lower part of FIG. 34 shows the configuration of the response register 30-2 shown in FIG. 30, and the response content is set in the response command 34-2. For example, if the response command 34-2 is 01h, it indicates BLOCK ACK, that is, indicates that the data has been received correctly after writing BLOCK COMPLETE to the control register 30-1, and if it is 02h, it indicates BLOCK NACK. That is, after BLOCK COMPLETE is written to the control register 30-1, it indicates that the data has not been received correctly.
[0115]
By using these control commands and response commands, it is possible to notify the completion of data writing to the block register and to respond thereto.
[0116]
FIG. 35 is a diagram showing a general format of a command written to the block register 30-3. The command includes a command ID 35-1 that is the identifier and Parameter 35-2 that accompanies the command.
[0117]
FIG. 36 is a diagram illustrating an example of an actual command. In the figure, the left side is a command (SEND command) for transferring image data, CommandID is SEND (36-1), and Parameter is Image Data (36-2) which is image data to be transferred. With this command, image data for printing from the image supply device to the printer can be transferred.
[0118]
Also, the right side of FIG. 36 is a command (GETSTATUS command) for the image supply device to receive the status indicating the printer status from the printer, the CommandID is GETSTATUS (36-3), and there is no Parameter. That is, the GETSTATUS command does not require a parameter.
[0119]
These commands are transferred from the image supply device to the printer as command 31-9 in FIG. However, in the case of the above SEND command, the image data is usually larger than the size of the block register 30-3. In this case, writing with a size suitable for the block register 30-3 is performed a plurality of times. become.
[0120]
FIG. 37 is a diagram showing a reply to the command shown in FIG. In the figure, the left side is a reply to a SEND command (SEND reply). This reply returns the command execution status from the printer to the image supply device in response to the SEND command, and includes a SEND reply 37-1 and a SEND reply status 37-2 indicating the command execution status.
[0121]
Also, the right side of FIG. 37 is a reply to the GETSTATUS command. This reply returns the printer status from the printer to the image supply device in response to the GETSTATUS command.
[0122]
These replies are transferred from the printer to the image supply device as replies 32-9 in FIG.
[0123]
The command and reply shown in FIGS. 36 and 37 enable the application of the image supply device shown in FIG. 29 to make a print request by transferring image data to the printer application and to obtain the printer status. Become.
[0124]
FIG. 38 is a diagram showing details of the printer status 38-1 returned by the GETSTATUS reply in FIG. 37. For example, the printer status 38-1 can have statuses such as no paper, error, and busy. The image supply device can know the current state of the printer from this status. For example, the image supply device can know that the printer is out of paper, and in this case, the user of the image supply device can be notified of this. Further, when an error occurs in the printer, it is possible to control not to perform printing.
[0125]
FIG. 39 shows a case where the size of the image data 39-1 is larger than the block register 31-3 when the image data 39-1 is sent by the SEND command. In this case, since it cannot be transferred at a time, the image data 39-1 is divided in accordance with the size of the block register 30-3 and transferred as a plurality of commands 39-2 to 39-5 as shown in FIG. This process is performed in the session layer 29-2 shown in FIG. Hereinafter, one divided command transfer is referred to as WriteBlock. Therefore, when transferring a large amount of image data, WriteBlock is executed a plurality of times. The image data transferred from the image supply device to the printer block register 31-6 is stored in an internal buffer on the printer side as shown in FIG.
[0126]
The image data controlled by the session layer 29-2 and WriteBlocked is further decomposed into data transfer units (1934 transactions 39-6 to 39-9) compliant with the IEEE1394 standard in the transaction layer 29-3. That is, the image data is written to all areas of the block register 31-3 by performing data transfer in units of 1394 transactions 39-6 on the 1394 serial bus a plurality of times.
[General data transfer control]
FIG. 40 is a diagram illustrating a general control procedure of the image supply device and the printer when the write block is repeatedly performed. The image supply device performs WriteBlock to the printer in divided command units. Specifically, the SEND command is repeatedly transferred.
[0127]
First, in step S40-1, the image supply device performs WriteBlock for writing the first command to the block register 31-6 of the printer. When the data writing for the block register 31-3 is completed, BLOCK COMPLETE for notifying the completion of WriteBlock is written in the control register 31-4 of the printer in step S40-2.
[0128]
On the other hand, since the printer has an empty buffer and the command written in the block register is normal, BLOCK ACK is written in the response register 31-2 to the image supply device in step S40-3. In this case, the response time from the occurrence of BLOCK COMPLETE to the return of BLOCK ACK is indicated by T1. By such a series of processes from WriteBlock to BLOCK ACK (steps S40-1 to S40-3), transfer in units of one block is completed. Thereafter, as shown in steps S40-4 to S40-6, WriteBlock is repeated until there is no more empty buffer in the printer.
[0129]
The printer consumes the data sent in accordance with the printing operation to empty the buffer, and reuses the buffer. However, when the data transfer from the image supply device is faster than the buffer consumption speed of the printer, there is no empty buffer, and WriteBlock is performed on the final buffer of the printer shown in step S40-7. This is because the image supply device does not have information such as the remaining number for the printer buffer, and therefore immediately after the BLOCK ACK is returned, WriteBlock is executed. FIG. 40 shows a case where the printer side has n buffers.
[0130]
In step S40-7, WriteBlock is performed on the final buffer, and when BLOCK COMPLETE is transferred in step S40-8, the printer buffer is full by this transfer. BLOCK ACK cannot be transferred to the image supply device. For this reason, the response time from BLOCK COMPLETE to BLOCK ACK is normally T1, but the image supply device cannot transfer data for T2 time until the buffer becomes empty. After T2 elapses and BLOCK ACK is returned from the printer, the image supply device can transfer the next data. That is, the response time is T2 that is much longer than T1.
[0131]
FIG. 41 is a diagram showing the control procedure of the GETSTATUS command in this embodiment, and shows the flow of processing when the GETSTATUS command is executed while image data is being transferred by the SEND command.
[0132]
The GETSTATUS command is executed periodically when it is necessary to take the status of the printer while performing WriteBlock repeatedly. That is, the GETSTAUS command is executed in the middle of the SEND command. First, a SEND command is executed from step S41-1 to 41-6, and when a predetermined time is reached, a GETSTATUS command is executed in step S41-7.
[0133]
Hereinafter, the GETSTATUS command control will be described in detail. First, in step S41-8, the GETSTATUS command is written to the block register of the printer by WriteBlock. Next, in step S41-9, BLOCK COMPLETE is written in the control register of the printer. On the other hand, BLOCK ACK is returned from the printer to the response register of the image supply device in step S41-10, and GETSTATUS reply is written from the printer side to the block register of the image supply device in step S41-11. In step S41-12, BLOCK COMPLETE is written from the printer to the control register of the image supply device, and in step S41-13, the corresponding BLOCK ACK is returned to the printer response register.
[0134]
The GETSTATUS command is interrupted and executed during the SEND command by the series of processing shown in step S41-7. After execution of the GETSTATUS command, the suspended SEND command is resumed in steps S41-14 to S41-16. That is, the GETSTATUS command is interrupted and executed during the SEND command, and the SEND command is resumed after waiting for the end of the GETSTATUS command.
[0135]
Therefore, the image supply device can obtain the current status of the printer by the GETSTATUS command even during execution of the SEND command, and can perform data transfer while checking the status of the printer. The interrupt processing of this GETSTATUS command is instructed from the application layer 29-1 shown in FIG. 29 and processed in the session layer 29-2. That is, after the application of the image supply device instructs the SEND command to the session layer, it means that the application issues a GETSTATUS command to the session layer at a specific time in order to obtain the printer status. .
[0136]
However, in the example shown in FIG. 41, the GETSTAUS command can be executed only when the printer buffer is empty. For example, the inconvenience that the GETSTATUS command cannot be transferred if it is time to execute the GETSTATUS command during the response time T2 when WriteBlock cannot be performed, as shown in steps S40-8 to S40-9 in FIG. Occurs. As described above, this is because there is no empty buffer on the printer side. If the response time T2 is long, the printer status cannot be obtained at regular intervals. Thus, depending on the remaining number of buffers on the printer side, there may be a problem that the printer status cannot be obtained periodically.
[0137]
[Data transfer processing in this embodiment]
[Dummy processing overview]
The present embodiment solves the problem in general command transfer described with reference to FIGS. 29 to 41 described above. Hereinafter, this solution will be described in detail. In the following description, the above-described FIG. 34 and FIG. 40 are appropriately changed, and the other drawings in FIG. 29 to FIG. 41 are the same.
[0138]
The present embodiment is characterized in that the configuration of the control register 30-1 and the response register 30-3 shown in FIG. 34 is changed as shown in FIG. The lower part of FIG. 42 shows the configuration of the response register 30-3, which is characterized in that a BLOCK count 42-3 is added. The BLOCK count 42-3 is a part for setting the number of empty buffers on the printer side. Therefore, in this embodiment, the printer can return the BLOCK count to the image supply device in addition to ACK / NACK for WriteBlock.
[0139]
FIG. 43 shows a DUMMYBLOCK command (hereinafter simply referred to as a DUMMY command) added in the present embodiment, in addition to the SEND command and the GETSTATUS command shown in FIG. This is a command sent from the image supply device to the printer. When the number of empty blocks indicated by BLOCK count42-3 in the response returned from the printer is less than the predetermined number, the SEND Sent to the printer on behalf of the command. When the printer receives this DUMMY command, it does not store in the internal block buffers 33-2 to 33-7 and does not change the number of empty buffers, and sends BLOCK ACK and NACK to the response register 31 of the image supply device. Return to -2. Thus, the DUMMY command is a command having no corresponding reply. Details of the DUMMY command processing will be described later.
[DUMMY command control procedure]
The present embodiment is characterized in that the above-described WriteBlock repeat process shown in FIG. 40 is changed as shown in FIG. 44, and the difference is as follows. First, in contrast to the BLOCK ACK response shown in step S40-3 in FIG. 40, the BLOCK ACK response in step S44-3 in FIG. 44 is set with a BLOCK count 42-3 indicating the number of remaining buffers. . Furthermore, in FIG. 40, the write block to the final buffer shown in step S40-7 and the response time T2 until BLOCK ACK is returned in step S40-9 are in a transfer waiting state, whereas in FIG. When BLOCK ACK is returned with BLOCK count set to 1 in step S44-9, dummy processing in step S44-10 is performed until BLOCK ACK is returned with BLOCK count set to m (m is a value other than 1). is there.
[0140]
Hereinafter, the dummy process in this embodiment will be described. First, in step S44-11, the image supply device determines that the BLOCK count of BLOCK ACK has become 1, and writes a DUMMY command in the printer block register instead of the SEND command. In step S44-12, BLOCK COMPLETE for notifying the completion of WriteBlock is written in the control register of the printer. Then, in step S44-13, BLOCK ACK is returned to the response register of the image supply device, but as long as the BLOCK count set in this BLOCK ACK is 1, as shown in steps S44-13 to S44-14, the printer Continue writing DUMMY commands to the block register.
[0141]
On the printer side, when a DUMMY command is written in the block register, it is determined that the command is a DUMMY command, and BLOCK ACK is returned without saving the DUMMY command in the buffer. Therefore, the number of free buffers at the time of reply is returned as BLOCK count, so if there are more free buffers, BLOCK count will increase. If there are no more free buffers, BLOCK count will continue to be set to 1 and BLOCK ACK will be returned. .
[0142]
In the image supply device, when a BLOCK ACK BLOCK count other than 1 is set and returned in step S44-16, the SEND command transfer interrupted by dummy processing is transferred in steps S44-17 to S44-22. Resume processing.
[0143]
As described above, in this embodiment as shown in FIG. 44, dummy processing can be performed until the buffer on the printer side becomes empty. Therefore, even if the printer buffer is full, the GETSTATUS command can be executed as shown below.
[DUMMY, GETSTATUS command control procedure]
FIG. 45 shows the control procedure of the DUMMY command and the GETSTATUS command in this embodiment. As described above, when the BLOCK count becomes 1 in step S44-9 in FIG. 44, the dummy processing of this embodiment is executed. In FIG. 45, step S45-5 shows dummy processing, and step S45-8 shows GETSTATUS command execution processing during dummy processing. Hereinafter, the GETSTATUS command execution process during the dummy process in step S45-8 will be described in detail.
[0144]
During the dummy processing shown in step S45-5, when it is time for the image supply device to capture the printer status, the image supply device writes the GETSTATUS command instead of the DUMMY command that was written to the printer block register. (Step S45-9) is performed. The execution process of the GETSTATUS command is the same as that in FIG.
[0145]
In step S45-11, if the BLOCK count set in the BLOCK ACK returned for the GETSTATUS command is still 1, as shown in steps S45-15 to S45-17 even after execution of the GETSTATUS command processing , DUMMY command processing is executed until BLOCK count is not 1.
[0146]
When the BLOCK count is returned to a number other than 1 in step S45-17, the processing of the SEND command is restarted from step S45-18, as described above with reference to FIG.
[0147]
As described above with reference to FIGS. 44 and 45, in the present embodiment, first, the remaining number of buffers on the printer side can be known, and when the remaining number becomes 1, dummy processing is executed. The During the dummy process, the DUMMY command is not stored in the buffer on the printer side, so the number of remaining buffers does not decrease. Therefore, other commands such as the GETSTATUS command can be written to the block register during the dummy process. That is, in the example shown in FIG. 40, while there was no empty buffer, that is, during the response time T2, the GETSTATUS command could not be interrupted and issued, but in this embodiment, by providing the DUMMY command, The GETSTATUS command can be issued as an interrupt even if there is no empty buffer. Details of each process of the image supply device and the printer at this time will be described later.
[DUMMY command control procedure before SEND]
FIG. 46 is a diagram showing a control procedure of the DUMMY command before the SEND command in the present embodiment, that is, shows a procedure when the DUMMY command is sent before the first SEND command is executed.
[0148]
In FIG. 46, step S46-4 is the first SEND command, and prior to this, DUMMY processing is performed in steps S46-1 to S46-3. Thus, by first performing DUMMY command processing, since the buffer is not yet used by the SEND command, the BLOCK countn returned in step S46-3 indicates the total number of buffers the printer has, Before starting the SEND command, you can know the total number of buffers the printer has. That is, it is possible to know the total number of buffers before starting to use the buffers.
[0149]
For example, if a dummy process is executed when the printer has only one buffer, the SEND command may not be executed indefinitely, and the DUMMY command may be repeated indefinitely. Therefore, as shown in FIG. 46, by executing the DUMMY command prior to the SEND command, it is possible to control so as not to perform dummy processing when the number of printer buffers is one.
[Traffic efficiency]
FIG. 47 is a diagram showing the control procedure of the DUMMY command described in FIG. 44 described above, and shows that the response time of BLOCK ACK to BLOCK COMPLETE is T1. In this manner, the image supply device repeats writing the DUMMY command to the block register on the printer side as long as BLOCK ACK returns after BLOCK count is set to 1.
[0150]
Here, if the response time T1 is short, many dummy processes are executed, and traffic on the bus is increased unnecessarily. In order to solve this on the image supply device side, after BLCOK ACK, it is possible to measure the time by the timer until the next DUMMY command is written to the block register and adjust the number of times the DUMMY command is written to the block register. . However, in this method, the processing of the image supply device increases and becomes complicated.
[0151]
Therefore, in this embodiment, the efficiency of traffic on the 1394 serial bus is realized by the following method.
[0152]
FIG. 48 is a diagram showing a DUMMY command control procedure for suppressing an increase in traffic in the present embodiment. In FIG. 48, the response time until the printer returns BLOCK ACK to BLOCK COMPLETE (steps S48-2 to S48-3, etc.) is adjusted to T1 ′ longer than T1. As a result, the DUMMY command can be written to the block register of the printer as soon as BLOCK ACK returns on the image supply device side.
[0153]
Further, since the response time T1 ′ can be controlled on the printer side, T1 ′ can be adjusted in consideration of the conditions on the printer side such as the printing speed and the buffer consumption speed.
As described above, in this embodiment, it is possible to realize the efficiency of traffic on the 1394 serial bus without adjusting processing on the image supply device side only by adjusting the response time to T1 ′ on the printer side. .
[0154]
Hereinafter, regarding the data transfer processing in the present embodiment, each of the image supply device side and the printer side will be described in detail.
[Image transfer processing in image supply device]
FIG. 49 is a flowchart showing image transfer processing in the image supply device of this embodiment. Here, the image transfer process is a process in which the image supply device transfers image data to the printer and performs printing by the printer. First, in step S500, a DUMMY command writing process is performed. This is a process for confirming the number of counterpart buffers as described above with reference to FIG. Next, in step S501, it is determined whether or not the BLOCK count returned in step S500 is 1. If 1, the process proceeds to step S502, and ENADUMMYSENDflag is set to 0. Here, ENADUMMYSENDflag is a flag for determining whether or not to perform DUMMY processing. If it is 0, dummy processing is not performed, and if it is 1, dummy processing is performed. If BLOCK count is not 1 in step S501, the process proceeds to step S503, and ENADUMMYSENDflag is set to 1. Then, the process proceeds to step S504, and a SEND command process described later is executed.
[0155]
FIG. 50 is a flowchart showing details of the SEND command processing of the image supply device in step S504. First, in step S600, it is determined whether a GETSTATUS command is requested during SNED command processing. In the present embodiment, the GETSTATUS command is interrupted at regular intervals by timer processing, and a GETSTATUS command request is set. Details of this GETSTATUS command interrupt will be described later. If there is a GETSTATUS command request in step S600, the process proceeds to step S601 to execute GETSTAUS command processing. This is the process for extracting the printer status described above with reference to FIG. 38, and is used to check whether the printer has any errors or abnormalities during execution of the SNED command.
[0156]
When the GETSTATUS command process in step S601 ends, the process returns to step S600. If there is no GETSTATUS command request in step S600, the process proceeds to step S602 to check whether BLOCK count is 1. If BLOCK count is 1, it indicates that the printer has one remaining free buffer, and the process proceeds to step S603 to check whether ENADUMMYflag is 1. ENADUMMYBLOCKflag is a flag indicating whether or not DUMMY command processing can be executed, and is set in accordance with the total number of empty buffers on the printer side in steps S502 and S503 in FIG. 49 described above. If ENADUMMYBLOCKflag is not 1 in step S603, the process returns to step S600 without performing the DUMMY command processing. This process corresponds to the process of preventing the DUMMY command process from being performed when the total number of buffers on the printer side is 1, as shown in FIG. 46 in the present embodiment. If ENADUMMYBLOCKflag is 1 in step S603, the process proceeds to step S604, and the DUMMY command transfer process shown in step S45-4 in FIG. 45 described above is executed. In other words, when the total number of buffers on the printer side is 1 or more and the BLOCK count is 1 (the remaining free buffer of the printer is 1), DUMMY command transfer processing is performed. Then, the process proceeds to step S606.
[0157]
On the other hand, if the BLOCK count is not 1 in step S602, the process proceeds to step S605 to execute a SEND command transfer process. This corresponds to steps S45-1, S45-18, and S45-21 in FIG. 45 described above, and is processing for sending image data to the printer. If the image data does not fit in one buffer, the image data is divided into a plurality of SNED commands and written to the printer block register as shown in FIG. 39 described above. Step S605 corresponds to a process of writing one of the divided image data, and the entire image data is transferred by repeatedly executing step S605.
[0158]
In step S606, BLOCK COMPLETE is written in the printer control register. By writing this BLOCK COMPLETE, the end of data writing to the block register is notified to the printer side.
[0159]
Next, the process proceeds to step S607, where it is checked whether a timeout has occurred. That is, the time from when BLOCK COMPLETE is written to the printer control register in step S606 to when BLOCK ACK / NACK is returned to the response register of the image supply device is measured by a timer, and even if the predetermined time elapses, BLOCK ACK / If NACK is not returned, a timeout occurs. If time out occurs in step S607, the process proceeds to step S608 to perform time-out processing. Here, the time-out process is a process for notifying the user that a time-out has occurred for some reason and the data transmission to the printer is not successful, or for terminating the data transfer process to the printer. After the timeout process, the SEND command process ends.
[0160]
If it is not timed out in step S607, the process proceeds to step S609 to check whether BLOCK NACK is returned from the printer to the response register of the image supply device. If BLOCK NACK is returned, the data sent to the printer has some trouble, and the process proceeds to NACK processing in step S610. In the NACK process in step S610, the data transmission process to the printer is terminated because the data transmission to the printer has failed for some reason as in the timeout process. After the NACK process, the SEND command process ends.
[0161]
If it is not BLOCK NACK in step S609, the process proceeds to step S611 to check whether BLOCK ACK is returned from the printer. If not BLOCK ACK, the process returns to step S607. If it is BLOCK ACK, the process proceeds to step S612 to check whether or not the SNED command is completed. If not completed, the process returns to step S600 and the above-described processing is repeated. On the other hand, if the SEND command has ended in step S612, the SEND command processing ends.
[0162]
As described above with reference to FIG. 50, it can be seen that the image supply device of this embodiment can execute the SNED and DUMMY commands and the GETSTATUS command during the SEND command. This is processing corresponding to the procedure on the image supply device side in the DUMMY, GETSTATUS command control procedure described with reference to FIG.
[0163]
FIG. 51 is a flowchart showing the details of the GETSTATUS command process shown in step S601 of FIG. 50 described above, that is, the process in which the image supply device writes a command for receiving the status from the printer into the block register on the printer side. is there. First, in step S700, the GETSTATUS command is written in the block register on the printer side. This corresponds to step S45-9 in FIG. 45 described above. In step S701, BLOCK COMPLETE is written in the control register of the printer. This corresponds to step S45-10 in FIG. Next, the process proceeds to step S702, where it is checked whether a timeout has occurred. That is, the response time from when BLOCK COMPLETE is written in the printer control register in step S701 to when BLOCK ACK / NACK is returned from the printer to the response register is measured, and BLOCK ACK / NACK is not returned even if the predetermined time elapses. Time out. If a timeout occurs in step S702, the process proceeds to step S703 to perform timeout processing. This timeout process is the same as step S608 shown in FIG. After the timeout process, the GETSTATUS command process ends.
[0164]
If it is not timed out in step S702, the process proceeds to step S704, and it is checked whether BLOCK NACK is returned from the printer to the response register of the image supply device. If BLOCK NACK is returned, the data sent to the printer has some trouble, and the process proceeds to NACK processing in step S705. This NACK process is the same as step S610 in FIG. After NACK processing, GETSTATUS command processing ends. If it is not BLOCK NACK in step S704, the process proceeds to step S706, and it is checked whether BLOCK ACK is returned from the printer. If it is not BLOCK ACK, the process returns to step S702. The processing from step S702 to S706 corresponds to step S45-11 in FIG.
[0165]
Next, the process proceeds to step S707, and a time-out until BLOCK COMPLETE is checked in steps S707 to S709. This means that the BLOCK COMPLETE response time from the printer in steps S45-12 to S45-13 in FIG. 45 is determined, and if it is a timeout, it means that BLOCK COMPLETE has not arrived within the predetermined time, and the process proceeds to step S708. move on. That is, step S708 is a timeout process similar to step S703, and then the GETSTATUS command process ends. If it is not timed out in step S707, the process proceeds to step S709, and it is checked whether BLOCK COMPLETE has been written in the control register of the image supply device. If it is not BLOCK COMPLETE, the process returns to step S707.
[0166]
If it is BLOCK COMPLETE in step S709, the process proceeds to step S710, and a GETSTATUS reply is fetched. This is a response to the GETSTATUS command shown on the right side of FIG. 37, and the contents are shown in FIG. Next, in step S711, it is determined whether or not the reply in step S710 was normal, that is, whether or not the returned status was correctly written in the block register of the image supply device. If it is correct, BLOCK ACK is written to the response register of the printer in step S712, and if it is not correct, BLOCK NACK is written in step S713. The processing in steps S712 and S713 corresponds to step S45-14 in FIG. Then, the GETSTATUS command process ends.
[0167]
As described above, the GETSTATUS command process shown in FIG. 51 (step S45-8 in FIG. 45) allows the image supply device to obtain the status from the printer.
[0168]
FIG. 52 is a flowchart showing details of timer interrupt processing in the image supply device. In the image supply device, this timer interrupt process is called at regular intervals. First, in step S800, it is checked whether it is time to perform GETSTATUS command processing. If it is the GETSTATUS execution time, the process proceeds to step S801, and a GETSTATUS command request is set. When this request is determined in step S600 of FIG. 50, the above-described GETSTATUS command processing is executed. After the request is set in step S801, the timer process ends.
[Image transfer process in printer]
FIG. 53 is a flowchart showing details of SEND command processing on the printer side. First, in step S900, it is checked whether BLOCK COMPLETE has been written in the printer control register. If BLOCK COMPLETE is not written, the process proceeds to step S901, and after executing the printing process, the process returns to step S900. This printing process will be described later. If BLOCK COMPLETE is written in the control register in step S900, the process proceeds to step S902 and the written command is fetched. As shown in FIG. 35 described above, this command is composed of CommandID 35-1 and Parameter 35-2, and the type of command can be known by examining this CommandID.
[0169]
In step S903, it is checked whether the command written in the block register is a GETSTATUS command, that is, whether CommandID indicates a GETSTATUS command. If it is a GETSTATUS command, the process proceeds to step S904, and a GETSTATUS command process on the printer side described later is executed. After executing the GETSTATUS command process, the process returns to step S900. If it is not a GETSTATUS command in step S903, it is next checked whether it is a DUMMY command. If it is not a DUMMY command, it is determined that the command is a SEND command, and the process advances to step S906 to check whether the image data sent by the SEND command is normal. If not normal, the process proceeds to step S907, and BLOCK NACK is written in the response register of the image supply device. As a result, the image supply device is notified that the image data has not been sent correctly.
[0170]
If the image data is normal in step S906, the process proceeds to step S908, and the image data written in the block register is moved to an appropriate internal buffer. This is a process of moving the image data in the block register to one of the buffers indicated by 33-2 to 33-7 in FIG. In step S909, 1 is subtracted from BLOCK count indicating the number of remaining free buffers. In step S910, BLOCK ACK is written in the response register of the image supply device, and the process returns to step S900.
[0171]
If the command is a DUMMY command in step S905, the process proceeds to step S911, and it is checked whether or not the BLOCK count is greater than one. If it is larger, it is not a DUMMY command in the final buffer, so the process proceeds to step S910 and BLOCK ACK is written in the response register of the image supply device. On the other hand, if the BLOCK count is 1 in step S911, the process proceeds to step S912 and waits for T1 ′ time. Here, T1 ′ is a response time until BLOCK ACK is returned to BLOCK COMPLETE shown in FIG. 48 described above, and is set longer than T1 shown in FIG. The time until BLOCK ACK is returned is adjusted by this T1 ′ time, and as a result, the number of DUMMY commands transferred from the image supply device to the printer can be reduced.
[0172]
As described above, the SEND command processing shown in FIG. 53 performs image data reception processing on the printer side, and processing of the GETSTATUS and DUMMY commands becomes possible during execution of the SEND command, and ACK is received according to the number of free buffers indicated by BLOCK count. The return time can be adjusted.
[0173]
FIG. 54 is a flowchart showing the printing process shown in step S901 of FIG. 53 described above. First, in step S1000, it is checked whether or not there is data in the buffer. If there is no data in the buffer, the printing process ends. If there is data, the process proceeds to step S1001, and a process for printing the data in the head buffer is performed. Here, the head buffer means a buffer at the head of data that has not yet been printed, and it is checked in step S1002 whether or not the head buffer is empty. If the head buffer is not empty, the printing process ends. If it is empty, the process proceeds to step S1003, and 1 is added to BLOCK count. That is, when all the data in the top buffer is printed and becomes empty, the number of empty buffers is increased by one. Then, the printing process ends. Through the printing process described above, printing and empty buffer management in this embodiment can be performed.
[0174]
FIG. 55 is a flowchart showing details of the GETSTATUS command processing in the printer shown in step S904 of FIG. 53 described above. This is processing for returning a response from the printer side to the GETSTATUS command from the image supply device. First, a status to be returned is created in step S1100. The contents of this status are as shown in FIG. 38 described above, and the printer status is investigated and the corresponding contents are set. In step S1101, the GETSTATUS reply is written in the block register of the image supply device. This corresponds to step S45-12 in FIG. 45 described above.
[0175]
In step S1102, BLOCK COMPLETE is written in the control register of the image supply device. This corresponds to step S45-13 in FIG. Then, the process proceeds to step S1103, and a timeout is checked. In other words, the time from when BLOCK COMPLETE is written to the control register of the image supply device in step S1102 until BLOCK ACK / NACK is returned to the response register of the printer is measured. If it is not returned, it times out. If a timeout occurs in step S1103, the process proceeds to step S1104 to perform timeout processing. This is the same processing as step S608 in FIG. 50 described above. After the timeout process, the GETSTATUS command process ends.
[0176]
If it is not time-out in step S1103, the process advances to step S1105 to check whether BLOCK NACK is returned from the image supply device to the response register of the printer. If BLOCK NACK is returned, there is some problem with the data sent to the image supply device. Therefore, the process proceeds to step S1106, and the same NACK process as step S610 in FIG. 50 is performed. After NACK processing, GETSTATUS command processing ends. On the other hand, if it is not BLOCK NACK in step S1105, the process proceeds to step S1107, and it is checked whether BLOCK ACK is returned from the image supply device. If it is not BLOCK ACK, the process returns to step S1103. The processing from step S1103 to S1107 corresponds to step S45-14 in FIG. If it is BLOCK ACK in step S1107, the GETSTATUS process ends.
[0177]
As described above, the printer status is returned to the image supply device by the GETSTATUS command processing on the printer side shown in FIG.
[0178]
As described above with reference to FIG. 42 to FIG. 55, according to the present embodiment, the image supply device uses the BLOCK ACK / NACK and BLOCK count written from the printer to the response register, so that the number of free buffers that the printer currently has When the number of free buffers becomes 1, processing to send a DUMMY command instead of the SEND command can be executed. Further, since the GETSTATUS command can be executed while the DUMMY command is being executed, the GETSTATUS command can be arbitrarily executed even when the SEND command is being executed. Since this DUMMY command can be configured with a smaller amount of data than other commands such as the SEND command, the influence on the traffic on the 1394 serial bus can be minimized.
[0179]
Further, since the time interval at which the DUMMY command is sent can be adjusted on the printer side, traffic on the 1394 serial bus can be made efficient without imposing a load on the image supply device side.
[0180]
Also, when the total number of buffers of the printer is 1, it is possible not to prevent necessary SEND command processing by not performing DUMMY command processing.
Second Embodiment
Hereinafter, a second embodiment according to the present invention will be described.
[Register configuration]
FIG. 56 is a diagram showing a configuration obtained by improving the configuration of the general control register and response register shown in FIG. 34 in the first embodiment described above in the second embodiment. The second embodiment is characterized in that 03h BLOCK RETRY is added as a response command 56-2 in the response register configuration shown in the lower part of FIG. Here, BLOCK RETRY is a response indicating that the image supply device is requested to re-transfer image data when the number of empty buffers on the printer side is 1, for example. Accordingly, if the response command 56-2 is 03h, it indicates BLOCK RETRY, that is, it indicates that retransfer of image data is requested.
[0181]
FIG. 57 is a diagram showing a RETRY, GETSTATUS command control procedure in the second embodiment, which corresponds to the DUMMY, GETSTATUS command control procedure shown in FIG. 45 in the first embodiment described above. However, this embodiment is different from FIG. First, BLOCK count is returned by 1 in step S45-3 in FIG. 45, but BLOCK RETRY is returned in step S57-3 in FIG. In step S45-4 in FIG. 45, the DUMMY command is written to the block register, whereas in step S57-4 in FIG. 57, the same data as the immediately preceding SEND command shown in step S57-1 is written. The point is different. The other processes in FIG. 57 are the same as those in FIG.
[0182]
Hereinafter, the processing on the image supply device side and the processing on the printer side in the second embodiment will be described in detail with reference to FIGS.
[Image transfer processing in image supply device]
FIG. 58 is a flowchart showing image transfer processing of the image supply device in the second embodiment, and substantially performs SEND command processing in step S1200.
[0183]
FIG. 59 is a flowchart showing details of the SEND command processing in step S1200 described above. First, in step S1300, it is determined whether there is a GETSTATUS command request. The GETSTATUS command is activated in the same manner as in FIG. 52 shown in the first embodiment. If there is a request in step S1300, the process proceeds to step S1301 to execute GETSTAUS command processing. This GETSTATUS command process is the same as the process for retrieving the printer status shown in FIG. 51 in the first embodiment. When the GETSTATUS command process in step S1301 ends, the process returns to step S1300.
[0184]
If there is no GETSTATUS command request in step S1300, the process advances to step S1302 to check whether BLOCK RETRY is written in the response register. If BLOCK RETRY is written, it means that there is only one remaining free buffer in the printer and data re-transfer is requested. Therefore, the process proceeds to step S1303, and the printer side control register The data written by the previous SEND command is written again. This corresponds to steps S57-4 and S57-15 in FIG. If it is not BLOCK RETRY in step S1302, the process proceeds to step S1304 to execute the SEND command transfer process. This corresponds to steps S57-1, S57-18, and S57-21 in FIG. 57, and is a process of sending image data to the printer. If the image data does not fit in one buffer, as shown in FIG. 39 in the first embodiment, the image data is divided into a plurality of SNED commands and written to the block register of the printer. Steps S1303 and S1304 correspond to a process of writing one of the divided image data, and the entire image data is transferred by repeatedly executing step S1304.
[0185]
In step S1305, BLOCK COMPLETE is written in the control register on the printer side. By writing this BLOCK COMPLETE, the end of data writing to the block register is notified to the printer side. Next, proceeding to step S1306, it is checked whether or not a timeout has occurred. In other words, the timer measures the time from when BLOCK COMPLETE is written in the printer control register in step 1305 until BLOCK ACK / NACK or RETRY is returned to the response register of the image supply device. A timeout occurs if / NACK and RETRY are not returned. If a time-out occurs in step S1306, the process proceeds to step S1307 to perform time-out processing. Here, the time-out process is a process for notifying the user that a time-out has occurred for some reason and the data transmission to the printer is not successful, or for terminating the image transfer process to the printer. After the timeout process, the SEND command process ends.
[0186]
If it is not timed out in step S1306, the process proceeds to step S1308 to check whether BLOCK NACK is returned from the printer to the response register of the image supply device. If BLOCK NACK is returned, the data sent to the printer has some trouble, and the process proceeds to NACK processing in step S1309. The NACK process in step S1309 terminates the image transfer process to the printer because the data transmission to the printer has failed for some reason as in the timeout process. After the NACK process, the SEND command process ends.
[0187]
If it is not BLOCK NACK in step S1308, the process proceeds to step S1310 to check whether BLOCK RETRY is returned from the printer. If BLOCK RETRY is returned, the process returns to step S1300. If BLOCK RETRY is not returned, the process proceeds to step S1311, where it is checked whether BLOCK ACK is returned from the printer. If not BLOCK ACK, the process returns to step S1306. If it is BLOCK ACK, the process proceeds to step S1312, and it is checked whether or not the SNED command is completed. If not completed, the process returns to step S1300 and the above-described processing is repeated. On the other hand, if the SEND command has ended in step S1312, the SEND command processing ends.
[0188]
As described above with reference to FIG. 59, it can be seen that the image supply device of the second embodiment can execute the SNED command, the processing for BLOCK RETRY, and the GETSTATUS command during the SEND command. This is processing corresponding to the procedure on the image supply device side in the RETRY and GETSTATUS command control procedure described with reference to FIG.
[Image transfer process in printer]
FIG. 60 is a flowchart showing in detail the SEND command processing in the printer of the second embodiment.
[0189]
First, in step S1400, it is checked whether BLOCK COMPLETE is written in the control register on the printer side. If BLOCK COMPLETE is not written, the process proceeds to step S1401, print processing is executed, and the process returns to step S1400. This printing process is the same as step S901 of FIG. 53 described in the first embodiment. If BLOCK COMPLETE has been written in step S1400, the process proceeds to step S1402 to capture the written command. As shown in FIG. 35 described above, this command is composed of CommandID 35-1 and Parameter 35-2, and the type of command can be known by examining this CommandID.
[0190]
Next, proceeding to step S1403, it is checked whether or not the written command is a GETSTATUS command, that is, whether or not CommandID indicates a GETSTATUS command. If it is a GETSTATUS command, the process proceeds to step S1404. After executing the GETSTATUS command processing on the printer side, the process returns to step S1400. This GETSTATUS command processing is the same as that in FIG. 55 shown in the first embodiment. If it is not a GETSTATUS command in step S1403, it is determined that the command is a SEND command, the process proceeds to step S1405, and it is checked whether or not the BLOCK count is greater than one.
[0191]
If the BLOCK count is greater than 1, the process proceeds to step S1408, and it is checked whether the image data sent by the SEND command is normal. If not normal, the process proceeds to step S907, and BLOCK NACK is written in the response register of the image supply device. As a result, the image supply device is notified that the image data has not been sent correctly. If the image data is normal in step S1406, the process proceeds to step S1408, and the image data written in the block register is moved to an appropriate internal buffer. This is a process of moving the image data in the block register to one of the buffers indicated by 33-2 to 33-7 in FIG. In step S1409, 1 is subtracted from BLOCK count indicating the number of remaining free buffers. In step S1410, BLOCK ACK is written in the response register of the image supply device, and the process returns to step S1400.
[0192]
On the other hand, if the BLOCK count is 1 in step S1405, the process proceeds to step S1411 and waits for T1 ′ time. Here, T1 ′ is a response time until BLOCK ACK is returned to BLOCK COMPLETE shown in FIG. 48 described above, and is set longer than T1 shown in FIG. After the elapse of T1 ′ time, BLOCK RETRY that prompts retransmission of the SEND command is written in the response register of the image supply device in step S1412, and the process returns to step S1400. The second embodiment is characterized in that the SEND command is retransmitted in place of the DUMMY command transfer process shown in FIGS. 47 and 48 in the first embodiment described above. Therefore, the time until BLOCK RETRY is returned is adjusted by the T1 ′ time, and as a result, the number of SEND commands retransmitted from the image supply device to the printer can be reduced.
[0193]
As described above, the SEND command processing shown in FIG. 60 performs image data reception processing on the printer side, and not only enables GETSTATUS command processing during execution of the SEND command, but also SEND by the number of free buffers indicated by BLOCK count. Command retransmission processing is possible.
[0194]
As described above with reference to FIGS. 56 to 60, according to the second embodiment, according to the second embodiment, the number of free buffers that the printer currently has is 1 by BLOCK ACK / NACK and BLOCK RETRY returned from the printer. In this case, the SEND command can be retransmitted. Further, since the GETSTATUS command can be executed while the SNED command is being retransmitted, the GETSTATUS command can be arbitrarily executed even while the SEND command is being executed.
[0195]
In addition, since the existing bus reset, error processing, and the like can be used in this SEND command retransmission processing, it can be realized without adding new processing.
[0196]
Further, since the time interval at which the SEND command is retransmitted can be adjusted on the printer side, traffic on the 1394 serial bus can be made efficient without imposing a load on the image supply device.
[Third Embodiment]
The third embodiment according to the present invention will be described below.
[register]
FIG. 61 is a diagram showing a configuration obtained by improving the configuration of the general control register and response register shown in FIG. 34 in the first embodiment described above in the third embodiment.
[0197]
The third embodiment is characterized in that, in the control register configuration shown in FIG. 61, BLOCK DUMMY COMPLETE of 02h is added as a control command. Here, BLOCK DUMMY COMPLETE means that in the first embodiment, after writing the DUMMY command, BLOCK COMPLETE is written and the DUMMY command is notified to the printer side. By having BLOCK DUMMY COMPLETE, the printer side detects the BLOCK DUMMY COMPLETE being written in the control register, thereby performing the same operation as in the first embodiment.
[0198]
FIG. 62 is a diagram showing a control procedure of DUMMY processing in the example of the third embodiment, and corresponds to the control procedure of DUMMY processing shown in FIG. 44 in the first embodiment described above. This is different from FIG. 44 in that respect. First, the difference is that the DUMMY command is written by WriteBlock in steps S44-11 and S44-14 in FIG. 44, whereas this step is eliminated in FIG. 44 differs from FIG. 44 in that BLOCK COMPLETE is written in the control register, whereas in FIG. 62 BLOCK DUMMY COMPLETE is written in steps S62-11 and S62-13. . The other processing in FIG. 62 is the same as that in FIG.
[0199]
FIG. 63 is a diagram showing the DUMMY processing and GETSTATUS command control procedure in the example of the third embodiment, and corresponds to the DUMMY processing and GETSTATUS command control procedure shown in FIG. 45 in the first embodiment described above. However, it is different from FIG. 45 in the following points. First, the difference is that the DUMMY command is written by WriteBlock in steps S45-4 and S45-15 in FIG. 45, whereas this step is eliminated in FIG. 45 differs from FIG. 45 in that BLOCK COMPLETE is written to the control register, whereas in FIG. 63, BLOCK DUMMY COMPLETE is written in steps S63-5 and S63-14. . The other processes in FIG. 62 are the same as in FIG.
[0200]
FIG. 64 is a diagram showing a control procedure of DUMMY processing performed prior to image transmission processing in the example of the third embodiment, and corresponds to the control procedure of DUMMY processing shown in FIG. 46 in the first embodiment described above. However, it is different from FIG. 46 in the following points. First, the difference is that the DUMMY command is written by WriteBlock in step S46-1 in FIG. 46, whereas this step is eliminated in FIG. 46 differs from FIG. 46 in that BLOCK COMPLETE is written to the control register, whereas in FIG. 64, BLOCK DUMMY COMPLETE is written in step S64-1. The other processing in FIG. 64 is the same as that in FIG.
[0201]
Hereinafter, the processing on the image supply device side and the processing on the printer side in the third embodiment will be described in detail with reference to FIGS.
[Image transfer processing in image supply device]
FIG. 65 is a flowchart showing details of image transmission processing in the example of the third embodiment, and corresponds to the flowchart showing details of image transmission processing shown in FIG. 49 in the first embodiment described above. This embodiment is different from FIG. 49 in the following points. First, in step S500 in FIG. 49, the DUMMY command is written by WriteBlock, whereas in FIG. 65, BLOCK DUMMY COMPLETE is written. The other processes in FIG. 65 are the same as those in FIG.
[0202]
FIG. 66 is a flowchart showing details of the SEND command processing in the example of the third embodiment, and corresponds to the flowchart showing details of the SEND command processing shown in FIG. 50 in the first embodiment described above. This embodiment is different from FIG. 50 in the following points. First, in step S604 in FIG. 50, the DUMMY command is written by WriteBlock and the process proceeds to step S606, whereas in FIG. 66, BLOCK DUMMY COMPLETE is written in step S1604 and the process proceeds to step S1607. The other processes in FIG. 66 are the same as those in FIG.
[Image transfer processing in printer]
FIG. 67 is a flowchart showing details of SEND command processing on the printer side in the example of the third embodiment, and shows details of SEND command processing on the printer side shown in FIG. 53 in the first embodiment described above. This corresponds to the flowchart.
[0203]
First, in step S1700, it is checked whether BLOCK DUMMY COMPLETE has been written in the control register on the printer side. If BLOCK DUMMY COMPLETE has been written, the process proceeds to step S1701, BLOCK ACK is written in the response register of the image supply device, and the process returns to step S1700. If BLOCK DUMMY COMPLETE has not been written in step S1700, the process proceeds to step S1702 to check whether BLOCK COMPLETE has been written. If BLOCK COMPLETE has not been written, the process advances to step S1703 to execute print processing, and then returns to step S1700. The printing process is the same as that described in FIG. 54 of the first embodiment. If BLOCK COMPLETE has been written in step S1702, the process proceeds to step S1704 to write the written command. As shown in FIG. 35 of the first embodiment, this command is composed of CommandID 35-1 and Parameter 35-2, and the type of command can be known by examining this CommandID. Next, proceeding to step S1705, it is checked whether or not the command written in the block register is a GETSTATUS command, that is, whether or not CommandID indicates a GETSTATUS command. If it is a GETSTATUS command, the process advances to step S1706 to execute GETSTATUS processing on the printer side. The GETSTATUS process is the same as that described in FIG. 55 of the first embodiment. After executing the GETSTATUS process, the process returns to step S1700. If it is not a GETSTATUS command in step S1705, the process proceeds to step S1707, and since the command is a SEND command, it is checked whether the image data sent by the SEND command is normal. If not normal, the process advances to step S1708 to write BLOCK NACK in the response register of the image supply device. As a result, the image supply device is notified that the image data has not been sent correctly. If the image data is normal in step S1707, the process proceeds to step S1709, and the image data written in the block register is moved to an appropriate internal buffer. This is a process of moving the image data in the block register to one of the buffers indicated by 33-2 to 33-7 in FIG. In step S1710, 1 is subtracted from BLOCK count indicating the number of remaining free buffers. In step S1711, BLOCK ACK is written in the response register of the image supply device, and the process returns to step S1700.
[0204]
As described above with reference to FIGS. 61 to 67, according to the third embodiment, the image supply device uses the BLOCK ACK / NACK and BLOCK count written in the response register from the printer, and the printer currently has a free space. The number of buffers can be known, and when the number of free buffers becomes 1, processing to write BLOCK DUMMY COMPLETE in the control register on the printer side can be executed instead of the SEND command. Further, since the GETSTATUS command can be executed during execution of the DUMMY process, the GETSTATUS command can be arbitrarily executed even during the execution of the SEND command.
[Modification of Embodiment]
In the above-described first and second embodiments, the example in which the DUMMY command processing and the BLOCK RETRY processing are performed when the number of free buffers in the printer becomes 1, has been described. It is not limited to. Any number may be used as long as it causes inconvenience in executing the SEND command processing. For example, it may be 2 or 3.
[0205]
In each embodiment, an example in which print processing is realized by transferring data from an image supply device to a printer has been described. However, the present invention is not limited to any device as long as it is a device that transfers and uses image data. It is also applicable to.
[0206]
In the first embodiment described above, the DUMMY command has been described as being transferred when the number of empty buffers in the printer becomes 1. However, this command is a command sent from the image supply device to the printer, Any command may be used as long as the number of free buffers can be obtained and the processing load on the printer is small.
[0207]
In each embodiment, the example in which the number of free buffers is set and notified in the BLOCK count has been described, but buffer information such as “there are free buffers” and “the number of free buffers is small” is not used instead of the number of free buffers. A setting method is also conceivable. Since this method can also notify the image supply device of the buffer status, the same effects as those of the above-described embodiments can be obtained.
[0208]
In each of the above-described embodiments, 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 is referred to as Universal Serial Bus (USB). The present invention can also be applied to a network configured using an arbitrary serial interface such as a serial interface.
[Other Embodiments]
Note that the present invention can be applied to a system composed of a plurality of devices (for example, a host computer, interface device, reader, printer, etc.), or a device (for example, a copier, a facsimile device, etc.) composed of a single device. You may apply to.
[0209]
Another object of the present invention is to supply a storage medium storing software program codes for realizing the functions of the above-described embodiments to a system or apparatus, and the computer (or CPU or MPU) of the system or apparatus stores the storage medium. Needless to say, this can also be achieved by reading and executing the program code stored in the. In this case, the program code itself read from the storage medium realizes the functions of the above-described embodiments, and the storage medium storing the program code constitutes the present invention. As a storage medium for supplying the program code, for example, a floppy disk, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM, a CD-R, a magnetic tape, a nonvolatile memory card, a ROM, or the like can be used.
[0210]
Further, by executing the program code read by the computer, 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 the function of the above-described embodiment is realized by performing part or all of the actual processing and the processing is included.
[0211]
Further, after the program code read from the storage medium is written into a memory provided in a function expansion card inserted in 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 functions of the above-described embodiments are realized by the processing.
[0212]
【The invention's effect】
As described above, according to the present invention, a host device and a target device are connected by a 1394 serial bus, etc., and the same register area is used for commands and data for transferring data sent from the host device to the target device. And a data transfer apparatus, a data transfer system and method, an image processing apparatus, and a recording medium that can arbitrarily execute a command other than data transfer when only a response to data writing to a register is performed. Can do. That is, according to the present invention, another command can be arbitrarily executed even during data transfer by executing a dummy process in accordance with the number of empty buffers in the target device.
[0213]
Also provided are a data transfer device, a data transfer system and method, an image processing device, and a recording medium that realize efficiency of traffic on a data bus by adjusting a response time for writing data to a register. be able to.
[0214]
[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 diagram showing a cross section of a cable for a 1394 serial bus;
FIG. 6 is a diagram for explaining the DS-Link method of data transfer method adopted in the 1394 serial bus;
FIG. 7 is a flowchart showing a series of sequence examples from the generation of a bus reset signal until the node ID is determined and data can be transferred;
FIG. 8 is a flowchart showing a detailed example from monitoring a bus reset signal to determining a root node;
FIG. 9 is a flowchart showing a detailed example of node ID setting;
FIG. 10 is a diagram showing an example of network operation of the 1394 serial bus;
FIG. 11 is a diagram showing the functions of the 1394 serial bus CSR architecture;
FIG. 12 is a diagram showing registers related to the 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 the minimum format of the configuration ROM of the 1394 serial bus;
FIG. 15 is a diagram showing the general format of a configuration ROM for a 1394 serial bus;
FIG. 16 is a diagram for explaining a request for a bus use right;
FIG. 17 is a diagram for explaining permission to use a bus;
FIG. 18 is a flowchart showing the arbitration flow in the 1394 serial bus;
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;
FIG. 20 is a diagram showing a service in the link layer;
FIG. 21 is a diagram showing temporal transition in asynchronous transfer;
FIG. 22 is a diagram showing the format of an asynchronous transfer packet;
FIG. 23 is a diagram showing an example of split transaction operation;
FIG. 24 is a diagram showing an example of temporal transition of the 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 packet format field for synchronous transfer in the 1394 serial bus;
FIG. 28 is a diagram showing temporal transition of the transfer state when synchronous transfer and asynchronous transfer are mixed;
FIG. 29 is a diagram showing a layer structure of a 1394 serial bus;
FIG. 30 is a diagram showing a register configuration for data transfer;
FIG. 31 is a diagram showing an overview of command control from the image supply device to the printer;
FIG. 32 is a diagram showing an outline of reply control from the printer to the image supply device;
FIG. 33 is a diagram showing a block register and internal buffer configuration in the printer;
FIG. 34 is a diagram showing a general configuration of a control and response register;
FIG. 35 is a diagram showing a command configuration;
FIG. 36 is a diagram showing the configuration of the SEND and GETSTATUS commands.
FIG. 37 is a diagram showing the configuration of SEND and GETSTATUS reply.
FIG. 38 is a diagram showing the status of the GETSTATUS command;
FIG. 39 is a diagram showing how image data is divided in the SEND command;
FIG. 40 is a diagram showing a general control procedure of the image supply device and the printer;
FIG. 41 is a diagram showing a control procedure of a GETSTATUS command;
FIG. 42 is a diagram showing the configuration of a control and response register;
FIG. 43 is a diagram showing the structure of a DUMMY command;
FIG. 44 is a diagram showing a control procedure of a DUMMY command;
FIG. 45 is a diagram showing a control procedure of a DUMMY, GETSTATUS command;
FIG. 46 is a diagram showing the control procedure of the DUMMY command before the SEND command;
FIG. 47 is a diagram showing a general control procedure of a DUMMY command;
FIG. 48 is a diagram showing a control procedure of a DUMMY command for improving traffic efficiency;
FIG. 49 is a flowchart showing image transfer processing in the image supply device;
FIG. 50 is a flowchart showing SEND command processing in the image supply device;
FIG. 51 is a flowchart showing GETSTATUS command processing in the image supply device;
FIG. 52 is a flowchart showing timer interrupt processing in the image supply device;
FIG. 53 is a flowchart showing SEND command processing in the printer;
FIG. 54 is a flowchart showing print processing in the printer;
FIG. 55 is a flowchart showing GETSTATUS command processing in the printer;
FIG. 56 is a diagram showing a configuration of a control and response register in the second embodiment;
FIG. 57 is a diagram showing the control procedure of the RETRY and GETSTATUS commands in the second embodiment;
FIG. 58 is a flowchart showing image transfer processing in the image supply device according to the second embodiment;
FIG. 59 is a flowchart showing SEND command processing in the image supply device according to the second embodiment;
FIG. 60 is a flowchart illustrating SEND command processing in the printer of the second embodiment.
FIG. 61 is a diagram showing a configuration of a control register and a response register in the third embodiment according to the present invention.
FIG. 62 is a diagram showing a control procedure of DUMMY processing in the third embodiment.
FIG. 63 is a diagram showing a control procedure of DUMMY processing and a GETSTATUS command in the third embodiment.
FIG. 64 is a diagram showing a control procedure of DUMMY processing before a SEND command in the third embodiment.
FIG. 65 is a flowchart showing image transfer processing in the image supply device of the third embodiment;
FIG. 66 is a flowchart showing SEND command processing in the image supply device of the third embodiment;
FIG. 67 is a flowchart illustrating a SEND process in the printer of the third embodiment.

Claims (18)

A data transfer method used between a host device and a target device,
A first transfer step of transferring first data to be stored in a buffer of the target device from the host device to the target device ;
A first reply step of returning buffer information indicating the free capacity of the buffer as a response to the first data from the target device to the host device ;
A second transfer step of transferring specific data from the host device to the target device when the free capacity indicated by the buffer information is not larger than a predetermined capacity;
A second reply step of returning buffer information indicating the free space of the buffer as a response to the specific data from the target device to the host device without storing the specific data in the buffer;
After the specific data is transferred from the host device to the target device, if the free capacity indicated by the buffer information is larger than a predetermined capacity, the second data to be stored in the buffer is transferred from the host device to the target device. And a third transfer step of transferring to the target device . The buffer comprises a plurality of buffers,
2. The data transfer method according to claim 1 , wherein the buffer information indicates the number of empty buffers capable of storing data among the plurality of buffers. 3. The data transfer method according to claim 2, wherein the specific data is transferred when the number of empty buffers is a predetermined number or less. 4. The data transfer method according to claim 2 , wherein the specific data is transferred when the number of empty buffers is one. The first data and the second data, the data transfer method according to any one of claims 1 to 4, characterized in that it comprises an image data to be transferred by the command for transferring the image data. The specific data, the data transfer method according to any one of claims 1 to 5, characterized in that a command for transferring the dummy data that do not contain data to be stored in the buffer. The specific data, the data transfer method according to any one of claims 1 to 5, characterized in that a transfer control command for performing a dummy transfer control. A fourth transfer step of transferring third data for obtaining status information of the target device from the host device to the target device when the free capacity indicated by the buffer information is not larger than a predetermined capacity;
  8. The method according to claim 1, further comprising a third return step of returning buffer information indicating the free space of the buffer from the target device to the host device as a response to the third data. The data transfer method described.   9. The data transfer method according to claim 8, wherein the third data is a command for acquiring status information of the target device. Wherein the time until a response in response to one transfer of certain data is returned, claims 1 to, characterized in longer than if sent back a response in accordance with the transfer of the first data 10. The data transfer method according to any one of 9 . 6. The data transfer method according to claim 5 , wherein a command and data are written into a register when the first data and the second data are transferred. 12. The data transfer method according to claim 11, wherein responses to the first data and the second data are returned in response to writing to the register.   13. The data transfer method according to claim 1, wherein the serial bus is a bus conforming to or conforming to the IEEE 1394 standard, or a bus conforming to or conforming to the USB standard. A data receiving device,
  A buffer to store the data,
  First receiving means for receiving first data to be stored in the buffer from a host device;
  First transmission means for transmitting buffer information indicating a free capacity of the buffer to the host device as a response to the first data;
  Second receiving means for receiving specific data from the host device when the free capacity indicated by the buffer information is not larger than a predetermined capacity;
  Second transmission means for transmitting buffer information indicating a free capacity of the buffer to the host device as a response to the specific data without storing the specific data in the buffer;
  After receiving the specific data from the host device, if the free capacity indicated by the buffer information is larger than a predetermined capacity, a third reception for receiving second data to be stored in the buffer from the host device Means,
  The host device transfers the specific data to the data receiver when the free capacity indicated by the buffer information is not larger than a predetermined capacity. A data transfer device,
  First transfer means for transferring first data to be stored in a buffer of the target device to the target device;
  First receiving means for receiving, from the target device, buffer information indicating a free capacity of the buffer as a response to the first data;
  A second transfer means for transferring specific data to the target device when the free capacity indicated by the buffer information is not larger than a predetermined capacity;
  Second receiving means for receiving, from the target device, buffer information indicating a free space of the buffer as a response to the specific data;
  After the specific data is transferred to the target device, if the free capacity indicated by the buffer information is larger than a predetermined capacity, the third data to be stored in the buffer is transferred to the target device. Transfer means,
  The target device, without storing the specific data in the buffer, transmits buffer information indicating a free capacity of the buffer to the data transfer device as a response to the specific data. . A data transfer device that communicates with an external device that stores a transferred image data in a buffer and transmits a response,
Receiving means for receiving a response including buffer information relating to the free space of the buffer from the external device;
Image data transfer means for transferring image data to the external device when the free space of the buffer indicated by the buffer information is larger than a predetermined value;
Command transfer means for interrupting the transfer of image data by the image data transfer means and transferring a specific command to the external device when the free space of the buffer indicated by the buffer information is not larger than a predetermined amount. ,
The external device transmits a response including the buffer information without storing the specific command in the buffer,
After the command transfer means transfers the specific command, the image data transfer means transfers the image data to the external device when the free space of the buffer indicated by the buffer information is larger than a predetermined value. Data transfer device. A data transfer method between a first device and a second device for storing a response in which image data transferred from the first device is stored in a buffer,
Transferring image data from the first device to the second device;
Transferring a response including buffer information about free space of the buffer from the second device to the first device;
Transferring a specific command from the first device to the second device if the free space of the buffer indicated by the buffer information is not larger than a predetermined amount,
The second device transfers the response including the buffer information without storing the specific command in the buffer;
Data is transferred from the first device to the second device when the free space of the buffer indicated by the buffer information is larger than a predetermined value after the specific command is transferred. Transfer method. An image processing apparatus,
Storage means for storing image data transferred from an external device;
A transmission unit that transmits to the external device a response including storage unit information related to the free capacity of the storage unit with respect to the image data from the external device;
Receiving means for receiving a specific command from the external device;
A second transmission unit configured to transmit a response including storage unit information relating to a free space of the storage unit to the external device without storing the specific command in the storage unit; And
When the free capacity of the storage means indicated by the storage means information is larger than a predetermined value, the external device transfers image data to the image processing device, and the free capacity of the storage means indicated by the storage means information is predetermined. If not, the image processing apparatus transfers the specific command to the image processing apparatus.

Images