JP2000049833A - Data transfer device, data transfer system, its method, image processing unit and record medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To allow the data transfer system to optionally transfer commands other than data in the case that the commands and the data use same register areas and only a result of the data transfer is returned at the time of the data transfer between a host device and a target device interconnected by a serial bus. SOLUTION: A 1394 serial bus directly interconnects an image supply device 101 and a printer 102 and in the case of returning a response with respect to a data transmission command from the printer 102 to the image supply device 101, the printer 102 informs the device 101 of a re-transmission request depending on a state of a data reception buffer of the printer 102. The image supply device 101 transfers again the data transmission command to the printer 102 based on the re-transmission request and transfers a status acquisition command to the printer 102 in response to the response with respect to the command.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a data transfer apparatus, a data transfer system and method, an image processing apparatus, and a recording medium, and relates to an image supply device via a serial interface defined by, for example, IEEE1394. The present invention relates to a data transfer device, a data transfer system and a data transfer method when directly connecting to an image processing device, an image processing device, and a recording medium.

2. Description of the Related Art A printer is a personal computer (PC) as a host device through a parallel or serial interface such as Centronics or RS232C.
Is connected to

[0002] Digital equipment which is an image supply device such as a scanner, a digital still camera and a digital video camera is also connected to the PC. The image data captured by each digital device is temporarily captured to a hard disk on a PC, processed by application software on the PC, converted to print data for a printer, and passed through the above interface. And sent to the printer.

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

[0004] Today, with a new interface such as the interface defined by IEEE1394 (hereinafter referred to as "1394 serial bus"), it is also possible to directly connect an image supply device and a printer. When connecting an image supply device and a printer directly via the 1394 serial bus, the FCP
A method is considered in which print data is included in the operand of (Function Control Protocol). In the 1394 serial bus, a method of providing a register area for data transfer and writing data in the register area to perform data transfer may be considered.

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

However, the above technique has the following problems. As described above, the image data output from the image supply device is
Therefore, even if the image supply device is directly connected to the printer, printing cannot be performed without a PC. There is a printer called a video printer that prints image data output from a digital video camera directly.However, a general-purpose video printer that can only be connected between specific models and can be used directly with many image supply devices is available. Absent. That is, it is not possible to directly send image data from an image supply device to a printer and print it by utilizing a function of directly connecting devices, which is a feature of the 1394 serial bus or the like.

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

In order to solve this problem, a method of using the same register area without separating data and command can be considered. In this method, the register area used can be reduced, and a simpler data transfer method can be provided.
Further, a method of determining whether or not a register area for writing data is writable is performed, and after writing data to the register, only a response of success or failure to the writing is performed, and if there is a successful response, the next data is transferred. Is also conceivable.

Although this method has the advantage of simplifying the data transfer procedure, it has the problem that the buffer for storing the area in which data has been written becomes full on the data receiving side. When the data is written to the register and saved in its own buffer, the data receiving side immediately returns a response indicating that the data can be received. The data transfer side that has received the response indicating that the data is ready to receive attempts to immediately start the transfer of the next data. Therefore, when 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] After storing the data in the last empty buffer, the data receiving side cannot return an acceptable response to the data sending side until the processing proceeds and an empty buffer is created. In this case, since the same register area is used for the command and the data, during execution of the command for transferring data, if there is no free space in the buffer on the data receiving side, commands other than data transfer cannot be executed.

This means that when a printer is considered as the data receiving side, there are cases where a command for obtaining the status of the printer (out of paper, error, etc.) can be executed during data transfer and cases where it cannot be executed. That is, the command can be executed when there is an empty buffer in the printer and a command for obtaining status can be received. However, when there is no empty buffer, the command cannot be executed or the command is kept waiting until an empty buffer is created. Therefore, a problem arises particularly when performing status acquisition that requires real-time processing. In addition, there is a problem that it is difficult to determine whether the status is at the required time.

In addition, since the response to the transfer is performed in a substantially fixed short time after transferring the data, the amount of data flowing on the data bus increases, and there is a problem in that the bus is effectively used.

In the case where the data transfer is instructed by using the command for instructing the start of the data transfer and the response to the command, the exchange of the command and the response occurs for each unit of data transfer. There is a problem that the efficiency is reduced.

The present invention is to solve the above-mentioned problems individually or collectively. The present invention relates to a method of connecting a host device and a target device by a 1394 serial bus or the like and transferring data sent from the host device to the target device. A data transfer device, a data transfer system, and a method capable of arbitrarily executing a command other than data transfer when using the same register area for command and data and only responding to writing of data to the register; It is an object to provide an image processing device and a recording medium.

Further, it is an object of the present invention to provide a data transfer device, a data transfer system and a method thereof, an image processing device, and a recording medium which realize efficient traffic on a data bus by adjusting a response time to the data transfer. With the goal.

[0015]

The present invention has the following configuration as one means for achieving the above object.

A data transfer method according to the present invention is a data transfer method used between a host device and a target device connected by a serial bus.
Data is continuously transferred in units of a predetermined size,
The first data, if necessary, together with the result of the predetermined number of data transfers.
The first data is retransmitted based on the retransmission request, and the second data is transmitted during the retransmission of the first data.

Further, a data transfer device according to the present invention comprises:
A data transfer device connected by a serial bus, comprising: communication means for transferring data in a predetermined size unit with a host device; and transmitting a request for retransmission of the data as necessary together with a result of the data transfer to the host. A reply unit for replying to the device, wherein the communication unit receives first data continuously transferred from the host device in the predetermined size unit, and the reply unit includes the first data unit. The communication unit returns a data reception result to the host device together with the retransmission request, and the communication unit further receives the first data transferred from the host device based on the retransmission request again, further comprising: The second data is received while the first data is being received again.

Further, the data transfer system according to the present invention is a data transfer system for transferring data via a serial bus. Replying means for returning a retransmission request of the data in accordance with the above, wherein the communication means transfers the first data continuously in units of the predetermined size, and the reply means transmits the first data. The first data is transferred again based on a retransmission request returned with a transfer result of a predetermined number of times, and the second data is transferred during the retransmission of the first data.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, a data transfer method according to an embodiment of the present invention will be described in detail with reference to the drawings.

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

[0019]

[Overview of IEEE1394] With the advent of home digital VTRs and digital video discs (DVDs), video data and audio data (hereinafter collectively referred to as "AV data")
For example, there is a need to transfer data with a large amount of information in real time. 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. 13 interfaces developed from such a viewpoint
94 serial bus.

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

The connection between the devices can be a mixture of the daisy chain method and the node branch method, and a highly flexible connection can be made. Each device has an ID, and recognizes each other to form one network within a range connected by a 1394 serial bus. For example, a single 13
By simply daisy-chaining with a 94 serial bus cable, each device plays the role of relay, so that one network can be configured as a whole.

The 1394 serial bus uses Plug and Play.
It has a function that automatically recognizes the device by simply connecting the 1394 serial bus cable to the device and recognizes the connection status. Also, in the system shown in FIG. 2, when a device is removed from the network or newly added, the bus is automatically reset (the network configuration information up to that point is reset) and the bus is automatically reset. Rebuilding a good network. With this function, the configuration of the network at that time can be constantly set and recognized.

The data transfer speed of the 1394 serial bus is defined as 100/200/400 Mbps, and the device having the higher transfer speed supports the lower transfer speed.
Compatibility is maintained. As the data transfer mode, asynchronous (A
synchronous) transfer mode (ATM) and synchronous (Isochronous) transfer mode for transferring synchronous data such as real-time AV data. In each cycle (usually 125 μs / cycle), the asynchronous data and synchronous data follow the transfer of the cycle start packet (CSP) indicating the start of the cycle,
Synchronous data is transferred in a mixed manner within a cycle while giving priority to the transfer of the data.

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 a connector at the end of a cable 813 for a 1394 serial bus. Above the connector port 810, the hardware section 8
00 physical layer 811 and link layer 812
There is. The hardware unit 800 is configured by an interface chip, of which the physical layer 811 performs coding and connection-related control and the like, and the link layer 812 performs packet transfer and cycle time control and the like.

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

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

FIG. 4 is a diagram showing an example of an address space in the 1394 serial bus. Each device (node) connected to the 1394 serial bus must have a unique 64-bit address for the node. This address is stored in the memory of the device, and by constantly recognizing the node address of itself or the other party, it is possible to perform data communication specifying the other party.

The addressing of the 1394 serial bus is based on the IE
The address is set according to the EE1212 standard. In the address setting, the first 10 bits are used for specifying a bus number, and the next 6 bits are used for specifying a node ID.

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

The first 512 bytes of the register space have a CSR
The register (CSR core), which is the core of the architecture,
The next 512 bytes contain serial bus registers, the next 1024 bytes contain configuration ROMs, and the rest contain unit-specific registers in unit space.

In general, to simplify the design of heterogeneous bus systems, nodes should use only the first 2048 bytes of the initial unit space, resulting in the CSR core, serial bus registers, configuration ROM and It is desirable that the first 2048 bytes of the unit space be composed of 4096 bytes.

The above is the outline of the 1394 serial bus.
Next, the 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 is a diagram showing a cross section of a cable for the 1394 serial bus. The 1394 serial bus cable has a power supply line in addition to the two twisted pair signal lines. As a result, power can be supplied to a device having no power supply or a device whose voltage has been reduced due to a failure or the like. The voltage of DC power supplied by the power line is 8 ~ 40V,
The current is specified at a maximum current of 1.5A. In the standard called DV cable, it is composed of four wires omitting a power supply line. [DS-Link System] FIG. 6 is a diagram for explaining a DS-Link (Data / Strobe Link) system of a data transfer system adopted in a 1394 serial bus.

The DS-Link system is suitable for high-speed serial data communication and requires two sets of signal lines. In other words, the data signal is transmitted by one of the two pairs of twisted pairs, and the strobe signal is transmitted by the other pair. The receiving side has a feature that a clock can be generated by taking an exclusive OR of this data signal and the strobe signal. Therefore, when using the DS-Link method, there is no need to mix a clock signal into the data signal, so transfer efficiency is higher than other serial data transfer methods, and a clock signal can be generated, so a phase locked loop (PLL)
The circuit becomes unnecessary, and the circuit size of the controller LSI can be reduced accordingly. Further, since there is no need to send information indicating the idle state when there is no data to be transferred, the transceiver circuit of each device can be put into the 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.
Recognized as nodes that make up the network. For example, when the number of nodes increases or decreases due to connection / disconnection of network devices or power on / off, that is, there is a change in the network configuration, and when it is necessary to recognize a new network configuration, each node that detects the change will be To a mode for recognizing a new network configuration. The detection of the change in the network configuration is performed by detecting a change in the bias voltage at the connector port 810.

