Tutorial 20a: Introducing I2C

The SPI protocol is a simple and useful system, but is not without its disadvantages. In the example we looked at, we noted that at any given time, despite the ability to exchange messages simultaneously, only the master or the slave was sending any meaningful data. The system is capable of linking multiple devices together, but the technique is much like an old switchboard operator: each devices gets its own unique and private line, and the master selects which device it is talking to at any given moment. In the mean time, lines not being used are taking up space and resources that could be allocated to other tasks. This technique is not the only way to communicate, however. What if instead of a switchboard model, we looked more to radio communication: if you tune in to a specific frequency, anything transmitted can be heard by all, and (at least at some frequencies) all can transmit at any time. This type of system is far more conducive to linking multiple devices together as it greatly simplifies the connections, both physically and conceptually.

In electrical systems, we call any line that links multiple parts together a "bus". In the sense of serial communication, a bus is a line on which devices can watch for signals, or generate signals of their own. A bus-type system reduces the number of connections needed between components and links multiple systems together in potentially complex ways. One of the most popular implementations of a true serial communications bus was developed in the 1980's by Philips Semiconductors: the Inter-integrated Circuit Bus, or I²C.

Problems With a Serial Bus

As you might expect if you've ever heard radio interference, some significant issues come up when rather than each device getting its own, private communication line they have to share a line. Much like a crowded household of entitled teenagers (at least before cell phones), a crowded bus in an electrical system needs to lay down rules for who can talk and when.

Problem 1: Since multiple devices control the same line, what happens when one device actively pulls the line low, while another actively pulls the line high? This creates a short between the low and high states, likely causing irreparable damage to the system. To get around this, the I²C specification requires devices to only actively pull a line low. The line is tied with a resistor to Vcc, so if no device is active it defaults to a high state. (This reason is similar to the need for the resistor(s) in the SPI example.) In terms of the MSP430 GPIO, think of it as setting the output of a pin to 0, then toggling whether the pin is an output (pulling the line low) or an input (allowing the line to be pulled high). In fact, if you ever find yourself required to bit-bang I²C, this is exactly the technique you'll have to use to prevent any damage to the systems involved.

Problem 2: As a result of the use of resistors to pull the line state high, we are limited on the speed at which we can communicate with I²C. Any capacitance in the line, combined with the resistor, will lengthen the amount of rise time in the line.  Too much resistance, and the line doesn't pull high soon enough to get the right message sent. Too little resistance, and you draw far too much power through the resistor when the line is pulled low. The standard specification for I²C limits transmission speeds to a 100 kHz clock. For the 3 V power used on many MSP430 designs, a resistance between 1 and 10 kΩ is typical; if you're concerned about speed, aim for the 1 kΩ end. Other specifications allow for clock speeds of up to 400 kHz (fast mode), or 1 MHz (fast mode plus). These modes will require smaller resistors, and inherently use more power than standard mode.

Problem 3: Since all devices are listening in on the same line, if the master asks for a data value to be reported, which device responds? I²C assigns a call sign, of sorts, to each device in the form of a 7-bit address. (An 8th bit is added to specify if the master wants to read from or write to the device.) This address is usually hard-coded into the device, and reading its datasheet will give the information needed to address it correctly. Some devices hard code some of the bits, allowing the user to select the specific address by setting the other bits accordingly. This technique allows the use of more than one of the same device in a system.

Problem 4: In addition to knowing who needs to respond, devices (including the master) need to know when they can send signals; if the line is tied up by another device, other devices must hold on their own messages until the line is signaled as being free. This coordination is effected in I²C by the timing of changes in the data line compared to the clock line. Communication in I²C is initiated by a falling edge in the data line, and marked complete by a rising edge in the data line, much like the use of the chip select in the SPI example we did. Since this is the same line where data is transmitted, I²C specifies that a "start condition" occurs when the data line is pulled low while the clock is high. A "stop condition" occurs when the line is pulled high while the clock is high. Data transmission occurs between these two conditions.

Data is sent after signaling a start condition by changing the line state while the clock is low, and the listening device reading the state while the clock is high. (Note that this is essentially equivalent to Mode 3 for SPI.) It is essential that devices sending messages do not change the state of the data line while the clock is high unless marking a start or stop condition. Other devices need to be aware of start and stop conditions to avoid sending messages of their own at the same time. If a device sees a start condition, it will listen for the address. If not its own, it must wait until the line is freed up by a stop condition before sending its message.

