|Publication number||USRE39763 E1|
|Application number||US 10/845,060|
|Publication date||Aug 7, 2007|
|Filing date||May 12, 2004|
|Priority date||Apr 1, 1996|
|Also published as||USRE44443|
|Publication number||10845060, 845060, US RE39763 E1, US RE39763E1, US-E1-RE39763, USRE39763 E1, USRE39763E1|
|Inventors||Erik Staats, Robin D. Lash|
|Original Assignee||Apple Computer, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (13), Non-Patent Citations (4), Referenced by (2), Classifications (3), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is a continuation application of U.S. Reissue application No. 09/932,846, filed Aug. 17, 2001, now U.S. Pat. No. RE. 38,641, which is a reissue application of U.S. Pat. No. 5,940,600, issued Aug. 17, 1999.
Notice: More than one reissue application has been filed for the reissue of U.S. Pat. No. 5,940,600. The reissue applications are application Nos. 10/845,060 (the present application), filed on May 12, 2004; 09/932,292, filed on Aug. 17, 2001, now RE 38,641; and 11/503,541, filed Aug. 11, 2006.
This invention relates generally to data communications and, more particularly, to data communications within a computer bus architecture.
The components of a computer system are typically coupled to a common bus for communicating information to one another. Various bus architectures are known in the prior art, and each bus architecture operates according to a communications protocol that defines the manner in which data transfer between components is accomplished.
The Institute of Electrical and Electronic Engineers (IEEE) has promulgated a number of different bus architecture standards including IEEE standards document 1394, entitled Standard for a High Performance Serial Bus (hereinafter “IEEE 1394 Serial Bus Standard”). A typical serial bus having the IEEE 1394 standard architecture is comprised of a multiplicity of nodes that are interconnected via point-to-point links, such as cables, that each connect a single node of the serial bus to another node of the serial bus. Data packets are propagated throughout the serial bus using a number of point-to-point transactions, wherein a node that receives a packet from another node via a first point-to-point link retransmits the received packet via other point-to-point links. A tree network configuration and associated packet handling protocol ensures that each node receives every packet once. The serial bus of the IEEE 1394 Serial Bus Standard may be used as an alternate bus for the parallel backplane of a computer system, as a low cost peripheral bus, or as a bus bridge between architecturally compatible buses.
A communications protocol of the IEEE 1394 Serial Bus Standards specifies two primary types of bus access: asynchronous access and isochronous access. Asynchronous access may be either “fair” or “cycle master”. Cycle master access is used by nodes that need the next available opportunity to transfer data. Isochronous access is used by nodes that require guaranteed bandwidth, for example, nodes transmitting video data. The transactions for each type of bus access are comprised of at least one “subaction”, wherein a subaction is a complete one-way transfer operation.
In the case of isochronous data transfers and computer systems conforming to the IEEE 1394 Serial Bus Standard, the prior art has attempted to manage the flow of data using dedicated drivers. Drivers are software entities associated with various components of a computer system and, among other functions, operate to configure the components and allow the components to be operable within the overall system. The drivers of the prior art have allowed for the transmission of video data from a digital video camera to a monitor, but have not allowed for real time video transmissions in a multi-tasking environment. In particular, the drivers of the prior art have required that a bus controller, e.g., the computer system's CPU, listen to a data channel at the exclusion of all other processes. As data arrives on the channel, it is stored in a buffer for later transmission to a frame buffer associated with a monitor. A new listen instruction must be issued for each separate isochronous data transmission. That is, if a single transmission corresponds to data for a single scan line of the monitor, for a display of five scan lines, five separate listen instructions are required. Because the data is being sent in real time, this system requires that the processor spend all of its time servicing the isochronous data transmissions, even if no data is currently being transmitted on the bus, without servicing any other tasks. It would, therefore, be desirable to have a means and method for a more efficient management of isochronous data channels in a computer system.
A computer implemented method of managing isochronous data channels in a computer system is described. In one embodiment, the computer system conforms to the IEEE 1394 Serial Bus Standard. An isochronous channel is established within the computer system and includes a linked list of buffers. The linked list of buffers corresponds to display locations on a display which is part of the computer system. Once the linked list of buffers has been established, the computer system executes instructions which allow for the transmission of isochronous data across the channel. Each time a sender node, a video camera in one embodiment, is ready to transmit data, an interrupt is generated which causes the processor to execute instructions to manage the flow of data from the sender. The processor transfers the data transmitted by the camera to a storage location within the linked list of buffers. Ultimately, this data is transferred to a frame buffer associated with a display. This interrupt driven management allows the processor to perform other tasks when no data is being transmitted over the isochronous channel.
In another embodiment, the data transfer is DMA driven rather than interrupt driven. For this embodiment, the isochronous channel, including the linked list of buffers, is established and the process is initiated. Data transmitted by the video camera is transferred to memory locations within the linked list of buffers by the DMA hardware and then ultimately transferred to a frame buffer for display.
In yet another embodiment, the central processing unit (CPU) for the computer system establishes an isochronous channel between a sender node and one or more receiver nodes, not including the CPU itself. For this embodiment, no linked list of buffers is required as data from the sender node is transferred directly to the receiver node.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
As described herein, a method and apparatus for managing isochronous data channels in a computer system is provided.
The computer system 5 of
A point-to-point link such as cable 20 is used to connect two nodes to one another. CPU node 12 is coupled to internal hard drive node 15 by an internal link 21, to monitor node 16 by cable 20, and to keyboard node 40 by a cable 20e. The keyboard node 40 is coupled to the mouse node 44 by a cable 20f. The monitor node 16 is coupled to the nodes of the other peripherals (not shown) by cable 20a and to the printer node 24 by cable 20b. The printer node 24 is coupled to the video camera node 30 by cable 20c and to the VCR node 34 by cable 20d. Each of the cables 20-20f and the internal link 21 may be constructed in accordance with the IEEE 1394 Serial Bus Standard and may include a first differential signal pair for conducting a first signal, a second differential signal pair for conducting a second signal, and a pair of power lines.
Each of the nodes 12, 15, 16, 24, 32, 34, 40 and 44 may have identical construction, although some of the nodes, such as mouse node 44, can be simplified because of their specified functions. Thus, the nodes can be modified to meet the needs of a particular local host. For example, each node may have one or more ports, the number of which is dependent upon its needs. For example, CPU node 12, as illustrated, has 3 ports, while the mouse node 44 has only 1 port.
Referring now to
In general, window 50 will be generated by an application program running on computer system 5. An example of such an application program is the QuickTime® program available from Apple Computer, Inc. of Cupertino, Calif. In such a case, computer system 5 may comprise the familiar Macintosh® computer system also available from Apple Computer, Inc. The video data to be displayed in window 50 on display screen 48 will generally be obtained from a frame buffer (not shown) associated with monitor 18. The techniques for displaying data stored in a frame buffer on the display screen of a monitor are well-known in the art.
In accordance with the methods of the present invention, real-time video data from video camera 32 is to be displayed within window 50 on display screen 48. The real-time video data generated by video camera 32 will comprise isochronous data packets in accordance with the IEEE 1394 Serial Bus Standard. Each of these isochronous data packets will include header information and payload information. The header information is used for routing the video data to the monitor 18 and for error detection and correction. The payload data comprises the video data to be displayed within window 50.
As indicated above, the prior art has attempted to manage this flow of isochronous data from video camera 32 to monitor 18 as follows. Once the application program has generated window 50 within display screen 48, CPU 10 executes instructions which cause it to listen on one of its associated ports. These instructions are typically stored on hard drive 14 and are loaded into system memory (not shown) upon initialization. When the video camera 32 has data to transmit, the video camera node 30 generates the isochronous data packets and transmits them over the serial bus in accordance with the IEEE 1394 Serial Bus Standard. CPU node 12 detects the presence of the isochronous data packets and strips the payload information from these packets. The payload information is placed in a buffer in the computer memory for later transmission to the frame buffer associated with monitor 18. If, for example, one transmission from video camera node 30 corresponded to data for a single scan line of window 50, five separate listen operations would be required to receive the video data associated with one frame to be displayed within window 50. To accommodate the real-time transmission nature of the video data, CPU 10 would be required to constantly listen to the bus for isochronous data transmissions from video camera node 30. That is, CPU 10 could not undertake to execute additional tasks, for example menu level tasks, as is common in multi-tasking environments.
To overcome this problem of the prior art, the present invention uses a linked list of buffers such as those shown in FIG. 3.
An exemplary structure of these isochronous channel buffers is shown below:
Branch pointer to next
channel buffer. When a
branch condition is met, its
corresponding branch pointer
is used to select the next
Pointer to buffer memory.
Length of above
The linked list of buffers corresponds to a particular isochronous channel. The isochronous channel is identified by a channel identification number (channel ID). The channel ID is maintained in a data record stored in the computer system 5 memory and is used by the various application programs and driver routines as described below. The use of a common channel ID allows the interoperation of application programs, driver routines, and other software routines which otherwise may not be capable of operating together.
One example of the use of a linked list of buffers according to the methods of the present invention as shown in
Upon receiving the instruction to create the isochronous channel ID, the CPU 10 will execute instructions to create such a channel. This may include a channel bandwidth and a preferred speed. An exemplary instruction is shown below.
OSStatus AllocateIsochronousChannelID ( IsochChannelID “pIsochChannelID, UInt32 bandwidth, UInt32 preferredSpeed); <-- pIsochChannelID Returned reference to this channel for use is subsequent isochronous service calls. --> bandwidth Bandwidth required for this channel. --> preferredspeed Preferred speed for this channel.
This instruction creates an isochronous channel ID that is used by the various isochronous service routines described below. The channel is initialized with the required bandwidth and the preferred speed. The actual channel speed may be less than the preferred speed depending on the maximum speed of the devices that are later attached to the channel. The isochronous channel is a data path between nodes which will be added as channel clients as described below.
Once a channel has been established, the application program can issue instructions in order to add interested clients to the isochronous channel specified by channel ID. These clients are typically software driver routines associated with the devices, such as video camera 32, which take part in the display of the real-time video data to be transferred. The client software will take part in and be notified of all events associated with the given isochronous channel specified by the channel ID. Accordingly, at step 104, the application program instructs the driver associated with video camera 32 to send real-time video data over the channel identified by “channel ID” and display the data within window 50 on monitor 18.
In response to the instructions issued by the application program, the camera driver will configure the camera 32 such that the camera 32 will transmit video data over the channel specified by “channel ID”. The camera driver will also establish a linked list of buffers, as described above, and assign the buffers to “channel IID”. The linked list of buffers will act as storage locations for the video data to be transmitted by camera 32.
An exemplary instruction for adding clients to “channel ID” is shown below
OSStatus AddIsochronousChannelClient ( IsochChannelID isochChannelID, DriverID driverID, Boolean clientIsTalker); --> isochChannelID Reference to the isochronous channel to add the given client to. --> driverID Reference to the driver client to add to the given channel. --> clientIsTalker If the given client will be a sender node (i.e., a node that will be “doing the talking” in IEEE 1394 pirlance) this should be set to true. Otherwise it should be set to false (i.e., if the node will be a listener).
This instruction adds the driver specified by “DriverID” as a client to the isochronous channel specified by IsochChannel ID”. The client will be called to perform its role in initializing, starting and stopping the given isochronous channel. The client will also be informed of all channel events such as bus resets.
For the example of
Next, at step 110, the camera driver sets up the linked list of buffers described above. Once this is accomplished, a port on CPU node 12 can be set to listen to the isochronous channel. An exemplary routine for this procedure is shown below.
Reference used to indicate which
node to allocate port on.
Returned reference to this prot for use
in subsequent port service calls.
Channel number for this port.
Speed for this port.
If false, allocate a port for listening,
otherwise allocate a port for talking.
Once all of the clients have been added to the isochronous channel specified by channel ID, a start instruction can be issued at step 116. This instruction, an example of which is given below, calls all of the given isochronous channel's clients (i.e., the driver software associated with the various devices) to start the given isochronous channel. Each listening client is first instructed to listen to the channel. Once all of the listeners are ready, the sender client is instructed to start the transmission of data.
Reference to the isochronous channel to
As shown in
OSStatus StartLocalIsochronousPort ( IsochPortActionParamsPtr pIsochPortActionParams); <--> pIsochPortActionParams Pointer to parameter block. --> controlFlags Flags used to control the request. <-- status Current status of request. --> completionProc Procedure to call upon comple- tion of request. --> completionProcData Data to be used by completionProc. --> isochPortID Reference to local port to start. --> pIsochChannelBuffer Isochronous channel buffer chain to talk/listen into/from. --> actionSync Sync event to start on.
This instruction causes the local port specified by isoch-PortID to start listening (for the example of
Similarly, at step 122 the VCR driver programs the VCR 36 to start listening to the isochronous channel specified by channel ID. Once this is completed, the service routine issues instructions telling the camera driver to program camera 32 to start sending data over the isochronous channel. At step 126, the camera driver does so.
At this point, CPU 10 may continue with other instructions as indicated by step 130. For example, CPU 10 may respond to menu level instructions initiated by a user or execute commands for a selected foreground application. When video camera 32 transmits data on the isochronous channel specified by a channel ID, the CPU receiving the data generates an interrupt. The interrupt is recognized at step 128 and procedure 100 moves to step 132 where the interrupt causes the CPU 10 to execute instructions which transfer the incoming isochronous data into an appropriate buffer within the linked list. The CPU 10 then returns from the interrupt to complete or continue with any tasks. For the second embodiment described above, a DMA transfer is initiated to transfer the data without interrupting the CPU 10. Subsequently, data is transferred from the buffers which comprise the linked list to a frame buffer associated with monitor 18 for eventual display on display screen 48 within window 50. This process continues until an isochronous channel stop instruction is issued.
Stopping the transmission of isochronous data is similar to the starting process. This time, however, a stop command is issued which calls all of the given channel's clients as follows. First, the stop command calls the sending client to stop sending data on the channel. Once the sender stops, the stop command calls each of the listening clients to stop listening.
Those skilled in the art will recognize that the simple linked list configuration shown in
To account for these types of errors, a more complex linked list of buffers is used. This more complex scheme is shown in FIG. 4. The linked list of buffers shown in
Where the video data received does not have a top-of-frame indication, the linked list will point to the next buffer in the chain. In this way, the situation described above where the data is displayed with the top-of-frame at the bottom of the window is avoided. Those skilled in the art will appreciate that other branching conditions, such as branch on fill or branch on synch, can also be implemented.
An exemplary structure of these isochronous channel buffers is shown below:
typedef struct IsohChannelBufferStruct
Branch1 pointer to next channel
buffer. When a branch condition is
met, its corresponding branch pointer
is used to select the next buffer. If
both branch conditions are met
simultaneously, branch1 will take
Branch2 pointer to next channel
Pointer to buffer memory.
Length of above buffer.
Current offset into above buffer.
Status of this buffer.
Conditions to meet to take branch1.
Data to use to further specify
Conditions to meet to take branch2.
Data to use to take branch2
Current state of branch2 condition.
Handler to call when a branch is
Data for above handler to use for its
The channel handler field within each of the buffers of the linked list provides a means of accommodating data conversion. For example, video camera 32 may transmit video data in YUV format However, monitor 18 may require the data in RGB format. Thus, a conversion would be required to change the YUV data to RGB data before display. The channel handler can be a set of software instructions to be called whenever a particular channel branch is taken so that after a buffer is filled, the data stored in the buffer can be converted from YUV data to RGB data for display. Thus, the channel handler would specify an address which corresponds to instructions for performing a conversion routine.
Another example of when such a channel handler may be required is when compressed data is being transmitted over the serial bus. Before display, the data would need to be decompressed. The channel handler routine could be used to decompress the data in the manner described for the YUV to RGB translation described above. Other examples of the use of such channel handlers will be apparent to those skilled in the art.
Thus far, the present invention has been described with the assumption that the CPU 10 will manipulate data transferred across the isochronous channel (i.e., the CPU transfers the data to the linked list of buffers within system memory for later transfer to a frame buffer). This need not, however, be the case. In other embodiments, the CPU 10 can establish the isochronous channel without becoming part of the channel. For example, in the situation where a user wishes to record video data produced by camera 32 on a video cassette, the isochronous channel can be established between only video camera 32 and VCR 36. In this example, one driver might be associated with the video camera 32 and a second driver might be associated with the VCR 36. The camera driver would establish the channel ID and add the camera 32 as a sender client in the manner described above. The camera driver would then call the VCR driver and would pass a reference to the channel ID. The VCR driver would add the VCR 36 as a listener client as described above. Once all of the clients have been added to the channel, the “start” instruction can be issued as described above. No linked list of buffers is required because the VCR 36 can record the video data directly (it need not be in frames). Now, isochronous data (i.e., video data) will be transmitted from the camera 32 to the VCR 36 without interrupting the CPU 10 (which is not a client of the isochronous channel). Those skilled in the art will appreciate that any number of clients can be added to the isochronous channel in this fashion to accommodate the required data transfer.
Although the methods of the present invention have been described with reference to the use of a linked list of buffers at the receiving node, those skilled in the art will appreciate that a similar configuration of buffers could be used at the sending node. In such an embodiment, isochronous data would be stored in a linked list of buffers similar to that described above and transmitted over the isochronous channel as network conditions permit.
Thus a system and method for managing isochronous data channels within a computer system has been described. In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be appreciated by those skilled in the art that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are accordingly, to be regarded in an illustrative rather than a restrictive sense.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5317692 *||Jan 23, 1991||May 31, 1994||International Business Machines Corporation||Method and apparatus for buffer chaining in a communications controller|
|US5406559 *||Nov 2, 1992||Apr 11, 1995||National Semiconductor Corporation||Isochronous link protocol|
|US5440556 *||Nov 1, 1993||Aug 8, 1995||National Semiconductor Corporation||Low power isochronous networking mode|
|US5452420 *||May 6, 1992||Sep 19, 1995||Allen-Bradley Company, Inc.||Intelligent network interface circuit for establishing communication link between protocol machine and host processor employing counter proposal set parameter negotiation scheme|
|US5566169 *||Nov 1, 1993||Oct 15, 1996||National Semiconductor Corporation||Data communication network with transfer port, cascade port and/or frame synchronizing signal|
|US5594732 *||Mar 3, 1995||Jan 14, 1997||Intecom, Incorporated||Bridging and signalling subsystems and methods for private and hybrid communications systems including multimedia systems|
|US5594734 *||Nov 1, 1993||Jan 14, 1997||National Semiconductor Corporation||Asynchronous processor access to a switch table in a network with isochronous capability|
|US5617418 *||Nov 1, 1993||Apr 1, 1997||National Semiconductor Corporation||Network link detection and generation|
|US5668811 *||Jun 7, 1995||Sep 16, 1997||National Semiconductor Corporation||Method of maintaining frame synchronization in a communication network|
|US5754789 *||Apr 15, 1996||May 19, 1998||Sun Microsystems, Inc.||Apparatus and method for controlling point-to-point interconnect communications between nodes|
|US5815678 *||Jul 14, 1995||Sep 29, 1998||Adaptec, Inc.||Method and apparatus for implementing an application programming interface for a communications bus|
|US6243783 *||Jun 21, 1999||Jun 5, 2001||Sony Corporation||Application programming interface for managing and automating data transfer operations between applications over a bus structure|
|USRE38641 *||Aug 17, 2001||Oct 26, 2004||Apple Computer, Inc.||Isochronous channel having a linked list of buffers|
|1||*||Apple Computer, Inc., "Interim Draft, Designing PCI Cards and Drivers for Power MacIntosh Computers", A8 Draft-Preliminary Information, pp. 1-372, (Mar. 9, 1995).|
|2||*||High Performance Serial Bus Working Group of the Microprocessor and Microcomputer Standards Committee, "P1394 Standard for a High Performance Serial Bus", P1394 Draft 8.0v3, pp. 1-364, (Oct. 16, 1995).|
|3||*||ISO/IEC 13213 ANSI/IEEE Standard 1212, "Information Technology-Microprocessor Systems-Control and Status Registers (CSR) Architecture For Microprocessor Buses", First Edition, pp. 1-125, (Oct. 5, 1994).|
|4||*||Philips Electronics et al, Digital Interface for Consumer Electronic Audio/Video Equipment Draft Version 2.0, IEEE 1394 Trade Association Meeting, pp. 1-47, Part 2-pp. 1-6, (Oct. 1995).|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7876787 *||Nov 26, 2004||Jan 25, 2011||Thomson Licensing||Method for monitoring the state of a device in a network and device for carrying out said monitoring|
|US20070088859 *||Nov 26, 2004||Apr 19, 2007||Olivier Bureller||Method for monitoring the state of a device in a network and device for carrying out said monitoring.|
|Mar 21, 2011||REMI||Maintenance fee reminder mailed|
|Apr 20, 2011||SULP||Surcharge for late payment|
Year of fee payment: 11
|Apr 20, 2011||FPAY||Fee payment|
Year of fee payment: 12