When a bus reset signal is transmitted from a certain node, the physical layer 811 of each node transmits the bus reset signal to the link layer 812 at the same time as receiving the bus reset signal, and transmits the bus reset signal to another node. To communicate. After all the nodes finally receive the bus reset signal, the bus reset sequence is started. Note that the bus reset sequence is started when a cable is connected or disconnected, or when hardware detects a network error or the like, and is also provided by directly giving an instruction to the physical layer 811 such as host control using a protocol. Is activated. When the bus reset sequence is activated, the data transfer
The bus is temporarily suspended, waited during the bus reset, and resumed under the new network configuration after the bus reset is completed. [Sequence of Node ID Determination] After the bus reset, each node starts an operation of giving an ID to each node in order to construct a new network configuration. The general sequence from the bus reset to the determination of the node ID at this time will be described with reference to the flowcharts shown in FIGS. FIG.
9 is a flowchart illustrating a series of sequence examples from generation of a bus reset signal to determination of a node ID and data transfer. Each node performs step S101
In step S102, when a bus reset signal is generated, the process proceeds to step S102.In order to obtain a new network configuration in a state where the network configuration is reset, a parent-child relationship between nodes directly connected to each other is established. Declared. Then, according to the determination in step S103,
Step S102 is repeated until it is determined that the parent-child relationship has been determined between all the nodes.

When the parent-child relationship is determined, the process proceeds to step S104, where the 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 from the root node to the specified node,
Step S105 is repeated until it is determined in step S106 that IDs have been assigned to all nodes.

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

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). FIG. 9 is a flowchart showing a detailed example of the node ID setting (S105, S106).

In FIG. 8, the generation of a bus reset signal is monitored in step S201, and when the bus reset signal is generated, the network configuration is reset once. Next, in step S202, as a first step of re-recognizing the reset network configuration, each device resets the flag FL with data indicating a leaf node. Then, in step S203, each device checks the number of ports, that is, the number of other nodes connected to itself, and in step S204,
In accordance with the result of step S203, the number of undefined (parent-child relationship is not determined) ports is checked in order to start declaring the parent-child relationship. Here, the number of undefined ports is
Immediately after the bus reset, the number of ports is equal to the number of ports. However, as the parent-child relationship is determined, the number of undefined ports detected in step S204 decreases.

Only the actual leaf node can declare the parent-child relationship immediately after the bus reset. Whether the node is a leaf node can be known from the result of checking the number of ports in step S203. That is, if the number of ports is "1", the node is a leaf node. Leaf node, step S205
Then, a parent-child relationship declaration is made for the connection partner node, "I am a child, and the partner is a parent," and the operation ends.

On the other hand, the node whose port number is “2 or more” in step S203, that is, the branch node, immediately after the bus reset, has “undefined port number> 1”, so the process proceeds to step S206, where the branch to flag FL is performed. The data indicating the node is set, and the process waits for the declaration of the parent-child relationship from another node in step S207. A parent-child relationship is declared from another node,
The branch node receiving it returns to step S204 and checks the number of undefined ports, but if the number of undefined ports is “1”, the other nodes connected to the remaining ports are checked in step S205. You can declare a parent-child relationship of "I am a child and my partner is a parent." Further, the branch node having the number of undefined ports “2 or more” is determined in step S207.
And wait for another node to declare the parent-child relationship again.

If the number of undefined ports of any one of the branch nodes (or, in exceptional cases, a leaf node that could not be operated quickly despite being able to make a child declaration) becomes “0”, the parent-child relationship of the entire network is reached. Is the only node for which the number of undefined ports has become "0", that is, the node that has been determined to be the parent of all nodes, sets data indicating the root node to the flag FL in step S208, In step S209, it is recognized as a root node.

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

Next, a procedure for assigning an ID to each node will be described. First, an ID can be set at a leaf node. Then, an ID is set in the order of leaf → branch → root in ascending order (node number: 0).

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

First, in the case of a leaf node, step S302
After setting the number (natural number) of leaf nodes existing in the network in the variable N, in step S303, each leaf node requests a node number from the root node.
If there are multiple requests, the root node determines in step S304
In step S305, a node number is given to one node, and the other nodes are notified of a result indicating that acquisition of the node number has failed.

The leaf node from which the node number could not be obtained by the determination in step S306 repeats the request for the node number in step S303 again. On the other hand, in step S307, the leaf nodes that have been able to obtain the node numbers notify all the nodes by broadcasting ID information including the obtained node numbers. When the broadcast of the ID information ends, in step S308, the variable N indicating the number of leaves is decremented. Then, the procedure of steps S303 to S308 is repeated until the variable N becomes “0” by the determination of step S309, and after the ID information of all leaf nodes has been broadcasted, the process proceeds to step S310, where the branch node
Move on to ID setting.

The setting of the ID of the branch node is performed in substantially the same manner as that of the leaf node. First, in step S310, the number (natural number) of branch nodes existing in the network is set as a variable M
After that, in step S311, each branch node requests a node number from the root node. In response to this request, the root node performs arbitration in step S312, assigns a small number following the leaf node to one branch node in step S313, and indicates that the branch node that could not obtain the node number indicates an acquisition failure Notify.

The branch node that has determined that the acquisition of the node number has failed by the determination in step S314 repeats the request for the node number again in step S311. On the other hand, in step S315, the branch node that has obtained the node number
All nodes are notified by broadcasting ID information including the acquired node number. When the broadcast of the ID information ends, in step S316, a variable M representing the number of branches
Is decremented. Then, according to the determination in step S317, the procedure from steps S311 to S316 is repeated until the variable M becomes “0”, and after the ID information of all branch nodes is broadcast, the process proceeds to step S318, where the ID of the root node is Move on to settings.

At this point, since the root node is the only node that has not finally obtained an ID, step S3
At 18, the lowest number not assigned to other nodes is set as its own node number, and at step S319 the root node
Broadcast ID information.

Thus, the procedure up to setting the IDs of all the nodes is completed. Next, a specific procedure of a sequence for determining a node ID will be described using the network example shown in FIG.

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

After the occurrence of the bus reset, a parent-child relationship is declared between the directly connected ports of each node in order to recognize the connection status of each node. Here, the parent and child means that the upper level of the hierarchical structure is “parent” and the lower level is “child”. In FIG. 10, it is the node A that first declared the parent-child relationship after the bus reset. As described above, the declaration of the parent-child relationship can be started from a node (leaf) to which only one port is connected. This means that if the number of ports is "1", the end of the network tree, that is, the leaf node is recognized, and the parent-child relationship is determined from the node that operates first among those leaf nodes. Become. In this way, the port of the node that has declared the parent-child relationship is set as the “child” of the two nodes connected to each other, and the node of the partner node is set as the “parent”.
Is set. Thus, between nodes AB, between nodes ED,
A "child-parent" relationship is set between the nodes FD.

Further, the hierarchy goes up by one, and a node having a plurality of ports, that is, a node having a parent-child relationship declared by another node among branch nodes is sequentially declared a parent-child relationship with an upper node. In Figure 10, first the node
After the parent-child relationship between DE and DF is determined, node D declares a parent-child relationship to node C, and as a result, node DC
A "child-parent" relationship is set between them. Node C, which has received a parent-child relationship from node D, declares a parent-child relationship to node B connected to another port, thereby establishing a "child-parent" relationship between nodes CB. You.

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

When the root node is determined, each node ID
Enter the decision mode. All nodes have a broadcast function of notifying the determined ID information to all other nodes. Note that the ID information is broadcast as ID information including a node number, information on a connected position, the number of ports having the number, the number of connected ports, information on the parent-child relationship of each port, and the like.

The assignment of the node numbers starts from the leaf nodes as described above, and the node numbers = 0, 1, 2,.
Is assigned. Then, by broadcasting the ID information, it is recognized that the node number has been assigned.

When all the leaf nodes have obtained the node numbers, the process moves to the branch node, and the node numbers following the leaf nodes are assigned. Like the leaf node, the branch node to which the node number is assigned is
The ID information is broadcast, and finally the root node broadcasts its own ID information. Therefore, the root node always owns the highest node number.

As described above, the ID setting of the entire hierarchical structure is completed, the network configuration is constructed, and the bus initialization operation is completed. [Control Information for Node Management] As a basic function of the CSR architecture for performing node management, the CSR core shown in FIG. 4 exists on a register. The locations and functions of these registers are shown in Figure 11, where the offset is 0xFFFF
This is a relative position from F0000000.

In the CSR architecture, 0xFFFFF0000200
And registers related to the serial bus.
FIG. 12 shows the locations and functions of these registers.

In the place starting from 0xFFFFF0000800, information on the node resources of the serial bus is arranged. FIG. 13 shows the positions and functions of these registers.

Although the CSR architecture has a configuration ROM to represent the function of each node,
This ROM has a minimum format and a general format, 0xFFFFF000040
Arranged from 0. In the minimum format, only the vendor ID is represented as shown in FIG. 14, and this vendor ID is a globally unique value represented by 24 bits.

The general format is a format as shown in FIG. 15 and has information on nodes. In this case, the vendor ID can be stored in a root directory (root_directory). Also, a bus info block
And the root leaf have a 64-bit globally unique device number, including the vendor ID. This device number is used for continuously recognizing a node after a reconfiguration such as a bus reset. [Serial Bus Management] As shown in FIG. 3, the protocol of the 1394 serial bus is composed of 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.

A node that performs bus management (hereinafter, referred to as a “bus management node”) exists solely on the same bus and provides a management function to other nodes on the serial bus. Control, performance optimization, power management, transmission speed management, configuration management, etc.

The bus management function is roughly divided into three functions: a bus manager, a synchronous (isochronous) resource manager, and a node control. Node control is CS
R is a management function that enables communication between nodes in the physical layer 811, the link layer 812, the transaction layer 814, and the application. The synchronous resource manager is a management function necessary for performing synchronous data transfer on the serial bus, and manages the transfer bandwidth of synchronous data and the assignment of channel numbers. To perform this management, a bus management node is dynamically selected from nodes having a synchronous resource manager function after the bus is initialized.

In a configuration in which a bus management node does not exist on a bus, a node having a synchronous resource manager function performs a part of the bus management such as power management and cycle master control. Further, the bus management is a management function for providing a service of providing a bus control interface to an application.The control interface includes a serial bus control request (SB_control.request) and a serial bus event control confirmation (SB _Control.confirm
ation), serial bus event notification (SB_EVENT.indicati
on).

