Microcontroller Solutions TechZone Magazine, April 2011 - Digikey

MICROCONTROLLER LIGHTING SOLUTIONS SOLUTIONS
TZ TL101.US M 112.CA
Look Inside Today’s
Connectivity Protocols!
uIP TCP/IP
Protocol Stack
Demonstration
Page 22

Leading-Edge
Suppliers
for Your
Leading-Edge
Designs

MICROCONTROLLER SOLUTIONS
TZ M 112.CA
Digi-Key Corporation brings you TechZones SM featuring suppliers,
products and resources for Lighting, Microcontroller, Power, Sensor,
and Wireless technologies, with more sites to come. Resources
include application notes, reference designs, white papers, links to
product training modules, and more!
Quick Way to Find Digi-Key’s TechZones SM :
• Links located on our homepage
• Links located in our header under Resources
• Links located in our toolbar
• www.digikey.ca/techzones
uIP TCP/IP Protocol
Stack Demonstration
contributed by Renesas Corporation
The popular open source uIP TCP/IP stack is widely used in embedded
designs. This demo provides both hands on experience and
insights into its use.
22
2011 DIGI-KEY CATALOGUE
AVAILABLE NOW!
View our environmentally-friendly interactive
and PDF catalogues online or request your
annual Digi-Key print catalogue today!
www.digikey.ca/catalogue
www.digikey.ca/microcontroller
3

Table of Contents
Digi-Key Features
Editorial Comment ................................................... 5
Microcontroller TechZone SM Q & A ............................
6
Trivia Contest ......................................................... 39
Innovations in Connectivity:
a look inside Digi-Key’s
state-of-the-art Weather Center ............................. 47
The Ultra-Low-Power USB Revolution ......................... 7
by Bhargavi Nisarga, Keith Quiring, and Les Taylor, Texas Instruments
USB is a fast, convenient connectivity interface, but until recently it
hasn’t been associated with low-power. New MCUs have made it an
attractive choice for ultra-low-power embedded applications.
USB-Based Temperature Monitor .............................. 12
contributed by Analog Devices
If you need to be able to detect small variations in temperature, an
RTD or thermocouple won’t do it. Using a thermocouple, an analog
MCU, an LDO and a few discretes, you can construct a highly accurate
temperature sensing application.
Introducing a Second MCU
to Embedded Designs ................................................. 15
by Nicholas Cravotta
Adding a second MCU to your embedded design addresses a number
of design issues, but not without adding some complex new ones.
This article focuses on inter-processor communications and how to
both avoid and/or solve the issues that arise.
Eliminating the Parallel/Serial Tradeoff
in Embedded Systems with
SPIFI-Equipped Cortex-M3 ......................................... 19
by Rob Cosaro and Gene Carter, NXP Semiconductors
The SPIFI peripheral creates a way for designers to use a small,
inexpensive serial fl ash where they might previously have needed
to use a larger, more expensive parallel fl ash to meet the system’s
performance requirements.
ColdFire Ethernet for Diverse Applications ................ 26
by Eric Gregori, Freescale Semiconductor
Adding Ethernet to embedded products provides a level of
connectivity never before available in the embedded space. This
article provides a detailed tutorial, an example application and XML
code to quickly get you comfortable with embedded Ethernet.
Your MCU is Just Starting to be Connected ............... 36
by Tom Starnes, Industry Analyst, Objective Analysis
Embedded applications, like individual PCs, become more useful
when they can communicate with other devices. A wide range of
protocols has been developed to enable such communication, but that
work is far from over.
Deeply Embedded Devices:
The “Internet of Things” ............................................. 40
by Mark Wright and Rodger Richey, Microchip Technology Inc.
Wi-Fi has long worked well to connect PCs and embedded devices.
However, it’s not known for being low-power and is hardly an obvious
choice for deeply embedded devices. That’s about to change.
Peripheral Reflex System
Avoids MCU Overload ................................................. 44
contributed by Energy Micro
Energy Micro’s Peripheral Refl ex System minimizes MCU loading by
enabling peripheral modules to communicate with each other without
processor intervention. This article details how it works and why.
CAN Primer: Creating Your Own Network .................. 48
by Bob Boys, ARM
CAN is a sophisticated network well suited to any number of
automotive, industrial and consumer applications. This article takes
an in-depth look at the protocol, its implementations and implications
for embedded designs.
Power Debugging ARM Cortex-M3
and Cortex-M4 Applications ...................................... 58
by Lotta Frimanson and Anders Lundgren, IAR Systems
Power debugging is based on the ability to sample the power
consumption of a system and correlate each sample with the source
code. ARM Cortex-M3 and –M4 cores provide the architectural hooks
and IAR provides the software to make this possible.
The Heartbeat Behind
Portable Medical Devices: Ultra-Low-Power
Mixed-Signal Microcontrollers .................................. 61
by Shahram Tadayon, Silicon Laboratories
In the medical device market, products must combine accurate
analog measurements with high reliability and ultra-low-power
consumption. Fortunately, there are some integrated mixed-signal
MCUs that can deliver on all three requirements.
USB 3.0—Are We There Yet ...................................... 64
by John Donovan, Low-Power Design
SuperSpeed USB promises a 10x speed improvement over USB 2.0
while maintaining compatibility with legacy devices. If your next
application involves streaming video, take a look at what it has to offer.
4

Editorial Comment
The Energy Management, Lighting, Medical, and Hybrid/Electric
Auto markets are quickly gaining scale and are directly driving an
explosion of microcontroller usage. As microcontroller designs
expand into new areas, so do the connectivity requirements, which is
the theme of this issue of TechZone Magazine.
In this issue, we explore all facets of Microcontroller connectivity
protocols and how to overcome typical technical roadblocks. You
will fi nd a strong selection of articles to support your connectivity
protocol design decisions including:
• “uIP TCP/IP Protocol Stack Demonstration” – a step by step
guide using Ethernet connectivity with the titled protocol stack
contributed by Renesas (page 22)
• “Introducing a Second MCU to Embedded Designs” – an article on overcoming the
common pitfalls of adding a second MCU to your design written by Nicholas Cravotta
(page 15)
• “The Ultra-Low-Power USB Revolution” – an article on integrated USB connectivity
written by a trio of authors from Texas Instruments (page 7)
If your design is integrated into a Lighting, Wireless or Sensor solution, see our recent
TechZone magazines focusing on those areas at www.digikey.ca/magazine.
When the design is complete and it’s time to build your product, remember that Digi-Key:
• Stocks over 565,000 components available for off-the-shelf delivery anywhere in the world
• Ships 99% of orders received by 8pm central time the same day
• Offers world-class supply chain support and customer service
While it’s unclear how the political uncertainty in the Middle East will affect the global
economy; it is very clear that microcontrollers will continue to pervasively expand into
products that touch our everyday lives. We believe that the information and insights in this
issue of TechZone Magazine will support your next generation product ideas and solutions.
Sincerely,
Mark Zack
Vice President, Semiconductor Product
Digi-Key Corporation
Mark Zack
Vice President, Semiconductor
About Digi-Key Corporation
As one of the world’s fastest growing
distributors of electronic components,
Digi-Key Corporation has earned its
reputation as an industry leader through
its total commitment to service and
performance. As a full-service provider
of both prototype/design and production
quantities of electronic components,
Digi-Key has been ranked #1 for Overall
Performance for 19 consecutive years
from among the nation’s more than 200
distributors (EE Times Distribution Study/
October 2010). Offering more than 1.9
million products from more than 470
quality name-brand manufacturers,
Digi-Key’s commitment to inventory is
unparalleled. Access to the company’s
broad product offering is available 24/7
at Digi-Key’s top-rated website.
www.digikey.ca
Digi-Key’s TechZone Magazine is a monthly
series of technology-specifi c publications
featuring information and resources for Lighting,
Microcontrollers, Wireless, and Sensors, with
more technologies to come. TechZone
Magazine
provides the engineering community,
from students to professional design engineers,
with information about supplier innovations,
quality in-depth solutions, and a selection of
application-specifi c considerations focused on
advancing technology.
Contact Information
For questions, comments, or to submit an article:
tzcontent@digikey.com
For information about advertising oppotunities:
techzoneadvertising@digikey.com
To be added to the mailing list:
www.digikey.ca/request
Copyrights: The masthead, logo, design, articles, content and format of
TechZone are Copyright 2011, Digi-Key Corporation. All rights are reserved.
No portion of this publication may be reproduced in part or in whole without
express permission, in writing, from Digi-Key.
Trademarks: DIGI-KEY, the Digi-Key logo, TECHZONE, and the TechZone logo
are trademarks of Digi-Key Corporation. All other trademarks, service marks or
product names are the property of their respective holders.
All product names, descriptions, specifi cations, prices and other information
are subject to change without notice. While the information contained in this
magazine is believed to be accurate, Digi-Key takes no responsibility for
incorrect, false or misleading information, errors or omissions. Your use of
the information in this magazine is at your own risk. Some portions of the
magazine may offer information regarding a particular design or application
of a product from a variety of sources; such information is intended only as a
starting point for further investigation by you as to its suitability and availability
for your particular circumstances and should not be relied upon in the absence
of your own independent investigation and review. Everything in this magazine
is provided to you “AS IS.” Digi-Key expressly disclaim any express or implied
warranty, including any warranty of fi tness for a particular purpose or noninfringement.
Digi-Key cannot guarantee and does not promise any specifi c
results from use of any information contained in this magazine. Any comments
may be addressed to techzone@digikey.com.
www.digikey.ca/microcontroller
5

Microcontroller TechZone SM Q & A
In the rapidly evolving microcontroller market, it seems as if there is something new every day – technologies, products,
consumer trends, or regulations. Time-to-market demands have never been greater with the design of many of today’s
new microcontroller products requiring expertise in more than one discipline.
You have questions. We have answers. On target to field more than 260,000 calls this year, our technical support
specialists are available 24/7/365 to answer your questions and assist you with your microcontroller needs.
If you have a question, we invite you to contact our technical staff via telephone, live web chat, or by emailing your
question to techzone@digikey.com.
How does USB 3.0 differ from USB 2.0
USB 3.0 offers a “SuperSpeed” bus feature. USB 3.0 cables have
two wires for power and ground, two wires for “non-SuperSpeed”
data, four additional wires for the “SuperSpeed” data, and a shield
which was not needed in other USB versions. The “SuperSpeed” bus
offers a forth transfer mode at 5.0 Gbits/s. The physical form factor
has changed for the USB 3.0 plugs and receptacles to accommodate
the additional pins for the “SuperSpeed” mode. The standard-A
plugs are extended as well as the receptacles are deeper. For the
Standard-B connectors, the “SuperSpeed” contacts are placed on
top of the existing connector. A legacy standard A to B cable will
work normally in these connectors as the legacy connectors will not
make contact with the new contacts for the “SuperSpeed.”
This ensures backwards compatibility. On the fl ip side, though, the
USB 3.0 connector will not mate to the legacy receptacles.
What are the common applications for CAN (Controller
Area Network)
CAN was fi rst developed with automotive applications in mind.
An example of this is in-vehicle electronic networking. However,
since its development CAN has been utilized in medical, industrial
and commercial applications. Examples of medical applications
include operating room components such as lights, tables, cameras,
patient beds and X-ray machines. Industrial application examples
include motor control and robotics. Finally, commercial application
examples include lab equipment, telescopes, and automatic doors.
How is an SPI master/slave connection set up
SPI is a protocol on four signal lines. A clock signal (SCLK) is sent
from the bus master to all slaves. A slave select signal for each slave,
SSn, is used to select the slave the master communicates with. A
data line from the master to the slaves called MOSI (Master Out-Slave
In) and a fi nal data line from the slaves to the master called MISO
(Master In-Slave Out) comprise the other two signal lines.
What is the difference between a UART and USART
A UART is a universal asynchronous receiver/transmitter where a
USART can communicate synchronously as well as asynchronously.
Does the operating ambient temperature include the selfheating
of the MCU
The operating ambient temperature is the ambient temperature in a
state without MCU self-heating. More specifi cally, consider it to be
the temperature of the surroundings infi nitely close to the package
surface when the MCU is not powered on.
What does it mean if a microcontroller supports big endian
or little endian, what does endian mean
The term “endian” refers to how individually addressable subcomponents
are ordered within a longer data item stored in memory.
Let’s say we had a block of memory that had ABCD stored, four bytes.
For the big-endian method, the most signifi cant byte value, which is A in
our example, is stored at the memory location with the lowest address,
0x00, the next byte value, B, would be stored at the following memory
location, 0x01, and so on. For the little-endian method, the least
signifi cant byte value, D, is stored at the lowest address, 0x00, the next
signifi cant byte, C, in the following memory location, 0x01, and so on.
What is the difference between SPI and I 2 C
SPI uses four logic signals commonly called: SCLK (Serial Clock),
MOSI (Master Output, Slave Input), MISO (Master Input, Slave
Output) and SS (Slave Select). While I 2 C uses only two bi-directional
open-drain lines commonly called: SDA (Serial Data Line) and SCL
(Serial Clock). Additionally, to add additional slaves, SPI will end up
being more than four signal lines, where I 2 C will stay with the same
two lines. In relation to speed, SPI is a higher speed protocol, over
10 Mbps. I 2 C is limited to data rates that are chosen between 100
kbps, 400 kbps or 3.4 Mbps.
Do you have a question about
microcontroller solutions
Digi-Key has more than 130 technical support
specialists, product managers, and applications
engineers who are eager to answer your questions
and assist you with your microcontroller projects.
Send your questions to techzone@digikey.com.
6

The Ultra-Low-Power
USB Revolution
by Bhargavi Nisarga, Keith Quiring, and Les Taylor, Texas Instruments
New MCUs bring power efficiency and
simplicity to USB for portable embedded
applications.
The ubiquity of USB makes it an extremely attractive interface for
applications requiring connectivity to a PC or other host device for
configuration, periodic downloading of data, or firmware updates.
Often these devices are portable, such as medical or industrial tools
which remotely collect data that needs to be uploaded at a later time.
As these devices are portable, the final USB implementation must be
both cost-effective and power efficient.
One of the main reasons for USB’s success is its unparalleled ease
of use. But under the surface, USB is a complicated technology that
artfully masks the user from the complexity. As a result, developers
new to USB often underestimate the effort involved. Many new terms
and procedures are also encountered, and things often do not “just
work” the way they should.
Hidden challenges may result in unexpected delays for the developer,
and delays are expensive.
To developers trying to focus on differentiating their products and
offering the best value to their customers, these challenges are an
unwelcome burden. For this reason, TI has committed to delivering
USB technology as an integrated, simplified solution that enables
developers to focus on using USB in their application rather than
learning USB as a technology.
Introducing the MSP430TM USB microcontroller
To meet the needs of developers, TI has introduced full-speed USB to
the F5xx series of MSP430 microcontrollers (MCU). By integrating USB
with powerful performance (up to 25 MHz), large memory (both Flash
and RAM), integrated intelligent peripherals (including an on-chip
ADC, comparator, hardware multiplier, DMA controller, temperature
sensor and other peripherals), and superior power management,
the MSP430 is the ideal MCU for implementing USB in embedded
applications (see Figure 1).
With the simple addition of a USB connector and a few discretes,
MSP430 USB MCUs are a complete solution for applications that
require USB connectivity and analog peripherals, while being
ultra-low-power. From a software standpoint, TI provides API stacks
supporting three of the most common device classes.
Figure 1: Integrating USB with the powerful performance and high integration of
the MSP430 architecture creates the ideal microcontroller for implementing USB in
embedded applications.
The new MSP430 USB MCUs are based on TI’s newest and most
advanced MSP430 architecture, the F5xx. Each supports 1.8 to
3.6 V operation, with clock speeds up to 25 MHz and integrated,
programmable power supervision on the order of 200 nA. New clock
sources further maximize tradeoffs between power, speed, precision
and cost. Flash writes/erases can be performed across the full range
of Vcc. In addition to offering a wide range of flash memory sizes (64
to 128 KB and 16 to 256 KB), USB-enabled MSP430 devices also have
2 KB RAM dedicated to USB that, when USB is disabled, is available
for general purpose use.
Accelerated development and ease of use
TI recognizes that consumers – and engineers – have come to
expect that USB “just works.” In truth, while USB looks as simple
as a UART or SPI port, the protocol is not trivial to implement.
And unlike the UART or SPI interfaces, compliance is a primary
USB design consideration, even in the simplest applications. For
example, a host can suspend an attached device at any time.
Devices must also be able to handle “surprise removals.” For
developers who have not been through this process before, such
unexpected considerations can require extra development time and
lead to unexpected delays.
Part of the value-add of the MSP430’s USB support is that much
of the underlying complexity of implementing USB is managed
through an intuitive API stack. The API stacks are designed for fast
absorption by the developer. Like USB itself, they contain much
of the complexity “under the hood,” masking the developer from
unnecessary hassle to help speed development time. The stack
www.digikey.ca/microcontroller
7

source code is open for those developers wishing for complete
control. For each stack, a complete Programmer’s Guide is provided
that serves as a reference for the API function calls and also
describes the underlying concepts with clarity.
Further, TI provides the MSP430 USB Descriptor Tool. This tool
serves as a “control panel” for the API stacks, allowing for quick
confi guration. It automatically creates the descriptors that every USB
device must report to the host, based on user input. This saves the
developer considerable time and provides peace of mind that the
descriptors are done correctly.
Stacks are available for the most common device classes and are
supplied without additional charge. While developers should not
underestimate what is required to create a robust USB interface,
TI has signifi cantly shortened the USB learning curve. In this way,
developers are freed of much of the burden of learning the intimate
details of USB as a technology and instead are able to focus on using
USB to increase the value and usability of their applications.
Multiple device classes
Part of the simplicity offered by the MSP430 USB API Stack is support
for three device classes:
Communications Device Class (CDC): The CDC presents the
USB port to the PC application as a standard COM port. COM ports
are popular interfaces that are fl exible, fast, and simple to use.
Because it uses bulk transfers, the CDC provides high bandwidth
with a reasonable amount of simplicity. The chief disadvantage of
using the CDC is that developers must distribute a simple fi le to
end users that allows it to be associated with the CDC driver built
into Windows. Fortunately, the “new device detected” installation in
Windows is fairly straightforward and a minor step already wellaccepted
by end-users.
Human Interface Device (HID): While HID is commonly thought of as
primarily for mice and keyboards, it is a fl exible device class suitable
for a wide variety of applications. TI’s HID API effi ciently generalizes
HID capabilities, thereby eliminating the complexity associated with
HID reports by allowing developers to access the interface in the
exact same way they would a CDC device/COM port. While it has
limited bandwidth (up to 64 KB/s), it requires no fi le to be distributed
as CDC does, and it loads silently in Windows with no installation
process required.
Mass Storage Class (MSC): MSC is the device class used to
implement the highly successful USB “fl ash drives,” as well as
digital cameras and fl ash card readers. Since it is designed for
moving large amounts of data, it provides higher bandwidth, similar
to that of CDC. The tradeoff is more complexity – for example,
developers will need to implement a fi le system – and the use of
more code space. Like HID, MSC devices load silently in Windows
without the need of an installation process. TI offers the MSC API
layer at no cost. Given the wide variety of confi guration possibilities
for software handling fi le systems, the different media types,
and Flash management (i.e., through wear-leveling and other
techniques), developers have the fl exibility of buying a commercial
implementation or using one of the many open-source systems
available for the MSP430.
Of the three device classes, developers should begin by considering
HID. If an application can work within the available 64 KB/s
bandwidth, HID will often be the most cost-effective choice given
that users can plug it in and use it without the need of an installation.
Since the Windows installation process can sometimes lead to
problems for the user, avoiding it can lead to a reduction of support
calls and returns from customers.
The TI USB API stacks support three data transfer types: control
for USB-level control/status data, interrupt for low bandwidth,
fi xed latency data, and bulk for high bandwidth, variable latency
data. Usage of these data types is determined by the device class;
developers need not concern themselves with most of the details
associated with the different types.
With these data types, the MSP430’s USB can support any application
requiring control/confi guration, fi rmware updating, or that needs to
transfer bulk data (as opposed to streaming data). The MSP430 does
not support isochronous (high-bandwidth, fi xed latency) data, so it is
not appropriate for streaming audio/video applications.
Just as the MSP430 is fl exible, so is its USB functionality. Any USB
device contains a certain number of what are called endpoints.
Support for multiple endpoints allows for composite USB devices
which can have more fl exible communication with hosts. For example,
a device that uses the MSC for bulk data transfers and HID to manage
control and status is comprised of three input and three output
endpoints. The MSP430 architecture supports up to eight input and
eight output endpoints, which provides suffi cient capacity for most
applications without overburdening cost.
Ultra-low-power efficiency
By its nature, the MSP430 architecture has been optimized for
low- power operation, both when USB is in use and when it is not. For
example, MSP430 devices have fi ve low-power modes that enable
designers to extend battery life in portable applications. The MSP430
delivers high performance at the lowest power consumption with
an active power consumption as low as 160 µA/MHz and 1.5 µA in
standby mode coupled with fast wakeup from standby (less than
5 microseconds) and a supply voltage as low as 1.8 V operation.
The onboard DMA controller can also save signifi cant power when
communicating with a battery-powered host.
One of the advantages of USB in embedded applications is the
ability to power devices over the interface. Ideally, battery-powered
devices can maximize operating life by powering the device over
the bus when attached to a host. As USB hosts source 5 V over the
bus, an LDO is required to drop the voltage to the 3.3 V typical of ICs.
MSP430 devices simplify power design and conserve board space by
integrating an effi cient LDO as well as associated pull-up functionality.
In addition to allowing MSP430s to operate directly from 5 V,
integrating the LDO and pull-up resistors reduces component count
and eliminates $.15 to $.20 relative to discrete implementations.
By keeping the USB power and other MSP430 modules’ power
management separate, the USB module can always be powered as
long as the USB device is connected to the host. This also enables the
USB module to auto-powerup the MSP430 via USB power even if the
device battery is dead or non-existent.
8

Figure 2: MSP430 USB microcontrollers can source power off the USB bus to power
the entire system with 12 mA.
MSP430s are designed to operate within the power limits of the
LDO and can even source power off the USB bus to power the entire
system. By driving the 3.3 V output externally (VUSB), the MSP430 can
supply the system with up to 12 mA (see Figure 2), and eliminate the
need for a system LDO as well. For high-current systems (requiring
more than 12 mA of current) or for applications where it makes sense
to power a device from battery even when connected via USB, the
MSP430 offers the flexibility of bypassing the integrated LDO and
driving DVcc from an external supply or regulator (see Figure 3). TI
offers a variety of external LDOs well-suited for low-cost (TPS73033),
low-power (TPS67233), low-noise (TPS1733), and low-noise, highercurrent
(TPS73433/735) applications.
Figure 3: For high-current systems or for applications where it makes sense to power a
device from battery even when connected via USB, the MSP430 offers the flexibility of
bypassing the integrated 3.3 V LDO and driving DVcc from an external supply.
The 5 V USB bus power can also be used as a primary source to
charge batteries (see Figure 4). In this configuration, DVcc is always
sourced from the battery whether the USB port is plugged into a host
or not. When the port is plugged in, the charger receives power via
USB to recharge the battery. TI’s BQ2407x/3x family of chargers have
been specifically designed for USB battery charging applications.
Figure 4: Power over USB can also be used as a primary source to charge batteries.
TI’s BQ2407x/3x family of chargers has been specifically designed for USB battery
charging applications.
The low-speed USB used in mice and keyboards, for example, in
general is not appropriate for any application processing enough
data that it requires a modern, general-purpose MCU. Specifically,
transmitting at a slower data rate wastes bus bandwidth and
consumes more power by requiring the MCU to stay active for
significantly longer transmission periods. Likewise, high-speed USB
supplies too much bandwidth unless an application needs to support
large audio or video transfers. Full-speed USB is a much better fit for
most embedded applications.
While being an OTG appears to be an appealing option, it is not
appropriate for many applications. Embedded hosts must be able
to source 8 mA to attached devices. This requirement has led many
companies to reconsider their intention to support OTG host capability,
especially in applications where long operation life is required from
a single-cell battery. For applications that do require OTG support, TI
offers solutions within its Stellaris MCU portfolio.
In general, USB devices are less expensive, simpler, and faster to
develop than embedded hosts. The MSP430 family with USB was
optimized to meet the needs of USB devices without burdening these
applications with the added complexity, additional memory, integrated
peripherals and larger power supplies required to implement USB hosts.
Taking care of details
In order to deliver on its promise to simplify USB, TI provides a wide
range of tools and software to assist developers in quickly coming up
to speed on using and implementing robust USB solutions. In addition
to its API stack, TI also offers:
• USB Descriptor Tool: The USB Descriptor Tool plays a key role
in simplifying USB design and implementation. This GUI-based
tool automatically configures the USB stack to reflect the
specific requirements of a particular application, handling the
management of descriptor fields including VID, PID, strings,
how much power to draw from the host, and so on. Rather than
require developers to delve into the details behind the various
USB descriptor fields by breaking into the USB stack and writing
code to support their application, the Descriptor Tool gathers
the required information from developers and automatically
generates the appropriate software modifications to the API
stacks, requiring no further work from developers. In addition,
the USB Descriptor Tool is intended to make the high-level stack
configuration of composite devices much simpler.
• Bootstrap Loader (BSL): TI’s BSL is another important tool
offered to developers who require field firmware update
capability. One of the common uses of USB is to push updates
to deployed devices. For example, a doctor could plug a medical
instrument into a PC and have it quickly and automatically update
itself with new features or bug fixes. The BSL tool simplifies the
updating process for developers by converting a firmware image
file into a self-contained PC executable that can be delivered to
end customers. All MSP430 devices are BSL-equipped and when
implemented over USB, updates can be made securely even when
the device is not powered (i.e., the MSP430 is powered via USB),
enabling fast and efficient production-line programming without
having to install batteries. For developers, the most complex
part of the bootstrapping process will be to customize the BSL
executable with their own logo.
www.digikey.ca/microcontroller
9

