Microcontroller Solutions TechZone Magazine, April 2011 - Digikey

e implemented in hardware because of the data rates involved. SPI
also needs to be hardware-based. Multi-master systems will need to
be hardware-based as well.
Beyond data rate, each interface offers specifi c features that may
make it more appropriate for a specifi c application. UART is extremely
simple to implement and is full-duplex. I 2 C is popular because it
requires only two wires, can have a simple master, and offers a
variety of advanced options including support for addressing, multiple
masters, broadcasting, and clock stretching. Clock stretching, for
example, allows an I 2 C slave to hold the clock and halt the fl ow of
data while it processes the data it has received, thus preventing
potential overrun issues. In contrast, a SPI slave is at the mercy of
the SPI master.
With all of the various options available for I 2 C and SPI, many silicon
vendors supply example code which you’ll need to use as a model
for creating your own code. Fortunately drivers for these interfaces
can be fairly simple – an I 2 C driver can be 15 lines of code, allowing
you to implement an interface in a short period of time. However, it is
important that you determine which features you need to support, that
you’ve implemented them correctly, and that the master and slave
implement the same features.
For example, there are a number of parameters you’ll need to decide
upon when creating an I 2 C driver, such as 7- or 11-bit addressing,
single or multi-master (with collision detection and recovery), data
rate, whether to use ACK/NAK protocols, support for address holding,
and a slew of other options. As a result, any two particular I 2 C
interfaces can be very different. For example, one common problem
developers run into is mistaking the System Management Bus
(SMBus) used in laptops as a simple I 2 C bus. Even though the SMBus
runs over an I 2 C interface, it usually uses fi xed voltages for high and
low values whereas a generic I 2 C interface uses threshold values
which are typically based on a percentage of the MCU power supply,
thus representing a potential discrepancy between the two which can
create diffi cult-to-debug intermittent errors.
Note too, that UART, I 2 C, and SPI are just physical interfaces. You’ll still
need to supply a logical protocol that operates on top of the physical
layer. If the interface is between two MCUs under your design, this
protocol can be whatever you want it to be. If the MCU is talking to
a device like a serial EEPROM, then the protocol is already defi ned
for you. As a consequence, a driver for a master is likely to be more
complex than a slave given the number of different devices and their
protocols it may communicate with. In addition, if your master doesn’t
support all of the protocols features a slave does (or, conversely, tries
to use a feature a slave does not support), compatibility problems will
eventually surface.
The simplicity of each of these interfaces is both its advantage and
curse. You can implement intricate protocols, which makes the
interface more effi cient and powerful, but this can also make it more
diffi cult to debug. The simplicity gives you all the rope you need to
hang the system up if you aren’t careful.
For example, consider an application where the interface is
controlling an analog multiplexer which needs to smoothly transition
between two audio streams. Depending upon how the transition is
implemented, there can be undesirable – and audible – side effects;
i.e., switching from a soft to loud stream can result in a loud “Pop!”
Additionally, command latency may affect the transition. Ideally,
you’ll want to run the audio down, switch streams, and then run
the audio back up. However, this may not always be convenient for
your application. The same diffi culties apply if you are working with
multiple power supplies at the same time.
To facilitate initial driver design and verifi cation, many vendors
offer powerful development tools for implementing and verifying
interface functionality. For example, Microchip offers the PICkit Serial
Analyzer which connects to your system and to a PC which you use
to confi gure the link as a master or slave with any of the standard
interface options for UART, I 2 C, and SPI. A classic problem in interface
design is the need for a pre-existing master to design a slave or
a pre-existing slave to design a master. The PICkit eliminates this
problem by providing a reliable other half of the link to design against
with visibility into what’s being sent over both sides of the link. The
PICkit also has the capable of emulating a variety of I 2 C peripherals
like ADCs and fan controllers.
Many MCU vendors also offer a variety of full-featured development
kits and libraries to facilitate the introduction of subsystems such
as an LCD display, touchscreen, or other peripheral to a system.
For example, TI offers the RDKIDML-35 Intelligent Display module
reference design kit which makes it relatively easy to add a 3.5”
QVGA touchscreen to a system connected over either an I 2 C or SPI
link. The kit also includes a software library with various GUI functions
to speed user interface design.
Figure 1: PICKit Serial Analyzer.
Avoiding common pitfalls
In the end, the best way to learn to implement a UART, I 2 C, or SPI
link is to do it yourself. The following list of tips and tricks has been
suggested by experts from a variety of MCU manufacturers to help
you avoid some of the more common mistakes, misconceptions,
and missteps developers often take when implementing their fi rst
processor-to-processor interface.
16