The serial bus control request is used when an application requests the bus management node for bus reset, bus initialization, bus status information, and the like. The serial bus event control confirmation is notified to the application from the bus management node as a result of the serial bus control request. The serial bus event notification is for notifying an event generated asynchronously from the bus management node to the application. [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 and reception at an arbitrary timing exist simultaneously.
In addition, the real-time property of the synchronous data is guaranteed. In data transfer, prior to the transfer, a bus use right is requested, and bus arbitration for obtaining a bus use permission is performed.

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

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

These data transfer protocols are defined by three layers: a physical layer 811, a link layer 812, and a transaction layer 814. The physical layer 811 performs a physical / electrical interface with a bus, automatic recognition of node connection, bus arbitration of a bus use right between nodes, and the like. Link layer 81
2 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, the bus arbitration in the physical layer 811 will be described.

The 1394 serial bus always performs arbitration of the right to use the bus prior to data transfer. 13
94 Each device connected to the serial bus forms a logical bus network that transmits the signal to all devices in the network by relaying the signals transmitted on the network. Bus arbitration is necessary in order to prevent this. This allows only one node to transfer at a given time.

FIG. 16 is a diagram for explaining a request for the right to use the bus.
FIG. 17 is a diagram illustrating permission to use a bus. When the bus arbitration starts, one or a plurality of nodes respectively request the right to use the bus toward the parent node.
In FIG. 16, nodes C and F request a bus use right. The parent node that received this request (the node
A) further requests the right to use the bus toward the parent node, thereby relaying the request for the right to use the bus by the node F. This request is finally delivered to the arbitrating root node.

The root node that has received the request for the right to use the bus determines which node is to be given the right to use the bus. This arbitration work can be performed only by the root node, and the node that wins the arbitration is given permission to use the bus. FIG. 17 shows a state in which the node C is given a bus use permission, and the node F request for the bus use right is rejected.

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

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

In order for a node to be able to start data transfer, the bus must be idle. In order to confirm that the data transfer started earlier has been completed and the bus is currently in an idle state, a predetermined idle time gap length (for example, a subaction gap) that is individually set in each transfer mode is required. , And when a predetermined gap length is detected, each node determines that the bus is in an idle state. Each node performs step S4
At 01, it is determined whether or not a predetermined gap length corresponding to data to be transferred, such as asynchronous data and synchronous data, has been detected. Unless a predetermined gap length is detected, it is not possible to request the necessary bus right to start the transfer.

When a predetermined gap length is detected in step S401, each node determines whether there is data to be transferred in step S402, and if so, in step S403, routes a signal requesting the right to use the bus to the root. Make an outgoing call. The signal indicating the request for the right to use the bus is finally delivered to the root node while being relayed to each device in the network, as shown in FIG. If it is determined in step S402 that there is no data to be transferred, the process returns to step S401.

When the root node receives at least one signal requesting the right to use the bus at step S404, the root node proceeds to step S4.
Check the number of nodes that requested the usage right in 05. Step S4
As a result of the determination at 05, if there is only one node that has requested the right to use, that node is given the bus use permission immediately after that. If there are a plurality of nodes that have requested the use right, an arbitration operation is performed in step S406 to immediately reduce the number of nodes to which the bus use permission is immediately made to one. This arbitration work does not always grant the bus use permission only to the same node, but equally gives the bus use permission (fair arbitration).

The processing of the root node is as follows in step S407.
The process branches depending on one node that has won the arbitration in step S406 and another node that has lost the arbitration. If one node has won the arbitration or one node has requested the right to use the bus, a permission signal indicating permission to use the bus is sent to the node in step S408. The node receiving this permission signal starts transferring data (packet) to be transferred immediately (step S41).
0). In addition, the node that has lost the arbitration indicates in step S409 that the request for the right to use the bus has been rejected.
A DP (data prefix) packet is sent. The processing of the node that has received the DP packet returns to step S401 again to request the right to use the bus. The process of the node that has completed the data transfer in step S410 also returns to step S401. [Transaction Layer] There are three types of transactions: read transactions, write transactions, and lock transactions.

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

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 FIG. Is a unit.

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) sends an acknowledgment, and a transaction confirmation (TR_DATA.confirmation) receives an acknowledgment It is. [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, and a link notification (LK_DA) for notifying the response node of packet reception.
TA.indication), link response of acknowledgment transmission from response node (LK_DATA.response), link confirmation of acknowledgment transmission of request node (LK_DATA.confirm
ation) service unit. One packet transfer process is called a subaction, and there are two types of asynchronous subactions and synchronous subactions. Hereinafter, the operation of each sub-action will be described. [Asynchronous subaction] An asynchronous subaction is an asynchronous data transfer. FIG. 21 is a diagram showing temporal transition in asynchronous transfer. The first sub-action gap shown in FIG. 21 indicates the idle state of the bus.
When the idle time reaches a predetermined value, a node desiring data transfer requests a bus use right, and bus arbitration is executed.

When the use of the bus is permitted by the bus arbitration, the data is then transferred to a packet, and the node that has received the data returns a return code ACK for acknowledgment after a short gap called an ACK gap. Alternatively, the data transfer is completed by returning the response packet. The ACK is composed of 4-bit information and a 4-bit checksum, and includes information indicating success, busy status, or pending status, and is immediately returned to the data transmission source node.

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

The asynchronous transfer is one-to-one communication from the transmitting node to the receiving node. The packet sent from the source node is distributed to each node in the network, but each node ignores packets other than its own, so that only the node designated as the destination receives the packet. [Split Transaction] The service in the transaction layer 814 is performed by a set of a transaction request and a transaction response shown in FIG. Here, if the processing in the link layer 812 and the transaction layer 814 of the target (response node) is sufficiently fast, the request and the response are not processed by independent subactions of the link layer 812, but are processed by one subaction. It becomes possible. However, if the processing speed of the target is slow, it is necessary to process the request and response in separate transactions. This operation is called a split transaction.

FIG. 23 is a diagram showing an example of the operation of the split transaction. In response to a write request from the controller of the initiator (request node), the target returns pending. As a result, the target can return confirmation information for the write request from the controller, and can gain time for processing the data. And
After sufficient time for data processing, the target
A write response is notified to the controller to end the write transaction. At this time, the operation of the link layer 812 by another node is possible between the request and the response sub-action.

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

In sub-action 1, the initiator sends a data packet indicating a write request to the target, and upon receiving the data packet, the target returns the above-mentioned pending indicating the confirmation information by an acknowledge packet, thereby completing the request sub-action.

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

The minimum time from the end of sub-action 1 to the start of sub-action 2 is a time corresponding to the sub-action gap, and the maximum can be extended to the maximum waiting time set in the node. . [Synchronous sub-action] Synchronous transfer, which can be said to be the largest feature of the 1394 serial bus, is particularly suitable for transfer of data that requires real-time transfer such as AV data. Also, while asynchronous transfer is one-to-one transfer, this asynchronous transfer is performed by the broadcast function.
Data can be transferred uniformly from one source node to all other nodes.

FIG. 25 is a diagram showing a temporal transition in the synchronous transfer. The synchronous transfer is executed at fixed time intervals on the bus, and this time interval is called a synchronous cycle. The synchronization cycle time is
125 μs. A cycle start packet (CSP) 2000 indicates the start of the synchronization cycle and synchronizes the operation of each node. The node that transmits CSP2000 is a node called the cycle master. After the transfer in the previous cycle has been completed and a predetermined idle period (subaction gap 2001) has passed, CSP2000 indicating the start of this cycle is transmitted. I do. That is, the time interval at which the CSP2000 is transmitted is 125 μS.

Also, as shown in FIG. 25 as channel A, channel B and channel C, by assigning channel IDs to a plurality of types of packets in one synchronization cycle, it is possible to transfer these packets in a distinguished manner. it can. Thereby, real-time transfer can be performed substantially simultaneously between a plurality of nodes, and the receiving node need only 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. Therefore,
Certain transmitted packets will be broadcast from one source node to all other nodes, ie, broadcast.

Prior to packet transmission by synchronous transfer, bus arbitration is performed as in asynchronous transfer. However, since it is not one-to-one communication as in asynchronous transfer, there is no ACK of a return code for acknowledgment in synchronous transfer.

The 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 detects the predetermined idle period determines that the bus is in the idle state, and requests the right to use the bus when performing synchronous transfer, so that bus arbitration is performed.

FIG. 26 is a diagram showing an example of a packet format for synchronous transfer. Each packet divided into each channel has a data part and data for error correction.
In addition to the CRC, there is a header, in which the transfer data length, channel number, other various codes, a header CRC for error correction, and the like are written as shown in FIG. [Bus cycle] In the 1394 serial bus, synchronous transfer and asynchronous transfer can be mixed. FIG. 28 is a diagram showing a temporal transition of a transfer state when synchronous transfer and asynchronous transfer are mixed.

Here, as described above, synchronous transfer is executed prior to asynchronous transfer. The reason is that after CSP,
This is because synchronous transfer can be started with a gap (isochronous gap) shorter than the idle period gap (subaction gap) required to start asynchronous transfer. Therefore, synchronous transfer is performed with priority over asynchronous transfer.

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

After the operations from the bus arbitration to the packet transfer are repeatedly performed for the given channel, when all the synchronous transfers in cycle #m are completed, the asynchronous transfer can be performed. That is, when the idle time reaches a subaction gap where asynchronous transfer is possible, a node that wants to perform asynchronous transfer participates in bus arbitration. However, asynchronous transfer can be performed only when a sub-action gap to start asynchronous transfer is detected between the end of synchronous transfer and the time to transfer the next CSP (cycle synch). .

In a cycle #m shown in FIG. 28, after synchronous transfer for three channels, two packets (packet 1 and packet 2) including ACK are transferred by asynchronous transfer. After the asynchronous packet 2, the time to start the cycle m + 1 (cycle synch) is reached, and the transfer in the cycle #m ends here. However, if it is time to send the next CSP during asynchronous or synchronous transfer (cycle synch), the transfer will not be forcibly interrupted, and after the transfer is completed, the CSP of the next synchronous cycle will be sent after an idle period. I do. That is, when one synchronization cycle lasts for 125 μs or more, the next synchronization cycle is shortened by the extension from the reference 125 μs. In this way, the synchronization cycle exceeds 125 μs,
It can be shortened.

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

[0101]