• haring Program TI also offers developers the opportunity
to participate in its VID Sharing Program. Every USB device
requires a Vendor_ID (VID) and Product_ID (PID). For companies
making only a few devices, TI can provide a VID and a unique PID
to bypass the investment of time and money required to register
a VID with the USB consortium.
By taking care of the “odds and ends” of implementing USB
through the USB Descriptor Tool, Bootstrap Loader, API stack, and
other support software from its extensive third party network,
TI has simplified the process of working with USB. By providing
most of the underlying foundation required for USB, TI’s MSP430
enables developers to focus on the value-added components of
their application without having to concern themselves with the
myriad implementation issues involved with a complex interface
like USB.
igh level of integration
In addition to integrating USB, these new controllers also integrate
a number of other features and peripherals beyond the standard
MSP430 architecture that further simplify development, including:
• Programmale P This fl exible, programmable PLL can
adapt to a wide range of crystal frequencies, enabling
developers to choose a frequency based on applicationrelevant
criteria such as cost, other components within the
system, or whether that frequency is needed elsewhere in the
system for another purpose.
• er opoer scillator The VLO enables developers
to keep the USB module running when the host is suspended.
This is important because the USB module must be able to
recognize when the host wants to wake it. Current drawn by the
VLO in this manner is in the sub-µA range.
• omparator MSP430 USB microcontrollers also offer a new
comparator for the generation of hysteresis without the need
for external components. Many applications require the ability
to monitor an input against two thresholds, such as for battery
charging and capacitive touch interfaces. Typical comparators
can only monitor one threshold and must be confi gured to
watch for the rising or falling threshold and switch to the other
threshold when it is crossed. Known as Comparator_B, the new
comparator is a versatile reference generator using R-ladders
capable of generating 32 different voltage reference levels.
This approach avoids the need for external components as well
as the constant power drain when external resistors are used.
Comparator_B operates in three modes, ultra-low-power (0.1 µA
typical to 0.5 µA max.), normal (10 µA typical to 30 µA max.), and
high-speed (40 µA typical to 65 µA max.) for optimizing power
consumption to the application.
• Port Mapping A unique feature of USB-based MSP430
microcontrollers is the port mapping controller. With port
mapping, developers can dynamically reconfi gure digital outputs
such as Timer PWMs or SPI/I2C interfaces across a specifi c
range of pins. Such mapping enables fl exibility of signal routing
during board design, allowing designers to move signals to
the other side of the IC as required. Each digital output can be
mapped to multiple output pins, which can be useful in cases,
for example, where the same Timer PWM is required on multiple
pins. Port mapping also eases the challenges associated with
migrating from one family of devices to another in terms of
pin-to-pin compatibility.
etting started ith
Getting started MSP430 USB microcontrollers is very easy. The
MSP430F552x Sample Kit includes the 80-pin MSP-TS430 target
board (#MSP-TS430PN80-USB) complete with USB support as well
as sample silicon. With the proven tool chain of the MSP430 and the
comprehensive USB support package, developers already familiar
with the MSP430 can introduce USB to their applications with
little effort. In addition, TI’s many third parties supply a wide range
of software and hardware to speed development and accelerate
time-to-market.
Developers can choose from three families of USB-enabled MSP430
microcontrollers, each with a fl exible roadmap and options that scale
to meet a variety of embedded application requirements:
• Midrange applications The F552x / F551x supplies 64
to 128 KB Flash and 4 to 8 KB (+2 KB) RAM, as well as
Comparator_B functionality. F552x \ F551x devices are
sampling now.
• ighend applications The F563x/F663x is perhaps the most
feature-rich, integrated MSP430 device ever produced. With
128 to 256 KB Flash and 16 KB (+2 KB) RAM, this device has
six DMA channels, an RTC backup mode (enabling the RTC to
operate at less than 1 µA even when Vcc is lost), and many
other integrated peripherals.
• oend applications The F550x provides cost-effective USB
with 16 to 32 KB Flash and 4 KB + 2KB RAM as well as a 10-bit
ADC and Comparator_B functionality.
TI’s new MSP430 USB microcontrollers reduce system cost,
offer superior power effi ciency to improve battery life, facilitate
fast implementation, and are easy to use. In addition to allowing
developers to focus on their application rather than USB as an
enabling technology, these new controllers also lower system
BOM by integrating several advanced peripherals and modules
that increase performance and improve power consumption while
reducing component count. With its comprehensive supporting
software and hardware, TI reduces the USB learning curve from
weeks to hours, making it cost-effective – and simple – to
introduce USB into a wide range of embedded applications.
Tools http://www.ti.com/msp430tools
ptodate documentation, product information, and softare
lins http://focus.ti.com/docs/prod/folders/print/msp430f5529.html
Tale Device class tradeoffs.
es es M es
Simplicity on host Yes Yes No
Simplicity on MSP430 Yes Yes No
Avoids user install process No Yes Yes
High bandwidth Yes No, 64 KB/s Yes
Code size 4 KB 4 KB 10 to 20 KB
10

MSP430x5xx Overivew
Texas Instruments
The MSP430x5xx MCU from Texas Instruments is the next
generation technology platform for the MSP430 series
of MCUs. The device features advanced ultra-low-power
technology, signifi cantly higher levels of integration,
and is designed
for customer
ease-of-use.
The product training
module for this
product allows
viewers to learn more
about the product
line’s features and
the device’s capability for easy migration. Direction to TI’s
collection of over 1,000 code examples and more than 100
application reports is included
in this product training module.
www.digikey.ca/ptm
MSP-EXP430F5438 Experimenter Board (MSP-EXP430F5438)
The MSP430F5438 Experimenter Board (MSP-EXP430F5438)
is a development platform for the latest generation of
MSP430 MCUs. It features a 100-pin socket that supports
the MSP430F5438 and other devices with similar pinout.
The socket allows for quick upgrades to newer devices
or quick applications changes. It is compatible with many
TI low-power RF wireless evaluation modules such as the
CC2520EMK. The Experimenter Board helps designers
quickly learn and develop
using the new F5xx MCUs,
which provide the industry’s
lowest active power
consumption, more memory
and leading integration
for applications such
as energy harvesting,
wireless sensing and
automatic metering
infrastructure (AMI).
www.devtoolsxpress.com
www.digikey.ca/texasinstruments-mcu
www.digikey.ca/microcontroller
11

USB-Based
Temperature Monitor
contributed by Analog Devices
Using an analog MCU, an LDO, an external thermistor, and a few discretes, you can construct a
highly accurate temperature sensing application.
Figure 1: ADuC7122 used as a temperature monitor interfaced to a thermistor (simplifi ed schematic, all connections not shown).
The circuit in Figure 1 shows how the ADuC7122 precision analog
microcontroller can be used in an accurate thermistor temperature
monitoring application. The ADuC7122 integrates a multichannel
12-bit SAR ADC, twelve 12-bit DACs, a 1.2 V internal reference,
as well as an ARM7 core, 126 kB flash, 8 kB SRAM, and various
digital peripherals, such as UART, timers, SPI, and two I2C
interfaces. The ADuC7122 is connected to a 4.7 kΩ thermistor.
Due to the small form factor of the ADuC7122 (7 mm × 7 mm,
108-ball BGA package) the entire circuit will fit on an extremely
small PCB, thus further reducing cost.
Similar in function to an RTD, thermistors are low-cost,
temperature-sensitive resistors and are constructed of solid
semiconductor materials, which exhibit a positive or negative
temperature coefficient. Thermistors are inexpensive and have
high sensitivity. They detect small variations in temperature,
which could not be observed with an RTD or a thermocouple.
However, thermistors are highly nonlinear; thus, they are limited to
applications with very narrow temperature ranges if linearization
techniques are not applied. Circuit linearization techniques can be
accomplished in software.
Despite the powerful ARM7 core and high-speed SAR ADCs,
the ADuC7122 still provides a low-power solution. With the
ARM7 core running at 326.4 kHz and the primary ADC active
and measuring the external
temperature sensor, the entire
circuit typically consumes 7
mA. Between temperature
measurements, the ADC and/
or the microcontroller can
be switched off to further
minimize power consumption.
Circuit description
The circuit shown in Figure 1 is
powered entirely from the USB
interface. The 5 V supply from the
USB is regulated to 3.3 V using
the ADP3333 (3.3V) low-dropout
linear regulator. The regulated
3.3 V supplies the DVDD voltage to the ADuC7122. The AVDD supply to
the ADuC7122 has additional fi ltering as shown. A fi lter is also placed
on the USB supply at the input of the linear regulator.
The following features of the ADuC7122 are used in this application:
• 12-bit SAR ADC.
• ARM7TDMI core: The powerful 16-/32-bit ARM7 core with
integrated 126 kB fl ash and SRAM memory, runs the user
code that confi gures and controls the ADC, processes the
ADC conversions from the thermistor sensor, and controls the
communications over the UART/USB interface.
• UART: The UART is used as the communication interface to the
host PC.
• Two external switches/buttons (not shown) are used to force the part
into its flash boot mode. By holding DOWNLOAD low and toggling the
RESET switch, the ADuC7122 will enter boot mode instead of normal
user mode. In boot mode, the internal flash may be reprogrammed
through the I2CWSD tool utilizing the USB interface.
• BUF_VREF: The band gap reference also connects through
buffers to the BUF_VREF1 and the BUF_VREF2 pins, which
can be used as a reference for other circuits in the system. A
minimum of 0.1 µF capacitor should be connected to these pins
to reduce noise.
12

The thermistor used in the circuit is a 4.7 kΩ resistor, model number
NCP18XM472. It is available in a 0603 surface-mount package.
The thermistor used in the circuit in Figure 2 has the following
specifi cations at 25°C: ß = 3500 (the ß parameter describes resistance
as a function of temperature) and resistance (R 25
) = 4.7 kΩ.
The USB interface to the ADuC7122 is implemented with an FT232R
UART to USB transceiver, which converts USB signals directly to the
UART protocol.
In addition to the decoupling shown in Figure 1, the USB cable itself
should have a ferrite for added EMI/RFI protection. The ferrite beads
used in the circuit are Taiyo Yuden, BK2125HS102-T, which have an
impedance of 1,000 Ω at 100 MHz.
The circuit must be constructed on a multilayer PC board with a
large area ground plane. Proper layout, grounding, and decoupling
techniques must be used to achieve optimum performance.
Figure 2: A simple temperature sensor
circuit implemented with the ADuC7122.
The input thermistor circuit
in Figure 2 is designed to
produce accurate temperature
measurements from 0°C to
90°C. Note that this system
contains no temperature
calibration. This circuit
contains a simple thermistor
circuit that does not contain
circuit linearization. If this
circuit employed linearization
techniques, it could function over a broader range of temperatures;
however, this would decrease the resolution of the sensor.
The circuit in Figure 2 is set up in a voltage divider confi guration. This
will allow us to transform the ADC result, D, into a measurement of
the resistance of RTH (thermistor) using the following formulas:
= ∗ (
( + ) )
Figure 3: ADuC7122 thermistor sensor measured output (converted to volts) with ADC0
versus temperature.
Figure 3 plots the response of the ADuC7122 to the thermistor sensor
detailed in Figure 2 over temperature.
Code description
The source code and a HyperTerminal confi guration fi le used to test
the attached circuit can be downloaded as a zip fi le at www.analog.
com/CN0153_Source_Code.
The UART is confi gured for a baud rate of 9600, 8 data bits, no parity
and no fl ow control. If the circuit is connected directly to a PC, a
communication port viewing application such as HyperTerminal can
be used to view the results sent by the program to the UART (Figure
4). The source code is commented to make it easier to understand
and manipulate. The code was compiled and tested using the Keil
µVision 3 application.
= 2 ∗ (
)
= ∗ (
= ∗ (( 2
+ 1) ) )
= 2 ∗ (
)
Once the resistance of the thermistor is calculated, the Steinhart-Hart
equation can be used to determine the ( 1
current ∗ ) temperature of the sensor.
= ∗ (
Using the following formula, the
(
ADuC7122
2
25
)
1)
is able to determine the
sensor temperature:
2 =
( 25
)
( 1 ∗ )
( 25
)
2 =
( 25
)
where:
T 2
= unknown temperature
V 1
= 298K
ß = ß parameter of the thermistor @ 298K or 25°C. ß = 3500
R 25
= resistance of thermistor @ 298K or 25°C. R25 = 4.7 kΩ
R TH
= resistance of thermistor @ unknown temperature as
calculated by formula above
Figure 4: Output of HyperTerminal communication port viewing application.
Common variations
The ADP3333 (3.3 V) can be replaced with the ADP120 (2.5 V),
which has a wider operating temperature range (−40°C to +125°C)
and consumes less power (typically 20 μA versus 70 μA) but has a
lower maximum input voltage range (5.5 V versus 12 V). Note that
the ADuC7122 can be programmed or debugged using a standard
JTAG interface. For a standard UART to RS-232 interface, the FT232R
transceiver can be replaced with a device such as the ADM3202,
which requires a 3 V power supply.
The thermistor circuit described here can be adapted to operate with
other precision analog microcontrollers, such as the ADuC7020 series,
the ADuC7023, and the ADuC7061 series.
www.digikey.ca/microcontroller
13

ARM7 Core MicroConverter
Applications and Tools
Analog Devices, Inc.
Analog Devices’ ARM7 series integrates high-precision
analog with an ARM7TDMI core. The small size and
integration of these devices makes them particularly
useful in a
wide range of
applications.
Experiencing the
product training
module regarding
the ARM7 series will
provide insight into
the industrial and
medical applications of which the device is often utilized,
along with example MicroConverter reference design
examples for the benefi t of any
purchaser.
USB-Based Emulator (ADZS-USB-ICE-ND)
Analog Devices’ cost-effective Universal Serial Bus (USB)-
based emulator provides an easy, portable, non-intrusive,
target-based debugging solution for Analog Devices JTAG
processors and DSPs. This powerful USB-based emulator
performs a wide range of emulation functions, including
single-step and full speed execution with pre-defi ned
breakpoints, and viewing and/or altering of register and
memory contents. With the ability to automatically detect
and support multiple I/O voltages, the USB emulator enables
users to communicate with all of the Analog Devices JTAG
processors and DSPs using a
full speed USB 1.1 on the host
PC. Applications and data can
easily and rapidly be tested
and transferred between the
emulators and the separately
available VisualDSP++
development and debugging
environment (sold separately).
www.digikey.ca/ptm
www.devtoolsxpress.com
ADuC7122: Precision Analog Microcontroller, 12-Bit Analog I/O, ARM7TDMI MCU
The ADuC7122 is a fully integrated, 1 MSPS, 12-bit data acquisition
system, incorporating high performance multichannel ADCs, 12 voltage
output DACs, 16-bit/32-bit MCUs, and Flash/EE memory on a single
chip. The ADC consists of up to 13 inputs. Four of these inputs can be
confi gured as differential pairs with a Programmable Gain Amplifi er on
their front end providing a gain between 1 and 5. The ADC can operate
in single-ended or differential input modes. The ADC input voltage is
0 V to VREF. A low drift band gap reference, temperature sensor, and
supply voltage monitor complete the ADC peripheral set.
• 13 external channel, 12-bit,
1 MSPS ADC
• 11 general-purpose inputs
• 0 V to VREF analog input range
• 12 × 12-bit voltage output DACs
• ARM7TDMI core, 16-bit/32-
bit RISC architecture
• JTAG port supports code
download and debug
• 41.78 MHz PLL with
programmable divider
• 126 kB Flash/EE memory, 8 kB
SRAM
• UART, 2 × I 2 C ® and SPI serial I/O
• Wake-up and watchdog timers
(WDT)
• Specifi ed for 3 V operation
• Active mode: 11 mA at 5 MHz,
40 mA at 41.78 MHz
Analog Devices and Digi-Key present New Product Express – a fast, easy way to
get ADI’s newest products. These products are in full production, having passed
ADI’s quality and reliability testing, and are available from Digi-Key to order today!
See New Product Express at www.digikey.com/newproductexpress
www.digikey.ca/analogdevices-mcu
14

Introducing a Second MCU
to Embedded Designs
by Nicholas Cravotta
There are numerous reasons to add a second
MCU to your design and numerous errors to
avoid once you do. This article considers the
arguments and options while pointing out the
pitfalls along the way.
With the wide variety of processors available today, there are a
great many reasons why you may find it to be a more cost-effective
choice to add new features to an application by introducing a
second microcontroller (MCU) or microprocessor (MPU) to your
design rather than trying to perform every task on a single, higher
performance processor:
• Cost: Migrating to a higher performance system MPU can have a
higher cost differential than adding an 8- or 16-bit MCU to take
on the added load.
• Power: Rather than expend the power to have the main
application processor continuously turn itself on to perform a
relatively simple operation such as monitoring a sensor bank
or checking if a key has been pressed, an 8-bit processor
can be introduced to perform these tasks. In essence, the
8-bit processor serves as a “power gate” by letting the main
processor sleep and waking it only when an event occurs that
requires its attention. This is especially effective with resistive
and surface capacitive touchscreens.
• Determinism: User interface (UI) functions involving compute
intensive tasks such as animation or audio can stress the
real-time deterministic behavior of a system. Rather than risk the
reliability of critical tasks such as motor control, a second MCU
can assume all “real-time” UI responsibilities.
• Diversity: Many systems can benefit from a modular design. For
example, a display module can be implemented with a different
processor to provide additional graphics, or streaming video
capabilities. By taking a modular approach, the main application
code does not need to be changed to add new features to the
system or to support different models.
• Simplicity: A product line may offer a wide variety of options.
For example, a product may have four screens, three keyboards,
and three connectivity options. When a single processor is
used, the design team has to maintain, test, and verify a
separate code version for each possible variant (4x3x3=36
distinct variants). When a secondary processor is used to
implement a new function, maintenance is required only
for each option (4+3+3=10). Note that with the first option,
the entire system needs to be tested and verified with every
variant, a complex and time-consuming process. When using
the second option, the main application code only needs to be
verified once. Each of the options can be verified separately
and with significantly less complexity.
• Conservation of I/O: An MCU can appear to be several devices
over an interface by responding to several addresses. For
example, the main application processor could issue a command
to turn on a fan which is intercepted by an MCU serving as a
virtual hub. This is an effective way to conserve I/O on the main
application processor since only one communication peripheral
is required to read and control multiple devices.
• Certification: Changing the user interface or introducing a new
interface like Wi-Fi to the main system requires the entire design
to be recertified for some markets. Implementing these functions
as an add-on module with a separate processor simplifies
the recertification process, significantly accelerating both
development and time-to-market.
UART, I 2 C, and SPI
There are many options available for interconnecting processors.
The most basic interfaces used for this purpose are Universal
Asynchronous Receiver-Transmitter (UART), Inter-Integrated Circuit
(I 2 C), and Serial Peripheral Interface (SPI). Today, many processors
offer hardware and software support for one or more of these
interfaces. For example, STMicroelectronicss’ STM32 Cortex-M3 32-
bit processors and 8-bit STM8L MCUs support all three. Alternatively,
Cypress’ PSoC family of programmable system-on-chip processors
have analog and digital blocks which can be configured to provide
multiple instances of each of these interfaces, allowing the interface
mix to be altered as required for different target markets. The
question becomes how many interfaces you’re going to need.
A UART operates up to 250 kbps, compared to 100 to 400 kbps for
I 2 C. SPI, which supplies its own clock, can operate at speeds over
1 Mbps. A UART link can typically be implemented in software using
an interrupt-based driver, so long as the driver doesn’t place too much
load or latency on the processor based on the application’s needs. An
I 2 C master can often be implemented in software, but a slave needs to
www.digikey.ca/microcontroller
15

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

Introduce complexity in stages: Do not try to implement the entire
system from the start. Begin with the basic driver and verify its
operation. Then add the protocol layer and verify again. Introduce
the application layer. Finally, operate the entire system with all of its
various concurrent tasks and interdependencies.
Design your system to abstract functionality: For example,
using a generic UI interface allows the main system to connect to
mechanical buttons, a keypad, or a touchscreen without having to
know which is actually connected. This approach also allows you to
fundamentally modify how a function is performed without requiring
any code changes to the main system. Consider a vending machine
with a separate processor handling coin and bill collection. If a
security problem arises (i.e., customers have figured out a way to
cheat the machine), only the hardware and software used to monitor
collection need to be redesigned to prevent this; the rest of the
system remains unchanged.
Figure 2: RDK_IDM L35.
Recognize that peripherals are different than processors:
Connecting to a peripheral is different than connecting to another
processor. When you control the software on both sides of the
interface, you define the interface specifics and protocol on both
sides and can therefore guarantee compatibility. When you only
design one side of the interface, you need to design your interface
to match the requirements of the peripheral to which you are
connecting. This can give rise to many potential problems. The
most common is the datasheet for the peripheral inaccurately
describing how the interface has been implemented. To avoid this
problem, verify how the interface has been implemented. Also be
aware that various interface options such as 11-bit addressing,
clock stretching, or multi-master support may not be supported
by a peripheral and that if you try to implement a feature that the
peripheral did not implement, the results will be unpredictable.
Specify a sufficient data rate: Confirm that the data rate of the
interface will meet both your current and future data needs. For
example, a small display requires a lower data rate than a larger
display or equivalent touchscreen. If you plan to support larger
displays in next-generation designs, keep your interface options open.
Account for overruns: Getting an I 2 C or SPI link up and going is
fairly straightforward. Where you are likely to encounter difficulties
is at the corner cases. For example, the interface may operate
properly up to a certain frequency, at which point it begins to fail.
The problem could either be from too much noise in the system
or a data overrun. A data overrun may be a local problem; a series
of a particular type of packet may require more processing time,
resulting in the processor not emptying the buffer fast enough. More
often, overruns are caused by system-level issues. For example,
the DMA or FIFO used by the interface may be a shared resource.
Depending upon what else is being processed by the system (i.e.,
the real-time operating system is managing several real-time tasks
simultaneously), latencies may be greater than estimated, causing
an overrun.
Verify the driver first: When a problem arises, it can be difficult to
determine the cause of the error. This is especially true in systems
managing multiple interfaces or real-time tasks where errors
can arise because of what else is happening in the system. Get
the systems talking reliably first by verifying your drivers before
introducing application-level functionality. This allows you to more
confidently eliminate the driver as the source of the problem during
later debugging.
Debug using code instrumentation: Debugging both sides of
an interface can be tricky because you are working with multiple
processors. While there are tools for debugging multiprocessor
systems, they often allow you to halt only one side of the link, making
it difficult to utilize traditional debugging techniques. If you are using
the same type of processor on both sides of the link, you have the
option of having the one processor send and then receive its own
signal; this allows you to watch both sides of the link and halt them
simultaneously. If you are debugging over JTAG, you may be able to
connect both processors to the same JTAG chain.
Once you mix architectures, however, you may find yourself forced
to debug one side of the link at a time. To simplify debugging,
limit the complexity of the other side of the link by creating a
simple stub driver that allows you to test basic functionality in
stages. As you begin to work with live systems on both sides of
the link, you can use the debugger on one side of the link and use
code instrumentation techniques on the other side of the link to
facilitate debugging. The instrumented side of the link can use the
link itself to send status information such as variable values, data
received, and other important information back to the processor
being debugged.
Exploit your debugger: Some engineers try to solve programming
issues without a debugger. When they encounter an error, they try
something different in the code. Many interface issues, however,
are caused at the system level and rewriting interface driver code
is not the solution. Observing these system-level interactions may
require a debugger.
Check your connections: Triple-check your connections before
debugging a problem. For example, an easy error to make is to hook
up the control signals of the interface but fail to have a common
ground. Do this and you may find yourself spending hours trying to
resolve a non-existent problem.
www.digikey.ca/microcontroller
17

Document your code: Take the time to write clean code with
complete comments. A simple I 2 C driver might only run 15 lines
and not seem to require documentation. However, if you are new
to I 2 C, you may have missed a critical parameter that you come to
understand more about at a later time. Complete documentation
gives you a reliable path for tracking your changes in thinking and not
getting lost as the complexity of the application increases.
Question the spec sheet: Because of its greater fl exibility,
developers typically encounter more issues with I 2 C than with
SPI. For example, the slave can adversely affect the master by
holding the clock down, using a different addressing mode, or
implementing start/stop sequences differently. Be wary even if you
are connecting to a peripheral like a sensor with a detailed data
sheet. The peripheral may not follow the spec, so don’t immediately
assume your driver or the MCU is at fault if you can’t get an interface
working. It is times like these that you may need a logic analyzer to
locate the true source of the problem.
Have access to a logic analyzer: This tool is especially useful when
you have to connect to another device with an existing interface
and protocol. It can also accelerate development when connecting
to peripherals with a parallel interface like a display. Be sure to
check if your logic analyzer supports the appropriate decode for
the interface you are using. Automatic decoding can substantially
simplify debugging by allowing you to observe the interface as a
logical signal rather than having to convert the physical signal to a
logical signal yourself.
Design for coexistence: In a multi-master system, sometimes you
will need to make sure to send data to multiple destinations without
risking giving up the bus to another master. To achieve this, you can
use a restart condition between each transmission to keep control
of the bus. Similarly, you can use a restart to change the direction
of data to receive data from a slave (i.e., EEPROM) without letting
go of the bus. A master that locks the bus in this way, however, can
create latency issues for other masters performing tasks that are
also time-critical. Use such techniques sparingly and thoroughly test
the interplay between masters to ensure that they operate well with
each other.
Design slave/master-capable drivers: Consider giving your slaves
the ability to become a master. This can be useful in the case of
system failure, allowing a slave to take over the bus and initiate
recovery mechanisms with signifi cantly less latency than if the slave
has to wait until it is addressed before it can signal an alert.
Separate data processing from data transmission: Often, the
data collected (i.e., a voltage from a temperature sensor) is very
different from the data that needs to be transferred (i.e., whether a
temperature threshold has been crossed). Consider an interface to a
touchscreen module where the main system, acting as the master,
asks for the current fi nger position data. The module collects the
raw data and stores it until position data is requested by the master.
At this time, the module retrieves the raw data, processes it, and
then transmits it.
This particular architecture can innocently create an overrun
condition. Consider that to maintain responsiveness, the main system
may ask for information at a higher frequency than at which the raw
data actually changes. This means that with each request, the module
has to recompute the position data using data-intensive algorithms,
even if the data has not changed. Because the raw data is being
computed multiple times, the result is tremendous overhead that can
affect the responsiveness of the module.
There are several ways to eliminate such overhead. For example,
a check could be made before the position data is computed as to
whether the raw data has changed suffi ciently or not. If the raw data
has not changed, the previous calculation is used. Another approach
would be to have the touchscreen module serve as the master over
the link and send an update whenever the position has changed.
Keep the interface simple: If you only have one master and one
slave, there is no need to implement address collision. Of course, take
into consideration future expansion and whether a deployed device
may need to support such a feature to be compatible with future
generations of devices.
With today’s integrated MCUs and MPUs, coupled with powerful
development tools, designing your fi rst processor-to-processor
interface can be a simple process that allows you to quickly introduce
a second processor to your existing design. By taking care in your
design, you can avoid many common pitfalls to create a reliable
and effi cient interface that will meet the performance needs of your
application today and into the future.
ATmega128RFA1
Wireless MCU
Atmel
The ATmega128RFA1 wireless MCU is a single-chip
microcontroller that is known as the world’s fi rst
wireless AVR. This device consists of a unique Atmel
microcontroller and an RF transceiver and offers the
highest system
integration and best
cost-effi ciency.
Digi-Key’s product
training module
for this product
features information
regarding the
integration of
the AVR MCU with the RF module, reviews the power
specifi cations offered with this series, and provides
in-depth application examples.
www.digikey.ca/ptm
18

Eliminating the Parallel/Serial
Tradeoff in Embedded Systems
with SPIFI-Equipped Cortex-M3
by Rob Cosaro and Gene Carter, NXP Semiconductors
Choosing parallel versus serial flash has
traditionally meant gaining speed at the cost of
complexity. This no longer needs to be the case.
The SPI Flash Interface (SPIFI), a patent-pending feature initially available
on NXP’s latest ARM Cortex-M3 microcontrollers, lets designers of 32-bit
embedded systems use a small, inexpensive serial flash in place of a
larger, more expensive parallel flash. With SPIFI (“spiffy”), the external
serial flash appears in the microcontroller’s memory map and can be
read like other on-chip memory. This essentially eliminates the traditional
tradeoff associated with choosing the type of external flash to be used in
an embedded system, and gives designers a new way to minimize size
and cost while delivering the required system performance.
NXP has developed a peripheral function, initially available on its new
ARM-based LPC1800 Cortex-M3 microcontrollers, that lets designers of
embedded systems use external serial flash memory in place of larger,
more expensive parallel flash. The patent-pending peripheral, called
the SPI Flash Interface (SPIFI), lets external serial flash memory appear
in the microcontroller’s memory map, so it can be read like an on-chip
memory. This gives designers a new way to meet performance demands
while creating a system that is easier to configure, uses smaller
packages, requires less board space, and is less expensive to build.
The need for external flash
Embedded applications that use a 32-bit microcontroller (MCU) are
increasingly tasked with offering a range of sophisticated features
for managing multimedia, photos, and other data-intensive content.
This is particularly true of systems that present a human interface,
since today’s users have come to expect a graphical display that lets
them interact with window boxes, photos, animations, sound files,
and more. As products become increasingly international, they have to
operate in different languages and may need to support several sets
of alphabets and non-Roman characters. All these requirements place
extra demands on the system’s memory resources.
Most 32-bit microcontrollers are equipped with on-chip flash memory
that can be used to support data-intensive features, but it’s often not
enough to support the entire application. The on-chip flash is typically
limited to 1 Megabyte or less. That may be enough to house the bulk
of the critical application code, but it may fall short when it comes
to storing all the other things the application needs, such as look-up
tables, images, photos, sound files, multiple languages, and so on. For
these items, designers often turn to external flash memory.
External flash memory is significantly cheaper than on-chip flash
and is readily available in sizes in excess of 8 Megabytes. Flash
memory can also add an extra level of flexibility to the system,
since it can be used to patch or upgrade software once the system
is in the field.
The parallel/serial tradeoff
When choosing what kind of external flash to use, parallel or serial,
designers have traditionally had to balance several tradeoffs. Parallel
flash is often faster than serial flash, but requires more pins, more
PCB traces, and more board space.
Figure 1 shows data transfer rates for typical parallel and serial flash
devices. For the parallel flash, the graph assumes a fixed access
time of roughly 90 ns without buffering. With these conditions the
maximum transfer rate for a 16-bit-wide parallel flash is 22 Mbytes/
sec. For the serial flash the maximum clock frequency is 80 MHz
giving a per-bit transfer rate of 80 Mbits/sec. For a quad device
this means a maximum transfer rate of 40 Mbytes/second. This
calculation ignores any control bits but quad SPI devices support
bursting which is used by the SPIFI interface This allows the SPIFI
interface to approach these transfer rates.
Figure 1: Typical transfer rates of serial and parallel flash memories.
Table 1: Parallel verus Serial Flash Performance.
Interface Mode Access Time (nS) Effective Throughput (MB/S)
Parallel
8 Bits 90 11
16 Bits 90 22
Single 12.5* 10
Serial Dual 12.5* 20
Quad 12.5* 40
*Effective access time.
www.digikey.ca/microcontroller
19

As shown in Figure 1, a typical 16-bit parallel fl ash memory delivers a
data transfer rate of 20 Megabytes per second. In systems that use
a 32-bit microcontroller with a 32-bit bus for the external memory
(like those from NXP), the designer can opt to use two 16-bit parallel
devices in combination for a rate of 40 Megabytes per second.
However, the added speed comes at a cost. The confi guration uses
two separate parallel fl ash memories, each housed in a package
with dozens of pins, and that may be more, in terms of package
size, pin count, and PCB space, than the designer can afford.
Serial fl ash, which typically uses the simple four-pin Serial
Peripheral Interface (SPI), can be a good alternative to parallel
fl ash when space, power, and cost are concerns, but it’s much
slower. Figure 1 shows that a typical SPI fl ash operating at 50
MHz transfers data at roughly 5 Megabytes per second (eight
times slower than a confi guration that uses two 16-bit parallel
devices). Another consideration is that the SPI interface on most
microcontrollers is connected to the MCU’s peripheral matrix, where
data has to be received by driver code and put into on-board RAM
before the processor can access it. This can slow things down,
since each read from serial fl ash has to go through an SPI software
layer. Depending on the application, using the standard SPI interface
for external memory may not be fast enough.
The new Quad SPI fl ash format, which uses a modifi ed, six-pin SPI
confi guration, is much faster than traditional SPI formats. As shown
in Figure 1, Quad SPI delivers a transfer rate of 40 Megabytes per
second, which is the same as using two 16-bit parallel devices.
Using Quad SPI is often much less expensive than the parallel
approach, since it uses far fewer pins and a much smaller package.
It would seem that Quad SPI fl ash would be a good replacement for
parallel fl ash in embedded systems, but the reality is that today’s
32-bit microcontrollers aren’t designed to support Quad SPI fl ash
at its maximum speeds. This is because the Quad SPI interface, like
the traditional SPI interface, is connected to the microcontroller’s
peripheral matrix.
Eliminating the tradeoff
NXP has developed a new peripheral function, called the SPI
Flash Interface (SPIFI) that essentially eliminates the parallel/
serial tradeoff. The patent-pending SPIFI (“spiffy”) peripheral lets
low-cost SPI and new Quad SPI fl ash memories appear in the
memory map of an ARM Cortex-M3 microcontroller, so the MCU
can use external SPI fl ash with only a minimal performance penalty
compared to external parallel fl ash memories. The complete
memory space of the external SPI fl ash appears in the MCU’s
memory map, so the microcontroller can access the external
memory directly, without a software API or library.
When used with a Quad SPI fl ash, for example, the SPIFI peripheral
supports a data transfer rate of up to 40 Megabytes per second.
The designer can choose a less expensive SPI fl ash device, with
its compact footprint and simple confi guration, but doesn’t have
to sacrifi ce performance. The designer may also be able to choose
a smaller, less costly microcontroller, because the system won’t
need a bulky interface for external parallel memory. The SPIFI
peripheral enables an embedded system that makes better use
of memory resources yet remains compact and effi cient while
lowering overall cost.
The SPIFI peripheral is a dedicated function that will initially
be available on the NXP LPC1800 series of ARM Cortex-M3
microcontrollers. It will also be available on upcoming product lines,
including the low-cost Cortex-M0 series and the Cortex M4 line of
digital serial controllers (DSCs).
SPIFI supports most serial fl ash devices on the market today
(including those with quad read/write capability) and is designed
for easy confi guration and programming. It uses four or six pins
(depending on the type of serial fl ash used), works with a small
register set, is optimized for effi cient memory transactions, and
uses software commands that reduce CPU overhead and streamline
memory interactions.
How SPIFI works
Figure 2 shows a block diagram of the SPIFI peripheral. The SPIFI
function is connected to the microcontroller’s Application Highspeed
Bus (AHB) matrix, which is used for the processor core and
the on-chip memories. The SPIFI peripheral presents the contents
of the external SPI fl ash in the microcontroller’s memory map. Once
the boot code in the on-chip ROM initializes the SPIFI interface, the
external SPI memory looks just like an on-chip memory to the core
processing unit.
Figure 2: Block diagram of the SPIFI peripheral.
Initialization sequence
All of the drivers required for the SPIFI interface are available in
ROM. For reading, only one call to a routine is made to initialize the
SPIFI peripheral. After the initialization sequence, the entire SPI fl ash
content is accessible as normal memory using byte, half word, and
word accesses by the processor and/or the DMA channels. Erasure
and programming are handled by a simple API call, which accesses
commands in ROM, so using the external SPI memory is as easy as
using on-chip fl ash memory.
Booting from SPIFI
For systems that need the microcontroller to boot from external
serial fl ash, the NXP LPC1800 microcontroller has been equipped
with a mechanism that includes SPIFI as a boot source. There
are two ways to select the boot source. The fi rst uses the
microcontroller pins to determine which interface to boot from, and
the second relies on the user to program a non-volatile location to
choose the interface. Using the non-volatile location saves the pins
from having dual-use functions.
20

Physical interface
Figure 3 shows the physical interface of the SPIFI peripheral. It uses the
standard four pins for traditional SPI devices; when configured with Quad
SPI memory it uses an additional two pins to support the quad capability.
Figure 3: Physical interface of the SPIFI peripheral.
Different serial flash vendors and devices accept or require
different commands and command formats. The SPIFI peripheral provides
sufficient flexibility to be compatible with most common SPI flash and
includes extensions to help insure compatibility with future devices.
Reduced register set
A compact register set gives the SPIFI peripheral a considerable amount
of intelligence while keeping it simple to use. It takes just eight registers
to control the SPIFI function, interface with the external SPI memory,
store and retrieve data, and monitor operation. Since the built-in ROM
API governs setup, programming, and erasure, handling the external SPI
memory in an application is a matter of a few calls. As a result, the SPIFI
peripheral is simple to configure and easy to support in the application.
Software commands
The external memory responds to commands sent by the
microcontroller software and to commands automatically sent by the
SPIFI peripheral when its software reads the serial fl ash region of
the memory map. Commands are divided into fi elds called opcode,
address, intermediate, and data. The address, intermediate, and
data fi elds are optional depending on the opcode. Some memory
devices include a mode in which the opcode can be implied in Read
commands for higher performance. Data fi elds are further divided into
input and output data fi elds depending on the opcode. All commands
to the external SPI memory can be handled by calls to the ROM API.
The SPIFI ROM API driver lets the contents of the external SPI memory
be accessed using simple load commands, so the application code
remains compact and easy to write.
CPU-independent operation
The SPIFI software can read data from the external memory and write it
to RAM or a peripheral without involving the CPU. With microcontrollers
that have an integrated LCD controller, for example, this feature can be
used to enhance performance and save power. Images can be stored in
the external memory and fetched by the LCD controller. Since the LCD
controller reads most of its data from sequential addresses, the SPIFI
peripheral can pre-fetch the addresses so they’re ready when needed,
with essentially no wait states. The entire operation can happen without
getting the CPU involved, and there’s no need to load the images into
on-chip RAM before the LCD controller fetches them. That means the
system can use a microcontroller with less on-chip RAM, or can free
up its existing RAM for other tasks. Also, since the images are fetched
directly by the LCD controller, the LCD display can refresh graphics
faster, so simple operations like opening and closing windows appear
smoother. Also, to save power, the system can use a slower clock speed
without having a noticeable impact on the display’s performance.
Direct execution
From a software point of view, the microcontroller can execute code
directly from the external SPI memory. Direct execution can be helpful
when using in-fi eld upgrades or when replacing functions originally
shipped in on-chip fl ash. Validated upgrade code can be placed in the
external fl ash. If, for example, the system’s function addresses are in
a table stored in on-chip fl ash, the table can be reprogrammed with
the address of the routine now housed in external fl ash. Alternatively,
if the page containing the start of the original routine is stored in
on-chip fl ash, the page can be updated with a branch long jump to
the new routine in external fl ash. In either case, the new code doesn’t
need to be loaded into the on-chip RAM to execute, because the SPIFI
peripheral allows direct execution from the external memory.
Executing code from an external memory is never as fast as using
on-chip memory. The SPIFI peripheral isn’t intended for use with
real-time functions that require peak performance but, for less critical
code sequences, SPIFI can be a very attractive option.
Write-while-execute functions
The SPIFI supports write-while-execute functionality, which means it
can program or erase the external memory simply and quickly, even
when the processor is executing code from on-chip fl ash. Since the
SPIFI peripheral can run on its own, without interaction from the CPU,
the system can perform its functions without interruption while the
serial fl ash is being reprogrammed.
This feature can be used to perform software upgrades in the fi eld,
because the system can write to the external memory without
interrupting critical application code. In a smart meter, for example,
the metering function needs to operate continuously, even during a
software upgrade. With SPIFI, the utility company can confi gure the
system to write any new code to external fl ash, without interrupting
the active metering function, and can then integrate the new code
into the system. Similarly, in a system that has a USB port, new code
can be placed on a portable USB drive and transferred to the external
fl ash without interrupting critical operations.
Conclusions
NXP’s new SPI Flash Interface (SPIFI), a patent-pending feature initially
available on its new ARM-based LPC1800 Cortex-M3 microcontrollers,
lets external serial fl ash memory appear in the microcontroller’s
memory map, so it can be read like on-chip memory. This gives
designers access to a large amount of external fl ash memory while
reducing system costs and minimizing the design footprint.
The SPIFI peripheral creates a way for designers to use a small,
inexpensive serial flash where they might previously have needed to use
a larger, more expensive parallel flash to meet the system’s performance
requirements. Designers can take advantage of the many benefits of
serial flash — low-cost, small size, simple configuration — without
making large sacrifices in performance. SPIFI also lets designers opt for
a microcontroller without a parallel interface, for a smaller, less expensive
design that still delivers the required performance.
The NXP roadmap for SPIFI includes migration to other Cortex-M
families, including the low-cost Cortex-M0 series and the upcoming
Cortex-M4 series of Digital Signal Controllers.
www.digikey.ca/microcontroller
21

uIP TCP/IP Protocol
Stack Demonstration
contributed by Renesas Corporation
The popular open source uIP TCP/IP stack
is widely used in embedded designs. This
demo provides both hands-on experience and
insights into its use.
This article demonstrates the features and capabilities of the RX62N
Renesas Ethernet connectivity target devices with the open source
uIP TCP/IP protocol stack. It assumes some experience with Ethernet,
TCP/IP, and HTML. For more introductory material on these subjects
please see the references at the end of this article.
The uIP TCP/IP stack demonstration project provides an example
of Ethernet connectivity and a sample web server application that
controls LEDs on the Renesas Starter Kit (RSK) boards.
Overview
The procedure below provides step by step instructions for how to
setup the demonstration project and run it.
Setup
Set up a demonstration environment as shown in Figure 1. In this
setup, a router is used as a DHCP server and a PC as a web client.
Several RSK boards can be connected to the multiport router.
Use straight RJ-45 Ethernet cables to make the connections.
Depending on the RSK board used there may be other settings to
be confi gured before running the demonstration project. These may
include instructions for connecting a debugger to the RSK board.
Please refer to the Quick Start Guide (QSG) of the RSK board for
more information.
Figure 2: Test setup.
The demonstration project by default is confi gured to run in little endian
mode. Please make sure RSK board is confi gured for the same endian
mode. Refer to your QSG how to change endian mode of operation.
For a simpler setup, an RSK board can be directly connected to a PC.
In this setup, the router is not used and the demonstration project
is designed to fall back to a static IP address if a DHCP server is not
found in about ten seconds. In this case, the RSK board assumes the
default IP address of 192.168.1.10.
Figure 2 shows a more detailed test setup environment as an
alternative. In this setup all devices are on the same collision domain
and all network activity can be monitored and analyzed on the PC.
If this setup is used, make sure the center connectivity device is a
true hub rather than a switch. The router can be disconnected and
connected back to the network independent of the connections
between the PC and the RSK boards. This allows monitoring of RSK
board behavior with or without a DHCP server on the network.
Figure 1: Demonstration setup.
Figure 3: Router network confi guration.
22

Configure the IP address of the router to 192.168.1.1. This is
usually the default IP address for most home or office routers.
Configure the DHCP start IP address to 192.168.1.100 with two
maximum DHCP users. A snapshot of the router configuration is
shown in Figure 3.
Configure the Ethernet port of the PC with a static IP address of
192.168.1.2. Internet Protocol (TCP/IP) properties of the PC are
shown in Figure 4. Make sure that this Ethernet port is not used to
access a corporate network or a workgroup. If there is not a spare
Ethernet port available, it is recommended to use an USB to an
Ethernet adaptor. Please follow the adaptor manufacturer manual
for installation instructions.
Figure 5: Directory structure of uIP demonstration project.
What to do with the demo
The demonstration project displays “uIP Demo” on the RSK
board LCD on power up. The IP address used is displayed on the
LCD. The RSK board either receives its IP address from a DHCP
server or uses its default setting of 192.168.1.10. For the test
setup in this article, the DHCP server can assign IP addresses of
192.168.1.100 and 192.168.1.101. Make sure the Ethernet cables
are connected and devices are powered up if no IP address is
displayed after ten seconds. Some of the possible LCD settings are
shown in Figure 6.
Figure 6: LCD settings.
Figure 4: PC network configuration.
Sample project directory structure
Figure 5 shows the demonstration project directory structure. The \src
folder contains the source code and has four subfolders: bsp, driver
uip, and user-app. The \src\bsp and \src\driver folders have Renesas
board specific source code and the Ethernet drivers for the RSK
board. The uIP stack is in the \src\uip folder.
The open source uIP TCP\IP stack comes with its own
documentation. It is in the \src\uip\doc folder. The main.c file is
in \src\uip\uip and the example web pages are in src\uip\apps\
webserver\httpd-fs folders.
The demonstration project includes a simple user application that
controls the LEDs on the RSK board. This application is in the \src\
user-application folder.
The router’s status page can also be used to find which IP address
is assigned to the RSK board as shown in Figure 7. Another way
is simply to ping IP addresses and use the IP address with the
reply. Ping messages can be generated by the following DOS
Shell commands:
C:\>ping 192.168.1.10
C:\>ping 192.168.1.100
C:\>ping 192.168.1.101
Figure 7: DHCP client information.
www.digikey.ca/microcontroller
23

Launch a web browser and use the IP address of the RSK board
in the URL fi eld. After a successful connection, the user will see
the welcome page shown in Figure 8. This is also the front page.
Note that the Renesas logo is linked to http://am.renesas.com/. By
activating this link the user can easily access the Renesas Electronics
America internet site. The other external link on this page is http://
www.sics.se/~adam/uip. It is the main page for the uIP TCP/IP
protocol stack.
Figure 10: LED control web application page.
Figure 8: uIP welcome page.
All other pages can be accessed by links provided in the top banner.
The fi le statistics page shows the number of times a specifi c page
is accessed. The network statistics page displays the number of IP,
ICMP, and TCP packet reception and transmission information. The
network connections page shows the current status of established
TCP connections within the uIP stack. These pages are dynamic and
recreated every time they are accessed.
Two custom pages are created and included within the demonstration
project. First is the RSK board specifi c page. An example of this page
is shown in Figure 9. In this case it is an RX62N custom page. The
demonstration project is personalized for different target devices and
target specifi c images are shown on this page. This is to show that
creating custom web pages can be easily achieved and integrated
with the uIP TCP/IP stack. The next section describes step by step
instructions for creating a new web page.
Figure 9: RSK custom page.
The second custom page is the simple user application that controls
the LEDs on the RSK board. One of the LEDs on the RSK board is
used to indicate system timer activity. The other three are used by
the LED control web page as shown in Figure 10. From this web
page, the user can turn the LEDs on and off on the RSK board. The
reset button selects the off setting for all LEDs. Note that the LED
names in Figure 10 are generic and labeled as A, B, and C to allow
portability between different RSK boards. They are usually grouped
together on the target board.
Steps to create a new web page
A new web page can be easily created and added to the
demonstration project by following the following steps. With a little
HTML language knowledge, the user can create custom web page
applications. All the tools and information needed are provided with
the demonstration project and in this article.
1. Write a new web page application. See the led.shtml example in
src\uip\apps\webserver\httpd-fs.
2. Copy it to src\uip\apps\webserver\httpd-fs directory.
3. Run makefsdata.exe from src\uip\apps\webserver directory to
generate the new fttpd-fsdat.c fi le.
4. Rebuild the project.
The makefsdata.exe is a Renesas add-on program created from
makefsdata Perl script. This executable is included into the
demonstration project located in apps\webserver\ directory to make it
easier for the user to generate the httpd-fsdata.c fi le without the need
to fi nd and install a Perl interpreter.
More on uIP TCP/IP stack
uIP TCP/IP stack was originally developed by Adam Dunkels of
the Networked Embedded Systems Group at the Swedish Institute
of Computer Science. Currently, is it part of the open source
community and can be obtained freely from http://www.sics.
se/~adam/uip. uIP TCP/IP stack includes some higher layer example
applications such as web server, web client, Trivial File Transfer
Protocol (TFTP), and DNS hostname server.
uIP TCP/IP stack does not require a real-time operating system.
However, there are versions of it ported to an open source FreeRTOS
operating system and are available on the Internet. It is also
ported to several other Renesas MCU devices. Sample code can be
downloaded from the uIP web site.
24

Usage considerations with uIP TCP/IP stack
One consideration when using a uIP TCP/IP stack is that it
supports only one TCP segment in transit. If uIP TCP/IP stack
is used with a TCP receiver using a delayed acknowledgment
algorithm, throughput performance can be poor. You can modify
TCP acknowledgment behavior of your PC if you experience this
condition with your default PC setup.
More information can be found at http://support.microsoft.com/
kb/328890. This situation is also discussed in the uIP TCP/IP
reference manual.
Another consideration is that the uIP TCP/IP stack supports one
TCP and one UDP application at a given time. In this demonstration
project, the HTTP web server application uses TCP and DHCP client
runs on UDP. An application multiplexer layer based on connection
port number can be added to the uIP TCP/IP stack to support multiple
TCP or UDP applications.
More on DHCP
Dynamic Host Confi guration Protocol (DHCP) is a protocol used by
networked devices to obtain IP addresses and other parameters
such as default gateway, subnet mask, and an IP address of the
Domain Name Server (DNS) from a DHCP server. The protocol is
defi ned by RFC 2131. DHCP eases the management of the above
tasks and ensures that all IP addresses on the network are unique
and unused IP addresses are returned back to the IP address poll for
reassignment for other devices joining the network.
The demonstration project makes use of the dynamic mode of
DHCP. In dynamic mode, a client is provided with an IP address and
time duration in which this IP address is valid. This time duration is
called lease time.
DHCP operation
There are four main messages exchanged between a DHCP client
and a DHCP server during dynamic IP address assignment. They are
shown in Table 1.
Table 1: DHCP messages.
Message From To Details
DHCP
Discovery
DHCP
Offer
DHCP
Request
DHCP
Acknowledge
Client Server Client discovers DHCP servers and asks for
an IP address.
Server Client Server reserves and IP address and offers it
to the client.
Client Server Client tells all DHCP servers that it accepted
the offer.
Server Client Server initiates fi nal phase of the
confi guration. This message includes the
lease time and other option parameters.
How to use DHCP client
There are certain things to consider while using a DHCP client.
The most important consideration is to ensure that each device
on the network has a unique MAC address. DHCP servers assign
IP addresses based on client MAC addresses. For end customer
production devices the MAC address can be purchased from IEEE.
Another consideration is how to know what IP address is assigned
to a device. One way to fi nd this information is to query the DHCP
server through its management interface. Figure 11 shows that the
RSK board with MAC address 00:11:22:33:44:55 is assigned to an
IP address of 192.168.1.101. On the other hand, the RSK board
with MAC address 00:11:22:33:44:56 is given an IP address of
192.168.1.100.
Figure 11: DHCP client status information on the DHCP server.
Debugging a system with a DHCP server can be tricky. Here are some
recommendations. First, use of a network analyzer is a great help.
Wireshark has been used throughout the development of this project.
It is a PC-based network analyzer software. For more information on
Wireshark, see http://www.wireshark.org.
Second, the IP address of the PC Ethernet port used by the network
analyzer must be on the same network and subnet with the DHCP
server and its clients, e.g. the Renesas target board(s). This can be
achieved by assigning a static IP address to the PC Ethernet port that
is outside the IP addresses that can be given out by the DHCP server,
but still making sure that network and subnet requirements are met.
For example, in Figure 3 the DHCP server is confi gured with a start IP
address of 192.168.1.100. Figure 4 shows that the PC Ethernet port is
confi gured to use the192.168.1.2 and it is outside the range of the IP
addresses that can be given to its clients by the server.
References
1. Group Hardware Manuals for the Renesas device on the RSK board.
2. The uIP Embedded TCP/IP Stack, The uIP 1.0 Reference Manual, June 2006, Adam
Dunkels, Swedish Institute of Computer Science
3. IEEE 802.3 Ethernet, IEEE Standards Association, http://standards.ieee.org/
getieee802/802.3.html
4. HTTP – Hypertext Transfer Protocol. World Wide Web Consortium, http://www.
w3.org/Protocols
5. RFC 2131 Dynamic Host Confi guration Protocol, IETF, http://www.ietf.org/rfc/
rfc2131.txt
6. RFC 2132 DHCP Options and BOOTP Vendor Extensions, IETF, http://www.ietf.org/
rfc/rfc2132.txt
Website and Support
Renesas Electronics Website: http://www.renesas.com/
Inquiries: http://www.renesas.com/inquiry
Quick HEW Demonstration
Renesas Electronics America
Renesas’ HEW demonstration product training module
narrates the use of the High-performance Embedded
Workshop (HEW), a key tool
for developing software for
embedded systems.
www.digikey.ca/ptm
www.digikey.ca/microcontroller
25

ColdFire Ethernet for
Diverse Applications
by Eric Gregori, Freescale Semiconductor
Ethernet has migrated from PCs to embedded
systems, a much more constrained
environment. It can bring a lot of capabilities
if you’re careful about its implementation
Embedded Ethernet
Ethernet has become a reality for low-cost embedded systems. The
Ethernet standard (IEEE 802.3) was originally designed for networking
computers over local area networks (LAN), but it has since been
adapted for other purposes. Today it has become so popular that
it is hard to fi nd a PC or laptop without an Ethernet port. Now this
capability is migrating to the embedded world, where the ColdFire ®
family excels. The IEEE 802.3 specifi cation defi nes a mechanical/
electrical connection between devices (physical layer) and a multinode
addressable communications protocol (Media Access Control —
MAC — layer).
Ethernet physical layer
The Ethernet physical layer (PHY) defi nes the physical connections
between nodes. The 802.3 standard defi nes many physical layers,
including everything from coaxial cable to fi ber optics. Through
the years, the most common choice for this purpose has changed
drastically from thick multi-strand cables with large connectors
(called thicknet) to the small RJ-45 8-pin connector we use today.
The common modern copper physical layer is referred to as
100Base-TX (a type of 100Base-T). This copper-based twistedpair
medium contains eight wires grouped in four twisted pairs.
Two twisted pairs are used for communication in each direction.
The cable is referred to as a
category 5 (cat 5 for short). The
RJ45 Jack
category 5 standard defi nes a
cable consisting of four twisted
pairs capable of carrying
frequencies up to 100 MHz.
Pin 8
Most Ethernet embedded devices
have integrated MACs (discussed
in the next section) with external
PHY. ColdFire offers a sevenmember
family of microcontroller
Pin 1
units (MCU) with integrated MAC/
PHY called MCF5223x.
Figure 1: The Modern Ethernet Jack.
Most modern buildings and residences are wired using category
5 cables for their PC networks and broadband, making this an
ideal medium for distributed processing/sensing in a building or
residential environment.
Ethernet MAC layer
The MAC protocol layer defi nes the communication that occurs over
the physical layer. Ethernet is a multi-node protocol, so each node
has a unique address. This address is defi ned in the MAC layer. In
Ethernet communication, MAC addresses are 48 bits long (six bytes,
or octets). The device’s MAC address never changes — usually it is
programmed at the factory. The MAC address must be unique, so
MAC addresses are managed and distributed by the IEEE.
The MAC address, along with various other fields, is contained in
the Ethernet MAC header. As the name implies, the header sits in
front of the Ethernet packet. It contains the MAC address of the
source node, the MAC address of the destination node, and a
type field.
Preamble
Destination
Address
Figure 2: Ethernet MAC header.
Source
Address
Frame
Type
Frame User Data
FCS
Checksum
8 Bytes 6 Bytes 6 Bytes 2 Bytes 46 - 1500 Bytes 4 Bytes
Ethernet can be used directly without any additional layers. It
provides a simple point-to-point communication mechanism, with
some error checking (FCS checksum). Ethernet by itself does not
provide the high degree of communications robustness of which
we have become accustomed. Additional layers are required to add
features such as multiple ports, packet re-transmission, packet
timeouts, and connections. These additional layers are defi ned by
the seven-layer OSI model.
Seven-Layer OSI model
The seven-layer OSI model defi nes the functions of the various layers
in a communication stack. The lowest layers (physical and MAC/data
link layers) are traditionally implemented in hardware. The fi ve layers
above the MAC/DDL are usually implemented in software.
The network or IP layer (for a TCP/IP stack) provides an additional
layer of addressing (IP addresses in the hexadecimal format of xx.xx.
xx.xx) and multiplexing. Multiplexing splits a single communications
channel into multiple time-divided communications channels (ports, in
TCP/IP terminology).
26

The transport layer adds the most critical feature to the
communication stack. TCP (transmission control protocol) is one of
the transport layers in TCP/IP. This layer is responsible for creating a
virtual connection between two logical points (not nodes). The logical
points are referred to as sockets. The socket’s API is actually defined
by the session layer.
Last, at the highest level, is the application layer. This application
defines the common protocols used on the Internet: HTTP, SMTP, and
TFTP. This layer can also be used for custom protocols.
Movement up and down the stack is an area of inherent inefficiency
in a communication stack. To improve efficiency, higher-performance
stacks use pointers instead of copying the data multiple times (this is
sometimes referred to as zero copy). Pointer arithmetic is significantly
more efficient with a 32-bit core using true 32-bit registers. This is a
big advantage for the ColdFire 32-bit architecture.
In addition, extracting data from individual fields in a header can
become a single-instruction operation by using advanced addressing
modes with offset capability.
Figure 3: Seven-layer OSI model.
ColdFire family of microcontrollers
The ColdFire family of microcontrollers is based on the 32-bit ColdFire
cores. The ColdFire core is available in four varieties, each a superset
of the core below it. The cores are completely scalable, with the
differences consisting of additional instructions or add-on modules
(for instance, MMU) and longer pipelines to increase frequency
and performance for demanding applications. The current V1 core
contains the base register and instruction set. The V2 core adds
additional instructions and addressing modes to the V1 core, along
with an optional eMAC (Enhanced Multiply/Accumulate unit).
Figure 4: ColdFire cores: scalable instruction sets, features and performance.
Advantage of a 32-bit architecture
The true 32-bit architecture of ColdFire microcontrollers lends
itself well to efficient communication stack data movement. In a
communication stack such as TCP/IP, the packet comes in at the
bottom of the stack and propagates up. Data to be sent starts at the
top of the stack as a buffer, and then works its way to the bottom of
the stack to be sent out as a packet.
Figure 5: Seven-layer OSI model with communication stack overlaid on top.
ColdFire Fast Ethernet Controller (FEC)
The FEC module is the ColdFire interface to the Ethernet world. The
FEC module is consistent from the highest-performance V4-corebased
part all the way down to the V1 core. This consistency means
that drivers written for one Ethernet-enabled ColdFire processor will
work on any Ethernet-enabled ColdFire processor (memory allocation
would be the biggest difference).
The FEC module is a high-performance Ethernet engine with a very
rich heritage. The FEC module started out in the MPC860T. This highperformance,
Power Architecture-based processor quickly became
a powerhouse in the Ethernet world, going into high-performance
routers and telecommunication equipment. The MPC860T was so
popular in the Ethernet world that if you make a call today, chances
are that somewhere along the way the voice data of your call will
pass through an MPC860T.
The MPC860T came out in the mid-1990s. The FEC module has been
tested and improved upon for over ten years in some of the highest
performance Ethernet environments. The FEC module from the
MPC860T is now in the ColdFire line of processors.
ColdFire FEC features
• Ethernet MAC is designed to support 10 Mbps and 100 Mbps
Ethernet/IEEE 802.3 networks
• IEEE 802.3 full-duplex flow control
• Support for full-duplex operation (200 Mbps throughput)
www.digikey.ca/microcontroller
27

•
•
•
•
ColdFire TCP/IP stack
ColdFire TCP/UDP/IP stack features
•
•
•
•
•
•
Figure 6:
•
•
•
•
•
•
•
•
Figure 7:
28

DHCP client
The Dynamic Host Configuration Protocol (DHCP) is used to acquire
network parameters at runtime. The DHCP protocol is defined in RFC
2131 and RFC 2132. The stack runs a DHCP client which searches for
a DHCP server (this is referred to as discovery).
Packets are transferred using the UDP layer and BOOTP ports (67
and 68). Because the IP stack does not have an IP address yet,
discovery is done using strictly broadcast addresses. Included in the
discovery packet is a unique transaction ID (xid). A listening DHCP
server sends an offer message containing the xid sent by the client
and the suggested network parameters, again using broadcast
addressing. Encoded in the offer is a unique server ID. The client will
use this server ID when sending a request packet back to the server,
indicating that it accepts the network parameters that were offered.
Finally the server ACK’s the client using its new IP address.
DNS client
The DNS client is used to communicate with the DNS (Domain Name
Server). The purpose of the DNS system is to translate domain names
into IP addresses. The DNS protocol is described in RFC 1035. DNS
can use UDP or TCP, with port 53. The DNS protocol is stateless — all
the information is contained in a single message. This message is
fully documented in RFC 1035.
Available examples and application notes
All application notes mentioned in this article are available at www.
freescale.com.
HTTP web server and flash file system
The HTTP web server and flash file system are described in detail in
application note AN3455, ColdFire Lite HTTP Server.
The features are:
• HTTP 1.0 compliant server with connection persistence and
multiple sessions
• Multiple HTTP connections supported
• Flash file system which supports both ColdFire internal flash and
external SPI flash
• Web pages can be updated in flash over Ethernet or built in at
compile time
• HTTP GET method supported, with a simple mechanism for
adding other methods
• Dynamic HTML (Hypertext Markup Language) support with
replace and conditional tokens
• Serial interface support for Dynamic HTML variables
• Run-time and compile-time flash file systems
• Long filename support with subdirectories
• “DIR” command supported on serial interface
• PC utilities for compressing compile-time and run-time
downloadable images of multi-page web pages
• PC utility for downloading run-time downloadable web page
image through port 80 (to get through firewalls)
• 32-byte ASCII key for web page download security
UDP/TCP clients and servers — Example source code
The ColdFire Lite stack project includes almost a dozen built-in
usage examples. These examples are designed to highlight
various features in the stack and demonstrate how to use them.
The TCP/IP stack and RTOS, along with all the sample applications
listed below, are discussed in AN3470, ColdFire TCP/UDP/IP Stack
and RTOS.
Code examples include:
• ColdFire_Lite
Barebones TCP/IP stack
• ColdFire_Lite_RTOS
How to use the RTOS application
• ColdFire_Lite_TFTP
TFTP server application
• ColdFire_Lite_UDP_client
UDP client application for UDP performance testing
• ColdFire_Lite_UDP_server
UDP server application for UDP performance testing
• ColdFire_Lite_TCP_client
TCP client application for TCP performance testing
• ColdFire_Lite_TCP_server
TCP server application for TCP performance testing
• ColdFire_Lite_TCP_serial_client
TCP to serial/serial to TCP client
• ColdFire_Lite_TCP_serial_server
TCP to serial/serial to TCP server
• ColdFire_Lite_TCP_with_Web_Server
Web (HTTP) server with dynamic HTML
ColdFire_Lite_TCP_alarm
The alarm demo application includes both PC-side and ColdFireside
firmware. This code is an example of a remote sensor
application, where a remote sensor periodically sends data over TCP
to a host server.
Figure 8: ColdFire TCP alarm.
www.digikey.ca/microcontroller
29

HTTP client firmware
The HTTP client provides the ability to read web pages and XML data
from the Internet using a ColdFire processor. The HTTP client uses the
DHCP client to automatically acquire an IP address and other TCP/
IP information, including the IP address of any DNS server. Then the
HTTP client uses the DNS client to translate any user-provided URLs
into IP addresses.
The HTTP client uses the GET method to request a page from the
server. Along with the GET request is the HTTP header. The HTTP
header is hard-coded in the HTTP client via constant strings declared
in the fi le emg_http_client.c.
Wget command – An example of using the HTTP client
The Wget command is a command often found in Linux distributions that
transfer files using the HTTP protocol. The Wget command is a consolebased
HTTP client. Using the menuing system provided by the ColdFire
TCP/IP stack (explained in application note AN3470) and the HTTP client,
Wget functionality can be added to the ColdFire TCP/IP stack.
RSS/XML character data filter
To extract the character data (the information you actually want to
read) from the RSS stream, all the meta-text must be fi ltered out. Any
valid HTML must be translated and processed. For instance, the HTML
tag that causes a line break is . This would appear as <br>
in the RSS stream. The fi lter must correctly translate <br> into a
carriage return and line feed.
Other HTML tags that are routinely embedded in character data
include paragraph tags and image tags . In the stream
these tags appear as <p> and <img> respectively. The
paragraph tab can be translated to a carriage return and line feed,
but the image tag must be ignored unless the embedded system can
process images.
The fi lter takes in an XML or RSS data stream and a list of tags. It
outputs only the character data from the selected tags. The tag list is
an array of pointers to those tag strings that need to be fi ltered.
Normally the fi lter returns 0. When the fi lter processes the “>” in a tag
in the list, it returns to the fi lter array the index + 1 for the tag that it
found. Example: after detecting a tag in an RSS or XML stream
the fi lter will return 1. After detecting a tag in a stream
the fi lter will return 2. Normally the fi lter returns 0.
Example embedded appliance — RSS/XML feed reader
The RSS/XML feed reader is an embedded appliance that allows
users to display and even hear real-time content from the World Wide
Web. The purpose of the embedded appliance is to provide instant
real-time information without booting a PC. There are many types
of real-time data available on the web; weather data (current and
forecast), online DVD queue data, online auction data, sports score
data, real-time news data, real-time stock data, medical and health
data, and much more. All this data is available on the web as either
an XML feed or an RSS feed. This appliance connects to the web, gets
the desired feed, and parses the text information or character data
from the feed. That data is displayed on the LCD, sent to the serial
port, and spoken through the speech processor.
For complete details on the RSS feed reader, please see AN3518,
Advanced ColdFire TCP/IP Clients.
Figure 9: The RSS/XML feed reader.
M52233DEMO board from Freescale Semiconductor
The M52233DEMO board is a reference board used to evaluate
Freescale’s ColdFire MC52233 processor. The inexpensive board
includes a serial port, USB BDM debug port, and Ethernet port. The
board along with the free CodeWarrior tools (up to 128K of fl ash)
are all you need to get up and running on your Ethernet projects.
Freescale provides a free public source TCP/IP stack on their
website. This TCP/IP stack is what the application in this article
runs on. The ColdFire TCP/IP stack is documented thoroughly in
application note AN3470.
The demo board includes a 40-pin header fi ving the use access to
most of the Coldfi re signals, a 3-axis accelerometer, a potentiometer,
and two user buttons.
LCD
The parallel LCD is a 4 × 20 character display that uses the standard
Hitachi instruction set. The LCD is used in its 4-bit mode, requiring
only six connections to the micro, the 4-bit data bus, a clock signal
(E), and a register select line (RS). The fi rmware also includes a library
to drive the LCD.
30

Voice synthesizer
The RC Systems V-Stamp voice synthesizer is an easy-to-use, textto-speech
processor. The V-Stamp is a fully self-contained module,
requiring only power, a speaker, a resistor, two capacitors, and a serial
connection to an embedded system. The V-Stamp communicates with
the embedded system using a UART. The module automatically sets
its baud rate to that of the embedded system. From both a hardware
and firmware point of view, there is very little work required to add
the V-Stamp module to the RSS feed reader.
Firmware
Figure 11: HTTP communication protocol.
Figure 10: Firmware block diagram.
HTTP
HTTP is the communication protocol of the World Wide Web. HTTP is
used to transfer web pages (hypertext documents) across the Internet.
An HTTP connection has two parts, the HTTP client (web browser) and
the HTTP server. The HTTP client is used to receive and view the web
pages. The HTTP server is used to store, organize, and transfer the
web pages.
HTTP is defined by RFC 1945 and RFC 2616. RFC 1945 defines
HTTP 1.0, and RFC 2616 defines the latest version, HTTP 1.1.
HTTP is a request-response protocol. The client requests a web
page from the server and the server responds with the web page
contents. HTTP can be used to send any type of data, including
binary data. The client requests a file using the GET method (HTTP
is an ASCII protocol). The server responds with an HTTP header
followed by the file contents. Within the request, the version number
of the HTTP is also embedded in ASCII. This tells the server the
limitations of the client.
Really Simple Syndication (RSS)
RSS feeds are available everywhere on the Internet. The idea behind
the RSS feed is to convey dynamic textual information in a simple
standard format.
RSS originated in 1999 with the idea of providing content in a
simple easy-to-understand format. Instead of describing a complete
document in the way that HTML does, RSS feeds use XML to describe
data. An RSS feed is simply an XML document containing data. The
methods used to convey the data within the XML document are
described in the RSS 2.0 specification. All RSS files must conform
to the XML 1.0 specification. RSS feeds generally use HTTP as the
transport mechanism.
Extensible Markup Language (XML)
The XML 1.0 specification can be found at www.w3.org/TR/REC-xml/.
XML is a language used to describe and parse information. It is very
similar to structures in C.
Data is organized into elements, with each element assigned to a
tag. The data in the element is surrounded by a start tag and an
end tag. The name in the start and end tags defines the element’s
type. The end tag name must be the same as the start tag name,
except the end tag is identified by the addition of a “/” before the
tag name.
Tags
Here is an example of an XML tag:
Advanced ColdFire TCP/IP Clients
TITLE is the type, is the start tag, and is the end
tag. The data is between the tags. Just like a C data structure, the
data is associated with the type. The data between the start and end
tags is referred to as the element’s content.
www.digikey.ca/microcontroller
31

Elements can contain other elements, which provide a method of
grouping data of different types under a single name. Just like a C
structure, the particular piece of data is referenced by specifying a
path to the data. a single name. Just like a C structure, the particular
piece of data is referenced by specifying a path to the data.
ColdFire HTTP Server
ColdFire TCP/IP Stack
ColdFire USB Stack
Special characters and escape sequences
The “&”, “” characters are special XML characters.
They are used as indicated above, to defi ne XML tags and escape
sequences. Escape sequences are a method of specifying a character
using a code, as opposed to using a single symbol. Escape sequences
start with an ampersand (&) and end with a semicolon(;).
Because XML ordinarily uses these characters for special functions,
here is how to have them appear in XML data:
• “” is indicated using the escape sequence >
• “&” is indicated using the escape sequence &
CDATA sections: the exception to the rule
All rules have exceptions, and in XML it’s the CDATA section. Any text
specified in a CDATA section is ignored by the XML parser, allowing the
use of special characters without the need for escape sequences. A
CDATA section starts with a “” string. Anything between the brackets is ignored by the XML parser.
•
• < ]]>
• Because the text between the brackets is ignored by the XML
parser, both the tag and the escape sequence are not parsed, but
instead are interpreted as text or character data.
Finding text or character data in an XML document
From the XML 1.0 specifi cation: “all text that is not markup
constitutes the character data of the document.” That would include
all the text between the brackets in a CDATA section, and any text not
between “” brackets in the main body. Escape sequences in
the main body represent a single piece of character data.
To fi lter out the character data from an XML document, simply remove
all tags as well as “” brackets. Then translate the escape
sequences into actual characters.
Sample XML file
In the sample XML document below, notice how data is encapsulated
by tags, and how the tag names describe the data. It even looks like
a C structure. To fi nd the desired data in an XML document, simply
look for the start and end tags with the name of the type of data you
are looking for. The actual data associated with the desired type is
between the tags.
http://www.weather.gov/data/current_obs/KUGN.xml
-
NOAA’s National Weather Service
http://weather.gov/
-
http://weather.gov/images/xml_logo.gif
NOAA’s National Weather Service
http://weather.gov
15 minutes after the hour
60
Chicago / Waukegan, Waukegan Regional Airport, IL
KUGN
42.420
-87.870
Last Updated on Jul 28, 10:52 am CDT
Sat, 28 Jul 2007 10:52:00 -0500 CDT
Overcast
73 F (23 C)
73
23
81
From the Northeast at 13 Gusting to 21 MPH
Northeast
30
12.65
21
29.98” (1014.1 mb)
1014.1
29.98
67 F (19 C)
67
19
73 F (23 C)
73
23
NA
NA
NA
10.00
http://weather.gov/weather/images/fcicons/
ovc.jpg
http://www.weather.gov/data/obhistory/KUGN.html
http://www.nws.noaa.gov/data/METAR/KUGN.1.txt
http://weather.gov/disclaimer.html
http://weather.gov/disclaimer.html
http://weather.gov/notice.html
32

