TECHNICAL FIELD
The present invention relates generally to systems having a host device and one or more secondary devices that include a storage media, and more particularly to systems and system components for transferring data between a host device and a secondary device.
BACKGROUND OF THE INVENTION
The decreasing cost and increased capacity of portable mass storage media has resulted in numerous secondary devices with an increased ability to store relatively large sized media files, such as picture files, music files, and/or video files, as but a few examples. Secondary devices can take numerous forms, such as audio or video players (e.g., MP3 type players), cell phones incorporating audio/video players, portable gaming devices, personal digital assistants (PDAs), digital still and/or video cameras, and other devices integrating such functions, to name but few.
Typically, a secondary device can include an interface by which data can be transferred out of a host device into the secondary device and/or from the secondary device into the host device. A host device can be a device that can control such data transfers, and can also take various forms. For example, a host device can be larger device, such as a personal computer (PC). However, a host device can be a smaller device, such as another secondary device designated as a host, or some other device type such as a home entertainment system, gaming console, printer, automobile entertainment system, to name but a few of the many possible examples.
Data transfers between a host and secondary device are usually executed according to a predetermined protocol and interface. As but one very particular example, the Media Transfer Protocol (MTP), promulgated by Microsoft Corporation can be used for content exchange between a desktop host system and a secondary device, such as mobile handsets. MTP can operate in conjunction with a universal serial bus (USB) type interface.
In certain secondary device designs, a USB interface and storage functions can be placed in a device such as a bridge/controller.
To better understand various features of the disclosed embodiments, two examples of conventional approaches to implementing MTP type transfers will now be described.
Referring now to FIG. 10, a conventional system is shown in a block diagram and designated by the reference character 1000. Conventional system 1000 can include a host device 1002 and a secondary device 1004. A secondary device 1004 can include a processor 1006, a bridge/controller 1008, and one or more storage sections 1010 (different storage sections shown as 1010-0 and 1010-1). A processor 1006 can include a file system 1011 that can organize data files stored within storage sections 1010. Thus, processor 1006 has direct access to file system 1011.
A bridge/controller 1008 can have a USB interface (I/F) 1012, a processor I/F 1014, and a store I/F 1016. A USB I/F 1012 can provide a communication path between secondary device 1004 and host device 1002. Similarly, a processor I/F 1014 and store I/F 1016 can provide communication paths between bridge/controller 1008 and processor 1006 and storage sections 1010, respectively. Bridge/controller 1008 can provide communication paths between I/Fs 1012, 1014 and 1016.
FIG. 10 also shows two communication processing paths, a data path 1018 and a control path 1020.
In the conventional approach shown in FIG. 10, an MTP type transfer can be implemented “inside” processor 1006. That is, all communication traffic (both control and data) can go through processor 1006. In such an arrangement, a processor 1006 can maintain a file system that includes information on data files contained within store section 1010 and can directly control traffic during accesses to storage section 1010. For example, during a file download operation, data packets can travel from host device 1002 through host I/F 1012 through bridge/controller 1008 and to processor 1006, via processor I/F 1014. Such packets can then travel from processor 1006 to storage section 1010 via store I/F 1016. This manner of operation is conceptualized in FIG. 10 by data path 1018 and control path 1020 both passing from host device 1002 through processor 1006 to storage section 1010.
A conventional arrangement like that of FIG. 10 can have limited throughput as data travels from a host device 1002 to a processor 1004 and then from processor 1004 to storage section 1010. In addition, such a conventional arrangement can require relatively large overhead (e.g., processing power, instruction set size and/or memory capacity) to control such operations. In particular, such operations can consume an undesirably large amount of processor resources (memory, processor cycles) that might otherwise be used for executing other tasks associated with the secondary device 1004.
Referring now to FIG. 11, a second conventional system is shown in a block diagram and designated by the general reference character 1100. A system 1100 can include some of the same general components as that of FIG. 10, thus like components are referred to by the same reference character but with the first two digits being “11” instead of “10”.
System 1100 of FIG. 11 can differ from that of FIG. 10 in that a bridge/controller 1108′ can include greater hardware resources than that shown as 1008 in FIG. 10. In particular, a bridge controller 1108′ can have direct access to a file system 1111′, and can include additional computing power to enable packet processing. Such additional resources can enable MTP type transfers to be implemented within bridge/controller 1108′. For example, during a file download operation, data packets can travel from host device 1102 to bridge/controller 1108′. Bridge/controller 1108′ can then determine and track where such files are be stored, and output such files to storage section 1110. This manner of operation is conceptualized in FIG. 11 by data path 1118-H and control path 1120-H both passing from host device 1102 through bridge controller 1108′ to storage section 1110. At the same time, another data path 1118-P and control path 1120-P are shown passing from processor 1106′ through bridge controller 1108′ to storage section 1110.
A conventional system 1100 shown in FIG. 11 can require a higher performance computing circuit within bridge controller 1108′ than the other conventional example of FIG. 10. In addition, a bridge/controller 1108′ can require a larger memory size, as a file system 1111′ is maintained within the bridge/controller. This can result in greater cost and/or size for a secondary device 1104.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 shows a block diagram of a system according to one embodiment of the invention.
FIGS. 2A to 2C show a bridge/controller device and associated configurations according to embodiments of the invention.
FIGS. 3A to 3D show another bridge/controller device and associated operations according to another embodiment of the invention. FIGS. 3E to 3I show a bridge/controller device and associated operations according to a further embodiment.
FIGS. 4A to 4I show yet another bridge/controller device and associated operations according to another embodiment of the invention.
FIGS. 5A to 5C show instructions executable by a controller circuit of a bridge/controller device according to another embodiment.
FIGS. 6A to 6I are block diagrams showing a method of transferring files according to a protocol of one embodiment of the invention.
FIGS. 7A to 7C show the processing of one type of data container according to an embodiment of the invention.
FIG. 8 is a flow diagram of a method according to an embodiment.
FIG. 9 is state diagram showing file transfer operations according to another embedment.
FIG. 10 is a block diagram of a first conventional file transfer system.
FIG. 11 is a block diagram of a second conventional file transfer system.
DETAILED DESCRIPTION
Various embodiments will now be described in detail that show methods, systems, selected system components, and protocols for transferring data between a host device and a device having a storage medium. Embodiments can include a “split” transfer method that can provide a data transfer path between a host device and storage interface in a secondary device that can bypass a secondary device processor. Such an arrangement can provide significant throughput advantages over conventional arrangements like that shown in FIG. 10.
Referring now to FIG. 1, a system according to a first embodiment is shown in a block diagram and designated by the reference character 100. System 100 can include a host device 102 and a secondary device 104. A secondary device 104 can include a processor 106, a bridge/controller 108, and one or more storage sections 110 (different storage sections shown as 110-0 and 110-1).
A processor 106 can include a file system 111 that can organize data files stored within storage section 110. As but one example, a file system 111 can be stored in a memory (e.g., random access memory) accessible by a processing unit of processor 106. A file system can provide information on files, such as a file identifier (e.g., a file handle), file size (e.g., number of bytes), file location (e.g., file relation to higher level structures, such as folders, as well as physical address(es) for data of the file), to name but a few examples. Thus, file system storage and maintenance can be undertaken by a processor 106 and not a bridge/controller 108.
A bridge/controller 108 can have a host interface (I/F) 112, a processor I/F 114, and a storage I/F 116. In the embodiment of FIG. 1, a host I/F 112 can provide a communication path between a host device 102 and bridge/controller 108, a store I/F 116 can provide a communication path between bridge/controller 108 and storage section 110, and a processor I/F 114 can provide a communication path between bridge/controller 108 and processor 106.
However, unlike the conventional approaches described above, a bridge/controller 108 can provide configurable data paths between I/Fs (112, 114 and 116) that can be switched according to operation and/or data type (e.g., control or data). More particularly, a bridge/controller 108 can transfer control data from a host I/F 112 to a processor I/F 114 by a path that bypasses a storage I/F 116. In addition, bridge/controller 108 can transfer data from a host I/F 112 to a storage section 110 by a path that can bypass a processor I/F 114. Such an arrangement can allow for fast data transfers to storage section 110, as such transfers do not pass through to a processor 106, as in the case of FIG. 10. At the same time, file system information can be maintained by a processor 106 rather than a bridge/controller 108, allowing bridge/controller 108 to be smaller, less expensive, or have additional resources that would otherwise be dedicated to a file system, as in the case in FIG. 11.
Such advantageous processing paths are shown in FIG. 1. FIG. 1 shows two communication paths, a data path 118 and a control path 120. Unlike the conventional approach shown in FIG. 10, a data path 118 can pass from a host I/F 112 to a storage I/F 118, and not pass through processor I/F 114. At the same time, a control path 120 can pass from host I/F 112 to processor I/F 118.
In this way, a system can provide separate communication paths through a bridge/controller depending upon whether data or control information is been received or sent.
Having described one example of system that can include a secondary device with a bridge/controller, a particular example of a bridge/controller will now be described.
Referring to FIG. 2A, a bridge/controller according to one embodiment is shown in a block schematic diagram and designated by the general reference character 200. In one very particular arrangement, a bridge/controller 200 can be considered related to the embodiment of FIG. 1 in that it can represent one example of bridge/controller shown as 108. A bridge/controller 200 can include some of the same general sections as that shown In FIG. 1, thus like sections are referred to by the same reference character but with the first digit being a “2” instead of a “1”.
As shown in FIG. 2A, in addition to I/Fs 212, 214, and 216, bridge/controller 200 can include a controller circuit 218, control registers 220, and a link circuit 222. In the particular example of FIG. 2A, a host I/F 212 can be serial I/F receiving data in serial format and providing such data in parallel form to a link circuit 222. In one very particular arrangement, a host I/F 212 can be a universal serial bus (USB) transceiver.
A controller circuit 218 can execute predetermined operations in response to selected inputs. As but one example, a controller circuit 218 can be a microcontroller having an instruction store (e.g., firmware) and operational memory (e.g., random access memory). Such a microcontroller can execute predetermined instructions in response to commands received via a processor I/F 214.
Control registers 220 can be addressable storage locations that can output values for controlling the configuration of link circuit 222, and optionally, any of I/Fs 212, 214 and/or 216. In this way, a controller circuit 218 can configure bridge/controller 200 by writing values to registers. In alternate embodiments, a controller 220 could directly output control signals to such other sections.
A link circuit 222 can be connected between I/Fs 212, 214 and 216, and can provide configurable paths between such I/Fs based on configuration data contained within control registers 220 or control values provided from I/F 214.
Having described the general construction of the bridge/controller 200, examples of bridge/controller 200 operations will now be described with reference to FIGS. 2B and 2C.
FIG. 2B shows the bridge/controller 200 of FIG. 2A configured to create a control data path. In the example shown, in response to received control data, a processor connected to processor I/F 214, or alternatively controller circuit 218, can write values to control registers 220 that configure link circuit 222 to provide a communication path between host I/F 212 and processor I/F 214. For example, a link circuit 222 can receive a packet. A controller circuit 218 can examine the packet and determines that it contains control information. In response to such a determination, controller circuit 218 can transfer the data packet via a data path between host I/F 212 and processor I/F 214. It is understood that “control data” can be data utilized by a secondary device 200 to configure or alter the operation of the device, or other devices attached to the secondary device 200 (e.g., a command). This is in contrast to “data for storage” which is a data intended for storage within a secondary device (e.g., a media file).
FIG. 2C shows the bridge/controller 200 of FIG. 2A configured to create a data path. Such a configuration can be established by a processor connected to processor I/F 214 (not shown). Like FIG. 2B, in response to received data intended for storage, link circuit 222 can provide a path between host I/F 212 and storage I/F 216. Such a path can bypass a processor I/F 214. For example, a link circuit 222 can receive a packet. A controller circuit 218 can examine the packet and determines that it contains data for storage. In response to such a determination, controller circuit 218 configures a data path between host I/F 212 and storage I/F 216.
In this way, a link circuit can be configured to provide an essentially direct path for data depending upon the type of data being transferred.
Referring now to FIGS. 3A to 3D a bridge/controller according to another embodiment is shown in block schematic diagram, and designated by the general reference character 300. As in the case of FIG. 2A, in one very particular arrangement, the bridge/controller 300 can be considered related to the embodiment of FIG. 1 in that it can represent one example of bridge/controller shown as 108. A bridge/controller 300 can include some of the same general sections as that shown In FIG. 1, thus like sections are referred to by the same reference character but with the first digit being a “3” instead of a “1”.
In the arrangement of FIG. 3A, a bridge/controller 300 can include a link circuit 322′ situated between I/Fs 312, 314 and 316. Link circuit 322′ can include a de-multiplex (de-MUX) data path 324 and a multiplex (MUX) data path 326. A de-MUX data path 324 can include a de-MUX input 328 connected to an output of host I/F 316, a first output 330-0 connected to storage I/F 316, and a second output 330-1 connected to processor I/F 314. In response to data received on a first control signal path 336-0, de-MUX data path 324 can be configured to transfer data at de-MUX input 328 to either of first or second outputs (330-0 and 330-1).
In a similar fashion, a MUX data path 326 can include a MUX output 332 connected to an input of host I/F 316, a first input 334-0 connected to storage I/F 316, and a second input 334-1 connected to processor I/F 314. In response to data received on a second control signal path 336-1, MUX data path 326 can be configured to provide a data path from either of MUX inputs (334-0 and 334-1) to MUX output 332.
In the arrangement of FIG. 3A, a processor connected to I/F 214 or controller circuit 318 can place configuration information on first and second control signal paths (336-0 and 336-1). It is noted that while FIG. 3A shows separate control signal paths (336-0 and 336-1), alternate embodiments can include common control of both de-MUX data path 324 and MUX data path 326. That is, de-MUX data path 324 and MUX data paths 326 can simultaneously switch in response to the same control signal(s). Further, control signals can be provided to link circuit 322′ by way of registers, or the like, accessible by a processor via I/F 214, by controller circuit 318, or both.
FIGS. 3A to 3D also represent particular signal paths according to the type of information carried by such paths during file transfer operations. In particular, as shown by key 338, a host I/F 312 can provide both data (i.e., data intended for storage) and control values to de-MUX data path 324. In contrast, a first output 330-0 of de-MUX data path 324 can be utilized to transfer large data values and not control values. In contrast, a second output 330-1 of de-MUX data path 324 can be utilized to provide control values and not large data values. More particularly, in predetermined operations that involve the transfer of large amounts of data from host I/F 312 to storage I/F 316 first output 330-0 can provide an essentially direct path for file data values while second output 330-1 can provide a path for control values. In contrast, for relatively small data transfers or as dictated by a processor at I/F 214, both control values and data values can be transferred via second output 330-1.
MUX data path 326 can be conceptualized as operating in the reverse fashion. For example, a host I/F 312 can receive both data and control values from output 332 of MUX data path 326, while a first input 334-0 of MUX data path 326 can receive data values and not control values in certain large data transfers, and a second input 334-1 of MUX data path 326 can receive control values and not data values such large data transfers. For smaller data transfer operations or particular operations established by a processor at IF 214, second input 334-1 can carry both control and data values.
Having described the general construction of a bridge/controller 300 with reference to FIG. 3A, the operation of such a bridge/controller will now be described with reference to FIGS. 3B to 3D.
FIG. 3B shows a bridge/controller 300 in a control mode of operation. De-MUX data path 324 can be configured to forward values received at de-MUX input 328 to processor I/F 314. As but one example, a request packet that includes a particular operation request can be sent along such a data path for subsequent processing by a processor connected to processor I/F 314. FIG. 3B also shows MUX data path 326 configured to forward values received at second input 334-1 to MUX output 332. Again, as but one example, a response packet that includes a result of a particular requested operation can be sent along such a data path and received by a host device connected to host I/F 312.
In this way, a bridge/controller 300 can be configured to send and receive control values between a host device and a processor.
FIG. 3C shows a bridge/controller 300 in a data transfer OUT mode of operation. In this description, data transfer operation directions (i.e., IN or OUT) are referenced with respect to a host I/F 312. Thus, a data OUT operation illustrates data being transferred from a host I/F 312 to a storage I/F 316. In the configuration of FIG. 3C, de-MUX data path 324 can be configured to forward values received at de-MUX input 328 to storage I/F 316. Such a path does not include, and can completely bypasses processor I/F 316. In one particular application, a data packet, or sequence of data packets, can be sent along such a data path for subsequent storage within a storage device connected to storage I/F 316. FIG. 3C also shows the same essential MUX data path 326 as FIG. 3B. In one example, such a path can be utilized to send a response packet once a data transfer operation has been completed.
FIG. 3D shows a bridge/controller 300 in a data transfer IN mode of operation. In such an operation MUX data path 324 can be configured to forward data received at first MUX input 334-0 to MUX output 332. As in the data OUT mode of operation, such a path does not include, and completely bypasses processor I/F 316.
In this way, a bridge/controller 300 can be configured to transfer data values, more particularly large numbers of data values, between a storage device and host device along a path independent of a path utilized for control data.
Referring now to FIGS. 3E to 3I, a bridge/controller according to yet another embodiment is shown in block schematic diagram, and designated by the general reference character 350. As in the case of FIG. 3A, in one very particular arrangement, the bridge/controller 350 can be considered related to the embodiment of FIG. 1 in that it can represent one example of bridge/controller shown as 108. A bridge/controller 350 can include some of the same general sections as that shown In FIG. 3A, thus like sections are referred to by the same reference character.
The bridge/controller 350 can differ from that of FIGS. 3A to 3D in that it can include a first first-in-first-out (FIFO) memory 370 and a second FIFO memory 372. First FIFO memory 370 can be arranged between host I/F 312 and de-MUX input 328. Second FIFO memory 372 can be arranged between host I/F 312 and MUX output 332. Various operations for the embodiment shown in FIGS. 3E to 3I will now be described.
Referring to FIG. 3E, a bridge/controller 350 can have an initial or default state in which de-MUX data path 324 and MUX data path 332 are configured as shown. That is, de-MUX data path 324 provides a path from first FIFO memory 370 to processor I/F 314, and MUX data path 326 provides a path from processor I/F 314 and second FIFO memory 372. In such a state, a host device (not shown) can issue control and data information along path 374 as shown. Such information can be stored in first FIFO memory 370, and then forwarded through de-MUX data path 324 to a processor connected to processor I/F 314.
Referring to FIG. 3F, in response to information received from a host device, a processor can provide configuration information (CFG) that can directly, or indirectly via controller circuit 318, reconfigure de-MUX data path 324 and MUX data path 326. In particular, de-MUX data path 324 can be reconfigured to provide a path from first FIFO memory 370 to storage I/F 316, and MUX data path 326 can be reconfigured to provide a path from processor I/F 314 to second FIFO memory 372. Such a reconfiguration can take place prior to a large data transfer operation between host I/F 312 and storage I/F 316.
Referring to FIG. 3G, one example of a data transfer following the above reconfiguration operation is shown. A host device can output file data along path 376 as shown. In particular, file data originating from a host device can be received at host I/F 312 and stored in first FIFO memory 370. Once first FIFO memory 370 is filled, such data can be forwarded through de-MUX path 324 to storage I/F 316 for storage in a storage device.
Referring to FIG. 3H, another example of a data transfer following the above reconfiguration operation is shown. A storage device (not shown) can output file data along path 378 as shown. In particular, file data originating from a storage device can be received at storage I/F 316 and forwarded through MUX path 326 and stored in second FIFO memory 372. Once second FIFO memory 372 is filled, such data can be output to a host device via host I/F 312.
Referring to FIG. 3I, following the completion or termination of a data transfer operation, a processor can return a bridge/controller 350 to an original configuration. More particularly, a processor can provide configuration information (CFG) that can directly, or indirectly via controller circuit 318, reconfigure de-MUX data path 324 and MUX data path 326 to the same state as shown in FIG. 3E. In addition, a processor can provide control information confirming such an operation along control path 380 as shown.
In this way, for predetermined operations, such as the transfer of relatively large data files, a bridge/controller can be switched to provide an essentially direct data path between a host device and storage device.
Referring now to FIGS. 4A to 4I a bridge/controller according to yet another embodiment is shown in block schematic diagram, and designated by the general reference character 400. As in the case of FIG. 2A, in one very particular arrangement, the bridge/controller 300 can be considered related to the embodiment of FIG. 1 in that it can represent one example of bridge/controller shown as 108. A bridge/controller 400 can include some of the same general sections as that shown In FIG. 1, thus like sections are referred to by the same reference character but with the first digit being a “4” instead of a “1”.
In the embodiment illustrated in FIGS. 4A to 4I, in addition to controller 418 and I/Fs 412, 414 and 416, a bridge/controller 400 can include a link circuit 423 and an endpoint indicator 440. Link circuit 423 can include a MUX section 442 and a buffer section 444. A MUX section 442 can include an input MUX 446 and an output de-MUX 448. An input MUX 446 can have one input connected to a host I/F 412, another input connected to a processor I/F 414, and an output connected to buffer section 444. An output de-MUX 448 can have one output connected to a host I/F 412, another output connected to a processor I/F 414, and an input connected to buffer section 444. A MUX section 442 can be configurable between a host direction (input MUX 446 inputs data from host I/F 412; output de-MUX 448 outputs data to host I/F 412) and a processor direction (input MUX 446 inputs data from processor I/F 414; output de-MUX 448 outputs data to processor I/F 414).
A buffer section 444 can include a number of buffers, each assigned to an “endpoint” within bridge/controller 400. In the very particular example shown, buffer section 444 can include a first endpoint buffer 450 and a second end point buffer 452. Each endpoint buffer (450 and 452) can be configurable to operate in an OUT direction (receive data from MUX section 442) or operate in an IN direction (output data to MUX section 442). In addition, a first endpoint buffer 450 can additionally output data to store I/F 416, while second endpoint buffer 452 can input data from store I/F 416.
In one very particular arrangement, first and second endpoint buffers (450 and 452) can be first-in-first-out (FIFO) memory circuits that can track how much storage is occupied by an incoming data packet, provide an interrupt when a data packet transfer is complete (data completely read from buffer, or completely written to buffer), and maintain a transaction status indicator (i.e., toggle value) to maintain synchronization with a host device during a data transfer operation.
An endpoint indicator 440 can receive an endpoint value from a host I/F 412 that indicates an intended endpoint for a received packet.
Controller circuit 418 can provide configuration values for interfaces 412, 414, and 416, and in addition can access endpoint indicator 440, first endpoint buffer 450, and second endpoint buffer 452. A controller circuit 418 can also include a direct communication path 454 to processor interface 414 that does not pass through MUX section 442. In the particular example illustrated, controller circuit 418 can also configure host I/F 412 into a “no acknowledgement” state, in which accesses to given endpoints will not be acknowledged by host I/F 412.
It is noted that FIG. 4A shows one example of an initial configuration for a bridge/controller 418. In particular, first endpoint buffer 450 is configured in the OUT direction, and so can receive data values via input MUX 446, while second endpoint buffer 452 is configured in the IN direction, and so can output data values to output de-MUX 448. In addition, MUX section 442 is shown configured in the host direction.
Having described the general construction of a bridge/controller 400 with reference to FIG. 4A, various operation of such a bridge/controller will now be described with reference to FIGS. 4B to 4I. In the following description a processor I/F 414 will also be referred to as a processor port (P-port), while a storage I/F 416 will also be referred to as a storage port (S-port).
Referring to FIG. 4B, a bridge/controller 400 can receive an OUT packet 456 from host I/F 412, which can be stored in first endpoint buffer 450. Because the type of packet (e.g., data or control) is not immediately known, such a packet has a label “?”. Once the OUT packet 456 has been received, a first endpoint buffer 450 can generate an interrupt for controller circuit 418. In response to the interrupt, controller circuit 418 can access endpoint indicator 440 to determine if the OUT packet 456 is for a valid endpoint (in this case endpoint “2” or EP2). If the packet is for EP2, controller circuit 418 can read a predetermined portion of OUT packet 456 which can indicate the type of packet. More particularly, if such read data indicates a control packet, the packet's appropriate destination is P-port 414. However, if the read data indicates a data packet, the packet's appropriate destination is S-port 416.
The operation of a bridge/controller 400 in response to an S-port OUT packet is shown in FIG. 4C.
Referring to FIG. 4C, upon determining that a received packet is a data packet, a controller circuit 418 can automatically output data from first endpoint buffer 450 to S-port 416. More particularly, a controller circuit 418 can receive, or can have previously received, file attribute data for a transfer operation as well as an indication of when a file transfer is to start. Such file attribute data can indicate how much data is to be transferred (e.g., number of bytes and/or number of packets), and where such data is to be transferred (e.g., physical addresses of a storage device accessed by S-port 416). According to such attribute data, controller circuit 418 can configure first endpoint buffer 450 to output data until an entire file has been received and output to S-port 416. At the same time, controller circuit 418 can configure S-port 416 to write data as it is received.
Once all data for a given data OUT operation has been transferred, first endpoint buffer 450 can generate an interrupt to controller circuit 418. In response to such an interrupt, controller circuit 418 can send a notification to P-port. In response to the notification, a response packet (an IN packet) can be generated by a processor connected to P-port. One example showing the generation of an IN response packet is shown in FIGS. 4D and 4E.
Referring to FIG. 4D, after a predetermined operation (e.g., data transfer), a response packet can be received from P-port 414. In the particular example shown, the sending of a response packet can include controller circuit 418 configuring host I/F 412 into the no acknowledgement (NAK) state. In such a state, access/inquiries directed to first and second endpoints (EP2 and EP4 in this particular example) will not be acknowledged. In addition, a second endpoint buffer 452 can be configured to the OUT direction, and MUX section 442 can be set to the processor direction. A controller circuit 418 can also store a transaction indication (e.g., toggle value) for second endpoint buffer 452. Controller circuit 418 can then indicate to a processor, via communication path 454, that a packet can be written. Such a processor can then write a response packet 458 to second endpoint buffer 452.
Referring to FIG. 4E, after a processor completes the writing of a response packet to second endpoint buffer 452, second endpoint buffer 452 can generate an interrupt for control circuit 418. In response to such an interrupt, control circuit 418 can configure second endpoint buffer 452 into the IN direction, restore the toggle value for the second endpoint buffer 452, and switch MUX section 442 back to the host direction. Further, controller circuit 418 can restore host I/F 412 to an acknowledging state. A host can then read the response packet via host I/F 412.
Referring back to FIG. 4B, it will be recalled that a bridge/controller 400 can provide a different configuration depending upon whether a received OUT packet was for an S-port 416 or a P-port 414. One example of the operation of a bridge/controller 400 in response to an S-port OUT packet was shown in FIG. 4C. An example of the operation of a bridge/controller 400 in response to a P-port OUT packet will now be described with reference to FIG. 4F.
Referring to FIG. 4F, upon determining that a received OUT packet stored within a first endpoint buffer 450 is a control packet 460, a controller circuit 418 can send such a packet to P-port 414. In the particular example shown, the sending of such a control packet can include controller circuit 418 configuring host I/F 412 into the no acknowledgement (NAK) state. A controller circuit 418 can then store a transaction indication (e.g., toggle value) for first endpoint buffer 450. First endpoint buffer 450 can be configured to the IN direction, and MUX section 442 can be set to the processor direction. Controller circuit 418 can then indicate to a processor, via communication path 454, that a packet is ready to be read. Such a processor can then read the control packet 460 from first endpoint buffer 450. Following such an operation, a bridge/controller 400 can return to the original state as shown in FIG. 4A.
While FIGS. 4B to 4F have illustrated configurations for data and control IN packets, a bridge/controller 400 can also be configured for data OUT packets.
Referring to FIG. 4G, in response to predetermined instructions from a processor, data can be automatically read from S-port 416 to a second endpoint buffer 452. More particularly, a controller circuit 418 can receive, or can have previously received, file attribute data for a transfer operation as well as an indication of when a file transfer is to start. Like the OUT data packet operation like that shown in FIG. 4C, such file attribute data can indicate how much data is to be transferred (e.g., number of bytes and/or number of packets), and can also include where such data is presently stored (e.g., physical addresses of a storage device accessed by S-port). According to such attribute data, controller circuit 418 can configure S-port 416 to read such data to second endpoint buffer 452. At the same time, a host can read data from second endpoint buffer until an entire file has been read. Once all data for a given operation has been transferred, a response packet (an IN packet) can be generated as described with reference to FIGS. 4D and 4E.
FIGS. 4B and 4F show one example of how a control data path can be created. In particular, FIG. 4B shows how an OUT packet can be received and examined, and FIG. 4F shows how once an OUT packet is determined to be a control packet, it can be output by switching a direction of first endpoint buffer 450 and MUX section 442. However, the structure illustrated in FIGS. 4A to 4I can provide such a data path in an alternate fashion. Such an alternate control data path is shown in FIGS. 4H and 4I.
Referring to FIG. 4H, upon determining that a received OUT packet within a first endpoint buffer 450 is a control packet 460, a controller circuit 418 can configure host I/F 412 into the no acknowledgement (NAK) state, store transaction indications (e.g., toggle values) for first and second endpoint buffers 450 and 452. Second endpoint buffer 452 can be configured to the IN direction, and MUX section 442 can be set to the processor direction. Controller circuit 418 can then copy the control packet 460 from first endpoint buffer 450 to second endpoint buffer 452.
Referring to FIG. 4I, once control packet 460 has been copied to second endpoint buffer 452, controller circuit 418 can switch MUX section 442 to the processor direction. Controller circuit 418 can then indicate to a processor, via communication path 454, that a packet is ready to be read. Such a processor can then read the control packet 460 from second endpoint buffer 452. Following such an operation, a bridge/controller 400 can return to the original state shown in FIG. 4A.
In this way, a control data path can be provided by copying a packet from one buffer to another, and then switching an output MUX direction. This type of operation can be less effective in data throughput than the approach shown by FIGS. 4B and 4F.
While the embodiments have shown systems and bridge/controllers that can be included in such systems, the present invention can also include machine readable instructions executed by a controller circuit. One such embodiment is shown in FIGS. 5A to 5C. FIGS. 5A to 5C show instructions and operations executable by a microcontroller that can serve as a controller circuit in any of the embodiments described herein. The general flow is described in “pseudocode” form, which can be equivalently represented by those skilled in the art into a suitable instruction set for execution by a processor. Preferably, such instructions are firmware for a microcontroller.
FIG. 5A shows a series of instructions that can be included in a main routine. FIGS. 5B and 5C show subroutines SUB1 and SUB2 that can be called by the main routine of FIG. 5A.
Referring to FIG. 5A, lines 1-4 show steps to establish an initial configuration, like that shown in FIG. 4A. Lines 5-19 show steps for a request “SendFileData” which can perform operations like those shown in FIGS. 4B to 4E. Lines 20-34 show steps for a request “GetFileID” which can perform operations like those shown in FIGS. 4B, 4F and 4G.
In this way, a set of instructions can create configurable data paths for fast data transfer from a host device to a storage device.
The present invention can also includes a method of transferring a file, such as a media file, from a host device to a secondary device. Such a method can take the form of a communication protocol for execution between a host device and a secondary device that includes a storage device. Such a protocol is shown in FIGS. 6A to 6I.
FIGS. 6A to 6I show a system in a block diagram and designated by the general reference character 600. System 600 can include a host device 602 and a secondary device 604. A secondary device 604 can be connected to a host device 602 by a communication path 606, which can be a wired path or a wireless path. A secondary device 604 can include a device processor 606, a bridge/controller 608, and a storage device 610. A device processor 606 can include a file system 612 that can organize files stored within storage device 610.
In very particular arrangements, FIGS. 6A to 6I can be considered related to the above embodiments, as a system 600 can be one version of the system shown in FIG. 1, and bridge/controller 608 can include any of the bridge/controllers shown herein and equivalents.
FIGS. 6A to 6I show a protocol that includes three phases, a request phase, a transfer phase, and an acknowledgement phase. In a request phase, a host device 602 can issue a request to a secondary device 604. In a transfer phase, data can be transferred between host device 602 and secondary device 604. In an acknowledgement phase, a secondary device 604 can generate a response indicating the results of the requested operation.
FIGS. 6A to 6C show the execution of a “SendFileInfo” operation by system 600 according to a three phase protocol. Such a request can provide file information to a secondary device 604.
FIG. 6A shows a system 600 in a request phase of a “SendFileInfo” operation. A host device 602 issues a SendFileInfo request to a secondary device 604. Bridge/controller 608 can be initially configured to pass such a request through to a device processor 606. Such a request can indicate to a device processor 606 that file information will follow from a host device 602.
FIG. 6B shows system 600 in a transfer phase of a “SendFileInfo” operation. A host device 602 can send file attribute data to secondary device 604. As but one example, such data can include a file name, file size, and other information for organizing the file in a file system (e.g., target folder). Bridge/controller 608 can pass such data to a device processor 606. In response to such data, a device processor 606 can confirm a file corresponding to the file data can be stored (i.e., secondary device meets the parameters necessary to store the file). Device processor 606 can then issue commands to configure bridge/controller 608 to provide a direct path for subsequently transmitted data. For example, bridge/controller 608 can be configured to monitor a received packet to determine if it is a data or control packet, as noted above.
FIG. 6C shows system 600 in an acknowledgement phase of a “SendFileInfo” operation. A device processor 606 can generate a response indicating the status of the request. For example, in the case of the “SendFileInfo” request, such a response can indicate whether or not the data for the file was completely received, or if the file system indicates the file can be accommodated, etc. If secondary device 604 can accommodate the identified file, such an acknowledgement can include a file identifier (e.g., FileID).
FIGS. 6D to 6F show the execution of a “SendFile” request by system 600 according to a three phase protocol. Such a request can send a file from a host device to a secondary device.
FIG. 6D shows a system 600 in a request phase of a “SendFileData” operation. A host device 602 issues a SendFile request to a secondary device 604. A bridge/controller 608 can be configured to examine such a request and forward it as control data to a device processor 606. In response to such a packet, a device processor can issue information to a bridge/controller 608. For example, a device processor 606 can indicate when file data will be sent.
FIG. 6E shows system 600 in a data phase of a “SendFileData” operation. A host device 602 can send file data to secondary device 604. Bridge/controller 608 can pass such data to storage device 610, bypassing device processor 606. In one particular arrangement, in such an operation, a bridge/controller 608 can request block numbers of locations within a storage device 610 from device processor 606. Device processor 606 can provide such blocks, as determined by a file system accessible by device processor 606.
FIG. 6F shows system 600 in an acknowledgement phase of a “SendFileData” operation. In response to bridge/controller 608 indicating whether or not a data transfer was successful, a device processor 606 can generate a response indicating the status of the request. For example, such an acknowledgement can indicate the file was safely transferred, etc.
FIGS. 6G to 6I show the execution of a “GetFile” operation by system 600 according to a three phase protocol. Such a request can have a host device retrieve a file from a secondary device.
FIG. 6G shows a system 600 in a request phase of a “GetFile” operation. A host device 602 issues a GetFile request to a secondary device 604. Such a request can include a file identifier (i.e., file name, object “handle”, or other file identifier). A bridge/controller 608 can be configured to examine such a request and forward it as a control data to a device processor 606. A device processor 606 can determine a location for the requested file (or determine such a file is not stored on secondary device 604). In one arrangement, a device processor 606 can also indicate when a data transfer operation is to start.
FIG. 6H shows system 600 in a data phase of a “GetFile” operation. Bridge/controller 608 can request storage locations for the requested file, and read data from such locations, and output such data to a host device 602. Such an operation can bypass device processor 606.
FIG. 6I shows system 600 in an acknowledgement phase of a “SendFile” operation. In response to an indication from bridge/controller 608 indicating whether or not a data transfer was successful, a device processor 606 can generate a response packet indicating the status of the request.
The above three phase protocol arrangement can be modified to accommodate various particular data transfer conventions. As but one example, in other conventions, an acknowledgement phase can be a “response phase”. That is, the invention can be incorporated for use in any compatible file transfer protocol, preferably those protocols involving media files, including but not limited to video and music files.
In this way, a system can transfer data files between a host device and secondary device with a three phase protocol, where data can be transferred by a path that does not include a device processor.
FIGS. 7A to 7C show one very particular approach to implementing the transfer of data having a particular format.
FIG. 7A shows a data “container” 700. A data container 700 can define the format data must take in a given operation. A data container 700 can be conceptualized as including a header portion 702 and a payload portion 704. More particularly, data container 700 can show how data is formatted in each phase of a three phase protocol, like that shown in FIGS. 6A to 6I. In an even more particular arrangement, FIG. 7A can show a data capsule according to International Standards Organization (ISO) 15740. However, the present invention should not be construed as being limited to any particular protocol, or data format.
A header portion 702 can contain information about the data transmission, while a payload portion 704 can include data to be included in an operation (e.g., stored). Thus, a payload portion 704 can be optional. In the very particular example shown, a header portion 702 can include a LENGTH field that can indicate the total amount of data being sent (e.g., header+payload), a TYPE field that can indicate type of container (e.g., request, data, response), an EVENT field that can indicate a particular type of operation being executed, and an ID field that can indicate where in sequence of transmissions the present data is occurring.
FIGS. 7B and 7C show a logical operation that can be executed on a data container 700 according to an embodiment of the invention. FIG. 7B shows how a header portion 702 can be split off from a payload portion 704.
FIG. 7C shows how data container 700 can be transmitted as an initial packet 706-0, that only includes a header portion 704, and one or more follow on packets 706-1 to 706-n for any corresponding payload. As but one particular example, an initial packet 706-0 can be received by a bridge/controller according to any of the described embodiments, or equivalents. Such a bridge/controller can determine the packet is a data packet (i.e., by field TYPE and/or EVENT), and configure itself to automatically store subsequently transmitted packets 706-1 to 706-n at suitable locations in a storage device.
In this way, a data capsule having a header can be separated into a header only portion and one or more following data portions.
Referring now to FIG. 8, a method according to an embodiment is shown in a flow diagram and designated by the general reference character 800. A method 800 can include sending a packet with data information (step 802). Such a packet can be received by a bridge/controller (step 804). A data path can then be configured based on such data information (step 806). File data can then be automatically transferred between a storage port and a host port, bypassing a local processor that includes a file system for the file (step 808).
In this way, a method can transfer data between a host device and a secondary device by configuring a data path in the secondary device that bypasses a local processor of the secondary device.
While some embodiments of the present invention can be represented by block diagrams and flow diagrams, other embodiments can be represented with a state diagram. One example of such a state machine is shown in FIG. 9.
FIG. 9 shows a state diagram designated by the general reference character 900. A state diagram 900 can include a host executing IN and OUT type operations (902). If an OUT type operation is a request type operation, a controller can receive and check the content of a packet (904). A controller can then execute an operation like that described in subroutine SUB1 of FIG. 5B (906) (e.g., transfer such a packet to a processor). A processor can return a response packet (908). A controller can then execute an operation like that described in subroutine SUB2 of FIG. 5C (910) (e.g., transfer such a packet to a host). A controller can also receive attribute values for a data file sent in the request (step 912).
Referring still to FIG. 9, once a controller has file attribute data, if a host sends an IN data packet, a controller can configure a storage interface to read data from a storage device, and data can be read from the storage I/F (914) by a host. If a host sends an OUT data packet, a controller can configure a storage interface to write data to a storage device, and data received from a host can be written by storage I/F (916) into some storage media.
In this way, data transfer operations can be executed between a host device and a secondary device having a controller, storage I/F, and processor with a file system.
Embodiments of the present invention can be well suited to performing various other steps or variations of the steps recited herein, and in a sequence other than that depicted and/or described herein.
For purposes of clarity, many of the details of the various embodiments and the methods of designing and manufacturing the same that are widely known and are not relevant to the present invention have been omitted from the following description.
It should be appreciated that reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Therefore, it is emphasized and should be appreciated that two or more references to “an embodiment” or “one embodiment” or “an alternative embodiment” in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the invention.
Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.
It is also understood that the embodiments of the invention may be practiced in the absence of an element and/or step not specifically disclosed. That is, an inventive feature of the invention can be elimination of an element.
Accordingly, while the various aspects of the particular embodiments set forth herein have been described in detail, the present invention could be subject to various changes, substitutions, and alterations without departing from the spirit and scope of the invention.
Patent Grant
8315269