[Data transfer processing] [Data transfer protocol]
FIG. 3 is a diagram for explaining a protocol stack for data transfer on a 1394 serial bus.

Applications often need to exchange large amounts of data, such as image data, between devices. In such a case, provide a reliable data transfer service to the application in order to separate the details of hardware technology related to data transfer, restrictions, processing of error re-transfer of data, etc. from the application program. It is necessary to define a generic interface.

Therefore, in this embodiment, when the application program performs data transfer, a hierarchical protocol system as shown in FIG. 29 is used. Figure 29
Are the application layer 29-1, the session layer 29-2, the transaction layer 29-3, and the IE
1394 transaction layer 29-4 defined by EE1394,
14 shows the 1394 physical layer 29-5. Here, the 1394 transaction layer 29-4 corresponds to the above-described transaction layer 814 shown in FIG. 3, and the 1394 physical layer 29-5 corresponds to the link layer 812 and the physical layer 811.

In the present embodiment, the device transmitting data operates as follows. First, the data transfer application 29-1 transfers a large amount of data such as image data,
The data is passed 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 the divided data 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. 1394 transaction layer 29-4 and 1394 physical layer 29-5
Transfers the divided application data to another device by means defined in IEEE1394.

The device receiving the data operates as follows. Appropriately divided data transferred from the transmission side is transmitted to the 1394 physical layers 29-5 and 13
94 The data is sequentially written into the block register 30-3 of the data receiving device defined by the transaction layer 29-3 by the transaction layer 29-4. The transaction layer 29-3 reconstructs the data sequentially written to the block register 30-3, assembles the data in units of one block register, and transfers the data to the upper session layer 29-2. The session layer 29-2 sequentially receives the data in units of one block register, reconstructs the data in the form of a data stream, and transfers the data stream to the application 29-1. The data receiving side application 29-1 receives a large amount of data such as image data from the data transmitting side device via the abstracted interface. [Register configuration] FIG. 30 shows the transaction layer of FIG.
29-3 is a diagram showing a register configuration for performing data transfer between devices, which is arranged in an initial unit space (shown as a unit space in FIG. 4) of the 1394 serial bus.
Prior to performing data transfer, the device knows in advance the address and size where the transfer destination register is located, and uses these registers to perform data transfer. The registers are the block register 30-3 to write the actual data and the write control to the block register 30-3
Control register for (write completion notification)
30-1 and a response register 30-2 for responding to the write completion notification to the control register 30-1 whether the written data is correct or not (ACK / NACK).
The control register 30-1 and the response register 30-2 are collectively referred to as a block management register. These registers are provided in both an image supply device that transfers image data and a printer that receives and prints image data, and can mutually transfer data.

FIG. 31 shows an outline 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 into the control register 31-4 on the printer side to notify the end of the transfer of the command data (control 31-7). The printer writes the content corresponding to ACK or NACK in the response register of the image supply device in order to reply to the image supply device whether or not the data has been normally received (response 31-8).

With the above-described procedure, the writing of the command from the image supply device to the register of the printer and the reply to the writing are performed. If the ACK response from the printer is written to the response register of the image supply device, it indicates that the command was successfully received by the printer. Indicates no. The answer is NA
In the case of CK, the image supply device needs to perform some kind of error processing such as an end processing for an error or a command retransmission processing.

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 to the block register 32-3 on the image supply device side (reply 32-9). Next, the printer writes to the control register 32-1 of the image supply device to notify the end of the reply transfer (control 32-7). The image supply device sends an AC signal to the response register 32-5 of the image supply device to respond to the printer whether or not the data has been received normally.
Write the contents equivalent to K or NACK (Response 32
-8).

By the above procedure, the reply is written from the printer to the register of the image supply device, and the reply to the writing is performed. ACK from image supply device
If the reply is written to the response register of the printer, it indicates that the reply was successfully received by the image supply device, and if a NACK is returned, the data is not correctly sent to the image supply device for some reason Indicates that If the response is a NACK, the printer needs to perform some kind of error processing such as termination processing for the error or command retransmission processing.

The procedure for transferring a command from the image supply device to the printer and the reply to the command have been described above with reference to FIGS. These are general command and reply procedures. Some commands do not require a reply. In this case, FIG.
Will not be performed. These can be determined for each command.

FIG. 33 is a diagram showing the relationship between the block register 33-1 and a buffer internally provided in the device. Multiple buffers with the same size as block register 33-1
Blockbuffer [1] to [n] (33-2 to 33-7) are prepared inside the device, and when writing to the block register 33-1, it is stored in the Blockbuffer [1] to [n]. . When writing to the block register 33-1, if there is free space in the internal buffer, save the written data in the buffer, and if there is a free buffer that can be saved next, the AC
Return K to the image supply device. When the buffer becomes full, ACK is not returned to the image supply device until an empty buffer is created after saving the last buffer.

In the image supply device, the transfer of the next command cannot be performed until an ACK is returned because a buffer space is made available on the printer side. The buffer in the printer can be vacant if the data to be printed is, for example, the data in Blockbuffer [1] is converted into data for printing, and the buffer becomes empty when all the data in the buffer is processed. Then, the data written in the block register 33-1 can be stored again.

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 indicates BLOCK COMPLETE, that is, indicates that writing to the block register is completed.

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, after BLOCK COMPLETE has been written to the control register 30-1, it indicates that the data has been received correctly, and if it is 02h, it indicates BLOCK NACK. , That is, the control register 30
Indicates that data was not received correctly after BLOCK COMPLETE was written to -1.

By using these control command and response command, it is possible to notify the completion of writing data to the block register and to respond to it.

FIG. 35 is a diagram showing a general format of a command written in the block register 30-3. The command is composed of CommandID 35-1 as its identifier and Parameter 35-2 attached to the command.

FIG. 36 is a diagram showing an example of an actual command. In the figure, the left side is a command (SEND command) for transferring image data, and the Command ID is SEND (36-
1), and as the Parameter, I which is the image data to be transferred
It has mage Data (36-2). With this command, image data for printing from the image supply device to the printer can be transferred.

On the right side of FIG. 36 is a command (GETSTATUS command) for the image supply device to receive status indicating the status of the printer from the printer.
Is GETSTATUS (36-3), and has no Parameter. That is,
The GETSTATUS command does not require a Parameter.

These commands correspond to the commands 31-9 in FIG.
Is transferred from the image supply device to the printer. 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.

FIG. 37 is a diagram showing a reply to the command shown in FIG. In the figure, the left side is a reply to the 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.
Indicates SEND reply 37-1 and command execution status
Consists of SEND reply status 37-2.

The right side of FIG. 37 is a reply to the GETSTATUS command. This reply returns the status of the printer from the printer to the image supply device in response to the GETSTATUS command.

These replies correspond to the replies 32-9 in FIG.
Is transferred from the printer to the image supply device.

By the commands and replies shown in FIGS. 36 and 37, the application of the image supply device shown in FIG. 29 issues a print request by transferring image data to the printer application and obtains the status of the printer. Becomes possible.

FIG. 38 is a diagram showing the details of the printer status 38-1 returned by the GETSTATUS reply in FIG. 37. For example, the printer status 38-1 can have status such as no paper, error, or busy. The image supply device can know the current state of the printer from this status. For example, the image supply device can be notified that the printer has run out of paper, and in this case, the user of the image supply device can be notified of the fact. Further, when an error occurs in the printer, it is possible to perform control so that printing is not performed.

FIG. 39 shows image data 39 by the SEND command.
This shows a case where the size of the image data 39-1 is large with respect to the block register 31-3 when sending -1. In this case, since the data cannot be transferred at once, the image data 39-1 as shown in FIG.
Is divided according to the size of the block register 30-3 and transferred as a plurality of commands 39-2 to 39-5. This process
This 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, Writ
eBlock will be executed multiple 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.

The image data that is WriteBlock controlled by the session layer 29-2 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. Is done. That is, on the 1394 serial bus, the data transfer in the unit of the 1394 transaction 39-6 is performed a plurality of times, whereby the image data is written to all the areas of the block register 31-3. [General Data Transfer Control] FIG. 40 is a diagram showing a general control procedure of an image supply device and a printer when Write Block is repeatedly performed. The image supply device performs WriteBlock on the printer in units of divided commands. Specifically, the SEND command is repeatedly transmitted.

First, in step S40-1, the image supply device performs a WriteBlock for writing the first command into the block register 31-6 of the printer. When the writing of the data in the block register 31-3 is completed, in step S40-2, the BLOCK COMPLETE for notifying the completion of the WriteBlock is set in the control register of the printer.
Write to 31-4.

On the other hand, the printer has a free buffer, and the command written in the block register is normal. Therefore, in step S40-3, the printer writes BLOCK ACK in the response register 31-2 to the image supply device. In this case, the response time from the occurrence of BLOCK COMPLETE to the return of BLOCK ACK is indicated by T1. Such a series of processing from WriteBlock to BLOCK ACK (steps S40-1 to S40-3)
Thereby, the transfer in one block unit is completed. Thereafter, as shown in steps S40-4 to S40-6, WriteBlock is repeated until there is no free buffer in the printer.

The printer consumes the data sent in accordance with the printing operation, empties 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 free buffer, so the WriteBlock for the final buffer of the printer shown in step S40-7 is performed.
This is because the image supply device does not have information such as the remaining number for the buffer of the printer, and therefore immediately executes the WriteBlock when the BLOCK ACK is returned. The figure
Numeral 40 indicates a case where the printer has n buffers.

In step S40-7, WriteBlock is performed on the final buffer, and in step S40-8, BLOCK C is executed.
When OMPLETE is transferred, this transfer fills up the printer buffer, so that the printer cannot transfer the BLOCK ACK to the image supply device until the buffer becomes available. Therefore, usually BLOCK COMPLETE to BLOC
The response time until K ACK was T1, whereas the image supply device could not transfer data during T2 time until the buffer became empty. Then, after T2 has elapsed and BLOCK ACK is returned from the printer, the image supply device can transfer the next data. That is, the response time is T2, which is much longer than T1.

FIG. 41 is a diagram showing a control procedure of the GETSTATUS command in the present embodiment, and shows a flow of processing when the GETSTATUS command is executed during the transfer of image data by the SEND command.

If it is necessary to take the status of the printer while the WriteBlock is being repeated, the GETSTATUS
Commands are executed periodically. That is, the GETSTAUS command is executed in the middle of the SEND command. First step S4
The SEND command is executed from 1-1 to 41-6, and when a predetermined time has elapsed, the GETSTATUS command is executed in step S41-7.