I²C in Action

If after reading all of that you feel like I²C is really complicated, it's not. Well, it's certainly more complicated than SPI, but once you see how the protocol works it's not too difficult to understand. So let's look at a typical I²C transmission and analyze what's going on.

Look at this image of the first part of an I²C transmission-- this portion highlights the start condition and the addressing portions. Note that the state of the clock (bottom curve) is idling high. The clock does not start until after the master pulls SDA low. The start condition is signaled by the falling edge on SDA while SCL is high. The start signal is followed by 9 pulses of the clock on SCL. Remember: at this point, neither the master nor the slave changes the state of SDA while the clock is high. Notice that the changes in SDA sending the data occur between pulses-- you can read out the transmitted value at the points where the clock is high. In this example, the data reads 0b01000001. The first 7 bits of this value are the address of the slave (in this case, 0b0100000). These bits are followed by a final 1, which designates a read command. The following data will be sent by the slave, reporting the data it has ready to send.

Did you note that there were 9 pulses, but only 8 bits? The 9th clock is done for some basic handshaking, and is called the "acknowledge" bit. In this case, the master addresses the slave at the specified address and releases the line after sending the 8 bits. If the slave recognizes the call, it pulls the line low; the master reads the 9th bit to confirm that the slave has heard the instruction. What happens if the slave doesn't hear, or fails to acknowledge the signal? Since the line is tied high and the master has relinquished control, the line automatically pulls high. If the master reads the 9th bit and sees it high, it aborts the transmission. (Whether it tries again or not depends on how the master is built, of course.)

At this point (assuming the slave acknowledged the instruction), it is important that the master not signal a stop condition (by sending a rising edge on SDA while the clock is high) to give the slave the time to report back the data it was asked to read. The remainder of this example looks like this:

How we interpret the remainder of the instruction depends on the exact device being read. For simplicity, let's assume that we're dealing with a device that has a single, 2-byte register. No further addressing is necessary, so when the slave receives the instruction to read, it reports back the 16 bit value it has. Data is transmitted one byte at a time, with an acknowledge bit between bytes. In this example, we see the slave reporting back the two byte value corresponding to the ASCII characters "%%". After the first byte, the slave relinquishes SDA and watches for the master to acknowledge receiving the data (again, by holding SDA low). After the final byte, notice that the acknowledge bit is now high. On the last cycle, the master does not send an acknowledge bit, indicating that no more data is expected.

Finally, the master pulls SDA low again, then releases the clock so that SCL is high. The master then releases SDA to give a stop condition.  At this point, any other devices needing to start a transmission are free to do so; if between the start and stop any other device has a message to send, it must wait until it sees the stop condition before doing so.

Now that we've got a handle on some basic I²C formatting, we'll turn our attention to the USI module and how it's used in I²C in the next part of this tutorial.

Reader Exercise: Using the second image, identify which bits (including acknowledge bits) in the data stream on SDA are sent by the master, and which are sent by the slave, according to the description given in this tutorial. What is the slave doing while the master is sending data? What is the master doing while the slave is sending data? Who has control of SDA at what times?

Tutorial 19c: The 25xx080

Now that we have a handle on configuring the USI module to communicate using the SPI protocol, we can implement it in a real situation. Today we'll be using a Microchip Serial EEPROM (I'm using specifically the 25AA080C, though in principle this should work with any Microchip SPI EEPROM).  Looking at the datasheet for this chip, there are a few things to understand.

Instructions and the Status Register

This chip has 6, 8-bit instructions.  In this design, the Chip Select pin is actually used to mark the end of an instruction, and so is a necessary signal that should be enabled (set to 0) before and disabled (set to 1) after each of the following:

• READ (0x03): Sending these 8 bits followed by the 16-bit address of the location in memory you want to read instructs the EEPROM to send the 8-bit value at the specified address on the next 8 clock cycles.  The whole instruction takes 32 clock cycles (8 for the command, 16 for the address, and 8 for the read-back).
• WRITE (0x02): This command can be used in two different ways. First, after sending the command, a 16-bit address is sent followed by the 8-bit value to write. Second, rather than write single bytes at a time, the chip can write a group of bytes (called a page) at once. The 25AA080C has a page size of 16, so up to 16 bytes can be written in one instruction.  This mode uses the command bits, followed by the initial address (each byte is written in the subsequent address of the last), and then the values for each byte to write.  Note: writing does not occur until the chip select has been disabled (set).  In addition, the chip needs a small amount of time (about 5 ms, according to the datasheet) to perform the writing. Any subsequent write commands must be sent after the settling time to prevent interruption. We'll examine this point a little more later. This instruction takes 24 + 8n clock cycles, where n is the number of bytes being written (max of 16 on this chip).
• WRDI (0x04): This simple, 8-bit only instruction disables writing to the EEPROM. Data can still be read, but write instructions will have no effect. This instruction takes only 8 clock cycles.
• WREN (0x06): The opposite of WRDI, sending these 8 bits enables writing to the EEPROM. When a write cycle completes, the write-enable latch is reset, so this instruction must be issued before every write instruction. This instruction also only takes 8 clock cycles.
• RDSR (0x05): The EEPROM also includes a Status Register that indicates the configuration of the chip. The 8-bit value can be read by issuing this command followed by 8 clock cycles to read the value back. This instruction takes 16 clock cycles.
• WRSR (0x01): The Status Register can be written directly under certain circumstances. When those conditions are met, a write is done by issuing a WREN instruction, followed by this command and the 8 bits to write to the Status Register. This instruction takes 16 clock cycles, but like the WRITE instruction must be preceded by a WREN.

The Status Register uses 5 of the 8 bits in this EEPROM chip:

• WIP (Bit 0): This bit is a flag that is set when the chip is in the middle of writing to the flash. Write instructions should not be issued until this is clear, which should take no more than 5 ms.
• WEL (Bit 1): This bit flags when writing is enabled on the chip. A WREN command will set this bit, while a WRDI will clear it. Writing to the flash only occurs if this bit is set. Writing to the Status Register may be possible while set, depending on the chip's configuration. (See WPEN below.)
• BP0 and BP1 (Bits 2-3): These bits enable write protection for individual blocks in the EEPROM. The 25AA080C is built with two blocks, corresponding to the upper half and lower half of the flash memory respectively. Setting both BP0 and BP1 will protect the entire chip from being over-written. These bits are set through WRSR instructions.
• WPEN (Bit 7): This bit determines whether the Write Protect pin affects the writeability of the Status Register. If this bit is clear, the Status Register can be written to regardless of the state of WP (as long as WREN has been done, of course). If this bit is set, then the Status Register can be written to if WP is held high, but is protected if this bit is held low.

All of these instructions and register definitions can be encapsulated in a C header file. As an example, look at 25xx080c.h. This file was written with this single device specifically in mind, but can be expanded to generalize to any SPI EEPROM from Microchip. I will be using this header file in all of the example code below, in addition to the calibrations.h header file. If you run these code examples, be sure to include the two header files. If they are linked to, be sure to adjust the CCS project properties to search for the directory they reside in for both the compiler and the linker, and set the debugger to clear only the main memory so the DCO calibration doesn't get overwritten.  (If that happens, go back to the flash memory programming tutorial and re-calibrate your MSP430.)

MSP430 Issues

As you get more involved with MSP430 design, you'll want to become aware of problems in the hardware itself. Every device on TI's website has a link to a "Device Errata", that details known problems with the hardware. The MSP430G2231 Device Errata lists a known problem labeled as "USI5", which applies to using the SPI protocol. For some reason, this device will send an extra clock cycle the first time it is used; so instead of sending 8 clock cycles after writing 8 to USICNT, it will send 9. There are two ways to get around this: the errata suggests writing one less to USICNT the first time, so writing 7 instead of 8. I think that makes for messy code, since the first transmission has to be treated differently, so instead I clear the bug in initializing USI. Before enabling the SDO and SDI pins on the MSP430, but after starting the USI, I send a command to transmit a single bit. Two pulses are actually sent, due to the bug, but since P1.6 and P1.7 haven't been enabled in USI yet, it has no effect on any devices attached to the MSP430. Once the two pulses have cleared, the pins are enabled, and the MSP430 is free to use the module as expected. The code I used to do this looks like this:

void USI_init(void) {

    USICTL0 = USIPE5 + USIMST + USIOE + USISWRST;

        // Enable SCLK, Master mode, enable output and reset USI

    USICTL1 = USICKPH + USIIE; // Mode 0 requires CKPH=1, enable interrupt

    USICKCTL = USIDIV_3 + USISSEL_2;    // SMCLK div 8 -> 921.6 kHz USI clock

 // One write command should take ~50 us at this rate,

 // while 1 bit via UART @ 9600 should take ~100 us.

    USICTL0 &= ~USISWRST;        // Clear USI for use

    USICNT = 1;  // clear 1st transmit due to errata USI5

    __delay_cycles(50);          // finish clearing (minimum (n+1)*16 cycles)

    USICTL0 |= USIPE7 + USIPE6;  // Enable SDI/SDO pins.

    USICTL1 &= ~USIIFG;

} // USI_init

Another technique you will see used in these examples was used in the UART tutorials: a custom flag is used to indicate when SPI transmission is occuring. This flag is polled to hold the program until the transmission has completed, ensuring that the USISR is not changed until all bits have been transmitted.  This flag is cleared in the interrupt routine for the USI.  The chip select is done manually in each example below.  See the Reader Exercise at the end of the tutorial for an idea on a better way to handle the chip select.

Example Code

Writing, Method 1

First up, eepromwrite_spiG2231.c demonstrates writing to the EEPROM device. The code uses P1.4 as the chip select signal, and that pin should be connected to pin 1 of the EEPROM. Be sure to connect P1.5/SCLK to SCK (pin 6), P1.6/SDO to SI (pin 5), and P1.7/SDI to SO (pin 2). Recall that the SCLK, SDO, and SDI functions are enabled in the MSP430 in the USI registers, not in P1SEL. It might not hurt to remove the jumper to the LED on P1.6 on the LaunchPad.  In addition, though the code may work without it, it's a good idea to tie the SDI-SO line (pin 2) to Vcc. The MSP430 does not automatically set this line when idling, as one would expect, so a simple resistor (say ~10k) will do the trick.  Finally, be sure to tie HOLD (pin 7) to Vcc as well.

RealTerm lets you send data from a text file, and

add the necessary 5 ms delay between characters.

Once running, this code will write the first 1024 bytes received by UART (at 9600 baud) to the EEPROM. Once that has completed, it lights the LED on P1.0 and goes into a low power mode, signaling that the write process is done. Now, if you think about it, there's a problem with this code. At 9600 baud, each byte takes just over 1 ms to transmit. While that's more than enough time to send the write command to the EEPROM at the USI clock rate being used, it's not enough time for the write to settle; there should be roughly 5 ms between write commands. If you are transmitting each character by hand, you'll probably be ok. If you're like me and really don't want to press keys 1024 times just to test this code, you'll want to write a 1024 character text file, and transmit that directly. For that to work, you need to have some delay between characters in the transmission. I used the Windows program RealTerm, which in addition to having a feature to transmit from a file has a feature to introduce a manual delay between characters. With that configuration, I was able to transmit the file mspsci.txt and have it write successfully to the EEPROM.

Reading

To get this file to display nicely, you need to enable the

newLine mode in RealTerm. Displaying an extra line or

two also helps.

Second, eepromread_spiG2231.c will read back the contents of the EEPROM and send them via UART (at 9600 baud) for display. If you run this code before any writing, it will display whatever the contents of your chip are prior to doing either of the write programs. If your chip is new, it will likely be very boring, consisting of the value 0xFF in every address.  If you run either of the write methods, running this program should result in a display much like what is shown here.

If you're using my text file and RealTerm, note that I've enabled newLine mode; the character being transmitted by default only initiates a line feed, without a carriage return. This mode adds the carriage return, so that it displays properly. If you lose a line of the display, increase the number of rows as well.

Writing, Method 2

Having to wait 5 ms between characters is a pain; we've effectively reduced our transmission rate to a crawling 200 baud. Fortunately, being able to write up to a single page at once saves us, since even after writing 16 bytes the settling time is still only 5 ms! At 9600 baud, each character takes just over 1 ms to transmit, so as long as we write more than 5 characters at a time, the amount of time it takes to transmit and store those characters is longer than the settling time needed between write commands. The disadvantage, of course, is that we need to employ a buffer to hold all of those characters in memory in the MSP430 while we wait. The MSP430 devices should have sufficient RAM to do this, however, so it's not much of a sacrifice. (But it is something of which we need to be aware in more complicated programs that write to EEPROM!) 

In eepromwrite2_spiG2231.c, I implement the same technique as before, but by writing a full page of 16 bytes at once. Received values are stored in the buffer[] array, and then transmitted to the EEPROM to be written. The amount of time it takes to send the complete write command is less than the time it takes to receive the next character, so the code returns to the for loop waiting for the next 16 characters before the next character is received. If we operate SPI at a slower rate such that this condition isn't met, we can run into a race condition. 

