11 November 2014

What's Coming Up

Thanks, everyone, who has been a part of this blog! It's been way too long since I've worked on this, but it's not a topic I've intended to give up forever. I do intend to expand on these tutorials, and branch out into a few other topics as well, using other Launchpads, perhaps FPGAs, and other transducers and tools to work in scientific instrumentation.

I'm adding a post here to let you all know that more will come, hopefully in early 2015, but that it will come in the form of an entirely independent website. The tutorials here will be updated and refreshed for that site and new content will start showing up. I hope you all look forward to it as much as I do!

25 April 2013

Tutorial 21: Timer Tricks (PWM)



The Basic PWM Signal

Three examples of PWM signals with different
duty cycles. Each is also marked with its
average level.




Better PWM






Why PWM?



Putting PWM to Work




23 February 2013

Tutorial 20c: The 24xx08

While setting up the USI for I2C is more complicated, the value of that complexity becomes apparent when you look at a real implementation of the I2C protocol. The Microchip 24AA08 EEPROM is the I2C equivalent to the 25AA080 we used as an example for SPI. The I2C version of this EEPROM is substantially simpler.


This chip, unlike its SPI counterpart, has no status register. Write protection is handled strictly by hardware through a single pin connected to either ground (write enable) or Vcc (write protect). There are really only two instructions, and the read and write instructions can be done by single bytes or by up to 16 bytes (a page). The seek instruction is really nothing more than a write instruction without sending any data to write.

  • Seek: The 24xx08 has a register that points to the current address in its memory for the next read/write command. We can change the current address by sending the slave address + write bit (a 0 in the 8th bit sent) followed by the address to which the slave should point. Each of these is, of course, followed by an acknowledge bit. The master issues a stop condition immediately after the address.
  • Write: We write a value to the 24xx08 by sending the slave address + write bit followed by the memory address to which the value should be written. This is followed by the 8-bit value to write and a stop condition. We can write up to 16 bytes in contiguous memory space by sending subsequent values before the stop condition.
  • Read: We read a value from the 24xx08 by sending the slave address + read bit (a 1 in the 8th bit sent). After acknowledging the command, the slave sends the 8 bit value at the current address on the next 8 clock cycles and increments the address pointer to the next space. If the master acknowledges, the slave will repeat by sending the next value. When all values required are read, the master sends a nack, indicating no more data is to be sent, and then issues a stop condition. If a value is required from a different address than the one to which the 24xx08's register currently points, a seek instruction should be sent before the read instruction.

Design Considerations

A quick look at the datasheet for the 24xx08 is worthwhile. There are a few things to note about this device.
  • Address: The 7-bit binary address for this device is 0b1010XBB. The bit labeled X is unused in this device, and can take either value. The last two bits BB refer to the block within the chip. The memory space is divided into four, 256-byte blocks. (Each byte within a block has an 8-bit address between 0 and 255. The X bit here would be used in a larger device with 8 blocks in memory.) Note that this means that only one of this particular device can be used on a given I2C bus; adding a second 24xx08 device, or any Microchip I2C EEPROM in fact, would create an address conflict on the bus. Adding the 8th R/W bit, this corresponds to slave addresses from 0xA0 to 0xA7 in hex. (That uses 0 as the X bit. Technically a 1 can be used here as well, so the addresses 0xA8 through 0xAF are respectively equivalent in this device.)
  • Most packages of this chip have three pins labeled A0, A1, and A2. In this particular device, these pins are unused and unconnected internally. Larger devices would use these in place of the block bits to determine the chip's address, allowing for up to 8 of the same chip on the bus. For this chip, the pins can be grounded, tied to Vcc, or even left floating.
  • Most of the timing requirements specified in the datasheet are good to see, but not an issue at the transmission rates we'll be using. (The device is rated for up to 400 kHz, and even at that rate the minimum requirements are well below what is actually used.) The important one for our purposes, however, is the maximum rise and fall times, TR and TF. These define the maximum RC time constant for the SDA and SCL lines. This device is rated with a 10 pF capacitance on the lines. The GPIO pins of the MSP430 are rated at 5 pF. The lines connecting the two chips will add a little more capacitance. Using a worst-case estimate of 30 pF and the maximum rise/fall times of 300 ns, we get a maximum resistance value of 10 kΩ.
  • Faster rates, as you recall, will benefit from lower resistances, at the expense of power consumption. The internal resistors available in the MSP430 are between 20 and 50 kΩ. For slow data rates, these are probably alright to use. But faster rates may require an external resistor in the 1 to 10 kΩ range.
  • Like the SPI version of this chip, the write process is not initiated until a stop condition is seen, and a 5 ms settling period is required for write operations whether writing a single byte or a full 16-byte page. Using a similar setup to the previous tutorial, we'll have to keep that in mind when using a 9600 baud UART to send the data being written. If any instruction is issued to the device during this settling time, the chip will not respond. The master can identify the nack by polling, in this case, and wait until an ack bit is sent before sending the next instruction.