Hereinafter, the GETSTATUS command control will be described in detail. First, in step S41-8, WriteBloc
k writes the GETSTATUS command to the printer's block register. Next, in step S41-9, BLOCK COMPLETE
Is written to the control register of the printer. In response to this, in step S41-10, the printer returns BLOCK ACK to the response register of the image supply device, and in step S41-11, the printer writes the GETSTATUS reply to the block register of the image supply device. Then, in step S41-12, the BLOCK COMP
LETE is written to the control register of the image supply device, and in step S41-13, a BLOCK ACK corresponding thereto is returned to the response register of the printer.

By the series of processing shown in step S41-7, G
ETSTATUS command is interrupted during SEND command. After executing the GETSTATUS command, step S41-1
In steps 4 to S41-16, the suspended SEND command is resumed. That is, the GETSTATUS command is interrupted and executed during the SEND command, and the SEND command is restarted after the GETSTATUS command is completed.

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. this
The interrupt processing of the GETSTATUS command is instructed from the application layer 29-1 shown in FIG. 29, and is processed by the session layer 29-2. That is, after the application of the image supply device instructs the session layer to send a SEND command, at a specific time, in order to obtain the status of the printer, the application sends a command to the session layer.
This means issuing a GETSTATUS command.

However, in the example shown in FIG. 41, GETSTAUS
Commands can only be executed if there is free space in the printer buffer. For example, step S40-8 in FIG.
Response time T2 that WriteBlock cannot perform, shown in ~ S40-9
If it is time to execute the GETSTATUS command during this time, there is a disadvantage that the GETSTATUS command cannot be transferred. This is because there is no empty buffer on the printer side as described above, and if the response time T2 is long, it becomes impossible to obtain the status of the printer at regular intervals. As described above, depending on the number of remaining buffers on the printer side, a problem that the printer status cannot be obtained periodically may occur.

[0137]

[Data transfer processing in this embodiment] [Summary of dummy processing] This embodiment solves the problem in the 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 FIGS. 34 and 40 are appropriately modified, and the same applies to the other drawings in FIGS. 29 to 41.

In this embodiment, the control register 30-1 and the response register 30-1 shown in FIG.
The configuration of 30-3 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 of the printer. Therefore, in this embodiment, the printer can return the BLOCK count to the image supply device in addition to the ACK / NACK for the WriteBlock.

FIG. 43 shows, in addition to the SEND command and the GETSTATUS command shown in FIG. 36 described above, a DUMMYBLOCK command (hereinafter, simply referred to as a DUMMY command) added in this embodiment. This is a command sent from the image supply device to the printer.If the number of empty blocks indicated by BLOCK count 42-3 in the response returned from the printer becomes smaller than the predetermined number, the image supply device Sent to printer in place of command. When the printer receives this DUMMY command, it does not store the data in the internal block buffers 33-2 to 33-7, and does not change the number of empty buffers to BLOCK ACK, N.
ACK is returned to the response register 31-2 of the image supply device. Thus, the DUMMY command is a command having no corresponding reply. The 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 processing shown in FIG. 40 is changed as shown in FIG. 44, and the difference lies in the following points. First, the BLOCK shown in step S40-3 in FIG.
In contrast to the ACK response, the BLOCK ACK response of step S44-3 in FIG. 44 is that a BLOCK count 42-3 indicating the number of remaining buffers is set. Further, in FIG. 40, the WriteBlock to the final buffer shown in step S40-7 and the response time T2 until the BLOCK ACK is returned in step S40-9 are in a transfer waiting state, whereas in FIG. , Step
When the BLOCK ACK is returned with the BLOCK count set to 1 in S44-9, the dummy processing in step S44-10 is performed until the BLOCK ACK is returned with the BLOCK count set to m (m is a value other than 1).

Hereinafter, the dummy processing 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 place of the SEND command in the block register of the printer. And step S4
BLOCK COMPLE notifying of completion of WriteBlock in 4-12
Write TE to 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, steps S44-13 to S4
As shown in 4-14, DU to the printer block register
Continue writing the MMY command.

When the DUMMY command is written in the block register, the printer determines that the command is a DUMMY command, and returns BLOCK ACK without storing the DUMMY command in the buffer. Therefore, since the number of free buffers at the time of reply is returned as BLOCK count, if the number of free buffers increases, the BLOCK count increases.If the number of free buffers does not increase, BLOCK count is continuously set to 1 and BLOCK ACK is returned .

In the image supply device, step S4
If a value other than 1 is set to the BLOCK count of the BLOCK ACK and returned in 4-16, in steps S44-17 to S44-22, the transfer processing of the SEND command interrupted by the dummy processing is restarted.

As described above, in the present embodiment, as shown in FIG. 44, dummy processing can be performed until the buffer on the printer side becomes empty. Therefore, even if the buffer on the printer side is full, the GETS
TATUS command can be executed. [DUMMY, GETSTATUS command control procedure] FIG. 45 shows a control procedure of the DUMMY command and the GETSTATUS command in the present embodiment. As described above, step S44- in FIG.
When the BLOCK count becomes 1 in 9, the dummy processing of the present embodiment is executed. In FIG. 45, steps
S45-5 shows the dummy processing, and step S45-8 shows the GETSTATUS command execution processing during the dummy processing. Hereinafter, the GETSTATUS command execution processing during the dummy processing in step S45-8 will be described in detail.

During the dummy processing shown in step S45-5,
When it is time for the image supply device to take in the status of the printer, the image supply device writes a GETSTATUS command (step S45-9) in place of the DUMMY command written in the block register of the printer. Note that the execution processing of the GETSTATUS command is the same as that shown in FIG.
Since it is the same as 1, the description is omitted.

Then, in step S45-11, GETSTATU
BL set in BLOCK ACK returned for S command
If the OCK count is still 1, after the execution of the GETSTATUS command processing, the DUMMY command processing is executed until the BLOCK count becomes other than 1 as shown in steps S45-15 to S45-17.

If the BLOCK count is returned to a value other than 1 in step S45-17, the process proceeds to step S45-18 and thereafter.
Processing of the SEND command is resumed as described at 44.

As described above with reference to FIGS. 44 and 45, in the present embodiment, the remaining number of buffers on the printer side can be first known, and when the remaining number becomes 1, dummy processing is performed. Is executed. During the dummy processing, since the DUMMY command is not stored in the buffer on the printer side, 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 processing. That is, in the example shown in FIG.
During T2, the GETSTATUS command could not be interrupted and issued, but in this embodiment, the GETSTATUS command is provided even if there is no free buffer due to the provision of the DUMMY command.
Commands can be issued as interrupts. The details of each processing 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, a case where the DUMMY command is sent before the first SEND command is executed. The procedure will be described.

In FIG. 46, step S46-4 is the first SEN
This is a D command, and prior to that, steps S46-1 to S46-
At 3, the DUMMY processing is performed. Thus, first DUMM
Since the buffer is not yet used by the SEND command by performing the Y command processing first, the SEND command is started because the BLOCK countn returned in step S46-3 indicates the total number of buffers held by the printer. First, the total number of buffers in the printer can be known. That is, it is possible to know the total number of buffers before starting to use the buffers.

For example, if dummy processing is executed when the printer has only one buffer, the SEND command is not executed forever, 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 not to perform dummy processing when the number of buffers in the printer is one. [Traffic Efficiency] FIG. 47 is a diagram showing a control procedure of the DUMMY command, which has been described in FIG.
Indicates that the response time of the BLOCK ACK to OMPLETE is T1. In this way, the image supply device sets BLOCK ACK to BLO
As long as CK count is set to 1 and returned, writing of the DUMMY command to the block register on the printer side is repeated.

Here, if the response time T1 is short, a large number of dummy processes will be executed, and traffic on the bus will be increased unnecessarily. To solve this on the image supply device side, after BLCOK ACK, a method of measuring the time by a timer until writing the next DUMMY command to the block register and adjusting the number of times the DUMMY command is written to the block register can be considered. . However, in this method, the processing of the image supply device increases, and the processing becomes complicated.

Therefore, in the present embodiment, the efficiency of traffic on the 1394 serial bus is realized by the following method.

FIG. 48 is a diagram showing a DUMMY command control procedure for suppressing an increase in traffic in this embodiment. In FIG. 48, the printer is BLOCK COMPLETE
Until the BLOCK ACK is returned (steps S48-2 to S48-3
Etc.) is adjusted to T1 ′ longer than T1. As a result, the BLOCKA
As soon as CK returns, the DUMMY command can be written to the printer's block register.

Since the response time T1 'can be controlled on the printer side, T1' can be adjusted in consideration of conditions on the printer side, such as the printing speed and the consumption speed of the buffer. As described above, in the present embodiment, the response time is set on the printer side.
By simply adjusting to T1 ', it is possible to realize more efficient traffic on the 1394 serial bus without adding processing to the image supply device side.

Hereinafter, the data transfer processing in the present embodiment will be described in detail for each of the image supply device side and the printer side. [Image Transfer Process in Image Supply Device] FIG. 49 is a flowchart showing an image transfer process in the image supply device of the present embodiment. Here, the image transfer process is a process in which the image supply device transfers image data to the printer and prints the image data. First, in step S500, a DUMMY command writing process is performed. This is a process for confirming the number of buffers of the other party as described with reference to FIG. 46 described above. Next, in step S501,
It is determined whether the BLOCK count returned in step S500 is 1 or not, and if it is 1, the flow proceeds to step S502 and ENADUMMYSENDf
Set lag to 0. Where ENADUMMYSENDflag is DUMM
This is a flag for determining whether or not to perform the Y processing. If the flag is 0, the dummy processing is not performed. If the flag is 1, the dummy processing is performed. If the BLOCK count is not 1 in step S501, the flow advances to step S503 to set ENADUMMYSENDflag to 1. Then, the process proceeds to step S504, and SEND described later
Execute command processing.

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 has been requested during the SNED command processing. In the present embodiment, the GETSTATUS command is interrupted at regular time intervals by timer processing, and G
ETSTATUS command request is set. Details of the interruption of the GETSTATUS command will be described later. Steps
If there is a GETSTATUS command request in S600, step S601
Go to and execute GETSTAUS command processing. This is a process for retrieving the status of the printer described with reference to FIG. 38 described above, and is used to confirm whether there is an error or abnormality in the printer during execution of the SNED command.

