This action might not be possible to undo. Are you sure you want to continue?
www .d ig ilen tinc .c om
215 E Main Suite D | Pullman, WA 99163 (509) 334 6306 Voice and Fax
This document describes the protocols for constructing, sending, and receiving commands and data between master and slave devices using the SPI, TWI, or RS232 binary interface.
The packet-level protocol provides a transparent means of sending various command and data payloads between a master and a slave device independent of the hardware interface. All that is required of the interface is the ability to transmit byte-aligned data and to identify boundaries between packets. Fundamentally, the protocol consists of packets containing a simple header (typically one or two bytes) followed by an arbitrary amount of application-specific data. All packets conform to this format, whether they are sent from the master to the slave, or vice-versa. The packet header’s upper three bits indicate the type of packet, and the lower five bits (and the second byte, if present) describe the sub-type. The following is a brief summary of all packet types and pre-defined sub-types: 000x xxxx – pktSync This packet type includes various synchronization bytes used to implement specific transport-level protocols. The byte’s specific meaning is interfacedependent, with some sub-types not being used by all interfaces. • • 00000 – synIdle A filler byte sent by the slave or master. 00001 – synReqWr Sent by the master to request to send a packet to the slave. The slave will not respond with meaningful data until it is ready to respond, at which point it will send an rspPacketStart. This is only used in SPI and binary RS232 mode. 00010 – synReqRd Sent by the master to request to read a packet from the slave. The slave will not respond with meaningful data until it is ready to respond, at which point it will send an rspPacketStart, then a packet header followed by the packet’s payload (if any). Should a master attempt to read from the slave when there is no data available for reading, an rspNoData packet will be received. This is only used in SPI and binary RS232 mode. 00011 – synDone In binary RS232 mode, this is used to terminate every packet sent (by either the master or the slave). This must be transmitted immediately after the last data byte of the packet for it to be recognized as valid.
001c cccc – pktCmdI An immediate command byte. Immediate commands have no operands other than the five lower bits, which denote either an application-specific command (high command id 16 -31) to be executed or one of the mandatory immediate commands (low command id 0 - 15) that all slave devices must respect. All immediate commands may also be implemented in the short format with a single byte parameter.
Copyright Digilent, Inc. All rights reserved. Other product and company names mentioned may be trademarks of their respective owners.
page 1 of 6
00001 – cmdGetRsp Returns the response code generated by the reception and/or execution of the last packet in a single byte pktRsp packet. page 2 of 6 .Packet-Level and Transport-Level Protocols Digilent. Rev 1.). with subsequent bytes representing command parameters. The following codes are currently established. etc. The lower five bits in the header byte (shown here as S’s) denote the length of the data contained in the rest of the packet. 111r rrrr – pktRsp Response byte. It may be up to 30 characters long (31 with null) in a pktDataS. Typically.digilentinc. • 00010 (pktRsp + 0x02) – rspNoData Byte sent in response to a master requesting to read data when none is available. Also sent by the slave immediately prior to transmission of any response packet (pktRsp. and the second byte is the specific device ID. 00010 – cmdGetDevType Returns the device class type and firmware revision within the class in a 2-byte payload pktDataS. Other product and company names mentioned may be trademarks of their respective owners. A slave device may generate these bytes in response to a master. 00100 – cmdGetDevCap Returns a 2-byte payload where each bit flags a device class capability. the buffer will be reset to the default of rspPacketOk. while the second byte (shown here as S‘s) is the lower byte of the data payload’s size (representing a maximum payload size of 2^(5+8) = 8KB). www. 100h hhhh ssss ssss – pktDataL A long-form data packet. The lower five bits in the header byte (shown here as S‘s) denote the length of the data contained in the rest of the packet. The lower five bits in the header byte (shown here as H’s) are the lower five bits in the upper byte of the data payload’s size. For example. This is only used in SPI and binary RS232 mode. 010s ssss – pktCmdS A short-form command packet.0. 011s ssss – pktDataS A short-form data packet. • 00001 (pktRsp + 0x01) – rspPacketOk Result code generated by the slave to indicate that a packet was successfully received and processed. The first byte is the device class type. This payload data represents an application-specific command and operands. The lower five bits (shown here as R’s) denote the response code. All rights reserved. 00110 – cmdGetPacketSize Returns the maximum packet payload size supported by this device in a 2-byte payload. Inc. with all other codes being reserved for future use: • 00000 (pktRsp + 0x00) – rspPacketStart Sent by the slave to the master to indicate that it is cleared to begin transmission of a packet. Upon sending the response code. 110x xxxx – pktRsv2 This packet type is reserved for future uses. 00101 – cmdGetFirmVer Returns the firmware revision in a 2-byte payload where the MSByte is a major revision number and the LSByte is a minor revision number.com Copyright Digilent. The response code buffer is populated with this at start-up and after a successful read of the buffer (through cmdGetRsp). the first byte of the packet’s payload will indicate the command to execute. 101x xxxx – pktRsv1 This packet type is reserved for future uses. pktDataS. Inc. 00011 – cmdGetDevName Returns a null-terminated ASCII string identifying the device and firmware revision. • • • • • • • 00000 – cmdReset Resets the device to its power-on defaults.
setup on falling. the packet’s payload is then sent. an rspBadPacket error will. the least significant byte is sent first (little endian). TWI. To initiate a transfer with SPI. All rights reserved. Serial Peripheral Interface (SPI) Generally. To www. On the byte immediately following the reception of rspPacketStart. this is caused by an incorrect quantity of parameter data – either too much or too little – or by the slave having received a different amount of data than indicated by the header.digilentinc. The slave will receive and store all bytes from the master (unless its internal buffers become full – a situation that the master will receive no immediate notification of. During reception of a packet. there are established protocols for sending packets over SPI. SPI uses mode 0 (sample on rising clock edge. be generated and stored). while waiting for the slave to respond with an rspPacketStart byte. Once the packet header has been transmitted. the slave will transmit synIdles. All bytes received are assumed to be part of the packet. 11101 (pktRsp + 0x1D) – rspBadParameter Result code generated by the slave to indicate that a parameter for a valid command packet was invalid (in most cases. for multi-byte parameters. Inc. Other product and company names mentioned may be trademarks of their respective owners. Currently. The first byte received by the master after pulling the SS line low should always be discarded (because there is no way the slave could initially transmit a valid byte). and payload of a packet. The upper three bits of this first byte identify the packet type (as described in the previous section). Inc. 11110 (pktRsp + 0x1E) – rspBadType Result code generated by the slave to indicate that it does not respect the specified packet type. this means out-of-range). however. and the clock line idles low). the master first pulls the slave-select (SS) line low. • • • • • 11011 (pktRsp + 0x1B) – rspCmdFailure Indicates that an internal error unrelated to the communications protocol was encountered during execution of a command. The master then begins continuously transmitting pktReqWr bytes. until the slave responds with rspPacketStart. page 3 of 6 . Transport-Level Protocols The transport level is responsible for providing the interface-independent means of sending packets (as described previously). Additionally. Packets begin with at least a one-byte packet header identifying the type.com Copyright Digilent. and RS232 binary interfaces. Commands which generate this error will indicate in their description what conditions can cause such an error. length. the master must begin transmitting a valid packet. and if too few or too many bytes are sent for a particular packet. an rspBadPacket error will be generated. Subsequent bytes will echo what was sent by the master on the previous byte (pktReqWr). with the most significant bit (MSB) transferred first. 11111 (pktRsp + 0x1F) – rspBadPacket Result code generated by the slave to indicate that a packet was determined to be malformed.Packet-Level and Transport-Level Protocols Digilent. 11100 (pktRsp + 0x1C) – rspBadCommand Result code generated by the slave to indicate that it did not recognize a command specified in a command packet. Generally.
the master must first pull the SS line low.Packet-Level and Transport-Level Protocols Digilent. followed by the packet’s payload. Upon the SS line being pulled high. Immediately following the rspPacketStart byte. should always be stable while the SCL line is high (the data on SDA is setup while the SCL is low and sampled while it is high). for example). The first byte received by the master after pulling the SS line low should always be discarded (because there is no way the slave could initially transmit a valid byte). The SDA line. the master must pull the SS line high immediately following the transmission of the final byte in a packet. and the response code is ready. except during start and stop conditions. it will instead transmit a single rspNoData byte. Additionally.digilentinc. it first places a start condition on the bus by bringing the data line (SDA) low while the clock line (SCL) remains high. Then. it will receive synIdles. it must continuously send pktReqRd bytes while waiting for the slave to respond with an rspPacketStart byte. It then clocks out a single byte (MSB first) whose upper seven bits are the address of the slave device and whose lower bit indicates whether the master is reading (LSB = 1) or writing (LSB = 0) from the slave. This eliminates the need for any pktSync bytes to be sent when using the TWI interface. the slave will then begin processing the packet. and methods for delaying communications when a slave is busy. properly terminate a packet. which all slaves are required to respect. it will send an acknowledge (ACK) to the master by pulling the SDA line low on the ninth clock from the master. the master should be transmitting synIdles while receiving the packet from the slave. Subsequent bytes will echo what was sent by the master on the previous byte (pktReqRd). With TWI. To read data from the slave following the execution of an instruction that generates a response (cmdGetRsp. The slave will not respond to additional commands over the SPI interface until packet processing has finished. see the TWI section of the Atmel data sheet for an AVR microcontroller such as the ATmega64. All rights reserved. For a complete reference on how the TWI bus operates. The response code may be read by issuing the cmdGetRsp immediate command. the slave will begin transmitting its response packet. page 4 of 6 . When a master wishes to communicate with a slave. by leaving the SDA line high on the ninth clock (known as a NACK condition). Should the master attempt to read beyond the length of the packet. Inc. www. and a suitable response code will be generated and stored to an internal buffer (overwriting any previously generated response code). the master should break off communications by issuing a stop condition (bringing the SDA line high while the SCL line is already high). Two-Wire Interface (TWI) The complete details of the TWI bus’ operation are beyond the scope of this document. Inc. Should the slave not have any valid data to send. If the slave fails to acknowledge. until the slave responds with rspPacketStart. First the packet header is sent. there are methods for indicating a master’s desire to read or write data to a slave.com Copyright Digilent. When a slave is successfully addressed. Other product and company names mentioned may be trademarks of their respective owners.
or any other niceties. the master should then transmit the packet header and then the packet’s payload. These include 0x00 – 0x07 and 0x78 – 0x7F (inclusive). To conform to the TWI specification. Inc. Binary RS232 Interface Because RS232 is an inherently asynchronous interface. All rights reserved. the master must address the slave in read mode (as previously described). except for the last byte. if it wishes. To initiate a write to a slave. This code can be queried using the immediate command cmdGetRsp. in response to which it must send a NACK. and wait for it to be released by the slave to resume clocking. as previously described. The master should attempt to re-address the device and resume communications later. Following successful addressing (indicated by the slave acknowledging its address). If the slave is busy (processing a previously received packet. will respond with an rspPacketStart byte for every four www. That is. it must detect that the SCL line is still low. The slave. Attempting to read beyond the length of a packet will merely yield synIdles. to which no standard-mode TWI device should respond. the master must signal an end to communications by issuing a stop condition to the bus. To perform a write to a slave. the slave will begin processing the packet and generate an appropriate response code (overwriting any previously generated code). The master should check for an ACK from the slave following each byte sent. page 5 of 6 . it may choose to not acknowledge its address on the TWI bus. When the master then attempts to bring the line back high. At this point. and communications should be immediately terminated by issuing a stop condition to the bus. the slave will return a single byte rspNoData packet. there are no built-in provisions for marking boundaries between packets. Should there be no data available to read. the slave will hold the SCL line low until it is no longer busy. the master should acknowledge every byte sent by the slave. Following an ACK from the slave. when it is ready. for example). due to the execution of a higher priority interrupt. As such. It should be noted that there are two ranges of eight addresses that are reserved in the official specification. the master must address the slave in write mode. To read data from the slave following execution of a command expected to generate response data (cmdGetRsp. it can be inferred that the packet has failed to successfully transmit. the master begins continuously transmitting synReqWr bytes to the slave. Other product and company names mentioned may be trademarks of their respective owners.Packet-Level and Transport-Level Protocols Digilent.digilentinc. This will allow the master to move on to communicating with other devices. Inc. followed by the payload. additional synchronization bytes are used to facilitate the transmission of the aforementioned interface-independent packets. with the packet header sent first. If the slave becomes temporarily busy during communications (for example. or merely storing a previously received byte). Once the packet has been transmitted. If an ACK is not received. while the busy device finishes its current task. for example). subsequent bytes from the slave will contain the response packet.com Copyright Digilent. The slave may not respond to its address until it has finished processing the packet. it may delay transmission of additional data by “clock-stretching”.
Inc. the master continually transmits synReqRd bytes. Immediately following transmission of the last byte in the packet. Upon receiving the first start byte. Following the last byte of the packet. the slave will then (with no intervention from the master) send the rest of the packet. page 6 of 6 .digilentinc. the slave will discard the packet and generate an rspBadPacket error. until the slave responds with a rspPacketStart. the slave will send an rspNoData packet. Immediately following the last start byte.Packet-Level and Transport-Level Protocols Digilent. the master must transmit a synDone to indicate the end of the packet. The master should not accept a packet received from the slave as valid unless it is prefixed with a rspPacketStart and terminated with a synDone. these should be discarded. All rights reserved. Other product and company names mentioned may be trademarks of their respective owners. No response is generated by the slave for any bytes received at this point. www. as usual. Should the master fail to send the appropriate byte at this crucial point. If there is no data to be read. the slave will also send a synDone. Initially.com Copyright Digilent. Once the synDone is received. there is a potential for multiple rspPacketStart bytes to be received. Also note that sending a synDone immediately in response to an rspPacketStart will also generate an rspBadPacket error. the master may immediately begin transmitting a packet. The slave may not respond to consecutive requests to read with no data present. Reading from the slave is accomplished in a similar fashion. synReqWrs that it successfully receives (it will always respond to the first synReqWr following reception of anything besides a synReqWr). the slave will begin packet processing and generate a response code (readable via cmdGetRsp). Note that due to buffering issues on the master side. Inc. The slave may not respond to additional queries until it has finished processing the packet.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.