SPI Signal Details

Let's take a look at some of the details of the signals being passed back and forth in these programs.

These two images show signals from the first program, eepromwrite_spiG2231.c. The SPI lines are labeled from the perspective of the EEPROM, the UART from the MSP430. Notice in the first panel that the SPI lines only operate every 5 ms, between received characters.  There's a lot of wasted time in this method. The second panel shows the important signal lines in detail. Note that there are two instructions being used, since CS shows two pulses. The SCLK is configured correctly for the chosen mode, idling low and reading on the rising edge of the clock. In a write command, the EEPROM is sending nothing back, so SDO is high throughout the instructions. The EEPROM sees the instruction 0x06 (WREN) followed by 0x02 (WRITE). Then the 16-bit address 0x06 is received followed by the value 0x2A to write to that address. (0x2A corresponds to the asterisk symbol.)

For the program eepromread_spiG2231.c, the UART signals now follow the SPI instructions (as makes sense; the UART is transmitting the values read). There is much less dead time in this program, since no settling is required between reads as there was between writes. Zooming in on the bottom panel, we see a single instruction. 0x03 (READ) is followed by an address, 0x08 in this case, then 8 dummy bits. At the same time, the SDO line idles until the last 8 bits, where it reports the value 0x2A as the value stored at address 0x08 in the EEPROM. After a short delay (due to steps taken in the MSP430), the next UART transmission is begun.

One thing to note in this chart; the SDI line is not idling at high all the time. This is due to the same reason we wanted to put a resistor on the SDO line to tie it to Vcc; likely it's a good idea to do this to both lines. By leaving it off, I was able to demonstrate that the process still works fine; it's only convention that requires us to have a specified idle state.

Finally, we have three panels to illustrate the eepromwrite2_spiG2231.c program. The first and third are analogous to those shown previously, giving a view of the overall signals being sent and a zoomed in picture of the SPI signals themselves. Notice there is almost no dead time in the UART signals received. The middle panel shows that even though we now have to send 16 bytes of data to write, the total length of the write instruction on SPI is less than the time to receive a single byte via UART. If this were not the case, and a UART transmission were to complete first, it could mess up the transmission by changing the values in the buffer array. Fortunately, SPI can operate very quickly compared to this transmission rate, even faster than is implemented in this code.

This post completes the tutorial on SPI (for now, anyway!), and next time we'll switch gears and learn to use USI with the I2C protocol.

Reader Exercise: There's a lot of commands that are retyped in each of these examples... wouldn't it be nice if instead of manually writing each instruction you could call a function that handles it for you? Write a C function that handles write instructions and read instructions, passing the address of interest, and the value to write (in the write instruction case) as parameters. A general write function for multiple bytes may be tricky to do; can you write one that handles both single-byte and multiple-byte cases?

Tutorial 19b: USI SPI

Previously, I hinted at the variety of configurations possible for SPI communication. The MSP430's USI peripheral is very flexible for all of these configurations, so which we use will primarily be determined by the devices we connect to it. That being said, it's important to know how to decide which configuration we need to use.

SPI Modes

There are four primary modes for SPI, depending on the signal's polarity (whether it idles high or low) and its phase (do we read when the clock is low and write when the clock is high, or vice-versa). Common notation for these two values are CPOL and CPHA, respectively. TI, however, uses the values CKPL and CKPH, with CKPH being inverted from the standard definitions for CPHA. (That is, if CPHA = 0, CKPH = 1 and if CPHA = 1, CKPH = 0.)