Drawback of XML documents
The problem with XML documents is the flexibility of the tag names.
The creator of the XML document can use any name to describe the
data. To avoid confusion, a standard is required to standardize the tag
names, and the way that data is associated with a specific type. That
standard exists and is called the RSS specification.
The RSS specification
RSS is a dialect of XML — it embeds HTML constructs into the XML
architecture. RSS also defines a set group of elements and a general
template using those elements. There are many elements defined
in the specification, but here we will concentrate on the elements of
interest for the RSS appliance.
Typical RSS file
The name of the channel
URL to the HTML website corresponding to this
channel
Text describing the channel
< title>Item1 Title
URL of item 1
Text for item 1
Item2 Title
URL of item 2
Text for item 2
The organization of the RSS file can be compared to a newspaper.
The channel is the name of the paper, the items are the articles in the
paper, the titles are the titles of the articles, and the descriptions are
the text of the articles.
Sample RSS file
The sample RSS file given here contains the same data as the sample
XML file above. Notice the structure and tag names. The RSS standard
defines the title and description tag names, and those tags contain
the data we want. All RSS 2.0 compliant feeds will contain title and
description tags.
http://www.weather.gov/data/current_obs/KUGN.rss
-
-
Weather at Chicago / Waukegan, Waukegan Regional Airport,
IL - via NOAA’s National Weather Service
http://www.weather.gov/data/current_obs/
Sat, 28 Jul 2007 16:32:11 UT
60
Weather conditions from NOAA’s National Weather
Service.
en-us
robert.bunge@noaa.gov
w-nws.webmaster@noaa.gov
-
http://www.weather.gov/images/xml_logo.gif
NOAA - National Weather Service
http://www.weather.gov/data/current_obs/
-
Overcast and 73 degrees F at Chicago / Waukegan, Waukegan
Regional Airport,IL
http://weather.noaa.gov/weather/current/KUGN.html
-
-
]]>
Winds are Northeast at 13 Gusting to 21 MPH. The pressure is 29.98”
(1014.1 mb) and the humidity is 81%.
The heat index is 73. Last Updated on Jul 28, 10:52 am CDT.
Sat, 28 Jul 2007 10:52:00 -0500 CDT
RSS/XML character data filter
To extract the character data (the information you actually want
to read) from the RSS stream, all the meta-text must be filtered
out. See the previous section, “RSS/XML Character Data Filter,” for
more information.
RSS/XML character data filter state machine
The character data filter is implemented as a finite state machine.
The state machine uses only two global variables, a state variable
and a FILO. The purpose of the FILO is to store characters. Each byte
entered into the filter is shifted left into the FILO. Therefore the most
recent character is at location filo_buff[FILO_BUFF_SIZE–1]. The FILO
buffer size must be larger than the largest tag name expected. The
FILO buffer size is set with the FILO_BUFF_SIZE macro.
#define FILO_BUFF_SIZE 32
States:
STATE_ZERO
STATE_TAGSEARCH
STATE_INTAG
STATE_PRINT
STATE_SKIP
STATE_SKIP_NON_ASCII
STATE_SKIP_SPACE
STATE_CDATA
STATE_CDATA_PRINT
STATE_CDATA_SKIP_AMP
STATE_SKIP_INTAG
STATE_IN_AMPERSAND
Global Variables:
unsigned char filo_buff[FILO_BUFF_SIZE];
unsigned char state;
unsigned char EMG_rss_text_filter(unsigned char data, unsigned char
**tag_filter)
www.digikey.ca/microcontroller
33