And that's really about all you need to know to use this EEPROM successfully with the MSP430! The wire connections are just as straight forward, as only 4 wires are needed: Vcc, ground, SDA, and SCL. The WP pin of the 24xx08 should be tied to ground for write operations.


This example starts off simply, writing a single value to every memory space one by one. Since we need 5 ms between write commands, a simple delay is used in the code. Ideally, you would allow the MSP430 to continue with other tasks, and have a timer to indicate when it is ready to write again, but for this example a simple method works fine. The code provided uses a default fill value of 0xff, to act as an eraser of the flash memory. Feel free to change the fill_char value to whatever you wish; hex, decimal, and C character values are all acceptable here.
This example reads the entire contents of the EEPROM and dumps the data via UART. If you ran the i2cerase_G2231.c code previously, you should see 1024 instances of 0xff appear in your terminal (assuming it has the capability of displaying this code; you might change to a visible character if not). In this example, I've used a low power mode to hold the main function until a value has been read by I2C  Uncommenting the _low_power_mode_off_on_exit() command at the end of USI_ISR signals the data is ready to be transmitted by UART. A delay loop is used again to delay the next read, though ideally a low power mode could be used again here.
The final example demonstrates writing in full pages of 16 bytes. The first 1024 characters received by UART are written to the EEPROM. Like the SPI example, you can use a text file to send particular ASCII data to the EEPROM. After sending the data, use i2cread_G2231.c again to display the message on your terminal. The page write itself is used to accommodate the EEPROM settling time: the amount of time it takes to send 16 bytes at 9600 baud is longer than the required 5 ms.

Race Conditions