When the processing of the GETSTATUS command in step S601 ends, the processing returns to step S600. Step S6
If there is no GETSTATUS command request in 00, step S602
Go to and check if the BLOCK count is 1. BLOC
If K count is 1, it indicates that there is only one free buffer remaining in the printer, and the process proceeds to step S603 and E
Check if NADUMMYflag is 1. ENADUMMYBLOC
Kflag is a flag indicating whether or not the DUMMY command processing is executable. In steps S502 and S503 in FIG. 49 described above, the setting is performed according to the total number of empty buffers of the printer. ENADUMMYBLOCKfla in step S603
If g is not 1, the process returns to step S600 without performing the DUMMY command processing. This processing is performed when the total number of buffers on the printer side is 1 as shown in FIG.
This is equivalent to processing for preventing the UMMY command processing from being performed. If ENADUMMYBLOCKflag is 1 in step S603, the process proceeds to step S604, and in step S4 in FIG. 45 described above.
The transfer processing of the DUMMY command shown in 5-4 is executed. That is, if the total number of buffers on the printer side is 1 or more and the BLOCK count is
When the value becomes 1 (the remaining free buffer of the printer becomes 1), the transfer process of the DUMMY command is performed. Then, the process proceeds to step S606.

On the other hand, in step S602, BLOCK count
If is not 1, 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 a process of transmitting 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 into the block register of the printer as shown in FIG.
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.

The flow advances to step S606 to write BLOCK COMPLETE into the control register on the printer side. this
By writing the BLOCK COMPLETE, the end of the data writing to the block register is notified to the printer.

Then, the flow advances to step S607 to check whether a timeout has occurred. That is, after writing BLOCK COMPLETE in the control register of the printer in step S606, BLOCK COMPLETE is written in the response register of the image supply device.
Measure the time until the ACK / NACK is returned by the timer,
If a BLOCK ACK / NACK is not returned even after a predetermined time has elapsed, a timeout occurs. If a timeout has occurred in step S607, the process proceeds to step S608 to perform a timeout process. 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 has not been successful, or terminating the data transfer process to the printer. After the timeout processing, the SEND command processing ends.

If the timeout has not occurred in step S607, the flow advances to step S609 to check whether BLOCK NACK has been returned from the printer to the response register of the image supply device. If BLOCK NACK is returned, there is some problem in the data sent to the printer, and the process proceeds to NACK processing in step S610. In the NACK processing in step S610, data transmission to the printer is terminated because data transmission to the printer did not succeed for some reason as in the time-out processing. After NACK processing
SEND command processing ends.

If it is not BLOCK NACK in step S609, the flow advances to step S611 to check whether or not a BLOCK ACK has been returned from the printer. If not, the flow returns to step S607. If it is BLOCK ACK, the process advances to step S612 to check whether the SNED command has been completed. If not, the process returns to step S600 to repeat the above-described processing. On the other hand, if the SEND command has been completed in step S612, the SEND command processing ends.

As described above with reference to FIG. 50, in the image supply device of the present embodiment, SNED, DUMMY
It can be seen that the execution of the command and the processing of the GETSTATUS command during the execution of the SEND command can be performed. This is the figure above
This is processing corresponding to the procedure on the image supply device side in the DUMMY, GETSTATUS command control procedure described in 45.

FIG. 51 is a flowchart showing the details of the GETSTATUS command processing shown in step S601 in FIG. 50 described above. That is, the image supply device sends a command for receiving status from the printer to the block register on the printer side. This is the writing process. First step S700
In, a GETSTATUS command is written to a block register on the printer side. This is the step in FIG. 45 described above.
It corresponds to S45-9. Next, the process proceeds to step S701, where BLOCK COMPLETE is written to the control register of the printer.
This corresponds to Step S45-10 in FIG. Next, the process proceeds to step S702, and it is checked whether a timeout has occurred. That is, in step S701, the
The response time from when the BLOCK COMPLETE is written to when the BLOCK ACK / NACK is returned from the printer to the response register is measured. If the BLOCK ACK / NACK is not returned even after the predetermined time has elapsed, a timeout occurs. If a timeout has occurred in step S702, the process proceeds to step S703 to perform a timeout process. This timeout process is the same as step S608 shown in FIG. After timeout processing,
The GETSTATUS command processing ends.

If a timeout has not occurred in step S702, the flow advances to step S704 to check whether BLOCK NACK has been returned from the printer to the response register of the image supply device. If BLOCK NACK is returned, there is some problem in the data sent to the printer, and step S705
To NACK processing. This NACK processing is performed in step S6 in FIG.
Same as 10. After the NACK processing, the GETSTATUS command processing ends. If it is not BLOCK NACK in step S704, the process advances to step S706 to check whether BLOCK ACK has been returned from the printer. If not BLOCK ACK, step S70
Return to 2. As described above, the processing from steps S702 to S706 is performed as shown in FIG.
This corresponds to Step S45-11 of Step 5.

Next, the process proceeds to step S707, and steps S707 to S707 are performed.
Check the timeout until BLOCK COMPLETE in S709. This determines the BLOCK COMPLETE response time from the printer in steps S45-12 to S45-13 in FIG. 45, and if it is a timeout, it means that the 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 the timeout has not occurred in step S707, the process proceeds to step S709, and BLOCK is stored in the control register of the image supply device.
Checks whether COMPLETE has been written. BLOCK
If it is not COMPLETE, the process returns to step S707.

If BLOCK COMPLETE in step S709, the flow advances to step S710 to fetch a GETSTATUS reply. 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 the reply in step S710 was normal, that is, whether the returned status was correctly written in the block register of the image supply device. If it is correct, a BLOCK ACK is written to the response register of the printer in step S712, and if not, a BLOCK NACK is written in step S713. This step S71
2. The processing of S713 corresponds to step S45-14 in FIG.
Then, the GETSTATUS command processing ends.

As described above, the image supply device can obtain the status from the printer by the GETSTATUS command processing (step S45-8 in FIG. 45) shown in FIG.