Figure 14: Character data fi lter usage.
Using the RSS/XML feed reader
Using the RSS/XML feed reader fi rmware is easy:
Figure 12: RSS/XML datafl ow diagram.
The fi lter takes in an XML or RSS data stream and a list of tags.
It outputs only the character data from the selected tags. The
tag list is an array of pointers to those tag strings that need to
be fi ltered.
Normally the fi lter returns 0. When the fi lter processes the “>” in a
tag in the list, it returns into the fi lter array the index+1 for the tag
that it found. Example: after detecting a tag in an RSS or
XML stream the fi lter will return 1. After detecting a
tag in a stream the fi lter will return 2. The fi lter returns 0 if a tag is
not found.
Const unsigned char *tag_filter[] =
{
{(const unsigned char *)”title”},
{(const unsigned char *)”description”},
{(const unsigned char *)””}
};
Figure 13: Sample tag_fi lter pointer array.
1. Set the variable url to the URL or to the desired RSS or XML server.
static const unsigned char url[] =
“http://www.weather.gov/data/current_
obs/KUGN.rss”;
2. Set the tag_fi lter[] to the type of data you want to display.
For RSS feeds, and would be a fi rst choice.
For XML feeds, this could be any tag name depending on the
information.
const unsigned char *tag_filter[] =
{
{(const unsigned char *)”title”},
{(const unsigned char *)”description”},
{(const unsigned char *)””}
};
3. Set the character buffer size large enough to collect your
fi ltered data.
#define RSS_CHARACTER_BUFF_SIZE2048
4. Compile the project and fl ash it to the board.
After the TCP/IP stack comes up, these actions occur:
1. The DHCP client automatically acquires an IP address and DNS IP
address.
2. It displays and speaks a title screen.
3. It connects to the server specifi ed in the URL.
4. The status of the connection is displayed and spoken.
5. The fi le is downloaded from the server using the HTTP client.
6. After the connection closes, the fi le is displayed and spoken.
7. The RSS/XML feed reader sleeps, waiting for either SW1 or SW2
to be pushed. When that happens, a connection is initiated to
the server specifi ed in the URL that starts the download/display/
speak process all over again.
34

XML Streams
For XML streams, the EMG_rss_text_fi lter() return value is used
to determine which tag is applied to the data that comes after the
tag. This allows another const array containing more descriptive
names to be used to describe the data from the tag. Simply use
the EMG_rss_text_fi lter() return value–1 to index into a descriptive
name array, then send the indexed string into the character buffer
before leaving the RSS callback function. The XML fi lter will then
place the data from the tag in the character fi lter directly after the
descriptive name.
Conclusion
Adding Ethernet to embedded products provides a level of
connectivity never before available in the embedded space.
Embedded devices can be networked together using the same
cables and hardware used by the industry to connect PCs together.
The embedded device can become part of the PC network.
Ethernet and TCP/IP enable the embedded device to connect to
the ultimate network, the Internet. After the embedded device
is connected to the Internet it is available to the world, and
controllable or viewable from anywhere. The possibilities are
endless, from remote monitoring and control to distributed control,
and even real-time, world-wide data presentation through the
RSS feed reader.
i.MX35 Processor
Freescale Semiconductor
The i.MX35 processor is the latest series from Freescale.
This chip includes an increased level of integration and
support, while maintaining low-power requirements.
Digi-Key’s product
training module
featuring the
i.MX35 processor
aids purchasers
in understanding
the many benefi ts
of integrating this
device into designs
and projects. Applications for this processor include
portable navigation devices, printers, and eBooks to
name a few.
www.digikey.ca/ptm
Kinetis Microcontrollers
Design Potential. Realized.
• The fi rst broad-market mixed signal MCU family based on
the ARM ® Cortex-M4 core
• One of the most comprehensive ARM enablement portfolios
in the industry
• Over 200 pin-, peripheral- and software-compatible MCUs
with exceptional performance, memory and feature scalability
• Innovative 90 nm thin-fi lm-storage fl ash technology
with FlexMemory delivering high-endurance EEPROM
• Ultra-low-power performance and rich mixedsignal
integration
Kinetis Family Positioning
K10 Family: 32 KB to 1 MB, ultra-low power, advanced mixed signal,
touch sensing, CAN
K20 Family: 32 KB to 1 MB, ultra-low power, advanced mixed signal,
touch sensing, CAN, USB OTG
K30 Family: 32 KB to 512 KB, ultra-low power, advanced mixed signal,
touch sensing, CAN, segment LCD
K40 Family: 32 KB to 512 KB, ultra-low power, advanced mixed signal,
touch sensing, CAN, USB OTG, segment LCD
K60 Family: 256 KB to 1 MB, ultra-low power
www.digikey.ca/freescale-mcu
www.digikey.ca/microcontroller
35

Your MCU is Just Starting
to be Connected
by Tom Starnes, Industry Analyst, Objective Analysis
If “the network is the computer,” then
connectivity is what empowers—or limits—
your MCU application. This is an area that
continues to evolve rapidly.
Microcontrollers (MCUs) have utilized serial transmissions
practically from the onset, but the purpose and elegance of those
channels have evolved greatly over the last 30 years. The word
“connectivity” has taken on new prominence in most applications
in the new century, driving on-chip support for networking and
even wireless communications from the microcontroller. The
advantages of more advanced connectivity and the ease with
which it can be obtained make it well worthwhile to take a renewed
look at how your end-application can make use of broader
communications capabilities.
Begin with the basics
In the 1970s, as MCUs were fi rst emerging, UARTs (universal
asynchronous receiver-transmitters) fi rst brought a pre-confi gured
serial port to microprocessors and microcontrollers. UARTs and
synchronous-capable USARTs were largely used to perform simple
data communications. UARTs and USARTs were added to the MCU
as the transistor budget allowed, and serial communication became
more attractive.
Soon, the need was determined to more tightly connect the central
brain of the MCU with nearby peripherals that remained separate
from the MCU due to their complexity, uniqueness, or electrical
characteristics that made them less practical to integrate on-chip. A
serial connection may have been slower than transmitting over the
parallel bus, but it conserved valuable pins (even in the 8 bit era)
and made it easier to use peripherals from a different, perhaps more
specialized, vendor than the controller manufacturer. This gave rise
to the various standard serial modules found in great numbers on
today’s MCUs:
• Philips’ I 2 C (Inter-Integrated Circuit)
• Motorola’s faster SPI (Serial Peripheral Interface)
• Philips’ fairlyspecifi c I 2 S (Inter-IC Sound)
• Motorola’s SCI (Serial Communications Interface)
Tradeoffs between speed and complexity may take a back seat to
how many devices are on the channel and exactly which interface
the desired peripheral supports. Generally, such serial interfaces are
intended to connect only with other chips on the circuit board, often in
a master-slave relationship. The SCI, often bundled with these serial
ports, is really just a UART and more likely to provide a little longer
reach. Buses like the I 2 C, SPI, and I 2 S are used to connect with nearby
peripherals such as E2PROMs, real-time clocks, memory cards
interfaces, analog-to-digital converters, digital-to-analog converters,
sensors, camera interfaces, and audio codecs. For most of today’s
MCUs, the existence of SCI, SPI, I 2 C, and similar serial ports are more
of a requirement than a differentiating feature.
Automotive drivers
More sophisticated, frame-based serial communications were
fi rst driven onto MCUs with the advent of CAN (Controller-Area
Network). In the 1980s, Robert Bosch GmbH initiated CAN as a
means for microcontrollers to communicate among themselves in
an automobile, a platform where numerous MCUs were used. This
harsh environment required robustness and a strict protocol. Since
the number of potential network end-points was growing quickly,
the need for a specifi c host or master could be limiting. Yet, reliable
communications between disparate and optional controllers in the
vehicle have greatly improved the operating conditions of the vehicle
and have become a necessity for engine control, safety systems, and
diagnostics. With the automotive industry’s support, the CAN network
and CAN peripheral chips took hold.
In the 1990s, CAN peripherals started appearing on-chip in MCUs
destined for automotive applications, about the time the protocol
started evolving. While other networks have also found some places
in the automobile for specifi c applications, CAN still forms the
backbone of most automotive systems. CAN has also found a home
in industrial applications, with their similarly harsh environments and
noisy conditions and in medical instruments where special integrity
requirements are highly valued.
CAN and MCUs were mad for each other. CAN was developed to let
the systems that MCUs comprised communicate with each others.
Since automotive applications are the inspiration for much of the
design of MCUs, CAN modules are a natural circuit to include in MCUs.
36

Computer connectivity
The tremendous growth of the personal computer (PC), accompanied
by Ethernet (see Figure 1) and the Internet, took place somewhat
outside of the microcontroller industry but is having a heavy influence
on it. The PC made de facto standards of TCP/IP, Ethernet, and
Wi-Fi for long distance data communications with servers, email,
the Internet, databases, and other systems. The need for system
inter-activity drove TCP/IP and Ethernet to be the backbone of data
communications, even supplanting the circuit-switched telephone
network to a large degree, and attracting creative minds to make the
protocol work for nearly every application. The utility of TCP/IP made it
quite popular and the protocol stack became a well-honed standard,
economies of scale dramatically drive down the prices of chips and
software down.
The ubiquity of the protocol and some confluence of Metcalfe’s
Law and Moore’s Law, has opened untold opportunities for
electronic system connectivity. Whether it is refrigerators reporting
food shortages to the grocery store or air conditioning systems
taking a break during peak electricity rate periods, networks,
Ethernet, and TCP/IP are being employed in every conceivable
application for machines to communicate with hosts, servers,
directly to other machines, hubs, remote monitors, and to control
centers manned or unmanned.
Microcontroller vendors have responded by providing Ethernet
controllers on their MCUs (although it took some time for the transistor
budget to free up) and for OEMs to give serious consideration to
Ethernet as a connectivity option on traditional MCU-based systems.
Today the benefits are difficult to ignore. From software updates
to remote monitoring to long-term customer services,
when TCP/IP brings the Internet to the edge of
the board for a small price adder, the
option can be very attractive. If
nothing else, access to the
Internet gives essentially
unlimited range to
the control or
management of
the system.
Figure 1: Ethernet cable.
The ubiquitous USB
The PC is also responsible for the great popularity of the USB
(Universal Serial Bus). There used to be discussions of whether USB
(Figure 2) would supplant other local connectivity
ports on the PC, especially the spaceconstrained
laptop, but it did not take very
long for the discussion to turn to “how
many USB ports can we put on
this” Once USB ports and
drivers became integral to
the PC and a few devices
converted over to the
convenient standard,
USB caught on
like wildfire.
Figure 2: USB connector.
Soon, MCU-controlled devices such as the mouse, keyboard, and
similar input devices, switched over to USB connections. Printers,
modems, and other output devices made the change, abandoning
interfaces with origins in the mainframe era. USB evolved to be faster
(Table 1), making it more practical for hard drive interfaces. New form
factors put flash memory on a thumb-sized portable storage device
that easily plugs into many hosts. USB also became an intermediary
and a “dongle” port where other connectivity devices can plug in,
such as Ethernet, Bluetooth, Wi-Fi, and memory card adapters. At
some point, the convenience of the USB port drew MCU vendors
to put their own MCU evaluation boards and debugging ports on
USB-enabled cards.
Table 1: USB versions.
Version Mbps Grade Comment
USB 1.1 1.5 low-speed mice, keyboards
12 full-speed printers
USB 2.0 480 high-speed hard drives
USB 3.0 5000 super-speed new connector, emerging
USB gained additional popularity as its facility for supplying current
to attached devices started to be exploited. It is possible to draw
100 mA at 5 V (up to 500 mA also accommodated), which is more
than enough to power numerous applications without an additional
power source. With the slightest effort, this current can recharge
the battery of a truly portable handheld device. This allows USB to
perform the dual functions of transmitting data as well as supplying
power – all with a single cord and connector.
MCUs are convenient for operating the USB port for transmitting
data and even for managing a recharging circuit. While the latter
is usually left to the system engineer to design, integrating a USB
controller onto the MCU eliminates an additional chip in the system.
The cost is minimal and most of the software is readily available
and prepackaged.
The distinction between host (master), device (slave), and the
swings-both-ways, On-The-Go (OTG) varieties of USB controllers
must be considered when picking an MCU with USB capability, but
more USB modules and stacks can support any role the controller
must play. It’s another dimension of USB that should be narrowed
down (along with speed grade and, eventually, physical connector
style) when evaluating how the technology can expand an
application’s utility.
Less wire
The ultimate in connectivity and
communication would require no physical
contact. Wireless communications,
be it using Bluetooth, ZigBee, Wi-Fi,
near-field communications (NFC), or
similar technologies, are robust enough to
link up between devices or with a network or
the Internet without much trouble. Breaking the
tether avoids certain hassles but also removes
the benefit of getting electricity to the device, so
there are some tradeoffs in going wireless. Also,
the nature of radio circuits limits just how much
www.digikey.ca/microcontroller
37