When CPOL/CKPL = 0, the line idles low. An example of the timing of a mode using low polarity and using clock high to read is shown here. (These example diagrams come from John Davies' excellent book MSP430 Microcontroller Basics.)  Note that we determine the phase by looking at the edge that appears in the middle of a bit. In this example, we see a rising edge in the middle, followed by a falling edge between bits. Whichever edge occurs in the middle of the bit is a read, and the edge between bits is a write, and the order these occur (not which direction the edge is!) determines the phase. This tells us we want to use CPHA = 0 (or CKPH = 1 for the MSP430) which reads first, then writes.  This mode is often referred to as either Mode 0,0 or Mode 0.

Mode 0 Timing Diagram
From [Davies, 2008].

Here's another example using CPOL/CKPL = 1, with the line idling high. In this example, the rising edge is still in the middle of the bit, and the falling edge is between, but the write is first and the read second.  For this setup we would use CPHA = 1 (or CKPH = 0 for the MSP430). This mode is called Mode 1,1 or Mode 3 (as in 0b11 = 3).

Mode 3 Timing Diagram
From [Davies, 2008].

Now let's look at a real-world example. The Microchip 25AA080C chip is an SPI EEPROM with 1 kB (1024 bytes) of memory. In its datasheet, we see this timing diagram:

The diagram specifies Mode 0,0 (alternatively Mode 1,1), but we can verify that ourselves because (1) the line idles low, and (2) the read occurs before the write. For this device, we want to use CKPL = 0 and CKPH = 1 for the MSP430. Note also that the order of the transmission is specified as MSB first.

Configuring the USI

The USI uses 6 registers in the MSP430. One new thing about these registers that we haven't seen before is that, since each register is only one byte in size, we can also access them as 3 2-byte registers: the USI Control Register (USICTL), the USI Clock and Counter Control Register (USICCTL), and the USI Shift Register (USISR). (Alternatively, you can manipulate each register individually. There are convenient times to use both methods.)

USICTL

The control register is comprised of two parts: USICTL0 and USICTL1.  The pertinent bits are described here.

USICTL0 (lower byte)

• USIPEx (bits 7-5): these bits enable the USI functions on the MSP430 pins. (The MSP430G2211 and G2231 use pins P1.5-7 for USI functions.) These pins are already connected to other peripherals with the P1SEL register, so they are configured for USI through its own register, each pin individually.
• USILSB (bit 4): when set, data is transmitted least significant bit first rather than the default most significant bit first.
• USIMST (bit 3): when set, the MSP430 will act in the master role, and SCLK is connected to the USI clock as an output. When cleared (the default configuration), it's in slave mode, and SCLK is an input.
• USIOE (bit 1): when set, output is enabled. This function is equivalent to the chip select in other devices; since the MSP430 doesn't have an explicit pin configuration for chip select, it has to be done in software if its use is needed.
• USISWRST (bit 0): software reset for the USI; when set, operation is held to allow configuration. This bit must be cleared to start the USI.

USICTL1 (upper byte)

• USICKPH (bit 7): Sets the clock phase; inverted from the standard CPHA. When set, allows modes 0 and 2. When cleared, allows modes 1 and 3.
• USII2C (bit 6): Clear this bit to use the SPI protocol.
• USIIE (bit 4): enable interrupts for the USI counter; flags an interrupt when the specified number of bits have been transmitted.
• USIIFG (bit 0): interrupt flag for USIIE. This flag can either be cleared automatically or manually, though as we'll see later manual clearing is usually desireable.

USICCTL

The two parts of this register are USICKCTL and USICNT, for the clock and the counter.

USICKCTL (lower byte)

• USIDIVx (bits 7-5): Divide clock by powers of two up to 128.
• USISSELx (bits 4-2): Source select for the clock. USI has a wide variety of clock possibilities, including the Timer_A capture/compare registers. The variety allows for a lot of fine tuning for the exact transmission speed needed. (These bits are not used if the USI is used in slave mode.)
• USICKPL (bit 1): determines the clock polarity (set -> idle high, clear -> idle low).
• USISWCLK (bit 0): One option for the clock is to do everything in software. In this case, toggling this bit serves as the clock.

USICNT (upper byte)

• USI16B (bit 6): When set, USI will transmit up to 16 bits . When clear, USI will transmit up to 8 bits.
• USIIFGCC (bit 5): When set, the interrupt flag must be cleared manually.
• USICNTx (bits 4-0): Writing a value to these bits starts transmission, which continues until the number of bits specified is reached (eg. to transmit 6 bits, write 0b00110 to these bits).

USISR

The two byte-sized registers here are USISRL (the lower byte) and USISRH (the upper, or high byte). USISRH is ignored if the USI is configured in 8 bit mode (ie. USI16B is cleared in USICNT).

For the 25AA080C, we'll configure the MSP430 to be in master mode by setting USIMST, and select an appropriate clock speed for transmission. (At 3.3V, the 25AA080C works up to 5 MHz.) Using Mode 0, we'll clear USICKPL and set USICKPH. The commands (which we'll examine in the next tutorial) are 8 bits in length with MSB first, so we'll use the 8-bit shift register mode by clearing USI16B and use MSB first by clearing USILSB. Since we'll need to connect the two data lines and the clock to the EEPROM, we need to be sure to set all of the USIPEx bits. While not essential, we'll also use one extra P1 output to control the chip select for the EEPROM. Got all that? Great. Next time we'll actually do it!

If you're following along exactly, be sure you get an SPI EEPROM device before doing the next post. These are quite inexpensive, and available directly from Microchip. If you use a size other than the 8 kbit one I'm using, most everything will be the same.

Tutorial 19a: SPI Theory

When we looked at the UART, we imagined a setup where two people agreed that at a specific time and at specific intervals, one would send a message to the other one letter at a time. Doing so required both sender and receiver to have an accurate clock to prevent frame errors, or mis-reading the message by skipping or duplicating one of the letters. Using a similar analogy, we can think of the Serial Peripheral Interface as having the two people write a message to each other on a piece of paper, then exchange messages by handing them to each other at the same time. As a serial communication, it's still done letter by letter, though there are variations of SPI that allow for exchanging multiple bits simultaneously. We'll focus on single-bit-at-a-time transmission, since that is the only mode available in the USI and USCI peripherals.

There are 3 basic steps in SPI:

(1) Write bit 7 to the output.
(2) Shift register to the left.
(3) Write the other device's output to bit 0.

Let's say our two devices have 8-bit registers. At a given signal, each writes their most significant bit (bit 7) to their output. At the next signal, each shifts their register up one place, and sets the least significant bit (bit 0) to whatever value is on the other device's output. After 8 cycles, the 8 bit value that was in device A's register is now in device B, while the value that was in device B is now in A. Both read the new value (and probably do something with it), and then perhaps write a new message in their registers for the next exchange. This exchange of information makes it possible to very quickly send data from one device to another.

The key to getting the process to work properly is to have all the shifting occur at the same time--the two devices need to be synchronized. This timing is accomplished by sharing a clock between the two devices; one of the two generates its own clock and includes it as an output for the other device's use. By convention, we refer to the device that generates the clock signal as the "master", and any devices listening in as "slaves". Such nomenclature may seem a little non-politically correct, but at the same time it's a reasonable description of how SPI works. We cannot necessarily deem one device as a "sender" and the other as a "receiver", for example, because both devices are simultaneously sending and receiving. Referring to both as "transceivers" doesn't really work either, because the sending and receiving are in fact the same process. Rather, the devices are "exchangers". One device serves as a control of the exchange, while the other depends on the controller in order to make the exchange. Note that, contrary to the connotation of the nomenclature, the master does not necessarily have to be the device that issues commands, nor does a slave have to only receive instructions. In fact, one could envision a system where the clock is external to both master and slave, and neither device operates entirely independently of the other, but rather a third device mediates the exchange between the two by providing the clock synchronization. Generally, however, it's simpler to let one of the exchanging devices mediate, and that device become designated as the master.

You can imagine that the technique used for the SPI protocol lends itself to many variations. (Eg. do we pass the data starting from most to least significant bit or vice-versa? How many bits do we pass at a time?) Do we start the exchange on a rising edge or a falling edge of the clock? (The edge choice also leads to whether a quiet line idles high or low, of course.) To make it more confusing, for whatever reason various manufacturers have created different naming schemes for the lines between the two devices. In particular for our purposes, TI has the three lines between the devices named as Serial Data In (SDI), Serial Data Out (SDO), and Serial Clock (SCLK). Like for UART, the data in line of one device is connected to the data out line of the other: SDI_A-SDO_B and SDO_A-SDI_B for devices A and B. Note that because we must include the clock, SPI requires three lines (plus one more for ground) between the devices as opposed to two lines (plus ground) in the basic UART. (There are some situations where if one of the devices doesn't need to communicate anything to the other ever you can get away with just two lines, but in general you need three.)

The other common nomenclature for SPI connections was given by Motorola: each device has a Master Out-Slave In (MOSI), and a Master In-Slave Out (MISO) rather than SDI and SDO.  In this nomenclature, you connect like pins rather than opposite pins: MOSI_A-MOSI_B and MISO_A-MISO_B. Other devices use a similar nomenclature to TI, dropping the "D" in the abbreviations: SI and SO, connecting as in the TI scheme. You may also encounter SPSCK and SCK for the clock, and devices enabled with a chip select can be labeled as CS, SS (slave select), or sometimes CE (chip enable). Be certain to verify whether tying this pin high or low enables the device. In this blog, I'll stick with TI's nomenclature, and use SDI, SDO, SCLK, and CE.

SPI can also extend to communication with multiple devices by including a "Chip Select" pin-- a slave will only listen when this pin is high or low, depending on the implementation. Thus other peripherals can be attached, and instructions/data can be exchanged only between the master and the pertinent slave. The disadvantage to this means of multiple-party communication is that it requires one more line for each device that needs to communicate independently.

So how do we know what conventions we should use in our designs? Unfortunately, you need to get familiar with reading data sheets, and my experience has been it takes some practice to read data sheets describing exact communication protocols. In the next tutorial, we'll look at how to implement SPI using the USI peripheral, and delve more into the details of how to determine the particular protocol being used and configure the MSP430 properly.

Tutorial 19: Going Beyond the UART

We've already looked at asynchronous serial communication, and seen how useful it can be for a scientific instrument as a data logging system. Serial communication has a lot more power, however, especially when we begin looking at the "control" aspect of the microcontroller.

There are a lot of sensors and devices designed to work with microcontrollers that use synchronous communication protocols. The primary difference for these modes of communication are the inclusion of a single clock between the sender and receiver, rather than having to rely on precise and accurate clocks. Having to share a clock limits the separation to a fairly close proximity, but it does simplify the communication process a great deal.

The number of protocols designed for serial communication is quite large, but a few have stood out as standard for many devices. The MSP430 has many devices that, for example, have built-in hardware for communication using the Serial Peripheral Interface (SPI) and the Inter-integrated Circuit Bus (I²C or I2C -- pronounced either as eye-two-see or eye-squared-see, your preference).

Most MSP430 devices have one of two forms of serial communication hardware. The less expensive devices have the Universal Serial Interface (USI), which can do SPI and I2C. Larger devices come with the Universal Serial Communication Interface (USCI), in at least one of two flavors: USCI_A handles asynchronous communication (UART), and USCI_B handles synchronous communication (SPI/I2C). If for any reason you must use a device without either of these modules, you can resort to bit-banging, but aside from the previous tutorial on UART we won't cover that any time soon; most modules have at least USI, and it's far more economical to use the built in hardware.

To work with this tutorial, you'll need at least one of the following:

• Two devices that communicate via SPI and I2C, such as a serial EEPROM produced by Microchip. 
• USB-SPI/I2C interfaces, such as the FTDI devices. (Their chips include one that is great for UART at speeds other than 9600 bps too!)
• A second MSP430 device.

Owners of a LaunchPad already have two devices that include USI, but keep in mind you'll need a few other components to power the chip off of the LaunchPad. I'll do tutorials that will demonstrate all three methods, but for the beginning I will be working with Microchip serial EEPROM chips. (I will use the 25AA080C for SPI and the 24AA08 for I2C, but any size will do.)

Of the two synchronous protocols used by the MSP430, I2C will likely be the one used most frequently (at least by me), for the reason that the protocol is designed to work with multiple devices on a single communication line. Many sensors and external peripherals are already available that use I2C. However, SPI is a little simpler to understand, and we'll start with that. Once I've gone over the USI peripheral, I'll begin working on a new experiment that will make use of a pressure sensor, and design an MSP430-driven 4-digit LED display. Both will communicate over I2C as a digital pressure gauge. The project will require designing and fabricating a couple of printed circuit boards, so we'll go over a little of that process as well.

New Tutorials are Coming!

Hi everyone; it's great to be back. It's been a crazy few months, what with finishing my Ph.D. and all the other changes in my life. But, it's high time I start learning some new things and building some cool toys. I have a lot in mind for the coming weeks, and hopefully you'll find some of it helpful as well.

These tutorials will be a little different; call them "intermediate-level tutorials" if you will. Mostly, these tutorials will require the use of more parts and tools outside of the LaunchPad, much like the LCM tutorial from before. I'll try to keep the tools I use within a reasonable budget for beginners and amateurs, but some of the parts will probably cost a little more. (I just purchased a sensor for the next project that was $35.) If you have any suggestions or requests for topics, let me know!

Thanks, all of you who read this blog; I have a lot of fun writing this, and I'm glad so many of you have expressed your appreciation for its contribution to the MSP430 community. Let's see what more we can learn!