<\/p>\n
With the wide variety of Pmods available, there are also a number of communication styles different Pmods might use.<\/p>\n SPI (serial peripheral interface) is a useful communication style originally developed by Motorola. It uses four communication pins, along with a power and\u00a0ground pin, so SPI is easily used with the 6-pin and\u00a012-pin Pmod standards. In SPI, there is generally a “master” device (the host board) and a\u00a0“slave” device (the Pmod) that communicate. To do so, the master will select one of its slaves with it’s slave select (SS) communication line to indicate\u00a0to the Pmod that it is going to communicate with it. The master and the slave will then simultaneously communicate with each other (a full-duplex operation)\u00a0on the MOSI (Master Out Slave In) and the MISO (Master In Slave Out) data lines. Both the master and the slave send one bit of information to each other\u00a0after the master sends out a clock pulse on the SCK (serial clock) line to ensure that the timing of the data transfer is correct. Once a full byte, or eight bits of\u00a0information, has\u00a0been sent to the other device, the master (based on whatever code the programmer chooses) can either communicate again with the slave device or stop its\u00a0communication with the slave device.<\/p>\n <\/p>\n With its full-duplex capability, SPI is a fast communication standard. It can also support having multiple slave devices, but additional state-space (SS) data lines would need to be added, which takes up input\/output pins on the host board that\u00a0could have been used for other operations.<\/p>\n UART stands for a “universal asynchronous receiver\/transmitter” and was developed by Gordon Bell at Digital Equipment Corporation in the 1960s. The\u00a0“universal” portion refers to\u00a0the format of the data and the speed of the transmission are configurable. UARTs are able to communicate\u00a0in several different modes: full-duplex, half-duplex (the two devices communicate with each other one at a time), or simplex (the data communication is one\u00a0way only). Because UARTs are configurable in their communication style, both the transmitting and receiving UARTs need to be configured in the exact same way\u00a0to ensure that successful communication occurs.<\/p>\n <\/p>\n UARTs are designed to communicate with other UARTs, although they generally do not directly generate the communication themselves; they only transmit and receive\u00a0the signals. The transmitting UART will receive a byte from the host board, and then, using its internal shift register, first send a “start” bit to\u00a0communicate to the receiving UART that information is about to be transferred. The byte of information is then sent one bit at a time, followed by a “stop”\u00a0bit after the expected number of bits has been recieved, letting the communication line go high. The receiving UART takes the stream of bits and uses its\u00a0SIPO shift register<\/a>\u00a0to make the data available to it’s host controller.<\/p>\n <\/p>\n For the Pmod line, there are two different variations of UART that are used. The reason for this is primarily historical–at the time that UART pin interfaces\u00a0were designed, microcontroller chips had completely separate SPI and UART interfaces that had no relation to each other. However, as newer microcontroller\u00a0chips were developed, such as some of the newer PIC32s, they had serial interfaces that could work with both SPI and UART. To accommodate for this change, the\u00a0UART interfaces on Pmods were also adjusted from the old standard so that they could easily share the same pins as the SPI pinouts.<\/p>\n I\u00b2C (generally pronounced I-squared-C) is a communication style originally developed by Phillips Semiconductor (now NXP Semiconductor). In this protocol, originally intended to be part of the “Imod series<\/a>“, only two communication pins are used: a serial data line (SDA) which is shared by both the master and\u00a0slave devices, and an SCK, which the master controls. In the widely used 9-bit communication style of I\u00b2C, a master will pull the SDA low\u00a0as\u00a0the “START” condition to indicate that it wishes to communicate with a slave device and transmit two things–the 7-bit address of the slave it wishes to\u00a0communicate with, and then either a read or write bit to show how it wants to communicate with the Pmod. For the 9th bit, and the 9th clock signal, a slave\u00a0with the matching address will send an acknowledge (ACK) bit on the SDA line to show that it is ready to communicate. If there was no slave with the 7-bit\u00a0address, the SDA line would be pulled up high during the 9th clock cycle and the master would interpret this as a not acknowledged (NAK) signal.<\/p>\n <\/p>\n Assume\u00a0that a Pmod does send an ACK signal, 9 more bits would then be transferred; the first 8 bits will be the information that is to be communicated\u00a0either from the master or from the slave, depending if a read or write command was originally sent. If the master wants to keep sending information, it will\u00a0wait to see if an ACK from the Pmod on the 9th clock cycle, or send an ACK response to the slave if it wants to receive more information from the slave. To\u00a0end communication, the master may send a NAK signal after sending or receiving a byte of data for the 9th clock cycle. The master may then issue a “reSTART”\u00a0to start a fresh communication or should release the SDA line as its “STOP” condition.<\/p>\n nbsp;<\/p>\n Although this communication style is not as fast as SPI (because it only operates in half-duplex), it is far easier to create a string or “daisy-chain” of I\u00b2C\u00a0devices. This is because the Pmods that offer I\u00b2C communication styles have a 2×4 pin header for I\u00b2C, allowing for two sets of I\u00b2C. Additionally, because the\u00a0communication style is set up where the master calls out a slave address as opposed to selecting a specific slave on its own line, only two input\/output\u00a0pins are ever needed for a I\u00b2C communication setup.<\/p>\n And finally, Pmods also communicate with the host board through general purpose input\/output (GPIO) pins. This does not follow follow a strict set of rules\u00a0regarding how the Pmod and the host should communicate. Rather, the host is able to send high, low, pulse-width modulation (PWM), analog, audio, and\u00a0a variety of other signal types\u00a0to the Pmod at any time and have the Pmod respond (more or less) immediately. This is great if you want to get a response whenever you press a\u00a0button or flip a switch. The host could also receive the same variety of signals from the Pmod at any time, but it depends on how the code is designed to\u00a0have the host respond to or ignore the signals. Also, because we are using input\/output pins for communication, we can become rapidly limited in our\u00a0capability to operate a large amount of peripheral modules.<\/p>\n Example Application: if you’re designing a motion-detecting application, consider using the Pmod Passive Infrared Motion Sensor<\/a>. The Pmod PIR communicates through the GPIO pins and can easily integrate with various host boards. It\u2019s designed to detect motion through passive infrared sensors, which is perfect for applications like security systems, automation, or even interactive displays.<\/p>\n In setups where a direct Pmod connection isn\u2019t practical\u2014such as when using breadboards, jumper wires, or custom wiring\u2014something like the Pmod CON1 Wire Terminal Connectors<\/a> can make integration much easier. These allow secure wire connections without needing a standard Pmod header on your host board.<\/p>\n And now for our bonus historic information! You may have noticed that a few of these communication styles keep the data communication line in a high, or\u00a0powered, state when they waiting for a new communication to occur. This is leftover from the telegraph era where the communication line was held in a high\u00a0voltage state when it was not being used to show that neither the line nor the transmitter were damaged.<\/p>\n![\"Digilent's](\"https:\/\/digilent.com\/blog\/wp-content\/uploads\/2014\/08\/colored-spi.jpg\")
<\/a>![\"Digilent's](\"https:\/\/digilent.com\/blog\/wp-content\/uploads\/2014\/08\/colored-uart.jpg\")
<\/a>![\"Digilent's](\"https:\/\/digilent.com\/blog\/wp-content\/uploads\/2014\/08\/colored-i2c.jpg\")
<\/a>![\"Digilent's](\"https:\/\/digilent.com\/blog\/wp-content\/uploads\/2014\/08\/colored-io.jpg\")
<\/a>