these can be integrated onto the mostly-digital MCUs, but the vendors
are still working to get closer to more compact and well-blended
with wireless systems. Range, EMI, and security are other issues to
consider in selecting the radio air interface.
In industrial applications, for instance, having wireless
controllers, especially in a mesh network, means that to
move some equipment or add a sensor on a factory floor may
mean just placing the equipment where it is needed. With a
wireless network, no new cables need to be laid out or routers
reconfigured. The network self-discovers the new equipment (and
probably doesn’t care if it was only moved). If a unit fails, it simply
falls off the grid and the rest of the network continues without it,
though hopefully a flag is raised.
Consumer explosion
As mentioned, many forms of communications have become stand-outs
and true standards in recent years. The high volume of digital consumer
electronics has become a significant factor in establishing such
standards. While CAN is more under-the-hood, USB and Ethernet are far
more visible. The phenomenal boom – and churn – in digital still cameras,
MP3 players and cellular phones—in tandem with the desire to transfer
large amounts of data between PCs, TVs, printers, and the Internet—has
caused an explosion in the need for universal connectivity.
This explosion of consumer electronics needing connectivity opened
huge opportunities for chip vendors to supply vast quantities of
chips and programmers to write the protocol stacks to support the
standards. Lower costs and off-the-shelf software made it even easier
to connect consumer devices in more ways.
Microcontrollers will hook you up
Microcontroller vendors have been taking care of your
connectivity and communications needs. More and more serial
channels, communications methods, and networking peripherals have
been brought into the MCU as the market has called for it. Along with
the hardware implementation, the chip vendors have been assembling
the software that makes it work. Third-party software vendors step
up to the plate to offer improved, more universal, customizable,
and specialized communications software and protocol stacks. The
result is a relatively easy and cost-effective means of adding greater
connectivity to MCU-based equipment.
The more advanced communications protocols require more
horsepower from the processor than a little bit-banging does or a
UART. Some can take advantage of additional RAM for buffering
and forming packets. Some can use Direct Memory Access (DMA)
techniques to block-transfer strings of data to other parts of the
system. The more advanced MCUs typically have more advanced
communications capabilities. However, some advanced connectivity
is available on 16-bit and 8-bit MCUs, as well. Most vendors have
evolved with their markets, so your favorite architecture probably
has a selection of MCUs with a peripheral on board to implement the
technology of your choice.
In my opinion, the best bet for exotic network and communications
will be with 32-bit MCUs. They have the performance, the fl exibility,
and the memory space to handle the code, and they are more likely
to be in markets where overall performance is important, and where
connectivity is a must rather than a luxury. This also means the 32-bit
MCUs will keep up with heavy communications traffi c. However, 32-bit
MCUs are not as expensive as one might believe. The price difference
from a comparably-equipped 8-bit MCU is hardly noticeable.
The established architectures have a good range of MCUs with
CAN peripherals. Namely Renesas, Freescale, Texas Instruments,
STMicroelectronics, and Microchip all have suitable solutions for
this market.
When it comes to USB, almost any vendor has a good range of MCUs
with USB connectivity. USB does not weigh down 8-bit MCUs, and
16-bit controllers should handle USB well.
Ethernet has been appearing on MCUs more frequently the last
few years, and has increasing promise as the Internet becomes
a backbone for all things electronic. We are consistently seeing
suppliers provide solutions with both MAC and PHY integrated on chip.
There are a few MCUs containing an array of communications
facilities. To highlight one solution, ARM-based Stellaris line from
Texas Instruments has MCUs with several serial peripherals all
on-chip including: two CAN 2.0 A/B controllers, a USB 2.0 Full-
Speed Host/Device/OTG module, a 10/100 Ethernet MAC/PHY with
hardware-assist to synchronize industrial networks via the IEEE 1588
Precision Time Protocol, two SSI/SPI controllers, two I 2 C interfaces, an
I 2 S interface, and three UARTs.
Is your application suffi ciently connected for tomorrow
Technical and Design Support Services
Digi-Key offers live technical support 24/7 via telephone, e-mail
and live web chat. Digi-Key’s 130 technicians on staff are
trained by manufacturers to answer product-specifi c questions.
Additionally, these technicians cross-reference part numbers,
assist customers in choosing products, research and aid in
selecting new product, and provide access to in-depth productspecifi
c information as well as specifi cations and performance
data on new products.
Digi-Key’s Design Support Services (DSS) team of application
engineers and technicians provides general information and
complimentary project-specifi c assistance. DSS provides service
to engineers ranging from one-time contacts regarding product
recommendations to ongoing prototype-to-production design
support. DSS strives to guide the customer through the design
process while achieving the best solutions and, ultimately,
streamlining the design cycle. The DSS team provides support
and advice on system design, aids with product selection and
development tools, and provides assistance with other applicable
design issues. Additionally, members of the DSS team produce
application notes, webinars and instructional videos. The DSS team
is available from 8:30 a.m.-5:00 p.m. CST via telephone, e-mail
and web-conferencing software.
38

Are you a Microcontroller Solution Expert Submit your
answers to find out and automatically be entered for
a chance to win a Microchip PIC18 Starter Kit or an F1
Evaluation Platform!
The MPLAB ® Starter Kit for
PIC18F MCU functions as a USB
mouse, joystick or mass storage
device all using the on-board
capacitive touch sense pads. It
includes a MicroSD memory
card, potentiometer, acceleration
sensor, and an OLED display. It is
completely USB-powered.
The F1 Evaluation Platform
is a simple development tool
for Enhanced Mid-range PIC
microcontrollers (PIC12F1xxx/
PIC16F1xxx) and demonstrates
the capabilities & low power
enhancements of these new PIC
microcontrollers. Included with a
PICkit3 for quick programming,
this kit provides a platform for general purpose development and
gives you the ability to develop code for any PIC12F1xxx/PIC16F1xxx
microcontroller.
Submit your answers to
www.digikey.ca/trivia-mcu
for your chance to win!
Sponsored By:
Official Rules: No purchase necessary to enter or claim prize. A purchase will not improve an individual’s chances of
winning with such entry. Employees of Digi-Key (the “sponsor”), business partners, members of immediate families are not
eligible. Void where prohibited by law or internal company policy. Valid entries contingent upon participation in the trivia
contest and providing name and e-mail address. Prizes will be randomly drawn among eligible entries on or about May 7,
2011. One Microchip PIC18 Starter Kit and one Microchip F1 Evaluation Platform will be awarded. Total value of all prizes
will not exceed $500.00. Contest rules declare only One Microchip PIC18 Starter Kit or Microchip F1 Evaluation Platform
will be awarded per winner . Winners will be contacted via e-mail. If a winner cannot be reached within 7 days of initial
attempt, winner will be disqualifi ed and an alternate winner selected. Odds of winning will be determined by the number of
eligible entries received. Taxes on prizes are the sole responsibility of winners. Sponsor reserves the right in its sole
discretion to cancel or suspend the promotion or any portion thereof should viruses, bugs, or other causes beyond control
of Sponsor corrupt the administration, security or proper play of the promotion, in which case the prizes will be awarded
via a random drawing from among all eligible entries received prior to cancellation. Sponsor is not responsible or liable for
late, lost, damaged or misdirected entries. Any attempts to deliberately damage any web site or undermine the legitimate
operation of the promotion may be subject to prosecution of criminal and civil law. If due to a printing, production or other
error, more prizes are claimed than are intended to be awarded, the intended prizes will be awarded in a random drawing
from among all verifi ed and validated prize claims received. In no event will more than the stated number of prizes be
awarded. Entries become the property of Sponsor and will be used in accordance with Sponsor’s privacy policy, available
at: http://digikey.com/privacy. For a list of winners, mail a self-addressed, stamped envelope to be received by June 1, 2011
to: Digi-Key Corporation, TechZone Trivia, 701 Brooks Ave South, Thief River Falls, MN 56701. If you do not want to receive
any future mailings for contests of this nature, you can remove your name by calling 800-344-4539.
1. Name the only 8-bit MCU provider that offers integrated USB,
CAN, Ethernet, and LCD.
A: Your next door neighbor C: Amazon.com
B: Microchip Technology, Inc. D: Walmart
2. With XLP technology, Microchip is the world-wide leader in
low power. How low is eXtreme Low Power “SLEEP” on the
latest PIC microcontrollers
A: 5 A C: 9 nA
B: 100 nA D: 10 uA
3. With the HiTech C compiler, how much does it cost to start
developing code on PIC microcontrollers
A: About the cost of your college degree
B: $5,000
C: Free
D: Less than the cost of “short-selling” your house
4. Beyond low power “SLEEP” currents, PIC microcontrollers
provide world-class low power “DYNAMIC” currents. How
low can we go
A:

Deeply Embedded Devices:
The “Internet of Things”
by Mark Wright and Rodger Richey, Microchip Technology Inc.
The “Internet of Things” consists of
interconnected, deeply embedded devices
that need to communicate while maintaining
extremely long battery life. Fortunately there
are some low-power RF solutions that address
both halves of the problem.
The “Internet of Things” is about connecting products that create,
store, and consume data via the Internet. This allows processing to
provide results that can be more easily used by people. The basic
technical requirements to enable this are vastly different from the
current treadmill of mainstream Internet-connectivity technology.
Mainstream connectivity strives to constantly increase bandwidth,
range and features to counter dwindling margins and prepare for
the next “killer” application. Whether this is HD media serving,
on-demand TV, 4-play (voice, data, Internet and multimedia), Network
Attached Storage (NAS), or the next thing you absolutely must have,
mainstream connectivity requires a wider, faster-pipe mentality.
Mainstream provisioning, however, is fundamentally disjointed from
the requirements of the “Internet of Things.” While an Internet gamer
will pay $150 to replace his 802.11b/g access point with the latest
802.11a/b/g/n access point, in order to reduce game “latency” or
increase their virtual “survivability,” this is not a price option for
adding connectivity to a thermostat, temperature sensor, garagedoor
opener, coffee maker, or lawn sprinkler. In short, the “Internet
of Things” dictates a signifi cantly different adoption model than
mainstream broadband support.
Applications can be categorized as open, embedded, and deeply
embedded. Open systems are compute-based products with
purpose-loaded functions. Open systems may change their nature
from one use to another. A laptop that is confi gured to be a word
processor in one setting and an Internet-connected media player
in another is an example of this. Due to the varying uses of open
systems, the capabilities must be fl exible yet high-performance
in nature, with the limitations usually driven by cost. Embedded
systems are fi xed function. They may be very high- or lowperformance,
with a limited energy footprint. Deeply embedded
systems are single-purpose devices that are used to detect
something in the environment, perform a basic level of processing
and then do something with the results.
Table 1: Comparison of device categories.
Categories Product Examples Battery Life Data Rate Range
Open PC 4 - 8 hours High Max.
Embedded Access Point, iReader, AC Powered or
Pocket Dictionary up to 2 years
High 30 m - Max.
Deeply
Embedded
Sprinkler Valve, Locks,
Power Monitor
The “Internet of Things” is primarily driven by deeply embedded
devices. These devices are low- bandwidth, low-repetition
data capture, and low-bandwidth data usage “appliances” that
communicate with each other and provide data via user interfaces.
There are embedded appliances, such as high-resolution video
security cameras, video VOIP phones, and a handful of others that
require high-bandwidth streaming capabilities. This article instead
targets the countless products that simply require packets of data to
be intermittently delivered.
Figure 1: Device categories.
2 years + Low - Med. 30 m
Data-rate requirements and the corresponding power consumption
vary signifi cantly between the different device categories. Open-type
devices utilize Pentium class or similar processing, and run complex
OS-based protocols for communication. Such devices require mains
power, or utilize large batteries and have battery life measured in
hours. Battery-operated embedded devices are products for which
it is critical to reduce power consumption, design complexity, and
cost through the optimization of computation occurring in the device.
This is done through the use of specialized hardware, or less fl exible
purpose-driven software. Deeply embedded devices build upon
this optimization and often require battery operation, which creates
a critical need for low power consumption. These products utilize
low-power microcontrollers such as the 16-bit PIC24F family from
Microchip, which features low-power sleep currents down to 20 nA
and allows the use of AA or coin-cell batteries for up to 20 years of
operational life.
40

Examples of deeply embedded, Internet-connected devices include
information displays for the home that can integrate heating and
cooling control with lighting, music, and information displays (e.g.
a web browser); security still cameras that provide an extra level of
coverage for monitored services; appliances that allow time-of-start
control from utilities for smart-energy control, to reduce consumers’
electricity bills; heavy equipment with sensors that can provide
remote indication when in need of pending service; and toys or
multimedia handsets that could be configured for subscription
services, allowing updates during off periods.
The 802.11 protocol provides two basic methods of connectivity. The
primary method is called infrastructure, or basic service set, and is
implemented as a structured network with at least one central point
that routes traffic among the devices and onto other networks. In this
method, the central point is commonly called an access point, and all
communications occur through the access point. The second method
allows “unrelated” devices to connect temporarily. This mode is called
ad hoc, or independent basic service set. Ad hoc communication occurs
from device to device, but allows many devices to share the common
network. A primary advantage of 802.11 over other wireless protocols
is its intrinsic ability to connect devices to the Internet. However, this
functionality is provided primarily through the infrastructure mode of
operation. The Microchip TCP/IP stack and Microchip 802.11 radio
combination supports both infrastructure and ad hoc modes of operation.
Figure 2: Basic methods of connectivity.
One example of a use for a deeply embedded Wi-Fi solution is for
vehicle diagnostics. Considerable effort is spent designing the hardware
and software for user interfaces in these types of applications. However,
PDAs such as the iPod Touch or cellular phones such as the iPhone
are perfectly designed for user interfaces with a rich and intuitive
feature set. Most include Wi-Fi connectivity, which allows the use
of infrastructure or ad hoc modes in the Microchip Wi-Fi module. As
shown in Figure 3, the PDA or phone can connect to the Microchip Wi-Fi
module, and the PIC24F 16-bit microcontroller runs the Microchip TCP/
IP stack for ad hoc mode. The PIC24F microcontroller connects to the
vehicle using any of the standard On-Board Diagnostic (OBD) interfaces,
such as J1850, J1939, ISO 15765-4, etc. Vehicle status, such as RPM,
MPH, and battery voltage, can be displayed in a variety of forms such
as raw values, graphs, or gauges. Once disconnected, the PIC24F can
connect to a central server using infrastructure mode to upload data, or
download new firmware or parameters.
Figure 3: Application example.
Latency is not a critical factor for data transfers in most deeply
embedded devices. This means the data transfer has so little
latency that a user does not discern a delay from an action to the
corresponding reaction. Latency is often critical for handheld remotecontrol
devices, because users get frustrated and consider it a poor
user experience if the time for a local reaction to a button push on the
device is discernable (more than 250 ms).
The 802.11 specification has a mode called “power-save poll”
within the infrastructure service. It allows a device to go to sleep
while maintaining a connection to the access point. A device can
wake immediately and begin communication. Latency can be a little
more than 100 ms for an external client to begin transferring data
to a sleeping device. This is an ideal mode for remote controls using
infrastructure mode, as it provides the ability to power down without
a user-perceived reduction in latency. Battery life is only days with
this mode if the unit is frequently used, so this usage model should
be considered with a charging station. This scenario makes the usage
model for such a device similar to that of a cellular phone.
“Power-save poll” mode is also an efficient way to reduce power
consumption in devices where latency is not an important issue, such
as those that transfer data more than four times a minute. In such
cases, the act of reconnecting to the network consumes more energy
than keeping the device connected via power-save poll. For example,
the Microchip Wi-Fi radio provides the “power-save poll” mode
autonomously to the microcontroller. An added advantage of this is that
the entire client system can shut down during the sleep periods. An
interrupt from the radio will provide the wake indication, in case there
is data waiting on the AP. Additionally, for remote-control applications,
a wake-on-button-press or wake-on-motion can be provided via the
microcontroller, to maintain the illusion of always being on for the user.
For deeply embedded devices where latency is not critical, the best
methodology for increasing battery life is to turn off the radio. The off
state with leakage is the hibernate mode on the Microchip Wi-Fi radio.
Once outstanding traffic is resolved via the TCP/IP stack, a single
GPIO pin is used to deselect the device. This operation automatically
disconnects power from the Wi-Fi radio. This mechanism allows the
microcontroller and Wi-Fi radio combination to utilize about 120 nA in
power-down mode. Such a combination is ideal for deeply embedded
devices, because their low active power consumption stretches the
system’s battery life.
www.digikey.ca/microcontroller
41

In all of the aforementioned deeply embedded devices, latency
is not critical. Other applications where latency is not critical
include security or environmental sensors, data-upload services
for medical monitoring, and consumer news devices, as well as
information servers.
Deeply embedded devices don’t need 300 Mbps, 54 Mbps or often
even 11 Mbps of throughput. A majority of deeply embedded devices
use a low amount of bandwidth. They have data for transmission
a few times a day, or expect to receive data possibly once a day.
The amount of data they deal with is on the order of 100 bytes. By
keeping external memory minimized or not using it at all, the overall
system cost and power consumption remain low.
A normal infrastructure connection provides about a 5-10 second
reconnect period from the hibernation stage. The connect processing
between the Wi-Fi radio and an access point takes about 176 ms.
Connecting takes longer than this, so the majority of the time is
spent in the delays associated with the access point dealing with the
connection. This can be easily seen by virtue of the time it takes a
standard laptop (a high-end open system) to connect to a network.
This time can be reduced by using the static addressing feature of the
Microchip TCP/IP stack. With such an operation, the connect time with
security can be reduced to less than a second.
Ad hoc connection from a power up can take less than 200 ms.
For point-to-point-only remote-control devices, ad hoc operation is
suitable because the achievable connection times are short. This
method of operation is not often used for remotes because while
it does resolve the connection-time problem, the limited use of the
wireless technology for simple point–to-point only communications
without LAN or internet connectivity can be better served by other
wireless technologies, such as basic RF transceivers or the IEEE
802.15.4 protocol.
A very good application of the ad hoc mode of operation is as a
default mechanism to enable easy confi guration of the device onto
the network of interest. Deeply embedded products that do not
have a screen/keyboard to enter data need a method for the end
user to confi gure the network, as well as the security parameters
of their network. In this case, the codes can be entered using a
temporary network. To use a temporary network, the product must
be preconfi gured to start either searching for a pre-determined
infrastructure network, or by creating a pre-determined ad hoc
network. In either case, another computer or Wi-Fi-enabled device
(e.g. iPhone, Smartphone, etc.) connects to the product using the
pre-determined network, and then confi gures the product to the
fi nal desired network. Once the appropriate network information
is entered, a command can be sent to the product to restart in the
desired network.
One advantage of 802.11 for deeply embedded devices is the
ability to use pre-existing networks and the Internet. There is some
concern regarding the impact to performance for other computers
that use the network, when a low-bandwidth, deeply embedded
device is also attached to that network. Wireless communication
is a shared-bandwidth, media-access mechanism. There is a fi nite
amount of bandwidth available for all to use before the airwaves get
saturated with signals. The biggest impact is from clients utilizing
the available bandwidth. Thus, adding a second 802.11g laptop
to a network that already has an 802.11g-connected laptop on it
will reduce the available bandwidth by 50 percent. The hibernate
mode described earlier for power savings also serves, in this
case, to minimize the effect on the network of embedded devices.
Embedded devices should be confi gured to buffer their information
and burst as required. Such usage will allow the devices to get on
the network, transfer their data, and then get off the network. The
effect of this will be maximum power savings and minimal impact
on network-bandwidth capabilities.
Figure 4: Example of mixed devices in a network.
A critical need of deeply embedded systems is to keep the
communication system easy to implement and use. While the
802.11 protocol makes an ideal candidate for communication for
these devices, many manufacturers are specialized in the art of
their own product, and not in wireless IP communications. There
is often no room in a critically costed product for more memory
to run an operating system, in order to use an off-the-shelf driver
that traditional 802.11 solutions offer. These drivers are created for
complex operating systems, such as Windows, Windows Embedded
CE, or Linux.
A signifi cant benefi t of a solution like the Microchip 802.11 one is
the ease of implementation to the developer. Along with the basic
networking features of security, infrastructure, and ad hoc; the
stack supports various services that a deeply embedded product
developer would require. Some of the services supported are ICMP,
HTTP, SSL, DHCP, FTP, SMTP, SNMP, TFTP, DNS, and Telnet. These
are suffi cient for serving Web pages, sending and receiving data
fi les, and handling e-mail services. The value to the customer is
the ability to minimize code-space requirements by selecting only
the services they require, accelerated time-to-market, and allowing
concentration on device application and user interface, rather than
on the underlying communications protocol.
The “Internet of Things” is about connecting a diverse set of simple,
deeply embedded devices to the tools we already use. It allows
servers and other instruments that can work in the background to
provide a clearer understanding of what is happening—whether
the interest is in energy conservation, product maintenance, health
and safety, or just information retrieval. The Microchip 802.11
solution has been designed with the mindset for deeply embedded
devices. This solution takes into consideration the speed, bandwidth,
and latency needs of embedded devices—these being much
42

less than what most people demand for their day-to-day Internet
connectivity experience. This makes the solution much lower in
power and easier to use than standard IP-connection alternatives.
The solution is also compatible with the cost constraints of
deeply embedded devices. These characteristics allow the system
developer to concentrate on application development rather than on
networking knowledge.
While it is said that the “Internet of Things” will progress to a
billion new connected things by 2011, the majority of these will
be in embedded and deeply embedded devices. The unique
characteristic of IP connectivity is that having devices connected
and providing improved effi ciency is not the only benefi t. The
real return is the progression of benefi ts that will result from the
interconnecting of devices to a wider and automated information
database. This can include better performance through longer
operation within optimal ranges, new revenue streams that will
give users simplicity in dealing with things that otherwise go into
disrepair, and also increased sales pull-through via product and
information co-marketing.
Intro to PIC24FJDA Family
Microchip Technology
The PIC24FJDA family from Microchip features graphic
acceleration and direct interface to STN, TFT, and OLED
displays. The series comes with 64-pin QFN, TQFN, and for
the fi rst time BGA packages.
The product training
module for this
series provides
in-depth lists of
the products’ many
features, explains the
properties of Power
Consumption, and
a cost comparison
chart for budget planning.
This module can be experienced with or without audio in
approximately 15 minutes
and is 24 pages in length.
www.digikey.ca/ptm
PIC24F04KA201 Family
As more electronic applications require low power or battery
power, energy conservation becomes paramount. Products with
Microchip’s nanoWatt XLP Technology offer the industry’s lowest
currents for Run and Sleep modes. The PIC24F04KA201 family is
ideal for low cost, low pin-count applications (14-20 pins) which
require up to 4 KB Flash that also need 16-bit performance (16
MIPS). This family includes a range of peripherals including timers,
UART, SPI, I 2 C, ADC, comparators and CTMU for precise time
measurement or touch sensing. With full analog and self write
capability down to 1.8 V, the PIC24 “KA” family will extend the
battery life in your next design.
Use the free Microchip XLP Battery Life Estimator to select the
target MCU, battery type, and energy profi le to get an estimate of
battery life for your application. It’s easy to get started with the
XLP MCUs, using the XLP 16-bit Development Board (DM240311),
which includes current measurement terminals and fl exible power
sources (AAA, coin cells or energy harvesting modules).
Example applications for the new PIC24F04KA microcontrollers include:
• Medical (portable and home medical devices, oxygen fl ow
meters, lifestyle/fi tness monitors)
• Industrial (energy harvesting/scavenging, water/gas/heat
meters, portable gas sensors, remote sensor networks, asset
tracking, sealed/harsh environment sensors)
• Consumer (security-system dongles, sealed disposable
electronics, portable electronics, smart cards)
www.digikey.ca/microchip-mcu
www.digikey.ca/microcontroller
43

Peripheral Reflex System
Avoids MCU Overload
contributed by Energy Micro
Normally, MCUs spend much of their time
passing information between peripherals. That
doesn’t have to be the case.
The Peripheral Refl ex System (PRS) is a network which lets the
different peripheral modules communicate directly with each other
without involving the CPU. Peripheral modules which send out Refl ex
signals are called producers. The PRS routes these refl ex signals to
consumer peripherals which apply actions depending on the Refl ex
signals received. The format for the Refl ex signals is not given, but
edge triggers and other functionality can be applied by the PRS.
Overview
An overview of one channel and how four different peripherals can
be connected using PRS is given in Figure 1. The PRS contains eight
interconnect channels, and each of these can select between all of
the output Refl ex signals offered by the producers. The consumers
can then choose which PRS channel to listen to and perform actions
based on the Refl ex signals routed through that channel. The Refl ex
signals can be both pulse signals and level signals. Synchronous PRS
pulses are one HFPERCLK cycle long, and can either be sent out by
a producer (e.g. ADC conversion complete) or be generated from the
edge detector in the PRS channel. Level signals can have an arbitrary
waveform, but will be synchronized with the HFPERCLK.
Producer
Side
Channel 0
Signals from
producer
peripherals
TIMER0
Overflow Pulse
ACMP
Output Level
.
.
.
.
.
PRS
x8
SIGSEL[2:0]
SOURCESEL[5:0]
EDSEL[1:0]
SWPULSE[0]
SWLEVEL[0]
ADC0
Start single conv.
Reg
APB bus
Signals to
consumer
perpherals
TIME1
CC1 Input
Consumer
Side
Figure 1 shows four peripherals connected to two PRS channels.
On one channel is TIMER0 and ADC0 and the ACMP and TIMER1 are
connected to a second channel. An overfl ow from TIMER0 can start an
ADC single conversion and an ACMP output can be used as input for a
Compare/Capture channel on TIMER1.
General operation
Channel functions
Different functions can be applied to a Refl ex signal within the
PRS. Each channel includes an edge detector to enable generation
of pulse signals from level signals. It is also possible to generate
output Refl ex signals by software writing to PRS_SWPULSE and
PRS_SWLEVEL registers. PRS_SWLEVEL is a programmable level
for each channel and holds the value it is programmed to. The
PRS_SWPULSE will give out a one-cycle high pulse if it is written to
1, otherwise a 0 is asserted. The SWLEVEL and SWPULSE signals
are then XOR’ed with the selected input from the producers to form
the output signal sent to the consumers listening to the channel.
This is illustrated in Figure 1.
The efm32lib function void PRS_
SourceSignalSet(unsigned int ch, uint32_t
source, uint32_t signal, PRS_Edge_TypeDef
edge) can be used to easily confi gure the PRS channels. By
specifying the PRS channel producing peripheral signal from
the peripheral and the edge for pulse generation, the function
confi gures the PRS accordingly.
Producers
Each PRS channel can choose between signals from several
producers, which is configured in SOURCESEL in PRS_CHx_CTRL.
Each of these producers outputs one or more signals which can
be selected by setting the SIGSEL field in PRS_CHx_CTRL. Setting
the SOURCESEL bits to 0 (Off) leads to a constant 0 output from
the input mux. An overview of the available producers is given in
Table 1.
Consumers
Consumer peripherals (Table 2) can be set to listen to a PRS channel
and perform an action based on the signal received on that channel.
Most consumers expect pulse input, while some can handle level
inputs as well.
Figure 1: PRS overview.
44

