Serial peripheral interface for a transceiver integrated circuit

This application claims the benefit of U.S. Provisional Application No. 60/990,365, filed Nov. 27, 2007, the entirety of which is incorporated herein by reference.

This application is related by subject matter to the subject matter disclosed in the following commonly assigned application, the entirety of which are hereby incorporated by reference: U.S. patent application No. ______ (Attorney Docket No. MSFT-6083/321743.02) filed on May 30, 2008 and entitled “Interface Protocol And API For A Wireless Transceiver.”

A portion of the disclosure of this patent document may contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice shall apply to this document: Copyright© 2008 Microsoft Corp.

The presently disclosed subject matter relates to the field of computing and electronics, and more particularly, to fields such as entertainment consoles, although these are merely exemplary and non-limiting fields.

Video game and entertainment systems are increasingly incorporating new features and accessories. Development of accessories, such as wireless radios, and the necessary drivers require significant design effort. In turn, the commands and protocols required to control and manage the interfaces can be complicated and require significant development resources for developers of software and hardware accessories. Furthermore, technologies and related standards change on a frequent basis, requiring developers to adapt to new interface requirements. Thus a developer\'s investment in developing products for a particular interface may not be recouped when the interfaces and protocols frequently change.

Nevertheless, it would be advantageous to use an existing standard interface developing features and accessories. An interface standard widely used in the industry and supported by a large number of products typically drive down costs, and incorporation of such off the shelf components is desirable to reduce the cost of product development. Furthermore, in the case of a wireless transceiver, it is typically desirable to limit the number of integrated circuit (IC) pins needed to support inter-processor communications, while at the same time providing sufficient data bandwidth. Therefore, a simple serial interface may be selected for a wireless architecture. One such standard interface commonly used and well known in the art that provides such features is the Serial Peripheral Interface (SPI). One limitation of the SPI interfaces is that data transfers are limited to 8 bits at one time. Because many applications may require higher command and data transfer capability, a higher level protocol is needed that has the advantages of a serial interface.

In an SPI link there are typically four different operational modes possible. Both ends of the interface must agree to one before starting communications. This can be accomplished by many methods but they require extra IC pins to be used. Another possibility is to only support one mode and require the Master end to support the selected one. This limits flexibility within the platform. It would be advantageous for devices in an SPI link to be able to select an operational mode without the need for additional pins

Another problem with the SPI interface relates to the need of a Chip Select signal. This is normally used if the bus is shared between multiple slave devices. In an application in which only one slave device is implemented, the Chip Select signal is not required and can be tied to an always active state. This now presents a problem with byte framing on the bus. Each transfer is defined as the movement of one byte of data. If, for some reason a clock edge is missed or an extra created and no method exists to define the correct end of the byte transfer, the Master and Slave would become un-synchronized and self-recovery would not be possible. A method which permits frame timing on the SPI bus to be restored without resetting the slave device would be desirable.

Various systems, methods, and computer readable media are disclosed herein for providing a platform to support the development of new accessories for video game and entertainment systems using serial interfaces such as the Serial Peripheral Interface (SPI). In one exemplary and non-limiting aspect of the present disclosure, a smart transceiver device may contain the complete physical (PHY) and media access control (MAC) layers of a wireless protocol stack, and the wireless protocol functionality may be partitioned into a single device.

In various embodiments, a protocol is disclosed that may be used to provide control and data transfer to and from such a smart transceiver device. In particular, an exemplary format for the protocol, the commands, and responses is disclosed. Such an exemplary format may be suitable for use in both wired and wireless implementations.

In a further embodiment, a method for mode synchronization that does not require the use of additional pins and can be accomplished with the standard SPI pins is disclosed. In an embodiment, the method used to select the correct mode used by the slave occurs immediately after a slave reset. The slave may start up in a “Mode Detect” state. The SPI port may then wait for a Mode byte to be sent to it from the Master. The Mode byte is sent in the correct mode the Master wishes to use. The slave measures the Mode byte to determine which of the four modes was used to send it. The Mode byte may be detected three times to ensure proper detection. This byte is repeatedly transmitted until the slave responses to these bytes by returning a 0x00 byte. When the Master receives this reply, the Mode Detect phase of the SPI bus has been completed. The slave will now be in the correct SPI operating mode.

In another embodiment, a method that permits frame timing on the SPI bus to be restored without resetting the slave device is disclosed. The SPI Frame Resynchronization procedure may be invoked by the master detecting the messages being received from the slave are not valid. This can be done in at least three ways:

An undefined command was received

A command was sent but no response was received

The Frame length field was not valid

In other embodiments the slave device may detect errors using similar approaches, i.e. illegal command and length not valid. If these conditions occur, the master device may reset the interface.