FIG. 52 is a flowchart showing details of the 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 the GETSTATUS command processing. GE
If it is the TSTATUS execution time, the process proceeds to step S801, and GETSTAT
Set US command request. When this request is determined in step S600 in FIG. 50, the above-described GETSTATUS command processing is executed. After the request is set in step S801, the timer process ends. [Image Transfer Processing 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 to the control register on the printer side. Step if BLOCK COMPLETE is not written
The process proceeds to S901, executes the printing process, and returns to Step S900. This printing process will be described later. If BLOCK COMPLETE has been written to the control register in step S900, the flow advances to step S902 to fetch the written command. This command is composed of CommandID 35-1 and Parameter 35-2, as shown in FIG.
The type of command can be known by checking andID.

Next, the flow advances to step S903 to check whether or not the command written in the block register is a GETSTATUS command, that is, whether or not the CommandID indicates the GETSTATUS command. If the command is a GETSTATUS command, the process advances to step S904 to execute GETSTATUS command processing on the printer side, which will be described later. After executing the GETSTATUS command processing, the process returns to step S900. GETSTATUS in step S903
If it is not a command, then it is checked whether it is a DUMMY command. If not a DUMMY command, the command is SEN
Assuming that the command is a D command, the process advances to step S906 to check whether the image data sent by the SEND command is normal. If not, the process advances to step S907 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 correctly transmitted.

If the image data is normal in step S906, the flow advances to step S908 to move the image data written in the block register to an appropriate internal buffer. This means that the image data in the block registers is
This is the process of moving to any of the buffers indicated by 33-7. Then, the process proceeds to step S909, in which BLOCK count indicating the remaining number of free buffers is decremented by one. Next, proceed to step S910, where BLOCK AC is stored in the response register of the image supply device.
Write K and return to step S900.

If it is determined in step S905 that the command is a DUMMY command, the flow advances to step S911 to set BLOCK count to 1
Check if it is greater than. If it is larger, it is not a DUMMY command in the final buffer, so step S910
Go to BLOC in the response register of the image supply device
Write K ACK. On the other hand, in step S911, the BLOCK count
If 1, the flow advances to step S912 to wait for the time T1 '. Here, T1 'is the BLOCK COMPLET shown in FIG.
This is the response time until a BLOCK ACK is returned for E,
A time longer than T1 is set. The time until the BLOCK ACK is returned is adjusted by this T1 'time, and as a result, the DU transferred from the image supply device to the printer is adjusted.
The number of MMY commands can be reduced.

As described above, by the SEND command processing shown in FIG. 53, the image data receiving processing on the printer side is executed, and the GETSTATUS and DUMMY commands can be processed during the execution of the SEND command, and the number of empty buffers indicated by BLOCK count Can adjust the time to return the ACK.

FIG. 54 is a flowchart showing the printing process shown in step S901 in FIG. 53 described above. First, in step S1000, it is checked whether data exists in the buffer. If there is no data in the buffer, the printing process ends. If there is data, the process advances to step S1001 to perform a process for printing the data in the first buffer. Here, the head buffer means a buffer at the head of data that has not been printed yet, and it is checked in step S1002 whether the head buffer is empty. If the first buffer is not empty, the printing process ends. If the first buffer is empty, the process proceeds to step S1003 and 1 is added to the BLOCK count. That is, when all the data in the first buffer is printed and becomes empty, the number of empty buffers is increased by one. Then, the printing process ends. Through the above-described printing processing, printing can be executed and empty buffers can be managed in the present embodiment.

FIG. 55 is a flowchart showing the details of the GETSTATUS command processing in the printer shown in step S904 in FIG. 53 described above. This is processing for returning a response from the printer to the GETSTATUS command from the image supply device. First, in step S1100, a status to be returned is created. The content of this status is as shown in FIG. 38 described above. The status of the printer is checked and the corresponding content is set. Next, in step S1101, the GETSTATUS reply is written to the block register of the image supply device. This corresponds to step S45-12 in FIG. 45 described above.

Next, in step S1102, BLOCK COMPLETE is written to the control register of the image supply device. This corresponds to Step S45-13 in FIG. Then, the process advances to step S1103 to check for a timeout. That is, the time from writing BLOCK COMPLETE to the control register of the image supply device in step S1102 until the BLOCK ACK / NACK is returned to the response register of the printer is measured.
Timeout if no K / NACK is returned. If a timeout occurs in step S1103, the process advances to step S1104 to perform a timeout process. This is a process similar to step S608 in FIG. 50 described above. After the timeout processing, the GETSTATUS command processing ends.

If a timeout has not occurred in step S1103, the flow advances to step S1105 to check whether BLOCK NACK has been returned from the image supply device to the response register of the printer. When the BLOCK NACK is returned, there is some problem in the data sent to the image supply device, and the process advances to step S1106 to perform the same NACK processing as step S610 in FIG. After the NACK processing, the GETSTATUS command processing ends. On the other hand, if it is not BLOCK NACK in step S1105, the process proceeds to step S1107, where
Check if LOCK ACK is returned. BLOCK ACK
If not, the process returns to step S1103. Step S1103 ~
The processing up to S1107 corresponds to step S45-14 in FIG. If it is BLOCK ACK in step S1107, GETSTA
The TUS process ends.

As described above, the GETSTA on the printer side shown in FIG.
By the TUS command processing, the status of the printer is returned to the image supply device.

As described above with reference to FIGS. 42 to 55, according to the present embodiment, the image supply device performs the BLOCK ACK / NACK written from the printer to the response register.
And the BLOCK count, it is possible to know the number of empty buffers that the printer currently has, and when the number of empty buffers becomes 1, a process of sending a DUMMY command instead of the SEND command can be executed. GETST during DUMMY command execution
Since the ATUS command can be executed, the GETSTATUS command can be arbitrarily executed even while the SEND command is being executed. Since the DUMMY command can be configured with a smaller amount of data than other commands such as the SEND command, the influence on traffic on the 1394 serial bus can be minimized.

Further, since the time interval at which the DUMMY command is sent can be adjusted on the printer side, the traffic on the 1394 serial bus can be made more efficient without imposing a load on the image supply device side.

When the total number of buffers in the printer is 1, the DUMMY command processing is not performed, so that the necessary SEND command processing can be prevented.

[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, in the response register configuration shown in the lower part of FIG. 56, BLOCK RETRY of 03h is added as a response command 56-2. Here, the BLOCK RETRY is a response indicating that a request for retransfer of image data to the image supply device is made when, for example, the number of empty buffers held by the printer becomes one. Therefore, if the response command 56-2 is 03h, it indicates BLOCK RETRY, that is, a request for retransfer of image data.

FIG. 57 shows RETRY, GETS in the second embodiment.
FIG. 46 is a diagram showing a TATUS command control procedure, which corresponds to the DUMMY, GETSTATUS command control procedure shown in FIG. 45 in the first embodiment described above.
It is different from 45. First, step S4 in FIG.
The difference is that the BLOCK count is returned by 1 in 5-3, whereas the BLOCK RETRY is returned in step S57-3 in FIG. 57. Then, while the DUMMY command is written in the block register in step S45-4 of FIG.
In step S57-4, the SEND immediately before step S57-1
The difference is that the same data as the command is written.
Note that the other processing in FIG. 57 is the same as that in FIG. 45, and thus the description is omitted.

Hereinafter, processing on the image supply device side and 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.
9 is a flowchart illustrating an image transfer process of the image supply device according to the embodiment, which substantially performs a SEND command process in step S1200.

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 activation of the GETSTATUS command is performed in the same manner as in FIG. 52 shown in the first embodiment. If there is a request in step S1300, the process advances to step S1301 to execute GETSTAUS command processing. This GETSTATUS command processing is the same as the processing for extracting the status of the printer shown in FIG. 51 in the first embodiment. When the GETSTATUS command processing in step S1301 ends, the processing returns to step S1300.

If there is no GETSTATUS command request in step S1300, the flow advances to step S1302 to store B in the response register.
Check if LOCK RETRY has been written. BLOCK RE
If TRY is written, it indicates that the printer has only one free buffer and that data retransfer is requested, so the process proceeds to step S1303, where the printer registers in the control register. The data written by the immediately preceding SEND command is written again. this is,
This corresponds to steps S57-4 and S57-15 in FIG. Step S13
If it is not BLOCK RETRY in 02, proceed to step S1304 and SE
Execute ND command transfer processing. This corresponds to steps S57-1, S57-18, and S57-21 in FIG. 57, and is processing for transmitting image data to the printer. Here, if the image data does not fit in one buffer, as shown in FIG. 39 in the first embodiment, the image data
The command is divided into commands and written into 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.

The flow advances to step S1305 to write BLOCK COMPLETE into the control register on the printer side. By writing the BLOCK COMPLETE, the end of data writing to the block register is notified to the printer.
Next, the process advances to step S1306 to check whether a timeout has occurred. That is, in step 1305, BLOCK COMPLETE is written to the control register of the printer, and then BLOCK ACK / NACK or
The time until the RETRY is returned is measured by the timer, and if the BLOCK ACK / NACK and the RETRY are not returned even after the predetermined time has elapsed, a timeout occurs. If a timeout has occurred in step S1306, the flow advances to step S1307 to perform a timeout process. Here, the timeout process is a process of notifying the user that a timeout has occurred for some reason and the data transmission to the printer has not been successful, or terminating the image transfer process to the printer.
After the timeout processing, the SEND command processing ends.

If a timeout has not occurred in step S1306, the flow advances to step S1308 to check whether BLOCK NACK has been returned from the printer to the response register of the image supply device. If BLOCK NACK is returned, there is something wrong with the data sent to the printer.
The process proceeds to the NACK process in step S1309. NACK in step S1309
The process terminates the image transfer process to the printer because data transmission to the printer failed for some reason, similar to the timeout process. After the NACK processing, the SEND command processing ends.

If it is not BLOCK NACK in step S1308, the flow advances to step S1310 to execute BLOCK RETRY from the printer.
Is returned or not, and if BLOCK RETRY is returned, the process returns to step S1300. If BLOCK RETRY is not returned, the flow advances to step S1311 to check whether or not BLOCK ACK has been returned from the printer. If not, the flow returns to step S1306. If it is a BLOCK ACK, the process advances to step S1312 to check whether the SNED command has been completed. If not, the process returns to step S1300 to repeat the above-described processing. On the other hand, if the SEND command has ended in step S1312, the SEND command processing ends.

As described above with reference to FIG.
It can be seen that the image supply device of the second embodiment can execute the SNED command, process the BLOCK RETRY, and process the GETSTATUS command during the execution of the SEND command. This is the same as RETRY, GETSTAT described in FIG.
This is a process corresponding to the procedure on the image supply device side in the US command control procedure. [Image Transfer Processing in Printer] FIG. 60 is a flowchart showing in detail the SEND command processing in the printer of the second embodiment.

First, in step S1400, it is checked whether BLOCK COMPLETE has been written in the control register of the printer. If BLOCK COMPLETE has not been written, the flow advances to step S1401 to execute print processing, and then to step S14.
Return to 00. This printing process is the same as that described in the first embodiment with reference to FIG.
This is the same as step S901 in step 3. BLOCK in step S1400
If COMPLETE has been written, the flow advances to step S1402 to fetch the written command. This command
As shown in Fig. 35 above, CommandID35-1 and Paramet
The type of command can be known by checking the CommandID.

Next, the flow advances to step S1403 to determine whether or not the written command is a GETSTATUS command,
Check if mandID indicates a GETSTATUS command. If the command is a GETSTATUS command, the process advances to step S1404 to execute GETSTATUS command processing on the printer side, and then returns to step S1400. This GETSTATUS command processing is the same as in FIG. 55 shown in the first embodiment. Step S
If 1403 is not a GETSTATUS command, the command is SEN
Proceed to step S1405 as D command,
Check if nt is greater than 1.

If the BLOCK count is larger than 1, step S1
Proceeding to 408, it is checked whether the image data sent by the SEND command is normal. If not, the process advances to step S907 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 correctly transmitted. If the image data is normal in step S1406, the flow advances to step S1408 to move the image data written in the block register 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. Then, the process advances to step S1409 to decrement BLOCK count indicating the number of remaining free buffers by one. Next, the process proceeds to step S1410, writes BLOCK ACK in the response register of the image supply device, and returns to step S1400.

On the other hand, if the BLOCK count is 1 in step S1405, the flow advances to step S1411 to wait for T1 'time. Here, T1 'is the BLOCK COMPL shown in FIG.
This is the response time until a BLOCK ACK is returned to ETE.
A time longer than T1 shown in 47 is set. Then, after the elapse of the time T1 ', in step S1412, BLOCK RETRY urging retransmission of the SEND command is written in the response register of the image supply device, and the process returns to step S1400. In the second embodiment, the D shown in FIGS. 47 and 48 in the first embodiment described above is used.
It is characterized by resending a SEND command instead of transferring a UMMY command. Therefore, the time until the BLOCK RETRY is returned is adjusted by this T1 'time, and as a result, the SEND which is resent from the image supply device to the printer is
The number of commands can be reduced.

As described above, by the SEND command processing shown in FIG. 60, the image data receiving processing on the printer side is executed, and not only the GETSTATUS command processing can be performed during the execution of the SEND command, but also the empty buffer indicated by the BLOCK count. Depending on the number, retransmission processing of the SEND command becomes possible.

As described above with reference to FIGS. 56 to 60, according to the second embodiment, the image supply device uses the BLOCK ACK / NACK and BLOCK RETRY returned from the printer to execute the empty buffer currently held by the printer. When the number becomes 1, the retransmission processing of the SEND command can be executed. Also,
The GETSTATUS command can be executed while the SNED command is being re-transferred.
TSTATUS command can be executed.

In the retransmission processing of the SEND command, existing bus reset, error processing, and the like can be used, so that it can be realized without adding new processing.

Since the time interval at which the SEND command is retransmitted can be adjusted on the printer side, the traffic on the 1394 serial bus can be made more efficient without imposing a load on the image supply device.

Modification of Embodiment In the first and second embodiments described above, an example has been described in which the DUMMY command processing and the BLOCK RETRY processing are performed when the number of empty buffers in the printer becomes 1. However, the number of free buffers is not limited to one. Any number may be used as long as it is inconvenient to execute the SEND command processing. For example, the number may be 2 or 3.

In each of the embodiments, an example has been described in which print processing is realized by transferring data from an image supply device to a printer. However, the present invention is not limited to any device that transfers and uses image data. It is also applicable to such a device.

In the first embodiment described above, D
Although the UMMY command is described as being transferred when the number of empty buffers in the printer becomes 1, the command is sent from the image supply device to the printer, and the number of empty buffers in the printer is obtained. Any command may be used as long as it has a small load.

In each embodiment, the BLOCK coun
The example in which the number of free buffers is set to t and the notification is performed has been described. However, a method of setting buffer information such as “there is a free buffer” or “the number of free buffers” instead of the number of the free buffers is also conceivable. Also in this method, the state of the buffer can be notified to the image supply device, so that the same effects as those of the above-described embodiments can be obtained.

In each of the above embodiments, the IEEE
Although an example in which a network is configured using the serial interface specified in 1934 has been described, the present invention is not limited to this, and an arbitrary serial interface such as a serial interface called Universal Serial Bus (USB) can be used. The present invention can also be applied to networks configured using faces.

[Other Embodiments] Even if the present invention is applied to a system including a plurality of devices (for example, a host computer, an interface device, a reader, a printer, etc.), an apparatus (for example, a copying machine) Machine, facsimile machine, etc.).

Further, an object of the present invention is to supply a storage medium storing program codes of software for realizing the functions of the above-described embodiments to a system or an apparatus, and to provide a computer (or a CPU or M
Needless to say, this can also be achieved by the PU) reading and executing the program code stored in the storage medium. In this case, the program code itself read from the storage medium implements the functions of the above-described embodiment, and the storage medium storing the program code constitutes the present invention. Examples of the storage medium for supplying the program code include a floppy disk, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM,
CD-R, magnetic tape, non-volatile memory card, ROM, etc. can be used.

When the computer executes the readout program code, not only the functions of the above-described embodiment are realized, but also the OS (Operating System) running on the computer based on the instruction of the program code. ) May perform some or all of the actual processing, and the processing may realize the functions of the above-described embodiments.