Table 1: Reflex producers.
Module Reflex Output Output Format
ACMP Comparator Output Level
ADC Single Conversion Done Pulse
Scan Conversion Done
Pulse
DAC Channel 0 Conversion Done Pulse
Channel 0 Conversion Done Pulse
GPIO Pin 0 Input Level
Pin 1 Input
Level
Pin 2 Input
Level
Pin 3 Input
Level
Pin 4 Input
Level
Pin 5 Input
Level
Pin 6 Input
Level
Pin 7 Input
Level
Pin 8 Input
Level
Pin 9 Input
Level
Pin 10 Input
Level
Pin 11 Input
Level
Pin 12 Input
Level
Pin 13 Input
Level
Pin 14 Input
Level
Pin 15 Input
Level
RTC Overflow Pulse
Compare Match 0
Pulse
Compare Match 1
Pulse
TIMER Underflow Pulse
Overflow
Pulse
CC0 Output
Level
CC1 Ouput
Level
CC2 Output
Level
UART TX Complete Pulse
RX Data Received
Pulse
USART TX Complete Pulse
RX Data Received
Pulse
IrDA Decoder Output
Level
VCMP Comparator Output Level
Table 2: Reflex consumers.
Module Reflex Input Input Format
ADC Single Mode Trigger Pulse
Scan Mode Trigger
Pulse
DAC Channel 0 Trigger Pulse
Channel 1 Trigger
Pulse
TIMER CC0 Input Pulse/Level
CC1 Input
Pulse/Level
CC2 Input
Pulse/Level
DTI Fault Source 0 (TIMER0 only) Pulse
DTI Fault Source 1 (TIMER0 only) Pulse
DTI Input (TIMER0 only)
Pulse/Level
UART TX/RX Enable Pulse
USART TX/RX Enable Pulse
IrDA Encoder Input (USART0 only) Level
Software examples
This section describes four software examples that explore possible
interactions between peripherals using the PRS:
• TIMER triggered ADC conversion
• Pulse Width Measurement with the ACMP and TIMER
• GPIO triggered UART transmission
• Software triggered DAC conversion
TIMER triggered ADC conversion
Figure 2 shows how to set up ADC0 to start a single conversion every
time that TIMER0 overflows. TIMER0 sends a one HFPERCLK cycle
high pulse sent from TIMER0 to the ADC0 through the PRS on each
overflow, and the ADC does a single conversion which is displayed
on the LCD of the STK/DK development boards. The ADC consumes
pulse signals, which are the same signals produced by the TIMER. In
this case there is no edge detection needed, so the PRS leaves the
incoming signal unchanged.
Producer
Side
Channel 5
Signals from
producer
peripherals
TIMER0
Overflow Pulse
1 HFPERCLK Pulse
SIGSEL[2:0]
SOURCESEL[5:0]
EDSEL[1:0]
SWPULSE[5]
SWLEVEL[5]
ADC0
Start single conv.
APB bus
Signals to
consumer
perpherals
Figure 2: TIMER0 overflow starting ADC0 single conversions using the PRS.
PRS
Consumer
Side
The ADC is configured with 8-bit resolution and Vdd as both
reference and input. When the ADC finishes the conversion it
generates a single conversion complete interrupt. The CPU will then
fetch the result and display it on the LCD. The displayed result is a
direct reading from the ADC0_SINGLEDATA register which is always
255, given that the input is the same as the reference. The DMA can
also be used to fetch the conversion result and that is covered by
the AN0021 Analog to Digital Converter.
The software project prs_timer_adc implements this example
and can be used on both STK and DK development boards.
Pulse width measurement with ACMP and TIMER
Figure 3 illustrates how to measure the pulse width or period of an
arbitrary waveform. The ACMP is used to send a level signal through
the PRS. TIMER0 consumes both pulse and level signals so the PRS
leaves the incoming signal unchanged. On TIMER0 the PRS signal is
used as input for CC0 channel. TIMER0 starts counting on a positive
edge and captures the counter value on a negative edge.
Reg
1 HFPERCLK Pulse
www.digikey.ca/microcontroller
45

Channel 5
SIGSEL[2:0]
SOURCESEL[5:0]
EDSEL[1:0]
APB bus
must be used to generate a pulse signal on a GPIO positive edge
transition. The clock pulse enables the USART TX and transmits the data
that was placed in the TX buffer. For the GPIO to generate PRS signals,
the PRS Sense must be enabled in the GPIO_INSENSE register.
Signals from
producer
peripherals
SWPULSE[5]
SWLEVEL[5]
Reg
Signals to
consumer
perpherals
The software project prs_gpio_uart implements this example
and is intended for the DK only. To enable the USART TX, pin PD0 must
be connected to VMCU to generate a positive edge. The EFM32 will then
send the character ‘X’ through SERIAL A with a 57600 baud rate, no
parity and one stop bit.
Producer
Side
ACMP
Output Level
PRS
TIMER0
Reload&Start + Capture&Stop
Consumer
Side
Software generated PRS pulse triggers DAC conversion
Figure 5 shows how to generate a PRS pulse by software. The PRS
pulse will trigger a DAC conversion which outputs a 0.5 V signal on
pin PB11. It is possible to generate both pulse and level signals by
software. In this case a pulse signal is generated because it is the type
of signal consumed by the DAC. DAC conversions can also be started
by software in the DAC itself. This example only shows how this can be
done through the PRS as well.
Level
Figure 3: ACMP level output used as PRS signal for TIMER0 CC0 channel input.
Level
Channel 5
SIGSEL[2:0]
Figure 3 also shows the level output from the ACMP sent through the PRS
to the TIMER which measures the pulse width using the capture feature.
The software project prs_pulse_width implements this
example and can be used on both STK and DK. To trigger the pulse
width measurement, pin PC4 (P4.7 on the DK protoboard) must be
connected to VMCU to generate a high level that will trigger the ACMP
and start the TIMER. When the connection is released, the output of
the ACMP will be low again and the TIMER captures the counter value
and displays it on the LCD.
GPIO triggered USART transmission
Figure 4 illustrates how to use an external signal coming through the GPIO
to enable the USART transmitter. It shows a positive edge from a GPIO
pin sent on the producer side through the PRS edge detector to create
a one HFPERCLK cycle pulse on the consumer side. The GPIO produces
level signals which are not consumed by the UART so the edge detector
Producer
Side
Channel 5
Signals from
producer
peripherals
GPIO
Output Level
Positive Edge
PRS
SIGSEL[2:0]
SOURCESEL[5:0]
EDSEL[1:0]
SWPULSE[5]
SWLEVEL[5]
UART
Enable TX
Figure 4: USART TX enabled by GPIO signal using the PRS.
Reg
1 HFPERCLK Pulse
APB bus
Signals to
consumer
perpherals
Consumer
Side
Producer
Side
Signals from
producer
peripherals
Figure 5: Software triggered PRS signal.
SOURCESEL[5:0]
EDSEL[1:0]
SWPULSE[5]
SWLEVEL[5]
APB bus
Figure 5 shows a one HFPERCLK cycle pulse triggered from software.
Pulse and level signals can be generated by software by writing directly
to the PRS_SWPULSE and PRS_SWLEVEL registers respectively. They
can also be generated using functions from the efm32lib:
• void PRS_PulseTrigger(uint32_t channels)
generates pulse signals
• void PRS_LevelSet(uint32_t level,
uint32_t mask) generates level signals
PRS
DAC0
Start conv.
Signals to
consumer
perpherals
Consumer
Side
The software project prs_soft_dac implements this example
and can be used on both STK and DK.
Monitoring of PRS signals
The PRS channels can be monitored using peripherals that consume
PRS signals. One example is using a TIMER to make a capture when
there is activity on the PRS channel it is connected to. The software
project main_prs_channel_scan exemplifi es how this can
be accomplished and can be used on both STK and DK.
Reg
1 HFPERCLK Pulse
46

The function PRS_ScanChannel(TIMER_TypeDef
*timer, TIMER_PRSSEL_TypeDef prsCh,
TIMER_Edge_TypeDef edgeType) in the main_
prs_channel_scan project can be used to monitor activity on a
specifi c PRS channel. It sets the CC0 channel on the chosen TIMER to
capture a selected signal edge. The project can be used on both STK
and DK and the parameters are as follows:
• timer: pointer to the TIMER peripheral register c\block
• prsCh: PRS channel to be monitored
• edgeType: signal edge to be monitored/captured
This function will hang on a while loop waiting for activity in the PRS
channel. When such activity occurs, it writes PRS and the channel
number on the LCD. To generate activity on this line, the user must
connect PC4 to VMCU to generate a rising edge transition on the PRS
channel using the ACMP.
Another option is to have a capture interrupt instead of polling. That
way the program will not hang and the processor will be available to
execute other tasks. When a capture is triggered, the user knows that
there was activity on the selected PRS channel.
Innovations in Connectivity:
a look inside Digi-Key’s state-of-the-art Weather Center
iDigi Server
Ethernet, WiFi, Cellular
Computer
HTML,
Gadgets, Widgets
Node
(Wired/Wireless)
Drivers
Gateway
(Cellular, WiFi,
Ethernet, Satellite)
Drivers
Internet
(Cloud)
Cell Phone
Digi-Key Server
WiFi, Cellular
Android, iPhone,
Blackberry Apps
Weather Center Structure
12VDC
Power Rail
In a wireless world, devices like the Digi-Key
Weather Center utilize the best in electronic
components to test conditions in an environment
where temperatures range from sizzling to
subzero. Above is a diagram depicting the process
by which Digi-Key’s Weather Center conveys the
data collected to computers and mobile devices.
This connectivity is achieved by Digi-Key’s
custom-made weather tracking system—
composed of the best in wireless, sensor,
microcontroller, and lighting technology.
Outer Design
The Digi-Key Weather Center was constructed in
a simple “T” shaped design. Measuring three feet
across, the top beam is made of three-inch “C”
channel. This provides a place for sensor modules,
an anemometer, and any future additions.
The trunk of Digi-Key’s Weather Center is
approximately seven feet tall and composed of
three-inch square tubing. Mounting brackets for
solar panels and the electronic box are attached.
The Weather Center is supported by a square
plate, measuring two feet across.
Inside the Weather Center
The heart of the Weather Center, the main box
located in the middle of the Weather Center’s
trunk, is from BUD’s NBA series, Digi-Key part
number 377-1139-ND. This box is rated at IP65
of IEC 529 and NEMA 1, 2, 4 and 4x specifi cations
with temperature ranges from -40°C to over 70°C.
While the Digi-Key Weather Center has seen
nearly 100°F of heat in the summer and has been
exposed to -38°F temperatures in the winter, the
center has remained resilient.
To provide venting for the center’s box, Bud’s
NBX-10910-ND and the NBX-10911-ND moisture
vents were installed. Although the center has
experienced harsh weather conditions, no moisture
or debris has been detected within the box.
The top beam is made of “C” channel, which provides a place
for sensor modules, an anemometer, and any future additions.
To interface the box to the sensors, Switchcraft’s
SC1390-ND Jack and the SC1381-ND Plug were
utilized. These connectors are rated at IP68 when
properly mated.
On the inside of the box, Injectorall Electrics’ FR4
unclad board material (PC8-UNCLAD-ND) was
installed to create a proper back panel. On the panel
the primary circuit board and two power distribution
strips by Molex (WM5737-ND) were applied.
This inside look at the mechanics behind Digi-
Key’s Weather Center is the second in a series of
articles that will explore the development of the
Weather Center’s technology and the innovations
of connectivity. Additional articles will appear in
upcoming issues of TechZone magazines. For
more information about the Digi-Key Weather
Center, visit connectivity.digikey.com.
An update was made in November 2010 to include three solar
panels in order to collect as much solar energy as possible.
www.digikey.ca/microcontroller
47

CAN Primer: Creating
Your Own Network
by Bob Boys, ARM
CAN is a flexible network that is easy to
implement. If you are considering networking
topologies for your next embedded design,
this article will set you on the right path.
CAN is extensively used in automobiles and trucks and can be found
in multiple applications. There are many “application” layers available
for CAN, such as ISO 15765 (cars), J1939 (trucks), and CANopen
(factory automation), but it is very easy to develop your own protocol
to fi t and simplify your needs. Modern CAN transceivers provide a
stable and reliable CAN physical environment without the need for
expensive coaxial cables. Most of the mystery of CAN has dissipated
over the years. There is plenty of example CAN software available to
help you quickly develop your own network.
A CAN controller is a sophisticated device. Nearly all the features
of the CAN protocol described below are automatically handled by
the controller with almost no intervention by the host processor. All
you need to do is confi gure the controller by writing to its registers,
write data to the controller, and the controller then does all the
housekeeping work to get your message on the bus.
The controller will also read any frames found on the bus and hold
them in a small FIFO memory. It will notify the host processor that this
data is available, which is then read from the controller. The controller
also contains a hardware fi lter mechanism that can be programmed
to ignore the CAN frames you do not want passed to the processor.
For the purposes of this article; we will assume a CAN network
consists of the physical layer (the voltages and the wires) and a frame
consisting of an ID and a varying number of data bytes. CAN has the
following general attributes:
1. 11- or 29-bit ID and from zero to eight data bytes. These can be
dynamically changed “on the fl y.”
2. Peer-to-Peer network. Every node can see all messages from all
other nodes. A node cannot read its own messages.
3. Nodes are easy to add. Attach one to the network with two wires
plus a ground.
4. Higher priority messages are sent fi rst depending on the value of
the ID. A lower ID has the highest priority.
5. Automatic retransmission of defective frames. A node will “busoff”
if it causes too many errors.
6. Speeds from approximately 10 Kbps to 1 Mbps. All nodes must
operate at the same frequency.
7. The twisted differential pair provides excellent noise immunity
and some decent bus fault protection.
8. The CAN system will work with the ground connection at
different DC levels or no ground at all.
The CAN system layout
A CAN network consists of at least two nodes connected together
with a pair of twisted wires, as shown in Figure 1. A ground wire can
be included with the twisted pair or separately as part of the chassis.
One twist per inch (or more) will suffi ce, and the integrity of the
ground is not necessary for normal operation. As in any differential
systems, the voltage levels between the wire pair are important, and
not their values to ground. CAN is completely described in ISO 11898.
The maximum length of the network is dependent on the frequency,
number of nodes and propagation speed of the wire. It is relatively
easy to have a 20 node (or more), 500 Kbps system running 30 or 40
feet (or more). The drops should be less than three feet and randomly
spaced to reduce standing waves. These issues all become more
important at higher bus speeds.
Figure 1: A CAN network.
Since the twisted pair is a transmission line, 120 ohm termination
resistors are needed at both ends of the backbone. Do not put any
resistors at the nodes. Your total resistance value as measured
between the two twisted wires will be 60 ohms. CAN is a broadcast
system. Any node can “broadcast” a message using a CAN frame
on a bus that is in idle mode. Every node will see this message. A
“message” can be considered the same as a CAN frame until you
need to use more than one frame to send a long message. It is up to
the individual node if it must react to a CAN frame or just ignore it.
48

Figure 2: Schematic diagram from the
Keil MCBSTM32E evaluation board.
A node schematic
Figure 2 shows the schematic diagram from the Keil MCBSTM32E
evaluation board. IC1 is a Texas Instruments CAN transceiver that
performs the conversion between the single-ended CAN controller
CAN Tx and CAN Rx signals to the bidirectional differential pair of
the CAN bus called CANH and CANL (High and Low). This schematic
is complete.
The STM32 CAN I/O is TTL, CMOS and 5 V tolerant, making it
exceptionally easy to design the interface. This transceiver IC1
connects to the STM32 microprocessor IC2, which contains an
integral CAN controller via two pins: D (Driver input) and R (Receiver
output). The corresponding nomenclature on the STM32 is CAN Rx
and CAN Tx. CAN Tx connects to D. CAN Rx connects to R. Some
processors have multiple CAN controllers. These are usually used
in routers, gateways or to create more receiver FIFO memory for
intentionally slowed down CPUs (for EMI reasons). For general use, a
node normally needs only one controller. If it had at least two, it could
talk to itself.
RS on IC1 (slope control) is used to adjust the rise and fall times of
the output edges to limit EMI from the twisted pair. Note R4 is a 120
ohm termination resistor. This evaluation board is meant to be used
with one other board as a small test network. If this board is used as
a node, and is not at one of the ends, this resistor should be removed
and external resistors used. P17 corresponds to a generally accepted
standard for CAN on DB9 connectors. P17 Pin 7 is the CAN Hi bus line
and pin 6 is CAN Lo. If CAN Hi and CAN Lo are reversed, the network
will not operate properly. It might not work at all.
There are three physical layers used in CAN: Hi-Speed, Fault Tolerant
and Single Wire. Hi-Speed is the most common and is the one we will
use in this article. Fault Tolerant offers more robustness as its name
implies and is used more often in European autos. Single Wire is used
by General Motors as a low-speed body network along with Hi-Speed
main network.
Hi-Speed in cars has a speed of 500 Kbps, trucks are 250 kbps.
CANopen runs up to 1 Mbps. Fault Tolerant is usually 125 kbps, and
GM Single Wire is normally 33.33 kbps. One Mbps in a large system is
difficult to handle. 500 kbps is easier.
To change from one to the other requires only the transceiver chip
to be exchanged and probably changing the speed. These three
layers cannot be physically connected to each other as the voltage
levels are different. Use a router or gateway to join different CAN
networks together. Any CAN controller will properly service all three
layers of CAN.
The Hi-Speed CAN physical layer is a pair of twisted wires with a
120 ohm termination resistor at each end and twisted wire drops to the
individual CAN nodes. A node can be directly connected to the bus.
CAN Hi voltage, with respect to ground, changes between 2.5 to 4
volts nominal. CAN Lo changes from 2.5 to 1 volt. Therefore, the
difference between the two is either 0 volts (is logical “1”) or 3 volts
(logical “0”). 0 is known as the “dominant” state and 3 volts is the
“recessive” state.
These two signals, CAN Hi and CAN Lo, are 180 degrees out of phase.
Bus idle is when the voltage difference is zero.
The CAN frame
The CAN frame has many fields but can be simplified to a
Programming Model as shown in Figure 3. These fields must be
written by software or read from the CAN controller registers. The CAN
configuration registers are not included.
Figure 3: CAN Frame Programming Model.
• IDE: Identifier Extension: 1-bit - specifies if the ID field is 11 or
29 bits.
If IDE = 0, then the ID is 11 bits.
If IDE = 1, then the ID is 29 bits.
• DLC: Data Length Code: 4 bits - specifies number of data bytes
in frame from 0 through 8.
• ID: Identifier: 11 or 29 bits as set by IDE. This part of the CAN
frame sets the priority.
• Data Bytes: 0 through 8 bytes. A CAN frame with only an ID field
and no data bytes is valid and useful.
www.digikey.ca/microcontroller
49

ID: Identifier: 11 or 29 bits
The Identifi er can be used for any purpose. It is often used as a node
address or to identify requests and responses. CAN does not specify
what the ID should be.11-bit is sometimes called Standard CAN and
29-bit is called Extended CAN.
1. If two or more CAN messages are put on the bus at the same
time; the one with the highest priority (the lowest value) ID will
immediately get through. The others will be delayed and will be
resent as soon as possible.
2. An ID of 0 has the highest priority and will always get through.
An 11-bit ID has priority over any 29-bit ID.
3. The ID size can be changed at any time for a mix of 11- and
29-bit IDs. The controller can easily sort this out.
4. Messages tend to start transmitting at the same time. It is not
permissible for a CAN node to start transmitting if another is
already transmitting. This will cause a bus error.
5. Note that a CAN controller can be confi gured to pass only certain
messages to its host processor. Choose ID values carefully to
take advantage of this, if needed. This can take a large work load
off of a node’s processor.
6. Use the ID for data, node addressing, commands and request/
response sequences. Commercial protocols use these in
practice. Choose any method or create your own to best suit
your purpose.
7. Make sure two nodes will never send the same ID value at the
same time. It is illegal but possible to do this. If two messages
sent at the same time are identical, they will be seen as one. If
the data bytes are different, this will result in a bus error and the
frames will be resent continuously, creating havoc on the bus
until bus-off occurs.
Data bytes
Select from zero to eight data bytes using the 4-bit DLC fi eld.
1. Any number of data bytes can be mixed on the CAN bus. The
controller can easily sort this out.
2. By always using only one number of data bytes,
software will be much simpler to write and maintain.
3. The data bytes can contain anything. It will not be prioritized like
the ID. CAN does not specify data contents.
4. Commercial protocols such as J1939 use these for data as well
as control bits for multi-frame transmission schemes.
Remote frames
Though not used often, a remote frame is a quick method of getting a
response from another node(s). It is a request for data. The requesting
node sends out a shortened CAN frame with only a user specifi ed ID
number and the number of data bytes it expects to receive (the DLC
is set). No data fi eld is sent. The responding node(s) sees this ID and
DLC, recognizes that it has the desired information and sends back
a standard CAN frame with the same ID, DLC and with its data bytes
attached. All of this (except that the response node recognizes the ID
and DLC) is implemented in the CAN controller hardware. Everything
else must be confi gured by the user software.
Bus loading
Many CAN networks work on a bus loading from 15 to 35 percent
and this is increasing. A higher bus loading can cause lower priority
messages to be delayed, but these messages will still get through in
a timely fashion. It is quite diffi cult to achieve 100 percent bus loading
although one can come quite close. Overall system performance does
not drop greatly at high bus loading.
It is possible to get very high bus loads for a very short period of time
in any CAN network. CAN does not automatically space out messages.
It is possible to get a series of back-to-back messages that will
equal nearly 100 percent bus loading. One solution is to select only
those messages needed by a node by programming its acceptance
fi lter. Another is to have your software space out the messages. This
problem is diffi cult to diagnose.
Bus speed
Bus speed in a system is a balancing act between things such as
propagation delays (from bus length) and EMI emissions versus
necessary data throughput. Run the network as fast as possible for
stable operation and with enough throughput. Do not run it faster than
necessary, but make some room for later expansion.
If the network is not stable, make sure there are two good termination
resistors at each end of the network. Try slowing the CAN speed
down to see if this helps. Resistors can be ordinary 120 ohm 1/2 watt
carbon type. This is not critical.
TIP: How to determine the frequency of a CAN signal: (This is the best
and sometimes only way to determine this.)
1. Connect an oscilloscope hot lead to CAN Hi and its ground to CAN
Lo. The scope ground must be isolated from the CAN ground. You
can go from ground to one of the CAN leads, but the signals will
be lower and noisier.
2. Display a trace. A storage scope may be needed to see just one
trace due to the non-repetitive nature of CAN.
3. Pick the smallest width signal pulse and measure its time period
in seconds as accurately as possible.
4. Invert this value (divide into 1)to obtain the CAN speed in bits per
second.
Bus errors
Recall that all the nodes (including the transmitting node) check each
CAN frame for errors. If an error is detected, the following occurs:
1. Any or all of the nodes will signify this fact by driving the bus to
logical 0 (dominant state) for at least six CAN bits.
2. This violates the Bit Stuffi ng rule (never greater than 5 bits the
same polarity), so every node sees this as an error.
3. This so called “Error Frame” signals to all nodes a serious error
has occurred.
4. The transmitting bus abandons the current frame and adds four
to its 8-bit TEC (Transmit Error counter) register.
5. If this TEC equals 0xFF, the transmitting node goes BUS OFF and
takes itself off the bus (it is zero at RESET).
50

6. If not, it attempts to retransmit its message. It will still have to go
through the priority process with other messages.
7. All other nodes also abandon reading the current frame, and
adds four to each REC (Receive Error Counter) register.
8. Any nodes that have messages queued up for transmission will
transmit now. All others start listening to the bus.
9. Hopefully, this time the message(s) will be broadcast and
received error free. Each time a frame is transmitted and/or
received successfully, the corresponding TEC and REC registers
are decremented (usually by only one).
TIP: Error counters These are two 8-bit registers in every CAN
controller and you can read these with your software. This is a good
idea because it gives some indication of general bus health and
stability. In a good CAN network, TEC and REC will equal zero. If it
starts having higher values, something has happened to your network.
The usual suspect is bad hardware. The problem is usually in either
the wires or the transceiver chip.
Don’t forget that if something happens to the integrity of the twisted
pair, such as CAN Lo disconnected; it might still work but with greatly
reduced noise immunity (that is what differential signals do best). If
the network is in a very noisy environment, there might be a lot more
transient bus errors. This is very tricky to debug without knowledge of
the REC and TEC register contents. Put this in the software and report
it to the diagnostic routines.
In a general sense, TEC represents a given node’s errors and REC
indicates the other nodes’ errors.
Bus off: As mentioned, if a transmitting node detects it has put too
many bad frames on the bus, it will disconnect itself. It will assume
that there is something very wrong with itself. To get back on the bus
depends on how the controller is configured. It can take a controller
RESET or a certain number of good frames received or what is
configured to get back on.
TIP: How can you create a Bus Error for testing
Have a node send a message at the wrong frequency. When this
frame tries to get on the bus, this is certain to create a bus error
condition. Some CAN controllers can send a one-shot frame.
BUS faults
This is different from a bus error. We normally think of a bus fault as
something that has happened to the “wires” or the output transistors
of the transceiver chip. Not all bus faults will result in a bus error. A bus
error can be thought of as the CAN controllers’ reaction to a problem on
the bus such as noise, faulty node that includes a bus fault.
What happens if one of the twisted pair opens or is shorted out
CAN has an automatic mechanism for this. Not all transceiver chips
implement all of them. You can usually short CAN Lo to ground (ISO
11898 says CAN short Hi also) or open one CAN line. The ground needs
to be connected for these to function. You cannot short both Hi and
Lo together (Fault Tolerant will work) or open both up. You can cut the
ground or have a large ground loop present and CAN will still work.
These will be detected as a bus error as described above. At least one
node must try to transmit a frame in a bus fault condition to trigger a
bus error. A bus in idle mode cannot trigger a bus error. When the bus
fault is removed, in many systems the network will come back alive,
if so configured. CAN has excellent noise immunity because of the
twisted pair. The common mode noise gets cancelled out and the CAN
signal is not affected (because it is 180 degrees out of phase).
The ground: The ground is not needed for CAN operation if the
twisted pair is intact. This is readily shown with simple experiments.
One experiment showed a small network still worked properly with
two nodes having a 40 volts DC ground difference.
However, it is a good idea to include a good ground in the system
design. Some bus faults need the ground to allow the transceiver
to compensate.
Here are some bonus items that are not part of the CAN specification
that might prove helpful in your system:
1) Transmitting data sets greater than 8 bytes:
Clearly, transmitting a data set greater than 8 bytes will take multiple
frames and this will require some planning. Such schemes can
become very complicated as they have to deal with a wide-ranging
set of contingencies. By focusing on a narrow requirement set, design
of a simpler protocol is possible.
Most current schemes use the first data byte to contain the number of
total data bytes to follow plus a counter to help determine which data
byte is which. The ID usually identifies the node plus whether it is a
request or response message. To use an existing protocol, see ISO
15765. This is what automobiles use. This includes OBDII diagnostics
which is public information. This is a good example where one
message can be comprised of many CAN frames.
2) Periodic, Request/Response and Command Frames:
Periodic: This technique sends a frame out periodically – several
times a second is typical. This frame will contain data that any node
can use and is identified by its ID. Examples are speed, position,
pressure and events.
Request/Response: A node sends out a frame requesting certain
specified information. Any other nodes that have the requested
information then put it on the bus. The ID identifies the Request
frame and the Response by changing one bit of the Request ID. ID
0x248 is a Request frame and 0x648 is its Response. The Request
frame data bytes will specify what information is requested. The
Response frame will contain the requested information or an error
message.
Command: A frame commanding some event is performed. The ID
usually contains the address of the commanded node and the data
bytes the actual command(s). Sometimes an acknowledge frame
is returned.
TIP: Consider a blend of these three types of traffic depending on your
system’s needs.
3) Time-outs:
Automotive CAN networks use time-outs. This concept is easily and
effectively transferred to systems in other fields. A time-out occurs
when a node fails to respond to a request in a timely fashion. Timeouts
are handled completely by software. The CAN specification does
not provide this mechanism. A time-out is helpful to recover from
problems with the network such as severe bus errors, catastrophic
bus faults, faulty nodes or intermittent connections.
www.digikey.ca/microcontroller
51