When designing these examples, I ran into a bug that took me a long while to solve, so I thought I'd mention it here. What I finally figured out was that I was hitting what's called a race condition. Originally, my main function in i2cwrite_G2231.c looked like this:
     slave_address = SAdrs + i/16; // Current Block Address
     pageBuffer[0] = (i%16)*16; // EEPROM Write Address
     for(j=1; j<17; j++) {
     _BIS_SR(LPM0_bits + GIE);   // Standby for UART RX
    pageBuffer[j] = RXBuffer;   // Extract RXBuffer
    while(SCFG & BIT4) // Ensure previous transmission is complete
     SCFG |= BIT3; // Mark transmission/write instruction
    USICTL1 |= USIIFG; // Set USI Interrupt to start
    // I2C communication
The problem was that the first element of pageBuffer would be overwritten shortly after the USI interrupt was started-- before the USI could transmit the original value! Once you start mixing peripherals and making extensive use of interrupts, you need to be very careful of race conditions: when values you want to use are changed before you actually use them. The solution here, as seen in the linked code example, was to not change the slave and memory addresses until a new page of 16 bytes was ready to be sent. That prevented the race condition by ensuring the value was not changed until the USI was clear.

Note that there is still a potential race condition due to the UART: if you speed up the UART (likely you'd need to slow down the I2C bus too), you could receive new data before the old data is transmitted to the EEPROM. Of course, increasing the UART speed could cause problems with the settling time as well.

That concludes this particular tutorial; I'll move on to some other topics now, and bring a new experiment to the blog that will illustrate a fun use of I2C.

06 February 2013

Tutorial 20b: USI & I2C

Implementing I2C on the MSP430 USI is more involved than SPI. One of the major problems is that part of the implementation must be done in software; the USCI module is a more complete hardware implementation that makes I2C communication easier, but not all devices have that module. For those devices that don't have a serial module at all, I would recommend using SPI instead. It's possible to do I2C completely in software and timers, but it's not easy. SPI is much simpler for "bit-banging".

When you consider how a device should react to an interrupt, there are three possibilities. First, there may be only one task to be done. This reaction is the simplest, and is straightforward to code. A good example is using the timer interrupt to toggle the state of an LED. Second, there may be a set of possible tasks, and a given set of circumstances determines which task is performed at the interrupt. Often this is accomplished through use of if/else statements. Finally, there may be a sequence of tasks to be performed, each step timed by a succession of interrupts. This final reaction is also described as a "state machine".

The USI module has, of course, only one interrupt. (Well, there are two, technically, if your device is configured as a slave: there is a separate interrupt for signalling the start condition for an I2C transaction.) This interrupt is triggered every time a non-zero value is written to USICNT.  Every I2C transaction will require more than one write to USICNT, and we can make use of that to set up the module as a state machine. Doing so makes it easier to understand what is happening and to debug problems, and also allows you to spend more time in a low power mode. Let's examine a flow chart describing the state machine for an I2C master:

I've tried to group these in a suggestive way, separating the different states as they will appear in code. Note that in particular the logic analyzing the Ack/Nack bit will be in the same section of code that handles the transmit/receive of the data. I've also left out the Ack/Nack handling for dealing with multiple bytes of data to keep from cluttering the diagram, but be aware that those will also be handled.

Note that the state machine diagram for a slave configuration is not much different--replace the first two steps with a receive address and acknowledge if needed. (A "Nack" response would simply be to go right back to idle in this case.) Instead of generating the stop condition, a slave would simply clean up (perhaps taking a new measurement or otherwise preparing for the next command) and go back to idle.

The state machine concept lends itself very easily to the switch statement in C. Looking at this state diagram, we should be able to code the USI interrupt with 6 different states. The states can be assigned a number (eg. 1-5 + default for idle), or by using the enum construction in C, making the code much more readable.

Configuring the USI for I2C

The USICTL0 register is handled similarly to the setup we did for SPI. The main difference is that we no longer need P1.5, since there is only one data line in I2C. In USICTL1, we also need only enable the USII2C bit. For I2C operation, as you recall, we want the phase/polarity to match Mode 3 in SPI; USICKCTL should be set to whatever clock source and division are desired, with the USICKPL bit enabled.

Finally, when operating the USI in I2C mode you should disable automatic clearing of the interrupt flag by enabling the USIIFGCC bit in USICNT. The reason for this will become apparent when we look at the interrupt service routine. Since one of the upper bits in USICNT is now enabled, we can't start transmission/reception simply by assigning the number of bits to this register. For that reason, we'll start the clock by using an or operator to avoid changing any of the upper bits in this configuration.

The code to setup the USI for I2C may look something like this:

// Enable ports and set as master
USICTL1 = USII2C + USIIE;       // I2C mode, enable interrupts
// Use SMCLK/8, Mode 3 phase/polarity
USICNT |= USIIFGCC;             // Disable automatic clear control
USICTL0 &= ~USISWRST;           // Enable USI
USICTL1 &= ~USIIFG;             // Clear any early flags

Setting Up the ISR

This (updated and verified!) code fragment is a simple way to set up the ISR in a way that allows both transmission and reception with I2C. There are a few things to note about this code:

  • The format for usage of the enum C type is:
    enum{item_1, item_2, ... , item_n} var_name = initial_state
    The numbering as done in this example is redundant, but serves to illustrate that explicit enumeration values can be given. This variable is declared as static to retain its value between calls to the ISR.
  • Recall that the start and stop conditions are given by changes in SDA while the clock is high. This is handled by enabling the output latch for the SDA line using the USIGE bit in USICTL0. The SDA line will immediately take whatever value is in the first bit to send in USISRL, and so that register is set to 0x00 for start and 0xFF for stop. (Only the most significant bit need be set, but this method has the benefit of being both convenient and comforting.)
  • Also recall that in I2C, the SDA line can be changed by master or slave. When receiving, control of the line must be relinquished to whomever is transmitting. This is accomplished by setting the USIOE bit in USICTL0 to control the line, and clearing it to relinquish the line.
  • The SCFG flag I have used in the prior tutorials on serial communication adds two more bits used here: bit 3 indicates transmit when set, receive when clear. Bit 4 is used to indicate a new receive value has been saved to the buffer. Presumably the buffers ITXBuffer and IRXBuffer have been defined previously. (The names here are thinking ahead to using I2C in parallel with UART.)
  • I have also used a hopefully self-explanatory variable slave_address, presumably defined earlier.
  • Note the inclusion of an additional state labeled "PrepStop". This state is necessary before sending a stop condition, as the line must be low before a stop can be sent. Note that each case in the switch statement ends with setting one or more of the first 5 bits in USICNT and setting the next state. After the break, the USIIFG is cleared. When the USI module has finished transmitting everything, an interrupt is generated, and the routine will call into the next state as a result. The PrepStop state is needed in order to allow the previous ack/nack to finish before stopping the communication.
  • Finally, clearing USIIFG is handled manually in order to stretch the clock when necessary for a slow communication. If something delays the master, clearing it manually ensures that every step in the ISR is followed before another interrupt can be allowed.

That finishes this tutorial on the configuration of the USI module for the I2C protocol. Next time we'll put it to use with the 24xx08 serial EEPROM, as we did for the SPI example.

29 September 2012

Tutorial 20a: Introducing I2C



Problems With a Serial Bus







I2C in Action








21 September 2012

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) {
        // 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.
} // 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.


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?

08 September 2012

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.)


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.


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).


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.