Further, after the program code read from the storage medium is written into a memory provided in a function expansion card inserted into the computer or a function expansion unit connected to the computer, based on the instruction of the program code, It goes without saying that the CPU included in the function expansion card or the function expansion unit performs part or all of the actual processing, and the processing realizes the functions of the above-described embodiments.

[0204]

As described above, according to the present invention,
Connect the host device and the target device via a 1394 serial bus, etc., and use the same register area for the command and data for the transfer of data sent from the host device to the target device, and only respond to writing data to the register. It is possible to provide a data transfer device, a data transfer system and a method thereof, an image processing device, and a recording medium that can arbitrarily execute commands other than data transfer. That is, according to the present invention, the target device issues a data retransmission request to the host device according to the number of free buffers, so that other commands can be arbitrarily executed even during data transfer.

Also, a data transfer device, a data transfer system and its method, an image processing device, and a data transfer device for realizing efficient traffic on a data bus by adjusting a response time to data writing to a register.
A recording medium can be provided.

[0206]

[Brief description of the drawings]

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

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

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

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

FIG. 5 is a view showing a cross section of a cable for a 1394 serial bus.

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

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

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

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

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

FIG. 11 is a diagram showing functions of a CSR architecture of a 1394 serial bus;

FIG. 12 is a diagram showing registers related to a 1394 serial bus;

FIG. 13 is a diagram showing registers related to node resources of the 1394 serial bus;

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

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

FIG. 16 is a diagram for explaining a request for a bus use right;

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

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

FIG. 19 is a diagram showing a request / response protocol of each command of read, write, and lock based on a CSR architecture in a transaction layer,

FIG. 20 is a diagram showing a service in a link layer;

FIG. 21 is a diagram showing temporal transition in asynchronous transfer;

FIG. 22 is a diagram showing a format of an asynchronous transfer packet.

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

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

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

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

FIG. 27 is a diagram showing details of a field of a packet format of the synchronous transfer in the 1394 serial bus;

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

FIG. 29 is a diagram showing a layer structure of a 1394 serial bus.

FIG. 30 is a diagram showing a configuration of a register for data transfer;

FIG. 31 is a diagram showing an outline 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 configuration of a block register and an internal buffer 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 a configuration of a SEND, GETSTATUS command;

FIG. 37 is a diagram showing a configuration of a SEND, GETSTATUS reply;

FIG. 38 is a diagram showing the status of the GETSTATUS command;

FIG. 39 is a diagram showing a state of image data division by a 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 a configuration of a control and response register;

FIG. 43 is a diagram showing a configuration 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 a control procedure of a DUMMY command before a SEND command;

FIG. 47 is a view 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 an image transfer process in the image supply device;

FIG. 50 is a flowchart showing a SEND command process 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 a SEND command process in the printer;

FIG. 54 is a flowchart showing a printing process 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 according to the second embodiment;

FIG. 57 is a diagram showing a control procedure of a RETRY, GETSTATUS command in the second embodiment;

FIG. 58 is a flowchart showing an image transfer process in the image supply device of the second embodiment;

FIG. 59: SEND in the image supply device of the second embodiment
Flowchart showing command processing,

FIG. 60 is a flowchart illustrating SEND command processing in the printer of the second embodiment.

Claims (40)

[Claims] 1. A data transfer method used between a host device and a target device connected by a serial bus, wherein the first data is continuously transferred in units of a predetermined size, and A request for retransmission of the first data is returned as necessary together with a result of the predetermined number of transfers, the first data is retransmitted based on the retransmission request, and during the retransmission of the first data, 2. A data transfer method characterized by transferring the data of 2. 2. The data reception buffer includes a plurality of buffers having the predetermined size, and the first data retransmission request is transmitted in accordance with the number of available data receivable buffers among the plurality of buffers. 2. The data transfer method according to claim 1, wherein a reply is sent. 3. The data transfer method according to claim 2, wherein the retransmission request is returned when the number of empty buffers is equal to or less than a predetermined number. 4. When the number of empty buffers is one,
4. The data transfer method according to claim 3, wherein the retransmission request is returned. 5. The data transfer method according to claim 1, wherein the first data retransmission request is repeated according to the buffer status. 6. The data transfer method according to claim 1, wherein the second data is transferred at a timing at which a retransmission result of the first data is received. 7. The data transfer method according to claim 1, wherein the first data includes a command for transferring image data. 8. The data transfer method according to claim 1, wherein the second data is a command for acquiring status information of the target device. 9. The time until the retransmission request is returned in response to one transfer of the first data is shorter than the time when the transfer result of the first data is returned without a retransmission request. 2. The data transfer method according to claim 1, wherein the data transfer method is long. 10. The data according to claim 1, wherein in transferring the first and second data, a command and data are written in the same register area in each of the host device and the target device. Transfer method. 11. The data transfer method according to claim 10, wherein a response to the transfer of the first and second data is a response to a write of data to the register. 12. The serial bus according to claim 1, wherein the serial bus conforms to or conforms to the IEEE 1394 standard.
12. The data transfer method according to any one of claims 1 to 11. 13. The serial bus according to claim 1, wherein the serial bus conforms to or conforms to a USB standard.
2. The data transfer method according to any one of 1. 14. The apparatus according to claim 1, wherein the host device is a device that outputs image data.
The data transfer method according to any one of the above. 15. The data transfer method according to claim 1, wherein the target device is a device that forms a visible image based on image data on a recording medium. 16. An image processing apparatus for transmitting image data to the target device by the data transfer method according to claim 1. Description: 17. An image processing apparatus which processes image data received from the host device by the data transfer method according to claim 1. 18. A data transfer device connected by a serial bus, comprising: communication means for transferring data to and from a host device in a predetermined size unit; Replying means for returning a retransmission request to the host device, wherein the communication means receives first data continuously transferred from the host device in units of the predetermined size, and the reply means Returning the reception result of the first data to the host device together with the retransmission request, the communication unit further receives the first data transferred from the host device based on the retransmission request again. A data transfer device for receiving the second data while re-receiving the first data. 19. The system according to claim 18, wherein the reply unit transmits the retransmission request for the first data in accordance with the number of empty buffers that can receive data among a plurality of data reception buffers. Data transfer device. 20. The data transfer device according to claim 19, wherein the reply unit repeats a retransmission request for the first data according to the number of empty buffers. 21. The method according to claim 18, wherein the first data includes a command for transferring image data.
A data transfer device according to claim 1. 22. The data transfer device according to claim 18, wherein the second data is a command for transferring dummy data that does not include valid data. 23. The data transfer device according to claim 18, wherein the third data is a command for requesting status information of the data transfer device. 24. The time until the retransmission request is returned in response to one reception of the first data in the return means, the reception result of the first data is returned without a retransmission request. Claims that are longer than
18. The data transfer device according to 18. 25. The communication device according to claim 25, wherein the communication unit writes the command and the data in the same register area.
18. The data transfer device according to 18. 26. The data transfer apparatus according to claim 25, wherein said reply means only makes a response to writing of data into said register area. 27. A data transfer system for transferring data via a serial bus, comprising: a communication unit for transferring data in a predetermined size unit; and a request for retransmission of the data together with a result of the data transfer as required. A communication unit that continuously transfers the first data in units of the predetermined size, and is returned by the return unit together with a result of the first-time transfer of the first data. A data transfer system, wherein the first data is transferred again based on a retransmission request, and the second data is transferred during the retransmission of the first data. 28. The data reception buffer includes a plurality of buffers having the predetermined size, and the reply unit replies the retransmission request based on the number of free buffers that can receive data among the plurality of buffers. 28. The data transfer system according to claim 27, wherein: 29. The data transfer system according to claim 28, wherein said reply means returns said retransmission request when said empty buffer is equal to or less than a predetermined number. 30. The data transfer system according to claim 29, wherein said reply means returns said retransmission request when said number of empty buffers is one. 31. The method according to claim 31, wherein the reply unit repeats the retransmission request according to the buffer status.
27. The data transfer system according to item 27. 32. The communication device according to claim 2, wherein the communication unit transfers the second data at a timing when a retransmission result of the first data is received by the reply unit.
7. Data transfer system according to 7. 33. The apparatus according to claim 27, wherein the first data includes a command for transferring image data.
Data transfer system as described. 34. The data transfer system according to claim 27, wherein the second data is a command for acquiring status information of a data transfer destination. 35. The reply means, wherein:
28. The method according to claim 27, wherein a time period until the retransmission request is returned in response to the first transfer is longer than a case where the transfer result of the first data is returned without a retransmission request.
Data transfer system as described. 36. The communication device according to claim 36, wherein the communication unit writes the command and the data in the same register area.
27. The data transfer system according to item 27. 37. The data transfer system according to claim 36, wherein said reply means performs only a response to writing of data to said register. 38. The serial bus according to claim 27, wherein the serial bus conforms to or conforms to the IEEE1394 standard.
38. The data transfer system according to any one of items 37 to 37. 39. The serial bus according to claim 27, wherein the serial bus conforms to or conforms to the USB standard.
38. The data transfer system according to any one of 37. 40. A recording medium storing a program code of a data transfer method used between a host device and a target device connected by a serial bus, wherein the program code stores the first data in a predetermined size. A code for continuously transferring in units, a code for returning a retransmission request for the first data as needed together with a result of the predetermined number of transfers of the first data, and the first data based on the retransmission request. A recording medium comprising: a code for transferring data again; and a code for transferring second data during retransmission of the first data.