The result is usually a limp-home mode in which a node will attempt
to run itself without information from the rest of the network. In some
cases, a punitive limp-home mode is entered that forces the user to
perform repairs.
A good example is if the transmission fails and proper shifting
becomes impossible. In this case, the module will go into limp-home
mode and the transmission might be put into one gear, such as
second, to allow the vehicle to still be driven.
This can be for safety reasons or to prevent further damage to the
power train.
Heart-beats and Address Claiming: The other side to a time-out
is a heartbeat. Periodic messages can be sent out to determine that
all nodes are on the bus and active. CANopen uses such heartbeats.
J1939 has a software mechanism in which each node can declare
itself to be on the bus and be recognized by the other nodes. This
is called “Address Claiming” and occurs during the system startup.
These mechanisms are provided by your software.
Sequence of transmitting data on the CAN bus:
1. Any node(s), seeing the bus idle for the required minimum time,
can start sending a CAN frame.
2. All other nodes start receiving it except those also starting to
transmit a message. (They all start at the same time.)
3. If any other node starts transmitting, the priority process starts.
The node with the highest priority continues on and those with a
lesser priority stop sending, immediately turn into a receiver and
receive the higher priority message.
4. At this point, only one node is transmitting a message and no
other nodes will start at this time.
5. When the transmitting node has completed sending its message,
it waits one bit time for the 1-bit ACK fi eld to be pulled to a logic
0 by any other node (or usually all of them) to signify the frame
was received without errors.
6. If this happens, the transmitting node assumes the message
reached its recipient, sends the end-of-frame bits and goes
into receive mode or starts to send its next message if it has
one. The receiving nodes pass the received message to their
host processors for processing unless the acceptance fi ltering
prevents this action.
7. At this time, any node can start sending any messages or the bus
goes into the idle state. Go to 1.
8. If this does not happen (ACK bit not set), then the transmitting
node retransmits the message at the earliest time allowed. If
the ACK bit is never set, the transmitting node will send this
message forever.
Transmitting notes:
• How does a node know when it should transmit a message
Create the CAN frame you want to send by loading up the IDE,
ID, DLC. Any data byte registers in the CAN controller and then,
in most controllers, you set a bit that triggers sending the frame
as soon as legally possible. After this, the controller takes care
of sending all frame bits. Until the controller signals otherwise
to the processor, you can assume the message was sent.
• What if there is an error All nodes, including the transmitting
node, monitor the bus for any errors. If an error condition is
detected, a node (or nodes) signify to the other nodes there is an
error by holding the bus at logical 0 for at least 6 bus cycles. At
this point, all nodes take appropriate action. The message being
sent (and now aborted) will be resent but only a certain number
of times.
• What if no node wants or uses the message Nothing.
The ACK bit only says that the CAN frame was transmitted
without errors and at least one node saw this frame error free.
Remember the transmitting frame cannot ACK itself. CAN does
not provide any acknowledgment mechanism that a frame was
used or not received by its intended recipient. If needed, you will
have to provide this in your software as many systems do.
TIP: In a periodic system, if a node misses a message, it does
not matter much as another copy will be along shortly.
Sequence of receiving data from the CAN bus:
1. All nodes except those currently transmitting frames are in
listening mode.
2. A CAN frame is sent using the procedure as described previously
in “Sequence of Transmitting data on the CAN Bus.”
3. This frame is received by all listening nodes. If deemed to be
a valid CAN message with no errors, the ACK bit is set. In CAN
terminology, the bus is set to the “dominant” state as opposed to
the “recessive” state.
4. The frame is sent through the controller’s acceptance fi lter
mechanism. If this frame is rejected, it is discarded. If accepted,
it is sent to the controller FIFO memory. If the FIFO is full, the
oldest frame is lost.
5. The host processor is alerted when a valid frame is ready to be
read from the FIFO. This is done either by an interrupt or a bit
set in a controller register. This frame must be read as soon as
possible.
6. The host processor decides what to do with this message as
determined by your software.
Receiving notes:
•
is available. Polling is where the host processor “polls” or
continuously tests the bit mentioned in sequence 5. Polling runs
the risk of losing or “dropping” a frame but is sometimes easier to
implement and debug. Interrupts cause the processor to jump to
an interrupt handler in which the frame is read from the controller.
Using interrupts is the recommended method.
• What happens if a message is “dropped” This can cause
some problems as CAN itself does not have a mechanism
for acknowledging a CAN frame. If desired, this must be
added to your software. In the case of Periodic Messages, it
doesn’t normally matter as a replacement message will be
along shortly.
52

• How fast do I have to read the FIFO to not drop messages
CAN controllers and their errata sheets
Test tools
Bit stuffing
Conclusion
CAN demonstration software
®
www.digikey.ca/microcontroller
53

STMicroelectronics CAN controller for Cortex-M3 processors
Shown is a block diagram of the CAN controller. Here are the main
points of all CAN controllers:
1. I/O Pins: These connect to the CAN transceiver chip pins R and D
as previously described.
2. Parallel-Serial Converters: CAN is a serial bus while the
processor is parallel. Conversion happens here.
3. Tx mailbox: The messages to be transmitted are written here. ID,
data (if any) and the DLC go here.
4. Acceptance Filter: This passes only specifi ed messages to the
processor via the FIFOs. By default at RESET, these fi lters pass
all messages to the FIFOs. Your software must confi gure them to
fi lter messages.
5. FIFO 0 & 1: Each Receive FIFO can hold three CAN messages.
They provide a buffering system to the processor.
6. Control, Status, Confi guration registers: Your software
must confi gure these registers, usually at initialization.
Various fl ags and switches are found here. Examples are
set CAN speed, request transmission, manage receive
messages, enable interrupts and obtain diagnostic
information. Keil provides examples on how to set and use
these registers.
All CAN controllers have the same basic architecture. Different
controllers will have differences in the number of receive FIFO
buffers, transmit buffers, size of acceptance fi lters and the bit
mapping, addresses and defi nitions of the various confi guration
registers. All CAN controllers are licensed by Robert Bosch GmbH
in Germany and therefore they are able to exert considerable
control over basic CAN attributes to make them consistent with
various manufacturers.
This means that all CAN controllers can communicate with other
brands in a reliable and predictable manner.
Figure 4: STMicroelectronics CAN controller for Cortex-M3 processors.
Keil example CAN program
1. Start μVision by clicking on its
icon on your Desktop.
2. Select Project/Open Project. Open the fi le C:\Keil\ARM\Boards\
Keil\MCBSTM32\CAN\CAN.Uv2.
3. Make sure “Simulator” is selected in the Target window.
4. There is a typo in a source fi le. In the fi le CanDemo.c,
go to line 126. It will probably be:
delay (45000000); // Wait for initial display (~5s)
This delay will be too long. Please change this to a lower value.
45000 works well.
5. Compile the source fi les by clicking on the Build icon.
They will compile with no errors or warnings.
6. Click on the Options for Target icon.
Then, select the Debug tab and confi rm
“Use Simulator” is checked.
7. Enter the Debug mode by clicking on the debug icon.
Select OK when the Evaluation Mode box appears.
8. Position the Toolbox, CAN: Communication and CAN: Controller
windows as appropriate.
9. Click on the RUN icon.
Note: Stop the program
with the STOP icon.
10. Note CAN messages with an ID of 0x21 will appear in the CAN:
Communications window. You can see both the transmit and
receive frames. The CAN controller is in a special Test Mode that
allows it to see its own messages.
11. In the Toolbox window, click on the
“Analog Sweep 0…3.3 V” button.
12. Changing data values representing output from the A/D convertor
will now appear in the CAN messages.
The Keil CAN demonstration software: How it works…
Keil provides a working CAN example with their development tools.
You have already compiled and run this example. You can view and
edit the C source fi les whether in debug mode or not, but to compile
them you must not be in debug mode. This example uses almost no
assembly code as it is (nearly) entirely written in C. Any source fi le
can be opened in μVision, if not already visible, by clicking on File/
Open and selecting it. There are three source fi les we will look at:
Can.h: This fi le defi nes a structure to contain the information used to
construct the CAN frame and create two instances of it.
Can.c: This C code initializes the CAN controller, writes and transmits
a message, receives a message, confi gures the Acceptance Filters
and provides the transmit and receive interrupt handlers.
CanDemo.c: The main function is located in this fi le. CanDemo.c is
the heart of the demonstration program and calls the functions in
Can.C.
54

1) Can.h
The CAN structure CAN_Msg: (lines 23-29, 42 & 43)
The structure declaration in Can.h is shown. You should now be able
to recognize each of these elements. You can enter either an 11- or
29-bit identifier. Two instances of CAN.msg are invoked and are
shown below: CAN_TxMsg and CAN_RxMsg. CanDemo.c writes to
these to create the CAN messages with data.
The prototypes for functions used in Can.c are listed in Can.h in lines
32 to 40. These are visible in μVision.
23 typedef struct {
24 unsigned int id; // 29 bit identifier
25 unsigned char data[8]; // Data field
26 unsigned char len; // Length of data
field in bytes
27 unsigned char format; // 0 - STANDARD,
1- EXTENDED
IDENTIFIER
28 unsigned char type; // 0 - DATA FRAME,
1 - REMOTE FRAME
29 } CAN_msg;
42 extern CAN_msg CAN_TxMsg; // CAN message for
sending
43 extern CAN_msg CAN_RxMsg; // CAN message for
receiving
2) Can.c
Configuring the CAN controller (Can.C)
There are several things that must be done to properly configure the
CAN controller. These are done in Can.C by functions that are called
by CanDemo.c. Examples are found in the function CAN_setup as
shown in μVision:
1. Enable and set the clock for the CAN controller. The clock must
be stable for CAN. No R-C oscillators here.
2. Configure GPIO ports PB8 and PB9 for the transmit and receive
lines to the transceiver chip.
3. Enable the interrupts for the transmit and receive functions.
4. Set CAN_BTR: This is a 32 CAN controller register in which things
such as bit timing, bus frequency, sample point and silent and
loop back modes are set. In the Keil example, the baud rate is
set to 500 Kbps. All CAN controllers on a network should have
consistent BTR values for stable operation.
Sometimes timing settings can cause strange problems. If you
experience some unusual problems, you might want to study CAN
timing in greater detail. For small systems, the default settings
or those suggested by the processor manufacturer will work
satisfactorily. You can adjust these settings for the most robust
bus performance.
All CAN controllers have the same general settings for bit timing
because of the licensing agreements with Robert Bosch GmbH.
For a detailed explanation of CAN bit timing, see www.port.de/pdf/
CAN_Bit_Timing.pdf, and for the calculations, see page 505 of the ST
Reference Manual RM0008.
Other functions in Can.c
• CAN_start: Starts the CAN controller by ending the
initialization sequence.
• CAN_waitReady: Waits until transmit mailbox is ready – then can
add another message to be transmitted.
• CAN_wrMsg: Writes a message to the CAN controller and transmit it.
• CAN_rdMsg: Reads a message from the CAN controller and
releases it to be sent to the STM32 processor.
• CAN_wrFilter: Configures the acceptance filter. This is not
discussed in this article.
• USB_HP_CAN_TX_IRQHandler: The transmit interrupt handler.
• USB_LP_CAN_RX0_IRQHandler: The receive interrupt handler.
These functions are called by CanDemo.c and in the main function.
3) CanDemo.c
This contains the main function and contains the example program that
reads the voltage on the A/D converter and sends its value as a CAN
data byte with an 11-bit ID of 0x21. CanDemo.c contains functions to
configure and read the A/D converter, display the A/D values on the LCD
and call the functions that initialize the CAN controller.
Transmitting a CAN Message:
Lines 131 to 135 put the frame values into the structure CAN_TxMsg.
(Except for the data byte from the A/D converter.)
131 CAN_TxMsg.id = 33; // initialise
message to send
132 for (i = 0; i < 8; i++) CAN_TxMsg.data[i] = 0;
133 CAN_TxMsg.len = 1;
134 CAN_TxMsg.format = STANDARD_FORMAT;
135 CAN_TxMsg.type = DATA_FRAME;
This CAN message will send one data byte. For example, if you
change the value in the member CAN_TxMsg.len to “3,” three data
bytes will be sent on the bus. What data will be in them depends on
the contents of the array CAN_TxMsg.data.
If you send more data bytes than you have data, it is a good idea to fill
the empty data bytes with either 0 or 0xFF.
141 CAN_TxMsg.data[0]= adc_Get (); // data[0] field
= ADC value
142 CAN_wrMsg (&CAN_TxMsg); // transmit
message
143 val_Tx= CAN_TxMsg.data[0]; // send to LCD
screen
Line 141 puts the A/D value into the data member CAN_TxMsg.data in
data byte 0 and line 142 transmits it.
www.digikey.ca/microcontroller
55

Receiving a CAN Message:
Lines 148 to 151 indicate when a CAN message is received, but
something more must be going on here. Line 151 shows that the data
byte received and inserted in the array[0] is sent to be displayed on
the LCD. How exactly does the CAN data byte get into the member
array CAN_RxMsg.data[0]
If you right click on line 210 and select Show Source at Current Line,
this will be displayed in the source fi le.
148 if (CAN_RxRdy) {
149 CAN_RxRdy = 0;
151 val_Rx = CAN_RxMsg.data[0];
It was stated earlier in this article that the function to read the CAN
data was located in Can.c. If we look in Can.c, we fi nd the function
CAN_rdMsg at lines 130 to 159. Examining it, clearly it is here that
the array[0] is loaded at line 148. How does this function get called
It is not called from CanDemo.c.
If we set a breakpoint on Can.c line 132 (the fi rst assembly instruction
of the function CAN_rdMsg) by double-clicking on the left side of Line
132, we can check the Call Stack window to see from where it was
called. This is shown in the screen shot below. This would indicate
line 148 in the main function called CAN_rdMsg. Examining the
assembly code at line 148 shows this cannot be true.
We can use the Trace function of μVision that is available in Simulator
mode to fi gure out how CAN_rdMsg is called.
Figure 5: CAN Call Stack window.
1. Click on Enable Trace Recording icon.
2. Run the program to the breakpoint set previously at line 132.
3. Click on View Trace Records.
View the Disassembly window
that opens up as shown in next window.
The yellow arrow points to the start of the function CAN_rdMsg. The
arrow represents the program counter.
The grey area shows a recording of the instructions that were
executed. The white area displays unexecuted instructions.
Just before line 132 is the source line 213: that calls CAN_rdMsg.
This is actually the assembly instruction at addresses 0x8000A10
BL.W CAN_rdMsg. Reading higher to 210, we can see this source line
comes from the function USB_LP_CAN_RX0_IRQHandler, which is the
Receive Interrupt Handler in Can.c.
So, this interrupt handler called the function that reads the CAN frame
from the CAN controller and inserts it into the structure.
Figure 6: Trace Window showing source code behind current instruction.
If you have more than one CAN controller in your processor, you can
operate these as parallel receivers. Divide the messages with the
Acceptance Filters. This will help capture all the messages on a very
busy bus without losing any. Each CAN controller will handle its share
of the messages. This effectively multiplies the number of FIFO buffer
memories and is an excellent method of getting all the CAN frames.
Exception, PC and data tracing
The ST Cortex-M3 processor possesses signifi cant debugging
capabilities. These features are grouped under the Serial Wire Viewer
and are supported by Keil μVision and the USB-JTAG adapter ULINK2
and ULINK-ME. Recall that Can.c contains two interrupt handlers: for
transmit and receive. These can be displayed in real-time (no CPU
cycles are stolen) in the Trace Records window as shown below. This
works only with a real target Cortex-M3 connected to μVision with a
ULINK2 or ULINLK-ME USB to JTAG adapter.
The Serial Wire Viewer can be used to display PC samples, data read
and write cycles, exceptions and other events. The ITM is a print type
instrumentation output.
To show our example using the Serial Wire Viewer and a STM32 chip:
1. Connect an STM32 processor to μVision and run the same CAN
program using the ULINK Cortex debugger.
2. Activate the Serial Wire Viewer as described in the appendix of
www.keil.com/download/fi les/labst.pdf.
3. Confi gure the Logic Analyzer to display CAN_RxMsg.data[0].
This will also display it in the Trace Records.
4. Set a breakpoint at the instruction at line 148in Can.c. This is the
fi rst instruction after the write to the array CAN_RxMsg. data[0].
This is needed because the instruction the breakpoint is set on is
not executed. We want to see and record this write, so we must
execute this source line.
5. Run the program to the breakpoint. The resulting Exception Trace
window is displayed in Figure 7.
Figure 7: Exception Trace window.
56

Two IRQ events are shown. Note an IRQ is a subset of Exceptions.
Referring to the ST RM0008 reference manual, IRQ 19 is the CAN
Transmit IRQ and IRQ 20 is the Receive IRQ. The Trace Records
window will also be displayed (Figure 8).
Figure 8: Trace Records window.
We can see the following lines:
• 3rd and 4th Line: Exception Entry and Exit: 35: This is the
transmit IRQ. Translate the 35 into IRQ19 in the Exception Trace
window (Figure 6).
• 5th Line: Exception Entry: 36: This is the entry of the receive
IRQ 20 – this is the Receive IRQ Handler.
• 6th Line: Data Write: The value 0x8F is written to address
0c2000004C by the instruction at 0x8004910. You can confi rm
that these values represent an assembly instruction that is
part of source line 148 and that the address written to is
CAN_RxMsg.data[0].
That fi nishes a partial demonstration of the Serial Wire Viewer
trace feature of the Cortex-M3 processor. Visit www.keil.com for
more information concerning the Serial Wire Viewer interface in
Cortex-M3 processors.
An example CAN network
Figure 9 shows a real two-node CAN network using Keil
MCBSTM32 (right) and the MCBSTM32E evaluation boards using the
same example code discussed in this article. The Tx of one node is
transmitted to the Rx of the other node and this is clearly seen on
the LCDs.
Note the twisted differential pair of wires CAN Hi and CAN Lo.
Note that no ground wire is used in this small network.
This setup is part of the Keil lab available for the STM32:
www.keil.com/download/fi les/labst.pdf. Full details are in the lab.
How can I learn more about these CAN examples
With a hardware board, you can generate and receive real CAN
messages and connect to other nodes or a CAN test analyzer. The lab
for the Keil MCBSTM32 board has instructions on how to do this.
This document has some interesting CAN examples. For instance, you
can use the Cortex-M3 Serial Wire Viewer to see the CAN messages
and interrupts displayed in real-time. You can compile these examples
with the evaluation version of the software. Please see www.keil.com/
download/fi les/labst.pdf.
STMicroelectronics supplies a complete software library for
all their peripherals in the STM32 family using the Cortex-M3
processor. This includes CAN support. Search www.st.com/stm32
for STM32F10xFWLib. A zip fi le, UM0427.zip, and an application
note, UM0427.pdf, are available. Keil μVision project and source
fi les are included. There is no charge for these libraries. Keil
uses portions of these libraries in their own examples programs.
These are identifi ed by the letters STLIB in the Keil μVision
project fi lename.
Keil makes NXP evaluation boards with CAN examples. Luminary
Micro also offers some with CAN controllers that are supported
by Keil examples. You now know how CAN works and are familiar
with the Keil software and will have no problem getting a real CAN
system operating. You have already run an accurate simulation
of a CAN network. If you obtain real target hardware, such as the
MCBSTM32, you can also connect up to any CAN network and
communicate with it.
Keil offers a complete CAN stack for all ARM7, ARM9 and
Cortex-M3/M1 processors. This comes as part of RL-ARM. (Please
visit www.keil.com/rl-arm/ for more information.) This comprehensive
package contains the RTX RTOS source (the actual RTOS is already
included free with the MDK toolset), USB, TCP/IP networking and the
CAN interface.
MCBSTM32E Evaluation Board (MCBSTM32EXL-ND)
The Keil MCBSTM32E Evaluation Board introduces you to
the STMicroelectronics Cortex-M3 family of ARM devices
and allows you to create and test working programs for
this advanced architecture. Featuring a QVGA LCD display
plus a wide range of
interfaces such as USB,
CAN, MicroSD Card and
UART, the MCBSTM32E is
a great starting point for
your Cortex-M3 project.
Figure 9: A two node CAN network using Keil MCBSTM32 and the MCBSTM32E
evaluation boards.
www.devtoolsxpress.com
www.digikey.ca/microcontroller
57

Power Debugging ARM Cortex-M3
and Cortex-M4 Applications
by Lotta Frimanson and Anders Lundgren, IAR Systems
Your application is now working properly,
but you’re still over your power budget.
This article shows you how to debug that
problem, too.
Power debugging is a recent innovation that provides software
developers with information about how the software implementation
in an embedded system affects system-level power consumption. By
coupling source code to power consumption, testing and tuning for
power optimization is enabled.
Long battery lifetime is a very important factor for many embedded
systems in almost any market segment--medical, consumer
electronics, home automation, and many more. Power consumption
has traditionally been a design goal that only the hardware developers
have been able to infl uence. But in an active system, power
consumption depends not only on the design of the hardware but also
how it is used, which in turn is controlled by the system software.
The technology for power debugging is based on the ability to
sample power consumption and correlate each sample with the
program’s instruction sequence and hence with the source code.
One diffi culty is achieving high precision sampling. It would be ideal
to be able to sample power consumption with the same frequency
the system clock uses, but power system capacitances reduce the
reliability of such measurements. Usually this is not a problem since
from the software developer’s perspective, it is more interesting
to correlate the power consumption with the source code and
various events in the program execution rather than with individual
instructions, so the resolution needed is much lower than one
sample per instruction.
Typically within the debug probe, a resistor is connected in series with
the supply to the development board. The voltage drop across this
resistor is measured, fed to a differential amplifi er and then sampled
by an A/D converter.
The key to accurate power debugging is a good correlation between
the instruction trace and the power samples. The best correlation can
be achieved if a complete instruction trace is available, as is the case
for ARM MCUs with ETM (Embedded Trace Macrocell) support. The
drawback with using ETM is that it requires a special debug probe
and ETM support in the device itself.
Figure 1: The debug module on Cortex-M3/M4.
Less accurate but still giving good correlation is to use the PC (Program
Counter) sampling facility available in the ARM Cortex-M3/M4 cores
(Figure 1). The DWT (Discrete Wavelet Transform) module implements
the PC sampler; it samples the PC periodically around 10,000 times per
second and triggers an ITM (Instrumentation Trace Macrocell) packet for
each sample taken. The ITM is the formatter for events originating from
the DWT. It packetizes the events and timestamps them. The debug
probe (J-Link Ultra) samples the power consumption of the device using
an A/D converter. By time stamping the sampled power values and the
PC samples, the debugger is able to present power data on the same
time axis as graphs like the interrupt log and variable plots as well as to
correlate power data with the source code.
As stated before, power debugging is based on the ability to sample
the power consumption and correlate each sample with the source
code. For example, in IAR Embedded Workbench the power samples
can be displayed in different formats. The Power Log window (Figure
2) is a log of all collected power samples. This window can be useful
to fi nd peaks in the power sampling, and since the power samples are
correlated with the executed code it is possible to double-click on a
value in the Power Log window and get to the corresponding code.
Figure 2: Power Log window.
58

Figure 3: Timeline window.
Another way of viewing the power samples is via the Timeline window
(Figure 3). In the Timeline window, the power samples are displayed
on a time scale together with the call stack and up to four application
variables that you can select.
Power profiling
On a Cortex-M3 device the debugger can utilize the PC sampling
possibility in the DWT module. This allows the debugger to sample the
PC and provide statistical profiling. The profiler finds the function that
correlates with the sampled PC value and builds an internal database
of how often the functions are executed to generate function profiling
information. The profiling information for each function in an application
will be displayed in a debugger while the application is running.
Low-power mode diagnostics
Many embedded applications spend most of their time waiting for
something to happen: receiving data on a serial port, watching an
I/O pin change state, or waiting for a time delay to expire. If the
processor is still running at full speed when it is idle, battery life is
being consumed while very little is being accomplished. So in many
applications, the microprocessor is only active during a very small
amount of the total time and by placing it in a low-power mode during
the idle time the battery life can be extended by orders of magnitude.
One approach is to have a task-oriented design and to use an
RTOS; in a task-oriented design a task can be defined with the
lowest priority and it will only run when there is no other task that
needs to run. This idle task is the perfect place to implement power
management. In practice every time the idle task is activated it puts
the processor into a low-power mode. Many microprocessors and
other silicon devices have a number of different low-power modes in
which different parts of the processor can be turned off when they are
not needed. The oscillator can, for example, be turned off or switched
to a lower frequency; peripheral units and timers can be turned
off; and the CPU then stops executing instructions. The different
low-power modes have different power consumption rates based on
which peripherals are left on.
Interrupt handling
In an event-driven system, for example, when the system is activated
the power consumption increases as the MCU comes into active
mode along with any peripheral devices. Once execution is suspended
by an interrupt with a higher priority, any peripheral devices that were
already active are not turned off, even though the thread with the
higher priority is not using them. Instead more peripheral devices may
be activated by the new thread, further pushing up consumption.
Even though system performance might be good, more optimizations
can still be made in the power domain. Power debugging will make it
easier to discover the extraordinary increase in power consumption
that occurs when an interrupt hits and identifies it as abnormal. A
closer examination of the Timeline window could have shown that
unused peripheral devices were activated and consuming power for a
longer period than necessary.
DMA versus polled I/O
DMA has traditionally been used to increase transfer speed. In the
MCU world chip vendors have invented a plethora of DMA techniques
to increase flexibility and speed and to lower power consumption. In
some architectures the CPU can even be put into sleep mode during
the DMA transfer. Power debugging allows the developer to experiment
and see directly in the debugger what effects these DMA techniques
will have compared to a traditional CPU-driven polled approach.
Finding conflicting hardware setups
To avoid floating inputs it is a common design practice to tie unused
MCU I/O pins to ground. If the software by mistake configures one of
the grounded I/O pins as a logical ‘1’ output, a current as high as 25
mA may be drained on that pin. This high unexpected current is easily
observed by reading the current value from the power graph; it is also
possible to find the corresponding erratic initialization code by looking
at the power graph at application startup. A similar situation will arise
if an I/O pin is designed to be an input and is driven by an external
circuit, but the software incorrectly configures the input pin as output.
Waiting for device status
One common mistake that could cause unnecessary power to be
consumed is to use a poll loop to wait for a status change of, for
example, a peripheral device. While code constructions execute
without interruption until the status value changes into the expected
state. Another related code construction is the implementation of a
software delay as a for or while loop.
In both of these situations the code could be changed to minimize the
power consumption. Time delays are better implemented by using a
hardware timer. The timer interrupt is set up and after that the CPU goes
into a low-power mode until it is awakened by the interrupt. Also a polling
of a device status change should be solved with interrupts if possible or
by using a timer interrupt so that the CPU can sleep between the polls.
Depending on the characteristics of the embedded system it could
be difficult to find these situations using power debugging. One way
forward is to use the different power debugging windows to get to
know the power profile of the application so that abnormal behavior
can more easily be identified.
Finally, power debugging allows the developer to verify the power
consumption as a factor of the clock frequency. A system that spends
very little time in sleep mode at 50 MHz is expected to spend 50 percent
of the time in sleep mode when running at 100 MHz. The power data in
the debugger will allow the developer to verify expected behavior and
if nonlinear dependency on the clock frequency exists, to choose the
operating frequency that gives the lowest power consumption. Power
consumption in a CMOS MCU is theoretically given by the formula:
PPPP = ffff ∗ UUUU2 ∗ kkkk
where f is the clock frequency, U is the supply voltage and k is a
constant.
www.digikey.ca/microcontroller
59

Analog interference
Mixing analog and digital circuits on the same board has its own
challenges. Board layout and routing become important in order
to keep the analog noise levels at a low level in order to ensure
accurate sampling of low-level analog signals. Doing a good
mixed-signal design requires careful hardware considerations and
skills. Software design can also affect the quality of the analog
measurements. Performing a lot of I/O activity at the same time
as sampling analog signals will cause many digital lines to toggle
state at the same time – a candidate for introducing extra noise
into the A/D converter.
Power debugging will help to identify interference from digital and
power supply lines affecting the analog parts. Interrupt activity
can easily be displayed in the Timeline window together with
power data. Be sure to study the power graph right before the A/D
converter interrupts. Power spikes in the vicinity of A/D conversions
could be the source of noise and must be investigated. All data
presented in the timeline window is correlated to the executed
code; simply double-clicking on a suspicious power sample will
bring up the corresponding C source code.
Conclusion
Power debugging techniques provide embedded developers the
ability to understand the effect of source code on their application’s
power consumption. By careful analysis of power “hot spots” and
the review of programming methods used, engineers can make
signifi cant battery lifetime savings even during the early stages of
project development.
Figure 4: Power spike due to stepper motor interfering with A/D-sampling.
We’re changing how engineers think about
design using Cortex-M0 solutions with:
Lowest active power – as low as 130 μA/MHz
Superior Code Density – 50% less code for most tasks
Higher performance – LPC1100 runs at over 45 DMIPS
Smallest size – the LPC1102 has a footprint of 5 mm 2
Low-cost toolchain – LPCXpresso for less than $30
Cortex-M0: a simple choice
www.digikey.ca/nxp-mcu
60

The Heartbeat Behind Portable
Medical Devices: Ultra-Low-Power
Mixed-Signal Microcontrollers
by Shahram Tadayon, Silicon Laboratories
Low-power, low-noise, low-cost MCUs are
powering the next generation of portable
medical devices.
The proliferation of sophisticated yet affordable personal medical devices is
transforming the health care industry, enabling consumers to monitor vital
signs and other key aspects of their health at home and on the go without
costly and inconvenient visits to the doctor’s office. According to Gartner,
Inc., portable consumer medical devices such as blood glucose monitors,
blood pressure monitors, insulin pumps, and heart rate monitors, represent
the fastest-growing segment in the medical equipment market. A recent
medical semiconductor report by Databeans projects that the home medical
device segment will experience a compound annual growth rate (CAGR) of
nine percent over the next five years.
The explosive growth of the personal medical device market stems
from a variety of factors: a steadily “graying” (aging) population
requiring more frequent health monitoring; skyrocketing costs of
traditional physician-directed medical care; growing consumer
awareness of the benefits of wellness products; widespread
availability of personal medical devices, both online and in
retail outlets; and the increasing sophistication, ease of use and
affordability of consumer health care products enabled by continuing
advances in semiconductor technology.
While consumer products are generally price sensitive, the consumer
portable health market adds other stringent requirements in order
for devices to be successful in the market. Above all, they must be
highly reliable and accurate in order to detect and help prevent health
problems. These requirements are regulated by government entities
such as the Food and Drug Administration (FDA) in the United States.
In order to succeed in the increasingly competitive home health care
market, portable medical devices should offer the following features:
• Ease of use
• Highly reliable and safe (government-regulated) operation
• Easy, secure connectivity
• Low-power operation (long battery life)
• Support for a wide range of voltages (especially lower voltages)
• High measurement accuracy
• Small form factors
• Affordable cost
To be able to deliver this array of product features to consumers at
economical prices, medical device developers must reduce system
cost by limiting the number of discrete components within the
design. Semiconductor suppliers also are tasked with supplying
highly integrated embedded control solutions that enable increased
performance and reliability within strict power and cost budgets.
At the heart of these portable device designs are highly integrated
mixed-signal microcontrollers (MCUs) designed to deliver exceptional
processing performance at the lowest supply currents.
Ease of use is essential for all portable medical products because it
reduces errors in measurement resulting from operator error. Such
devices should require minimal user interaction for proper operation,
simple user input (for example, fewer buttons and simpler software
menus) and large, backlit easy-to-read displays. To support these
features, MCUs must provide field-programmable, non-volatile
memory storage (typically in-system programmable flash memory),
as well as flexible I/O configurations to make the best use of a limited
number of pins.
While many portable medical devices today simply display health
monitoring results and leave the interpretation and logging to end users
and their physicians, newer devices feature simple connectivity to log
and transmit results automatically. Typically, these more sophisticated
products will connect to personal computers or mobile health
appliances with software that can track results, or they will securely
transmit information wirelessly to medical professionals, caretakers or
web-based applications – a practice known as telemedicine.
The health care equipment market has adopted an optimized USB
device standard, the Personal Health Care Device (PHCD) Class
(Figure 1), which leverages the ubiquitous USB interface to enable
standardized transmission of data and messages regardless of device
manufacturer. Moving forward, wireless transmission of data
Figure 1: USB personal healthcare device class supports easy connectivity.
www.digikey.ca/microcontroller
61

will make connectivity even easier with simple, yet reliable wireless
connections for even greater convenience. MCUs will need to provide
a variety of integrated connectivity interface methods, such as
integrated USB controllers with precision oscillators.
RF transmitters and transceivers working in concert with MCUs
can enable wireless connectivity for telemedicine applications. In
addition, wireless MCUs – highly integrated devices that combine
a low-power MCU core with a high-performance RF transceiver in
the same package – are now widely available. Silicon Labs’ Si10xx
wireless MCUs, for example, provide the ultra-low-power operation
required by battery-powered portable medical applications, coupled
with extended range and exceptional RF sensitivity enabled by an
integrated sub-GHz transceiver.
Whatever the connectivity method or system architecture used,
communication protocol stacks will require more code space in the
MCU. As a result, more memory in smaller footprint devices will be in
greater demand.
While choices in high-performance, low-power MCUs and
communications options will be important, all medical devices will
need to accurately and consistently measure and some aspect of a
person’s health, be it light (for blood oxygen), conductivity (for blood
glucose), pressure (for blood pressure), or temperature. In the health
care market, there is simply no room for errors in measurement.
Mixed-signal MCUs must give superior analog voltage measurement
results in the presence of noisy digital processor and communications
signals in small spaces. This is one of the most challenging
engineering problems faced by semiconductor suppliers, and such
specifi cations will be scrutinized by product engineers, especially
when faced with low battery voltages for the IC. Measurements must
be low in noise and distortion (good signal-to-noise and distortion
ratios) and highly linear. Analog-to-digital converter (ADC) operation
must be allowed even when the MCU is in operation; the end user
will expect to observe functions during measurement, and it is likely
that the MCU will interpret results in real time. Furthermore, all chip
features should be permitted even at the lowest battery voltages;
what good is the MCU if you cannot make a measurement over the
full battery life In short, MCU suppliers in this market must integrate
accurate analog measurements without compromise.
The next design challenge for the MCU supplier is the demand for
long battery life in the end product. “Portable” generally means that
the device is battery powered. Typically, added features result in
greater power consumption, but developers will not design a portable
medical product that requires end users to use large, heavy batteries
or to change them frequently.
MCUs must support three parts of a low-power strategy: low-power
while in active mode, low-power while in standby mode and reduced
time in an active state. The portable device, and thus the MCU, will
be in an off or lower power state most of the time; however, it will
often maintain some sort of function such as a clock/calendar or
alarm when not in use. While active power consumption is important,
minimizing the time awake is the key to extending battery life. MCU
designers must engineer ways to wake the MCU clock and analog
circuits for fast measurements and then allow the MCU to settle back
to a low-power state. For example, making a voltage measurement
with an ADC requires a voltage reference. Such voltage references
typically require tens of milliseconds to turn on and stabilize before
a measurement can be made. During this time the MCU is on and
draining the battery.
Silicon Labs’ ultra-low-power C8051F9xx MCUs (Figure 2) wake up
in microseconds like many power-effi cient MCUs, but the on-chip
voltage reference is designed to also wake within 2 microseconds,
allowing accurate ADC measurements to begin quickly. The ADC is
also designed to rapidly accumulate many measurements without
CPU intervention for improved results while further minimizing time
awake. The less time awake, the less current is drawn from the
battery while giving good results.
Figure 2: Fast wake times and short operation intervals will extend battery life.
Another important trend in MCU design involves supporting new
battery use confi gurations and technologies (Figure 3). Rechargeable
batteries are popular and typically need higher voltage support, so
integrated on-chip voltage regulators are mandatory. An emerging
trend is to use only one alkaline battery to reduce product size or to
save cost when the end user expects the supplier to ship an installed
battery. Until recently, this approach required the added cost and
space of a discrete DC-DC switching regulator to boost the alkaline
battery voltage for proper MCU operation (alkaline batteries have a
useful life to 0.9 V). Not only do these switching regulators create a
large amount of noise in voltage measurements, they must remain
on at all times to allow the MCU to wake from sleep mode, thereby
draining power and reducing battery life.
Sophisticated low-power MCUs such as Silicon Labs F9xx devices include
an integrated DC-DC regulator that addresses these issues. The result is
lower noise, less cost, reduced footprint, and better control, allowing the
DC-DC regulator to be off while the MCU is in its low-power state, thus
extending battery life. Even though this DC-DC regulator is integrated, it
should still output the boosted voltage supply externally to the rest of the
system for a true low-power, single-battery solution.
Figure 3: MCUs should support a wide range of voltages supplied by batteries.
62

While MCU suppliers continue to innovate and integrate powerand
battery-saving features, the trend toward energy effi ciency
would not be fully advantageous if the cost and footprint of
the MCU grew substantially. The goal is to help the embedded
developer deliver a lower cost, smaller end product as well as
reduce power consumption. Such solutions must reduce the bill
of materials and device size. The best MCUs will deliver plenty
of performance, integrated connectivity, memory and superior
analog peripherals in the smallest form factors. In other words,
semiconductor suppliers must provide increased functional
density without compromise.
Note the ultra-low-power MCU example in Figure 4 – 64 kB of fl ash
code storage, 4 kB of data RAM, an ADC, and two voltage regulators
(LDO and DC-DC boost convertor) within a 4 mm x 4 mm footprint
(in some cases even smaller). This compact mixed-signal MCU
design allows a complete measurement and interface system on a
single chip without sacrifi cing performance or battery life. Product
designers will be careful to choose MCUs like this with the right set
of peripherals to obtain the optimal cost/performance benefi t.
Embedded developers and product managers are under
continuous pressure to push the envelope of reduced cost, size,
power consumption, and increased performance in their portable
medical device designs. The answer is to use highly integrated
mixed-signal MCUs to deliver products to a market that demands
the very best in performance and affordability in the smallest form
factors. Functionally dense mixed-signal MCUs will provide the
heartbeat for the next generation of portable medical devices, and
health care equipment makers that deliver optimized products that
meet consumer needs will enjoy the benefits of this fast-growing
market segment.
Figure 4: F9xx ultra-low-power MCU architecture.
megaAVR: The Next Step in Capacity and Performance
When your designs need some extra muscle, you need the megaAVR. Ideal for
applications requiring large amounts of code, the megaAVR offers substantial
program and data memories with performance up to 20 MIPS. Innovative
picoPower technology minimizes power consumption. All megaAVRs offer
self-programmability for fast, secure, cost-effective in-circuit upgrades. You
can even upgrade the fl ash while running your application.
Based on industry-leading, proven technology, the megaAVR family offers our
widest selection of devices in terms of memories, pin counts and peripherals.
Choose from general-purpose devices to models with specialized peripherals
like USB, or LCD controllers, or CAN, LIN and Power Stage Controllers. It’s
easy to fi nd the perfect fi t for your project in the megaAVR product family.
Key Features
• Broad family — megaAVR offers our widest selection of devices in
terms of memories, pin counts and peripherals, enabling reuse of code
and knowledge across projects.
• picoPower technology — Selected megaAVR features ultra-lowpower
consumption and individually selectable low-power sleep modes
that make it ideal for battery-powered applications.
• High integration — The megaAVR features on-chip fl ash, SRAM,
internal EEPROM, SPI, TWI, and USART, USB, CAN, and LIN, watchdog
timer, a choice of internal or external precision oscillator, and general
purpose I/O pins, simplifying your design and reducing bill-of-materials.
• Analog functions — Advanced analog capabilities, such as ADC, DAC,
built-in temperature sensor and internal voltage reference, brown
out detector, a fast analog comparator and a programmable analog
gain amplifi er. The high level of integration allows designs with fewer
external analog components.
• Rapid development — megaAVR microcontrollers speed development
with powerful in-system programming and on-chip debug. In addition,
in-system programming simplifi es production line programming and
fi eld upgrades
www.digikey.ca/atmel-mcu
www.digikey.ca/microcontroller
63

USB 3.0—
Are We There Yet
by John Donovan, Low-Power Design
SuperSpeed USB may be slow out of the blocks,
but with a 10x speed advantage and lower power
profile than its predecessors, its compelling
advantages make it look like a sure winner.
Firewire 800
Firewire 400
0.2
0.2
49.6
31.6
39.3
39.9
40
73.6
74.5
75.8
If there was a universal serial bus in 1995, it was RS-232. Every PC in the
world had one, although you could connect only one device to it at a time.
Reconfiguring the port for new devices and/or applications required you
to either be a “power user” or have an engineering degree.
In January 1996, Intel introduced the Universal Serial Bus (USB), a
bidirectional, low-cost, low- to mid-speed peripheral bus that could
support as many as 127 devices, all of which could be added to the
bus in “plug-and-play” (initially “plug-and-pray”) fashion. USB 1.0
supported a data transfer rate of 12 Mb/s, which worked well for disk
drives. In 1998, USB 1.1 added a slower (1.5 Mb/s) rate to support
keyboards, mice, and other human-interface devices (HID).
Addressing the need for speed, the USB 2.0 specifi cation was released
in 2000 and standardized in 2001, promising a data rate of 480 Mb/s.
However, because of the overhead involved in the protocol and USB’s
heavy reliance on the processor for transaction arbitration and scheduling,
speeds closer to half that rate were more typical. Still, a theoretical 40x
increase in bus speed in four years was pretty impressive.
USB has since become the most successful PC peripheral
interconnect ever defi ned, with over 10 billion USB 2.0 products
installed today, a number that is rising rapidly. In-Stat predicts that
nearly 4.5 billion USB ports will ship in 2014, of which 1.7 billion will
support the new “SuperSpeed” USB 3.0 spec.
Facing competition from other high-speed interconnect protocols
(Figure 1), like 400 and 800 Mbps IEEE-1394 (FireWire) and HDMI
(both of which targeted high-data rate streaming of video), the USB
Implementers Forum (USB-IF) formalized the specifi cation for USB 3.0
in 2008, which promises a “SuperSpeed” data rate of 5 Gb/sec, a 10x
improvement over USB 2.0.
Design goals
With USB 2.0 having become universal, the key goal was to make
it faster. Since smart phone users can now sideload video fi les ten
times faster, this will supposedly keep HDMI or FireWire sockets from
proliferating on these devices.
SATA 3Gbps (direct)
eSATA
USB 2.0
Access Time (ms)
Average Read (MB/s)
Read Burst (MB/s)
Max Read (MB/s) USB 3.0
Min Read (MB/s)
The primary goals for USB 3.0 are to:
• Preserve the USB model of smart host and simple device.
• Leverage the existing USB infrastructure. This means
maintaining the same software architecture and easing the
migration from legacy products.
• Improve power management.
• Maintain ease-of-use.
• Preserve users’ investment in USB 2.0 devices.
0.1
0.1
0.2
0.1
0 50
29.8
36.3
36.8
36.8
Figure 1: Communications protocols speed comparison.
With minor modifi cations, USB software stacks will continue to
recognize the following three device classes:
• Communications Device Class (CDC), which presents the USB
port to an application as a standard COM port. Supporting bulk
transfers, the CDC provides high-bandwidth with a reasonable
amount of simplicity.
• Human Interface Device (HID) Class, which supports mice,
keyboards, touchscreens and other input devices. Bandwidth is
limited to 64 kb/s.
• Mass Storage Class (MSC), which supports moving large
amounts of data to and from fl ash drives, digital cameras, and
fl ash card readers.
69.8
99.6
91.7
119.8
120
121.1
194.5
227.9
216.3
184.4
196.8
213.1
100 150 200 250
64

USB 3.0 is clearly overkill for HID applications, but it’s definitely a
new contender for embedded CDC and MSC applications, particularly
those involving streaming high-definition video. Its power advantage
over legacy USB makes it a serious consideration for portable devices.
Architectural innovations
Achieving a 10x speed improvement while reducing power
consumption involved making serious architectural changes to both
the protocol and associated hardware. At the same time, some tradeoffs
(and clever workarounds) were necessary to maintain backward
compatibility with legacy USB 2.0 products.
For starters, USB 3.0 maintains the same tiered star topology as USB 2.0,
maintaining compatibility by adding two more twisted pairs to the
cable to supplement the USB 2.0 data pair, which is left untouched.
The two additional signal pairs create a dual simplex SuperSpeed
data path, with one pair for transmit and one for receive. This enables
backward compatibility by including both SuperSpeed and non-
SuperSpeed bus interfaces.
Super
Speed
SuperSpeed
Extended
Connector(s)
SuperSpeed
Function
High-
Speed
SuperSpeed
Hub
Non-SuperSpeed
Full-
Speed
Non-
SuperSpeed
Function
USB 2.0
Hub
Low-
Speed
USB 3.0 Hub
USB 3.0 Host
Extended
Connector(s)
Non-SuperSpeed
(USB 2.0)
Composite Cable
USB 3.0 Peripheral Device
Note: Simultaneous operation of SuperSpeed and non-SuperSpeed
modes is not allowed for peripheral devices
Figure 2: USB 3.0 dual-bus architecture. (Used with permission from USB-IF).
Polling is also eliminated. A USB 2.0 host continuously polls all
peripheral devices to see if they have data to send to the host
controller. All devices must therefore be on at all times, which not only
wastes power but adds unnecessary traffic to the bus. In USB 3.0,
polling is replaced by asynchronous notification. The host waits until
an application tells it that there is a peripheral with data it needs to
send to the host. The host then contacts that peripheral and requests
that it send the data. When both are ready, the data is transferred.
USB 2.0 is inherently a broadcast protocol. USB 3.0 uses directed
data transfer to and from the host and only the target peripheral. Only
that peripheral turns on its transceiver, while others on the bus remain
in powered-down mode.
Numerous innovations in the USB 3.0 architecture set it apart from its
predecessors (Figure 3).
Chip to Chip Port-to-Port End-to-End
Host
Device Driver/Application
USB System Software
Notifications
Transaction
Packets
Transactions
Data
Packets
Link Management Packets
Pkt
Delims
8b/10b
encode/
decode
Spread
Clock CDR
Link Control/Mgmt
Link Cmds
Scramble/
descramble
LFPS
Elasticity
Buffer/Skips
Hub
Pipe Bundle (per Function Interface)
Pkt
Delims
8b/10b
encode/
decode
Default Control Pipe
Spread
Clock CDR
Link Control/Mgmt
Link Cmds
Scramble/
descramble
LFPS
Elasticity
Buffer/Skips
Notifications
PHY
The SuperSpeed USB physical connection is comprised of two
differential data pairs: one transmit path and one receive path, both
operating at 5 GB/s. Each differential link is initialized by enabling
its receiver termination. In the absence of signaling, low frequency
periodic signaling (LFPS) is used to signal initialization and power
management information. Data is packetized and passed directly to
the intended receiver. Since USB 3.0 does not include a reference
clock, each PHY has its own clock domain with spread spectrum
clocking (SSC) modulation. The transmitter encodes data and control
characters into symbols using an 8b/10b code, ensuring enough
transitions that the receiver can accurately recover clock and data.
Link layer
SuperSpeed USB moves firmly into the realm of high-speed packet
processing. The link layer handles link initialization and flow control,
packet framing, link power management and error detection, and
recovery. There are separate Link Management Packets (LMP),
Transaction Packets (TP), Isochronous Timestamp Packets (ITP) and
Data Packets (DP); all start with a distinct 14 byte header packet,
consisting of 12 bytes of header information and a two byte CRC-16
code. This is not your dad’s USB.
Protocol layer
SuperSpeed USB is not a polled protocol, as devices may
asynchronously transmit notifications to the host. Host-transmitted
protocol packets are routed through intervening hubs, taking a direct
path to a peripheral device. The transmitter can transmit multiple
bursts of back-to-back sequences of data packets, while the receiver
can simultaneously transmit data acknowledgements without
interrupting the burst of data packets. This is a far more efficient use
of bus bandwidth than the half-duplex, non-bursting nature of traffic
on earlier USB buses.
Table 1 summarizes the main differences between high-speed USB
2.0 and SuperSpeed 3.0.
Power management
First, SuperSpeed makes more power available to connected
devices. The amount of power available on the USB bus (for
recharging cell phones and other portable devices, for example)
is increased from 5 V @ 500 mA in USB 2.0 to 5 V @ 900 mA for
USB 3.0. This is a distinct advantage as more portable devices have
come to rely on the USB bus not just for data transfer but also for
battery recharging.
Device
Transaction
Packets
Function
Device
Transactions
Data
Packets
Link Management Packets
Pkt
Delims
8b/10b
encode/
decode
Spread
Clock CDR
Link Control/Mgmt
Link Cmds
Scramble/
descramble
LFPS
Elasticity
Buffer/Skips
Figure 3: USB 3.0 logical architecture. (Used with permission from USB-IF).
USB Function
Power
Management
USB Device
Power
Management
(Suspend)
Localized
Link Power
Management
Device or Host PROTOCOL LINK PHYSICAL
www.digikey.ca/microcontroller
65

Table 1: USB 2.0 versus 3.0. (Used with permission from USB-IF).
Characteristic USB 2.0 USB 3.0
Data rate Low-speed (1.5 Mbps), full-speed (12
Mbps), and high-speed (480 Mbps).
Data
interface
Cable signal
count
Bus transaction
protocol
Power
management
Bus power
Port state
Data transfer
types
Half-duplex, two-wire differential
signaling. Unidirectional data fl ow
with negotiated directional bus
transitions.
Two: two for low-/full-/high- speed
data path.
Host directed, polled traffic flow. Packet
traffic is broadcast to all devices.
Port-level suspend with tow levels
of entry/exit latency. Device-level
power management.
Support for low/high bus-powered
devices with lower power limits for
unconfigured and suspended devices.
Port hardware detects connect
events. System software uses port
command to transitions the port
into an enabled state (USB data
communication fl ows).
Four data transfer types: control,
bulk, Interrupt, and Isochronous.
SuperSpeed (5.0 Gpbs).
Dual-simplex, four-wire differential
signaling separate from USB
2.0 signaling. Simultaneous
bi-directional data fl ows.
Six: four for SuperSpeed data path.
Two for non-SuperSpeed data path.
Host directed, asynchronous traffi c
fl ow. Packet traffi c is explicitly routed.
Multi-level link power management
supporting idle, sleep, and suspend
states. Link-, Device-, and Functionlevel
power management.
Same as for USB 2.0 with a 50%
increase for unconfigured power and
an 80% increase for configured power.
Port hardware detects connect
events and brings the port into
operational state ready for
SuperSpeed data communication.
USB 2.0 types with SuperSpeed
constraints. Bulk has streams
capability.
More importantly, SuperSpeed USB enables considerable power
savings by enabling both upstream and downstream ports to initiate
lower power states on the link. In addition, multiple link power
states are defi ned, enabling local power management control and,
therefore, improved power usage effi ciency. Eliminating polling
and broadcasting also went a long way toward reducing power
requirements. Finally, the increased speed and effi ciency of USB
3.0 bus, combined with the ability to use data streaming for bulk
transfers, further reduces the power profi le of these devices.
Typically, the faster a data transfer completes, the faster system
components can return to a low-power state. The USB-IF estimates
the system power necessary to complete a 20 MB SuperSpeed data
transfer will be 25 percent lower than is possible using USB 2.0.
The SuperSpeed specifi cation brings over Link Power Management
(LPM) from USB 2.0. LPM was fi rst introduced in the Enhanced Host
Controller Interface (EHCI) to accommodate high-speed, PCI-based
USB interfaces. Because of the diffi culty of implementing it, LPM was
slow to appear in USB 2.0 devices. It is now required in USB 3.0 and
for SuperSpeed devices supporting legacy high-speed peripherals.
LPM is an adaptive power management model that uses link-state
awareness to reduce power usage.
LPM defi nes a fast host transition from an enabled state to L1
Sleep (~10 µs) or L2 Suspend (after 3 ms of inactivity). Return from
L1 sleep varies from ~70 µs to 1 ms; return from L2 Suspend mode is
OS dependent. The fast transitions and close control of power at the
link level enables LPM to manage power consumption in SuperSpeed
systems with greater precision than was previously possible.
Link power management enables a link to be placed into a lower
power state when the link partners are idle. The longer a pair of
link partners remain idle, the deeper the power savings that can
be achieved by progressing from UO (link active) to Ul (link standby
with fast exit) to U2 (link standby with slower exit), and fi nally to U3
(suspend). Table 2 summarizes the logical link states.
Table 2: Logical link states. (Used with permission from USB-IF).
Link State Description Key Characteristics Device Clock Exit Latency
U0 Link active - On N/A
U1 Link idle, fast exit RX & TX quiesced On or off µs
U2 Link idle, slow exit Clock gen circuit also On or off µs-ms
quiesced
U3 Suspend Portions of device power
removed
Off
ms
Most SuperSpeed devices, sensing inactivity on the link, will
automatically reduce power to the PHY and transition from U0 to U1.
Further inactivity will cause these devices to progressively lower
power. The host or devices may further idle the link (U2), or the host
may even suspend it (U3).
Both devices and downstream ports can initiate Ul and U2 entry.
Downstream ports have inactivity timers used to initiate Ul and U2
entry. Downstream port inactivity timeouts are programmed by system
software. Devices may have additional information available that they can
use to decide to initiate Ul or U2 entry more aggressively than inactivity
timers. Devices can save significant power by initiating Ul or U2 more
aggressively rather than waiting for downstream port inactivity timeouts.
While the advantages of SuperSpeed USB are impressive, these
devices are just beginning to appear in a world dominated by USB 2.0.
For backward, compatibility SuperSpeed devices must support both
USB 2.0 and 3.0 link speeds, maintaining separate controllers and
PHYs for full-speed, high-speed and SuperSpeed links. By maintaining
a parallel system to support legacy devices, SuperSpeed’s designers
accepted higher cost and complexity as a price worth paying to avoid
compromising the speed advantage of their new architecture.
Adoption ramp
No new standard, whatever its technical advantages, is adopted
overnight. That is certainly true with USB 3.0, which needs to
see a critical mass of devices in the fi eld before it will take off.
Since consumers have long been content with USB 2.0, and since
SuperSpeed devices will initially be more expensive, consumers
will need to be convinced of compelling application benefi ts before
it is likely to see broad adoption. Streaming multimedia is almost
undoubtedly the killer app that will make this happen.
One of the major things holding back USB 3.0 is the lack of support
for it in core logic chipsets. Intel made much of its support for the
standard at IDF 2009, and there was plenty of talk about it at the
USB pavilion. However, at IDF 2010 Intel made no production silicon
announcements—reportedly because of the diffi culty of developing
bug-free silicon—and there does not appear to be any plan to include
it in either Sandy Bridge or Atom processors for the next year or so.
Intel’s apparent hesitation about supporting the standard will clearly
stall its adoption in the marketplace and give Intel-based embedded
developers pause about including it in their designs. Despite its recent
hesitation, Intel will almost undoubtedly support USB 3.0 by next year.
Meanwhile, the USB-IF announced more than 100 SuperSpeedcertifi
ed products at IDF 2010, so this train, while still getting up
to speed, has clearly left the station. It is now up to embedded
developers to determine whether USB 3.0 is appropriate for their
applications, and if so, to get on board.
66

Digi-Key, at your service.
Programming
Programmable Oscillators
Digi-Reel
Battery Packs
Cable Assembly Services
Departments
Phone ....................................................................800-344-4539
Sales/General Inquiries ..........................................E-mail: sales@digikey.com
Phone: 218-681-6674
Fax: 218-681-3380
Customer Service ..................................................E-mail: customer.service@digikey.com
Technical Support ..................................................E-mail: techs@digikey.com
Design Support Services (DSS) ...............................E-mail: design@digikey.com
Phone: 877-DK-DESIGN (877-353-3744)
Quote Request ........................................................E-mail: quotes@digikey.com
Comments/Suggestions .........................................E-mail: webmaster@digikey.com
Web Links:
Feedback ...............................................................www.digikey.ca/feedback
My Digi-Key ...........................................................www.digikey.ca/registration
TechZones SM ..........................................................www.digikey.ca/techzones
PTM Online...On Demand ® .....................................www.digikey.ca/ptm
New@Digi-Key ......................................................www.digikey.ca/new
DK Toolbar .............................................................www.digikey.ca/toolbar
BOM Manager ........................................................www.digikey.ca/bommanager
Digi-Key Catalogue ................................................www.digikey.ca/catalogue
Technical Support Web Chat ..................................www.digikey.ca/techchat
2

Digi-Key’s TechZones SM
• Featured products from
leading suppliers
• Application notes,
references designs,
PTMs, exclusive editorial
• Parametric search
tools and more!
Text Paper Contains 10% Post-Consumer Fiber
Please Recycle
©2011 Digi-Key Corporation, 701 Brooks Ave. South, Thief River Falls, MN 56701, USA
www.digikey.ca/techzones